Re: [openstack-dev] Migrating to newer full projects from what used to be part of nova
Migrations from Essex to Grizzly/Havana ... I would find it entirely suitable to upgrade from Essex to Folsom, then migrate from nova-volume to cinder and from nova-network to quantum, then only to upgrade to Grizzly. We're in the same spot, upgrading an Essex deployment to Havana. We decided to forego an incremental upgrade of nova, glance and keystone since it was not clear that we could perform that upgrade without a major service disruption to active VMs. Additionally we had no good way of fully testing the upgrade beforehand. However, we have a nova-volume service hosting ~ 500TB of volume data ( 200 volumes) using the ZFS driver. We'd like to be able to carry these volumes over the upgrade to cinder. Our current strategy is to deploy cinder and nova-volume on the same machine with separate ZFS pools. When a user's ready to upgrade a volume, they hit a button; a script fires off 1) creating a new cinder volume, 2) rename the nova-volume in ZFS to the new cinder one and 3) deleting the old nova-volume record. That's the plan, at least. ~ Scott On Fri, Nov 1, 2013 at 3:16 PM, Dean Troyer dtro...@gmail.com wrote: On Fri, Nov 1, 2013 at 1:38 PM, Devananda van der Veen devananda@gmail.com wrote: Actually, anyone deploying nova with the baremetal driver will face a similar split when Ironic is included in the release. I'm targeting Icehouse, but of course, it's up to the TC when Ironic graduates. This should have a smaller impact than either the neutron or cinder splits, both of which were in widespread use, but I expect we'll see more usage of nova-baremetal crop up now that Havana is released. I didn't recall in which release baremetal was first a supported option, is it only now in Havana? Is it clear in the docs that this sort of situation is coming in the next release or two? (And no, I haven't gone to look for myself, maybe on the plane tomorrow...) dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Migrating to newer full projects from what used to be part of nova
On 11/01/2013 11:02 AM, Dean Troyer wrote: To clarify a bit, while deprecated, nova-network has not lost any functionality in Havana yet. It also hasn't gained much (if any), but it still works. The majority of the testing is performed using nova-network and not neutron (yet). It is also amazing that the current install-guide still tells about nova-network... :( [1] Thomas [1] No, I'm not volunteering to fix, unfortunately (I already spent the week on adding Debian support to the install-guide). ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Migrating to newer full projects from what used to be part of nova
On Thu, Oct 31, 2013 at 8:02 PM, Dean Troyer dtro...@gmail.com wrote: Also, FWIW, I don't see another one of these situations coming anytime soon. All of the new project activity is around new services/features. Actually, anyone deploying nova with the baremetal driver will face a similar split when Ironic is included in the release. I'm targeting Icehouse, but of course, it's up to the TC when Ironic graduates. This should have a smaller impact than either the neutron or cinder splits, both of which were in widespread use, but I expect we'll see more usage of nova-baremetal crop up now that Havana is released. -Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Migrating to newer full projects from what used to be part of nova
On Fri, Nov 1, 2013 at 1:38 PM, Devananda van der Veen devananda@gmail.com wrote: Actually, anyone deploying nova with the baremetal driver will face a similar split when Ironic is included in the release. I'm targeting Icehouse, but of course, it's up to the TC when Ironic graduates. This should have a smaller impact than either the neutron or cinder splits, both of which were in widespread use, but I expect we'll see more usage of nova-baremetal crop up now that Havana is released. I didn't recall in which release baremetal was first a supported option, is it only now in Havana? Is it clear in the docs that this sort of situation is coming in the next release or two? (And no, I haven't gone to look for myself, maybe on the plane tomorrow...) dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Migrating to newer full projects from what used to be part of nova
Hi everyone, Migrations from Essex to Grizzly/Havana are starting to hit my radar of responsible tasks and I'm disappointed that beyond this old wiki note [1] and a wealth of questions with very few answers [2], there is very little available to support the migrations from what used to be part of nova to the newer full projects. I really think that as Openstack grows and the projects split out, one of the focal areas really needs to be on ensuring that people using the older versions can migrate to the newer versions without needing to do all sorts of terrible hacks. Issues at hand, for now, are: 1) Migrating from nova-volume to cinder 2) Migrating from nova-network to neutron It'd be great if we could pool efforts to figure out an effective way of handling these migrations. Whether they're handled in the 'db sync' process, or by a set of companion utilities instead is immaterial to a deployer... as long as something suitable and effective is available to cater for the need. [1] https://wiki.openstack.org/wiki/MigrateToCinder [2] https://www.google.co.za/search?q=migrate+'nova-network'+quantumhttps://www.google.co.za/search?q=migrate+nova-network+quantumoq=migrate+nova-network+quantumaqs=chrome..69i57.12524j0j7sourceid=chromeespv=210es_sm=93ie=UTF-8 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Migrating to newer full projects from what used to be part of nova
Yes, OS as big product tries to split hierarchy of responsibilities. Currently we have serveral tasks, i suppose. First one is upgrading from one stable release to another. Second one is migrating from one release to another. Currently OpenStack has several deployment projects: TripleO, Fuel (--- is a bit different from TripleO, it performs bare-metal deployment of whole OS). As way of covering issue of upgrading/migrating, personaly i see, we could suggest those projects to propose a way of solving it. 2013/10/31 Jesse Pretorius jesse.pretor...@gmail.com Hi everyone, Migrations from Essex to Grizzly/Havana are starting to hit my radar of responsible tasks and I'm disappointed that beyond this old wiki note [1] and a wealth of questions with very few answers [2], there is very little available to support the migrations from what used to be part of nova to the newer full projects. I really think that as Openstack grows and the projects split out, one of the focal areas really needs to be on ensuring that people using the older versions can migrate to the newer versions without needing to do all sorts of terrible hacks. Issues at hand, for now, are: 1) Migrating from nova-volume to cinder 2) Migrating from nova-network to neutron It'd be great if we could pool efforts to figure out an effective way of handling these migrations. Whether they're handled in the 'db sync' process, or by a set of companion utilities instead is immaterial to a deployer... as long as something suitable and effective is available to cater for the need. [1] https://wiki.openstack.org/wiki/MigrateToCinder [2] https://www.google.co.za/search?q=migrate+'nova-network'+quantumhttps://www.google.co.za/search?q=migrate+nova-network+quantumoq=migrate+nova-network+quantumaqs=chrome..69i57.12524j0j7sourceid=chromeespv=210es_sm=93ie=UTF-8 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Migrating to newer full projects from what used to be part of nova
On Thu, Oct 31, 2013 at 10:26 AM, Jesse Pretorius jesse.pretor...@gmail.com wrote: Hi everyone, Migrations from Essex to Grizzly/Havana are starting to hit my radar of responsible tasks and I'm disappointed that beyond this old wiki note [1] Is your disappointment that there isn't a path from Essex -- Grizzly/Havana, or are you unhappy with the content? and a wealth of questions with very few answers [2], there is very little available to support the migrations from what used to be part of nova to the newer full projects. I really think that as Openstack grows and the projects split out, one of the focal areas really needs to be on ensuring that people using the older versions can migrate to the newer versions without needing to do all sorts of terrible hacks. Issues at hand, for now, are: 1) Migrating from nova-volume to cinder So to be quite honest we never intended to make skips like you describe. Perhaps that wasn't such a good choice in retrospect. I'm willing to take a look at putting some special migrations in, but honestly given the changes in Nova alone between Essex and Folsom making a full jump from something like Essex to Havana is going to be challenging not just for adding Cinder, but overall. I know it's not ideal but right now the best/preferred solution may in fact be to do incremental updates as intended. Going forward maybe we can come up with something better. 2) Migrating from nova-network to neutron It'd be great if we could pool efforts to figure out an effective way of handling these migrations. Whether they're handled in the 'db sync' process, or by a set of companion utilities instead is immaterial to a deployer... as long as something suitable and effective is available to cater for the need. [1] https://wiki.openstack.org/wiki/MigrateToCinder [2] https://www.google.co.za/search?q=migrate+'nova-network'+quantum ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Migrating to newer full projects from what used to be part of nova
On 10/31/2013 12:46 PM, John Griffith wrote: Issues at hand, for now, are: 1) Migrating from nova-volume to cinder So to be quite honest we never intended to make skips like you describe. Perhaps that wasn't such a good choice in retrospect. I'm willing to take a look at putting some special migrations in, but honestly given the changes in Nova alone between Essex and Folsom making a full jump from something like Essex to Havana is going to be challenging not just for adding Cinder, but overall. I know it's not ideal but right now the best/preferred solution may in fact be to do incremental updates as intended. Right, Nova (and probably other projects, too) only supports N to N+1 upgrades. If you need to go to N+2, you'll need to go through N+1 to get there. FWIW, improving upgrades is very high on the priority list across all of OpenStack. We have sessions all over the place to talk about it. It's getting a lot better. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Migrating to newer full projects from what used to be part of nova
On 31 October 2013 18:46, John Griffith john.griff...@solidfire.com wrote: Is your disappointment that there isn't a path from Essex -- Grizzly/Havana, or are you unhappy with the content? Upgrading Essex-Folsom introduced both the challenge of upgrading nova-volume to cinder and the challenge of upgrading nova-network to quantum. Upgrading Folsom-Grizzly presents the challenge of migrating nova-network to quantum and assumes that nova-volume has already been migrated to cinder. Upgrading Grizzly-Havana finally closes the door on nova-network as far as I can see, although I may be wrong. It comes down to the fact that while we cater for migrating between versions of a particular project we don't cater particularly well for migrating between projects when a project splits out from a parent project as was the case for both of the above. I'm not disappointed about the lack of ability to jump from Essex to Grizzly or Havana, but rather the lack of ability to migrate between projects. I would find it entirely suitable to upgrade from Essex to Folsom, then migrate from nova-volume to cinder and from nova-network to quantum, then only to upgrade to Grizzly. So to be quite honest we never intended to make skips like you describe. This misses the point somewhat, as I've made (hopefully) clear above. It's not about the skipping, but rather the clean migration, even within the same version, from something that used to be inherent (like nova-volume and cinder) to something that is now a new project with its own code tree. Going forward maybe we can come up with something better. The reason for raising this now is primarily to do just that. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Migrating to newer full projects from what used to be part of nova
On 31 October 2013 19:05, Russell Bryant rbry...@redhat.com wrote: Right, Nova (and probably other projects, too) only supports N to N+1 upgrades. If you need to go to N+2, you'll need to go through N+1 to get there. Dead right, and especially with the aggressive schedule we have this is the only sane approach for now. FWIW, improving upgrades is very high on the priority list across all of OpenStack. We have sessions all over the place to talk about it. It's getting a lot better. Yes it is, and while the upgrades haven't been perfect so far the increased focus on getting the grenade testing in place are sure to make a big difference. I just feel that it's important to highlight the gap to bring it into the same discussion and hopefully raise some awareness for those who are in a prime position to make the difference. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Migrating to newer full projects from what used to be part of nova
On Thu, Oct 31, 2013 at 2:18 PM, Jesse Pretorius jesse.pretor...@gmail.comwrote: On 31 October 2013 18:46, John Griffith john.griff...@solidfire.comwrote: Upgrading Essex-Folsom introduced both the challenge of upgrading nova-volume to cinder and the challenge of upgrading nova-network to quantum. Upgrading Folsom-Grizzly presents the challenge of migrating nova-network to quantum and assumes that nova-volume has already been migrated to cinder. Upgrading Grizzly-Havana finally closes the door on nova-network as far as I can see, although I may be wrong. To clarify a bit, while deprecated, nova-network has not lost any functionality in Havana yet. It also hasn't gained much (if any), but it still works. The majority of the testing is performed using nova-network and not neutron (yet). It comes down to the fact that while we cater for migrating between versions of a particular project we don't cater particularly well for migrating between projects when a project splits out from a parent project as was the case for both of the above. I am not aware of any effort to do a migration from nova-network to neutron, we certainly don't have it in grenade's near future. The differences are large and the development cost for that sort of migration is significant for something that a given deployment is only going to use once. It isn't a technical problem but a resource problem. Also, FWIW, I don't see another one of these situations coming anytime soon. All of the new project activity is around new services/features. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
