Re: Fedora 22 is out, Fedora 23 is coming :)
On Thu, Jun 04, 2015 at 02:10:05PM -0400, Josh Boyer wrote: But in order to be really useful unless they're all-in on Fedora, many people will want the python version for their infrastructure/environment, not whichever python we happen to ship in a given release. I will provide flexibility and utility by providing no flexibility and utility sounds like a crappy marketing point to me. Well, if we got a resounding python is definitely the one thing we want, that'd be one thing. The first-round plan was to offer a very lightweight image — minimal + provisioning utils like cloud-init — and then language stacks via SCLs. Adding those was where the utility was supposed to come from. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 is out, Fedora 23 is coming :)
But in order to be really useful unless they're all-in on Fedora, many people will want the python version for their infrastructure/environment, not whichever python we happen to ship in a given release. That's always been the case and why software collections came about. Rewriting system tools to make it easier for someone who might like to use a different version of python at /usr/bin sounds like overkill. A lot EC2 AMIs, public and private, are 8GB+ snapshots with 2GB+ of OS installed. I may be broken recording but I'm still seeing context switches between the cloud flavors (atomic, docker base, cloud-ified server). We need to be careful were making the right changes to the right flavor. Ripping everything out of Docker Base makes sense, not so much for Cloud Server. A common baseline across the board that says Cloud Server is Base + Server and Docker Base is Base + Stripped System Utils may not be worth the effort to maintain. On Thu, Jun 4, 2015 at 1:05 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Jun 04, 2015 at 01:00:34PM -0400, Josh Boyer wrote: But cloud isn't minimal. It's Cloud. It needs to be useful for Cloud-y things. Like management via Ansible, etc. If you're going for minimal, you guys might as well become the Base image which doesn't exist today. But in order to be really useful unless they're all-in on Fedora, many people will want the python version for their infrastructure/environment, not whichever python we happen to ship in a given release. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 is out, Fedora 23 is coming :)
1. If it were me, I'd merge Server and Cloud products into one, called Server, and distribute it as an install DVD , a netinstall CD and images for the various cloud hosting providers. Strip as much as you can out of it to get the image sizes down but keep Anaconda, dnf and repository compatibility with Workstation. 2. The Docker base image is OK in size now - it's still bigger than Debian 'jessie' but its close in size to the much more widely used Ubuntu 14.04 LTS and CentOS 7 images. The problem with the Fedora base Docker image isn't size, it's that it isn't popular. Go look at the download numbers on Docker Hub: Ubuntu: 4397479 CentOS: 727768 Debian: 426676 Fedora: 106409 We got there late and Ubuntu grabbed the market share. I'm using Fedora in my Docker images mostly to maintain compatibility with Workstation, but that costs me when someone asks, Why aren't you using Ubuntu like everyone else? I can't just fork your project - I have to port it! In all likelihood I'll be forced to port the images to Ubuntu 14.04 LTS if I want people to use them. :-( On Thu, Jun 4, 2015 at 10:34 AM, Matt Micene nzwul...@gmail.com wrote: But in order to be really useful unless they're all-in on Fedora, many people will want the python version for their infrastructure/environment, not whichever python we happen to ship in a given release. That's always been the case and why software collections came about. Rewriting system tools to make it easier for someone who might like to use a different version of python at /usr/bin sounds like overkill. A lot EC2 AMIs, public and private, are 8GB+ snapshots with 2GB+ of OS installed. I may be broken recording but I'm still seeing context switches between the cloud flavors (atomic, docker base, cloud-ified server). We need to be careful were making the right changes to the right flavor. Ripping everything out of Docker Base makes sense, not so much for Cloud Server. A common baseline across the board that says Cloud Server is Base + Server and Docker Base is Base + Stripped System Utils may not be worth the effort to maintain. On Thu, Jun 4, 2015 at 1:05 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Jun 04, 2015 at 01:00:34PM -0400, Josh Boyer wrote: But cloud isn't minimal. It's Cloud. It needs to be useful for Cloud-y things. Like management via Ansible, etc. If you're going for minimal, you guys might as well become the Base image which doesn't exist today. But in order to be really useful unless they're all-in on Fedora, many people will want the python version for their infrastructure/environment, not whichever python we happen to ship in a given release. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 is out, Fedora 23 is coming :)
I see 3 editions based on the current images offered [1] (not a fan of the terms, just looking at the web page): * Base Cloud * Atomic Host * Docker Base The current Cloud PRD [2] refers (in my reading) mainly to Base Cloud. This is where I think the discussion of removal of python sits. I think it's a balance between Req #1 of the PRD and Req #6 as well as sticking to the user stories, not building a new way users are required to use Fedora. Building updated images as an *option* for folks who want to or have the processes in place to do immutable servers or other Ops patterns shouldn't preclude those who still want to run dnf update from using Fedora Base Cloud. What Atomic is going to do re: faster 2 week releases starting w/ F22 b/c of speed of release of core software is separate. It adds to the confusion, certainly. And I jumped the gun on SCL, I hadn't realized that proposal had been marked rejected after stalling on package reviews. I think Req #5 and the need for multiple stacks is the ideal argument for SCL. [1] https://getfedora.org/en/cloud/download/ [2] https://fedoraproject.org/wiki/Cloud/Cloud_PRD?rd=Cloud_PRD On Thu, Jun 4, 2015 at 2:08 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Thu, Jun 4, 2015 at 1:34 PM, Matt Micene nzwul...@gmail.com wrote: But in order to be really useful unless they're all-in on Fedora, many people will want the python version for their infrastructure/environment, not whichever python we happen to ship in a given release. That's always been the case and why software collections came about. Rewriting system tools to make it easier for someone who might like to use a different version of python at /usr/bin sounds like overkill. A lot EC2 AMIs, public and private, are 8GB+ snapshots with 2GB+ of OS installed. I may be broken recording but I'm still seeing context switches between the cloud flavors (atomic, docker base, cloud-ified server). We need to be careful were making the right changes to the right flavor. Ripping Yes, please. It's gotten to the point where I don't even know what the Cloud Edition actually is any longer. It was confusing enough with the changes from F21-F22, and now (I thought) we basically are dropping all of the Atomic flavors that were done in F22 because Fedora moves to slow. So what is left, what are the images, and what are they based on? So confused. josh ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 is out, Fedora 23 is coming :)
On Thu, Jun 4, 2015 at 1:34 PM, Matt Micene nzwul...@gmail.com wrote: But in order to be really useful unless they're all-in on Fedora, many people will want the python version for their infrastructure/environment, not whichever python we happen to ship in a given release. That's always been the case and why software collections came about. Rewriting system tools to make it easier for someone who might like to use a different version of python at /usr/bin sounds like overkill. A lot EC2 AMIs, public and private, are 8GB+ snapshots with 2GB+ of OS installed. I may be broken recording but I'm still seeing context switches between the cloud flavors (atomic, docker base, cloud-ified server). We need to be careful were making the right changes to the right flavor. Ripping Yes, please. It's gotten to the point where I don't even know what the Cloud Edition actually is any longer. It was confusing enough with the changes from F21-F22, and now (I thought) we basically are dropping all of the Atomic flavors that were done in F22 because Fedora moves to slow. So what is left, what are the images, and what are they based on? So confused. josh ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 is out, Fedora 23 is coming :)
On Thu, Jun 4, 2015 at 1:05 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Jun 04, 2015 at 01:00:34PM -0400, Josh Boyer wrote: But cloud isn't minimal. It's Cloud. It needs to be useful for Cloud-y things. Like management via Ansible, etc. If you're going for minimal, you guys might as well become the Base image which doesn't exist today. But in order to be really useful unless they're all-in on Fedora, many people will want the python version for their infrastructure/environment, not whichever python we happen to ship in a given release. I will provide flexibility and utility by providing no flexibility and utility sounds like a crappy marketing point to me. josh ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 is out, Fedora 23 is coming :)
On Thu, Jun 4, 2015 at 10:11 AM, Matthew Miller mat...@fedoraproject.org wrote: On Mon, Jun 01, 2015 at 06:20:32PM +0530, Kushal Das wrote: Below I have written few points which came up in different discussions. Please feel free to comment/add/delete in this thread. * Better automation or at least SOP for release - docker hub - can we integrate this into fedimg? * Cloud providers: Azure, GCE, Digital Ocean, HP, others - push is hard for us because of legal requirements; can we make pull arragements? also, comments: * Reduce the base cloud image size (we also have https://fedorahosted.org/fedora-badges/ticket/378 ) I'm a little baffled by why it grew so much this time around; there's a few extraneous things in the package set, but not a lot new and egregious, yet it still grew. * https://github.com/vmware/tdnf this might help us to go another step closer to remove Python stack from the cloud image.* Having a better We need to talk to Peter Jones about plans to rewrite grubby in Python. I'm very sympathetic to his wish to have it no longer be in C, but if we _really_ are moving to getting python out Er, can you elaborate on this desire to get python out? I'm kind of confused. Particularly about why grubby is such a concern. If you don't have python, you don't have yum/dnf which means updating your kernel in your cloud image at _runtime_ is a PITA. If you aren't updating your kernels at runtime and are instead relying on the whole image to be respun (ala Atomic or otherwise) then you don't need grubby anyway and it doesn't matter what language it's written in. Secondly, isn't a lack of python in the cloud image going to impact their ability to be managed via things like ansible/puppet/chef/whatever? This really kind of baffles me. I would love to hear the reasoning behind it. josh ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 is out, Fedora 23 is coming :)
On Thu, Jun 04, 2015 at 01:00:34PM -0400, Josh Boyer wrote: But cloud isn't minimal. It's Cloud. It needs to be useful for Cloud-y things. Like management via Ansible, etc. If you're going for minimal, you guys might as well become the Base image which doesn't exist today. But in order to be really useful unless they're all-in on Fedora, many people will want the python version for their infrastructure/environment, not whichever python we happen to ship in a given release. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 is out, Fedora 23 is coming :)
On Thu, Jun 4, 2015 at 12:43 PM, Colin Walters walt...@verbum.org wrote: On Thu, Jun 4, 2015, at 12:31 PM, Josh Boyer wrote: If you don't have python, you don't have yum/dnf which means updating your kernel in your cloud image at _runtime_ is a PITA. OSTree has built in support for updating the kernel at runtime. The fact that it does so atomically in concert with the rest of userspace is an important aspect of how it works. Systems (by default) have two kernels and two userspaces which share storage; if both userspace trees reference the same kernel, the storage isn't duplicated. If you aren't updating your kernels at runtime and are instead relying on the whole image to be respun (ala Atomic or otherwise) There appears to be some confusion here - Atomic/rpm-ostree is definitely capable of incremental upgrades that install a new kernel at runtime, there's no whole image to be respun. The tree is currently composed on a build server, not on the client, and it is a fresh installroot every time, but clients only download objects which have changed. Right, I know that. The confusion here isn't about how Atomic works. The confusion stems from the fact that I thought Atomic was going off to do its own thing, and the Cloud images would be non-Atomic images. If that isn't the case, the OK but I've missed that as well. Secondly, isn't a lack of python in the cloud image going to impact their ability to be managed via things like ansible/puppet/chef/whatever? Mainly Ansible...Chef and Puppet both require agents. Sure, but ansible is kind of a big thing to lose by default. josh ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 is out, Fedora 23 is coming :)
On Thu, Jun 04, 2015 at 12:31:15PM -0400, Josh Boyer wrote: * https://github.com/vmware/tdnf this might help us to go another step closer to remove Python stack from the cloud image.* Having a better We need to talk to Peter Jones about plans to rewrite grubby in Python. I'm very sympathetic to his wish to have it no longer be in C, but if we _really_ are moving to getting python out Er, can you elaborate on this desire to get python out? I'm kind of confused. Particularly about why grubby is such a concern. If you don't have python, you don't have yum/dnf which means updating your kernel in your cloud image at _runtime_ is a PITA. If you aren't Well, see above — tdnf is python-free dnf (from which you could bootstrap to the full one). updating your kernels at runtime and are instead relying on the whole image to be respun (ala Atomic or otherwise) then you don't need grubby anyway and it doesn't matter what language it's written in. And maybe that's the best path. This really kind of baffles me. I would love to hear the reasoning behind it. I think because it's one of the biggest and most complex things in minimal. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 is out, Fedora 23 is coming :)
On Thu, Jun 4, 2015, at 12:31 PM, Josh Boyer wrote: If you don't have python, you don't have yum/dnf which means updating your kernel in your cloud image at _runtime_ is a PITA. OSTree has built in support for updating the kernel at runtime. The fact that it does so atomically in concert with the rest of userspace is an important aspect of how it works. Systems (by default) have two kernels and two userspaces which share storage; if both userspace trees reference the same kernel, the storage isn't duplicated. If you aren't updating your kernels at runtime and are instead relying on the whole image to be respun (ala Atomic or otherwise) There appears to be some confusion here - Atomic/rpm-ostree is definitely capable of incremental upgrades that install a new kernel at runtime, there's no whole image to be respun. The tree is currently composed on a build server, not on the client, and it is a fresh installroot every time, but clients only download objects which have changed. Secondly, isn't a lack of python in the cloud image going to impact their ability to be managed via things like ansible/puppet/chef/whatever? Mainly Ansible...Chef and Puppet both require agents. ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 is out, Fedora 23 is coming :)
On Thu, Jun 4, 2015 at 12:47 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Jun 04, 2015 at 12:31:15PM -0400, Josh Boyer wrote: * https://github.com/vmware/tdnf this might help us to go another step closer to remove Python stack from the cloud image.* Having a better We need to talk to Peter Jones about plans to rewrite grubby in Python. I'm very sympathetic to his wish to have it no longer be in C, but if we _really_ are moving to getting python out Er, can you elaborate on this desire to get python out? I'm kind of confused. Particularly about why grubby is such a concern. If you don't have python, you don't have yum/dnf which means updating your kernel in your cloud image at _runtime_ is a PITA. If you aren't Well, see above -- tdnf is python-free dnf (from which you could bootstrap to the full one). I remain skeptical that is a good idea. We've already had one transition from yum to dnf where things aren't quite the same. Throwing in yet-another implementation with no proven track record and no discussion with QA simply because it's smaller seems odd. updating your kernels at runtime and are instead relying on the whole image to be respun (ala Atomic or otherwise) then you don't need grubby anyway and it doesn't matter what language it's written in. And maybe that's the best path. Sure. I won't disagree that updating via rpm/dnf/yum might be better served by just shipping a whole new image in the Cloud case. Yet you cut out and failed to reply about the other aspects of this. This really kind of baffles me. I would love to hear the reasoning behind it. I think because it's one of the biggest and most complex things in minimal. But cloud isn't minimal. It's Cloud. It needs to be useful for Cloud-y things. Like management via Ansible, etc. If you're going for minimal, you guys might as well become the Base image which doesn't exist today. josh ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 is out, Fedora 23 is coming :)
On Mon, Jun 01, 2015 at 06:20:32PM +0530, Kushal Das wrote: Below I have written few points which came up in different discussions. Please feel free to comment/add/delete in this thread. * Better automation or at least SOP for release - docker hub - can we integrate this into fedimg? * Cloud providers: Azure, GCE, Digital Ocean, HP, others - push is hard for us because of legal requirements; can we make pull arragements? also, comments: * Reduce the base cloud image size (we also have https://fedorahosted.org/fedora-badges/ticket/378 ) I'm a little baffled by why it grew so much this time around; there's a few extraneous things in the package set, but not a lot new and egregious, yet it still grew. * https://github.com/vmware/tdnf this might help us to go another step closer to remove Python stack from the cloud image.* Having a better We need to talk to Peter Jones about plans to rewrite grubby in Python. I'm very sympathetic to his wish to have it no longer be in C, but if we _really_ are moving to getting python out -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [cloud] #105: Missing Cockpit RPMs in Fedora Atomic 22
#105: Missing Cockpit RPMs in Fedora Atomic 22 ---+ Reporter: jzb| Owner: Type: defect | Status: new Priority: blocker| Milestone: Fedora 22 Component: Docker Host Image | Resolution: Keywords: meeting| ---+ Comment (by scollier): In order to get cockpit to run on a F22 atomic host is two commands: docker pull fedora/cockpitws atomic run docker.io/fedora/cockpitws Then you are ready to go. -- Ticket URL: https://fedorahosted.org/cloud/ticket/105#comment:9 cloud https://fedorahosted.org/cloud Fedora Cloud Working Group Ticketing System ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [cloud] #105: Missing Cockpit RPMs in Fedora Atomic 22
#105: Missing Cockpit RPMs in Fedora Atomic 22 ---+ Reporter: jzb| Owner: Type: defect | Status: new Priority: blocker| Milestone: Fedora 22 Component: Docker Host Image | Resolution: Keywords: meeting| ---+ Comment (by walters): The thing, the whole point of this effort is to containerize. Anyone who wants the traditional one set of packages model has plenty of other options *within Fedora*, such as Fedora Server and Fedora Cloud Base. There's also the aspect that even if we add cockpit into the tree in an update, anyone who does an initial install won't get it, so there will still be issues with that. Finally, while Fedora 21 shipped with it enabled by default, I'm a bit hesistant to ship a new service that listens on the network by default in an update to Fedora 22. It's very reasonable for organizations to evaluate a gold OS configuration, perform some customization including turning on/off services, setting up firewalling etc. These types of deployments would be unhappy to have new services appear. (It's actually not completely easy to simply blacklist all services, because it's reasonable for e.g. nfs-utils to include a new internal service, and if you then disable it by default, you wouldn't want to break NFS. This is more about services which listen on the network) -- Ticket URL: https://fedorahosted.org/cloud/ticket/105#comment:10 cloud https://fedorahosted.org/cloud Fedora Cloud Working Group Ticketing System ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [cloud] #105: Missing Cockpit RPMs in Fedora Atomic 22
#105: Missing Cockpit RPMs in Fedora Atomic 22 ---+ Reporter: jzb| Owner: Type: defect | Status: new Priority: blocker| Milestone: Fedora 22 Component: Docker Host Image | Resolution: Keywords: meeting| ---+ Comment (by ausil): Replying to [comment:6 mattdm]: +1 to focusing on moving forward. I have great confidence that everyone here wants to do the right thing; there's just a lot up in the air all at once. I'm told that [https://fedoraproject.org/wiki/User:Ttomecek Tomas Tomecek] is working on something w.r.t. layered image building. Dennis, is that what you're referring to, or something else? If we land this for F23 (ideally, as I know you like to do, before alpha), can we also turn it on for F22? That is what I am talking about, we can look at turning it on for f22 updates also. It is still a way off, so I am not sure when we will be able to do it. -- Ticket URL: https://fedorahosted.org/cloud/ticket/105#comment:11 cloud https://fedorahosted.org/cloud Fedora Cloud Working Group Ticketing System ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
