Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Lloyd Dewolf wrote: In my fantasies for the Grizzly release it would start something like: A. Grizzly Summit B. From the summit the Tech Committee PTL have community consensus on the overarching goal for the release and the projects' goals. Articulated online in user friendly manner. C. Webinar / OpenStack User Groups get a presentation on the release goals, and channels for input and participation. D. About the half way point in release schedule, development adjusts the online communication to reflect reality, presents an update, and again channels for input and participation. How do things work today? I haven't found much in the wiki. Currently we publicly track and adjust release goals through the series blueprints in Launchpad (for example: https://blueprints.launchpad.net/quantum/folsom for Quantum). You can see a combined view for all Folsom at: http://wiki.openstack.org/releasestatus/ . The plan is initially seeded by the PTLs after the design summit, then continuously adjusted to reflect reality (with a status update every week at the Project Release status meeting). These public plans can then be used by anyone who wants to present them in webinars or user group meetups, and anyone is free to comment on them and provide input. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Mon, Jul 16, 2012 at 9:08 AM, Thierry Carrez thie...@openstack.org wrote: Using the user committee setup, you don't really need to take authority away from the PTL. You increase the influence of the users on technical decisions. You just provide a clear and official mechanism to represent the interests of the users as a whole. Once you have that, if the PTL or technical committee decides to ignore it, it's a rather strong decision that better has to be well justified. Its better than having some arbitrary percentage of users in a single committee and then have most decisions won by the most largely represented party. If the user committee is an active and respected group, it provides nice checks and balances against developers living in developer bubbles. Most issues we have right now with deployer-friendliness are linked to the fact that the users don't have a clear or official voice. The trick is, of course, to manage to set up such a committee in a way that represents all the users and deployers. It will be all the more influential if it is seen as representing all the users, rather than just a loosely-tied pre-determined subset of large users. I generally agree with your thoughts around a user committee. For my benefit, I'd love to get a feel for what we're doing to make development user friendly? In my fantasies for the Grizzly release it would start something like: A. Grizzly Summit B. From the summit the Tech Committee PTL have community consensus on the overarching goal for the release and the projects' goals. Articulated online in user friendly manner. C. Webinar / OpenStack User Groups get a presentation on the release goals, and channels for input and participation. D. About the half way point in release schedule, development adjusts the online communication to reflect reality, presents an update, and again channels for input and participation. How do things work today? I haven't found much in the wiki. Thanks, -- @lloyddewolf http://www.pistoncloud.com/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Jay Pipes on 16 July 2012 18:31 wrote: On 07/16/2012 09:55 AM, David Kranz wrote: Sure, although in this *particular* case the Cinder project is a bit-for-bit copy of nova-volumes. In fact, the only thing really of cause for concern are: * Providing a migration script for the database tables currently in the Nova database to the Cinder database * Ensuring that Keystone's service catalog exposes the volume endpoint along with the compute endpoint so that volume API calls are routed to the right endpoint (and there's nothing preventing a simple URL rewrite redirect for the existing /volumes calls in the Compute API to be routed directly to the new Volumes endpoint which has the same API Plus stand up a new rabbit HA server. Plus stand up a new HA database server. Plus understand the new availability constraints of the nova-cinder interface point Plus whatever else I haven't scoped yet And there are bug fixes and correctness fixes slowly going into Cinder, so it is not a bit--for-bit copy any longer... ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Will we also have a separate Cinder API server? Tom -Original Message- From: openstack-bounces+tom.howley=hp@lists.launchpad.net [mailto:openstack-bounces+tom.howley=hp@lists.launchpad.net] On Behalf Of Thomas, Duncan Sent: 17 July 2012 10:47 To: Jay Pipes; openstack@lists.launchpad.net Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom Jay Pipes on 16 July 2012 18:31 wrote: On 07/16/2012 09:55 AM, David Kranz wrote: Sure, although in this *particular* case the Cinder project is a bit-for-bit copy of nova-volumes. In fact, the only thing really of cause for concern are: * Providing a migration script for the database tables currently in the Nova database to the Cinder database * Ensuring that Keystone's service catalog exposes the volume endpoint along with the compute endpoint so that volume API calls are routed to the right endpoint (and there's nothing preventing a simple URL rewrite redirect for the existing /volumes calls in the Compute API to be routed directly to the new Volumes endpoint which has the same API Plus stand up a new rabbit HA server. Plus stand up a new HA database server. Plus understand the new availability constraints of the nova-cinder interface point Plus whatever else I haven't scoped yet And there are bug fixes and correctness fixes slowly going into Cinder, so it is not a bit--for-bit copy any longer... ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Tue, Jul 17, 2012 at 6:12 PM, Howley, Tom tom.how...@hp.com wrote: Will we also have a separate Cinder API server? Yes, we have. Tom -Original Message- From: openstack-bounces+tom.howley=hp@lists.launchpad.net [mailto:openstack-bounces+tom.howley=hp@lists.launchpad.net] On Behalf Of Thomas, Duncan Sent: 17 July 2012 10:47 To: Jay Pipes; openstack@lists.launchpad.net Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom Jay Pipes on 16 July 2012 18:31 wrote: On 07/16/2012 09:55 AM, David Kranz wrote: Sure, although in this *particular* case the Cinder project is a bit-for-bit copy of nova-volumes. In fact, the only thing really of cause for concern are: * Providing a migration script for the database tables currently in the Nova database to the Cinder database * Ensuring that Keystone's service catalog exposes the volume endpoint along with the compute endpoint so that volume API calls are routed to the right endpoint (and there's nothing preventing a simple URL rewrite redirect for the existing /volumes calls in the Compute API to be routed directly to the new Volumes endpoint which has the same API Plus stand up a new rabbit HA server. Plus stand up a new HA database server. Plus understand the new availability constraints of the nova-cinder interface point Plus whatever else I haven't scoped yet And there are bug fixes and correctness fixes slowly going into Cinder, so it is not a bit--for-bit copy any longer... ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Regards Huang Zhiteng ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On 07/17/2012 05:47 AM, Thomas, Duncan wrote: Jay Pipes on 16 July 2012 18:31 wrote: On 07/16/2012 09:55 AM, David Kranz wrote: Sure, although in this *particular* case the Cinder project is a bit-for-bit copy of nova-volumes. In fact, the only thing really of cause for concern are: * Providing a migration script for the database tables currently in the Nova database to the Cinder database * Ensuring that Keystone's service catalog exposes the volume endpoint along with the compute endpoint so that volume API calls are routed to the right endpoint (and there's nothing preventing a simple URL rewrite redirect for the existing /volumes calls in the Compute API to be routed directly to the new Volumes endpoint which has the same API Plus stand up a new rabbit HA server. Why? This has nothing to do with the nova-volumes - Cinder move... Plus stand up a new HA database server. This is up to you. Technically, you could use the same database server as Nova and point your Cinder service to it (exactly like you do for nova-volumes, which queries the Nova database for volume information). You could gradually move the data to another database server over time, but it's not required at the time you transition to Cinder. Plus understand the new availability constraints of the nova-cinder interface point You can act like Cinder is just nova-volumes and not really change anything in your environment at all. Wherever you are installing the nova-volume daemon now, you would be installing Cinder. You can decide to understand the availability constraints at some future point. And there are bug fixes and correctness fixes slowly going into Cinder, so it is not a bit--for-bit copy any longer... This whole conversation has been about whether to continue applying patches to **both** nova-volumes and Cinder. We are trying to avoid doing that for an extended period of time because it is a pain. Look, software changes over time. It's not a static thing. We're trying to discuss the transition from an internal nova-volumes to an external volume service, but let's not go overboard in making the transition out to be more than it actually is... Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On 07/12/2012 05:40 PM, Vishvananda Ishaya wrote: Excellent points. Let me make the following proposal: 1) Leave the code in nova-volume for now. 2) Document and test a clear migration path to cinder. 3) Take the working example upgrade to the operators list and ask them for opinions. 4) Decide based on their feedback whether it is acceptable to cut the nova-volume code out for folsom. +1 -Sean -- Sean Dague IBM Linux Technology Center email: sda...@linux.vnet.ibm.com alt-email: slda...@us.ibm.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
An excellent idea. I believe that if the below message had been sent in April, the tenor of the discussion would have been much different. I think a main source of angst around this was that there was no mention at the Folsom summit of nova-volume being simply removed immediately, except perhaps inside the session devoted to this subject which many could not attend. Stepping up a level, it is hard for a project to move from a developer-centric (no real customers) way of doing things to one driven by having real enterprise users/customers. I know this from past experience. At a certain point, we will have to live with APIs or code organizations that are sub-optimal because it is just too much of a burden on real users/operators to change them. Obviously some members of the community believe this tipping point was the Essex release. It is also inevitable that development will slow down by some measures as the cost of regressions rises and what George Reese called technical debt has to be repaid. Going forward, and this may be controversial, I think these kinds of issues would be best addressed by following these measures: 1. Require each blueprint that involves an API change or significant operational incompatibility to include a significant justification of why it is necessary, what the impact would be, and a plan for deprecation/migration. This justification should assume that the remedy will have to be applied to a large, running OpenStack system in its many possible variations, without having to shut down the system for some unknown amount of time. 2. Require such blueprints to be approved by a technical committee that includes a significant representation of users/operators. The tradeoffs can be difficult and need to be discussed. 3. The technical committee should declare that the bar for incompatible changes is high, and getting higher. Some might argue that this is too much of a burden and takes authority away from PTLs, but I think the statement of stability to the community (and others) would more than compensate for that. -David On 7/16/2012 8:04 AM, Sean Dague wrote: On 07/12/2012 05:40 PM, Vishvananda Ishaya wrote: Excellent points. Let me make the following proposal: 1) Leave the code in nova-volume for now. 2) Document and test a clear migration path to cinder. 3) Take the working example upgrade to the operators list and ask them for opinions. 4) Decide based on their feedback whether it is acceptable to cut the nova-volume code out for folsom. +1 -Sean ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
I definitely agree with everything said here. On Jul 16, 2012, at 8:55 AM, David Kranz wrote: An excellent idea. I believe that if the below message had been sent in April, the tenor of the discussion would have been much different. I think a main source of angst around this was that there was no mention at the Folsom summit of nova-volume being simply removed immediately, except perhaps inside the session devoted to this subject which many could not attend. Stepping up a level, it is hard for a project to move from a developer-centric (no real customers) way of doing things to one driven by having real enterprise users/customers. I know this from past experience. At a certain point, we will have to live with APIs or code organizations that are sub-optimal because it is just too much of a burden on real users/operators to change them. Obviously some members of the community believe this tipping point was the Essex release. It is also inevitable that development will slow down by some measures as the cost of regressions rises and what George Reese called technical debt has to be repaid. Going forward, and this may be controversial, I think these kinds of issues would be best addressed by following these measures: 1. Require each blueprint that involves an API change or significant operational incompatibility to include a significant justification of why it is necessary, what the impact would be, and a plan for deprecation/migration. This justification should assume that the remedy will have to be applied to a large, running OpenStack system in its many possible variations, without having to shut down the system for some unknown amount of time. 2. Require such blueprints to be approved by a technical committee that includes a significant representation of users/operators. The tradeoffs can be difficult and need to be discussed. 3. The technical committee should declare that the bar for incompatible changes is high, and getting higher. Some might argue that this is too much of a burden and takes authority away from PTLs, but I think the statement of stability to the community (and others) would more than compensate for that. -David On 7/16/2012 8:04 AM, Sean Dague wrote: On 07/12/2012 05:40 PM, Vishvananda Ishaya wrote: Excellent points. Let me make the following proposal: 1) Leave the code in nova-volume for now. 2) Document and test a clear migration path to cinder. 3) Take the working example upgrade to the operators list and ask them for opinions. 4) Decide based on their feedback whether it is acceptable to cut the nova-volume code out for folsom. +1 -Sean ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
David Kranz wrote: Going forward, and this may be controversial, I think these kinds of issues would be best addressed by following these measures: 1. Require each blueprint that involves an API change or significant operational incompatibility to include a significant justification of why it is necessary, what the impact would be, and a plan for deprecation/migration. This justification should assume that the remedy will have to be applied to a large, running OpenStack system in its many possible variations, without having to shut down the system for some unknown amount of time. That would be useful. Strengthening a bit the feature proposal process definitely can't hurt. 2. Require such blueprints to be approved by a technical committee that includes a significant representation of users/operators. The tradeoffs can be difficult and need to be discussed. The Foundation bylaws propose that a User committee be set up. I hope that the User committee can be quickly set up, gets respected people on it and manages to be representative of all the users/operators of OpenStack. If done properly, such a committee can get very influential and its public recommendations cannot be easily ignored by the developer side (the technical committee). 3. The technical committee should declare that the bar for incompatible changes is high, and getting higher. Some might argue that this is too much of a burden and takes authority away from PTLs, but I think the statement of stability to the community (and others) would more than compensate for that. Using the user committee setup, you don't really need to take authority away from the PTL. You increase the influence of the users on technical decisions. You just provide a clear and official mechanism to represent the interests of the users as a whole. Once you have that, if the PTL or technical committee decides to ignore it, it's a rather strong decision that better has to be well justified. Its better than having some arbitrary percentage of users in a single committee and then have most decisions won by the most largely represented party. If the user committee is an active and respected group, it provides nice checks and balances against developers living in developer bubbles. Most issues we have right now with deployer-friendliness are linked to the fact that the users don't have a clear or official voice. The trick is, of course, to manage to set up such a committee in a way that represents all the users and deployers. It will be all the more influential if it is seen as representing all the users, rather than just a loosely-tied pre-determined subset of large users. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On 07/16/2012 09:55 AM, David Kranz wrote: An excellent idea. I believe that if the below message had been sent in April, the tenor of the discussion would have been much different. I think a main source of angst around this was that there was no mention at the Folsom summit of nova-volume being simply removed immediately, except perhaps inside the session devoted to this subject which many could not attend. Again, this was proposed, not decided. Vish and JohnG sent out the mailing list post to gather feedback. Stepping up a level, it is hard for a project to move from a developer-centric (no real customers) way of doing things to one driven by having real enterprise users/customers. I know this from past experience. At a certain point, we will have to live with APIs or code organizations that are sub-optimal because it is just too much of a burden on real users/operators to change them. Indeed. /see EC2 APIs. Obviously some members of the community believe this tipping point was the Essex release. It is also inevitable that development will slow down by some measures as the cost of regressions rises and what George Reese called technical debt has to be repaid. Sure, although in this *particular* case the Cinder project is a bit-for-bit copy of nova-volumes. In fact, the only thing really of cause for concern are: * Providing a migration script for the database tables currently in the Nova database to the Cinder database * Ensuring that Keystone's service catalog exposes the volume endpoint along with the compute endpoint so that volume API calls are routed to the right endpoint (and there's nothing preventing a simple URL rewrite redirect for the existing /volumes calls in the Compute API to be routed directly to the new Volumes endpoint which has the same API IMHO, it's not at all like the Keystone Light rework that was: * done in private with little community involvement * changed the way the API behaved Going forward, and this may be controversial, I think these kinds of issues would be best addressed by following these measures: 1. Require each blueprint that involves an API change or significant operational incompatibility to include a significant justification of why it is necessary, what the impact would be, and a plan for No disagreement here at all; though I will point out in the case of Cinder, there are no API changes. deprecation/migration. This justification should assume that the remedy will have to be applied to a large, running OpenStack system in its many possible variations, without having to shut down the system for some unknown amount of time. Yep, also agreed here too. And I think John's done a good job of highlighting this in http://wiki.openstack.org/Cinder 2. Require such blueprints to be approved by a technical committee that includes a significant representation of users/operators. The tradeoffs can be difficult and need to be discussed. Meh... I'm not sure this would actually prove useful. Frankly, we discussed this issue at the PPB meeting last week and the outcome of it was: make sure the mailing list is notified with a request for feedback on migration issues and that you work with the devstack folks to ensure smooth testing migration. IMHO, it's the domain of the PTLs of the projects that are affected that should gather feedback and find consensus. The PPB/technical committee should advise but I believe this is the purview of the PTLs to make the final decision on... 3. The technical committee should declare that the bar for incompatible changes is high, and getting higher. Again, in the case of Cinder, this isn't really an incompatible change in the sense that Keystone Light was. Nevertheless, the bar for incompatible changes SHOULD be high. Whether the technical committee is responsible for being the final arbiter for this or whether the affected projects' PTLs should be is a question for debate. Some might argue that this is too much of a burden and takes authority away from PTLs, but I think the statement of stability to the community (and others) would more than compensate for that. Sure, that's a good point, too. I don't think the technical committee should be involved as anything more than a group to bounce competing ideas off of -- the PTLs should be the final decisionmakers. But I see your point and respect it. Best, -jay -David On 7/16/2012 8:04 AM, Sean Dague wrote: On 07/12/2012 05:40 PM, Vishvananda Ishaya wrote: Excellent points. Let me make the following proposal: 1) Leave the code in nova-volume for now. 2) Document and test a clear migration path to cinder. 3) Take the working example upgrade to the operators list and ask them for opinions. 4) Decide based on their feedback whether it is acceptable to cut the nova-volume code out for folsom. +1 -Sean ___ Mailing list: https://launchpad.net/~openstack Post to
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Has the user committee selection/ setup process been discussed before? Does it matter how big a customer the user represents - big co vs individual/ enthusiast? Thanks, -Sriram -Original Message- From: openstack-bounces+sriram=sriramhere@lists.launchpad.net [mailto:openstack-bounces+sriram=sriramhere@lists.launchpad.net] On Behalf Of Thierry Carrez Sent: Monday, July 16, 2012 9:08 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom David Kranz wrote: Going forward, and this may be controversial, I think these kinds of issues would be best addressed by following these measures: 1. Require each blueprint that involves an API change or significant operational incompatibility to include a significant justification of why it is necessary, what the impact would be, and a plan for deprecation/migration. This justification should assume that the remedy will have to be applied to a large, running OpenStack system in its many possible variations, without having to shut down the system for some unknown amount of time. That would be useful. Strengthening a bit the feature proposal process definitely can't hurt. 2. Require such blueprints to be approved by a technical committee that includes a significant representation of users/operators. The tradeoffs can be difficult and need to be discussed. The Foundation bylaws propose that a User committee be set up. I hope that the User committee can be quickly set up, gets respected people on it and manages to be representative of all the users/operators of OpenStack. If done properly, such a committee can get very influential and its public recommendations cannot be easily ignored by the developer side (the technical committee). 3. The technical committee should declare that the bar for incompatible changes is high, and getting higher. Some might argue that this is too much of a burden and takes authority away from PTLs, but I think the statement of stability to the community (and others) would more than compensate for that. Using the user committee setup, you don't really need to take authority away from the PTL. You increase the influence of the users on technical decisions. You just provide a clear and official mechanism to represent the interests of the users as a whole. Once you have that, if the PTL or technical committee decides to ignore it, it's a rather strong decision that better has to be well justified. Its better than having some arbitrary percentage of users in a single committee and then have most decisions won by the most largely represented party. If the user committee is an active and respected group, it provides nice checks and balances against developers living in developer bubbles. Most issues we have right now with deployer-friendliness are linked to the fact that the users don't have a clear or official voice. The trick is, of course, to manage to set up such a committee in a way that represents all the users and deployers. It will be all the more influential if it is seen as representing all the users, rather than just a loosely-tied pre-determined subset of large users. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Speaking of the User Committee as proposed in the draft governance docs, I can certainly see value in having the committee chair chosen by the board. However, as currently proposed, there is a convoluted process for appointing the representatives of the committee. Frankly, if you want to give a voice to the end users, the user committee should be open to all who use the technology and wish to contribute their voice. My $0.02 USD Chris Sent from my iPad On Jul 16, 2012, at 12:10 PM, Thierry Carrez thie...@openstack.org wrote: David Kranz wrote: Going forward, and this may be controversial, I think these kinds of issues would be best addressed by following these measures: 1. Require each blueprint that involves an API change or significant operational incompatibility to include a significant justification of why it is necessary, what the impact would be, and a plan for deprecation/migration. This justification should assume that the remedy will have to be applied to a large, running OpenStack system in its many possible variations, without having to shut down the system for some unknown amount of time. That would be useful. Strengthening a bit the feature proposal process definitely can't hurt. 2. Require such blueprints to be approved by a technical committee that includes a significant representation of users/operators. The tradeoffs can be difficult and need to be discussed. The Foundation bylaws propose that a User committee be set up. I hope that the User committee can be quickly set up, gets respected people on it and manages to be representative of all the users/operators of OpenStack. If done properly, such a committee can get very influential and its public recommendations cannot be easily ignored by the developer side (the technical committee). 3. The technical committee should declare that the bar for incompatible changes is high, and getting higher. Some might argue that this is too much of a burden and takes authority away from PTLs, but I think the statement of stability to the community (and others) would more than compensate for that. Using the user committee setup, you don't really need to take authority away from the PTL. You increase the influence of the users on technical decisions. You just provide a clear and official mechanism to represent the interests of the users as a whole. Once you have that, if the PTL or technical committee decides to ignore it, it's a rather strong decision that better has to be well justified. Its better than having some arbitrary percentage of users in a single committee and then have most decisions won by the most largely represented party. If the user committee is an active and respected group, it provides nice checks and balances against developers living in developer bubbles. Most issues we have right now with deployer-friendliness are linked to the fact that the users don't have a clear or official voice. The trick is, of course, to manage to set up such a committee in a way that represents all the users and deployers. It will be all the more influential if it is seen as representing all the users, rather than just a loosely-tied pre-determined subset of large users. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Christopher B Ferris wrote: Speaking of the User Committee as proposed in the draft governance docs, I can certainly see value in having the committee chair chosen by the board. However, as currently proposed, there is a convoluted process for appointing the representatives of the committee. Frankly, if you want to give a voice to the end users, the user committee should be open to all who use the technology and wish to contribute their voice. I completely agree with you. It's critically important that the user committee is relevant and representative of the users, so that it can be an influential voice in the design and priorities of development. It can be very tricky to set up (it's easy to tell who is a developer, not so easy to tell who is a user). People interested in the user committee should really raise that subject on the Foundation mailing-list so that this representativity and relevance is ensured. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Hi, On Sat, Jul 14, 2012 at 1:51 PM, Andrew Clay Shafer a...@parvuscaptus.comwrote: I disagree with your last point, it is true if we look only into this particular problem, but if you look into the whole ecosystem you'll realize that the code removal of nova-volumes is not the only change from essex to folsom.. if we had deprecated all other changes, this particular one would not be painful at all. I'm not sure what you are disagreeing with or advocating. We should expect code to change between releases, no? Sure! As this thread demonstrated, we collectively have done a poor job of communicating and managing those changes. It is precisely because I expect more changes that I state that option 2 is postponing risks, not lowering them. I'm not saying you are wrong, or that my assumptions are correct, but I don't understand what you disagree with. Ok, I'll try to explain: I don't disagree when you say that we are postponing risks, maybe you're also right about confusing operators, my point is that it's one more non optional change (I'm not separating deployment from usage here). [...] On the question of compatibility, my assumption is this a non-issue for the moment. I believe it wouldn't be an issue if people were not using OpenStack, but we are.. I thought it was clear from the context of the thread and my email that compatibility in this case is in reference to the consumers of the API and not to the differences for managing deployments. Sorry, I read it again and that makes sense. On the question of an upgrade path and the relative ease of deployment, my assumption is this is no worse than any of the other upgrades. It doesn't really mean a good thing, since I don't think that the others upgrades were good, based on what I heard and experienced with sysadmins from my team... I totally agree that it's not a good thing. Do we believe that keeping nova-volumes will make it painless? I don't, as I said before (don't recall where), I think the problem is the whole, a lot of stuff changes without any deprecations, this change is just one more. I don't want to blame anyone by this, even the comunity, I just think we should go smoothly on upgrades. [...] In specific, I think getting more information from operators and users is generally good. Ultimately, if OpenStack cannot be operated and utilized, the mission will fail. I agree! (finally :P) I also think that it's our responsibility (as developers) to ask for input from operators, it's not because they are not complaining that things are going smoothly. We should ask for every one we know who's working with OpenStack and do our best to get feedback. Definitely! There are also different sets of unstated assumptions about what OpenStack is or should be that have to be resolved or we are going to keep running into these type of situations. Those definitely create the situation we are facing, but they aren't unique to Cinder/Volumes, so I will start another thread. Great :) Regards, -- Flavia ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Hi, On Fri, Jul 13, 2012 at 9:20 PM, Andrew Clay Shafer a...@parvuscaptus.comwrote: [...] In this particular case, I chose option 1 under the following assumptions (which may be wrong): - the api for the end user would not change - the code for the service is essentially the same, it is just being renamed - option 2 doesn't lower risk or burden for anyone, it just postpones them, while increasing complexity, confusion and future burdens for core development and probably operators as well I disagree with your last point, it is true if we look only into this particular problem, but if you look into the whole ecosystem you'll realize that the code removal of nova-volumes is not the only change from essex to folsom.. if we had deprecated all other changes, this particular one would not be painful at all. [...] On the question of compatibility, my assumption is this a non-issue for the moment. I believe it wouldn't be an issue if people were not using OpenStack, but we are.. On the question of an upgrade path and the relative ease of deployment, my assumption is this is no worse than any of the other upgrades. It doesn't really mean a good thing, since I don't think that the others upgrades were good, based on what I heard and experienced with sysadmins from my team... [...] In specific, I think getting more information from operators and users is generally good. Ultimately, if OpenStack cannot be operated and utilized, the mission will fail. I agree! (finally :P) I also think that it's our responsibility (as developers) to ask for input from operators, it's not because they are not complaining that things are going smoothly. We should ask for every one we know who's working with OpenStack and do our best to get feedback. Regards, -- Flavia ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
I disagree with your last point, it is true if we look only into this particular problem, but if you look into the whole ecosystem you'll realize that the code removal of nova-volumes is not the only change from essex to folsom.. if we had deprecated all other changes, this particular one would not be painful at all. I'm not sure what you are disagreeing with or advocating. We should expect code to change between releases, no? As this thread demonstrated, we collectively have done a poor job of communicating and managing those changes. It is precisely because I expect more changes that I state that option 2 is postponing risks, not lowering them. I'm not saying you are wrong, or that my assumptions are correct, but I don't understand what you disagree with. [...] On the question of compatibility, my assumption is this a non-issue for the moment. I believe it wouldn't be an issue if people were not using OpenStack, but we are.. I thought it was clear from the context of the thread and my email that compatibility in this case is in reference to the consumers of the API and not to the differences for managing deployments. On the question of an upgrade path and the relative ease of deployment, my assumption is this is no worse than any of the other upgrades. It doesn't really mean a good thing, since I don't think that the others upgrades were good, based on what I heard and experienced with sysadmins from my team... I totally agree that it's not a good thing. Do we believe that keeping nova-volumes will make it painless? [...] In specific, I think getting more information from operators and users is generally good. Ultimately, if OpenStack cannot be operated and utilized, the mission will fail. I agree! (finally :P) I also think that it's our responsibility (as developers) to ask for input from operators, it's not because they are not complaining that things are going smoothly. We should ask for every one we know who's working with OpenStack and do our best to get feedback. Definitely! There are also different sets of unstated assumptions about what OpenStack is or should be that have to be resolved or we are going to keep running into these type of situations. Those definitely create the situation we are facing, but they aren't unique to Cinder/Volumes, so I will start another thread. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Apologies if this has already been proposed, but how about an option 3 (perhaps more accurately option 2.5): We already have a process for maintaining code in one project and occasionally copying it to another project. Namely, code is maintained in openstack-common and then -- at appropriate times -- gets copied to Nova or Glance or whatever. Correct? Seeing as Cinder is supposedly a straight copy of Nova volume, it seems feasible to occasionally copy it all back into Nova. This way, it's not a matter of fixing bugs (and adding features and whatever) twice, but rather fixing bugs (and adding features and whatever) once and the rest is straight-forward (possibly even easily scriptable) patch management. Obviously, this wouldn't happen indefinitely, but simply serve to bridge the gap between those who want to split it out (with which I can certainly sympathise) and those who want to keep it Nova for Folsom (which I can also sort of relate to). -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
George Reese wrote: How many years has it been? [...] The answer to those questions is: - 3 It's been 2 years, actually. Feels like 3 years, I know. We are still maturing, obviously. But seeing the discussions we had at the last design summit, I think that we are improving. We are now raising the right topics. Now we need to align the participating companies resources priorities with the objectives we identify. As an example, at the last design summit we discussed and identified the need to support rolling upgrades for Nova (deployments that are running multiple versions of Nova at the same time). We even outlined a plan. But not so many developers showed up to work on that specific feature. OpenStack can't assign resources. In the end you need participating companies to care enough to assign people to do it. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Matt Joyce wrote: To certain extent I agree with george's sentiment. Recent example... we're changing tenants to projects in the keystone api. Yes we maintain v2 api compatibility but there will be a cost to users in the confusion of decisions like this. George is right to be calling for openstack to grow up. I agree that technical decisions tend to be weighted towards developers, which is precisely the reason why this thread was open on the mailing-list, rather than silently decided by a PPB. We needed to hear from users in that specific matter, to weigh the real drawbacks of the options we had. That said, being offensive and not constructive actually weakens that party and makes your opinion less likely to prevail. There is no excuse for going beyond the line. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
+1 to Vish's proposal I'd go a step further and suggest adopt this model for such changes going forward. Chris Sent from my iPad On Jul 12, 2012, at 5:40 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: On Jul 12, 2012, at 2:36 PM, David Mortman wrote: On Thu, Jul 12, 2012 at 3:38 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: Two thoughts: 1) I think this is the wrong forum to poll operators on their preferences in general 2) We don't yet even have a fully laid out set of requirements and steps for how someone would convert or how hard it will be. Historically (with openstack and software in general), it is _always_ harder to upgrade then we think it will be. I'm an optimist and I think it will be a disaster... Excellent points. Let me make the following proposal: 1) Leave the code in nova-volume for now. 2) Document and test a clear migration path to cinder. 3) Take the working example upgrade to the operators list and ask them for opinions. 4) Decide based on their feedback whether it is acceptable to cut the nova-volume code out for folsom. Vish___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
This is exactly the sort of interaction we need between the two perspectives of the OpenStack community. Thanks Chris Sent from my iPad On Jul 12, 2012, at 11:20 PM, Joe Topjian joe.topj...@cybera.ca wrote: Hello, I'm not an OpenStack developer nor any type of developer. I am, however, heavily involved with operations for a few production OpenStack environments. I understand the debate going on and wanted to add an administrator's point of view. For admins, OpenStack is not our job, but a tool we use in our job. It's terribly frustrating when that tool drastically changes every six months. I find Gabriel's reply interesting and sane. I think if it was agreed upon to ensure N+1 compatibility, then OpenStack should adhere to that. The change being discussed involves storage volumes. This is dead serious. If the migration goes awry, there's potential for production data loss. If the badly-migrated OpenStack environment is used to offer services for outside customers, we've just lost data for those customers. It's one of the worst scenarios for admins. If upgrading from one version of OpenStack to the next is too dangerous due to the possibility of getting into situations such as described above, then it needs to be clearly announced. There's a reason why major RHEL releases are maintained in parallel for so long. With regard to Option 1, I understand the benefits of making this change. If Option 1 was chosen, IMO, the best-case scenario would be if the extra work involved with upgrading to Cinder/Folsom was just a schema migration and everything else still worked as it did with Essex. If this were to happen, though, I would spend /weeks/ testing and planning the Folsom upgrade. I'd estimate that my production environments would make it to Folsom 3 months after it was released. But then what major change am I going to have to worry about in another 3 months? Thanks, Joe On Thu, Jul 12, 2012 at 2:48 PM, Gabriel Hurley gabriel.hur...@nebula.com wrote: The stated and agreed-upon goal from Essex forward is to make the core OpenStack projects N+1 compatible (e.g. Essex-Folsom, Folsom-Grizzly), and to make the clients capable of talking to every API version forever. Anything standing in the way of that should be considered a release-blocking bug, and should be filed against the appropriate projects. I for one intend to see to that as best I can. That said, there *is* a grey area around “migration” steps like Nova Volume - Cinder. If the migration path is clear, stable, well-documented, uses the same schemas and same APIs… I’d say that *may* still fall into the category of N+1 compatible. It sounds like that’s the idea here, but that we need to thoroughly vet the practicality of that assertion. I don’t think we can decide this without proof that the clean transition is 100% possible. Code isn’t the only thing of value; constructively and respectfully shaping design decisions is great, testing and filing bugs is also fantastic. Profanity and disrespect are not acceptable. Ever. All the best, - Gabriel -- Joe Topjian Systems Administrator Cybera Inc. www.cybera.ca Cybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Sent from my iPad On Jul 13, 2012, at 12:41 AM, Blake Yeager blake.yea...@gmail.com wrote: snip I am excited to see such passion from the community but we need to make sure that passion is directed in a constructive manner. +1 Chris___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
It would seem that those voting for option 1 do so primarily from a code hygiene and maintenance perspective. If code hygiene were the only issue this would make sense. But for those of us with a production environment going straight from Nova-volumes to a full Cinder deployment is too big a step. From an operational perspective integrating multiple new things at the same time is too high risk. Not only does all of the code have to work together but all of the operational services for standing up a Cinder production service need to be in place and working. This is too risky for people with services in production. I believe we need to have an approach that provides a migration path that will allow systems in production migrate from Nova-volumes in Folsom to a Cinder based production in a reliable and incremental way. From HP’s perspective we need option #2. I think the code maintenance issue can me ameliorated by just freezing the Nova-Volumes code in Folsom. This will incentivize people to move off it, but will allow them to do it in a way that supports production services. Tim From: openstack-bounces+tim.reddin=hp@lists.launchpad.net [mailto:openstack-bounces+tim.reddin=hp@lists.launchpad.net] On Behalf Of Shake Chen Sent: 12 July 2012 01:31 To: Renuka Apte Cc: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom option 1. On Thu, Jul 12, 2012 at 7:10 AM, Renuka Apte renuka.a...@citrix.commailto:renuka.a...@citrix.com wrote: It would be great if anyone who is already deploying Openstack, even if in non-production environments, could give cinder a try. For a test environment, it seems easy enough to make the switch using devstack (I have verified this with XenServer, and I believe, John and folks at Rackspace have tried on KVM). Of course, only when more people start trying it will we get a realistic picture. Thanks, Renuka. From: Flavia Missi [mailto:flaviami...@gmail.commailto:flaviami...@gmail.com] Sent: Wednesday, July 11, 2012 12:56 PM To: Renuka Apte Cc: Vishvananda Ishaya; Openstack (openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net) (openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net) Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom For me it's +1 to 1, but... Here at Globo.com we're already deploying clouds based on openstack (not in production yet, we have dev and lab), and it's really painful when openstack just forces us to change, I mean, sysadmins are not that happy, so I think it's more polite if we warn them in Folsom, and remove everything next. Maybe this way nobody's going to fear the update. It also make us lose the chain of thought.. you're learning, and suddenly you have to change something for an update, and then you come back to what you we're doing... Anyway... :) Thanks, On Wed, Jul 11, 2012 at 3:09 PM, Renuka Apte renuka.a...@citrix.commailto:renuka.a...@citrix.com wrote: +1 for 1 On 11/07/12 8:26 AM, Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On 07/12/2012 03:54 PM, George Reese wrote: This community needs offending. This is your opinion and you're entitled to it but let me assure you that *nobody* here wants to be offended by you. This community is made of smart people that deserve respect: stop offending them, now. Make your point in a civil way and try to build consensus around it: that's how this community operates. /stef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Because the community has done such a good job in the area of interoperability and compatibility over the past few years that it thus deserves the benefit of the doubt even though we have a thread previously showing blatant disregard for such concerns? No, this community has, by and large, been overtly hostile to concerns of interoperability and compatibility and I jumped into this thread exactly because it was in active expression of that ongoing overt hostility. As I said before, that needs to change. If you don't like my methods, oh well. But this is a serious problem that is a distinct threat to the viability of OpenStack. Much, much, much more so than whether block storage is represented by the nova-volumes model or the Cinder model. Having said that, I believe I've made my point. I think the net result is that some people better understand the pain caused by the lack of OpenStack interoperability and compatibility, and others are still interested in just paying it lips service. We'll see what wins out come GA of Folsom, won't we? -George On Jul 13, 2012, at 10:47 AM, Stefano Maffulli wrote: On 07/12/2012 03:54 PM, George Reese wrote: This community needs offending. This is your opinion and you're entitled to it but let me assure you that *nobody* here wants to be offended by you. This community is made of smart people that deserve respect: stop offending them, now. Make your point in a civil way and try to build consensus around it: that's how this community operates. /stef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Disagreements and misunderstanding concerning etiquette and upgrading Cassandra aside, this thread has three major themes: 1) the relative ease or burden of upgrade paths 2) compatibility between versions and 3) what OpenStack values when making decisions. I believe the first two hinge on the third and the overriding theme is how do the inevitable burdens of the choices made impact individuals and organizations. OpenStack choices impact at least these different personas across different organizations: core, operators and consumers. Those groups can obviously be segmented further. Work in core has been done by individuals with a wide range of motives and interests. Operators are in stages of deploying and supporting services of various shapes and sizes. Consumers represent everyone trying to integrate or use OpenStack in one or all of it's incarnations. Some people fit into more than one of these groups. The last two groups are clearly under represented in OpenStack decision making across the board. This impacts every decision from what code gets written to how releases are scheduled and gated. I personally believe this imbalance seriously jeopardizes the stated OpenStack mission. In this particular case, I chose option 1 under the following assumptions (which may be wrong): - the api for the end user would not change - the code for the service is essentially the same, it is just being renamed - option 2 doesn't lower risk or burden for anyone, it just postpones them, while increasing complexity, confusion and future burdens for core development and probably operators as well Under these assumptions, the impact on users would be negligible if any, and for the operators of existing deployments the burden is copying a database, changing some configurations and starting some services. Data and consequently storage should arguably be the most important thing in the hierarchy of priorities. Any risk of losing user data should be given the highest consideration. My assumption was that this could be applied to running deployments without risk of data loss. On the question of compatibility, my assumption is this a non-issue for the moment. On the question of an upgrade path and the relative ease of deployment, my assumption is this is no worse than any of the other upgrades. On the question of how we make decisions as a community and how they are perceived in the ecosystem at large, I believe this thread reveals more questions than answers. These assumptions could be totally wrong. If they are correct, I still advocate option 1. If they are wrong, or the preponderance of support is for option 2, I would support that and hope we collectively attempt to mitigate the complexity and confusion by over communicating with the community and each other. In specific, I think getting more information from operators and users is generally good. Ultimately, if OpenStack cannot be operated and utilized, the mission will fail. I'd hope that doesn't have to be done in a reactionary way and we can collectively get better at considering the cascading impacts of the choices we make both for operators, users and also across projects. I don't agree with George Reese on every point and he clearly knows nothing about Cassandra, but I don't have a problem with his message or his language choices. In this case, he is in a position to provide valuable insights into the current state of the OpenStack ecosystem, both relative to itself and most other cloud platforms. He's only mad because he cares. I prefer that to silent apathy. For the future, OpenStack has to come to terms with what it wants to be when it grows up. API compatibility should not be taken lightly. It doesn't mean things can't change, for me it means being mindful about how things are versioned and communicated. This is all about attitude and discipline. Ease of deployment and operations has been left as an exercise for the reader. Configuration management and packaging is something people understand to various degrees. Reliability and availability have been left up to deployment specific architectural choices. API end points can be scaled like any http service. Scaling up and scaling out relational databases is something people know how to do. There are technically more sophisticated ways to handle many of these issues by giving them more consideration in the projects and making openstack services more aware of themselves and each other. These changes would be a considerable undertaking and should not be taken lightly. So far, we haven't collectively had the patience or stomach to move in this direction, and in some places where progress has been made, it hasn't been pushed back upstream for a variety of reasons, real or imagined. I personally hope OpenStack will one day be able to deploy itself on bare metal and sensibly adding or removing capacity is relatively trivial compared to today. As for community, I am personally disappointed by
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
We've got volumes in production, and while I'd be more comfortable with option 2 for the reasons you list below, plus the fact that cinder is fundamentally new code with totally new HA and reliability work needing to be done (particularly for the API endpoint), it sounds like the majority is strongly favouring option 1... -- Duncan Thomas HP Cloud Services, Galway From: openstack-bounces+duncan.thomas=hp@lists.launchpad.net [mailto:openstack-bounces+duncan.thomas=hp@lists.launchpad.net] On Behalf Of Flavia Missi Sent: 11 July 2012 20:56 To: Renuka Apte Cc: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom For me it's +1 to 1, but... Here at Globo.com we're already deploying clouds based on openstack (not in production yet, we have dev and lab), and it's really painful when openstack just forces us to change, I mean, sysadmins are not that happy, so I think it's more polite if we warn them in Folsom, and remove everything next. Maybe this way nobody's going to fear the update. It also make us lose the chain of thought.. you're learning, and suddenly you have to change something for an update, and then you come back to what you we're doing... -- Flavia ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On 07/12/2012 10:36 AM, Thomas, Duncan wrote: We’ve got volumes in production, and while I’d be more comfortable with option 2 for the reasons you list below, plus the fact that cinder is fundamentally new code with totally new HA and reliability work needing to be done (particularly for the API endpoint), it sounds like the majority is strongly favouring option 1… Actually, I believe Cinder is essentially a bit-for-bit copy of nova-volumes. John G, is that correct? It's this similarity that really makes option 1 feasible. If the codebases (and API) were radically different, removal like this would be much more difficult IMHO. Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Thu, Jul 12, 2012 at 9:28 AM, Jay Pipes jaypi...@gmail.com wrote: On 07/12/2012 10:36 AM, Thomas, Duncan wrote: We’ve got volumes in production, and while I’d be more comfortable with option 2 for the reasons you list below, plus the fact that cinder is fundamentally new code with totally new HA and reliability work needing to be done (particularly for the API endpoint), it sounds like the majority is strongly favouring option 1… Actually, I believe Cinder is essentially a bit-for-bit copy of nova-volumes. John G, is that correct? Yes, that's correct, and as you state it's really the only reason that option 1 is feasible and also why in my opinion it's the best option. It's this similarity that really makes option 1 feasible. If the codebases (and API) were radically different, removal like this would be much more difficult IMHO. Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
We currently have a large deployment that is based on nova-volume as it is in trunk today, and just ripping it out will be quite painful. For us, option #2 is the only suitable option. We need a smooth migration path, and time to successfuly migrate to Cinder. Since there is no clear migration path between Openstack Nova releases, we have to track very close to trunk. The rapid change of nova and nova-volume trunk has already been a very difficult task. Ripping nova-volume out of nova would bring us to a standstill until we could migrate to Cinder. Cinder has made great strides to get where it is today, but I really hope we, the Openstack community, will take the time to consider the ramifications, and make sure that we take the time needed to ensure both a successful release of Cinder and a successful transition from nova-volume to Cinder. -- Chuck ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On 07/12/2012 12:32 PM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? a) Please don't be inappropriate on the mailing list b) Vish sent the email below to the mailing list *precisely because* he cares about compatibility. He wants to discuss the options with the community and come up with a reasonable action plan with the Cinder PTL, John Griffith for the move Now, would you care to be constructive with your criticism? Thanks, -jay On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.com mailto:george.re...@enstratus.com Skype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com http://www.enstratus.com/ To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Clearly, going forward, we want to be more deliberate about changes that may have impact on operations and he broader ecosystem that bases its efforts on assumptions established at the start of a release cycle, rather than on changes introduced late in the cycle. Cheers Chris Sent from my iPad On Jul 12, 2012, at 2:24 PM, George Reese george.re...@enstratus.com wrote: Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReese p: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
I certainly wasn't picking on Vish, but instead the entire community so eagerly interested in option #1. You see, the OpenStack community has a perfect record of making sure stuff like that ends up breaking everyone between upgrades. So, if you take offense by my comments… err, well, I'm not at all sorry. It's time for this community to grow the hell up and make sure systems upgrade nicely now and forever and that OpenStack environments are actually compatible with one another. Hell, I still find Essex environments that aren't even API compatible with one another. You have the Rackspace CTO wandering around conferences talking about how the value proposition of OpenStack is interoperability among clouds and yet you can't even get interoperability within the same OpenStack distribution of the same OpenStack version. I smell a pile of bullshit and the community just keeps shoveling. -George On Jul 12, 2012, at 12:22 PM, Jay Pipes wrote: On 07/12/2012 12:32 PM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? a) Please don't be inappropriate on the mailing list b) Vish sent the email below to the mailing list *precisely because* he cares about compatibility. He wants to discuss the options with the community and come up with a reasonable action plan with the Cinder PTL, John Griffith for the move Now, would you care to be constructive with your criticism? Thanks, -jay On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.com mailto:george.re...@enstratus.com Skype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com http://www.enstratus.com/ To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
You evidently have not had to live with the interoperability nightmare known as OpenStack in the same way I have. Otherwise, you would find responses like Brian's much more offensive. -George On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote: This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Clearly, going forward, we want to be more deliberate about changes that may have impact on operations and he broader ecosystem that bases its efforts on assumptions established at the start of a release cycle, rather than on changes introduced late in the cycle. Cheers Chris Sent from my iPad On Jul 12, 2012, at 2:24 PM, George Reese george.re...@enstratus.com wrote: Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReese p: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
What exactly was so offensive about what I said? Communities like OpenStack are built on top of people *doing* things, not *talking* about things. I'm just asking you to contribute code or design help rather than slanderous commentary. Brian Offensive Waldon On Jul 12, 2012, at 11:59 AM, George Reese wrote: You evidently have not had to live with the interoperability nightmare known as OpenStack in the same way I have. Otherwise, you would find responses like Brian's much more offensive. -George On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote: This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Clearly, going forward, we want to be more deliberate about changes that may have impact on operations and he broader ecosystem that bases its efforts on assumptions established at the start of a release cycle, rather than on changes introduced late in the cycle. Cheers Chris Sent from my iPad On Jul 12, 2012, at 2:24 PM, George Reese george.re...@enstratus.com wrote: Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont:
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
So if Im not coding, I should shut up? I think you answered your own question. Sent from my iPhone On Jul 12, 2012, at 14:10, Brian Waldon brian.wal...@rackspace.com wrote: What exactly was so offensive about what I said? Communities like OpenStack are built on top of people *doing* things, not *talking* about things. I'm just asking you to contribute code or design help rather than slanderous commentary. Brian Offensive Waldon On Jul 12, 2012, at 11:59 AM, George Reese wrote: You evidently have not had to live with the interoperability nightmare known as OpenStack in the same way I have. Otherwise, you would find responses like Brian's much more offensive. -George On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote: This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Clearly, going forward, we want to be more deliberate about changes that may have impact on operations and he broader ecosystem that bases its efforts on assumptions established at the start of a release cycle, rather than on changes introduced late in the cycle. Cheers Chris Sent from my iPad On Jul 12, 2012, at 2:24 PM, George Reese george.re...@enstratus.com wrote: Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype:
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Planning the development of the projects is valuable as well as contributing code. If you review my last message, you'll see the words '... or design help', which I intended to represent non-code contribution. You seem to have strong opinions on how things should be done, but I don't see your voice in any of the community discussions. Moving forward, I wish you would share your expertise in a constructive manner. Keep in mind this list reaches 2200 people. Let's not waste anyone's time. WALDON On Jul 12, 2012, at 12:14 PM, George Reese wrote: So if Im not coding, I should shut up? I think you answered your own question. Sent from my iPhone On Jul 12, 2012, at 14:10, Brian Waldon brian.wal...@rackspace.com wrote: What exactly was so offensive about what I said? Communities like OpenStack are built on top of people *doing* things, not *talking* about things. I'm just asking you to contribute code or design help rather than slanderous commentary. Brian Offensive Waldon On Jul 12, 2012, at 11:59 AM, George Reese wrote: You evidently have not had to live with the interoperability nightmare known as OpenStack in the same way I have. Otherwise, you would find responses like Brian's much more offensive. -George On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote: This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Clearly, going forward, we want to be more deliberate about changes that may have impact on operations and he broader ecosystem that bases its efforts on assumptions established at the start of a release cycle, rather than on changes introduced late in the cycle. Cheers Chris Sent from my iPad On Jul 12, 2012, at 2:24 PM, George Reese george.re...@enstratus.com wrote: Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
This ain't the first time I've had a run in with you where your response was essentially if you don't like it, go code it. And obviously you missed the entire constructive point in my response. It's this: The proposed options suck. It's too late to do anything about that as this ship has sailed. What you need to understand going forward is that this community has an abysmal history when it comes to compatibility and interoperability. Abysmal. Not checkered. Not patchy. Not lacking. Abysmal. Horizontally. Vertically. Abysmal. Actually, shockingly abysmal. You saw one public response laughing at me for expecting this community to care about compatibility. I also received private responses with the same sentiment. If you guys really think you care about compatibility, you need to go sit in a corner and do some heavy thinking. Because the history of this project and this thread in particular suggest otherwise. In case you missed it again, here it is in a single sentence: The constructive point I am making is that it's time to wake up and get serious about compatibility and interoperability. -George On Jul 12, 2012, at 2:27 PM, Brian Waldon wrote: Planning the development of the projects is valuable as well as contributing code. If you review my last message, you'll see the words '... or design help', which I intended to represent non-code contribution. You seem to have strong opinions on how things should be done, but I don't see your voice in any of the community discussions. Moving forward, I wish you would share your expertise in a constructive manner. Keep in mind this list reaches 2200 people. Let's not waste anyone's time. WALDON On Jul 12, 2012, at 12:14 PM, George Reese wrote: So if Im not coding, I should shut up? I think you answered your own question. Sent from my iPhone On Jul 12, 2012, at 14:10, Brian Waldon brian.wal...@rackspace.com wrote: What exactly was so offensive about what I said? Communities like OpenStack are built on top of people *doing* things, not *talking* about things. I'm just asking you to contribute code or design help rather than slanderous commentary. Brian Offensive Waldon On Jul 12, 2012, at 11:59 AM, George Reese wrote: You evidently have not had to live with the interoperability nightmare known as OpenStack in the same way I have. Otherwise, you would find responses like Brian's much more offensive. -George On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote: This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Clearly, going forward, we want to be more deliberate about changes that may have impact on operations and he broader ecosystem that bases its efforts on assumptions established at the start of a release cycle, rather than on changes introduced late in the cycle. Cheers Chris Sent from my iPad On Jul 12, 2012, at 2:24 PM, George Reese george.re...@enstratus.com wrote: Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Jul 12, 2012, at 11:48 AM, Christopher B Ferris wrote: This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Agreed, I'm a developer, so I'm clearly biased towards what is easier for developers. It will be a significant effort to have to maintain the nova-volume code, so I want to be sure it is necessary. End users really shouldn't care about this, so the other community members who are impacted are operators. I really would like more feedback on how painful it will be for operators if we force them to migrate. We have one clear response from Chuck, which is very helpful. Is there anyone else out there running nova-volume that would prefer to keep it when they move to folsom? Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
George, I am relatively new to this mailing list so I assume that there is some history that is prompting the vehemence but I do not understand what you are trying to accomplish. Vish sent out two proposed ways for dealing with the migration. Most of the early voting (including mine) has been for option #1 (happy to explain why if desired) but it isn't like the discussion is over. If you believe that option #2 is better, please explain why you believe that. If you believe that there is a 3rd option, please explain it to us. You are complaining without offering a counter proposal. That is simply not effective and makes semi-neutral folks (like me) tend to discard your point of view (which I assume is not your objective). -Jon From: George Reese george.re...@enstratus.commailto:george.re...@enstratus.com Date: Thursday, July 12, 2012 10:14 AM To: Brian Waldon brian.wal...@rackspace.commailto:brian.wal...@rackspace.com Cc: Openstack (openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net) (openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net) openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.commailto:george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
To certain extent I agree with george's sentiment. Recent example... we're changing tenants to projects in the keystone api. Yes we maintain v2 api compatibility but there will be a cost to users in the confusion of decisions like this. George is right to be calling for openstack to grow up. That's my personal opinion. -Matt On Thu, Jul 12, 2012 at 11:55 AM, George Reese george.re...@enstratus.comwrote: I certainly wasn't picking on Vish, but instead the entire community so eagerly interested in option #1. You see, the OpenStack community has a perfect record of making sure stuff like that ends up breaking everyone between upgrades. So, if you take offense by my comments… err, well, I'm not at all sorry. It's time for this community to grow the hell up and make sure systems upgrade nicely now and forever and that OpenStack environments are actually compatible with one another. Hell, I still find Essex environments that aren't even API compatible with one another. You have the Rackspace CTO wandering around conferences talking about how the value proposition of OpenStack is interoperability among clouds and yet you can't even get interoperability within the same OpenStack distribution of the same OpenStack version. I smell a pile of bullshit and the community just keeps shoveling. -George On Jul 12, 2012, at 12:22 PM, Jay Pipes wrote: On 07/12/2012 12:32 PM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? a) Please don't be inappropriate on the mailing list b) Vish sent the email below to the mailing list *precisely because* he cares about compatibility. He wants to discuss the options with the community and come up with a reasonable action plan with the Cinder PTL, John Griffith for the move Now, would you care to be constructive with your criticism? Thanks, -jay On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.com mailto:george.re...@enstratus.comgeorge.re...@enstratus.com Skype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com http://www.enstratus.com/ To schedule a meeting with me: http://tungle.me/GeorgeReese
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
You are mistaking me for caring about the answer to this question. This ship has sailed. We are faced with two shitty choices as a result of continued lack of concern by this community for compatibility. History? I've been pounding my head against the OpenStack all for years on compatibility and we end up AGAIN in a situation like this where we have two shitty options. I'm not offering an opinion or a third option because I just don't give a damn what option is picked since both will suck. I'm trying to get everyone to get their heads out of their asses and not stick us yet against in this situation in the future. You can discard my position if you want. I really don't give a damn. I just happen to work with a wider variety of OpenStack environments that most others on the list. But whatever. -George On Jul 12, 2012, at 2:40 PM, Jon Mittelhauser wrote: George, I am relatively new to this mailing list so I assume that there is some history that is prompting the vehemence but I do not understand what you are trying to accomplish. Vish sent out two proposed ways for dealing with the migration. Most of the early voting (including mine) has been for option #1 (happy to explain why if desired) but it isn't like the discussion is over. If you believe that option #2 is better, please explain why you believe that. If you believe that there is a 3rd option, please explain it to us. You are complaining without offering a counter proposal. That is simply not effective and makes semi-neutral folks (like me) tend to discard your point of view (which I assume is not your objective). -Jon From: George Reese george.re...@enstratus.com Date: Thursday, July 12, 2012 10:14 AM To: Brian Waldon brian.wal...@rackspace.com Cc: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) openstack@lists.launchpad.net Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
How can I disregard a position that you don't have? (or at least I don't understand yet) You have failed to provide a position. Like I said, I'm fairly new to OpenStack….but I am *very* experienced in open source and operating very large and complex production systems… so I am trying to come up to speed and understand your position… Separating out the volume code from the compute code seems like a no-brainer thing that needed to be done. Do you disagree with that basic premise (e.g. That Cinder should exist)? Do you disagree with the way that it was done (e.g. How Cinder is written)? Or do you disagree with the migration strategies proposed (which is what Vish's email was opening discussion about)? Or…?? -Jon From: George Reese george.re...@enstratus.commailto:george.re...@enstratus.com Date: Thursday, July 12, 2012 12:47 PM To: Jon Mittelhauser jon.mittelhau...@nebula.commailto:jon.mittelhau...@nebula.com Cc: Brian Waldon brian.wal...@rackspace.commailto:brian.wal...@rackspace.com, Openstack (openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net) (openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net) openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom You are mistaking me for caring about the answer to this question. This ship has sailed. We are faced with two shitty choices as a result of continued lack of concern by this community for compatibility. History? I've been pounding my head against the OpenStack all for years on compatibility and we end up AGAIN in a situation like this where we have two shitty options. I'm not offering an opinion or a third option because I just don't give a damn what option is picked since both will suck. I'm trying to get everyone to get their heads out of their asses and not stick us yet against in this situation in the future. You can discard my position if you want. I really don't give a damn. I just happen to work with a wider variety of OpenStack environments that most others on the list. But whatever. -George On Jul 12, 2012, at 2:40 PM, Jon Mittelhauser wrote: George, I am relatively new to this mailing list so I assume that there is some history that is prompting the vehemence but I do not understand what you are trying to accomplish. Vish sent out two proposed ways for dealing with the migration. Most of the early voting (including mine) has been for option #1 (happy to explain why if desired) but it isn't like the discussion is over. If you believe that option #2 is better, please explain why you believe that. If you believe that there is a 3rd option, please explain it to us. You are complaining without offering a counter proposal. That is simply not effective and makes semi-neutral folks (like me) tend to discard your point of view (which I assume is not your objective). -Jon From: George Reese george.re...@enstratus.commailto:george.re...@enstratus.com Date: Thursday, July 12, 2012 10:14 AM To: Brian Waldon brian.wal...@rackspace.commailto:brian.wal...@rackspace.com Cc: Openstack (openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net) (openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net) openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
I don't think Cinder should exist. Sometimes you have to live with the technical debt because that's the best way to preserve the investment your customers have made in your product. Or if you're very smart, you find a way to refactor that technical debt invisibly to customers. But you don't make the customer carry the burden of your refactoring technical debt. -George On Jul 12, 2012, at 2:52 PM, Jon Mittelhauser wrote: How can I disregard a position that you don't have? (or at least I don't understand yet) You have failed to provide a position. Like I said, I'm fairly new to OpenStack….but I am *very* experienced in open source and operating very large and complex production systems… so I am trying to come up to speed and understand your position… Separating out the volume code from the compute code seems like a no-brainer thing that needed to be done. Do you disagree with that basic premise (e.g. That Cinder should exist)? Do you disagree with the way that it was done (e.g. How Cinder is written)? Or do you disagree with the migration strategies proposed (which is what Vish's email was opening discussion about)? Or…?? -Jon From: George Reese george.re...@enstratus.com Date: Thursday, July 12, 2012 12:47 PM To: Jon Mittelhauser jon.mittelhau...@nebula.com Cc: Brian Waldon brian.wal...@rackspace.com, Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) openstack@lists.launchpad.net Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom You are mistaking me for caring about the answer to this question. This ship has sailed. We are faced with two shitty choices as a result of continued lack of concern by this community for compatibility. History? I've been pounding my head against the OpenStack all for years on compatibility and we end up AGAIN in a situation like this where we have two shitty options. I'm not offering an opinion or a third option because I just don't give a damn what option is picked since both will suck. I'm trying to get everyone to get their heads out of their asses and not stick us yet against in this situation in the future. You can discard my position if you want. I really don't give a damn. I just happen to work with a wider variety of OpenStack environments that most others on the list. But whatever. -George On Jul 12, 2012, at 2:40 PM, Jon Mittelhauser wrote: George, I am relatively new to this mailing list so I assume that there is some history that is prompting the vehemence but I do not understand what you are trying to accomplish. Vish sent out two proposed ways for dealing with the migration. Most of the early voting (including mine) has been for option #1 (happy to explain why if desired) but it isn't like the discussion is over. If you believe that option #2 is better, please explain why you believe that. If you believe that there is a 3rd option, please explain it to us. You are complaining without offering a counter proposal. That is simply not effective and makes semi-neutral folks (like me) tend to discard your point of view (which I assume is not your objective). -Jon From: George Reese george.re...@enstratus.com Date: Thursday, July 12, 2012 10:14 AM To: Brian Waldon brian.wal...@rackspace.com Cc: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) openstack@lists.launchpad.net Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Thu, Jul 12, 2012 at 1:14 PM, George Reese george.re...@enstratus.com wrote: So if Im not coding, I should shut up? I think you answered your own question. Sent from my iPhone On Jul 12, 2012, at 14:10, Brian Waldon brian.wal...@rackspace.com wrote: What exactly was so offensive about what I said? Communities like OpenStack are built on top of people *doing* things, not *talking* about things. I'm just asking you to contribute code or design help rather than slanderous commentary. Brian Offensive Waldon On Jul 12, 2012, at 11:59 AM, George Reese wrote: You evidently have not had to live with the interoperability nightmare known as OpenStack in the same way I have. Otherwise, you would find responses like Brian's much more offensive. -George On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote: This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Clearly, going forward, we want to be more deliberate about changes that may have impact on operations and he broader ecosystem that bases its efforts on assumptions established at the start of a release cycle, rather than on changes introduced late in the cycle. Cheers Chris Sent from my iPad On Jul 12, 2012, at 2:24 PM, George Reese george.re...@enstratus.com wrote: Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe :
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
The stated and agreed-upon goal from Essex forward is to make the core OpenStack projects N+1 compatible (e.g. Essex-Folsom, Folsom-Grizzly), and to make the clients capable of talking to every API version forever. Anything standing in the way of that should be considered a release-blocking bug, and should be filed against the appropriate projects. I for one intend to see to that as best I can. That said, there *is* a grey area around migration steps like Nova Volume - Cinder. If the migration path is clear, stable, well-documented, uses the same schemas and same APIs... I'd say that *may* still fall into the category of N+1 compatible. It sounds like that's the idea here, but that we need to thoroughly vet the practicality of that assertion. I don't think we can decide this without proof that the clean transition is 100% possible. Code isn't the only thing of value; constructively and respectfully shaping design decisions is great, testing and filing bugs is also fantastic. Profanity and disrespect are not acceptable. Ever. All the best, - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of George Reese Sent: Thursday, July 12, 2012 12:15 PM To: Brian Waldon Cc: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom So if Im not coding, I should shut up? I think you answered your own question. Sent from my iPhone On Jul 12, 2012, at 14:10, Brian Waldon brian.wal...@rackspace.commailto:brian.wal...@rackspace.com wrote: What exactly was so offensive about what I said? Communities like OpenStack are built on top of people *doing* things, not *talking* about things. I'm just asking you to contribute code or design help rather than slanderous commentary. Brian Offensive Waldon On Jul 12, 2012, at 11:59 AM, George Reese wrote: You evidently have not had to live with the interoperability nightmare known as OpenStack in the same way I have. Otherwise, you would find responses like Brian's much more offensive. -George On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote: This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Clearly, going forward, we want to be more deliberate about changes that may have impact on operations and he broader ecosystem that bases its efforts on assumptions established at the start of a release cycle, rather than on changes introduced late in the cycle. Cheers Chris Sent from my iPad On Jul 12, 2012, at 2:24 PM, George Reese george.re...@enstratus.commailto:george.re...@enstratus.com wrote: Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
George, your opinion is best conveyed if it comes with a polite choice of words. Please refrain from adding more of your references to excrements and help the community make a decision. /stef On 07/12/2012 12:14 PM, George Reese wrote: So if Im not coding, I should shut up? I think you answered your own question. Sent from my iPhone On Jul 12, 2012, at 14:10, Brian Waldon brian.wal...@rackspace.com mailto:brian.wal...@rackspace.com wrote: What exactly was so offensive about what I said? Communities like OpenStack are built on top of people *doing* things, not *talking* about things. I'm just asking you to contribute code or design help rather than slanderous commentary. Brian Offensive Waldon On Jul 12, 2012, at 11:59 AM, George Reese wrote: You evidently have not had to live with the interoperability nightmare known as OpenStack in the same way I have. Otherwise, you would find responses like Brian's much more offensive. -George On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote: This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Clearly, going forward, we want to be more deliberate about changes that may have impact on operations and he broader ecosystem that bases its efforts on assumptions established at the start of a release cycle, rather than on changes introduced late in the cycle. Cheers Chris Sent from my iPad On Jul 12, 2012, at 2:24 PM, George Reese george.re...@enstratus.com mailto:george.re...@enstratus.com wrote: Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Thu, Jul 12, 2012 at 2:37 PM, George Reese george.re...@enstratus.comwrote: This ain't the first time I've had a run in with you where your response was essentially if you don't like it, go code it. And obviously you missed the entire constructive point in my response. It's this: The proposed options suck. It's too late to do anything about that as this ship has sailed. Perhaps my English is not the best, but what exactly is constructive about this? What you need to understand going forward is that this community has an abysmal history when it comes to compatibility and interoperability. Abysmal. Not checkered. Not patchy. Not lacking. Abysmal. Horizontally. Vertically. Abysmal. Actually, shockingly abysmal. You saw one public response laughing at me for expecting this community to care about compatibility. I also received private responses with the same sentiment. If you guys really think you care about compatibility, you need to go sit in a corner and do some heavy thinking. Because the history of this project and this thread in particular suggest otherwise. In case you missed it again, here it is in a single sentence: The constructive point I am making is that it's time to wake up and get serious about compatibility and interoperability. -George On Jul 12, 2012, at 2:27 PM, Brian Waldon wrote: Planning the development of the projects is valuable as well as contributing code. If you review my last message, you'll see the words '... or design help', which I intended to represent non-code contribution. You seem to have strong opinions on how things should be done, but I don't see your voice in any of the community discussions. Moving forward, I wish you would share your expertise in a constructive manner. Keep in mind this list reaches 2200 people. Let's not waste anyone's time. WALDON On Jul 12, 2012, at 12:14 PM, George Reese wrote: So if Im not coding, I should shut up? I think you answered your own question. Sent from my iPhone On Jul 12, 2012, at 14:10, Brian Waldon brian.wal...@rackspace.com wrote: What exactly was so offensive about what I said? Communities like OpenStack are built on top of people *doing* things, not *talking* about things. I'm just asking you to contribute code or design help rather than slanderous commentary. Brian Offensive Waldon On Jul 12, 2012, at 11:59 AM, George Reese wrote: You evidently have not had to live with the interoperability nightmare known as OpenStack in the same way I have. Otherwise, you would find responses like Brian's much more offensive. -George On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote: This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Clearly, going forward, we want to be more deliberate about changes that may have impact on operations and he broader ecosystem that bases its efforts on assumptions established at the start of a release cycle, rather than on changes introduced late in the cycle. Cheers Chris Sent from my iPad On Jul 12, 2012, at 2:24 PM, George Reese george.re...@enstratus.com wrote: Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On 07/12/2012 12:37 PM, George Reese wrote: It's too late to do anything about that as this ship has sailed. This is wrong. You and anybody that believes options #1 and #2 proposed by Vish and John are sub-optimal still have time to make a proposal. Please, take time to write it down. Cheers, stef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Thu, Jul 12, 2012 at 2:38 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: Agreed, I'm a developer, so I'm clearly biased towards what is easier for developers. It will be a significant effort to have to maintain the nova-volume code, so I want to be sure it is necessary. End users really shouldn't care about this, so the other community members who are impacted are operators. I really would like more feedback on how painful it will be for operators if we force them to migrate. We have one clear response from Chuck, which is very helpful. Is there anyone else out there running nova-volume that would prefer to keep it when they move to folsom? I think that the long term maintenance or removal of nova-volume in its existing form is orthogonal to the actual issue of continuity from one release to the next. At this point, we've now run cactus, diablo and are in testing with essex. Each of these has effectively been a flag day for us; we build the new system, migrate users, images, etc, and let users do a bunch of manual migration of volume data, etc, while running both systems in parallel. This hasn't been as painful as it sounds because our understanding of best practices for running openstack is moving pretty quickly and each system has been quite different from the previous. The lack of an effective process to move from one major release to the next is the major issue here in my mind. It would be fantastic if (some day, ha ha ha) you could apt-get upgrade from folsom to grizzly, but i think that is likely to be more trouble than it is worth. A reasonable compromise would be a well documented process as well as tools to aid in the process. Each real deployment will have a substantial set of local customizations, particularly if they are running at any sort of scale. While it won't be feasible to support any upgrade with these customizations, tools for the process (which may only be used a straw man in complex cases) would go a long way. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Jul 12, 2012, at 2:36 PM, David Mortman wrote: On Thu, Jul 12, 2012 at 3:38 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: Two thoughts: 1) I think this is the wrong forum to poll operators on their preferences in general 2) We don't yet even have a fully laid out set of requirements and steps for how someone would convert or how hard it will be. Historically (with openstack and software in general), it is _always_ harder to upgrade then we think it will be. I'm an optimist and I think it will be a disaster... Excellent points. Let me make the following proposal: 1) Leave the code in nova-volume for now. 2) Document and test a clear migration path to cinder. 3) Take the working example upgrade to the operators list and ask them for opinions. 4) Decide based on their feedback whether it is acceptable to cut the nova-volume code out for folsom. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
tl;dr: I vote for option 2 as it's the only reasonable path from a deployer's point of view With my deployer hat on, I think option 1 isn't really valid. It's completely unfair to force deployers to use Cinder before they can upgrade to Folsom. There are real deployments using nova-volumes, let's not screw them. With my developer hat on, I don't want to support two forks of the same slowly-diverging codebase. I definitely want to make sure our stuff is consumable, but we can't be expected to support everything forever. How about we leave nova-volumes in for the Grizzly release, but with a deprecation warning and a notice that we will only maintain it as we would a stable release branch (no features). Waldon On Jul 11, 2012, at 8:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
So, in short, your entire purpose here is to troll everyone? Nice… : / You obviously care. You keep responding… You have been asked numerous times what we can do to NOT stick us yet against in this situation in the future. Why is that such a difficult question to answer? Do you have an answer? Is your answer to not change anything, ever? That is not likely or reasonable – so what can be done here? Have you seen the other thread about what this cinder/nova-volume change entails? There ARE people here willing to hear it out if you have an answer, or an actionable suggestion, or process, or SOMETHING besides get your heads out of your asses, which is hardly actionable, as it is vague and hopefully not a literal belief/suggestion… So, George: What do you want from us here? You likely have some legitimate pain-points, concerns, and reasons to be upset, but they are absolutely lost in your angry and personally offensive responses. Can you maybe elaborate on what pain THIS change would cause, and how we might assuage that? John Postlethwait Nebula, Inc. On Thursday, July 12, 2012 at 12:47 PM, George Reese wrote: You are mistaking me for caring about the answer to this question. This ship has sailed. We are faced with two shitty choices as a result of continued lack of concern by this community for compatibility. History? I've been pounding my head against the OpenStack all for years on compatibility and we end up AGAIN in a situation like this where we have two shitty options. I'm not offering an opinion or a third option because I just don't give a damn what option is picked since both will suck. I'm trying to get everyone to get their heads out of their asses and not stick us yet against in this situation in the future. You can discard my position if you want. I really don't give a damn. I just happen to work with a wider variety of OpenStack environments that most others on the list. But whatever. -George On Jul 12, 2012, at 2:40 PM, Jon Mittelhauser wrote: George, I am relatively new to this mailing list so I assume that there is some history that is prompting the vehemence but I do not understand what you are trying to accomplish. Vish sent out two proposed ways for dealing with the migration. Most of the early voting (including mine) has been for option #1 (happy to explain why if desired) but it isn't like the discussion is over. If you believe that option #2 is better, please explain why you believe that. If you believe that there is a 3rd option, please explain it to us. You are complaining without offering a counter proposal. That is simply not effective and makes semi-neutral folks (like me) tend to discard your point of view (which I assume is not your objective). -Jon From: George Reese george.re...@enstratus.com (mailto:george.re...@enstratus.com) Date: Thursday, July 12, 2012 10:14 AM To: Brian Waldon brian.wal...@rackspace.com (mailto:brian.wal...@rackspace.com) Cc: Openstack (openstack@lists.launchpad.net (mailto:openstack@lists.launchpad.net)) (openstack@lists.launchpad.net (mailto:openstack@lists.launchpad.net)) openstack@lists.launchpad.net (mailto:openstack@lists.launchpad.net) Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Thu, Jul 12, 2012 at 2:38 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: On Jul 12, 2012, at 11:48 AM, Christopher B Ferris wrote: This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Agreed, I'm a developer, so I'm clearly biased towards what is easier for developers. It will be a significant effort to have to maintain the nova-volume code, so I want to be sure it is necessary. End users really shouldn't care about this, so the other community members who are impacted are operators. I really would like more feedback on how painful it will be for operators if we force them to migrate. We have one clear response from Chuck, which is very helpful. Is there anyone else out there running nova-volume that would prefer to keep it when they move to folsom? Us reddwarfers are running a grunch of nova volumes in multiple DCs. While the developer in me says lets go w/ option 1, the release/operator in me says lets wait to do this on a formal release (#2?). It seems like we are too far gone in the Folsom release to do this w/o people having to scramble. Everyone will have to eventually migrate from old to new, and while i understand that there will be a clear path to do this, and its going to be painful for some companies. If we rip things out during Grizzly, it will at least give companies that are not rolling on trunk the ability to decide when to migrate. If you do it in Folsom, some companies who are depending on (or wanting) landed features, but may not be able to do this migration, could suffer. At least now deferring to El Oso will give companies time to brace themselves, and successfully migrate to Folsom w/o any major issues. In general it makes sense to do sweeping changes between major releases, communicated at the beginning of a release cycle rather than in the middle, to give operators/companies a decision to upgrade if they want the features vs stay on old if they dont want to migrate. At the end of the day, openstack depends on operators to function. Id rather piss of us developers than piss off the people that run the infrastructure we create! That being said, im not worried about the migration, given that its just a datastore/service/package/installation based migration. We will likely roll to cinder much sooner than the Grizzly release, assuming everything is stable (which im sure it will be). :) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Thu, Jul 12, 2012 at 2:56 PM, George Reese george.re...@enstratus.com wrote: I don't think Cinder should exist. Sometimes you have to live with the technical debt because that's the best way to preserve the investment your customers have made in your product. Or if you're very smart, you find a way to refactor that technical debt invisibly to customers. But you don't make the customer carry the burden of your refactoring technical debt. I hate to fan the fire, but what would happened in cassandra if they _never_ updated their data structures. Or hadoop, or any other open source project like that. I understand where you are coming from, but i would like to find an example of a project thats _never_ updated their datastore or caused some sort of migration, be it configuration or data based. I _do_ feel we should roll this migration in the least painful way possible though. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
[launchpad is slow at delivering messages to the list. Please everybody keep it in mind and slow down your replies too to give people the chance to comment, too.] On 07/12/2012 12:47 PM, Matt Joyce wrote: Yes we maintain v2 api compatibility but there will be a cost to users in the confusion of decisions like this. Any change has costs, all decisions are the result of compromises. I'm sure you all know this, it's a fact of life. We can't change that fact but we can change how we get to an agreement of what compromise is acceptable. From what I understand, some people are regretting the decision to create cinder. We should start from the beginning then: How many people regret the decision to start cinder? Where were you when the decision was taken? What prevented you to speak up then? I'd appreciate your answers to these questions and your suggestions on how to modify the decision-making process (if you think it's broken). thanks, stef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Jul 12, 2012, at 5:08 PM, John Postlethwait wrote: So, in short, your entire purpose here is to troll everyone? Nice… : / If you think that, you're likely part of the problem. You obviously care. You keep responding… You have been asked numerous times what we can do to NOT stick us yet against in this situation in the future. Why is that such a difficult question to answer? Do you have an answer? Is your answer to not change anything, ever? That is not likely or reasonable – so what can be done here? Have you seen the other thread about what this cinder/nova-volume change entails? This is an idiotic question. What can I suggest everyone do about as yet unproposed changes to OpenStack? Seriously? There ARE people here willing to hear it out if you have an answer, or an actionable suggestion, or process, or SOMETHING besides get your heads out of your asses, which is hardly actionable, as it is vague and hopefully not a literal belief/suggestion… So, George: What do you want from us here? You likely have some legitimate pain-points, concerns, and reasons to be upset, but they are absolutely lost in your angry and personally offensive responses. Can you maybe elaborate on what pain THIS change would cause, and how we might assuage that? This community needs offending. How many years has it been? How many OpenStack upgrades can you point to that have been painless? How many interoperable, multi-vendor OpenStack clouds? How reliable is the API as an appropriate abstract representation of an OpenStack implementation that can be used to build an ecosystem? The answer to those questions is: - 3 - 0 - 0 - not at all It is very clear that compatibility and upgradability is a huge issue. And a number of people, obviously including you, don't seem to grasp that. We have silly comments like Michael's I hate to fan the fire, but what would happened in cassandra if they _never_ updated their data structures. 1. Obviously I am not talking about never changing anything. Any suggestion otherwise is being willfully obtuse. 2. There's a big difference between systems like Cassandra that generally can have maintenance windows and environments like clouds which should NEVER have maintenance windows 3. Every single other cloud platform on the planet manages to support a much less painful upgrade path with a much higher level of interoperability. In all of yours and Jon's and Brian's nonsense, I don't see any actual defense of the compatibility and interoperability of OpenStack deployments. I can only assume that's because you can't actually defend it, yet you nevertheless have your head stuck in the sand. -George -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comSkype: nspollutiont: @GeorgeReesep: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Excellent points. Let me make the following proposal: 1) Leave the code in nova-volume for now. 2) Document and test a clear migration path to cinder. 3) Take the working example upgrade to the operators list and ask them for opinions. 4) Decide based on their feedback whether it is acceptable to cut the nova-volume code out for folsom. Finally something I can put a +1 against. -- Eric Windisch ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Jul 12, 2012, Christopher B Ferris wrote: Clearly, going forward, we want to be more deliberate about changes Funny how compatibility is always a popular going forward item. Best -Federico _ -- 'Problem' is a bleak word for challenge - Richard Fish (Federico L. Lucifredi) - federico at canonical.com - GnuPG 0x4A73884C ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Hello, I'm not an OpenStack developer nor any type of developer. I am, however, heavily involved with operations for a few production OpenStack environments. I understand the debate going on and wanted to add an administrator's point of view. For admins, OpenStack is not our job, but a tool we use in our job. It's terribly frustrating when that tool drastically changes every six months. I find Gabriel's reply interesting and sane. I think if it was agreed upon to ensure N+1 compatibility, then OpenStack should adhere to that. The change being discussed involves storage volumes. This is dead serious. If the migration goes awry, there's potential for production data loss. If the badly-migrated OpenStack environment is used to offer services for outside customers, we've just lost data for those customers. It's one of the worst scenarios for admins. If upgrading from one version of OpenStack to the next is too dangerous due to the possibility of getting into situations such as described above, then it needs to be clearly announced. There's a reason why major RHEL releases are maintained in parallel for so long. With regard to Option 1, I understand the benefits of making this change. If Option 1 was chosen, IMO, the best-case scenario would be if the extra work involved with upgrading to Cinder/Folsom was just a schema migration and everything else still worked as it did with Essex. If this were to happen, though, I would spend /weeks/ testing and planning the Folsom upgrade. I'd estimate that my production environments would make it to Folsom 3 months after it was released. But then what major change am I going to have to worry about in another 3 months? Thanks, Joe On Thu, Jul 12, 2012 at 2:48 PM, Gabriel Hurley gabriel.hur...@nebula.comwrote: The stated and agreed-upon goal from Essex forward is to make the core OpenStack projects N+1 compatible (e.g. Essex-Folsom, Folsom-Grizzly), and to make the clients capable of talking to every API version forever.** ** ** ** Anything standing in the way of that should be considered a release-blocking bug, and should be filed against the appropriate projects. I for one intend to see to that as best I can. ** ** That said, there **is** a grey area around “migration” steps like Nova Volume - Cinder. If the migration path is clear, stable, well-documented, uses the same schemas and same APIs… I’d say that **may** still fall into the category of N+1 compatible. It sounds like that’s the idea here, but that we need to thoroughly vet the practicality of that assertion. I don’t think we can decide this without proof that the clean transition is 100% possible. ** ** Code isn’t the only thing of value; constructively and respectfully shaping design decisions is great, testing and filing bugs is also fantastic. Profanity and disrespect are not acceptable. Ever. ** ** All the best, ** ** **- **Gabriel ** -- Joe Topjian Systems Administrator Cybera Inc. www.cybera.ca Cybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On the flip side - to refresh people's memory it might be useful to send out a link to some of the email threads (or wikis) that explained why this move is critical to OS's success. Perhaps some of those reasons aren't as valid any more given the impact people are now seeing it will have. Never hurts to measure again before you cut :-) thanks -Doug STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | d...@us.ibm.com The more I'm around some people, the more I like my dog. Stefano Maffulli stef...@openstack.org Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net 07/12/2012 06:38 PM To openstack@lists.launchpad.net cc Subject Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom [launchpad is slow at delivering messages to the list. Please everybody keep it in mind and slow down your replies too to give people the chance to comment, too.] On 07/12/2012 12:47 PM, Matt Joyce wrote: Yes we maintain v2 api compatibility but there will be a cost to users in the confusion of decisions like this. Any change has costs, all decisions are the result of compromises. I'm sure you all know this, it's a fact of life. We can't change that fact but we can change how we get to an agreement of what compromise is acceptable. From what I understand, some people are regretting the decision to create cinder. We should start from the beginning then: How many people regret the decision to start cinder? Where were you when the decision was taken? What prevented you to speak up then? I'd appreciate your answers to these questions and your suggestions on how to modify the decision-making process (if you think it's broken). thanks, stef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
+1 for Option 1. On Wed, Jul 11, 2012 at 11:26 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Regards Huang Zhiteng ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
One vote for option 1. Remove Volumes ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
+1 for option 1 On 7/11/12 8:26 AM, Vishvananda Ishaya vishvana...@gmail.com wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
+1 for option 1 -- Mike Perez DreamHost.com On Wednesday, July 11, 2012 at 8:26 AM, Vishvananda Ishaya wrote: Option 1 -- Remove Nova Volume == ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
I also vote for option 1, but the migration path really needs to be solid and well documented. -nld On Wed, Jul 11, 2012 at 10:52 AM, Andrew Clay Shafer a...@parvuscaptus.com wrote: One vote for option 1. Remove Volumes ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Wed, 11 Jul 2012 08:26:56 -0700 Vishvananda Ishaya vishvana...@gmail.com wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
+1 on 1 chuck On Wed, 11 Jul 2012 08:26:56 -0700 Vishvananda Ishaya vishvana...@gmail.com wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
+1 for option 1. Bite the bullet now, rather than making it worse later. -Paul ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
-Original Message- From: openstack-bounces+gregory_althaus=dell@lists.launchpad.net [mailto:openstack-bounces+gregory_althaus=dell@lists.launchpad.net] On Behalf Of Vishvananda Ishaya Sent: Wednesday, July 11, 2012 10:27 AM To: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) Subject: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp +1 for Option 1. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Before we completely pile on option 1, can we get devstack changed to run this way? I think the amount of pain / ease that transition is for users and the OpenStack CI team will greatly inform this decision, and give us some good data points on how tough this is for people to convert. -Sean On 07/11/2012 12:22 PM, Mike Perez wrote: +1 for option 1 -- Mike Perez DreamHost.com On Wednesday, July 11, 2012 at 8:26 AM, Vishvananda Ishaya wrote: Option 1 -- Remove Nova Volume == This body part will be downloaded on demand. -- Sean Dague IBM Linux Technology Center email: sda...@linux.vnet.ibm.com alt-email: slda...@us.ibm.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
+1 for option 1 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
+1 option one. On Wed, Jul 11, 2012 at 11:55 AM, Paul McMillan paul.mcmil...@nebula.comwrote: +1 for option 1. Bite the bullet now, rather than making it worse later. -Paul __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/~openstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp -- Nirmal http://rnirmal.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
+1 for 1 On 11/07/12 8:26 AM, Vishvananda Ishaya vishvana...@gmail.com wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
+1 to option 1, rip the band-aid off quickly :-) -Doug -Original Message- From: openstack-bounces+gregory_althaus=dell@lists.launchpad.net [mailto:openstack-bounces+gregory_althaus=dell.com@lists.launchpad. net] On Behalf Of Vishvananda Ishaya Sent: Wednesday, July 11, 2012 10:27 AM To: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) Subject: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On 07/11/2012 09:22 AM, Narayan Desai wrote: I also vote for option 1, but the migration path really needs to be solid and well documented. -nld I feel the same. I think documented and tested migration paths are of utmost importance here. Unlike the Keystone - Keystone Light migration, people are actually using Nova volume in production right now. There were some facilities added in the later Keystone to help with migration, but AFAICS Keystone adoption at the time wasn't to the point where the migration path really mattered--not enough to have any bugs being rasied, at least. Anyone know if beginnings of such docs and utilities exist currently? Adam ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
All, Just wanted to note that either decision means a revision and addition of documentation - to me, one option does not create more doc need than the other. Removal or deprecation, both require documentation. Anne On Wed, Jul 11, 2012 at 11:22 AM, Narayan Desai narayan.de...@gmail.com wrote: I also vote for option 1, but the migration path really needs to be solid and well documented. -nld On Wed, Jul 11, 2012 at 10:52 AM, Andrew Clay Shafer a...@parvuscaptus.com wrote: One vote for option 1. Remove Volumes ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Vish, How would the Nova migration from Essex to Folsom take place ? I'm wondering how we can validate Folsom without risking an existing Essex installation via some sort of clone/migrate operation. What is your assessment of the risk that Cinder is less stable than Nova volume ? Option 1 would give no option if there are issues, we would have either to stay on Essex entirely or wait until Folsom has the issues resolved. However, option 1 would be much cleaner code wise. Tim -Original Message- From: openstack-bounces+tim.bell=cern...@lists.launchpad.net [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf Of Vishvananda Ishaya Sent: 11 July 2012 17:27 To: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) Subject: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Wed, Jul 11, 2012 at 11:38 AM, Sean Dague sda...@linux.vnet.ibm.com wrote: Before we completely pile on option 1, can we get devstack changed to run this way? I think the amount of pain / ease that transition is for users and the OpenStack CI team will greatly inform this decision, and give us some good data points on how tough this is for people to convert. Yes, you can do this currently by adding the following to your localrc in devstack: ENABLED_SERVICES+=,-n-vol,c-api,c-sch,c-vol I'm also planning to propose a patch for devstack to make Cinder the default, here this afternoon (of course this can be configured back to use Nova Volume if desired). -Sean On 07/11/2012 12:22 PM, Mike Perez wrote: +1 for option 1 -- Mike Perez DreamHost.com On Wednesday, July 11, 2012 at 8:26 AM, Vishvananda Ishaya wrote: Option 1 -- Remove Nova Volume == This body part will be downloaded on demand. -- Sean Dague IBM Linux Technology Center email: sda...@linux.vnet.ibm.com alt-email: slda...@us.ibm.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
For me it's +1 to 1, but... Here at Globo.com we're already deploying clouds based on openstack (not in production yet, we have dev and lab), and it's really painful when openstack just forces us to change, I mean, sysadmins are not that happy, so I think it's more polite if we warn them in Folsom, and remove everything next. Maybe this way nobody's going to fear the update. It also make us lose the chain of thought.. you're learning, and suddenly you have to change something for an update, and then you come back to what you we're doing... Anyway... :) Thanks, On Wed, Jul 11, 2012 at 3:09 PM, Renuka Apte renuka.a...@citrix.com wrote: +1 for 1 On 11/07/12 8:26 AM, Vishvananda Ishaya vishvana...@gmail.com wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Flavia ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
On Wed, Jul 11, 2012 at 1:49 PM, Adam Gandelman ad...@canonical.com wrote: On 07/11/2012 09:22 AM, Narayan Desai wrote: I also vote for option 1, but the migration path really needs to be solid and well documented. -nld I feel the same. I think documented and tested migration paths are of utmost importance here. Unlike the Keystone - Keystone Light migration, people are actually using Nova volume in production right now. There were some facilities added in the later Keystone to help with migration, but AFAICS Keystone adoption at the time wasn't to the point where the migration path really mattered--not enough to have any bugs being rasied, at least. Thinking more about this, it seems to me that we need to have pretty detailed doc about this. Particularly since cinder isn't in wide use yet, I think that a lot of people are running weird configurations for volume storage. I suspect that having an automagic upgrade path won't be feasible in these cases, but there needs to be enough doc (and tools) to get old volumes migrated in some fashion. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
+1 Chris Sent from my iPad On Jul 11, 2012, at 3:02 PM, Sean Dague sda...@linux.vnet.ibm.com wrote: Before we completely pile on option 1, can we get devstack changed to run this way? I think the amount of pain / ease that transition is for users and the OpenStack CI team will greatly inform this decision, and give us some good data points on how tough this is for people to convert. -Sean On 07/11/2012 12:22 PM, Mike Perez wrote: +1 for option 1 -- Mike Perez DreamHost.com On Wednesday, July 11, 2012 at 8:26 AM, Vishvananda Ishaya wrote: Option 1 -- Remove Nova Volume == This body part will be downloaded on demand. -- Sean Dague IBM Linux Technology Center email: sda...@linux.vnet.ibm.com alt-email: slda...@us.ibm.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
Just to be clear, I was +1 ing Sean's point that we should get sme experience behind this before pulling the plug. Chris Sent from my iPad On Jul 11, 2012, at 3:02 PM, Sean Dague sda...@linux.vnet.ibm.com wrote: Before we completely pile on option 1, can we get devstack changed to run this way? I think the amount of pain / ease that transition is for users and the OpenStack CI team will greatly inform this decision, and give us some good data points on how tough this is for people to convert. -Sean On 07/11/2012 12:22 PM, Mike Perez wrote: +1 for option 1 -- Mike Perez DreamHost.com On Wednesday, July 11, 2012 at 8:26 AM, Vishvananda Ishaya wrote: Option 1 -- Remove Nova Volume == This body part will be downloaded on demand. -- Sean Dague IBM Linux Technology Center email: sda...@linux.vnet.ibm.com alt-email: slda...@us.ibm.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
I'm normally very much in favor of stable APIs and slow deprecation, but in this case I'm far more concerned about having to support two completely independent codebases. If we pursue option 2 I think the language there needs to be even stronger and we'd have to say that nova-volume is dead/frozen, should not be touched except for release blocking bugs, shouldn't have any new bugs filed against it, etc. Personally I'd like to follow option 1, but... - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Vishvananda Ishaya Sent: Wednesday, July 11, 2012 8:27 AM To: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) Subject: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
It would be great if anyone who is already deploying Openstack, even if in non-production environments, could give cinder a try. For a test environment, it seems easy enough to make the switch using devstack (I have verified this with XenServer, and I believe, John and folks at Rackspace have tried on KVM). Of course, only when more people start trying it will we get a realistic picture. Thanks, Renuka. From: Flavia Missi [mailto:flaviami...@gmail.com] Sent: Wednesday, July 11, 2012 12:56 PM To: Renuka Apte Cc: Vishvananda Ishaya; Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom For me it's +1 to 1, but... Here at Globo.com we're already deploying clouds based on openstack (not in production yet, we have dev and lab), and it's really painful when openstack just forces us to change, I mean, sysadmins are not that happy, so I think it's more polite if we warn them in Folsom, and remove everything next. Maybe this way nobody's going to fear the update. It also make us lose the chain of thought.. you're learning, and suddenly you have to change something for an update, and then you come back to what you we're doing... Anyway... :) Thanks, On Wed, Jul 11, 2012 at 3:09 PM, Renuka Apte renuka.a...@citrix.commailto:renuka.a...@citrix.com wrote: +1 for 1 On 11/07/12 8:26 AM, Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Flavia ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
option 1. On Thu, Jul 12, 2012 at 7:10 AM, Renuka Apte renuka.a...@citrix.com wrote: It would be great if anyone who is already deploying Openstack, even if in non-production environments, could give cinder a try. For a test environment, it seems easy enough to make the switch using devstack (I have verified this with XenServer, and I believe, John and folks at Rackspace have tried on KVM). Of course, only when more people start trying it will we get a realistic picture. ** ** Thanks, Renuka. ** ** *From:* Flavia Missi [mailto:flaviami...@gmail.com] *Sent:* Wednesday, July 11, 2012 12:56 PM *To:* Renuka Apte *Cc:* Vishvananda Ishaya; Openstack (openstack@lists.launchpad.net) ( openstack@lists.launchpad.net) *Subject:* Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom ** ** For me it's +1 to 1, but... Here at Globo.com we're already deploying clouds based on openstack (not in production yet, we have dev and lab), and it's really painful when openstack just forces us to change, I mean, sysadmins are not that happy, so I think it's more polite if we warn them in Folsom, and remove everything next. Maybe this way nobody's going to fear the update. It also make us lose the chain of thought.. you're learning, and suddenly you have to change something for an update, and then you come back to what you we're doing... Anyway... :) Thanks, On Wed, Jul 11, 2012 at 3:09 PM, Renuka Apte renuka.a...@citrix.com wrote: +1 for 1 On 11/07/12 8:26 AM, Vishvananda Ishaya vishvana...@gmail.com wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Flavia ** ** ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Shake Chen ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
