Re: [cloud] #44: hey we should have a vagrant base box

[Fedora Cloud Trac Tickets]

#44: hey we should have a vagrant base box
+-
 Reporter:  mattdm  |   Owner:
 Type:  task|  Status:  closed
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:  fixed
 Keywords:  |
+-
Changes (by kushal):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Closing this ticket as part of trac clean up process. If you want to
 reopen, please reopen it after we move to pagure.io as atomic-wg.

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: [cloud] #44: hey we should have a vagrant base box

[Fedora Cloud Trac Tickets]

#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):

  One issue with building a vagrant image (at least for the default
 virtualbox provider), is that the guest additions are kernel modules that
 aren't upstream, so can't be included in fedora (as far as I am aware).

 Agreed. Which is another reason why I built everything on vagrant-libvirt
 which has nothing to do with virtualbox.

 When need help packaging upstream vagrant with vagrant-libvirt. If anyone
 can help out who has RPM+Ruby skills, it would be much appreciated!

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#comment:13
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

[Fedora Cloud Trac Tickets]

#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 tomprince):

 One issue with building a vagrant image (at least for the default
 virtualbox provider), is that the guest additions are kernel modules that
 aren't upstream, so can't be included in fedora (as far as I am aware).

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#comment:12
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

[Fedora Cloud Trac Tickets]

#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: [cloud] #44: hey we should have a vagrant base box

[Fedora Cloud Trac Tickets]

#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

[Fedora Cloud Trac Tickets]

#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] #44: hey we should have a vagrant base box

[Fedora Cloud Trac Tickets]

#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

[Fedora Cloud Trac Tickets]

#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

[Fedora Cloud Trac Tickets]

#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

[Fedora Cloud Trac Tickets]

#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

Re: [cloud] #44: hey we should have a vagrant base box

[Fedora Cloud Trac Tickets]

#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):

 Oh. Fair enough! I'm building one now using this method...

 https://ttboj.wordpress.com/2014/01/20/building-base-images-for-vagrant-
 with-a-makefile/

 and this patch:

 https://github.com/purpleidea/puppet-
 gluster/commit/e6f0bc559802abae16e06c79062f1910538fbedd

 Should be ready once I get on fast internet...

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#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

[Fedora Cloud Trac Tickets]

#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 mattdm):

 Awesome!

 Eventually, it'd be awesome if this would automatically fall out of the
 release engineering process. But let's start with whatever we can get :)

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#comment:2
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

[Fedora Cloud Trac Tickets]

#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:2 mattdm]:
  Awesome!
 
  Eventually, it'd be awesome if this would automatically fall out of the
 release engineering process. But let's start with whatever we can get :)

 LOL, well you are all welcome to use my scripts-- they're all open
 source, but I'd rather not be the guy plugging it into release
 engineering. I'm happy to run make on my laptop whenever someone asks
 for a new build though.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#comment:3
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

[Fedora Cloud Trac Tickets]

#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):

 Currently uploading, but wholly untested. Not even once!

 In about two hours this should be downloadable. (Make sure the sha256sum
 matches!)

 https://download.gluster.org/pub/gluster/purpleidea/vagrant/fedora-20/

 After I get some sleep, I'll test this as soon as I can.

 HTH

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#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