Re: Chair for tomorrow's meeting?
On Wed, May 14, 2014 at 07:47:37PM -0500, Joe Brockmeier wrote: I believe Fedocal sent out the reminder, but I was hoping to see if anyone could step up to chair the IRC meeting tomorrow. I'm going to be around for the first bit of the meeting, but will have to step out early. Yep, I've got it. See eveybody in a couple of hours. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! ___ 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: Chair for tomorrow's meeting?
On Thu, May 15, 2014 at 7:41 PM, Matthew Miller mat...@fedoraproject.org wrote: On Wed, May 14, 2014 at 07:47:37PM -0500, Joe Brockmeier wrote: I believe Fedocal sent out the reminder, but I was hoping to see if anyone could step up to chair the IRC meeting tomorrow. I'm going to be around for the first bit of the meeting, but will have to step out early. Yep, I've got it. See eveybody in a couple of hours. Ah well, that's good. I was going to volunteer too, but just noticed I (also) failed at using the gmail app and sent it with the wrong address. Happens too damn often. Anyway, as long as we have a chair, all is well. :) ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
What needs to happen for official Fedora in GCE?
Hi everyone. As promised at the meeting two weeks ago, here is an email about this. :) I think the goal here is (and correct me if I'm wrong): a) a semi-official F20 image in GCE as soon as possible b) actually-official F21 images (for all of our spins) See https://fedorahosted.org/cloud/ticket/5 for the blockers. I think these are both resolved in F21 but the GCE datasource isn't yet in cloud-init in F20. So, there are really two parallel lines of work here: a) producing and uploading the ad-hoc F20 image (possily as a remix, if we don't get a cloud-init update b) figuring out what release engineering and quality assurance needs we have for F21, and... someone to do those things. (If we have an easy upload process which uses open-source tools included in Fedora, it'll be easy for Fedora Rel-Eng to add that to the current process. Better, we'll want it integrated into the planned _automatic_ process.) Anything I'm missing here? -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! ___ 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: What needs to happen for official Fedora in GCE?
I wrote GCE datasource support for cloud-init and submitted upstream few months ago which is now released - https://launchpad.net/cloud-init/trunk/0.7.5 . Not sure if this helps in any way. I have been running f20 in GCE in production for a long time now: https://github.com/vaijab/fedora-gce-image Let me know if I can be useful with anything. Thanks, Vaidas On 15 May 2014 14:25, Matthew Miller mat...@fedoraproject.org wrote: Hi everyone. As promised at the meeting two weeks ago, here is an email about this. :) I think the goal here is (and correct me if I'm wrong): a) a semi-official F20 image in GCE as soon as possible b) actually-official F21 images (for all of our spins) See https://fedorahosted.org/cloud/ticket/5 for the blockers. I think these are both resolved in F21 but the GCE datasource isn't yet in cloud-init in F20. So, there are really two parallel lines of work here: a) producing and uploading the ad-hoc F20 image (possily as a remix, if we don't get a cloud-init update b) figuring out what release engineering and quality assurance needs we have for F21, and... someone to do those things. (If we have an easy upload process which uses open-source tools included in Fedora, it'll be easy for Fedora Rel-Eng to add that to the current process. Better, we'll want it integrated into the planned _automatic_ process.) Anything I'm missing here? -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Vaidas Jablonskis ___ 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: What needs to happen for official Fedora in GCE?
On 5/15/14, 7:35 PM, Vaidas Jablonskis wrote: I wrote GCE datasource support for cloud-init and submitted upstream few months ago which is now released - https://launchpad.net/cloud-init/trunk/0.7.5 . Not sure if this helps in any way. I have been running f20 in GCE in production for a long time now: https://github.com/vaijab/fedora-gce-image I recently updated rawhide to cloud-init 0.7.5 and there's no reason it couldn't get merged back into f20. Let me know if I can be useful with anything. Thanks, Vaidas On 15 May 2014 14:25, Matthew Miller mat...@fedoraproject.org mailto:mat...@fedoraproject.org wrote: Hi everyone. As promised at the meeting two weeks ago, here is an email about this. :) I think the goal here is (and correct me if I'm wrong): a) a semi-official F20 image in GCE as soon as possible b) actually-official F21 images (for all of our spins) See https://fedorahosted.org/cloud/ticket/5 for the blockers. I think these are both resolved in F21 but the GCE datasource isn't yet in cloud-init in F20. So, there are really two parallel lines of work here: a) producing and uploading the ad-hoc F20 image (possily as a remix, if we don't get a cloud-init update b) figuring out what release engineering and quality assurance needs we have for F21, and... someone to do those things. (If we have an easy upload process which uses open-source tools included in Fedora, it'll be easy for Fedora Rel-Eng to add that to the current process. Better, we'll want it integrated into the planned _automatic_ process.) Anything I'm missing here? -- Matthew Miller-- Fedora Project-- mat...@fedoraproject.org mailto:mat...@fedoraproject.org Tepid change for the somewhat better! ___ cloud mailing list cloud@lists.fedoraproject.org mailto:cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Vaidas Jablonskis ___ 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: [cloud] #44: hey we should have a vagrant base box
#44: hey we should have a vagrant base box +- Reporter: mattdm | Owner: Type: task| Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: | +- Comment (by walters): A few issues with that script: * Disabling SELinux is obviously not something we can ship with * virt-builder is a useful tool, but rwmjones's website is not maintained by releng. It's not going to work to bounce content to his site and then have releng download it again Now there are two approaches. 1) Anaconda + kickstart I think this is probably the way to go, particularly as it would allow us to include Vagrant-specific content. 2) Mutate an existing qcow2 (e.g. the cloud image) For the latter, see: https://github.com/cgwalters/rpm-ostree- autocompose/commit/55af81ff04afb24429616ccb2c67b408e3a7e364 for an approach which injects a systemd unit file, rather than attempting to change the target from the outside. The advantage of this is that way we pick up the SELinux policy from the target. -- Ticket URL: https://fedorahosted.org/cloud/ticket/44#comment:5 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: What needs to happen for official Fedora in GCE?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 15 May 2014 09:25:25 -0400 Matthew Miller mat...@fedoraproject.org wrote: Hi everyone. As promised at the meeting two weeks ago, here is an email about this. :) I think the goal here is (and correct me if I'm wrong): a) a semi-official F20 image in GCE as soon as possible b) actually-official F21 images (for all of our spins) See https://fedorahosted.org/cloud/ticket/5 for the blockers. I think these are both resolved in F21 but the GCE datasource isn't yet in cloud-init in F20. So, there are really two parallel lines of work here: a) producing and uploading the ad-hoc F20 image (possily as a remix, if we don't get a cloud-init update b) figuring out what release engineering and quality assurance needs we have for F21, and... someone to do those things. (If we have an easy upload process which uses open-source tools included in Fedora, it'll be easy for Fedora Rel-Eng to add that to the current process. Better, we'll want it integrated into the planned _automatic_ process.) if it doesnt have open source uploading tools and we have to use proprietary tools to do it it will not be done. we have a requirement that everything has to be open. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTdMkUAAoJEH7ltONmPFDRYQ8P/jh5HVSaposF/4SR0qOyNJKP ummqgk+wDMzxNz1ixRgsBDkSzJCoojQduGUea8nmXqO/+wbyU9N0lodC04kNftdq 9cBDrlNdI4+D0eSwQYEEPjt8EUk8+Wlo6qBiR/CaRgdTwheXoMND/aqAeWFwxPV2 guQqXhAPyZkHW3wqzCTcIOhxlwHa/XZh5H4LWjpEsckMjsDNQZbe/rmsL2CQxDFN 1HVppwsfBGgJazjoZTeiavp3H/97JgydJVLJC55OmCWpbyJw4TG9NeIUj3w8OZOo bBrbzO878W11TUw0vQvWwatK8ELv2IKmNc+/f5g9mbFMJV2BsTUrN6FHE6ihSTEg uEVwQTkDr+sy0JR7Sw6HhvBCbUAsf7g7slydYxh8s8bOOrNvHmZS/RHpLFRmFCA6 XlnHLr6Sg/tS7S+dV7MN+wEGou09weHnLdfplpzq/NgLgiix+4Ah2SIbZVlv+bI5 JJRq+E9NoCIaoRLbwKl6n1j8PO8pBObirodDteKXLGCLXSMEmE2x8Uokf/+3Z2Bt qmtVoRVX62NG7wEhJfWGFXDXSdXE5PzcNVt1NE0X3WUhOflJaDZ//KtjKVd9fNX9 8uAV22xtsWI/sHjEnWOAFq28Bq7GmJW+DOZEHbLM7IYlkUnmAcPzmRJi1Vn/aPDX gbsnppUhrhVhcG/8LVkq =8t3R -END PGP 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: [cloud] #50: Deliverables and release engineering changes for Fedora.Next
#50: Deliverables and release engineering changes for Fedora.Next --+- Reporter: mattdm| Owner: Type: task | Status: new Priority: major | Milestone: Future Component: Planning | Resolution: Keywords: meeting | --+- Comment (by mattdm): note from May 15th meeting: jzb will file tickets for the individual new spins -- Ticket URL: https://fedorahosted.org/cloud/ticket/50#comment:1 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] #44: hey we should have a vagrant base box
#44: hey we should have a vagrant base box +- Reporter: mattdm | Owner: Type: task| Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: | +- Changes (by rjones): * cc: rjones@… (added) -- Ticket URL: https://fedorahosted.org/cloud/ticket/44#comment:6 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] #44: hey we should have a vagrant base box
#44: hey we should have a vagrant base box +- Reporter: mattdm | Owner: Type: task| Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: | +- Comment (by rjones): Not sure how virt-builder is involved here? In any case note that virt- builder will use existing cloud images, but someone has to provide an index file (https://fedorahosted.org/rel-eng/ticket/5805) -- Ticket URL: https://fedorahosted.org/cloud/ticket/44#comment:7 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] #23: File F22 change: Re-factor cloud-init
#23: File F22 change: Re-factor cloud-init --+ Reporter: mattdm| Owner: hguemar Type: task | Status: assigned Priority: normal| Milestone: Fedora 22 Component: Cloud Base Image | Resolution: Keywords:| --+ Changes (by mattdm): * keywords: meeting = Comment: as per current meeting, remove meeting keyword :) We will be investigating min-cloud-agent (new name for min-metadata- service) for the Fedora Atomic image ''only'' for F21. May look at it for other images for F22. -- Ticket URL: https://fedorahosted.org/cloud/ticket/23#comment:8 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] #51: start communication/collaboration on cloud image updates
#51: start communication/collaboration on cloud image updates -+--- Reporter: mattdm | Owner: roshi Type: task | Status: assigned Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -+--- Comment (by mattdm): Status update for this week is that things are basically moving forward but it isn't ready yet for doing cloudy things. Taskotron is reaching a useful stage. Leaving this ticket open for a status update next week. -- Ticket URL: https://fedorahosted.org/cloud/ticket/51#comment:4 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
Cloud WG meeting minutes (2014-05-15)
== #fedora-meeting: Cloud WG (2014-05-15) == Meeting started by mattdm at 14:00:54 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-05-15/cloud.2014-05-15-14.00.log.html . Meeting summary --- * Hello Everyone (mattdm, 14:01:03) * mattdm (mattdm, 14:01:35) * jzb (jzb, 14:01:40) * janeznemanic (janeznemanic, 14:01:47) * roshi (roshi, 14:02:08) * imcleod (imcleod, 14:02:12) * walters (walters, 14:02:36) * scollier (scollier, 14:02:54) * red_trela (red_trela, 14:03:33) * number80 (number80, 14:03:44) * Current Tickets (mattdm, 14:05:15) * LINK: https://fedorahosted.org/cloud/report/9 (mattdm, 14:05:19) * Deliverables and release engineering changes for Fedora.Next (mattdm, 14:06:45) * LINK: https://fedorahosted.org/cloud/ticket/50 (mattdm, 14:06:46) * ACTION: jzb to file spins tickets (mattdm, 14:13:48) * ACTION: mattdm to work with walters and dgilmore and whoever else to figure out the process of delivering ostree trees in a sane way (mattdm, 14:14:22) * ACTION: scollier to get legal signoff for docker image upload account (mattdm, 14:16:51) * ACTION: imcleod to verify licensing status of GCE upload code (imcleod, 14:22:10) * ACTION: mattdm to check with samkottler re state of gcutils (mattdm, 14:27:17) * ACTION: mattdm to continue working on legal signoff for hp account (mattdm, 14:27:48) * ACTION: imcleod talking to rackspace about image upload api (mattdm, 14:28:05) * Project Atomic and Fedora Docker Host Image (mattdm, 14:29:57) * LINK: https://fedorahosted.org/cloud/ticket/46 (mattdm, 14:29:58) * File F22 change: Re-factor cloud-init (mattdm, 14:33:11) * LINK: https://fedorahosted.org/cloud/ticket/23 (mattdm, 14:33:13) * start communication/collaboration on cloud image updates (mattdm, 14:37:18) * LINK: https://fedorahosted.org/cloud/ticket/51 (mattdm, 14:37:20) * rename cloud spin kickstart to distinguish the cloud base image (mattdm, 14:40:11) * LINK: https://fedorahosted.org/cloud/ticket/16 (mattdm, 14:40:13) * ACTION: red_trela to deal with cloud image kickstart file renaming (mattdm, 14:45:24) * Other Followups (mattdm, 14:45:43) * All the things: https://fedorahosted.org/cloud/ticket/55 (mattdm, 14:47:04) * ostree conversations: https://fedorahosted.org/cloud/ticket/56 (mattdm, 14:47:10) * Open Floor (mattdm, 14:47:54) * red_trela to handle cloud base and atomic spins process (mattdm, 14:51:35) * LINK: https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs (roshi, 14:54:22) * HELP: need people to look at draft cloud QA docs https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs (mattdm, 14:54:43) Meeting ended at 14:57:41 UTC. Action Items * jzb to file spins tickets * mattdm to work with walters and dgilmore and whoever else to figure out the process of delivering ostree trees in a sane way * scollier to get legal signoff for docker image upload account * imcleod to verify licensing status of GCE upload code * mattdm to check with samkottler re state of gcutils * mattdm to continue working on legal signoff for hp account * imcleod talking to rackspace about image upload api * red_trela to deal with cloud image kickstart file renaming Action Items, by person --- * dgilmore * mattdm to work with walters and dgilmore and whoever else to figure out the process of delivering ostree trees in a sane way * imcleod * imcleod to verify licensing status of GCE upload code * imcleod talking to rackspace about image upload api * jzb * jzb to file spins tickets * mattdm * mattdm to work with walters and dgilmore and whoever else to figure out the process of delivering ostree trees in a sane way * mattdm to check with samkottler re state of gcutils * mattdm to continue working on legal signoff for hp account * red_trela * red_trela to deal with cloud image kickstart file renaming * samkottler * mattdm to check with samkottler re state of gcutils * scollier * scollier to get legal signoff for docker image upload account * walters * mattdm to work with walters and dgilmore and whoever else to figure out the process of delivering ostree trees in a sane way * **UNASSIGNED** * (none) People Present (lines said) --- * mattdm (118) * number80 (29) * roshi (21) * red_trela (15) * imcleod (15) * walters (7) * scollier (7) * dgilmore (6) * zodbot (6) * jzb (5) * janeznemanic (2) * jreznik (1) * jreznik_ (1) * jsmith (1) * mrunge (0) * samkottler (0) * rbergeron (0) * geppetto (0) * frankieonuonga (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better!
Re: [cloud] #44: hey we should have a vagrant base box
#44: hey we should have a vagrant base box +- Reporter: mattdm | Owner: Type: task| Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: | +- Comment (by purpleidea): Replying to [comment:5 walters]: A few issues with that script: * Disabling SELinux is obviously not something we can ship with Agreed. I actually forgot about this... I think it was something that was needed by vagrant boxes at some point. Easy to change this. (one-liner). * virt-builder is a useful tool, but rwmjones's website is not maintained by releng. It's not going to work to bounce content to his site and then have releng download it again I agree! I do think it makes sense to build upon existing tools where appropriate. This way we have fewer different initial ways to build a base image. For the releng requirements, I'm pretty sure rwmjones tools can point at a different repo, and even work fully offline. You typically need to set the /etc/virt-builder/repos.d/something.conf file to whatever you want. rwmjones is probably a great resource for info on how to build his template .xz files. Now there are two approaches. 1) Anaconda + kickstart I think this is probably the way to go, particularly as it would allow us to include Vagrant-specific content. 2) Mutate an existing qcow2 (e.g. the cloud image) For the latter, see: https://github.com/cgwalters/rpm-ostree- autocompose/commit/55af81ff04afb24429616ccb2c67b408e3a7e364 for an approach which injects a systemd unit file, rather than attempting to change the target from the outside. The advantage of this is that way we pick up the SELinux policy from the target. I actually prefer my makefile/virt-builder approach, but I obviously am fine with other people working on different methods. I figured I'd step up to help with this, since it was apparently a very long-standing request. I'm happy to continue to generate these Fedora vagrant boxes, and I think it makes sense to use this, even officially since it works _now_, and nobody for a while seemed to be doing this. I should mention, working on this isn't really my prime directive, so more than I anything I was trying to be helpful so that I have beverage or bug karma with mattdm :P Cheers -- Ticket URL: https://fedorahosted.org/cloud/ticket/44#comment:8 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] #44: hey we should have a vagrant base box
#44: hey we should have a vagrant base box +- Reporter: mattdm | Owner: Type: task| Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: | +- Comment (by purpleidea): Replying to [comment:7 rjones]: Not sure how virt-builder is involved here? In any case note that virt- builder will use existing cloud images, but someone has to provide an index file (https://fedorahosted.org/rel-eng/ticket/5805) Virt-builder being involved is my fault, sorry. It happened when I decided that I liked your tools enough to integrate them in my other projects. See: https://ttboj.wordpress.com/2014/01/20/building-base-images-for-vagrant- with-a-makefile/ For more details. -- Ticket URL: https://fedorahosted.org/cloud/ticket/44#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] #44: hey we should have a vagrant base box
#44: hey we should have a vagrant base box +- Reporter: mattdm | Owner: Type: task| Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: | +- Comment (by walters): Replying to [comment:8 purpleidea]: Easy to change this. (one-liner). I'm not so sure it's that easy. The problem I hit with using libguestfs for this sort of stuff is that you really need to be sure the SELinux label of critical files like /etc/passwd is set. It's hard to do that from the outside - doing it *inside* the system on boot means we use the target policy. I actually prefer my makefile/virt-builder approach, but I obviously am fine with other people working on different methods. The makefile versus shell versus javascript or whatever is mostly a red herring I think. The issue I see is more the second part - the semantics around how we change the contents of the target system. I figured I'd step up to help with this, since it was apparently a very long-standing request. Definitely! Do you have some bandwidth to work on this/continue the conversation here? There are a few aspects to this: 1) Content definition - what packages are installed? 2) Partition layout 3) System default configuration (vagrant user, vagrant ssh keys, sudo) To me, Anaconda+kickstart files are the thing to use for #1 and #2. In other words we're just talking about another Fedora Cloud type image, except with Vagrant as the hypervisor. For #3, kickstart files are probably also the way to go. My script was just a hack because I didn't have ostree support in Anaconda, but now I do. There's a general question here about anaconda versus virt-builder; when should you rebuild versus post-customize. To me the answer comes down to the package set. If for example we wanted different packages in the Vagrant image, then it would need to be an Anaconda rebuild. -- Ticket URL: https://fedorahosted.org/cloud/ticket/44#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] #44: hey we should have a vagrant base box
#44: hey we should have a vagrant base box +- Reporter: mattdm | Owner: Type: task| Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: | +- Comment (by purpleidea): Replying to [comment:10 walters]: Replying to [comment:8 purpleidea]: Easy to change this. (one-liner). I'm not so sure it's that easy. The problem I hit with using libguestfs for this sort of stuff is that you really need to be sure the SELinux label of critical files like /etc/passwd is set. It's hard to do that from the outside - doing it *inside* the system on boot means we use the target policy. Agreed... but, I do do it inside. :) https://github.com/purpleidea/puppet- gluster/blob/master/builder/Makefile#L83 I'm not sure if this is now equivalent to the new --selinux-relabel flag for virt-builder. If it is, we can simplify this. I actually prefer my makefile/virt-builder approach, but I obviously am fine with other people working on different methods. The makefile versus shell versus javascript or whatever is mostly a red herring I think. The issue I see is more the second part - the semantics around how we change the contents of the target system. I figured I'd step up to help with this, since it was apparently a very long-standing request. Definitely! Do you have some bandwidth to work on this/continue the conversation here? To be honest, not a lot, actually. If it would help, I will be in Westford next week, and I am happy to meet if you want to hack on this, or iterate quickly over some of the ideas. There are a few aspects to this: 1) Content definition - what packages are installed? 2) Partition layout 3) System default configuration (vagrant user, vagrant ssh keys, sudo) To me, Anaconda+kickstart files are the thing to use for #1 and #2. In other words we're just talking about another Fedora Cloud type image, except with Vagrant as the hypervisor. For #3, kickstart files are probably also the way to go. My script was just a hack because I didn't have ostree support in Anaconda, but now I do. There's a general question here about anaconda versus virt-builder; when should you rebuild versus post-customize. To me the answer comes down to the package set. If for example we wanted different packages in the Vagrant image, then it would need to be an Anaconda rebuild. So, I must say, that I love Anaconda for it's use case, however in general, it's the reason that virt-builder and vagrant are so useful. The vagrant user or really most people (IMO), don't want to have to muck around with getting every anaconda setting right... If I can build this on top of an already built base image, then there is less chance for error. IOW, I'm glad Anaconda exists, but I want to use it as little as possible. What OS image can't you build with virt-builder? I don't know that it does anything to the template that can't be properly fixed with --flags to virt-builder... And it's easy :) As a side note, these comments might not make much sense in light of some of the os-tree stuff you're doing, but I'm not up to speed on all the specifics, so my commentary assumes that stuff doesn't exist. My bad if that's the case. -- Ticket URL: https://fedorahosted.org/cloud/ticket/44#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
