Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
On 05/05/16 19:16 +, Amrith Kumar wrote:
Pete, please clarify … I was going to push the dib elements that we currently
have and you were writing CentOS elements. Is that right?
Seems like there are some crossed wires here.
Pete is out today so chiming in on his behalf for now. At the summit Pete signed
up for amending the current spec, include the DIB bits in there and to pull the
DIB elements out of trove-integration into the repo, which Pete himself agreed
to create as well.
I believe he's already started on this so, I'd prolly let him handle this as
agreed at the summit.
Thanks,
Flavio
-amrith
From: Victoria Martínez de la Cruz [mailto:victo...@vmartinezdelacruz.com]
Sent: Thursday, May 05, 2016 10:30 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion
of image building in Trove
We agreed during the summit that we were going to amend the spec to reflect
latest discussions with regards to having DIB as a primary implementation and
adding support for libguestfs in parallel. The spec blueprint is named "Trove
image builder" and it's about building images and not about which tool we are
going to use. Thanks for creating the artifacts we need to push the code, we
take it over from there.
2016-05-05 11:12 GMT-03:00 Amrith Kumar :
From: Victoria Martínez de la Cruz [mailto:victo...@vmartinezdelacruz.com]
Sent: Thursday, May 05, 2016 9:00 AM
To: OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
discussion of image building in Trove
Hi all,
A few things:
- I agree that moving from DIB to libguestfs is a bold move and that we
should try to avoid changing tools unless highly necessary. The downsides
we found for DIB are detailed in this spec [0] and Ethan (in this same
thread) also added valid points on the Sahara case. My concern here is,
should we stick with DIB just because is the standard for image creation?
Shouldn't we take in consideration that some projects, like Sahara, are
moving away from it?
- In the long term it would be ideal that we reach to a common solution for
image creation for all the projects that need tailored images: Trove,
Sahara, Octavia, Manila, and IIRC, Kolla and Cue.
- In the short term, I'm on board or working on having tools based on DIB
for image creation in Trove.
- Amrith, Pete is working on the image creation process for Trove. The spec
is up there [0]. I think is his work to kick-off that repository.
[amrith] The spec [0] referenced is entitled “Separate trove image build
project based on libguestfs tools”. I am working on image building using
the existing DIB elements that are already part of trove-integration. In
any event, please see line 220 of [0] for a detailed explanation of why I
am making the repository.
Best,
Victoria
[0] https://review.openstack.org/#/c/295274/
2016-05-04 23:20 GMT-03:00 Amrith Kumar :
As we discussed at summit, (and consistent with all of the comments) we
should move ahead with the project to advance the image builder for
Trove and make it easier to build guest images for Trove by leveraging
the DIB elements that we have in trove-integration.
To that end, the infra [1] and governance [2] changes have been
submitted for review. The Launchpad tracker [3] has been registered.
I am working on taking the existing DIB elements in trove-integration
and putting them in the new repository (openstack/trove-image-builder).
I am also going to continue to watch this conversation and record any
shortcomings with the existing DIB elements in Launchpad [3] and work
on fixing those as well. Pete mentions one in his earlier email and
I’ve logged that in Launchpad [4].
Thanks,
-amrith
[1] https://review.openstack.org/#/c/312805/
[2] https://review.openstack.org/#/c/312806/
[3] https://launchpad.net/trove-image-builder
[4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454
From: Mariam John [mailto:mari...@us.ibm.com]
Sent: Wednesday, May 04, 2016 4:19 PM
To: OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
discussion of image building in Trove
The way I see this, these are the 2 main concerns I have been hearing
regarding image building in Trove:
1) making the process simple and easy for users
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
Another few related things: * We tend to build our images in vm's. so if libguestfs has to spawn in a vm nested in that vm, it may have some performance issues. DIB doesn't have that problem. * We used to build our centos 6 images without grub a while back, but the first yum upgrade that upgraded a kernel in them broke things horribly. So grub support is very important. * Totally untested at this point, but we're going to be supporting uefi based VM's soon. We need a tool chain for building those images. I think DIB can build them, but last we looked it seems like the code makes some assumptions based on what the host is? If so, there is a chicken and an egg issue there? Thanks, Kevin From: Amrith Kumar [amr...@tesora.com] Sent: Thursday, May 05, 2016 12:54 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove Thanks Peter, that is very helpful. I’ve added your comments to the etherpad (https://etherpad.openstack.org/p/image-generation-in-openstack) -amrith From: Nordquist, Peter L [mailto:peter.nordqu...@pnnl.gov] Sent: Thursday, May 05, 2016 12:29 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove Hello all, I’m an Operator that has worked with DIB here for the last few months to get some working images for our Private Cloud. The only major issue I could come up with at the summit was the way grub 0.97 is treated in the bootloader element. For Centos 6, I had to find an element that could actually install grub 0.97 since when yum goes to update the kernel, it tries to update the grub config but not the extlinux config and in our cloud we need the VMs to stay updated. I’m sure the elements I have locally could be useful but the current thinking in my organization is to deprecate our Centos 6 use as quickly as possible. I’ve also run into an issue reported here [0] that makes installing a bootloader in Centos 6 a pain in either extlinux or grub 0.97. That’s really a quirk of the OS packages I’m using to build the image but still an odd situation. I’ve updated my VMs that build images to the Mitaka RDO release and with that release came the qemu-kvm-ev packages so I’m hopeful that these new packages might fix this bug. If not I’ll have to keep using Ubuntu to build my Centos 6 images. Security is a concern for sure but in my environment I have Jenkins spawn a VM in the cloud to build these images and I give these VMs enough ram to build the image in memory instead of copying the image to disk. I also have a requirement to standardize our images to using XFS for the root partition due to our flavors including a large amount of root disk. The reasoning here is that XFS resizes faster than ext4 so I would have a concern if libguestfs could not do this. It seems like I could just use DIB to fix any images that were created from your libguestfs scripts though so it might not be that much of a concern. [0]: https://bugs.launchpad.net/diskimage-builder/+bug/1477179 Peter Nordquist From: Mariam John [mailto:mari...@us.ibm.com] Sent: Thursday, May 05, 2016 07:43 To: OpenStack Development Mailing List (not for usage questions) mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove [Inactive hide details for Victoria Martínez de la Cruz ---05/05/2016 08:12:33 AM---Hi all, A few things:]Victoria Martínez de la Cruz ---05/05/2016 08:12:33 AM---Hi all, A few things: From: Victoria Martínez de la Cruz mailto:victo...@vmartinezdelacruz.com>> To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: 05/05/2016 08:12 AM Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove Hi all, A few things: - I agree that moving from DIB to libguestfs is a bold move and that we should try to avoid changing tools unless highly necessary. The downsides we found for DIB are detailed in this spec [0] and Ethan (in this same thread) also added valid points on the Sahara case. My concern here is, should we stick with DIB just because is the standard for image creation? Shouldn't we take in consideration that some projects, like Sahara, are moving away from? I think it would be worth trying to see if DIB can address the concerns raised by the different projects around image building and improve upon that. By improving DIB, I think all these projects and OpenStack in general can benefit from it. - In the long term it would be ideal that we reach to a common solution for image creation for all the projec
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
Thanks Peter, that is very helpful. I’ve added your comments to the etherpad (https://etherpad.openstack.org/p/image-generation-in-openstack) -amrith From: Nordquist, Peter L [mailto:peter.nordqu...@pnnl.gov] Sent: Thursday, May 05, 2016 12:29 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove Hello all, I’m an Operator that has worked with DIB here for the last few months to get some working images for our Private Cloud. The only major issue I could come up with at the summit was the way grub 0.97 is treated in the bootloader element. For Centos 6, I had to find an element that could actually install grub 0.97 since when yum goes to update the kernel, it tries to update the grub config but not the extlinux config and in our cloud we need the VMs to stay updated. I’m sure the elements I have locally could be useful but the current thinking in my organization is to deprecate our Centos 6 use as quickly as possible. I’ve also run into an issue reported here [0] that makes installing a bootloader in Centos 6 a pain in either extlinux or grub 0.97. That’s really a quirk of the OS packages I’m using to build the image but still an odd situation. I’ve updated my VMs that build images to the Mitaka RDO release and with that release came the qemu-kvm-ev packages so I’m hopeful that these new packages might fix this bug. If not I’ll have to keep using Ubuntu to build my Centos 6 images. Security is a concern for sure but in my environment I have Jenkins spawn a VM in the cloud to build these images and I give these VMs enough ram to build the image in memory instead of copying the image to disk. I also have a requirement to standardize our images to using XFS for the root partition due to our flavors including a large amount of root disk. The reasoning here is that XFS resizes faster than ext4 so I would have a concern if libguestfs could not do this. It seems like I could just use DIB to fix any images that were created from your libguestfs scripts though so it might not be that much of a concern. [0]: https://bugs.launchpad.net/diskimage-builder/+bug/1477179 Peter Nordquist From: Mariam John [mailto:mari...@us.ibm.com] Sent: Thursday, May 05, 2016 07:43 To: OpenStack Development Mailing List (not for usage questions) mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove [Inactive hide details for Victoria Martínez de la Cruz ---05/05/2016 08:12:33 AM---Hi all, A few things:]Victoria Martínez de la Cruz ---05/05/2016 08:12:33 AM---Hi all, A few things: From: Victoria Martínez de la Cruz mailto:victo...@vmartinezdelacruz.com>> To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: 05/05/2016 08:12 AM Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove Hi all, A few things: - I agree that moving from DIB to libguestfs is a bold move and that we should try to avoid changing tools unless highly necessary. The downsides we found for DIB are detailed in this spec [0] and Ethan (in this same thread) also added valid points on the Sahara case. My concern here is, should we stick with DIB just because is the standard for image creation? Shouldn't we take in consideration that some projects, like Sahara, are moving away from? I think it would be worth trying to see if DIB can address the concerns raised by the different projects around image building and improve upon that. By improving DIB, I think all these projects and OpenStack in general can benefit from it. - In the long term it would be ideal that we reach to a common solution for image creation for all the projects that need tailored images: Trove, Sahara, Octavia, Manila, and IIRC, Kolla and Cue. - In the short term, I'm on board or working on having tools based on DIB for image creation in Trove. - Amrith, Pete is working on the image creation process for Trove. The spec is up there [0]. I think is his work to kick-off that repository. Best, Victoria [0] https://review.openstack.org/#/c/295274/ 2016-05-04 23:20 GMT-03:00 Amrith Kumar mailto:amr...@tesora.com>>: As we discussed at summit, (and consistent with all of the comments) we should move ahead with the project to advance the image builder for Trove and make it easier to build guest images for Trove by leveraging the DIB elements that we have in trove-integration. To that end, the infra [1] and governance [2] changes have been submitted for review. The Launchpad tracker [3] has been registered. I am working on taking the existing DIB elements in trove-integration and putting them in the new repository (opensta
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
Pete, please clarify … I was going to push the dib elements that we currently have and you were writing CentOS elements. Is that right? Seems like there are some crossed wires here. -amrith From: Victoria Martínez de la Cruz [mailto:victo...@vmartinezdelacruz.com] Sent: Thursday, May 05, 2016 10:30 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove We agreed during the summit that we were going to amend the spec to reflect latest discussions with regards to having DIB as a primary implementation and adding support for libguestfs in parallel. The spec blueprint is named "Trove image builder" and it's about building images and not about which tool we are going to use. Thanks for creating the artifacts we need to push the code, we take it over from there. 2016-05-05 11:12 GMT-03:00 Amrith Kumar mailto:amr...@tesora.com>>: From: Victoria Martínez de la Cruz [mailto:victo...@vmartinezdelacruz.com<mailto:victo...@vmartinezdelacruz.com>] Sent: Thursday, May 05, 2016 9:00 AM To: OpenStack Development Mailing List (not for usage questions) mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove Hi all, A few things: - I agree that moving from DIB to libguestfs is a bold move and that we should try to avoid changing tools unless highly necessary. The downsides we found for DIB are detailed in this spec [0] and Ethan (in this same thread) also added valid points on the Sahara case. My concern here is, should we stick with DIB just because is the standard for image creation? Shouldn't we take in consideration that some projects, like Sahara, are moving away from it? - In the long term it would be ideal that we reach to a common solution for image creation for all the projects that need tailored images: Trove, Sahara, Octavia, Manila, and IIRC, Kolla and Cue. - In the short term, I'm on board or working on having tools based on DIB for image creation in Trove. - Amrith, Pete is working on the image creation process for Trove. The spec is up there [0]. I think is his work to kick-off that repository. [amrith] The spec [0] referenced is entitled “Separate trove image build project based on libguestfs tools”. I am working on image building using the existing DIB elements that are already part of trove-integration. In any event, please see line 220 of [0] for a detailed explanation of why I am making the repository. Best, Victoria [0] https://review.openstack.org/#/c/295274/ 2016-05-04 23:20 GMT-03:00 Amrith Kumar mailto:amr...@tesora.com>>: As we discussed at summit, (and consistent with all of the comments) we should move ahead with the project to advance the image builder for Trove and make it easier to build guest images for Trove by leveraging the DIB elements that we have in trove-integration. To that end, the infra [1] and governance [2] changes have been submitted for review. The Launchpad tracker [3] has been registered. I am working on taking the existing DIB elements in trove-integration and putting them in the new repository (openstack/trove-image-builder). I am also going to continue to watch this conversation and record any shortcomings with the existing DIB elements in Launchpad [3] and work on fixing those as well. Pete mentions one in his earlier email and I’ve logged that in Launchpad [4]. Thanks, -amrith [1] https://review.openstack.org/#/c/312805/ [2] https://review.openstack.org/#/c/312806/ [3] https://launchpad.net/trove-image-builder [4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454 From: Mariam John [mailto:mari...@us.ibm.com<mailto:mari...@us.ibm.com>] Sent: Wednesday, May 04, 2016 4:19 PM To: OpenStack Development Mailing List (not for usage questions) mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove The way I see this, these are the 2 main concerns I have been hearing regarding image building in Trove: 1) making the process simple and easy for users 2) addressing the issue of security I dont think there is any argument regarding the benefits of moving the database elements to a seperate repository and packaging and managing them from there. It looks like the case that we make for whether to use libguestfs or DIB for image building are in the technical details of how image building happens and their nuances - assuming that ease of use & having a simple interface to build secure images matters most, I wonder if the end-users would be concerned about these details. By addressing some of the issues like: - moving the Trove elements to a new repository - adding support for new distros - creating a wrapper script for building an image -get
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
In a chat on the Infra channel there was a suggestion that we create an etherpad to track issues with DIB. https://etherpad.openstack.org/p/image-generation-in-openstack I’ve created an etherpad above and populated it with some information that I have. I’ll post the etherpad on the infra IRC channel as well. Thanks, -amrith From: Michael Johnson [mailto:johnso...@gmail.com] Sent: Thursday, May 05, 2016 12:36 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove Just to chime in from an Octavia perspective as we were added to the subject. We have not had issues with DIB. There are things about the elements that could be improved, and we have been working on those over time. Currently we build the image with DIB for our scenario test runs and devstack. For images, we are investigating options to build smaller images, but again, I think DIB can support us in that and mostly it is work on elements. Michael On Thu, May 5, 2016 at 7:43 AM, Mariam John mailto:mari...@us.ibm.com>> wrote: [Inactive hide details for Victoria Martínez de la Cruz ---05/05/2016 08:12:33 AM---Hi all, A few things:]Victoria Martínez de la Cruz ---05/05/2016 08:12:33 AM---Hi all, A few things: From: Victoria Martínez de la Cruz mailto:victo...@vmartinezdelacruz.com>> To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: 05/05/2016 08:12 AM Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove Hi all, A few things: - I agree that moving from DIB to libguestfs is a bold move and that we should try to avoid changing tools unless highly necessary. The downsides we found for DIB are detailed in this spec [0] and Ethan (in this same thread) also added valid points on the Sahara case. My concern here is, should we stick with DIB just because is the standard for image creation? Shouldn't we take in consideration that some projects, like Sahara, are moving away from? I think it would be worth trying to see if DIB can address the concerns raised by the different projects around image building and improve upon that. By improving DIB, I think all these projects and OpenStack in general can benefit from it. - In the long term it would be ideal that we reach to a common solution for image creation for all the projects that need tailored images: Trove, Sahara, Octavia, Manila, and IIRC, Kolla and Cue. - In the short term, I'm on board or working on having tools based on DIB for image creation in Trove. - Amrith, Pete is working on the image creation process for Trove. The spec is up there [0]. I think is his work to kick-off that repository. Best, Victoria [0] https://review.openstack.org/#/c/295274/ 2016-05-04 23:20 GMT-03:00 Amrith Kumar mailto:amr...@tesora.com>>: As we discussed at summit, (and consistent with all of the comments) we should move ahead with the project to advance the image builder for Trove and make it easier to build guest images for Trove by leveraging the DIB elements that we have in trove-integration. To that end, the infra [1] and governance [2] changes have been submitted for review. The Launchpad tracker [3] has been registered. I am working on taking the existing DIB elements in trove-integration and putting them in the new repository (openstack/trove-image-builder). I am also going to continue to watch this conversation and record any shortcomings with the existing DIB elements in Launchpad [3] and work on fixing those as well. Pete mentions one in his earlier email and I’ve logged that in Launchpad [4]. Thanks, -amrith [1] https://review.openstack.org/#/c/312805/ [2] https://review.openstack.org/#/c/312806/ [3] https://launchpad.net/trove-image-builder [4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454 From: Mariam John [mailto:mari...@us.ibm.com<mailto:mari...@us.ibm.com>] Sent: Wednesday, May 04, 2016 4:19 PM To: OpenStack Development Mailing List (not for usage questions) mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove The way I see this, these are the 2 main concerns I have been hearing regarding image building in Trove: 1) making the process simple and easy for users 2) addressing the issue of security I dont think there is any argument regarding the benefits of moving the database elements to a seperate repository and packaging and managing them from there. It looks like the case that we make for whether to use libguestfs or DIB for image building are in the technical details of how image building happens and their nuances - assuming that ease of use & having a simple interface to
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
Just to chime in from an Octavia perspective as we were added to the subject. We have not had issues with DIB. There are things about the elements that could be improved, and we have been working on those over time. Currently we build the image with DIB for our scenario test runs and devstack. For images, we are investigating options to build smaller images, but again, I think DIB can support us in that and mostly it is work on elements. Michael On Thu, May 5, 2016 at 7:43 AM, Mariam John wrote: > [image: Inactive hide details for Victoria Martínez de la Cruz > ---05/05/2016 08:12:33 AM---Hi all, A few things:]Victoria Martínez de la > Cruz ---05/05/2016 08:12:33 AM---Hi all, A few things: > > From: Victoria Martínez de la Cruz > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: 05/05/2016 08:12 AM > Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] > discussion of image building in Trove > -- > > > > Hi all, > > A few things: > > - I agree that moving from DIB to libguestfs is a bold move and that we > should try to avoid changing tools unless highly necessary. The downsides > we found for DIB are detailed in this spec [0] and Ethan (in this same > thread) also added valid points on the Sahara case. My concern here is, > should we stick with DIB just because is the standard for image creation? > Shouldn't we take in consideration that some projects, like Sahara, are > moving away from? > > *I think it would be worth trying to see if DIB can address the concerns > raised by the different projects around image building and improve upon > that. By improving DIB, I think all these projects and OpenStack in general > can benefit from it. * > > - In the long term it would be ideal that we reach to a common solution > for image creation for all the projects that need tailored images: Trove, > Sahara, Octavia, Manila, and IIRC, Kolla and Cue. > - In the short term, I'm on board or working on having tools based on DIB > for image creation in Trove. > - Amrith, Pete is working on the image creation process for Trove. The > spec is up there [0]. I think is his work to kick-off that repository. > > Best, > > Victoria > > [0] *https://review.openstack.org/#/c/295274/* > <https://review.openstack.org/#/c/295274/> > > 2016-05-04 23:20 GMT-03:00 Amrith Kumar <*amr...@tesora.com* > >: > >As we discussed at summit, (and consistent with all of the comments) >we should move ahead with the project to advance the image builder for >Trove and make it easier to build guest images for Trove by leveraging the >DIB elements that we have in trove-integration. > > > >To that end, the infra [1] and governance [2] changes have been >submitted for review. The Launchpad tracker [3] has been registered. > > > >I am working on taking the existing DIB elements in trove-integration >and putting them in the new repository (openstack/trove-image-builder). I >am also going to continue to watch this conversation and record any >shortcomings with the existing DIB elements in Launchpad [3] and work on >fixing those as well. Pete mentions one in his earlier email and I’ve >logged that in Launchpad [4]. > > > >Thanks, > > > >-amrith > > > >[1] *https://review.openstack.org/#/c/312805/* ><https://review.openstack.org/#/c/312805/> > >[2] *https://review.openstack.org/#/c/312806/* ><https://review.openstack.org/#/c/312806/> > >[3] *https://launchpad.net/trove-image-builder* ><https://launchpad.net/trove-image-builder> > >[4] *https://bugs.launchpad.net/trove-image-builder/+bug/1578454* ><https://bugs.launchpad.net/trove-image-builder/+bug/1578454> > > > > > > > >*From:* Mariam John [mailto:*mari...@us.ibm.com* ] > * Sent:* Wednesday, May 04, 2016 4:19 PM > * To:* OpenStack Development Mailing List (not for usage questions) < >*openstack-dev@lists.openstack.org* >> > > > * Subject:* Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] >discussion of image building in Trove > > > >The way I see this, these are the 2 main concerns I have been hearing >regarding image building in Trove: >1) making the process simple and easy for users >2) addressing the issue of security > >I dont think there is any argument regarding the benefits of moving >the database elements to a seperate repository and packaging and managing >them from there. > >It looks like the case that we make for whethe
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
Hello all, I’m an Operator that has worked with DIB here for the last few months to get some working images for our Private Cloud. The only major issue I could come up with at the summit was the way grub 0.97 is treated in the bootloader element. For Centos 6, I had to find an element that could actually install grub 0.97 since when yum goes to update the kernel, it tries to update the grub config but not the extlinux config and in our cloud we need the VMs to stay updated. I’m sure the elements I have locally could be useful but the current thinking in my organization is to deprecate our Centos 6 use as quickly as possible. I’ve also run into an issue reported here [0] that makes installing a bootloader in Centos 6 a pain in either extlinux or grub 0.97. That’s really a quirk of the OS packages I’m using to build the image but still an odd situation. I’ve updated my VMs that build images to the Mitaka RDO release and with that release came the qemu-kvm-ev packages so I’m hopeful that these new packages might fix this bug. If not I’ll have to keep using Ubuntu to build my Centos 6 images. Security is a concern for sure but in my environment I have Jenkins spawn a VM in the cloud to build these images and I give these VMs enough ram to build the image in memory instead of copying the image to disk. I also have a requirement to standardize our images to using XFS for the root partition due to our flavors including a large amount of root disk. The reasoning here is that XFS resizes faster than ext4 so I would have a concern if libguestfs could not do this. It seems like I could just use DIB to fix any images that were created from your libguestfs scripts though so it might not be that much of a concern. [0]: https://bugs.launchpad.net/diskimage-builder/+bug/1477179 Peter Nordquist From: Mariam John [mailto:mari...@us.ibm.com] Sent: Thursday, May 05, 2016 07:43 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove [Inactive hide details for Victoria Martínez de la Cruz ---05/05/2016 08:12:33 AM---Hi all, A few things:]Victoria Martínez de la Cruz ---05/05/2016 08:12:33 AM---Hi all, A few things: From: Victoria Martínez de la Cruz mailto:victo...@vmartinezdelacruz.com>> To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: 05/05/2016 08:12 AM Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove Hi all, A few things: - I agree that moving from DIB to libguestfs is a bold move and that we should try to avoid changing tools unless highly necessary. The downsides we found for DIB are detailed in this spec [0] and Ethan (in this same thread) also added valid points on the Sahara case. My concern here is, should we stick with DIB just because is the standard for image creation? Shouldn't we take in consideration that some projects, like Sahara, are moving away from? I think it would be worth trying to see if DIB can address the concerns raised by the different projects around image building and improve upon that. By improving DIB, I think all these projects and OpenStack in general can benefit from it. - In the long term it would be ideal that we reach to a common solution for image creation for all the projects that need tailored images: Trove, Sahara, Octavia, Manila, and IIRC, Kolla and Cue. - In the short term, I'm on board or working on having tools based on DIB for image creation in Trove. - Amrith, Pete is working on the image creation process for Trove. The spec is up there [0]. I think is his work to kick-off that repository. Best, Victoria [0] https://review.openstack.org/#/c/295274/ 2016-05-04 23:20 GMT-03:00 Amrith Kumar mailto:amr...@tesora.com>>: As we discussed at summit, (and consistent with all of the comments) we should move ahead with the project to advance the image builder for Trove and make it easier to build guest images for Trove by leveraging the DIB elements that we have in trove-integration. To that end, the infra [1] and governance [2] changes have been submitted for review. The Launchpad tracker [3] has been registered. I am working on taking the existing DIB elements in trove-integration and putting them in the new repository (openstack/trove-image-builder). I am also going to continue to watch this conversation and record any shortcomings with the existing DIB elements in Launchpad [3] and work on fixing those as well. Pete mentions one in his earlier email and I’ve logged that in Launchpad [4]. Thanks, -amrith [1] https://review.openstack.org/#/c/312805/ [2] https://review.openstack.org/#/c/312806/ [3] https://launchpad.net/trove-image-builder [4] https://bugs.launchpad.net/trove-image-bu
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
In the scenario of Trove supporting both tools what do you expect the requirements for adding support for new databases will be? Are we expecting to have to support both tools for approval from the community? Cheers, Matt On May 5, 2016, at 10:43 AM, Mariam John mailto:mari...@us.ibm.com>> wrote: Victoria Martínez de la Cruz ---05/05/2016 08:12:33 AM---Hi all, A few things: From: Victoria Martínez de la Cruz mailto:victo...@vmartinezdelacruz.com>> To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: 05/05/2016 08:12 AM Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove Hi all, A few things: - I agree that moving from DIB to libguestfs is a bold move and that we should try to avoid changing tools unless highly necessary. The downsides we found for DIB are detailed in this spec [0] and Ethan (in this same thread) also added valid points on the Sahara case. My concern here is, should we stick with DIB just because is the standard for image creation? Shouldn't we take in consideration that some projects, like Sahara, are moving away from? I think it would be worth trying to see if DIB can address the concerns raised by the different projects around image building and improve upon that. By improving DIB, I think all these projects and OpenStack in general can benefit from it. - In the long term it would be ideal that we reach to a common solution for image creation for all the projects that need tailored images: Trove, Sahara, Octavia, Manila, and IIRC, Kolla and Cue. - In the short term, I'm on board or working on having tools based on DIB for image creation in Trove. - Amrith, Pete is working on the image creation process for Trove. The spec is up there [0]. I think is his work to kick-off that repository. Best, Victoria [0] https://review.openstack.org/#/c/295274/ 2016-05-04 23:20 GMT-03:00 Amrith Kumar mailto:amr...@tesora.com>>: As we discussed at summit, (and consistent with all of the comments) we should move ahead with the project to advance the image builder for Trove and make it easier to build guest images for Trove by leveraging the DIB elements that we have in trove-integration. To that end, the infra [1] and governance [2] changes have been submitted for review. The Launchpad tracker [3] has been registered. I am working on taking the existing DIB elements in trove-integration and putting them in the new repository (openstack/trove-image-builder). I am also going to continue to watch this conversation and record any shortcomings with the existing DIB elements in Launchpad [3] and work on fixing those as well. Pete mentions one in his earlier email and I’ve logged that in Launchpad [4]. Thanks, -amrith [1] https://review.openstack.org/#/c/312805/ [2] https://review.openstack.org/#/c/312806/ [3] https://launchpad.net/trove-image-builder [4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454 From: Mariam John [mailto:mari...@us.ibm.com<mailto:mari...@us.ibm.com>] Sent: Wednesday, May 04, 2016 4:19 PM To: OpenStack Development Mailing List (not for usage questions) mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove The way I see this, these are the 2 main concerns I have been hearing regarding image building in Trove: 1) making the process simple and easy for users 2) addressing the issue of security I dont think there is any argument regarding the benefits of moving the database elements to a seperate repository and packaging and managing them from there. It looks like the case that we make for whether to use libguestfs or DIB for image building are in the technical details of how image building happens and their nuances - assuming that ease of use & having a simple interface to build secure images matters most, I wonder if the end-users would be concerned about these details. By addressing some of the issues like: - moving the Trove elements to a new repository - adding support for new distros - creating a wrapper script for building an image -getting the Trove guest agent code & configuration files - managing environment variables better I believe it will make a huge improvement in terms of simplifying and improving the ease of use for end users and hence could be the low hanging fruit that we can implement in the mean time. I agree that switching from DIB to any other tool is a big step and we need to put alot of thought into it like many others have suggested. Like Pete mentioned earlier in one of the links, there are couple of other tools available for building images. I am sure we could make the case for each of these tools and how it is easier/faster/better than the others.
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
From: Victoria Martínez de la Cruz
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 05/05/2016 08:12 AM
Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
discussion of image building in Trove
Hi all,
A few things:
- I agree that moving from DIB to libguestfs is a bold move and that we
should try to avoid changing tools unless highly necessary. The downsides
we found for DIB are detailed in this spec [0] and Ethan (in this same
thread) also added valid points on the Sahara case. My concern here is,
should we stick with DIB just because is the standard for image creation?
Shouldn't we take in consideration that some projects, like Sahara, are
moving away from?
I think it would be worth trying to see if DIB can address the concerns
raised by the different projects around image building and improve upon
that. By improving DIB, I think all these projects and OpenStack in general
can benefit from it.
- In the long term it would be ideal that we reach to a common solution for
image creation for all the projects that need tailored images: Trove,
Sahara, Octavia, Manila, and IIRC, Kolla and Cue.
- In the short term, I'm on board or working on having tools based on DIB
for image creation in Trove.
- Amrith, Pete is working on the image creation process for Trove. The spec
is up there [0]. I think is his work to kick-off that repository.
Best,
Victoria
[0] https://review.openstack.org/#/c/295274/
2016-05-04 23:20 GMT-03:00 Amrith Kumar :
As we discussed at summit, (and consistent with all of the comments) we
should move ahead with the project to advance the image builder for Trove
and make it easier to build guest images for Trove by leveraging the DIB
elements that we have in trove-integration.
To that end, the infra [1] and governance [2] changes have been submitted
for review. The Launchpad tracker [3] has been registered.
I am working on taking the existing DIB elements in trove-integration and
putting them in the new repository (openstack/trove-image-builder). I am
also going to continue to watch this conversation and record any
shortcomings with the existing DIB elements in Launchpad [3] and work on
fixing those as well. Pete mentions one in his earlier email and I’ve
logged that in Launchpad [4].
Thanks,
-amrith
[1] https://review.openstack.org/#/c/312805/
[2] https://review.openstack.org/#/c/312806/
[3] https://launchpad.net/trove-image-builder
[4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454
From: Mariam John [mailto:mari...@us.ibm.com]
Sent: Wednesday, May 04, 2016 4:19 PM
To: OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
discussion of image building in Trove
The way I see this, these are the 2 main concerns I have been hearing
regarding image building in Trove:
1) making the process simple and easy for users
2) addressing the issue of security
I dont think there is any argument regarding the benefits of moving the
database elements to a seperate repository and packaging and managing
them from there.
It looks like the case that we make for whether to use libguestfs or DIB
for image building are in the technical details of how image building
happens and their nuances - assuming that ease of use & having a simple
interface to build secure images matters most, I wonder if the end-users
would be concerned about these details.
By addressing some of the issues like:
- moving the Trove elements to a new repository
- adding support for new distros
- creating a wrapper script for building an image -getting the Trove
guest agent code & configuration files
- managing environment variables better
I believe it will make a huge improvement in terms of simplifying and
improving the ease of use for end users and hence could be the low
hanging fruit that we can implement in the mean time. I agree that
switching from DIB to any other tool is a big step and we need to put
alot of thought into it like many others have suggested. Like Pete
mentioned earlier in one of the links, there are couple of other tools
available for building images. I am sure we could make the case for each
of these tools and how it is easier/faster/better than the others. If we
go down this route experimenting with libguestfs, is there anything
stopping us couple of releases down the lane from wanting to experiment
with some other tool because libguestfs doesn't perform well? The end
user could use any tool they want to use to create images if they wish to
do so but I agree and believe that Trove should support a standard way of
building images (DIB being an OpenStack project, I would assume that
would be the standar
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
We agreed during the summit that we were going to amend the spec to reflect latest discussions with regards to having DIB as a primary implementation and adding support for libguestfs in parallel. The spec blueprint is named "Trove image builder" and it's about building images and not about which tool we are going to use. Thanks for creating the artifacts we need to push the code, we take it over from there. 2016-05-05 11:12 GMT-03:00 Amrith Kumar : > > > *From:* Victoria Martínez de la Cruz [mailto: > victo...@vmartinezdelacruz.com] > *Sent:* Thursday, May 05, 2016 9:00 AM > *To:* OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > *Subject:* Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] > discussion of image building in Trove > > > > Hi all, > > > > A few things: > > > > - I agree that moving from DIB to libguestfs is a bold move and that we > should try to avoid changing tools unless highly necessary. The downsides > we found for DIB are detailed in this spec [0] and Ethan (in this same > thread) also added valid points on the Sahara case. My concern here is, > should we stick with DIB just because is the standard for image creation? > Shouldn't we take in consideration that some projects, like Sahara, are > moving away from it? > > - In the long term it would be ideal that we reach to a common solution > for image creation for all the projects that need tailored images: Trove, > Sahara, Octavia, Manila, and IIRC, Kolla and Cue. > > - In the short term, I'm on board or working on having tools based on DIB > for image creation in Trove. > > - Amrith, Pete is working on the image creation process for Trove. The > spec is up there [0]. I think is his work to kick-off that repository. > > *[amrith] The spec [0] referenced is entitled “Separate trove image build > project based on libguestfs tools”. I am working on image building using > the existing DIB elements that are already part of trove-integration. In > any event, please see line 220 of [0] for a detailed explanation of why I > am making the repository.* > > > > Best, > > > > Victoria > > > > [0] https://review.openstack.org/#/c/295274/ > > > > 2016-05-04 23:20 GMT-03:00 Amrith Kumar : > > As we discussed at summit, (and consistent with all of the comments) we > should move ahead with the project to advance the image builder for Trove > and make it easier to build guest images for Trove by leveraging the DIB > elements that we have in trove-integration. > > > > To that end, the infra [1] and governance [2] changes have been submitted > for review. The Launchpad tracker [3] has been registered. > > > > I am working on taking the existing DIB elements in trove-integration and > putting them in the new repository (openstack/trove-image-builder). I am > also going to continue to watch this conversation and record any > shortcomings with the existing DIB elements in Launchpad [3] and work on > fixing those as well. Pete mentions one in his earlier email and I’ve > logged that in Launchpad [4]. > > > > Thanks, > > > > -amrith > > > > [1] https://review.openstack.org/#/c/312805/ > > [2] https://review.openstack.org/#/c/312806/ > > [3] https://launchpad.net/trove-image-builder > > [4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454 > > > > > > > > *From:* Mariam John [mailto:mari...@us.ibm.com] > *Sent:* Wednesday, May 04, 2016 4:19 PM > *To:* OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > > > *Subject:* Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] > discussion of image building in Trove > > > > The way I see this, these are the 2 main concerns I have been hearing > regarding image building in Trove: > 1) making the process simple and easy for users > 2) addressing the issue of security > > I dont think there is any argument regarding the benefits of moving the > database elements to a seperate repository and packaging and managing them > from there. > > It looks like the case that we make for whether to use libguestfs or DIB > for image building are in the technical details of how image building > happens and their nuances - assuming that ease of use & having a simple > interface to build secure images matters most, I wonder if the end-users > would be concerned about these details. > > By addressing some of the issues like: > - moving the Trove elements to a new repository > - adding support for new distros > - creating a wrapper script for building an image -getting the T
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
From: Victoria Martínez de la Cruz [mailto:victo...@vmartinezdelacruz.com] Sent: Thursday, May 05, 2016 9:00 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove Hi all, A few things: - I agree that moving from DIB to libguestfs is a bold move and that we should try to avoid changing tools unless highly necessary. The downsides we found for DIB are detailed in this spec [0] and Ethan (in this same thread) also added valid points on the Sahara case. My concern here is, should we stick with DIB just because is the standard for image creation? Shouldn't we take in consideration that some projects, like Sahara, are moving away from it? - In the long term it would be ideal that we reach to a common solution for image creation for all the projects that need tailored images: Trove, Sahara, Octavia, Manila, and IIRC, Kolla and Cue. - In the short term, I'm on board or working on having tools based on DIB for image creation in Trove. - Amrith, Pete is working on the image creation process for Trove. The spec is up there [0]. I think is his work to kick-off that repository. [amrith] The spec [0] referenced is entitled “Separate trove image build project based on libguestfs tools”. I am working on image building using the existing DIB elements that are already part of trove-integration. In any event, please see line 220 of [0] for a detailed explanation of why I am making the repository. Best, Victoria [0] https://review.openstack.org/#/c/295274/ 2016-05-04 23:20 GMT-03:00 Amrith Kumar mailto:amr...@tesora.com>>: As we discussed at summit, (and consistent with all of the comments) we should move ahead with the project to advance the image builder for Trove and make it easier to build guest images for Trove by leveraging the DIB elements that we have in trove-integration. To that end, the infra [1] and governance [2] changes have been submitted for review. The Launchpad tracker [3] has been registered. I am working on taking the existing DIB elements in trove-integration and putting them in the new repository (openstack/trove-image-builder). I am also going to continue to watch this conversation and record any shortcomings with the existing DIB elements in Launchpad [3] and work on fixing those as well. Pete mentions one in his earlier email and I’ve logged that in Launchpad [4]. Thanks, -amrith [1] https://review.openstack.org/#/c/312805/ [2] https://review.openstack.org/#/c/312806/ [3] https://launchpad.net/trove-image-builder [4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454 From: Mariam John [mailto:mari...@us.ibm.com<mailto:mari...@us.ibm.com>] Sent: Wednesday, May 04, 2016 4:19 PM To: OpenStack Development Mailing List (not for usage questions) mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove The way I see this, these are the 2 main concerns I have been hearing regarding image building in Trove: 1) making the process simple and easy for users 2) addressing the issue of security I dont think there is any argument regarding the benefits of moving the database elements to a seperate repository and packaging and managing them from there. It looks like the case that we make for whether to use libguestfs or DIB for image building are in the technical details of how image building happens and their nuances - assuming that ease of use & having a simple interface to build secure images matters most, I wonder if the end-users would be concerned about these details. By addressing some of the issues like: - moving the Trove elements to a new repository - adding support for new distros - creating a wrapper script for building an image -getting the Trove guest agent code & configuration files - managing environment variables better I believe it will make a huge improvement in terms of simplifying and improving the ease of use for end users and hence could be the low hanging fruit that we can implement in the mean time. I agree that switching from DIB to any other tool is a big step and we need to put alot of thought into it like many others have suggested. Like Pete mentioned earlier in one of the links, there are couple of other tools available for building images. I am sure we could make the case for each of these tools and how it is easier/faster/better than the others. If we go down this route experimenting with libguestfs, is there anything stopping us couple of releases down the lane from wanting to experiment with some other tool because libguestfs doesn't perform well? The end user could use any tool they want to use to create images if they wish to do so but I agree and believe that Trove should support a standard way of building images (DIB being an OpenStack project, I
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
>
> The approach being proposed by Pete is something that is equally
> applicable to DIB, I think. I believe that he makes a valid observation
> and our current element design may in fact be bad.
>
> The invocation of DIB[1] is
>
> ${PATH_DISKIMAGEBUILDER}/bin/disk-image-create -a amd64 -o "${VM}" \
> -x ${QEMU_IMG_OPTIONS} ${DISTRO} ${EXTRA_ELEMENTS} vm
> heat-cfntools \
> cloud-init-datasources ${DISTRO}-guest ${DISTRO}-${SERVICE_TYPE}
>
> Observe that we include the ${DISTRO} element, and we prefix ${DISTRO}
> into the name of the guest and the database to get, for example,
>
> ... ubuntu ubuntu-guest ubuntu-mysql
>
> The minimal set of bash and data files could be used instead and we won't
> have this matrix of datastore-by-distro proliferation that you speak of.
> That's why I believe that this solution is equally applicable to DIB.
>
> [1] trove-integration/scripts/files/functions_qemu
>
Ah, yep - the typical pattern for elements which are not distro elements
is to not make the distro part of the element name and then have the
element itself use the provided tools as much as possible to perform
tasks in a distro-agnostic fashion (see the package-installs element for
an example tool).
Thanks,
Greg
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
Hi all, A few things: - I agree that moving from DIB to libguestfs is a bold move and that we should try to avoid changing tools unless highly necessary. The downsides we found for DIB are detailed in this spec [0] and Ethan (in this same thread) also added valid points on the Sahara case. My concern here is, should we stick with DIB just because is the standard for image creation? Shouldn't we take in consideration that some projects, like Sahara, are moving away from it? - In the long term it would be ideal that we reach to a common solution for image creation for all the projects that need tailored images: Trove, Sahara, Octavia, Manila, and IIRC, Kolla and Cue. - In the short term, I'm on board or working on having tools based on DIB for image creation in Trove. - Amrith, Pete is working on the image creation process for Trove. The spec is up there [0]. I think is his work to kick-off that repository. Best, Victoria [0] https://review.openstack.org/#/c/295274/ 2016-05-04 23:20 GMT-03:00 Amrith Kumar : > As we discussed at summit, (and consistent with all of the comments) we > should move ahead with the project to advance the image builder for Trove > and make it easier to build guest images for Trove by leveraging the DIB > elements that we have in trove-integration. > > > > To that end, the infra [1] and governance [2] changes have been submitted > for review. The Launchpad tracker [3] has been registered. > > > > I am working on taking the existing DIB elements in trove-integration and > putting them in the new repository (openstack/trove-image-builder). I am > also going to continue to watch this conversation and record any > shortcomings with the existing DIB elements in Launchpad [3] and work on > fixing those as well. Pete mentions one in his earlier email and I’ve > logged that in Launchpad [4]. > > > > Thanks, > > > > -amrith > > > > [1] https://review.openstack.org/#/c/312805/ > > [2] https://review.openstack.org/#/c/312806/ > > [3] https://launchpad.net/trove-image-builder > > [4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454 > > > > > > > > *From:* Mariam John [mailto:mari...@us.ibm.com] > *Sent:* Wednesday, May 04, 2016 4:19 PM > *To:* OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > > *Subject:* Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] > discussion of image building in Trove > > > > The way I see this, these are the 2 main concerns I have been hearing > regarding image building in Trove: > 1) making the process simple and easy for users > 2) addressing the issue of security > > I dont think there is any argument regarding the benefits of moving the > database elements to a seperate repository and packaging and managing them > from there. > > It looks like the case that we make for whether to use libguestfs or DIB > for image building are in the technical details of how image building > happens and their nuances - assuming that ease of use & having a simple > interface to build secure images matters most, I wonder if the end-users > would be concerned about these details. > > By addressing some of the issues like: > - moving the Trove elements to a new repository > - adding support for new distros > - creating a wrapper script for building an image -getting the Trove guest > agent code & configuration files > - managing environment variables better > > I believe it will make a huge improvement in terms of simplifying and > improving the ease of use for end users and hence could be the low hanging > fruit that we can implement in the mean time. I agree that switching from > DIB to any other tool is a big step and we need to put alot of thought into > it like many others have suggested. Like Pete mentioned earlier in one of > the links, there are couple of other tools available for building images. I > am sure we could make the case for each of these tools and how it is > easier/faster/better than the others. If we go down this route > experimenting with libguestfs, is there anything stopping us couple of > releases down the lane from wanting to experiment with some other tool > because libguestfs doesn't perform well? The end user could use any tool > they want to use to create images if they wish to do so but I agree and > believe that Trove should support a standard way of building images (DIB > being an OpenStack project, I would assume that would be the standard) and > do it well keeping it simple and easy to use as opposed to what it is > today. > > I think we should split this into 2 tasks > - one for going forward with seperating image building into a seperate > repository and putting
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
As we discussed at summit, (and consistent with all of the comments) we should move ahead with the project to advance the image builder for Trove and make it easier to build guest images for Trove by leveraging the DIB elements that we have in trove-integration. To that end, the infra [1] and governance [2] changes have been submitted for review. The Launchpad tracker [3] has been registered. I am working on taking the existing DIB elements in trove-integration and putting them in the new repository (openstack/trove-image-builder). I am also going to continue to watch this conversation and record any shortcomings with the existing DIB elements in Launchpad [3] and work on fixing those as well. Pete mentions one in his earlier email and I've logged that in Launchpad [4]. Thanks, -amrith [1] https://review.openstack.org/#/c/312805/ [2] https://review.openstack.org/#/c/312806/ [3] https://launchpad.net/trove-image-builder [4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454 From: Mariam John [mailto:mari...@us.ibm.com] Sent: Wednesday, May 04, 2016 4:19 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove The way I see this, these are the 2 main concerns I have been hearing regarding image building in Trove: 1) making the process simple and easy for users 2) addressing the issue of security I dont think there is any argument regarding the benefits of moving the database elements to a seperate repository and packaging and managing them from there. It looks like the case that we make for whether to use libguestfs or DIB for image building are in the technical details of how image building happens and their nuances - assuming that ease of use & having a simple interface to build secure images matters most, I wonder if the end-users would be concerned about these details. By addressing some of the issues like: - moving the Trove elements to a new repository - adding support for new distros - creating a wrapper script for building an image -getting the Trove guest agent code & configuration files - managing environment variables better I believe it will make a huge improvement in terms of simplifying and improving the ease of use for end users and hence could be the low hanging fruit that we can implement in the mean time. I agree that switching from DIB to any other tool is a big step and we need to put alot of thought into it like many others have suggested. Like Pete mentioned earlier in one of the links, there are couple of other tools available for building images. I am sure we could make the case for each of these tools and how it is easier/faster/better than the others. If we go down this route experimenting with libguestfs, is there anything stopping us couple of releases down the lane from wanting to experiment with some other tool because libguestfs doesn't perform well? The end user could use any tool they want to use to create images if they wish to do so but I agree and believe that Trove should support a standard way of building images (DIB being an OpenStack project, I would assume that would be the standard) and do it well keeping it simple and easy to use as opposed to what it is today. I think we should split this into 2 tasks - one for going forward with seperating image building into a seperate repository and putting all efforts into simplifying the current process, and - second, to have a joint collaboration with the DIB/TripleO team to raise concerns regarding DIB and see if we can address them in turn OR if using a different tool like libguestfs makes sense at that point. Thanks, Mariam. [Inactive hide details for Peter MacKinnon ---05/04/2016 12:39:15 PM---On 5/4/16 12:52 PM, Gregory Haynes wrote: > On Wed, May 4]Peter MacKinnon ---05/04/2016 12:39:15 PM---On 5/4/16 12:52 PM, Gregory Haynes wrote: > On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote: From: Peter MacKinnon mailto:pmack...@redhat.com>> To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org> Date: 05/04/2016 12:39 PM Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove On 5/4/16 12:52 PM, Gregory Haynes wrote: > On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote: >> On 04/05/16 15:05 +, Amrith Kumar wrote: >>> I'm emailing the ML on the subject of a review ongoing in the Trove project >>> regarding image building[1]. >>> >>> TL;DR >>> >>> One of the most frequent questions that new users of Trove ask is how and >>> where to get guest images with which to experiment with Trove, and how to >>> build these images for themselves. While documentation about this exists in >>> multiple
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
The way I see this, these are the 2 main concerns I have been hearing
regarding image building in Trove:
1) making the process simple and easy for users
2) addressing the issue of security
I dont think there is any argument regarding the benefits of moving the
database elements to a seperate repository and packaging and managing them
from there.
It looks like the case that we make for whether to use libguestfs or DIB
for image building are in the technical details of how image building
happens and their nuances - assuming that ease of use & having a simple
interface to build secure images matters most, I wonder if the end-users
would be concerned about these details.
By addressing some of the issues like:
- moving the Trove elements to a new repository
- adding support for new distros
- creating a wrapper script for building an image -getting the Trove
guest agent code & configuration files
- managing environment variables better
I believe it will make a huge improvement in terms of simplifying and
improving the ease of use for end users and hence could be the low hanging
fruit that we can implement in the mean time. I agree that switching from
DIB to any other tool is a big step and we need to put alot of thought into
it like many others have suggested. Like Pete mentioned earlier in one of
the links, there are couple of other tools available for building images. I
am sure we could make the case for each of these tools and how it is
easier/faster/better than the others. If we go down this route
experimenting with libguestfs, is there anything stopping us couple of
releases down the lane from wanting to experiment with some other tool
because libguestfs doesn't perform well? The end user could use any tool
they want to use to create images if they wish to do so but I agree and
believe that Trove should support a standard way of building images (DIB
being an OpenStack project, I would assume that would be the standard) and
do it well keeping it simple and easy to use as opposed to what it is
today.
I think we should split this into 2 tasks
- one for going forward with seperating image building into a seperate
repository and putting all efforts into simplifying the current process,
and
- second, to have a joint collaboration with the DIB/TripleO team to
raise concerns regarding DIB and see if we can address them in turn OR if
using a different tool like libguestfs makes sense at that point.
Thanks,
Mariam.
From: Peter MacKinnon
To: openstack-dev@lists.openstack.org
Date: 05/04/2016 12:39 PM
Subject:Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
discussion of image building in Trove
On 5/4/16 12:52 PM, Gregory Haynes wrote:
> On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote:
>> On 04/05/16 15:05 +, Amrith Kumar wrote:
>>> I'm emailing the ML on the subject of a review ongoing in the Trove
project regarding image building[1].
>>>
>>> TL;DR
>>>
>>> One of the most frequent questions that new users of Trove ask is how
and where to get guest images with which to experiment with Trove, and how
to build these images for themselves. While documentation about this exists
in multiple places (including [2], [3]) this is still something that can do
with some improvement.
>>>
>>> Trove currently uses diskimage-builder for building images used in
testing the product and these can serve as a good basis for anyone wishing
to build an image for their own use of Trove. The review [1] makes the
argument for the libguestfs based approach to building images and advocates
that Trove should use this instead of diskimage-builder.
>> At the summit we discussed the possibility of providing an
implementation
>> that
>> would allow for both DIB and libguestfs to be used but to give priority
>> to DIB.
>> Since there's no real intention of just switching tools at this point, I
>> believe
>> it'd be good to amend the spec so that it doesn't mention libguestfs
>> should be
>> used instead of DiB.
>>
>> The goal at this stage is to provide both and help these move forward.
>>
>>> I believe that a broader discussion of this is required and I
appreciate Greg Haynes' proposal at the design summit to have this
discussion on the ML. I took the action item to bring this discussion to
the ML.
>>>
>>> Details follow ...
>>>
>>> Before going further, I will state my views on these matters.
>>>
>>> 1. It is important for the Trove project to do things quickly to make
it easier for end users who wish to use Trove and who wish to build their
own images. I am not concerned what tool or tools a person will use to
build these images.
> ++. One of the biggest issues I see users of DIB hit is ease of use for
> 'just make me an
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
> -Original Message-
> From: Gregory Haynes [mailto:g...@greghaynes.net]
> Sent: Wednesday, May 04, 2016 3:52 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
> discussion of image building in Trove
>
> On Wed, May 4, 2016, at 10:33 AM, Peter MacKinnon wrote:
> >
> > Well, certainly one downside in the case of Trove (and probably
> > elsewhere) with DIB is the src tree matrix of datastore-by-distro
> > elements required to support various guest image combinations, leading
> > to a proliferation of directories and files. We feel this can be greatly
> > simplified using a libguestfs approach using a minimal set of bash and
> > directly applicable data files (e.g., systemd unit files, conf files,
> > etc.).
> >
>
> I am confused by this, so maybe I am just misunderstanding. Are you
> saying that DIB requires you to support more distro combinations? What
> combination of distros you support is entirely up to trove as a
> downstream and has absolutely nothing to do with the image build tool,
> or maybe you mean something else?
>
The approach being proposed by Pete is something that is equally applicable to
DIB, I think. I believe that he makes a valid observation and our current
element design may in fact be bad.
The invocation of DIB[1] is
${PATH_DISKIMAGEBUILDER}/bin/disk-image-create -a amd64 -o "${VM}" \
-x ${QEMU_IMG_OPTIONS} ${DISTRO} ${EXTRA_ELEMENTS} vm heat-cfntools \
cloud-init-datasources ${DISTRO}-guest ${DISTRO}-${SERVICE_TYPE}
Observe that we include the ${DISTRO} element, and we prefix ${DISTRO} into the
name of the guest and the database to get, for example,
... ubuntu ubuntu-guest ubuntu-mysql
The minimal set of bash and data files could be used instead and we won't have
this matrix of datastore-by-distro proliferation that you speak of. That's why
I believe that this solution is equally applicable to DIB.
[1] trove-integration/scripts/files/functions_qemu
> > >
> > > What seemed very apparent to me in the summit session is that there
> are
> > > a set of issues for Trove relating to image building, mostly relating
> to
> > > reliability and ease of use. There was no one who even mentioned let
> > > alone strongly cared about the issues which actually differentiate the
> > > existing DIB build process from libguestfs (which is isolation). If
> that
> > > has changed for some reason, then my recommendation would be to use a
> > > tool like virt-dib which will allow for a single image building code
> > > base while solving all the raised issues in the spec. I suspect when
> > > this is tried out the downsides to booting a VM will highly outweigh
> the
> > > benefits for almost all users (especially in trove's gate),
> >
> > Anecdotally, it takes the same amount of time for a CentOS7 MySQL build
> > (~ 7 minutes) with either toolchain.
> >
>
> I suspect this is actually "about the same amount of time with hardware
> virtualization", which the gate does not have. Otherwise, awesome - lets
> just use virt-dib / a libguestfs backend for DIB then.
>
> > > but if the
> > > libguestfs docs are to be believed this should be trivial to try out.
> >
> > Not quite sure what you mean by "to be believed"?
> >
>
> Just that it seems trivial to try out and there's no downsides
> mentioned.
>
> >
> > The various image building frameworks have been noted here
> > http://docs.openstack.org/image-guide/create-images-automatically.html
> > including libguestfs. So it's not like it is an unknown quantity. In the
> > interest of innovation I'm not sure I understand the hearty reluctance
> > to explore this path. We are proposing simply another Trove repo with an
> > alternate (and recognized) image build method. This is not displacing
> > any established tool for Trove; such a tool doesn't exist today. The
> > elements in trove-integration don't really count since they are largely
> > developed for Ubuntu only, inject Trove guestagent src from git only,
> > and, beyond MySQL 5.6, are not tested by the gate.
> >
>
> The reluctance is that, as you say, the existing set of scripts have
> deficiencies that need to be fixed. Rather than fix them, we are going
> to put effort in to rewriting them to use another tool which does not
> help the existing deficiencies. Distro support is still just as much of
> a trove issue as it is now - its up to the trove scripts to support the
> various distros. It seems a lot more
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
On Wed, May 4, 2016, at 10:33 AM, Peter MacKinnon wrote: > > Well, certainly one downside in the case of Trove (and probably > elsewhere) with DIB is the src tree matrix of datastore-by-distro > elements required to support various guest image combinations, leading > to a proliferation of directories and files. We feel this can be greatly > simplified using a libguestfs approach using a minimal set of bash and > directly applicable data files (e.g., systemd unit files, conf files, > etc.). > I am confused by this, so maybe I am just misunderstanding. Are you saying that DIB requires you to support more distro combinations? What combination of distros you support is entirely up to trove as a downstream and has absolutely nothing to do with the image build tool, or maybe you mean something else? > > > > What seemed very apparent to me in the summit session is that there are > > a set of issues for Trove relating to image building, mostly relating to > > reliability and ease of use. There was no one who even mentioned let > > alone strongly cared about the issues which actually differentiate the > > existing DIB build process from libguestfs (which is isolation). If that > > has changed for some reason, then my recommendation would be to use a > > tool like virt-dib which will allow for a single image building code > > base while solving all the raised issues in the spec. I suspect when > > this is tried out the downsides to booting a VM will highly outweigh the > > benefits for almost all users (especially in trove's gate), > > Anecdotally, it takes the same amount of time for a CentOS7 MySQL build > (~ 7 minutes) with either toolchain. > I suspect this is actually "about the same amount of time with hardware virtualization", which the gate does not have. Otherwise, awesome - lets just use virt-dib / a libguestfs backend for DIB then. > > but if the > > libguestfs docs are to be believed this should be trivial to try out. > > Not quite sure what you mean by "to be believed"? > Just that it seems trivial to try out and there's no downsides mentioned. > > The various image building frameworks have been noted here > http://docs.openstack.org/image-guide/create-images-automatically.html > including libguestfs. So it's not like it is an unknown quantity. In the > interest of innovation I'm not sure I understand the hearty reluctance > to explore this path. We are proposing simply another Trove repo with an > alternate (and recognized) image build method. This is not displacing > any established tool for Trove; such a tool doesn't exist today. The > elements in trove-integration don't really count since they are largely > developed for Ubuntu only, inject Trove guestagent src from git only, > and, beyond MySQL 5.6, are not tested by the gate. > The reluctance is that, as you say, the existing set of scripts have deficiencies that need to be fixed. Rather than fix them, we are going to put effort in to rewriting them to use another tool which does not help the existing deficiencies. Distro support is still just as much of a trove issue as it is now - its up to the trove scripts to support the various distros. It seems a lot more reasonable to fix the problems in the scripts rather than rewrite to use another tool given that the problems mentioned have nothing to do with the image building tool. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
On 2016-05-04 09:52:20 -0700 (-0700), Gregory Haynes wrote: [...] > One of the biggest issues I see users of DIB hit is ease of use > for 'just make me an image, I don't care about twiddling knobs'. A > wrapper script in trove is one way to help with this [...] For example, in openstack-infra/project-config we ship a wrapper along these lines: http://git.openstack.org/cgit/openstack-infra/project-config/tree/tools/build-image.sh -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
On Wed, May 4, 2016, at 09:57 AM, Ethan Gafford wrote: > > Sahara has support for several image generation-related cases: > 1) Packing an image pre-cluster spawn in Nova. > 2) Building clusters from a "clean" OS image post-Nova spawn, by >downloading and installing Hadoop/Spark/Storm/WhatHaveYou. > 3) Validating images after Nova spawn (to ensure that they're up to >spec for the plugin in question.) > Because of this, we are pulling image generation logic into the > plugins themselves, from a monolithic sahara-image-elements > repository. This will aid us in our eventual hope to pull plugins > out of the Sahara tree entirely; more immediately, it will allow us > to define logic for all of these cases in one place, written > eventually in Python. In our Sahara session at summit, which was > also attended by several members of the Ironic team (thanks all), we > discussed our current plan to use libguestfs rather than DIB as our > toolchain; our intent to define a linear, idempotent set of steps to > pack images for any plugin lends itself much more neatly to > libguestfs' API than to DIB's. Ok, there is clearly some kind of communication breakdown between DIB and some of its users that we *really* need to solve. AFAIK the primary set of DIB developers had no idea this was going on. I am going to push up a patch to our docs to make it a lot more clear where to find us (#tripleo or the ML). I'm not really sure what else we could do to make it easier for users to find us / raise issues with us so we can explore ways to solve them, but any suggestions would be a huge help. The idea that a linear set of idempotent steps is mutually exclusive with DIB's API is really interesting. IIUC this is something we grappled with in TripleO when creating the tool and simply never spent time looking in to solving for the existing distro elements, although that is an element issue not an API issue. DIB's API is just a linear set of commands you opt in to (by way of elements), if you make those commands idempotent then you have what you want, the problem is that the upstream element's themselves are not written in that way so you couldn't depend on them. I think there are some pretty obvious ways to solve this, potentially by making an element which provides the same API as libguestfs virt-customize (this would be very simple to do, I just haven't heard of anyone wanting it) or by hacking on some of the in-tree elements. Could you go in to some more detail on how you use this feature? > Beyond that, the Sahara team has certainly seen profound difficulty in > the field when customers attempt to generate their own images, and > even for Sahara cores, building images is occasionally quite > harrowing. These issues are seldom based on real issues in the scripts > themselves, but are frequently the result of bleed between the host > and guest; when these issues occur for a customer, they become > extremely difficult to diagnose remotely. Still, it's entirely > possible that DIB has answers to these problems, and it'd be a > universal good to identify real flaws in DIB, or just to educate the > uninitiated into how DIB can be made to work more cleanly if the > features are already there (which they may well be; far be it from me > to claim exhaustive mastery of DIB.) The technical reasons we like > libguestfs over DIB are: It would be *extremely* helpful to know about these issues when they come up. There's definitely some things we can do to prevent this but again, there hasn't been a lot of feedback that this is an issue people are running in to. There's a few different ways to prevent these types of problems ranging from doing something like virt-dib to having dib use another chroot during the image building process but I would really like to hear about some specific issues to get a better idea of what the root cause is. Hopefully we could even get these filed as bugs. > 1) Libguestfs manipulates images in a clean helper VM created by >libguestfs in a predictable way. As such, no mounts are made on the >host, no scripts can affect the host system, and no variables on >the host system are likely to affect the image packing process. See >http://libguestfs.org/guestfs-security.1.html for information on >libguestfs security. Yep, isolation is definitely something DIB currently gives up in order to provide speed/lower resource usage. That being said, there are lots of things that could be done to either mitigate these issues or remove them altogether (by compromising on speed/resource requirements). My biggest concern is that we are creating two sets of code to perform the same task due to a false dichotomy - the obvious case being that at a minimum we could still be using something compatible with DIB while utilizing a vm/libguestfs. This would then have the benefits of having a common toolset among the community without the raised issues. > 2) In-place image manipulation means that relativ
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
On 04/05/16 09:46 -0700, Clark Boylan wrote: On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote: On 04/05/16 15:05 +, Amrith Kumar wrote: >I'm emailing the ML on the subject of a review ongoing in the Trove project regarding image building[1]. > >TL;DR > >One of the most frequent questions that new users of Trove ask is how and where to get guest images with which to experiment with Trove, and how to build these images for themselves. While documentation about this exists in multiple places (including [2], [3]) this is still something that can do with some improvement. > >Trove currently uses diskimage-builder for building images used in testing the product and these can serve as a good basis for anyone wishing to build an image for their own use of Trove. The review [1] makes the argument for the libguestfs based approach to building images and advocates that Trove should use this instead of diskimage-builder. At the summit we discussed the possibility of providing an implementation that would allow for both DIB and libguestfs to be used but to give priority to DIB. Since there's no real intention of just switching tools at this point, I believe it'd be good to amend the spec so that it doesn't mention libguestfs should be used instead of DiB. The goal at this stage is to provide both and help these move forward. I disagree, as someone that has tried and failed in the past to build trove images the goal should be to make that process easy for the user. Maybe we can finally get rid of redstack years after it was supposed to go away. Well, that's part of what the spec under discussion is going to address. Pulling out the DiB bits out of trove-integration aims to provide a way for users to build their images. The priority is to get this to a state where users can build images easily and then work in parallel on adding support for an alternative. This is what was said in the Trove session last week. >I believe that a broader discussion of this is required and I appreciate Greg Haynes' proposal at the design summit to have this discussion on the ML. I took the action item to bring this discussion to the ML. > >Details follow ... > >Before going further, I will state my views on these matters. > >1. It is important for the Trove project to do things quickly to make it easier for end users who wish to use Trove and who wish to build their own images. I am not concerned what tool or tools a person will use to build these images. > >2. If we provide multiple alternatives to image building as part of the Trove project, we should make sure that images built with all sets of tools are equivalent and usable interchangeably. Failing to do this will make it harder for users to use Trove because we will be providing them with a false choice (i.e. the alternatives aren't really alternatives). This is harder than it sounds given the combination of tools, operating systems, and the source(s) from which you can get database software. Maintaining both in the long run will be harder especially because, as you mentioned, the output must be usable interchangeably. However, I think we're at a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano and some other folks that it'd be beneficial for us to have this discussion and to also experiment/test other options. The Sahara team seems to be going in a direction that differs with the one used by the infra team and the one we're headed to (although they overlap in some areas). Has Sahara expressed their needs somewhere too? This is the first I am hearing of them having trouble with image builds (I had thought they were using DIB successfully). I believe Ethan has replied to this in another email. >3. Trove already has elements for all supported databases using DIB in the trove-integration project but these elements are not packaged for customer use. Making them usable by customers is a relatively small effort including providing a wrapper script (derived from redstack[4]) and providing an element to install the guest agent software from a fixed location in addition to the development and testing version that is better suited to Trove development [5] and [6]. > >4. My comments on various patch sets in the review[1]. > >I agree with Monty and Greg Haynes that we should understand the deficiencies if any in DIB, and if it is in fact the case that they are "intractable/unsolvable", we should switch toolchains. This discussion should include issues faced by the Trove team as well as other teams that may have faced problems with DIB (such as the sahara team who described some of them in the past). ++ Agreed with the above. I'm think collaboration should be the preferred way. I don't think I've enough technical insight on this topic to provide a detailed list of things that are good/bad on either of these tools but I wanted to mention that I believe providing support for both in the short run is good for us and it
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
On 5/4/16 12:52 PM, Gregory Haynes wrote: On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote: On 04/05/16 15:05 +, Amrith Kumar wrote: I'm emailing the ML on the subject of a review ongoing in the Trove project regarding image building[1]. TL;DR One of the most frequent questions that new users of Trove ask is how and where to get guest images with which to experiment with Trove, and how to build these images for themselves. While documentation about this exists in multiple places (including [2], [3]) this is still something that can do with some improvement. Trove currently uses diskimage-builder for building images used in testing the product and these can serve as a good basis for anyone wishing to build an image for their own use of Trove. The review [1] makes the argument for the libguestfs based approach to building images and advocates that Trove should use this instead of diskimage-builder. At the summit we discussed the possibility of providing an implementation that would allow for both DIB and libguestfs to be used but to give priority to DIB. Since there's no real intention of just switching tools at this point, I believe it'd be good to amend the spec so that it doesn't mention libguestfs should be used instead of DiB. The goal at this stage is to provide both and help these move forward. I believe that a broader discussion of this is required and I appreciate Greg Haynes' proposal at the design summit to have this discussion on the ML. I took the action item to bring this discussion to the ML. Details follow ... Before going further, I will state my views on these matters. 1. It is important for the Trove project to do things quickly to make it easier for end users who wish to use Trove and who wish to build their own images. I am not concerned what tool or tools a person will use to build these images. ++. One of the biggest issues I see users of DIB hit is ease of use for 'just make me an image, I don't care about twiddling knobs'. A wrapper script in trove is one way to help with this, but I am sure there are other solutions as well... maybe by rethinking some of our fear about using elements as entry points to an image build, or by simply making element's with better defaults. 2. If we provide multiple alternatives to image building as part of the Trove project, we should make sure that images built with all sets of tools are equivalent and usable interchangeably. Failing to do this will make it harder for users to use Trove because we will be providing them with a false choice (i.e. the alternatives aren't really alternatives). This is harder than it sounds given the combination of tools, operating systems, and the source(s) from which you can get database software. Maintaining both in the long run will be harder especially because, as you mentioned, the output must be usable interchangeably. However, I think we're at a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano and some other folks that it'd be beneficial for us to have this discussion and to also experiment/test other options. The Sahara team seems to be going in a direction that differs with the one used by the infra team and the one we're headed to (although they overlap in some areas). I would highly recommend against having two sets of image building code for Trove - given DIB's current design there should not be any need for this and there's a HUGE downside to maintaining two sets of code to do the same thing in-tree. Ideally a single set of code would be used while being able to be run in different environments if there are mutually exclusive requirements being proposed by users. Well, certainly one downside in the case of Trove (and probably elsewhere) with DIB is the src tree matrix of datastore-by-distro elements required to support various guest image combinations, leading to a proliferation of directories and files. We feel this can be greatly simplified using a libguestfs approach using a minimal set of bash and directly applicable data files (e.g., systemd unit files, conf files, etc.). What seemed very apparent to me in the summit session is that there are a set of issues for Trove relating to image building, mostly relating to reliability and ease of use. There was no one who even mentioned let alone strongly cared about the issues which actually differentiate the existing DIB build process from libguestfs (which is isolation). If that has changed for some reason, then my recommendation would be to use a tool like virt-dib which will allow for a single image building code base while solving all the raised issues in the spec. I suspect when this is tried out the downsides to booting a VM will highly outweigh the benefits for almost all users (especially in trove's gate), Anecdotally, it takes the same amount of time for a CentOS7 MySQL build (~ 7 minutes) with either toolchain. but if the libguestfs docs are to be believed this s
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
On Wed, May 4, 2016 at 11:55 AM, Flavio Percoco wrote: > On 04/05/16 15:05 +, Amrith Kumar wrote: > >> I'm emailing the ML on the subject of a review ongoing in the Trove >> project regarding image building[1]. >> >> TL;DR >> >> One of the most frequent questions that new users of Trove ask is how and >> where to get guest images with which to experiment with Trove, and how to >> build these images for themselves. While documentation about this exists in >> multiple places (including [2], [3]) this is still something that can do >> with some improvement. >> >> Trove currently uses diskimage-builder for building images used in >> testing the product and these can serve as a good basis for anyone wishing >> to build an image for their own use of Trove. The review [1] makes the >> argument for the libguestfs based approach to building images and advocates >> that Trove should use this instead of diskimage-builder. >> > > At the summit we discussed the possibility of providing an implementation > that > would allow for both DIB and libguestfs to be used but to give priority to > DIB. > Since there's no real intention of just switching tools at this point, I > believe > it'd be good to amend the spec so that it doesn't mention libguestfs > should be > used instead of DiB. > > The goal at this stage is to provide both and help these move forward. > > I believe that a broader discussion of this is required and I appreciate >> Greg Haynes' proposal at the design summit to have this discussion on the >> ML. I took the action item to bring this discussion to the ML. >> >> Details follow ... >> >> Before going further, I will state my views on these matters. >> >> 1. It is important for the Trove project to do things quickly to make it >> easier for end users who wish to use Trove and who wish to build their own >> images. I am not concerned what tool or tools a person will use to build >> these images. >> >> 2. If we provide multiple alternatives to image building as part of the >> Trove project, we should make sure that images built with all sets of tools >> are equivalent and usable interchangeably. Failing to do this will make it >> harder for users to use Trove because we will be providing them with a >> false choice (i.e. the alternatives aren't really alternatives). This is >> harder than it sounds given the combination of tools, operating systems, >> and the source(s) from which you can get database software. >> > > Maintaining both in the long run will be harder especially because, as you > mentioned, the output must be usable interchangeably. However, I think > we're at > a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano > and > some other folks that it'd be beneficial for us to have this discussion > and to > also experiment/test other options. > > The Sahara team seems to be going in a direction that differs with the one > used > by the infra team and the one we're headed to (although they overlap in > some > areas). > Sahara has support for several image generation-related cases: 1) Packing an image pre-cluster spawn in Nova. 2) Building clusters from a "clean" OS image post-Nova spawn, by downloading and installing Hadoop/Spark/Storm/WhatHaveYou. 3) Validating images after Nova spawn (to ensure that they're up to spec for the plugin in question.) Because of this, we are pulling image generation logic into the plugins themselves, from a monolithic sahara-image-elements repository. This will aid us in our eventual hope to pull plugins out of the Sahara tree entirely; more immediately, it will allow us to define logic for all of these cases in one place, written eventually in Python. In our Sahara session at summit, which was also attended by several members of the Ironic team (thanks all), we discussed our current plan to use libguestfs rather than DIB as our toolchain; our intent to define a linear, idempotent set of steps to pack images for any plugin lends itself much more neatly to libguestfs' API than to DIB's. > 3. Trove already has elements for all supported databases using DIB in the >> trove-integration project but these elements are not packaged for customer >> use. Making them usable by customers is a relatively small effort including >> providing a wrapper script (derived from redstack[4]) and providing an >> element to install the guest agent software from a fixed location in >> addition to the development and testing version that is better suited to >> Trove development [5] and [6]. >> >> 4. My comments on various patch sets in the review[1]. >> >> I agree with Monty and Greg Haynes that we should understand the >> deficiencies if any in DIB, and if it is in fact the case that they are >> "intractable/unsolvable", we should switch toolchains. This discussion >> should include issues faced by the Trove team as well as other teams that >> may have faced problems with DIB (such as the sahara team who described >> some of them in the past). >> > > ++ > > Agreed
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
On 05/04/2016 11:46 AM, Clark Boylan wrote: On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote: On 04/05/16 15:05 +, Amrith Kumar wrote: I'm emailing the ML on the subject of a review ongoing in the Trove project regarding image building[1]. TL;DR One of the most frequent questions that new users of Trove ask is how and where to get guest images with which to experiment with Trove, and how to build these images for themselves. While documentation about this exists in multiple places (including [2], [3]) this is still something that can do with some improvement. Trove currently uses diskimage-builder for building images used in testing the product and these can serve as a good basis for anyone wishing to build an image for their own use of Trove. The review [1] makes the argument for the libguestfs based approach to building images and advocates that Trove should use this instead of diskimage-builder. At the summit we discussed the possibility of providing an implementation that would allow for both DIB and libguestfs to be used but to give priority to DIB. Since there's no real intention of just switching tools at this point, I believe it'd be good to amend the spec so that it doesn't mention libguestfs should be used instead of DiB. The goal at this stage is to provide both and help these move forward. I disagree, as someone that has tried and failed in the past to build trove images the goal should be to make that process easy for the user. Maybe we can finally get rid of redstack years after it was supposed to go away. I believe that a broader discussion of this is required and I appreciate Greg Haynes' proposal at the design summit to have this discussion on the ML. I took the action item to bring this discussion to the ML. Details follow ... Before going further, I will state my views on these matters. 1. It is important for the Trove project to do things quickly to make it easier for end users who wish to use Trove and who wish to build their own images. I am not concerned what tool or tools a person will use to build these images. 2. If we provide multiple alternatives to image building as part of the Trove project, we should make sure that images built with all sets of tools are equivalent and usable interchangeably. Failing to do this will make it harder for users to use Trove because we will be providing them with a false choice (i.e. the alternatives aren't really alternatives). This is harder than it sounds given the combination of tools, operating systems, and the source(s) from which you can get database software. Maintaining both in the long run will be harder especially because, as you mentioned, the output must be usable interchangeably. However, I think we're at a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano and some other folks that it'd be beneficial for us to have this discussion and to also experiment/test other options. The Sahara team seems to be going in a direction that differs with the one used by the infra team and the one we're headed to (although they overlap in some areas). Has Sahara expressed their needs somewhere too? This is the first I am hearing of them having trouble with image builds (I had thought they were using DIB successfully). 3. Trove already has elements for all supported databases using DIB in the trove-integration project but these elements are not packaged for customer use. Making them usable by customers is a relatively small effort including providing a wrapper script (derived from redstack[4]) and providing an element to install the guest agent software from a fixed location in addition to the development and testing version that is better suited to Trove development [5] and [6]. 4. My comments on various patch sets in the review[1]. I agree with Monty and Greg Haynes that we should understand the deficiencies if any in DIB, and if it is in fact the case that they are "intractable/unsolvable", we should switch toolchains. This discussion should include issues faced by the Trove team as well as other teams that may have faced problems with DIB (such as the sahara team who described some of them in the past). ++ Agreed with the above. I'm think collaboration should be the preferred way. I don't think I've enough technical insight on this topic to provide a detailed list of things that are good/bad on either of these tools but I wanted to mention that I believe providing support for both in the short run is good for us and it helps to make a better decision on what tool works best for the project. There's someone willing to do the job and spend sometime doing the research. This same person will provide feedback in addition to the one already provided in [1]. Sorry for not providing much technical details now but I did want to share the above. Thanks for starting this thread, I believe this discussion in the ML will be beneficial. This is the problem. We need tec
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote: > On 04/05/16 15:05 +, Amrith Kumar wrote: > >I'm emailing the ML on the subject of a review ongoing in the Trove project > >regarding image building[1]. > > > >TL;DR > > > >One of the most frequent questions that new users of Trove ask is how and > >where to get guest images with which to experiment with Trove, and how to > >build these images for themselves. While documentation about this exists in > >multiple places (including [2], [3]) this is still something that can do > >with some improvement. > > > >Trove currently uses diskimage-builder for building images used in testing > >the product and these can serve as a good basis for anyone wishing to build > >an image for their own use of Trove. The review [1] makes the argument for > >the libguestfs based approach to building images and advocates that Trove > >should use this instead of diskimage-builder. > > At the summit we discussed the possibility of providing an implementation > that > would allow for both DIB and libguestfs to be used but to give priority > to DIB. > Since there's no real intention of just switching tools at this point, I > believe > it'd be good to amend the spec so that it doesn't mention libguestfs > should be > used instead of DiB. > > The goal at this stage is to provide both and help these move forward. > > >I believe that a broader discussion of this is required and I appreciate > >Greg Haynes' proposal at the design summit to have this discussion on the > >ML. I took the action item to bring this discussion to the ML. > > > >Details follow ... > > > >Before going further, I will state my views on these matters. > > > >1. It is important for the Trove project to do things quickly to make it > >easier for end users who wish to use Trove and who wish to build their own > >images. I am not concerned what tool or tools a person will use to build > >these images. ++. One of the biggest issues I see users of DIB hit is ease of use for 'just make me an image, I don't care about twiddling knobs'. A wrapper script in trove is one way to help with this, but I am sure there are other solutions as well... maybe by rethinking some of our fear about using elements as entry points to an image build, or by simply making element's with better defaults. > > > >2. If we provide multiple alternatives to image building as part of the > >Trove project, we should make sure that images built with all sets of tools > >are equivalent and usable interchangeably. Failing to do this will make it > >harder for users to use Trove because we will be providing them with a false > >choice (i.e. the alternatives aren't really alternatives). This is harder > >than it sounds given the combination of tools, operating systems, and the > >source(s) from which you can get database software. > > Maintaining both in the long run will be harder especially because, as > you > mentioned, the output must be usable interchangeably. However, I think > we're at > a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano > and > some other folks that it'd be beneficial for us to have this discussion > and to > also experiment/test other options. > > The Sahara team seems to be going in a direction that differs with the > one used > by the infra team and the one we're headed to (although they overlap in > some > areas). > I would highly recommend against having two sets of image building code for Trove - given DIB's current design there should not be any need for this and there's a HUGE downside to maintaining two sets of code to do the same thing in-tree. Ideally a single set of code would be used while being able to be run in different environments if there are mutually exclusive requirements being proposed by users. What seemed very apparent to me in the summit session is that there are a set of issues for Trove relating to image building, mostly relating to reliability and ease of use. There was no one who even mentioned let alone strongly cared about the issues which actually differentiate the existing DIB build process from libguestfs (which is isolation). If that has changed for some reason, then my recommendation would be to use a tool like virt-dib which will allow for a single image building code base while solving all the raised issues in the spec. I suspect when this is tried out the downsides to booting a VM will highly outweigh the benefits for almost all users (especially in trove's gate), but if the libguestfs docs are to be believed this should be trivial to try out. > >3. Trove already has elements for all supported databases using DIB in the > >trove-integration project but these elements are not packaged for customer > >use. Making them usable by customers is a relatively small effort including > >providing a wrapper script (derived from redstack[4]) and providing an > >element to install the guest agent software from a fixed location in > >add
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote: > On 04/05/16 15:05 +, Amrith Kumar wrote: > >I'm emailing the ML on the subject of a review ongoing in the Trove project > >regarding image building[1]. > > > >TL;DR > > > >One of the most frequent questions that new users of Trove ask is how and > >where to get guest images with which to experiment with Trove, and how to > >build these images for themselves. While documentation about this exists in > >multiple places (including [2], [3]) this is still something that can do > >with some improvement. > > > >Trove currently uses diskimage-builder for building images used in testing > >the product and these can serve as a good basis for anyone wishing to build > >an image for their own use of Trove. The review [1] makes the argument for > >the libguestfs based approach to building images and advocates that Trove > >should use this instead of diskimage-builder. > > At the summit we discussed the possibility of providing an implementation > that > would allow for both DIB and libguestfs to be used but to give priority > to DIB. > Since there's no real intention of just switching tools at this point, I > believe > it'd be good to amend the spec so that it doesn't mention libguestfs > should be > used instead of DiB. > > The goal at this stage is to provide both and help these move forward. I disagree, as someone that has tried and failed in the past to build trove images the goal should be to make that process easy for the user. Maybe we can finally get rid of redstack years after it was supposed to go away. > >I believe that a broader discussion of this is required and I appreciate > >Greg Haynes' proposal at the design summit to have this discussion on the > >ML. I took the action item to bring this discussion to the ML. > > > >Details follow ... > > > >Before going further, I will state my views on these matters. > > > >1. It is important for the Trove project to do things quickly to make it > >easier for end users who wish to use Trove and who wish to build their own > >images. I am not concerned what tool or tools a person will use to build > >these images. > > > >2. If we provide multiple alternatives to image building as part of the > >Trove project, we should make sure that images built with all sets of tools > >are equivalent and usable interchangeably. Failing to do this will make it > >harder for users to use Trove because we will be providing them with a false > >choice (i.e. the alternatives aren't really alternatives). This is harder > >than it sounds given the combination of tools, operating systems, and the > >source(s) from which you can get database software. > > Maintaining both in the long run will be harder especially because, as > you > mentioned, the output must be usable interchangeably. However, I think > we're at > a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano > and > some other folks that it'd be beneficial for us to have this discussion > and to > also experiment/test other options. > > The Sahara team seems to be going in a direction that differs with the > one used > by the infra team and the one we're headed to (although they overlap in > some > areas). Has Sahara expressed their needs somewhere too? This is the first I am hearing of them having trouble with image builds (I had thought they were using DIB successfully). > >3. Trove already has elements for all supported databases using DIB in the > >trove-integration project but these elements are not packaged for customer > >use. Making them usable by customers is a relatively small effort including > >providing a wrapper script (derived from redstack[4]) and providing an > >element to install the guest agent software from a fixed location in > >addition to the development and testing version that is better suited to > >Trove development [5] and [6]. > > > >4. My comments on various patch sets in the review[1]. > > > >I agree with Monty and Greg Haynes that we should understand the > >deficiencies if any in DIB, and if it is in fact the case that they are > >"intractable/unsolvable", we should switch toolchains. This discussion > >should include issues faced by the Trove team as well as other teams that > >may have faced problems with DIB (such as the sahara team who described some > >of them in the past). > > ++ > > Agreed with the above. I'm think collaboration should be the preferred > way. I > don't think I've enough technical insight on this topic to provide a > detailed > list of things that are good/bad on either of these tools but I wanted to > mention that I believe providing support for both in the short run is > good for > us and it helps to make a better decision on what tool works best for the > project. > > There's someone willing to do the job and spend sometime doing the > research. > This same person will provide feedback in addition to the one already > provided > in [1]. > > Sorry f
Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
On 04/05/16 15:05 +, Amrith Kumar wrote: I'm emailing the ML on the subject of a review ongoing in the Trove project regarding image building[1]. TL;DR One of the most frequent questions that new users of Trove ask is how and where to get guest images with which to experiment with Trove, and how to build these images for themselves. While documentation about this exists in multiple places (including [2], [3]) this is still something that can do with some improvement. Trove currently uses diskimage-builder for building images used in testing the product and these can serve as a good basis for anyone wishing to build an image for their own use of Trove. The review [1] makes the argument for the libguestfs based approach to building images and advocates that Trove should use this instead of diskimage-builder. At the summit we discussed the possibility of providing an implementation that would allow for both DIB and libguestfs to be used but to give priority to DIB. Since there's no real intention of just switching tools at this point, I believe it'd be good to amend the spec so that it doesn't mention libguestfs should be used instead of DiB. The goal at this stage is to provide both and help these move forward. I believe that a broader discussion of this is required and I appreciate Greg Haynes' proposal at the design summit to have this discussion on the ML. I took the action item to bring this discussion to the ML. Details follow ... Before going further, I will state my views on these matters. 1. It is important for the Trove project to do things quickly to make it easier for end users who wish to use Trove and who wish to build their own images. I am not concerned what tool or tools a person will use to build these images. 2. If we provide multiple alternatives to image building as part of the Trove project, we should make sure that images built with all sets of tools are equivalent and usable interchangeably. Failing to do this will make it harder for users to use Trove because we will be providing them with a false choice (i.e. the alternatives aren't really alternatives). This is harder than it sounds given the combination of tools, operating systems, and the source(s) from which you can get database software. Maintaining both in the long run will be harder especially because, as you mentioned, the output must be usable interchangeably. However, I think we're at a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano and some other folks that it'd be beneficial for us to have this discussion and to also experiment/test other options. The Sahara team seems to be going in a direction that differs with the one used by the infra team and the one we're headed to (although they overlap in some areas). 3. Trove already has elements for all supported databases using DIB in the trove-integration project but these elements are not packaged for customer use. Making them usable by customers is a relatively small effort including providing a wrapper script (derived from redstack[4]) and providing an element to install the guest agent software from a fixed location in addition to the development and testing version that is better suited to Trove development [5] and [6]. 4. My comments on various patch sets in the review[1]. I agree with Monty and Greg Haynes that we should understand the deficiencies if any in DIB, and if it is in fact the case that they are "intractable/unsolvable", we should switch toolchains. This discussion should include issues faced by the Trove team as well as other teams that may have faced problems with DIB (such as the sahara team who described some of them in the past). ++ Agreed with the above. I'm think collaboration should be the preferred way. I don't think I've enough technical insight on this topic to provide a detailed list of things that are good/bad on either of these tools but I wanted to mention that I believe providing support for both in the short run is good for us and it helps to make a better decision on what tool works best for the project. There's someone willing to do the job and spend sometime doing the research. This same person will provide feedback in addition to the one already provided in [1]. Sorry for not providing much technical details now but I did want to share the above. Thanks for starting this thread, I believe this discussion in the ML will be beneficial. Flavio Thanks, -amrith [1] https://review.openstack.org/#/c/295274/ [2] http://docs.openstack.org/developer/trove/dev/building_guest_images.html [3] https://git.openstack.org/cgit/openstack/diskimage-builder/tree/README.rst#writing-an-element [4] http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/redstack [5] http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/files/trove-guest.systemd.conf [6] http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/files/trove-gu
[openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove
I'm emailing the ML on the subject of a review ongoing in the Trove project regarding image building[1]. TL;DR One of the most frequent questions that new users of Trove ask is how and where to get guest images with which to experiment with Trove, and how to build these images for themselves. While documentation about this exists in multiple places (including [2], [3]) this is still something that can do with some improvement. Trove currently uses diskimage-builder for building images used in testing the product and these can serve as a good basis for anyone wishing to build an image for their own use of Trove. The review [1] makes the argument for the libguestfs based approach to building images and advocates that Trove should use this instead of diskimage-builder. I believe that a broader discussion of this is required and I appreciate Greg Haynes' proposal at the design summit to have this discussion on the ML. I took the action item to bring this discussion to the ML. Details follow ... Before going further, I will state my views on these matters. 1. It is important for the Trove project to do things quickly to make it easier for end users who wish to use Trove and who wish to build their own images. I am not concerned what tool or tools a person will use to build these images. 2. If we provide multiple alternatives to image building as part of the Trove project, we should make sure that images built with all sets of tools are equivalent and usable interchangeably. Failing to do this will make it harder for users to use Trove because we will be providing them with a false choice (i.e. the alternatives aren't really alternatives). This is harder than it sounds given the combination of tools, operating systems, and the source(s) from which you can get database software. 3. Trove already has elements for all supported databases using DIB in the trove-integration project but these elements are not packaged for customer use. Making them usable by customers is a relatively small effort including providing a wrapper script (derived from redstack[4]) and providing an element to install the guest agent software from a fixed location in addition to the development and testing version that is better suited to Trove development [5] and [6]. 4. My comments on various patch sets in the review[1]. I agree with Monty and Greg Haynes that we should understand the deficiencies if any in DIB, and if it is in fact the case that they are "intractable/unsolvable", we should switch toolchains. This discussion should include issues faced by the Trove team as well as other teams that may have faced problems with DIB (such as the sahara team who described some of them in the past). Thanks, -amrith [1] https://review.openstack.org/#/c/295274/ [2] http://docs.openstack.org/developer/trove/dev/building_guest_images.html [3] https://git.openstack.org/cgit/openstack/diskimage-builder/tree/README.rst#writing-an-element [4] http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/redstack [5] http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/files/trove-guest.systemd.conf [6] http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/files/trove-guest.upstart.conf __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
