Matthew, Thanks for taking the time to respond. I did not quite make myself clear. I saw this post today and it is more succinct: Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> Oct 29 (4 days ago) to jzb, Fedora, server, tamertas On Thu, Oct 29, 2015 at 9:16 AM, Joe Brockmeier <jzb@xxxxxxxxxx> wrote: > On 10/28/2015 08:21 PM, Josh Boyer wrote: >> The *could* be the same thing, >> except cloud-init is terrible and I hate it and if that was the single >> offering we had for some kind of C&S WG I would cry. I hate it >> because it is ridiculous to use in a non-cloud environment, and Server >> very much has that as part of it's reach. > > Forking this thread briefly because I think this deserves its own > discussion. I apologize if my rambling wasn't clear on this point. Hopefully this tangent is short-lived. > Is your objection primarily to the concept of cloud-init or the > implementation? If it's the concept, not much we can help with there. If > it's the implementation... Well, neither really. Admittedly my use of the Cloud images, and therefore cloud-init, was in attempted to boot it in a VM and log in more like a traditional install for simple test purposes. That didn't work and getting it to the point where I could log in required running some virt-tool thing to modify the image offline. So in the context of "Server & Cloud", where people expect to be able to log in after an install in many cases, cloud-init makes it really hard and is ill-suited to that kind of environment. Specific to cloud environments, I have no idea if the hassle of getting it setup is the norm or worthwhile. I've been told it is, and I can see where having the infrastructure setup to provide the credentials already in place might make the hassle much less problematic. (It is also quite possible I hit a bug in the cloud image. I tried running the local setup to provide cloud-init with ssh keys and it didn't work, hence the virt-tool thing. It has been a while since I tried again.) > We've talked about replacing cloud-init a few times in the past, but > there are two objections: > > - cloud-init is "standard" and we have an uphill marketing battle to get > our image adopted with something else. > - lack of a great alternative. I completely believe both of these. > Mike has talked about a "rich boot process" previously, and I wonder if > we're ready to start working on that? I'm not sure what "rich boot process" means. I'd immediately interpret that as "a real init process" which to me means using systemd. Somehow I don't think that's what you're thinking... :) > Also, one of the CentOS GSoC projects was "Flamingo" "a lightweight > contextualization tool that aims to handle initialization of cloud > instances." [1] Maybe this is something we could look at for F24? CC'ing > Tamer Tas, the student who worked on that. (It's targeted at being a > cloud-init replacement for Atomic, so...) > > [1] https://github.com/tmrts/flamingo That might be nice for "get rid of python" reasons. If it had cloud-init compatibility that would be even better, since people wouldn't need to migrate their provisioning infrastructure. josh > RUWACH GROUP > Integrated Technology Professionals > __________________________________________________ > Bruce Harrison, MSIS > bfharrison@xxxxxxxxxxxxxxx > www.about.me/bfharrison > 540.226.0729 - Direct > 877.338.9264 ext 700 Toll Free > Other Numbers: > - 877.338.9264 option 1: Sales > - 877.338.9264 option 2: Support > - 877.338.9264 option 3: > On Oct 28, 2015, at 10:54 AM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > >> On Tue, Oct 27, 2015 at 08:23:59PM -0400, Bruce Harrison wrote: >> Although I just downloaded the Fedora Cloud, I want to test it and, >> if it is what I am looking for, let some of my customers who live on >> DeskTone, give this a test drive from a fast thumb drive on a laptop >> or even a modified Chromebook. These people are attorneys and real >> estate professionals that need the dependability of the cloud without >> Redmond controlling how they use the vehicle to get there - something >> lean and mean. > > Hi Bruce. If I understand you, Fedora Cloud Base is *not* what you're > looking for, although we may have something in Fedora. First, I know of > several people doing their own "desktop as a service" based on Fedora, > including at least one law firm. That might interest you as a possible > replacement for Desktone, if that's what you're looking for. > > But it sounds also like what you're looking for is a hosted file / > calendar / etc sync-and-share server — what people think of as cloud > services like Google Drive and etc. We have several things in the > greater Fedora universe that might fit that bill, and running ownCloud > — possibly on top of the Fedora Cloud Base image, or on Fedora Atomic — > might indeed fill that need. > > The Fedora Cloud edition downloads, however, won't give you this out of > the box. (It might be something we want as a Fedora Server role in the > future, though.) > > I think that overall, this might be another reason for demphasizing > "Cloud" as a Fedora edition. When we use the term, we mean it in the > sense of cloud computing — on-demand self service, broad network > access, resource pooling, elasticity, and measured service. And the > Fedora Cloud image is just one part of the picture. It's an operating > system meant to run inside an IaaS — infrastructure as a service — > cloud provider, like Amazon EC2 or an OpenStack or Eucalyptus instance > you configure yourself (see https://www.rdoproject.org/ or > http://www8.hp.com/us/en/cloud/helion-eucalyptus.html). You could then > use that to build up a Platform as a Service (on which you could run > Software as a Service), or any other "XaaS" — including file storage > and sync. But we don't currently have a turnkey solution for that. > > But, maybe I'm misunderstanding you. Can you explain your needs a > little more fully? > > > -- > Matthew Miller > <mattdm@xxxxxxxxxxxxxxxxx> > Fedora Project Leader > _______________________________________________ > cloud mailing list > cloud@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
