Re: Fedora 22 is out, Fedora 23 is coming :)
On Thu, Jul 9, 2015 at 10:35 PM, Dusty Mabe du...@dustymabe.com wrote: On Tue, Jun 16, 2015 at 09:31:27AM -0400, Dusty Mabe wrote: On Mon, Jun 15, 2015 at 01:10:58PM -0400, Josh Boyer wrote: On Mon, Jun 15, 2015 at 12:18 PM, Matthew Miller H -- what about making linux-firmware a Requires(Pre) for kernel-modules instead of kernel-core? Can't, because not all of the modules are in modules, and some of them in core need firmware. Naive little me might have an idea. This may not be technically possible for some reason so forgive me if my suggestion has on oversight. We currently have the kernel meta package with these requires: [root@localhost ~]# repoquery -q --requires --output ascii-tree kernel --level 2 Yum-utils package has been deprecated, use dnf instead. See 'man yum2dnf' for more information. kernel-0:4.0.6-300.fc22.x86_64 [cmd line] \_ kernel-core-0:4.0.6-300.fc22.x86_64 [1: kernel-core-uname-r = 4.0.6-300.fc22.x86_64] | \_ bash-0:4.3.39-3.fc22.x86_64 [1: /bin/sh] | \_ coreutils-0:8.23-10.fc22.x86_64 [1: fileutils] | \_ dracut-0:041-14.fc22.x86_64 [1: dracut = 027] | \_ linux-firmware-0:20150521-52.git3161bfa4.fc22.noarch [1: linux-firmware = 20130724-29.git31f6b30] | \_ systemd-0:219-13.fc22.i686 [2: systemd = 200, systemd = 203-2] | \_ systemd-0:219-18.fc22.x86_64 [2: systemd = 200, systemd = 203-2] \_ kernel-modules-0:4.0.6-300.fc22.x86_64 [1: kernel-modules-uname-r = 4.0.6-300.fc22.x86_64] | \_ bash-0:4.3.39-3.fc22.x86_64 [1: /bin/sh] | \_ kernel-core-0:4.0.6-300.fc22.x86_64 [1: kernel-uname-r = 4.0.6-300.fc22.x86_64] Could we break out the modules that live in kernel-core into a new package called kernel-core-modules. The toplevel kernel meta package would require it as well so we would have something like this: kernel \_ kernel-core | \_ bash | \_ coreutils | \_ dracut | \_ systemd-0:XX.fc22.i686 | \_ systemd-0:XX.fc22.x86_64 \_ kernel-core-modules | \_ linux-firmware \_ kernel-modules | \_ bash | \_ kernel-core | \_ kernel-core-modules In this case kernel-core could be installed without any modules and thus not needing linux-firmware. Does this make sense? Is it more complicated than that? I don't know. This is a No, it doesn't really make sense. Yes, it's more complicated. Why would you want to create yet another subpackage for modules instead of just moving them into kernel-modules? genuinely innocent attempt at trying to propose a solution that might be an alternative. Filtering modules to different subpacakges based on whether or not they need firmware is pretty time consuming for really little gain. You have to detect if they need firmware, move them, make sure depmod on kernel-core isn't broken, etc. The steps we use now are based on kernel subsystem and for the most part work relatively well. Making that even more complicated just to move firmware-requiring modules would mean it is more fragile and error prone. Why don't you just add a Provides: linux-firmware to fedora-release-cloud if this must be done on a packaging level? 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 Fri, Jul 10, 2015 at 10:16:49AM -0400, Josh Boyer wrote: On Fri, Jul 10, 2015 at 9:58 AM, Dusty Mabe du...@dustymabe.com wrote: On Fri, Jul 10, 2015 at 07:44:25AM -0400, Josh Boyer wrote: On Thu, Jul 9, 2015 at 10:35 PM, Dusty Mabe du...@dustymabe.com wrote: On Tue, Jun 16, 2015 at 09:31:27AM -0400, Dusty Mabe wrote: On Mon, Jun 15, 2015 at 01:10:58PM -0400, Josh Boyer wrote: In this case kernel-core could be installed without any modules and thus not needing linux-firmware. Does this make sense? Is it more complicated than that? I don't know. This is a No, it doesn't really make sense. Yes, it's more complicated. Why would you want to create yet another subpackage for modules instead of just moving them into kernel-modules? I guess I didn't know moving them into kernel-modules was an option. I thought they were left in kernel-core (and thus separate from kernel-modules) for a reason. Sort of. The kernel-core package is kernel-core, not kernel-cloud. It's useful for things outside of just the cloud image. genuinely innocent attempt at trying to propose a solution that might be an alternative. Filtering modules to different subpacakges based on whether or not they need firmware is pretty time consuming for really little gain. You have to detect if they need firmware, move them, make sure depmod on kernel-core isn't broken, etc. The steps we use now are based on kernel subsystem and for the most part work relatively well. Making that even more complicated just to move firmware-requiring modules would mean it is more fragile and error prone. The proposal I laid out doesn't really require evaluating each of them. It was simply to move the ones that are currently in kernel-core into kernel-core-modules. Yes it would be more complicated simply because there is another package. Maybe this would be more fragile and error prone. If this isn't done programmatically then it will break the next time a module in kernel-core adds firmware requirements. In other words, just moving the existing modules but not future proofing it by checking for that requirement is a half-assed solution that will lead to breakage. I don't like breakage. I think I understand better now. Yes, I agree that it would need to be programmatic and reliable. Would be great if there was a way to detect modules that have firmware requirements, but I think you mentioned earlier that it's not. Why don't you just add a Provides: linux-firmware to fedora-release-cloud if this must be done on a packaging level? There are a lot of ways to do it. We could blank or remove the files after install. We could add a provides to fedora-release-cloud, etc. These are all pretty easy to do and will probably be what we have to do. The only reason I don't like these solutions is because a user could decide that they do need modules and firmware (these can easily be installed on bringup) and then they have to work with a botched system to figure out what they need to do to get them. Why is a user installing the cloud image on real hardware for bringup? This might be a result of me being naive about when firmware is really needed or not. If it is safe to say that it is only ever needed for bringup on bare metal then I think doing the provides in fedora-release-cloud would be the right thing to do. Thanks again for being patient, Dusty ___ 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 Fri, Jul 10, 2015 at 07:44:25AM -0400, Josh Boyer wrote: On Thu, Jul 9, 2015 at 10:35 PM, Dusty Mabe du...@dustymabe.com wrote: On Tue, Jun 16, 2015 at 09:31:27AM -0400, Dusty Mabe wrote: On Mon, Jun 15, 2015 at 01:10:58PM -0400, Josh Boyer wrote: In this case kernel-core could be installed without any modules and thus not needing linux-firmware. Does this make sense? Is it more complicated than that? I don't know. This is a No, it doesn't really make sense. Yes, it's more complicated. Why would you want to create yet another subpackage for modules instead of just moving them into kernel-modules? I guess I didn't know moving them into kernel-modules was an option. I thought they were left in kernel-core (and thus separate from kernel-modules) for a reason. genuinely innocent attempt at trying to propose a solution that might be an alternative. Filtering modules to different subpacakges based on whether or not they need firmware is pretty time consuming for really little gain. You have to detect if they need firmware, move them, make sure depmod on kernel-core isn't broken, etc. The steps we use now are based on kernel subsystem and for the most part work relatively well. Making that even more complicated just to move firmware-requiring modules would mean it is more fragile and error prone. The proposal I laid out doesn't really require evaluating each of them. It was simply to move the ones that are currently in kernel-core into kernel-core-modules. Yes it would be more complicated simply because there is another package. Maybe this would be more fragile and error prone. Why don't you just add a Provides: linux-firmware to fedora-release-cloud if this must be done on a packaging level? There are a lot of ways to do it. We could blank or remove the files after install. We could add a provides to fedora-release-cloud, etc. These are all pretty easy to do and will probably be what we have to do. The only reason I don't like these solutions is because a user could decide that they do need modules and firmware (these can easily be installed on bringup) and then they have to work with a botched system to figure out what they need to do to get them. Thanks for the kind response and going easy on me as I'm not too familiar with our kernel packaging requirements. Dusty ___ 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 Fri, Jul 10, 2015 at 9:58 AM, Dusty Mabe du...@dustymabe.com wrote: On Fri, Jul 10, 2015 at 07:44:25AM -0400, Josh Boyer wrote: On Thu, Jul 9, 2015 at 10:35 PM, Dusty Mabe du...@dustymabe.com wrote: On Tue, Jun 16, 2015 at 09:31:27AM -0400, Dusty Mabe wrote: On Mon, Jun 15, 2015 at 01:10:58PM -0400, Josh Boyer wrote: In this case kernel-core could be installed without any modules and thus not needing linux-firmware. Does this make sense? Is it more complicated than that? I don't know. This is a No, it doesn't really make sense. Yes, it's more complicated. Why would you want to create yet another subpackage for modules instead of just moving them into kernel-modules? I guess I didn't know moving them into kernel-modules was an option. I thought they were left in kernel-core (and thus separate from kernel-modules) for a reason. Sort of. The kernel-core package is kernel-core, not kernel-cloud. It's useful for things outside of just the cloud image. genuinely innocent attempt at trying to propose a solution that might be an alternative. Filtering modules to different subpacakges based on whether or not they need firmware is pretty time consuming for really little gain. You have to detect if they need firmware, move them, make sure depmod on kernel-core isn't broken, etc. The steps we use now are based on kernel subsystem and for the most part work relatively well. Making that even more complicated just to move firmware-requiring modules would mean it is more fragile and error prone. The proposal I laid out doesn't really require evaluating each of them. It was simply to move the ones that are currently in kernel-core into kernel-core-modules. Yes it would be more complicated simply because there is another package. Maybe this would be more fragile and error prone. If this isn't done programmatically then it will break the next time a module in kernel-core adds firmware requirements. In other words, just moving the existing modules but not future proofing it by checking for that requirement is a half-assed solution that will lead to breakage. I don't like breakage. Why don't you just add a Provides: linux-firmware to fedora-release-cloud if this must be done on a packaging level? There are a lot of ways to do it. We could blank or remove the files after install. We could add a provides to fedora-release-cloud, etc. These are all pretty easy to do and will probably be what we have to do. The only reason I don't like these solutions is because a user could decide that they do need modules and firmware (these can easily be installed on bringup) and then they have to work with a botched system to figure out what they need to do to get them. Why is a user installing the cloud image on real hardware for bringup? I mean, that problem exists regardless of how not including firmware in the cloud image is done. If they use an image that lacks firmware on a machine that needs firmware, it won't work. It doesn't matter what technical solution is used to accomplish the goal of removing the firmware from the image. I understand the concern, but I don't think trying to code around people doing intentionally weird things is a great idea. 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 Tue, Jun 16, 2015 at 09:31:27AM -0400, Dusty Mabe wrote: On Mon, Jun 15, 2015 at 01:10:58PM -0400, Josh Boyer wrote: On Mon, Jun 15, 2015 at 12:18 PM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Jun 12, 2015 at 08:06:04AM -0400, Josh Boyer wrote: Well, and linux-firmware, which isn't needed at runtime but is pulled in for kernel upgrades, and which to my knowledge is not needed in any cloud environments. You might be the right person to talk to about figuring out if we can do anything about this. A post install scriptlet that removes the files in the cloud kickstarts is about as far as I'm going to go. I'm not dropping the Requires from the kernel-core package and leave everyone else in the lurch. Another option would be a dummy package that Provides linux-firmware, but that also runs the risk of non-cloud instances getting it installed since we don't have separate repos. It's unfortunate that the dependencies can't be expressed in a richer way here. It's not that the kernel requires that package... the hardware does. Even if we remove it in the cloud kickstarts, it gets pulled back in on update, because it's a Requires(pre). Create a dnf plugin to ignore it. Will this handle the rpm db correctly? Meaning after the install will rpm still think there is a missing dependency? If this happens I think you get a warning anytime you use yum/dnf. (The third option is a separate cloud kernel package but that would make the rework we did in f22 pointless and wasted and we've already had that discussion.) H -- what about making linux-firmware a Requires(Pre) for kernel-modules instead of kernel-core? Can't, because not all of the modules are in modules, and some of them in core need firmware. Naive little me might have an idea. This may not be technically possible for some reason so forgive me if my suggestion has on oversight. We currently have the kernel meta package with these requires: [root@localhost ~]# repoquery -q --requires --output ascii-tree kernel --level 2 Yum-utils package has been deprecated, use dnf instead. See 'man yum2dnf' for more information. kernel-0:4.0.6-300.fc22.x86_64 [cmd line] \_ kernel-core-0:4.0.6-300.fc22.x86_64 [1: kernel-core-uname-r = 4.0.6-300.fc22.x86_64] | \_ bash-0:4.3.39-3.fc22.x86_64 [1: /bin/sh] | \_ coreutils-0:8.23-10.fc22.x86_64 [1: fileutils] | \_ dracut-0:041-14.fc22.x86_64 [1: dracut = 027] | \_ linux-firmware-0:20150521-52.git3161bfa4.fc22.noarch [1: linux-firmware = 20130724-29.git31f6b30] | \_ systemd-0:219-13.fc22.i686 [2: systemd = 200, systemd = 203-2] | \_ systemd-0:219-18.fc22.x86_64 [2: systemd = 200, systemd = 203-2] \_ kernel-modules-0:4.0.6-300.fc22.x86_64 [1: kernel-modules-uname-r = 4.0.6-300.fc22.x86_64] | \_ bash-0:4.3.39-3.fc22.x86_64 [1: /bin/sh] | \_ kernel-core-0:4.0.6-300.fc22.x86_64 [1: kernel-uname-r = 4.0.6-300.fc22.x86_64] Could we break out the modules that live in kernel-core into a new package called kernel-core-modules. The toplevel kernel meta package would require it as well so we would have something like this: kernel \_ kernel-core | \_ bash | \_ coreutils | \_ dracut | \_ systemd-0:XX.fc22.i686 | \_ systemd-0:XX.fc22.x86_64 \_ kernel-core-modules | \_ linux-firmware \_ kernel-modules | \_ bash | \_ kernel-core | \_ kernel-core-modules In this case kernel-core could be installed without any modules and thus not needing linux-firmware. Does this make sense? Is it more complicated than that? I don't know. This is a genuinely innocent attempt at trying to propose a solution that might be an alternative. Sorry to open this back up.. Please be gentle :) - Dusty ___ 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 15, 2015 at 01:10:58PM -0400, Josh Boyer wrote: On Mon, Jun 15, 2015 at 12:18 PM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Jun 12, 2015 at 08:06:04AM -0400, Josh Boyer wrote: Well, and linux-firmware, which isn't needed at runtime but is pulled in for kernel upgrades, and which to my knowledge is not needed in any cloud environments. You might be the right person to talk to about figuring out if we can do anything about this. A post install scriptlet that removes the files in the cloud kickstarts is about as far as I'm going to go. I'm not dropping the Requires from the kernel-core package and leave everyone else in the lurch. Another option would be a dummy package that Provides linux-firmware, but that also runs the risk of non-cloud instances getting it installed since we don't have separate repos. It's unfortunate that the dependencies can't be expressed in a richer way here. It's not that the kernel requires that package... the hardware does. Even if we remove it in the cloud kickstarts, it gets pulled back in on update, because it's a Requires(pre). Create a dnf plugin to ignore it. Will this handle the rpm db correctly? Meaning after the install will rpm still think there is a missing dependency? If this happens I think you get a warning anytime you use yum/dnf. (The third option is a separate cloud kernel package but that would make the rework we did in f22 pointless and wasted and we've already had that discussion.) H -- what about making linux-firmware a Requires(Pre) for kernel-modules instead of kernel-core? Can't, because not all of the modules are in modules, and some of them in core need firmware. 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 16/06/15, Matthew Miller wrote: On Tue, Jun 16, 2015 at 09:31:27AM -0400, Dusty Mabe wrote: It's unfortunate that the dependencies can't be expressed in a richer way here. It's not that the kernel requires that package... the hardware does. Even if we remove it in the cloud kickstarts, it gets pulled back in on update, because it's a Requires(pre). Create a dnf plugin to ignore it. Will this handle the rpm db correctly? Meaning after the install will rpm still think there is a missing dependency? If this happens I think you get a warning anytime you use yum/dnf. In this case, since it's only a Requires(pre), RPM doesn't mind. I was talking with the dnf developers today. They said there is no direct way to achieve this. But we can create a plugin which will remove it (if it exits) after any transaction. Another option is to try to put the package in the exclude list for the transaction. I will try for this method first. Kushal -- Fedora Cloud Engineer CPython Core Developer CentOS Cloud SIG lead http://kushaldas.in ___ 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 Tue, Jun 16, 2015 at 09:00:32PM +0530, Kushal Das wrote: Create a dnf plugin to ignore it. I was talking with the dnf developers today. They said there is no direct way to achieve this. But we can create a plugin which will remove it (if it exits) after any transaction. It'd be nice to avoid the network traffic. I'm assuming here that the kernel update itself will act gracefully if the package isn't there. That's not actually a tested assumption. :) -- 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 Fri, Jun 12, 2015 at 08:06:04AM -0400, Josh Boyer wrote: Well, and linux-firmware, which isn't needed at runtime but is pulled in for kernel upgrades, and which to my knowledge is not needed in any cloud environments. You might be the right person to talk to about figuring out if we can do anything about this. A post install scriptlet that removes the files in the cloud kickstarts is about as far as I'm going to go. I'm not dropping the Requires from the kernel-core package and leave everyone else in the lurch. Another option would be a dummy package that Provides linux-firmware, but that also runs the risk of non-cloud instances getting it installed since we don't have separate repos. It's unfortunate that the dependencies can't be expressed in a richer way here. It's not that the kernel requires that package... the hardware does. Even if we remove it in the cloud kickstarts, it gets pulled back in on update, because it's a Requires(pre). Even if the package left that out, and we relied on something else to make sure it's in place on real hardware (e.g. anaconda pulls it in, or even just have it a base group in comps), I'm not sure how to tell RPM to order it properly during initial install otherwise. (Short of special-casing in anaconda, which, ugh.) (The third option is a separate cloud kernel package but that would make the rework we did in f22 pointless and wasted and we've already had that discussion.) H -- what about making linux-firmware a Requires(Pre) for kernel-modules instead of kernel-core? -- 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 Mon, Jun 15, 2015 at 12:18 PM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Jun 12, 2015 at 08:06:04AM -0400, Josh Boyer wrote: Well, and linux-firmware, which isn't needed at runtime but is pulled in for kernel upgrades, and which to my knowledge is not needed in any cloud environments. You might be the right person to talk to about figuring out if we can do anything about this. A post install scriptlet that removes the files in the cloud kickstarts is about as far as I'm going to go. I'm not dropping the Requires from the kernel-core package and leave everyone else in the lurch. Another option would be a dummy package that Provides linux-firmware, but that also runs the risk of non-cloud instances getting it installed since we don't have separate repos. It's unfortunate that the dependencies can't be expressed in a richer way here. It's not that the kernel requires that package... the hardware does. Even if we remove it in the cloud kickstarts, it gets pulled back in on update, because it's a Requires(pre). Create a dnf plugin to ignore it. (The third option is a separate cloud kernel package but that would make the rework we did in f22 pointless and wasted and we've already had that discussion.) H -- what about making linux-firmware a Requires(Pre) for kernel-modules instead of kernel-core? Can't, because not all of the modules are in modules, and some of them in core need firmware. 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 11, 2015 at 1:12 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Jun 11, 2015 at 12:53:42PM -0400, Josh Boyer wrote: You can get around this with on-the-fly image generation as I previously mentioned, or by creating a small (and I mean small in number not size) set of images that are flexible enough to hit the major categories while not being strictly tied 1:1 to a particular technology. E.g. you have a Cloud Container image that can be used for Docker, rkt, or systemd-nspawn. Yes, that makes it potentially larger in size but it also means you have less to QA, market, and carry. The bitnami link I sent before was probably a bit broad; our previous dicussions were more around something like this: https://bitnami.com/stacks/infrastructure -- which I think matches what you are saying. And I *do* think it'd be nice to have an app store built on top of that. First, though, the Cloud Base image, which is intended to underly all of that (and also be, as we have said, a generic platform to build up anything). Size _does_ matter, though, because it translates directly into network transfer and deploy time. Python is in the crosshairs because it's relatively large. In fact, with your kernel-core stuff and the glibc documentation split, it's the biggest thing (coming in just above systemd). I didn't say size doesn't matter. I'm saying I don't believe cutting python just because it is big is the right choice. We're probably going to have to disagree on this point. Well, and linux-firmware, which isn't needed at runtime but is pulled in for kernel upgrades, and which to my knowledge is not needed in any cloud environments. You might be the right person to talk to about figuring out if we can do anything about this. A post install scriptlet that removes the files in the cloud kickstarts is about as far as I'm going to go. I'm not dropping the Requires from the kernel-core package and leave everyone else in the lurch. Another option would be a dummy package that Provides linux-firmware, but that also runs the risk of non-cloud instances getting it installed since we don't have separate repos. (The third option is a separate cloud kernel package but that would make the rework we did in f22 pointless and wasted and we've already had that discussion.) 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 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. For a practical example: Ansible doesn't currently support Python 3. If we change the cloud image to python3 — as is the expected plan, right? — having that system python there doesn't provide any benefit. It's just extra weight. The early PRD called for a library of different images for different purposes, in addition to the base, and I think we're still interested in that — it's just not ready yet. That might include various ansible-ready or puppet-ready images, possibly with other tools installed as fits the use case. -- 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 11, 2015 at 10:01 AM, Matthew Miller mat...@fedoraproject.org wrote: 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. For a practical example: Ansible doesn't currently support Python 3. If we change the cloud image to python3 — as is the expected plan, right? Remains to be seen. I'm skeptical the distro-wide default will switch tbh. — having that system python there doesn't provide any benefit. It's just extra weight. Um, ok. It's extra weight for people that don't use python. In this case, what would be the solution to getting python on your cloud image? Would you do it via SCL or via some kind of container overlay or? The early PRD called for a library of different images for different purposes, in addition to the base, and I think we're still interested in that — it's just not ready yet. That might include various ansible-ready or puppet-ready images, possibly with other tools installed as fits the use case. That sounds like it will have all the problems we currently face with Spins. Too many choices, too much burden to produce, too little overall benefit for deviation, too niche, too much churn from release to release and new tech of the day. Why would we choose to repeat those same mistakes? While I have no vested interest in Cloud, I'd rather see an image that is flexible with utilities for people to customize and build on top of even if that means it isn't the tiniest, thinnest image out there. 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 11, 2015 at 03:37:00PM -0400, Matt Micene wrote: Is where we're at loggerheads. While cloud environments are operationally different than bare-metal, it's not useful to most cloud admins to have to track down and automate huge amounts of packages to get to a working Ruby on Rails server, and having a major usability difference between Server and Cloud in that context is going to harm adoption. I'm not clear on the track down and automate comment here. That's going to be the same on Cloud _or_ Server — `nf groupinstall rubyonrails` To possibly commit a faux pas and talk about RHEL (as a consumer, I'm not a red hatter), RHEL 6 Base on bare metal and RHEL 6 Base in AWS are functionally equivalent. Someone on the inside who knows exactly what the builds contain can probably pick nits but the differences are mostly invisible, aside from repo locations. That's what I think the Cloud SIG needs to deliver for Fedora Cloud Base. That RHEL image doesn't ship with rails installed either, though, does it? Spinning up a image *inside* an IaaS environment (from Heat or EC2 console) slightly faster isn't an advantage if I then lose more time installing packages over the network, creating a new image to then start using as my baseline. Agreed — that's where the idea of having a dozen or so images preconfigured with popular runtimes makes sense. But an image with _all_ the runtimes doesn't. -- 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 11, 2015 at 04:48:37PM -0400, Matthew Miller wrote: Agreed — that's where the idea of having a dozen or so images preconfigured with popular runtimes makes sense. But an image with _all_ the runtimes doesn't. And that said: if we _do_ decide to make Fedora Atomic the primary focus, those runtimes would be docker images, with the runtimes as layers (see https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service) on the docker base. (Although for provisioning speed, we _could_ even then consider shipping various images with those images preloaded.) -- 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 :)
That RHEL image doesn't ship with rails installed either, though, does it? Ok ROR was probably a bad example since it's not a standard package anywhere. But what I was trying to get across with track down and automate is the build and fix dance it takes to build a Docker image right now, where a package used by a runtime isn't an RPM dependency. Where in Server, an admin isn't going to have to add tar and procps to dnf install rubyonrails. Again, probably not the best specific examples. But having to install python is probably not the experience a Fedora user would expect. And that said: if we _do_ decide to make Fedora Atomic the primary focus, those runtimes would be docker images, with the runtimes as layers Runtimes as containers would probably be a nifty thing regardless of Atomic's status. I can see that as a pretty attractive use case for new Fedora users if they can pull a containerized stack and start poking around. - Matt M On Thu, Jun 11, 2015 at 4:48 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Jun 11, 2015 at 03:37:00PM -0400, Matt Micene wrote: Is where we're at loggerheads. While cloud environments are operationally different than bare-metal, it's not useful to most cloud admins to have to track down and automate huge amounts of packages to get to a working Ruby on Rails server, and having a major usability difference between Server and Cloud in that context is going to harm adoption. I'm not clear on the track down and automate comment here. That's going to be the same on Cloud _or_ Server — `nf groupinstall rubyonrails` To possibly commit a faux pas and talk about RHEL (as a consumer, I'm not a red hatter), RHEL 6 Base on bare metal and RHEL 6 Base in AWS are functionally equivalent. Someone on the inside who knows exactly what the builds contain can probably pick nits but the differences are mostly invisible, aside from repo locations. That's what I think the Cloud SIG needs to deliver for Fedora Cloud Base. That RHEL image doesn't ship with rails installed either, though, does it? Spinning up a image *inside* an IaaS environment (from Heat or EC2 console) slightly faster isn't an advantage if I then lose more time installing packages over the network, creating a new image to then start using as my baseline. Agreed — that's where the idea of having a dozen or so images preconfigured with popular runtimes makes sense. But an image with _all_ the runtimes doesn't. -- 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 :)
On Thu, Jun 11, 2015 at 10:47:00AM -0400, Josh Boyer wrote: For a practical example: Ansible doesn't currently support Python 3. If we change the cloud image to python3 — as is the expected plan, right? Remains to be seen. I'm skeptical the distro-wide default will switch tbh. Good to know. — having that system python there doesn't provide any benefit. It's just extra weight. Um, ok. It's extra weight for people that don't use python. In this It's extra weight for people who don't use _that_ python. case, what would be the solution to getting python on your cloud image? Would you do it via SCL or via some kind of container overlay or? Yes. Or just `dnf install` if the version is right. Just like you would with ruby or whatever else. The early PRD called for a library of different images for different purposes, in addition to the base, and I think we're still interested in that — it's just not ready yet. That might include various ansible-ready or puppet-ready images, possibly with other tools installed as fits the use case. That sounds like it will have all the problems we currently face with Spins. Too many choices, too much burden to produce, too little overall benefit for deviation, too niche, too much churn from release to release and new tech of the day. Why would we choose to repeat those same mistakes? I think that's why it hasn't been done yet. The plan would be for them to be largely auto-generated and auto-tested, unlike spins (which, as largely desktop/GUI focused outputs, are hard to test automatically). While I have no vested interest in Cloud, I'd rather see an image that is flexible with utilities for people to customize and build on top of even if that means it isn't the tiniest, thinnest image out there. Oh, it won't be. The tiniest, thinnest images are in the 10MB range. -- 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 11, 2015 at 11:18 AM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Jun 11, 2015 at 10:47:00AM -0400, Josh Boyer wrote: For a practical example: Ansible doesn't currently support Python 3. If we change the cloud image to python3 — as is the expected plan, right? Remains to be seen. I'm skeptical the distro-wide default will switch tbh. Good to know. — having that system python there doesn't provide any benefit. It's just extra weight. Um, ok. It's extra weight for people that don't use python. In this It's extra weight for people who don't use _that_ python. case, what would be the solution to getting python on your cloud image? Would you do it via SCL or via some kind of container overlay or? Yes. Or just `dnf install` if the version is right. Just like you would with ruby or whatever else. dnf requires python (unless you use that C version you pointed out, which I had other objections to). Circles anyone? The early PRD called for a library of different images for different purposes, in addition to the base, and I think we're still interested in that — it's just not ready yet. That might include various ansible-ready or puppet-ready images, possibly with other tools installed as fits the use case. That sounds like it will have all the problems we currently face with Spins. Too many choices, too much burden to produce, too little overall benefit for deviation, too niche, too much churn from release to release and new tech of the day. Why would we choose to repeat those same mistakes? I think that's why it hasn't been done yet. The plan would be for them to be largely auto-generated and auto-tested, unlike spins (which, as largely desktop/GUI focused outputs, are hard to test automatically). That helps with image creation. It doesn't help with scale, too much choice, and churn. Just because something is possible technically, doesn't mean it is a good idea. 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 11, 2015 at 11:22:37AM -0400, Josh Boyer wrote: Yes. Or just `dnf install` if the version is right. Just like you would with ruby or whatever else. dnf requires python (unless you use that C version you pointed out, which I had other objections to). Circles anyone? Circles indeed -- that was the start of this thread, wasn't it. I think that's why it hasn't been done yet. The plan would be for them to be largely auto-generated and auto-tested, unlike spins (which, as largely desktop/GUI focused outputs, are hard to test automatically). That helps with image creation. It doesn't help with scale, too much choice, and churn. Just because something is possible technically, doesn't mean it is a good idea. Not sure what you mean by scale then. I also don't think too much choice is a problem here. See for example the success of https://bitnami.com/stacks, which is a similar idea. And churn -- well, we have other initiatives aimed at modulating that. -- 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 11, 2015 at 11:44 AM, Matthew Miller mat...@fedoraproject.org wrote: I think that's why it hasn't been done yet. The plan would be for them to be largely auto-generated and auto-tested, unlike spins (which, as largely desktop/GUI focused outputs, are hard to test automatically). That helps with image creation. It doesn't help with scale, too much choice, and churn. Just because something is possible technically, doesn't mean it is a good idea. Not sure what you mean by scale then. I also don't think too much choice is a problem here. See for example the success of https://bitnami.com/stacks, which is a similar idea. And churn -- That is an app store. You want the cloud image(s) to be app/stack oriented? How is that not going to run into literally the same problem you describe with having python installed? What if someone wants version XYZ of drupal instead of what is in Fedora? Why wouldn't you instead focus on the base cloud image, and then if you want the app store model have a backend service that generated a app/stack image on the fly for someone to download. That seems a lot more flexible than generating 30 images that people might be interested in but probably only 6 will ever be used, etc. Then you'd already have tooling other people could use to create their own cloud images that aren't in the app store. well, we have other initiatives aimed at modulating that. Such as? 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 11, 2015 at 12:01:29PM -0400, Josh Boyer wrote: That is an app store. You want the cloud image(s) to be app/stack oriented? How is that not going to run into literally the same problem you describe with having python installed? What if someone wants version XYZ of drupal instead of what is in Fedora? Then Fedora isn't catering to that need very well? Why wouldn't you instead focus on the base cloud image, and then if you want the app store model have a backend service that generated a app/stack image on the fly for someone to download. That seems a Sure -- that's one of the approaches we've discussed. well, we have other initiatives aimed at modulating that. Such as? Such as the modularization effort we just approved in the council? -- 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 11, 2015 at 12:20 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Jun 11, 2015 at 12:01:29PM -0400, Josh Boyer wrote: That is an app store. You want the cloud image(s) to be app/stack oriented? How is that not going to run into literally the same problem you describe with having python installed? What if someone wants version XYZ of drupal instead of what is in Fedora? Then Fedora isn't catering to that need very well? .. Why wouldn't you instead focus on the base cloud image, and then if you want the app store model have a backend service that generated a app/stack image on the fly for someone to download. That seems a Sure -- that's one of the approaches we've discussed. well, we have other initiatives aimed at modulating that. Such as? Such as the modularization effort we just approved in the council? I don't see how that is going to help with you need to use Docker. No wait, rocket. No, I mean this other thing. Wait, containers? Those are terrible. Use xzy. in a model where you're spitting out images per technology. Modularization _enables_ you to spit out those images at a lower cost, but it doesn't help with churn at all. 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 11, 2015 at 12:40 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Jun 11, 2015 at 12:31:10PM -0400, Josh Boyer wrote: I don't see how that is going to help with you need to use Docker. No wait, rocket. No, I mean this other thing. Wait, containers? Those are terrible. Use xzy. in a model where you're spitting out images per technology. Modularization _enables_ you to spit out those images at a lower cost, but it doesn't help with churn at all. Maybe you can define the problem you are calling churn? I understood you to mean something like django version changing too quickly in Fedora. But it sounds like you mean cloud computing world overall changing really fast? s/cloud//, but yes. For example, if the idea is to ship a cloud image per technology then after one release you're going to have a bunch of images that nobody cares about. That means we carry those images on the mirrors until EOL and they're wasted. It also means that when the image isn't generated for the next release (or maybe the release after), you lack consistency around both what Fedora Cloud is providing and what you can market it as. You aren't helping people navigate this problem at all, you're just feeding into it. You can get around this with on-the-fly image generation as I previously mentioned, or by creating a small (and I mean small in number not size) set of images that are flexible enough to hit the major categories while not being strictly tied 1:1 to a particular technology. E.g. you have a Cloud Container image that can be used for Docker, rkt, or systemd-nspawn. Yes, that makes it potentially larger in size but it also means you have less to QA, market, and carry. 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 11, 2015 at 12:53:42PM -0400, Josh Boyer wrote: You can get around this with on-the-fly image generation as I previously mentioned, or by creating a small (and I mean small in number not size) set of images that are flexible enough to hit the major categories while not being strictly tied 1:1 to a particular technology. E.g. you have a Cloud Container image that can be used for Docker, rkt, or systemd-nspawn. Yes, that makes it potentially larger in size but it also means you have less to QA, market, and carry. The bitnami link I sent before was probably a bit broad; our previous dicussions were more around something like this: https://bitnami.com/stacks/infrastructure -- which I think matches what you are saying. And I *do* think it'd be nice to have an app store built on top of that. First, though, the Cloud Base image, which is intended to underly all of that (and also be, as we have said, a generic platform to build up anything). Size _does_ matter, though, because it translates directly into network transfer and deploy time. Python is in the crosshairs because it's relatively large. In fact, with your kernel-core stuff and the glibc documentation split, it's the biggest thing (coming in just above systemd). Well, and linux-firmware, which isn't needed at runtime but is pulled in for kernel upgrades, and which to my knowledge is not needed in any cloud environments. You might be the right person to talk to about figuring out if we can do anything about this. -- 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 11, 2015 at 7:47 AM, Josh Boyer jwbo...@fedoraproject.org wrote: That sounds like it will have all the problems we currently face with Spins. Too many choices, too much burden to produce, too little overall benefit for deviation, too niche, too much churn from release to release and new tech of the day. Why would we choose to repeat those same mistakes? While I have no vested interest in Cloud, I'd rather see an image that is flexible with utilities for people to customize and build on top of even if that means it isn't the tiniest, thinnest image out there. josh Indeed. Too many choices == nobody will use any of them, they'll go somewhere else. I'm probably repeating myself but here's my proposal: 1. Workstation is a winner. Keep it. 2. Replace the spins - yes, *all* of them - with a Netinstall disk that has selectable kickstart files for installing them. It's close to that now anyway. 3. I see no need for a separate cloud hosting install medium that's any different from Server. A cloud host *is* a server. 4. Docker base image: keep it, but recognize that there's a *huge* effort involved in getting users. Ubuntu and CentOS have the lion's share and the bobcat's share respectively. Debian has a kitten's share mostly because Docker recommends it. I'm using Fedora, but I'd switch to CentOS if all the texlive packages I need were in the EPEL repositories. ___ 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 11, 2015 at 11:05:25AM -0700, M. Edward (Ed) Borasky wrote: 3. I see no need for a separate cloud hosting install medium that's any different from Server. A cloud host *is* a server. I know we've had this conversation before. Fedora Server is, largely, addressing the more traditional server model, where each machine serves a unique purposes and is carefully maintained. Fedora Cloud is addressing the emerging cloud computing world, and provides a base for deploying scale-out applications. -- 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 11, 2015 at 11:30 AM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Jun 11, 2015 at 11:05:25AM -0700, M. Edward (Ed) Borasky wrote: 3. I see no need for a separate cloud hosting install medium that's any different from Server. A cloud host *is* a server. I know we've had this conversation before. Fedora Server is, largely, addressing the more traditional server model, where each machine serves a unique purposes and is carefully maintained. Fedora Cloud is addressing the emerging cloud computing world, and provides a base for deploying scale-out applications. But do they need different install media? Or can they live within one release image that has selectable options? I think a Workstation Live image, a netinstall image and a server DVD image are sufficient to create any Fedora laptop, desktop, server or cloud installation you want. Is that not the case? For an install without internet there would be some packages that aren't on the DVD image but you could have them on your intranet. ___ 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 06/11/2015 02:45 PM, M. Edward (Ed) Borasky wrote: But do they need different install media? Or can they live within one release image that has selectable options? I think a Workstation Live image, a netinstall image and a server DVD image are sufficient to create any Fedora laptop, desktop, server or cloud installation you want. Is that not the case? For an install without internet there would be some packages that aren't on the DVD image but you could have them on your intranet. As Matthew said, we've had this conversation before. I don't want to take a DVD or any kind of install image and spin it up to craft an AMI or image for OpenStack or whatever - I want a premade image I can spin up *immediately*. I want it tailored *for that environment* and that's it. -- Joe Brockmeier | Community Team, OSAS j...@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ signature.asc Description: OpenPGP digital signature ___ 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 want a premade image I can spin up *immediately*. Agreed, the purpose of the Cloud Base (per the current PRD) is pre-built guest images in various IaaS formats and availabilities. I want it tailored *for that environment* and that's it. Is where we're at loggerheads. While cloud environments are operationally different than bare-metal, it's not useful to most cloud admins to have to track down and automate huge amounts of packages to get to a working Ruby on Rails server, and having a major usability difference between Server and Cloud in that context is going to harm adoption. To possibly commit a faux pas and talk about RHEL (as a consumer, I'm not a red hatter), RHEL 6 Base on bare metal and RHEL 6 Base in AWS are functionally equivalent. Someone on the inside who knows exactly what the builds contain can probably pick nits but the differences are mostly invisible, aside from repo locations. That's what I think the Cloud SIG needs to deliver for Fedora Cloud Base. Spinning up a image *inside* an IaaS environment (from Heat or EC2 console) slightly faster isn't an advantage if I then lose more time installing packages over the network, creating a new image to then start using as my baseline. The SIG goals from the PRD are Increase in adoption. Third party support / targeting of Fedora Cloud as a platform. The reduced footprint should do nothing to harm the goals. I believe that aggressive attempts at driving size down (refactoring cloud-init and removing system python) do not have the return that we expect in terms of the goals over the requirements. To mangle Einstein As small as necessary, but no smaller - Matt M On Thu, Jun 11, 2015 at 3:09 PM, Joe Brockmeier j...@redhat.com wrote: On 06/11/2015 02:45 PM, M. Edward (Ed) Borasky wrote: But do they need different install media? Or can they live within one release image that has selectable options? I think a Workstation Live image, a netinstall image and a server DVD image are sufficient to create any Fedora laptop, desktop, server or cloud installation you want. Is that not the case? For an install without internet there would be some packages that aren't on the DVD image but you could have them on your intranet. As Matthew said, we've had this conversation before. I don't want to take a DVD or any kind of install image and spin it up to craft an AMI or image for OpenStack or whatever - I want a premade image I can spin up *immediately*. I want it tailored *for that environment* and that's it. -- Joe Brockmeier | Community Team, OSAS j...@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ ___ 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 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: Fedora 22 is out, Fedora 23 is coming :)
Then maybe it's just a terminology issue, I'm aware of the different Base projects under the Cloud SIG, but it's not always clear in email which Base is being discussed. Unless the two bullets in the list apply to the Cloud Base, which I'd then question. - Matt M On Tue, Jun 2, 2015 at 12:28 PM, M. Edward (Ed) Borasky zn...@znmeb.net wrote: On Tue, Jun 2, 2015 at 8:19 AM, Matt Micene nzwul...@gmail.com wrote: I'm curious about the drive to make the base cloud image as small as possible and remove things like the Python stack. It could be that I've got a terminology issue (which also could be the case) tracking threads. What's the expected use of the base cloud image? The relevant download page states: Everything you need, and nothing you don't. images for creating general purpose virtual machines (VMs) The drive to a small as possible and stripped down base image doesn't make sense to me in that context. General purpose compute for a modern system would include things like dnf, python, full logging capabilities, without a need to add a large number of packages. If the drive to make the base image as small as possible is for docker containers (as I've seen in other threads), there already exists a Docker Base image. What is base functionality in a container isn't the same as base functionality for a general purpose system in AWS or OpenStack. I guess I'm saying I'd like to be clear when we are talking about Cloud Base vs Docker Base and make sure the relationship between them is clear and the goals for each are clear. Especially where changes could harm adoption (Cloud Images without Python in AWS would be bad ). -Matt M There are two-and-a-half Cloud images: 1. Docker Base: this is a minimum viable Fedora and is usually run via 'docker pull' from Docker Hub, where it goes by the name 'docker.io/fedora:22'. Currently it's 186.5 MB. It has dnf, which depends on Python. I don't think you can remove Python but I believe there are no Perl or Ruby dependencies in it. 2. Cloud Base: this lives in a Platform-as-a-Service environment and IIRC is a stripped-down Server. It can host containers but IIRC it can do more. I've never used Cloud Base but I'm pretty sure it has dnf and Python. 2.5. Project Atomic: this was released in Fedora 22 but the project team has decoupled from Fedora's main six-month cycle in favor of a faster two-week release cycle. It uses rpm-ostree to manage RPMs rather than dnf so it may not need Python. It's mainly for hosting Docker containers, and its main end user is the OpenShift Platform-as-a-Service. So I don't think there's any risk that an AWS Fedora won't have Python. However, I believe there's a move to guarantee that all Python-dependent software runs with Python 3 and only the Python 3 runtime is present on Fedora Cloud products. ___ 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 Mon, Jun 1, 2015 at 5:50 AM, Kushal Das kushal...@gmail.com wrote: Hi, Thank you everyone for a great Fedora 22 release. Things are stable now, before we can understand we will be in the alpha freeze for Fedora 23. So this is a good time to start working on the new features list for Fedora 23. 23rd June is the last date to submit a new system wide change for Fedora 23, 11th August is the alpha release for Fedora 23. Below I have written few points which came up in different discussions. Please feel free to comment/add/delete in this thread. * Better user documentation for cloud. We need something better than wiki. For a volunteer-run documentation project, I'm extremely impressed with the Mozilla Developer Network's site. The underlying CMS is something they built after struggling with some commercial offerings. It's called Kuma and it's open source. Here's the link: https://developer.mozilla.org/en-US/docs/MDN/Kuma So I'd say: 1. Reach out to Mozilla 2. Package Kuma for Fedora 3. 4. Profit! ;-) [snip] My other long-standing wishlist item (one which I hack on myself sporadically) is a Boot2Docker-like point and click user interface for Windows 8.1+ Professional using Client Hyper-V as the hosting mechanism and Project Atomic (any of RHEL/CentOS/Fedora incarnations) as the Docker host. I've been able to make Atomic virtual machines via the bare metal Fedora Atomic ISO and run containers, but there's no point-and-click installer or documentation, both of which are mandatory for this use case. There's also no market research that indicates anyone but me would use it. ;-) -- 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 think there is one good (nearly) point and click installer that we could use (more): vagrant. Currently there is only boxes for VirtualBox and libvirt, maybe it would be possible to provide boxes for VMware, Parallels, KVM etc. It would also be great to publish the meta-info on https://atlas.hashicorp.com to allow something like vagrant init fedora/atomic-23. If we are looking for a more boot2docker like solution it is good to know that boot2docker (cli) is being deprecated by docker machine which actually (soon) have a decent number of drivers (VirtualBox, VMware etc). Docker machine just downloads and uses the boot2docker.iso. It should be possible to use another iso as long as it follows some expectations by docker machine. In the near future there will also be a GUI for docker machine called https://kitematic.com/ . And to repeat what previously have been said, there is a desperate need of better documentation. On Mon, Jun 1, 2015 at 9:15 PM, M. Edward (Ed) Borasky zn...@znmeb.net wrote: On Mon, Jun 1, 2015 at 5:50 AM, Kushal Das kushal...@gmail.com wrote: Hi, Thank you everyone for a great Fedora 22 release. Things are stable now, before we can understand we will be in the alpha freeze for Fedora 23. So this is a good time to start working on the new features list for Fedora 23. 23rd June is the last date to submit a new system wide change for Fedora 23, 11th August is the alpha release for Fedora 23. Below I have written few points which came up in different discussions. Please feel free to comment/add/delete in this thread. * Better user documentation for cloud. We need something better than wiki. For a volunteer-run documentation project, I'm extremely impressed with the Mozilla Developer Network's site. The underlying CMS is something they built after struggling with some commercial offerings. It's called Kuma and it's open source. Here's the link: https://developer.mozilla.org/en-US/docs/MDN/Kuma So I'd say: 1. Reach out to Mozilla 2. Package Kuma for Fedora 3. 4. Profit! ;-) [snip] My other long-standing wishlist item (one which I hack on myself sporadically) is a Boot2Docker-like point and click user interface for Windows 8.1+ Professional using Client Hyper-V as the hosting mechanism and Project Atomic (any of RHEL/CentOS/Fedora incarnations) as the Docker host. I've been able to make Atomic virtual machines via the bare metal Fedora Atomic ISO and run containers, but there's no point-and-click installer or documentation, both of which are mandatory for this use case. There's also no market research that indicates anyone but me would use it. ;-) -- 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 ___ 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 06/01/2015 06:46 PM, Rickard von Essen wrote: I think there is one good (nearly) point and click installer that we could use (more): vagrant. Currently there is only boxes for VirtualBox and libvirt, maybe it would be possible to provide boxes for VMware, Parallels, KVM etc. It would also be great to publish the meta-info on https://atlas.hashicorp.com to allow something like vagrant init fedora/atomic-23. we should add this to the PRD / features for F23. Note that it's not always trivial to add support for new box types. (Note, KVM is implied with libvirt, so we have that covered. Does Vagrant have a Parallels provider? VMware seems like an important target.) If we are looking for a more boot2docker like solution it is good to know that boot2docker (cli) is being deprecated by docker machine which actually (soon) have a decent number of drivers (VirtualBox, VMware etc). Docker machine just downloads and uses the boot2docker.iso. It should be possible to use another iso as long as it follows some expectations by docker machine. In the near future there will also be a GUI for docker machine called https://kitematic.com/ . I haven't tried docker machine, we should look into this... Best, jzb -- Joe Brockmeier | Open Source and Standards (OSAS) j...@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://projectatomic.io/ signature.asc Description: OpenPGP digital signature ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
