2015-07-10 13:59 GMT+02:00 Josh Boyer <jwboyer(a)fedoraproject.org&gt;: > > Hi All, > > I was hoping someone could clarify the use cases for the cloud image, > particularly in light of the reductions being looked at (like removing > python). I ask because I honestly don't know what purpose the cloud > image is serving any longer. > That's a trade-off * minimize disk usage that comes with a cost on IaaS platforms. * minimize attack surface by removing unnecessary components * base image is a generic one, not everyone needs a python interpreter especially when you deploy a java or ruby apps. * cloud instances provides tooling to customize images at startup (cloud-init in our case) * you can save a customized image to be reused on most IaaS platforms. * Patterns of deployment in the cloud are based on the assumptions of full automation and minimal human interventions. In my own opinion, base image is a neutral base and one has to customize it for their use. We provide the tooling and a suitable base and it's a much harder task to minimize fedora than adding missing tools.

And that's again, my own opinion, but the day we will provide an easy way to generate customize/upload in IaaS cloud images for end-users (maybe through copr), the cloud story will be complete. Suse has done an awesome job in that direction through kiwi.

> The atomic image is squarely targeted at being small, and for running > containers. It is somewhat positioned as a CoreOS solution. With > that being the case, I'm curious how the cloud image is different and > not a repetitive image simply not using the atomic mechanisms. > One could see the current cloud image as a transitional step between the opinionated approach from Atomic Host and classical linux distro.

Atomic Host concept goes further than just CoreOS, as it could become the next way to envision linux distro including the desktop.

Cloud images are the current production, Atomic Host is the Research lab of the cloud SIG.

On 07/10/2015 07:28 AM, Josh Boyer wrote: > OK. So your answer to my immediate question is "neutral base that > people have to customize". Fair enough. Now, why would someone > wish to choose a Fedora cloud image over Ubuntu or CoreOS or any of > the other "minimal base that you have to customize" images? It depends on the use case (which seems like a recursive statement in this thread). ;) Our customers (disclaimer: I work for Rackspace) usually choose the operating system for cloud instances that they're most familiar with or the ones that mesh will with their organization's strategy. Ubuntu seems to be a popular choice due to the million howto's laying around for installing services on Ubuntu. When it comes to the ultra-minimal OS choices largely intended for container platforms, like CoreOS, Atomic, or RancherOS, the customer usually has an idea of how they're planning to integrate/automate those operating systems on multiple instances. Whenever I've spoken with customers about what they want from an OS in a virtual machine, they want it to contain a small package set that lets them run their automation on top of it (i.e. Ansible, Chef, Puppet). Removing Python from that image would be a serious curveball since most people expect to have Python available on any system running yum/dnf.

On Fri, Jul 10, 2015 at 07:52:29AM -0500, Major Hayden wrote: > Whenever I've spoken with customers about what they want from an OS > in a virtual machine, they want it to contain a small package set > that lets them run their automation on top of it (i.e. Ansible, Chef, > Puppet). Removing Python from that image would be a serious curveball > since most people expect to have Python available on any system > running yum/dnf. Yeah, I'm willing to back down on wanting to remove Python.

2015-07-10 15:59 GMT+02:00 Ryan Brown <rybrown(a)redhat.com <mailto:rybrown@redhat.com>>: On 07/10/2015 09:48 AM, Matthew Miller wrote: > On Fri, Jul 10, 2015 at 07:52:29AM -0500, Major Hayden wrote: >> Whenever I've spoken with customers about what they want from an >> OS in a virtual machine, they want it to contain a small package >> set that lets them run their automation on top of it (i.e. >> Ansible, Chef, Puppet). Removing Python from that image would be >> a serious curveball since most people expect to have Python >> available on any system running yum/dnf. > > Yeah, I'm willing to back down on wanting to remove Python. +1 It'd be a lot of work (rewriting dnf/whatever, maintaining both codebases, etc) for (relatively) little gain. Depends: for end-users, it could mean a smaller bill each month on storage.

But I agree that we're not ready to drop python and it's *unlikely* before a long time. I also agree that it shouldn't be a high/medium priority task. As for dnf, there are discussion upstream to rewrite it in C, VMWare has also written a drop-in replacement for dnf based on hawkey/librepo that could be considered. The more problematic component is cloud-init.

The atomic image is squarely targeted at being small, and for running containers. It is somewhat positioned as a CoreOS solution. With that being the case, I'm curious how the cloud image is different and not a repetitive image simply not using the atomic mechanisms.

On Fri, Jul 10, 2015 at 11:26 AM, Joe Brockmeier <jzb(a)redhat.com&gt; wrote: > On 07/10/2015 12:59 PM, Josh Boyer wrote: >> >> The atomic image is squarely targeted at being small, and for running >> containers. It is somewhat positioned as a CoreOS solution. With >> that being the case, I'm curious how the cloud image is different and >> not a repetitive image simply not using the atomic mechanisms. > > That's sort of a key difference -- atomic == I can't just dnf install > things. cloud == I can add on what I want the way I'm used to doing. > (e.g., not containerized) Yes, absolutely. However, if that is the only difference then I'm not sure how compelling it is when you compare it to all the other images provided elsewhere that let you do that already. Conversely, atomic is compelling _because_ of the Atomic platform. Atomic has novelty (for now), decent technical advantages, and a lot more marketing behind it.

So what I'm really after is what sets Fedora Cloud apart from every other distro cloud image. What use cases is it better at than {Ubuntu, SuSE, <whatever>}. How should it be positioned so the people want to use it over those, etc. Fedora, in the Cloud space, is still behind in market share compared to the rest of the Linux world. I'm really curious if that can be overcome, or if instead the focus should be on Atomic entirely because it has a better chance.

(To be fair, Workstation and Server also have the same questions to answer in comparison to their peers. However, they have both history and familiarity on their side. Fedora has traditionally been a "desktop" OS and Server can feed off of RHEL which dominates the enterprise space. Cloud doesn't share that luxury.)

On Fri, Jul 10, 2015 at 11:51 AM, Joe Brockmeier <jzb(a)redhat.com&gt; wrote: > On 07/10/2015 04:42 PM, Josh Boyer wrote: >> On Fri, Jul 10, 2015 at 11:26 AM, Joe Brockmeier <jzb(a)redhat.com&gt; wrote: >>> On 07/10/2015 12:59 PM, Josh Boyer wrote: >>>> >>>> The atomic image is squarely targeted at being small, and for running >>>> containers. It is somewhat positioned as a CoreOS solution. With >>>> that being the case, I'm curious how the cloud image is different and >>>> not a repetitive image simply not using the atomic mechanisms. >>> >>> That's sort of a key difference -- atomic == I can't just dnf install >>> things. cloud == I can add on what I want the way I'm used to doing. >>> (e.g., not containerized) >> >> Yes, absolutely. However, if that is the only difference then I'm not >> sure how compelling it is when you compare it to all the other images >> provided elsewhere that let you do that already. Conversely, atomic >> is compelling _because_ of the Atomic platform. Atomic has novelty >> (for now), decent technical advantages, and a lot more marketing >> behind it. > > Well, I mean... it's compelling for us because we want people to have > Fedora available $all_the_places, right? Not always. We don't want people to have Fedora on their phones. :)

> So having only Atomic means we'd basically be saying if you want to do > things in the cloud, either do them the "Atomic way" or use another > project, right? The perception I've seen already indicates we're going that way. If all the hype is around containers these days, even the Fedora cloud download page plays Atomic up. It positions Atomic as the solution for containers and makes no mention of the fact that the base image would work too. It just says it's flexible.

> I think we'd be sending the wrong message by abandoning the generic > cloud image, though. Sure, maybe. So instead maybe try sending just as strong of a message for the Cloud image as is done for the Atomic image. This is really primarily a marketing issue. The more I try and figure this all out, the more I think Cloud is being overshadowed by Atomic and keeping them together is detrimental in the long run. My perspective is going to be much different from someone that lives and breaths cloud on a daily basis. But if I'm confused, there are other people out there wondering the same thing and clearing it up will help more than just me.

> provided elsewhere that let you do that already. Conversely, atomic > is compelling _because_ of the Atomic platform. Atomic has novelty > (for now), decent technical advantages, and a lot more marketing > behind it. Well, I mean... it's compelling for us because we want people to have Fedora available $all_the_places, right? So having only Atomic means we'd basically be saying if you want to do things in the cloud, either do them the "Atomic way" or use another project, right?

I think the Cloud SIG should be jumping up and down on getting SCLs back on track.

I just know I really like SCLs, how they work, and the capabilities. It's a big differentiator for the distro at large, and could be really useful for the envisioned Cloud end-user. I don't want to step on nuanced discussions of over 18+ months though.

So what I'm really after is what sets Fedora Cloud apart from every > other distro cloud image. What usecases is it better at than {Ubuntu, > SuSE, <whatever>}. Given that logic, Fedora should stop everything but Atomic. The Cloud image should be Fedora optimized for the cloud instance experience, just like Workstation is Fedora optimized for the desktop user experience. It shouldn't be massively different for Cloud than Server, b/c the use case between Server and Cloud isn't that large. Fedora should have a "typical" answer for what use cases are better than XYZ distro, that isn't dependent on a (frankly) edge use case like a container specific platform. Atomic is a new and interesting thing, with a very small and specific purpose and design. That's a good thing and shouldn't be used as an argument against the Cloud image. Or even as a comparison. > > Depends: for end-users, it could mean a smaller bill each month on > storage. > > I'm not a fan of this argument for minimizing the Cloud experience as the real cost of "magnetic" storage in most cloud providers is small. If pulling Python saves 1GB of on disk installed OS space, then users in a AWS environment save $0.24 a month / server in the most expensive storage in the most expensive region (Sao Paolo if you're curious). And I'm sure we aren't shaving that much off the image. I have to think the level of engineering required to majorly redesign things around minimization efforts are likely mis-placed if end user cost is the main metric.

That's where the Stack&Env WG work is important for us, as it could become > an asset against our other offers. > This ^^^ I'm a firm believer that the SCL work that got dropped is a huge value when we want to talk about differentiating Fedora as a Cloud or Server platform. The ability to cleanly separate system requirements from end-user platforms is huge. I think the Cloud SIG should be jumping up and down on getting SCLs back on track. - Matt M

More globally, our cloud image is still too fat compared to other distros by a large margin. What's a data supported target for an appropriate "small enough" sized Cloud image?

Multiply this by the number of instances, and it could amount to few > thousands dollars per month. > Agreed, that could be an issue. > More globally, our cloud image is still too fat compared to other distros > by a large margin. I'd like to see data. The end user will wind up paying for all storage attached to a running instance, not just what OS is laid down. Based on a quick launch, the current Ubuntu 14.04 HVM community image in EC2 is based on an 8GB image. What's a data supported target for an appropriate "small enough" sized Cloud image? On Fri, Jul 10, 2015 at 12:04 PM, Haïkel <hguemar(a)fedoraproject.org&gt; wrote: > > > 2015-07-10 17:59 GMT+02:00 Matt Micene <nzwulfin(a)gmail.com&gt;: > >> So what I'm really after is what sets Fedora Cloud apart from every >>> other distro cloud image. What usecases is it better at than {Ubuntu, >>> SuSE, <whatever>}. >> >> >> Given that logic, Fedora should stop everything but Atomic. The Cloud >> image should be Fedora optimized for the cloud instance experience, just >> like Workstation is Fedora optimized for the desktop user experience. It >> shouldn't be massively different for Cloud than Server, b/c the use case >> between Server and Cloud isn't that large. >> >> Fedora should have a "typical" answer for what use cases are better than >> XYZ distro, that isn't dependent on a (frankly) edge use case like a >> container specific platform. Atomic is a new and interesting thing, with a >> very small and specific purpose and design. That's a good thing and >> shouldn't be used as an argument against the Cloud image. Or even as a >> comparison. >> >> >>> > Depends: for end-users, it could mean a smaller bill each month on >>> storage. >>> >>> >> >> I'm not a fan of this argument for minimizing the Cloud experience as >> the real cost of "magnetic" storage in most cloud providers is small. If >> pulling Python saves 1GB of on disk installed OS space, then users in a AWS >> environment save $0.24 a month / server in the most expensive storage in >> the most expensive region (Sao Paolo if you're curious). And I'm sure we >> aren't shaving that much off the image. I have to think the level of >> engineering required to majorly redesign things around minimization efforts >> are likely mis-placed if end user cost is the main metric. >> >> > Multiply this by the number of instances, and it could amount to few > thousands dollars per month. > More globally, our cloud image is still too fat compared to other distros > by a large margin. > > > >> That's where the Stack&Env WG work is important for us, as it could >>> become >>> an asset against our other offers. >>> >> >> This ^^^ I'm a firm believer that the SCL work that got dropped is a >> huge value when we want to talk about differentiating Fedora as a Cloud or >> Server platform. The ability to cleanly separate system requirements from >> end-user platforms is huge. I think the Cloud SIG should be jumping up and >> down on getting SCLs back on track. >> >> - Matt M >> >> > Well, SCL is another topic (to remain polite), and I'm more than happy to > let Stack&Env WG > dealing with that matter. > > Regards, > H. > > > _______________________________________________ > cloud mailing list > cloud(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > >