Re: [Openstack] Remove Zones code - FFE
On Sat, 2012-02-18 at 19:36 +, Ed Leafe wrote: I still prefer 'cell'. The parallel to single celled / multi-cellular life forms makes sense, and there is really no overloading of the word in the world of computers. I'll point out the concept of AFS cells. That said, +1 for cell… -- Kevin L. Mitchell kevin.mitch...@rackspace.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] Remove Zones code - FFE
Vishvananda Ishaya wrote: +1 to cell. +1 to cell. Short, clean and relatively not overloaded. Someone has to decide, and that someone is actually Vish :) [ and I didn't see any good opposition to cell yet among all the bikeshedding ] -- 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] Remove Zones code - FFE
On Sun, Feb 19, 2012 at 8:57 PM, Ed Leafe ed.le...@rackspace.com wrote: On Feb 19, 2012, at 12:53 PM, Mark Washenberger wrote: For this reason, whatever name we choose I would hope we prefix it with compute- (i.e. compute-zone or compute-cell) so that we aren't letting language trick us out of some of our better implementation options, such as allowing deployers to scale compute, volume, network, and api resources separately. I certainly don't want to preclude implementation options, and like the clarification that this is an issue of scaling compute, but I have two problems with the use of a prefix. First, it indirectly implies that scaling other entities would be done in the same manner: e.g., that an api-cell would have its resources independently deployed and with the inter-cell communication design as compute-cell. If the desired outcome is that we encourage different entities to implement their scaling independently and in the best manner for that entity, having a common name would seem to encourage the opposite. Second, it just seems cumbersome. We should ensure that documentation about cells is clear that this is a way of scaling compute, but for referring to them in code and in discussion, a simple name like 'zone' or 'cell' is simpler and cleaner. I've seen folks confuse swift zones with nova zones (the old version). The confusion led to assuming that swift zones are optional, and that nova zones somehow solve HA problems (talk about a mishmash of concepts) Adding clarity for *users* around the fact that cells are different in the context of nova compute vs any other context where the same term is used is a net plus imho so I agree that in the code we could use the short version. But I'd really like user/deployer facing locations (e.g. docs, flag files, API calls etc) be more explicit about what variant of cell is being referred to, and use compute-cell. -- Ed Leafe ___ 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] Remove Zones code - FFE
+1 for cell Sent from my iPhone On Feb 18, 2012, at 14:32, Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com wrote: +1 to cell. On Feb 18, 2012 9:41 AM, Dean Troyer dtro...@gmail.commailto:dtro...@gmail.com wrote: On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote: The term zone was adopted at a time when we weren't really focusing on mimicking the AWS Availability Zone concept, and in hindsight, it was a poor choice. So we should learn from that mistake and make sure we don't choose a replacement term that already has a common usage, such as shards segments or clusters. On Sat, Feb 18, 2012 at 12:54 PM, Chris Behrens cbehr...@codestud.commailto:cbehr...@codestud.com wrote: Sector? Getting away from computing related collectives: assembly - lends itself to sub-assembly, etc faction - When these servers over here disagree with those servers over there, such as in Xen vs KVM configurations schism - a fancier-and-harder-to-spell-and-pronounce faction coalition - when the Xen vs KVM schism gets patched up and instead they separate based on vi vs emacs or Gnome vs KDE And my favorite (partly because it is only 4 characters!): bloc - a group with a common interest, sometimes in voting situations dt -- Dean Troyer dtro...@gmail.commailto:dtro...@gmail.com ___ 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 ___ 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] Remove Zones code - FFE
On 02/18/2012 03:22 PM, Chris Behrens wrote: On Feb 18, 2012, at 11:36 AM, Ed Leafe wrote: I still prefer 'cell'. The parallel to single celled / multi-cellular life forms makes sense, and there is really no overloading of the word in the world of computers. I like 'cell' too. It makes sense. ++ for cell Anyway, I think 'cell' could be a good choice. At some point, I'd like to collect the ideas and put them up in a poll for vote. I suspect that's the only way we'll come to a fair conclusion. ++ -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] Remove Zones code - FFE
Remember that for many deployments, the entire system will be a single zone, so whatever term is used should make sense in a singular sense. That rules out names such as 'slice' or 'fragment'. I think this is a slightly outdated concept of zones. The key to scalability in nova is to divide the set of all compute nodes into subsets, each with its own messaging and database infrastructure. The granularity of everything else (scheduling, api, volume, network, what-have-you) is just an implementation or deployment detail that should be flexible depending on our ultimate implementation and any alternative strategies we expose to deployers. With this in mind it's still true that the smallest deployment would be likely include just one compute zone (or compute cell, as we are trending). But that is a far cry from the whole system even in a small deployment. For this reason, whatever name we choose I would hope we prefix it with compute- (i.e. compute-zone or compute-cell) so that we aren't letting language trick us out of some of our better implementation options, such as allowing deployers to scale compute, volume, network, and api resources separately. Ed Leafe ed.le...@rackspace.com said: On Feb 18, 2012, at 1:08 PM, Nathanael Burton wrote: Sectors remind me too much of disks. Agreed. How about? Layers, Slices, Fragments, Knots... Remember that for many deployments, the entire system will be a single zone, so whatever term is used should make sense in a singular sense. That rules out names such as 'slice' or 'fragment'. 'Knot'? In what sense can 'knot' be used? I still prefer 'cell'. The parallel to single celled / multi-cellular life forms makes sense, and there is really no overloading of the word in the world of computers. -- Ed Leafe ___ 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] Remove Zones code - FFE
Fully agree with the prefix for the cell... there should be storage-cells and compute-cells with different goals in terms of data locality and availability, zone has become too overloaded... Tim -Original Message- From: openstack-bounces+tim.bell=cern...@lists.launchpad.net [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf Of Mark Washenberger Sent: 19 February 2012 19:54 To: openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Remember that for many deployments, the entire system will be a single zone, so whatever term is used should make sense in a singular sense. That rules out names such as 'slice' or 'fragment'. I think this is a slightly outdated concept of zones. The key to scalability in nova is to divide the set of all compute nodes into subsets, each with its own messaging and database infrastructure. The granularity of everything else (scheduling, api, volume, network, what-have- you) is just an implementation or deployment detail that should be flexible depending on our ultimate implementation and any alternative strategies we expose to deployers. With this in mind it's still true that the smallest deployment would be likely include just one compute zone (or compute cell, as we are trending). But that is a far cry from the whole system even in a small deployment. For this reason, whatever name we choose I would hope we prefix it with compute- (i.e. compute-zone or compute-cell) so that we aren't letting language trick us out of some of our better implementation options, such as allowing deployers to scale compute, volume, network, and api resources separately. Ed Leafe ed.le...@rackspace.com said: On Feb 18, 2012, at 1:08 PM, Nathanael Burton wrote: Sectors remind me too much of disks. Agreed. How about? Layers, Slices, Fragments, Knots... Remember that for many deployments, the entire system will be a single zone, so whatever term is used should make sense in a singular sense. That rules out names such as 'slice' or 'fragment'. 'Knot'? In what sense can 'knot' be used? I still prefer 'cell'. The parallel to single celled / multi-cellular life forms makes sense, and there is really no overloading of the word in the world of computers. -- Ed Leafe ___ 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] Remove Zones code - FFE
++ to you Mark. Excellent suggestion on compute-cell. -jay On 02/19/2012 01:53 PM, Mark Washenberger wrote: Remember that for many deployments, the entire system will be a single zone, so whatever term is used should make sense in a singular sense. That rules out names such as 'slice' or 'fragment'. I think this is a slightly outdated concept of zones. The key to scalability in nova is to divide the set of all compute nodes into subsets, each with its own messaging and database infrastructure. The granularity of everything else (scheduling, api, volume, network, what-have-you) is just an implementation or deployment detail that should be flexible depending on our ultimate implementation and any alternative strategies we expose to deployers. With this in mind it's still true that the smallest deployment would be likely include just one compute zone (or compute cell, as we are trending). But that is a far cry from the whole system even in a small deployment. For this reason, whatever name we choose I would hope we prefix it with compute- (i.e. compute-zone or compute-cell) so that we aren't letting language trick us out of some of our better implementation options, such as allowing deployers to scale compute, volume, network, and api resources separately. Ed Leafeed.le...@rackspace.com said: On Feb 18, 2012, at 1:08 PM, Nathanael Burton wrote: Sectors remind me too much of disks. Agreed. How about? Layers, Slices, Fragments, Knots... Remember that for many deployments, the entire system will be a single zone, so whatever term is used should make sense in a singular sense. That rules out names such as 'slice' or 'fragment'. 'Knot'? In what sense can 'knot' be used? I still prefer 'cell'. The parallel to single celled / multi-cellular life forms makes sense, and there is really no overloading of the word in the world of computers. -- Ed Leafe ___ 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] Remove Zones code - FFE
+1 cell From: openstack-bounces+ed_conzel=dell@lists.launchpad.net [mailto:openstack-bounces+ed_conzel=dell@lists.launchpad.net] On Behalf Of Vishvananda Ishaya Sent: Saturday, February 18, 2012 2:24 PM To: Dean Troyer Cc: Mark Washenberger; Chris Behrens; Ed Leafe; openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE +1 to cell. On Feb 18, 2012 9:41 AM, Dean Troyer dtro...@gmail.commailto:dtro...@gmail.com wrote: On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote: The term zone was adopted at a time when we weren't really focusing on mimicking the AWS Availability Zone concept, and in hindsight, it was a poor choice. So we should learn from that mistake and make sure we don't choose a replacement term that already has a common usage, such as shards segments or clusters. On Sat, Feb 18, 2012 at 12:54 PM, Chris Behrens cbehr...@codestud.commailto:cbehr...@codestud.com wrote: Sector? Getting away from computing related collectives: assembly - lends itself to sub-assembly, etc faction - When these servers over here disagree with those servers over there, such as in Xen vs KVM configurations schism - a fancier-and-harder-to-spell-and-pronounce faction coalition - when the Xen vs KVM schism gets patched up and instead they separate based on vi vs emacs or Gnome vs KDE And my favorite (partly because it is only 4 characters!): bloc - a group with a common interest, sometimes in voting situations dt -- Dean Troyer dtro...@gmail.commailto:dtro...@gmail.com ___ 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.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Remove Zones code - FFE
+1 for compute-cells ~sean On Feb 19, 2012, at 11:10 AM, Tim Bell tim.b...@cern.ch wrote: Fully agree with the prefix for the cell... there should be storage-cells and compute-cells with different goals in terms of data locality and availability, zone has become too overloaded... Tim -Original Message- From: openstack-bounces+tim.bell=cern...@lists.launchpad.net [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf Of Mark Washenberger Sent: 19 February 2012 19:54 To: openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Remember that for many deployments, the entire system will be a single zone, so whatever term is used should make sense in a singular sense. That rules out names such as 'slice' or 'fragment'. I think this is a slightly outdated concept of zones. The key to scalability in nova is to divide the set of all compute nodes into subsets, each with its own messaging and database infrastructure. The granularity of everything else (scheduling, api, volume, network, what-have- you) is just an implementation or deployment detail that should be flexible depending on our ultimate implementation and any alternative strategies we expose to deployers. With this in mind it's still true that the smallest deployment would be likely include just one compute zone (or compute cell, as we are trending). But that is a far cry from the whole system even in a small deployment. For this reason, whatever name we choose I would hope we prefix it with compute- (i.e. compute-zone or compute-cell) so that we aren't letting language trick us out of some of our better implementation options, such as allowing deployers to scale compute, volume, network, and api resources separately. Ed Leafe ed.le...@rackspace.com said: On Feb 18, 2012, at 1:08 PM, Nathanael Burton wrote: Sectors remind me too much of disks. Agreed. How about? Layers, Slices, Fragments, Knots... Remember that for many deployments, the entire system will be a single zone, so whatever term is used should make sense in a singular sense. That rules out names such as 'slice' or 'fragment'. 'Knot'? In what sense can 'knot' be used? I still prefer 'cell'. The parallel to single celled / multi-cellular life forms makes sense, and there is really no overloading of the word in the world of computers. -- Ed Leafe ___ 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 ___ 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] Remove Zones code - FFE
On Feb 19, 2012, at 12:53 PM, Mark Washenberger wrote: For this reason, whatever name we choose I would hope we prefix it with compute- (i.e. compute-zone or compute-cell) so that we aren't letting language trick us out of some of our better implementation options, such as allowing deployers to scale compute, volume, network, and api resources separately. I certainly don't want to preclude implementation options, and like the clarification that this is an issue of scaling compute, but I have two problems with the use of a prefix. First, it indirectly implies that scaling other entities would be done in the same manner: e.g., that an api-cell would have its resources independently deployed and with the inter-cell communication design as compute-cell. If the desired outcome is that we encourage different entities to implement their scaling independently and in the best manner for that entity, having a common name would seem to encourage the opposite. Second, it just seems cumbersome. We should ensure that documentation about cells is clear that this is a way of scaling compute, but for referring to them in code and in discussion, a simple name like 'zone' or 'cell' is simpler and cleaner. -- Ed Leafe ___ 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] Remove Zones code - FFE
Sector? On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote: On Feb 15, 2012, at 10:07 AM, Armando Migliaccio wrote: I think you touched the crucial point here: what is exposed to the user and what not. Reading: http://wiki.openstack.org/MultiClusterZones#Design one would think that zones is a concept exposed to end users. You're saying otherwise; Is it just my misunderstanding or the wiki page is out of sync with the latest developments? If zones are not going to be exposed to the users, what will? Just availability zones? Zones *could* be exposed, but that is not intrinsic to their design. Availability zones could be designated as a particular level of nesting of the overall zone design, such as a particular region, and users could specify the AZ they want their instance to be provisioned in. But a region might have several data centers, each of which could be a zone, and individual DCs could have several zones within them based on the physical layout of the building, or networking capacity, or because of incremental build out, or for any number of other reasons, none of which are relevant to a user. The term zone was adopted at a time when we weren't really focusing on mimicking the AWS Availability Zone concept, and in hindsight, it was a poor choice. So we should learn from that mistake and make sure we don't choose a replacement term that already has a common usage, such as shards segments or clusters. -- Ed Leafe ___ 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] Remove Zones code - FFE
On Feb 18, 2012, at 11:08 AM, Nathanael Burton wrote: Sectors remind me too much of disks. Right.. I mentioned it because I would think it'd be rather difficult to confuse 'Nova sectors' with sectors on a disk. How about? Layers, Slices, Fragments, Knots... Of those, I'd probably prefer 'Knots'. - Chris On Feb 18, 2012 1:57 PM, Chris Behrens cbehr...@codestud.com wrote: Sector? On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote: On Feb 15, 2012, at 10:07 AM, Armando Migliaccio wrote: I think you touched the crucial point here: what is exposed to the user and what not. Reading: http://wiki.openstack.org/MultiClusterZones#Design one would think that zones is a concept exposed to end users. You're saying otherwise; Is it just my misunderstanding or the wiki page is out of sync with the latest developments? If zones are not going to be exposed to the users, what will? Just availability zones? Zones *could* be exposed, but that is not intrinsic to their design. Availability zones could be designated as a particular level of nesting of the overall zone design, such as a particular region, and users could specify the AZ they want their instance to be provisioned in. But a region might have several data centers, each of which could be a zone, and individual DCs could have several zones within them based on the physical layout of the building, or networking capacity, or because of incremental build out, or for any number of other reasons, none of which are relevant to a user. The term zone was adopted at a time when we weren't really focusing on mimicking the AWS Availability Zone concept, and in hindsight, it was a poor choice. So we should learn from that mistake and make sure we don't choose a replacement term that already has a common usage, such as shards segments or clusters. -- Ed Leafe ___ 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] Remove Zones code - FFE
On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote: The term zone was adopted at a time when we weren't really focusing on mimicking the AWS Availability Zone concept, and in hindsight, it was a poor choice. So we should learn from that mistake and make sure we don't choose a replacement term that already has a common usage, such as shards segments or clusters. On Sat, Feb 18, 2012 at 12:54 PM, Chris Behrens cbehr...@codestud.com wrote: Sector? Getting away from computing related collectives: assembly - lends itself to sub-assembly, etc faction - When these servers over here disagree with those servers over there, such as in Xen vs KVM configurations schism - a fancier-and-harder-to-spell-and-pronounce faction coalition - when the Xen vs KVM schism gets patched up and instead they separate based on vi vs emacs or Gnome vs KDE And my favorite (partly because it is only 4 characters!): bloc - a group with a common interest, sometimes in voting situations dt -- Dean Troyer dtro...@gmail.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] Remove Zones code - FFE
On Feb 18, 2012, at 1:08 PM, Nathanael Burton wrote: Sectors remind me too much of disks. Agreed. How about? Layers, Slices, Fragments, Knots... Remember that for many deployments, the entire system will be a single zone, so whatever term is used should make sense in a singular sense. That rules out names such as 'slice' or 'fragment'. 'Knot'? In what sense can 'knot' be used? I still prefer 'cell'. The parallel to single celled / multi-cellular life forms makes sense, and there is really no overloading of the word in the world of computers. -- Ed Leafe ___ 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] Remove Zones code - FFE
On Feb 18, 2012, at 11:36 AM, Ed Leafe wrote: I still prefer 'cell'. The parallel to single celled / multi-cellular life forms makes sense, and there is really no overloading of the word in the world of computers. I like 'cell' too. It makes sense. But 'cell' reminds me too much of batteries could be a response here if we're going to say that sectors remind me too much of disks. :) Batteries may less relate to computers, but there's: memory cell, 'Cell' processor. The question is.. is something like cell or sector or whatever really going to be confusing in the context of Openstack/Nova. 'Zone' is certainly an issue because of 'availability zone', so I think it's obviously not a choice. Anyway, I think 'cell' could be a good choice. At some point, I'd like to collect the ideas and put them up in a poll for vote. I suspect that's the only way we'll come to a fair conclusion. - 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] Remove Zones code - FFE
+1 to cell. On Feb 18, 2012 9:41 AM, Dean Troyer dtro...@gmail.com wrote: On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote: The term zone was adopted at a time when we weren't really focusing on mimicking the AWS Availability Zone concept, and in hindsight, it was a poor choice. So we should learn from that mistake and make sure we don't choose a replacement term that already has a common usage, such as shards segments or clusters. On Sat, Feb 18, 2012 at 12:54 PM, Chris Behrens cbehr...@codestud.com wrote: Sector? Getting away from computing related collectives: assembly - lends itself to sub-assembly, etc faction - When these servers over here disagree with those servers over there, such as in Xen vs KVM configurations schism - a fancier-and-harder-to-spell-and-pronounce faction coalition - when the Xen vs KVM schism gets patched up and instead they separate based on vi vs emacs or Gnome vs KDE And my favorite (partly because it is only 4 characters!): bloc - a group with a common interest, sometimes in voting situations dt -- Dean Troyer dtro...@gmail.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] Remove Zones code - FFE
Clump? -B On Feb 18, 2012, at 12:24 PM, Vishvananda Ishaya wrote: +1 to cell. On Feb 18, 2012 9:41 AM, Dean Troyer dtro...@gmail.com wrote: On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote: The term zone was adopted at a time when we weren't really focusing on mimicking the AWS Availability Zone concept, and in hindsight, it was a poor choice. So we should learn from that mistake and make sure we don't choose a replacement term that already has a common usage, such as shards segments or clusters. On Sat, Feb 18, 2012 at 12:54 PM, Chris Behrens cbehr...@codestud.com wrote: Sector? Getting away from computing related collectives: assembly - lends itself to sub-assembly, etc faction - When these servers over here disagree with those servers over there, such as in Xen vs KVM configurations schism - a fancier-and-harder-to-spell-and-pronounce faction coalition - when the Xen vs KVM schism gets patched up and instead they separate based on vi vs emacs or Gnome vs KDE And my favorite (partly because it is only 4 characters!): bloc - a group with a common interest, sometimes in voting situations dt -- Dean Troyer dtro...@gmail.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 ___ 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] Remove Zones code - FFE
On Feb 15, 2012, at 10:07 AM, Armando Migliaccio wrote: I think you touched the crucial point here: what is exposed to the user and what not. Reading: http://wiki.openstack.org/MultiClusterZones#Design one would think that zones is a concept exposed to end users. You're saying otherwise; Is it just my misunderstanding or the wiki page is out of sync with the latest developments? If zones are not going to be exposed to the users, what will? Just availability zones? Zones *could* be exposed, but that is not intrinsic to their design. Availability zones could be designated as a particular level of nesting of the overall zone design, such as a particular region, and users could specify the AZ they want their instance to be provisioned in. But a region might have several data centers, each of which could be a zone, and individual DCs could have several zones within them based on the physical layout of the building, or networking capacity, or because of incremental build out, or for any number of other reasons, none of which are relevant to a user. The term zone was adopted at a time when we weren't really focusing on mimicking the AWS Availability Zone concept, and in hindsight, it was a poor choice. So we should learn from that mistake and make sure we don't choose a replacement term that already has a common usage, such as shards segments or clusters. -- Ed Leafe ___ 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] Remove Zones code - FFE
-1 for ServerGroup because in the OSAPI terminology Server is a guest instance rather than a physical host. I assume that the relationship between zone and availability zone will still exist (and I remind you that host-aggregates have been coming along to). So you have: ?? -- Availability Zones -- Host Aggregates How about ?? == Deployment [Slice | Area | or Section] I know that Region may not be liked by some people, but that is good too. Armando -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Martin Paulo Sent: 14 February 2012 23:34 To: Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE ServerGroup gets my vote at the moment: it's a term that has an overloaded meaning (as far as I know) Martin On 15 February 2012 06:25, Jay Pipes jaypi...@gmail.com wrote: -1 on shard b/c of database terminology. -1 on cluster because of HPC and database terminology. Zone was originally used because it is general -- referring to merely a collection of hosts or other zones and not having a geographic connotation like Region does. Other possibilities: * Container (not recommended, as it is overloaded with Solaris or Linux container virtualization) * ServerGroup * HostGroup * Group * Collection If Zone isn't used, I suppose I would prefer ServerGroup -jay On 02/13/2012 08:45 PM, Yun Mao wrote: agreed.. -1 on shard, +1 on cluster Yun On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com wrote: Please not 'shards' Sharding as a concept is so intertwined with databases IMHO that it will serve to confuse even more. Why not 'cluster'? Martin On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.com wrote: Sorry, I'm late. Really getting down to the wire here. :) I've thrown up a version here: https://review.openstack.org/#change,4062 I've not functionally tested it yet, but there's really good test coverage for the zones service itself. I also have added a test_compute_zones which tests that all of the compute tests pass while using the new ComputeZonesAPI class. There's a couple bugs I note in the review and then I think I'm missing pushing some instance updates to the top in libvirt code. And missing an update for instance deletes in the compute manager. Going to hit those up today and finish this off. One other comment: It's been suggested we not call this stuff 'Zones' anymore. It gets confused with availability zones and so forth. Since this is really a way to shard nova, it has been suggested to call this 'Shards'. :) Not sure I dig that name completely, although it makes sense. Thoughts? - Chris On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote: Awesome Chris !!! Lean On Thu, Feb 9, 2012 at 3:26 PM, Alejandro Comisarioalejandro.comisa...@mercadolibre.com wrote: Niceee !! Alejandro. On 02/09/2012 02:02 PM, Chris Behrens wrote: I should be pushing something up by end of day... Even if it's not granted an FFE, I'll have a need to keep my branch updated and working, so I should at least always have a branch pushed up to a github account somewhere until F1 opens up. So, I guess worst case... there'll be a branch somewhere for you to play with. :) - Chris On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote: Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKenty jos...@pistoncloud.com mailto:jos...@pistoncloud.com , Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com Cc: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.netopenstack@lists.launchp ad.net mailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull
Re: [Openstack] Remove Zones code - FFE
I think this thing we call zones is fundamentally different from an Availability Zone or a Host Aggregate. An Availability Zone is about redundancy, a Host Aggregate is about capabilities, and a Zone is about infrastructure performance. I could easily imagine an Availability Zone larger than a Zone, and vice versa, thus I want to be cautious about talking about the relationships between them. And I think host aggregates are way too powerful an idea to keep inside either of those boxes as well. In the new implementation we don't have entire openstack deployments - we have parts of an openstack deployment. Hypervisors, DB, and the queuing service are all that are the new Zones. Words that make the most sense to me are words that talk about that split rather than words that talk about location or aggregation. Slice, section, segment, sector, division, partition - something along those lines. Gabe -Original Message- From: openstack-bounces+gabe.westmaas=rackspace@lists.launchpad.net [mailto:openstack-bounces+gabe.westmaas=rackspace@lists.launchpad.net] On Behalf Of Armando Migliaccio Sent: Wednesday, February 15, 2012 6:36 AM To: Martin Paulo; Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE -1 for ServerGroup because in the OSAPI terminology Server is a guest instance rather than a physical host. I assume that the relationship between zone and availability zone will still exist (and I remind you that host-aggregates have been coming along to). So you have: ?? -- Availability Zones -- Host Aggregates How about ?? == Deployment [Slice | Area | or Section] I know that Region may not be liked by some people, but that is good too. Armando -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On bounces+Behalf Of Martin Paulo Sent: 14 February 2012 23:34 To: Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE ServerGroup gets my vote at the moment: it's a term that has an overloaded meaning (as far as I know) Martin On 15 February 2012 06:25, Jay Pipes jaypi...@gmail.com wrote: -1 on shard b/c of database terminology. -1 on cluster because of HPC and database terminology. Zone was originally used because it is general -- referring to merely a collection of hosts or other zones and not having a geographic connotation like Region does. Other possibilities: * Container (not recommended, as it is overloaded with Solaris or Linux container virtualization) * ServerGroup * HostGroup * Group * Collection If Zone isn't used, I suppose I would prefer ServerGroup -jay On 02/13/2012 08:45 PM, Yun Mao wrote: agreed.. -1 on shard, +1 on cluster Yun On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com wrote: Please not 'shards' Sharding as a concept is so intertwined with databases IMHO that it will serve to confuse even more. Why not 'cluster'? Martin On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.com wrote: Sorry, I'm late. Really getting down to the wire here. :) I've thrown up a version here: https://review.openstack.org/#change,4062 I've not functionally tested it yet, but there's really good test coverage for the zones service itself. I also have added a test_compute_zones which tests that all of the compute tests pass while using the new ComputeZonesAPI class. There's a couple bugs I note in the review and then I think I'm missing pushing some instance updates to the top in libvirt code. And missing an update for instance deletes in the compute manager. Going to hit those up today and finish this off. One other comment: It's been suggested we not call this stuff 'Zones' anymore. It gets confused with availability zones and so forth. Since this is really a way to shard nova, it has been suggested to call this 'Shards'. :) Not sure I dig that name completely, although it makes sense. Thoughts? - Chris On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote: Awesome Chris !!! Lean On Thu, Feb 9, 2012 at 3:26 PM, Alejandro Comisarioalejandro.comisa...@mercadolibre.com wrote: Niceee !! Alejandro. On 02/09/2012 02:02 PM, Chris Behrens wrote: I should be pushing something up by end of day... Even if it's not granted an FFE, I'll have a need to keep my branch updated and working, so I should at least always have a branch pushed up to a github account somewhere until F1 opens up. So, I guess worst case... there'll be a branch somewhere for you to play with. :) - Chris On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote: Just raising another deployment waiting on this new Zone implementation - we currently have
Re: [Openstack] Remove Zones code - FFE
On 02/15/2012 09:13 AM, Gabe Westmaas wrote: I think this thing we call zones is fundamentally different from an Availability Zone or a Host Aggregate. An Availability Zone is about redundancy, a Host Aggregate is about capabilities, and a Zone is about infrastructure performance. That is an awesome way of describing the differences. I could easily imagine an Availability Zone larger than a Zone, and vice versa, thus I want to be cautious about talking about the relationships between them. Very true. And I think host aggregates are way too powerful an idea to keep inside either of those boxes as well. Perhaps, yes. In the new implementation we don't have entire openstack deployments - we have parts of an openstack deployment. Hypervisors, DB, and the queuing service are all that are the new Zones. Words that make the most sense to me are words that talk about that split rather than words that talk about location or aggregation. Eventually, though, even the hypervisor wouldn't be unique in a Zone, right? HostAggregates would take over the role of exposing virtualization capacity and abilities... so really, a Zone is just the partition of DB and MQ that services a segment of HostAggregates? Slice, section, segment, sector, division, partition - something along those lines. Slice is overloaded from Slicehost... Partition is fairly overloaded from filesystem and database terminology... Segment has network connotations... Sector has disk/drive connotations... Perhaps division is the only one left out of the above that seems to fit the bill? :) -jay Gabe -Original Message- From: openstack-bounces+gabe.westmaas=rackspace@lists.launchpad.net [mailto:openstack-bounces+gabe.westmaas=rackspace@lists.launchpad.net] On Behalf Of Armando Migliaccio Sent: Wednesday, February 15, 2012 6:36 AM To: Martin Paulo; Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE -1 for ServerGroup because in the OSAPI terminology Server is a guest instance rather than a physical host. I assume that the relationship between zone and availability zone will still exist (and I remind you that host-aggregates have been coming along to). So you have: ??-- Availability Zones-- Host Aggregates How about ?? == Deployment [Slice | Area | or Section] I know that Region may not be liked by some people, but that is good too. Armando -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On bounces+Behalf Of Martin Paulo Sent: 14 February 2012 23:34 To: Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE ServerGroup gets my vote at the moment: it's a term that has an overloaded meaning (as far as I know) Martin On 15 February 2012 06:25, Jay Pipesjaypi...@gmail.com wrote: -1 on shard b/c of database terminology. -1 on cluster because of HPC and database terminology. Zone was originally used because it is general -- referring to merely a collection of hosts or other zones and not having a geographic connotation like Region does. Other possibilities: * Container (not recommended, as it is overloaded with Solaris or Linux container virtualization) * ServerGroup * HostGroup * Group * Collection If Zone isn't used, I suppose I would prefer ServerGroup -jay On 02/13/2012 08:45 PM, Yun Mao wrote: agreed.. -1 on shard, +1 on cluster Yun On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com wrote: Please not 'shards' Sharding as a concept is so intertwined with databases IMHO that it will serve to confuse even more. Why not 'cluster'? Martin On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.comwrote: Sorry, I'm late. Really getting down to the wire here. :) I've thrown up a version here: https://review.openstack.org/#change,4062 I've not functionally tested it yet, but there's really good test coverage for the zones service itself. I also have added a test_compute_zones which tests that all of the compute tests pass while using the new ComputeZonesAPI class. There's a couple bugs I note in the review and then I think I'm missing pushing some instance updates to the top in libvirt code. And missing an update for instance deletes in the compute manager. Going to hit those up today and finish this off. One other comment: It's been suggested we not call this stuff 'Zones' anymore. It gets confused with availability zones and so forth. Since this is really a way to shard nova, it has been suggested to call this 'Shards'. :) Not sure I dig that name completely, although it makes sense. Thoughts? - Chris On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote: Awesome Chris !!! Lean On Thu, Feb 9, 2012 at 3:26 PM, Alejandro Comisarioalejandro.comisa...@mercadolibre.comwrote: Niceee !! Alejandro. On 02/09/2012
Re: [Openstack] Remove Zones code - FFE
I am a bit lost...what has size got to do with relationship? -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 15 February 2012 14:36 To: Gabe Westmaas Cc: Armando Migliaccio; Martin Paulo; openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE On 02/15/2012 09:13 AM, Gabe Westmaas wrote: I think this thing we call zones is fundamentally different from an Availability Zone or a Host Aggregate. An Availability Zone is about redundancy, a Host Aggregate is about capabilities, and a Zone is about infrastructure performance. That is an awesome way of describing the differences. I could easily imagine an Availability Zone larger than a Zone, and vice versa, thus I want to be cautious about talking about the relationships between them. Very true. I would disagree with this, maybe if you could elaborate a bit more... To me an availability zone is a partition of the infrastructure that can fail as a whole. I increase the reliability of my cloud app by deploying across multiple availability zones. To this aim, I would keep an availability zone as small as possible. A zone is for load balancing on a large (geographical) scale. I can scale my cloud app horizontally by deploying it in multiple zones. This way of arranging a cloud app would imply the following options: a) zones contains availability zones b) zones and availability zones are arranged in a grid but to me a) is way easier to understand. And I think host aggregates are way too powerful an idea to keep inside either of those boxes as well. Perhaps, yes. In the new implementation we don't have entire openstack deployments - we have parts of an openstack deployment. Hypervisors, DB, and the queuing service are all that are the new Zones. Words that make the most sense to me are words that talk about that split rather than words that talk about location or aggregation. Eventually, though, even the hypervisor wouldn't be unique in a Zone, right? HostAggregates would take over the role of exposing virtualization capacity and abilities... so really, a Zone is just the partition of DB and MQ that services a segment of HostAggregates? Slice, section, segment, sector, division, partition - something along those lines. Slice is overloaded from Slicehost... Partition is fairly overloaded from filesystem and database terminology... Segment has network connotations... Sector has disk/drive connotations... Perhaps division is the only one left out of the above that seems to fit the bill? :) -jay Gabe -Original Message- From: openstack-bounces+gabe.westmaas=rackspace@lists.launchpad.net [mailto:openstack-bounces+gabe.westmaas=rackspace.com@lists.launchpad. net] On Behalf Of Armando Migliaccio Sent: Wednesday, February 15, 2012 6:36 AM To: Martin Paulo; Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE -1 for ServerGroup because in the OSAPI terminology Server is a guest instance rather than a physical host. I assume that the relationship between zone and availability zone will still exist (and I remind you that host-aggregates have been coming along to). So you have: ??-- Availability Zones-- Host Aggregates How about ?? == Deployment [Slice | Area | or Section] I know that Region may not be liked by some people, but that is good too. Armando -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.ne openstack-bounces+t [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On bounces+Behalf Of Martin Paulo Sent: 14 February 2012 23:34 To: Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE ServerGroup gets my vote at the moment: it's a term that has an overloaded meaning (as far as I know) Martin On 15 February 2012 06:25, Jay Pipesjaypi...@gmail.com wrote: -1 on shard b/c of database terminology. -1 on cluster because of HPC and database terminology. Zone was originally used because it is general -- referring to merely a collection of hosts or other zones and not having a geographic connotation like Region does. Other possibilities: * Container (not recommended, as it is overloaded with Solaris or Linux container virtualization) * ServerGroup * HostGroup * Group * Collection If Zone isn't used, I suppose I would prefer ServerGroup -jay On 02/13/2012 08:45 PM, Yun Mao wrote: agreed.. -1 on shard, +1 on cluster Yun On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com wrote: Please not 'shards' Sharding as a concept is so intertwined with databases IMHO that it will serve to confuse even more. Why not 'cluster'? Martin On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.com wrote: Sorry, I'm
Re: [Openstack] Remove Zones code - FFE
On 2/15/12 9:48 AM, Armando Migliaccio armando.migliac...@eu.citrix.com wrote: I am a bit lost...what has size got to do with relationship? -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 15 February 2012 14:36 To: Gabe Westmaas Cc: Armando Migliaccio; Martin Paulo; openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE On 02/15/2012 09:13 AM, Gabe Westmaas wrote: I think this thing we call zones is fundamentally different from an Availability Zone or a Host Aggregate. An Availability Zone is about redundancy, a Host Aggregate is about capabilities, and a Zone is about infrastructure performance. That is an awesome way of describing the differences. I could easily imagine an Availability Zone larger than a Zone, and vice versa, thus I want to be cautious about talking about the relationships between them. Very true. I would disagree with this, maybe if you could elaborate a bit more... To me an availability zone is a partition of the infrastructure that can fail as a whole. I increase the reliability of my cloud app by deploying across multiple availability zones. To this aim, I would keep an availability zone as small as possible. A zone is for load balancing on a large (geographical) scale. I can scale my cloud app horizontally by deploying it in multiple zones. This way of arranging a cloud app would imply the following options: a) zones contains availability zones b) zones and availability zones are arranged in a grid but to me a) is way easier to understand. I think it all depends on scale. Some very large nova deployments may have an availability zone at the datacenter level, but for infrastructure performance reasons, need to split that up into multiple zones. A datacenter could be considered an availability zone depending on your application - you want to be redundant even if the datacenter goes down. Much smaller deployments may consider a single switch to the bound on an availability zone, and probably don't need to even consider what we call zones until they get to several of those switches. I think both these approaches are valid, and speaks to the fact that there isn't really a relationship between the two concepts. It may mean that we need more options when defining availability zones, but that's for another thread! Gabe And I think host aggregates are way too powerful an idea to keep inside either of those boxes as well. Perhaps, yes. In the new implementation we don't have entire openstack deployments - we have parts of an openstack deployment. Hypervisors, DB, and the queuing service are all that are the new Zones. Words that make the most sense to me are words that talk about that split rather than words that talk about location or aggregation. Eventually, though, even the hypervisor wouldn't be unique in a Zone, right? HostAggregates would take over the role of exposing virtualization capacity and abilities... so really, a Zone is just the partition of DB and MQ that services a segment of HostAggregates? Slice, section, segment, sector, division, partition - something along those lines. Slice is overloaded from Slicehost... Partition is fairly overloaded from filesystem and database terminology... Segment has network connotations... Sector has disk/drive connotations... Perhaps division is the only one left out of the above that seems to fit the bill? :) -jay Gabe -Original Message- From: openstack-bounces+gabe.westmaas=rackspace@lists.launchpad.net [mailto:openstack-bounces+gabe.westmaas=rackspace.com@lists.launchpad. net] On Behalf Of Armando Migliaccio Sent: Wednesday, February 15, 2012 6:36 AM To: Martin Paulo; Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE -1 for ServerGroup because in the OSAPI terminology Server is a guest instance rather than a physical host. I assume that the relationship between zone and availability zone will still exist (and I remind you that host-aggregates have been coming along to). So you have: ??-- Availability Zones-- Host Aggregates How about ?? == Deployment [Slice | Area | or Section] I know that Region may not be liked by some people, but that is good too. Armando -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.ne openstack-bounces+t [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On bounces+Behalf Of Martin Paulo Sent: 14 February 2012 23:34 To: Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE ServerGroup gets my vote at the moment: it's a term that has an overloaded meaning (as far as I know) Martin On 15 February 2012 06:25, Jay Pipesjaypi...@gmail.com wrote: -1 on shard b/c of database terminology. -1 on cluster because of HPC
Re: [Openstack] Remove Zones code - FFE
Gabe Westmaas gabe.westm...@rackspace.com said: I think both these approaches are valid, and speaks to the fact that there isn't really a relationship between the two concepts. Absolutely. An availability zone is about partitioning user instance infrastructure and exposing that partitioning scheme to the api user for reliability purposes. What we're talking about with zones is partitioning the nova *control* infrastructure (nova-api, nova-compute, database, rabbit, etc) in a way that enables scale. And we most likely do not expose these scale-partitioning details to the api user. The two concepts seem wholly independent to me, which is one reason why I think we should ditch the term zone. Gabe Westmaas gabe.westm...@rackspace.com said: On 2/15/12 9:48 AM, Armando Migliaccio armando.migliac...@eu.citrix.com wrote: I am a bit lost...what has size got to do with relationship? -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 15 February 2012 14:36 To: Gabe Westmaas Cc: Armando Migliaccio; Martin Paulo; openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE On 02/15/2012 09:13 AM, Gabe Westmaas wrote: I think this thing we call zones is fundamentally different from an Availability Zone or a Host Aggregate. An Availability Zone is about redundancy, a Host Aggregate is about capabilities, and a Zone is about infrastructure performance. That is an awesome way of describing the differences. I could easily imagine an Availability Zone larger than a Zone, and vice versa, thus I want to be cautious about talking about the relationships between them. Very true. I would disagree with this, maybe if you could elaborate a bit more... To me an availability zone is a partition of the infrastructure that can fail as a whole. I increase the reliability of my cloud app by deploying across multiple availability zones. To this aim, I would keep an availability zone as small as possible. A zone is for load balancing on a large (geographical) scale. I can scale my cloud app horizontally by deploying it in multiple zones. This way of arranging a cloud app would imply the following options: a) zones contains availability zones b) zones and availability zones are arranged in a grid but to me a) is way easier to understand. I think it all depends on scale. Some very large nova deployments may have an availability zone at the datacenter level, but for infrastructure performance reasons, need to split that up into multiple zones. A datacenter could be considered an availability zone depending on your application - you want to be redundant even if the datacenter goes down. Much smaller deployments may consider a single switch to the bound on an availability zone, and probably don't need to even consider what we call zones until they get to several of those switches. I think both these approaches are valid, and speaks to the fact that there isn't really a relationship between the two concepts. It may mean that we need more options when defining availability zones, but that's for another thread! Gabe And I think host aggregates are way too powerful an idea to keep inside either of those boxes as well. Perhaps, yes. In the new implementation we don't have entire openstack deployments - we have parts of an openstack deployment. Hypervisors, DB, and the queuing service are all that are the new Zones. Words that make the most sense to me are words that talk about that split rather than words that talk about location or aggregation. Eventually, though, even the hypervisor wouldn't be unique in a Zone, right? HostAggregates would take over the role of exposing virtualization capacity and abilities... so really, a Zone is just the partition of DB and MQ that services a segment of HostAggregates? Slice, section, segment, sector, division, partition - something along those lines. Slice is overloaded from Slicehost... Partition is fairly overloaded from filesystem and database terminology... Segment has network connotations... Sector has disk/drive connotations... Perhaps division is the only one left out of the above that seems to fit the bill? :) -jay Gabe -Original Message- From: openstack-bounces+gabe.westmaas=rackspace@lists.launchpad.net [mailto:openstack-bounces+gabe.westmaas=rackspace.com@lists.launchpad. net] On Behalf Of Armando Migliaccio Sent: Wednesday, February 15, 2012 6:36 AM To: Martin Paulo; Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE -1 for ServerGroup because in the OSAPI terminology Server is a guest instance rather than a physical host. I assume that the relationship between zone and availability zone will still exist (and I remind you that host-aggregates have been coming along to). So you have: ??-- Availability Zones-- Host Aggregates How about
Re: [Openstack] Remove Zones code - FFE
See comments inline. -Original Message- From: Mark Washenberger [mailto:mark.washenber...@rackspace.com] Sent: 15 February 2012 15:51 To: Gabe Westmaas Cc: Armando Migliaccio; Jay Pipes; openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Gabe Westmaas gabe.westm...@rackspace.com said: I think both these approaches are valid, and speaks to the fact that there isn't really a relationship between the two concepts. Absolutely. An availability zone is about partitioning user instance infrastructure and exposing that partitioning scheme to the api user for reliability purposes. What we're talking about with zones is partitioning the nova *control* infrastructure (nova-api, nova-compute, database, rabbit, etc) in a way that enables scale. And we most likely do not expose these scale-partitioning details to the api user. I think you touched the crucial point here: what is exposed to the user and what not. Reading: http://wiki.openstack.org/MultiClusterZones#Design one would think that zones is a concept exposed to end users. You're saying otherwise; Is it just my misunderstanding or the wiki page is out of sync with the latest developments? If zones are not going to be exposed to the users, what will? Just availability zones? The two concepts seem wholly independent to me, which is one reason why I think we should ditch the term zone. Gabe Westmaas gabe.westm...@rackspace.com said: On 2/15/12 9:48 AM, Armando Migliaccio armando.migliac...@eu.citrix.com wrote: I am a bit lost...what has size got to do with relationship? -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 15 February 2012 14:36 To: Gabe Westmaas Cc: Armando Migliaccio; Martin Paulo; openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE On 02/15/2012 09:13 AM, Gabe Westmaas wrote: I think this thing we call zones is fundamentally different from an Availability Zone or a Host Aggregate. An Availability Zone is about redundancy, a Host Aggregate is about capabilities, and a Zone is about infrastructure performance. That is an awesome way of describing the differences. I could easily imagine an Availability Zone larger than a Zone, and vice versa, thus I want to be cautious about talking about the relationships between them. Very true. I would disagree with this, maybe if you could elaborate a bit more... To me an availability zone is a partition of the infrastructure that can fail as a whole. I increase the reliability of my cloud app by deploying across multiple availability zones. To this aim, I would keep an availability zone as small as possible. A zone is for load balancing on a large (geographical) scale. I can scale my cloud app horizontally by deploying it in multiple zones. This way of arranging a cloud app would imply the following options: a) zones contains availability zones b) zones and availability zones are arranged in a grid but to me a) is way easier to understand. I think it all depends on scale. Some very large nova deployments may have an availability zone at the datacenter level, but for infrastructure performance reasons, need to split that up into multiple zones. A datacenter could be considered an availability zone depending on your application - you want to be redundant even if the datacenter goes down. Much smaller deployments may consider a single switch to the bound on an availability zone, and probably don't need to even consider what we call zones until they get to several of those switches. I think both these approaches are valid, and speaks to the fact that there isn't really a relationship between the two concepts. It may mean that we need more options when defining availability zones, but that's for another thread! Gabe And I think host aggregates are way too powerful an idea to keep inside either of those boxes as well. Perhaps, yes. In the new implementation we don't have entire openstack deployments - we have parts of an openstack deployment. Hypervisors, DB, and the queuing service are all that are the new Zones. Words that make the most sense to me are words that talk about that split rather than words that talk about location or aggregation. Eventually, though, even the hypervisor wouldn't be unique in a Zone, right? HostAggregates would take over the role of exposing virtualization capacity and abilities... so really, a Zone is just the partition of DB and MQ that services a segment of HostAggregates? Slice, section, segment, sector, division, partition - something along those lines. Slice is overloaded from Slicehost... Partition is fairly overloaded from filesystem and database terminology... Segment has network connotations... Sector has disk/drive connotations... Perhaps division is the only one
Re: [Openstack] Remove Zones code - FFE
-1 on shard b/c of database terminology. -1 on cluster because of HPC and database terminology. Zone was originally used because it is general -- referring to merely a collection of hosts or other zones and not having a geographic connotation like Region does. Other possibilities: * Container (not recommended, as it is overloaded with Solaris or Linux container virtualization) * ServerGroup * HostGroup * Group * Collection If Zone isn't used, I suppose I would prefer ServerGroup -jay On 02/13/2012 08:45 PM, Yun Mao wrote: agreed.. -1 on shard, +1 on cluster Yun On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com wrote: Please not 'shards' Sharding as a concept is so intertwined with databases IMHO that it will serve to confuse even more. Why not 'cluster'? Martin On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.com wrote: Sorry, I'm late. Really getting down to the wire here. :) I've thrown up a version here: https://review.openstack.org/#change,4062 I've not functionally tested it yet, but there's really good test coverage for the zones service itself. I also have added a test_compute_zones which tests that all of the compute tests pass while using the new ComputeZonesAPI class. There's a couple bugs I note in the review and then I think I'm missing pushing some instance updates to the top in libvirt code. And missing an update for instance deletes in the compute manager. Going to hit those up today and finish this off. One other comment: It's been suggested we not call this stuff 'Zones' anymore. It gets confused with availability zones and so forth. Since this is really a way to shard nova, it has been suggested to call this 'Shards'. :) Not sure I dig that name completely, although it makes sense. Thoughts? - Chris On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote: Awesome Chris !!! Lean On Thu, Feb 9, 2012 at 3:26 PM, Alejandro Comisarioalejandro.comisa...@mercadolibre.com wrote: Niceee !! Alejandro. On 02/09/2012 02:02 PM, Chris Behrens wrote: I should be pushing something up by end of day... Even if it's not granted an FFE, I'll have a need to keep my branch updated and working, so I should at least always have a branch pushed up to a github account somewhere until F1 opens up. So, I guess worst case... there'll be a branch somewhere for you to play with. :) - Chris On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote: Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKenty jos...@pistoncloud.com mailto:jos...@pistoncloud.com , Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com Cc: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.netopenstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull the trigger. -S *From:* Joshua McKenty [ jos...@pistoncloud.com mailto:jos...@pistoncloud.com ] *Sent:* Wednesday, February 01, 2012 4:45 PM *To:* Vishvananda Ishaya *Cc:* Sandy Walsh; openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] Remove Zones code - FFE +1 to Vish's points. I know there are some folks coming online in the Folsom timeline that can help out with the new stuff, but this feels a bit like going backwards. -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has. On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1
Re: [Openstack] Remove Zones code - FFE
This really is more of about sharding than grouping though. The specific goal of this implementation is to shard your nova database (on a capacity basis, not on a special key) and allow you to split (or shard :) connections to your rabbit server. This implementation should be used for performance reasons and no other. Its not really a way to organize your servers into different groups, or clusters or anything else, but to split lots and lots of hosts up. I'm not completely in love with shards either, but I do hope the name makes it clear the exact goal of this code, so that we don't attribute too much meaning to it. Gabe On 2/14/12 2:25 PM, Jay Pipes jaypi...@gmail.com wrote: -1 on shard b/c of database terminology. -1 on cluster because of HPC and database terminology. Zone was originally used because it is general -- referring to merely a collection of hosts or other zones and not having a geographic connotation like Region does. Other possibilities: * Container (not recommended, as it is overloaded with Solaris or Linux container virtualization) * ServerGroup * HostGroup * Group * Collection If Zone isn't used, I suppose I would prefer ServerGroup -jay On 02/13/2012 08:45 PM, Yun Mao wrote: agreed.. -1 on shard, +1 on cluster Yun On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com wrote: Please not 'shards' Sharding as a concept is so intertwined with databases IMHO that it will serve to confuse even more. Why not 'cluster'? Martin On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.com wrote: Sorry, I'm late. Really getting down to the wire here. :) I've thrown up a version here: https://review.openstack.org/#change,4062 I've not functionally tested it yet, but there's really good test coverage for the zones service itself. I also have added a test_compute_zones which tests that all of the compute tests pass while using the new ComputeZonesAPI class. There's a couple bugs I note in the review and then I think I'm missing pushing some instance updates to the top in libvirt code. And missing an update for instance deletes in the compute manager. Going to hit those up today and finish this off. One other comment: It's been suggested we not call this stuff 'Zones' anymore. It gets confused with availability zones and so forth. Since this is really a way to shard nova, it has been suggested to call this 'Shards'. :) Not sure I dig that name completely, although it makes sense. Thoughts? - Chris On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote: Awesome Chris !!! Lean On Thu, Feb 9, 2012 at 3:26 PM, Alejandro Comisarioalejandro.comisa...@mercadolibre.com wrote: Niceee !! Alejandro. On 02/09/2012 02:02 PM, Chris Behrens wrote: I should be pushing something up by end of day... Even if it's not granted an FFE, I'll have a need to keep my branch updated and working, so I should at least always have a branch pushed up to a github account somewhere until F1 opens up. So, I guess worst case... there'll be a branch somewhere for you to play with. :) - Chris On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote: Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKenty jos...@pistoncloud.com mailto:jos...@pistoncloud.com , Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com Cc: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.netopenstack@lists.launchpad.n et mailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull the trigger. -S --- - *From:* Joshua McKenty [ jos...@pistoncloud.com mailto:jos...@pistoncloud.com ] *Sent:* Wednesday, February 01, 2012 4:45 PM *To:* Vishvananda Ishaya *Cc:* Sandy Walsh; openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] Remove Zones code - FFE +1 to Vish's points. I know there are some folks coming online in the Folsom timeline
Re: [Openstack] Remove Zones code - FFE
Partitions maybe? On 2/14/12 4:01 PM, Gabe Westmaas gabe.westm...@rackspace.com wrote: This really is more of about sharding than grouping though. The specific goal of this implementation is to shard your nova database (on a capacity basis, not on a special key) and allow you to split (or shard :) connections to your rabbit server. This implementation should be used for performance reasons and no other. Its not really a way to organize your servers into different groups, or clusters or anything else, but to split lots and lots of hosts up. I'm not completely in love with shards either, but I do hope the name makes it clear the exact goal of this code, so that we don't attribute too much meaning to it. Gabe On 2/14/12 2:25 PM, Jay Pipes jaypi...@gmail.com wrote: -1 on shard b/c of database terminology. -1 on cluster because of HPC and database terminology. Zone was originally used because it is general -- referring to merely a collection of hosts or other zones and not having a geographic connotation like Region does. Other possibilities: * Container (not recommended, as it is overloaded with Solaris or Linux container virtualization) * ServerGroup * HostGroup * Group * Collection If Zone isn't used, I suppose I would prefer ServerGroup -jay On 02/13/2012 08:45 PM, Yun Mao wrote: agreed.. -1 on shard, +1 on cluster Yun On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com wrote: Please not 'shards' Sharding as a concept is so intertwined with databases IMHO that it will serve to confuse even more. Why not 'cluster'? Martin On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.com wrote: Sorry, I'm late. Really getting down to the wire here. :) I've thrown up a version here: https://review.openstack.org/#change,4062 I've not functionally tested it yet, but there's really good test coverage for the zones service itself. I also have added a test_compute_zones which tests that all of the compute tests pass while using the new ComputeZonesAPI class. There's a couple bugs I note in the review and then I think I'm missing pushing some instance updates to the top in libvirt code. And missing an update for instance deletes in the compute manager. Going to hit those up today and finish this off. One other comment: It's been suggested we not call this stuff 'Zones' anymore. It gets confused with availability zones and so forth. Since this is really a way to shard nova, it has been suggested to call this 'Shards'. :) Not sure I dig that name completely, although it makes sense. Thoughts? - Chris On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote: Awesome Chris !!! Lean On Thu, Feb 9, 2012 at 3:26 PM, Alejandro Comisarioalejandro.comisa...@mercadolibre.com wrote: Niceee !! Alejandro. On 02/09/2012 02:02 PM, Chris Behrens wrote: I should be pushing something up by end of day... Even if it's not granted an FFE, I'll have a need to keep my branch updated and working, so I should at least always have a branch pushed up to a github account somewhere until F1 opens up. So, I guess worst case... there'll be a branch somewhere for you to play with. :) - Chris On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote: Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKenty jos...@pistoncloud.com mailto:jos...@pistoncloud.com , Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com Cc: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.netopenstack@lists.launchpad. n et mailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull the trigger. -S -- - - *From:* Joshua McKenty [ jos...@pistoncloud.com mailto:jos...@pistoncloud.com ] *Sent:* Wednesday, February 01, 2012 4:45 PM *To:* Vishvananda Ishaya *Cc:* Sandy Walsh; openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] Remove Zones code - FFE +1
Re: [Openstack] Remove Zones code - FFE
ServerGroup gets my vote at the moment: it's a term that has an overloaded meaning (as far as I know) Martin On 15 February 2012 06:25, Jay Pipes jaypi...@gmail.com wrote: -1 on shard b/c of database terminology. -1 on cluster because of HPC and database terminology. Zone was originally used because it is general -- referring to merely a collection of hosts or other zones and not having a geographic connotation like Region does. Other possibilities: * Container (not recommended, as it is overloaded with Solaris or Linux container virtualization) * ServerGroup * HostGroup * Group * Collection If Zone isn't used, I suppose I would prefer ServerGroup -jay On 02/13/2012 08:45 PM, Yun Mao wrote: agreed.. -1 on shard, +1 on cluster Yun On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com wrote: Please not 'shards' Sharding as a concept is so intertwined with databases IMHO that it will serve to confuse even more. Why not 'cluster'? Martin On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.com wrote: Sorry, I'm late. Really getting down to the wire here. :) I've thrown up a version here: https://review.openstack.org/#change,4062 I've not functionally tested it yet, but there's really good test coverage for the zones service itself. I also have added a test_compute_zones which tests that all of the compute tests pass while using the new ComputeZonesAPI class. There's a couple bugs I note in the review and then I think I'm missing pushing some instance updates to the top in libvirt code. And missing an update for instance deletes in the compute manager. Going to hit those up today and finish this off. One other comment: It's been suggested we not call this stuff 'Zones' anymore. It gets confused with availability zones and so forth. Since this is really a way to shard nova, it has been suggested to call this 'Shards'. :) Not sure I dig that name completely, although it makes sense. Thoughts? - Chris On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote: Awesome Chris !!! Lean On Thu, Feb 9, 2012 at 3:26 PM, Alejandro Comisarioalejandro.comisa...@mercadolibre.com wrote: Niceee !! Alejandro. On 02/09/2012 02:02 PM, Chris Behrens wrote: I should be pushing something up by end of day... Even if it's not granted an FFE, I'll have a need to keep my branch updated and working, so I should at least always have a branch pushed up to a github account somewhere until F1 opens up. So, I guess worst case... there'll be a branch somewhere for you to play with. :) - Chris On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote: Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKenty jos...@pistoncloud.com mailto:jos...@pistoncloud.com , Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com Cc: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.netopenstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull the trigger. -S *From:* Joshua McKenty [ jos...@pistoncloud.com mailto:jos...@pistoncloud.com ] *Sent:* Wednesday, February 01, 2012 4:45 PM *To:* Vishvananda Ishaya *Cc:* Sandy Walsh; openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] Remove Zones code - FFE +1 to Vish's points. I know there are some folks coming online in the Folsom timeline that can help out with the new stuff, but this feels a bit like going backwards. -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has. On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have
Re: [Openstack] Remove Zones code - FFE
On Feb 14, 2012, at 1:25 PM, Jay Pipes wrote: -1 on shard b/c of database terminology. -1 on cluster because of HPC and database terminology. Zone was originally used because it is general -- referring to merely a collection of hosts or other zones and not having a geographic connotation like Region does. Other possibilities: * Container (not recommended, as it is overloaded with Solaris or Linux container virtualization) * ServerGroup * HostGroup * Group * Collection - Set - Cell - Huddle - Constellation - Herd/Flock//Pod/Animal metaphor of choice. - System If Zone isn't used, I suppose I would prefer ServerGroup -jay On 02/13/2012 08:45 PM, Yun Mao wrote: agreed.. -1 on shard, +1 on cluster Yun On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com wrote: Please not 'shards' Sharding as a concept is so intertwined with databases IMHO that it will serve to confuse even more. Why not 'cluster'? Martin On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.com wrote: Sorry, I'm late. Really getting down to the wire here. :) I've thrown up a version here: https://review.openstack.org/#change,4062 I've not functionally tested it yet, but there's really good test coverage for the zones service itself. I also have added a test_compute_zones which tests that all of the compute tests pass while using the new ComputeZonesAPI class. There's a couple bugs I note in the review and then I think I'm missing pushing some instance updates to the top in libvirt code. And missing an update for instance deletes in the compute manager. Going to hit those up today and finish this off. One other comment: It's been suggested we not call this stuff 'Zones' anymore. It gets confused with availability zones and so forth. Since this is really a way to shard nova, it has been suggested to call this 'Shards'. :) Not sure I dig that name completely, although it makes sense. Thoughts? - Chris On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote: Awesome Chris !!! Lean On Thu, Feb 9, 2012 at 3:26 PM, Alejandro Comisarioalejandro.comisa...@mercadolibre.com wrote: Niceee !! Alejandro. On 02/09/2012 02:02 PM, Chris Behrens wrote: I should be pushing something up by end of day... Even if it's not granted an FFE, I'll have a need to keep my branch updated and working, so I should at least always have a branch pushed up to a github account somewhere until F1 opens up. So, I guess worst case... there'll be a branch somewhere for you to play with. :) - Chris On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote: Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKenty jos...@pistoncloud.com mailto:jos...@pistoncloud.com , Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com Cc: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.netopenstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull the trigger. -S *From:* Joshua McKenty [ jos...@pistoncloud.com mailto:jos...@pistoncloud.com ] *Sent:* Wednesday, February 01, 2012 4:45 PM *To:* Vishvananda Ishaya *Cc:* Sandy Walsh; openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] Remove Zones code - FFE +1 to Vish's points. I know there are some folks coming online in the Folsom timeline that can help out with the new stuff, but this feels a bit like going backwards. -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has. On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote: I am all for pulling this out, but I'm a bit concerned with the fact
Re: [Openstack] Remove Zones code - FFE
On Wed, 2012-02-15 at 00:00 +, Monsyne Dragon wrote: Other possibilities: * Container (not recommended, as it is overloaded with Solaris or Linux container virtualization) * ServerGroup * HostGroup * Group * Collection - Set - Cell - Huddle - Constellation - Herd/Flock//Pod/Animal metaphor of choice. - System - Realm - Universe - Galaxy - Kingdom - Nebula ... -- Kevin L. Mitchell kevin.mitch...@rackspace.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] Remove Zones code - FFE
On Wed, 2012-02-15 at 00:00 +, Monsyne Dragon wrote: On Feb 14, 2012, at 1:25 PM, Jay Pipes wrote: -1 on shard b/c of database terminology. -1 on cluster because of HPC and database terminology. Zone was originally used because it is general -- referring to merely a collection of hosts or other zones and not having a geographic connotation like Region does. Other possibilities: * Container (not recommended, as it is overloaded with Solaris or Linux container virtualization) * ServerGroup * HostGroup * Group * Collection - Set - Cell - Huddle - Constellation - Herd/Flock//Pod/Animal metaphor of choice. - System % Flange ;) Happy Hacking! 7-11 ___ 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] Remove Zones code - FFE
On Feb 14, 2012, at 6:28 PM, Kevin L. Mitchell wrote: On Wed, 2012-02-15 at 00:00 +, Monsyne Dragon wrote: Other possibilities: * Container (not recommended, as it is overloaded with Solaris or Linux container virtualization) * ServerGroup * HostGroup * Group * Collection - Set - Cell - Huddle - Constellation - Herd/Flock//Pod/Animal metaphor of choice. - System - Realm - Universe - Galaxy - Kingdom - Nebula Since TCFKAZ (The Concept Formerly Known As Zones) represents a series of related but independent deployments of nova, something like 'Cell' or 'Galaxy' would be closest analogies. IMO, though, 'Galaxy' is too grandiose a term, despite the NASA heritage. So +1 to 'Cell'. -- Ed Leafe ___ 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] Remove Zones code - FFE
+1 on shards On Mon, Feb 13, 2012 at 1:45 AM, Sandy Walsh sandy.wa...@rackspace.comwrote: +1 on shards / partitions / anything to avoid the naming confusion with availability zones. (congrats on the branch! Looking forward to trying it!) From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net[openstack-bounces+sandy.walsh= rackspace@lists.launchpad.net] on behalf of Chris Behrens [ cbehr...@codestud.com] Sent: Sunday, February 12, 2012 6:50 PM To: Leandro Reox Cc: openstack@lists.launchpad.net; Chris Behrens Subject: Re: [Openstack] Remove Zones code - FFE Sorry, I'm late. Really getting down to the wire here. :) I've thrown up a version here: https://review.openstack.org/#change,4062 I've not functionally tested it yet, but there's really good test coverage for the zones service itself. I also have added a test_compute_zones which tests that all of the compute tests pass while using the new ComputeZonesAPI class. There's a couple bugs I note in the review and then I think I'm missing pushing some instance updates to the top in libvirt code. And missing an update for instance deletes in the compute manager. Going to hit those up today and finish this off. One other comment: It's been suggested we not call this stuff 'Zones' anymore. It gets confused with availability zones and so forth. Since this is really a way to shard nova, it has been suggested to call this 'Shards'. :) Not sure I dig that name completely, although it makes sense. Thoughts? - Chris On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote: Awesome Chris !!! Lean On Thu, Feb 9, 2012 at 3:26 PM, Alejandro Comisario alejandro.comisa...@mercadolibre.com wrote: Niceee !! Alejandro. On 02/09/2012 02:02 PM, Chris Behrens wrote: I should be pushing something up by end of day... Even if it's not granted an FFE, I'll have a need to keep my branch updated and working, so I should at least always have a branch pushed up to a github account somewhere until F1 opens up. So, I guess worst case... there'll be a branch somewhere for you to play with. :) - Chris On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote: Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKenty jos...@pistoncloud.com mailto:jos...@pistoncloud.com , Vishvananda Ishaya vishvana...@gmail.com mailto:vishvana...@gmail.com Cc: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull the trigger. -S *From:* Joshua McKenty [ jos...@pistoncloud.com mailto:jos...@pistoncloud.com ] *Sent:* Wednesday, February 01, 2012 4:45 PM *To:* Vishvananda Ishaya *Cc:* Sandy Walsh; openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] Remove Zones code - FFE +1 to Vish's points. I know there are some folks coming online in the Folsom timeline that can help out with the new stuff, but this feels a bit like going backwards. -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has. On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken
Re: [Openstack] Remove Zones code - FFE
Please not 'shards' Sharding as a concept is so intertwined with databases IMHO that it will serve to confuse even more. Why not 'cluster'? Martin On 13 February 2012 09:50, Chris Behrens cbehr...@codestud.com wrote: Sorry, I'm late. Really getting down to the wire here. :) I've thrown up a version here: https://review.openstack.org/#change,4062 I've not functionally tested it yet, but there's really good test coverage for the zones service itself. I also have added a test_compute_zones which tests that all of the compute tests pass while using the new ComputeZonesAPI class. There's a couple bugs I note in the review and then I think I'm missing pushing some instance updates to the top in libvirt code. And missing an update for instance deletes in the compute manager. Going to hit those up today and finish this off. One other comment: It's been suggested we not call this stuff 'Zones' anymore. It gets confused with availability zones and so forth. Since this is really a way to shard nova, it has been suggested to call this 'Shards'. :) Not sure I dig that name completely, although it makes sense. Thoughts? - Chris On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote: Awesome Chris !!! Lean On Thu, Feb 9, 2012 at 3:26 PM, Alejandro Comisario alejandro.comisa...@mercadolibre.com wrote: Niceee !! Alejandro. On 02/09/2012 02:02 PM, Chris Behrens wrote: I should be pushing something up by end of day... Even if it's not granted an FFE, I'll have a need to keep my branch updated and working, so I should at least always have a branch pushed up to a github account somewhere until F1 opens up. So, I guess worst case... there'll be a branch somewhere for you to play with. :) - Chris On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote: Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKenty jos...@pistoncloud.com mailto:jos...@pistoncloud.com , Vishvananda Ishaya vishvana...@gmail.com mailto:vishvana...@gmail.com Cc: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull the trigger. -S *From:* Joshua McKenty [ jos...@pistoncloud.com mailto:jos...@pistoncloud.com ] *Sent:* Wednesday, February 01, 2012 4:45 PM *To:* Vishvananda Ishaya *Cc:* Sandy Walsh; openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] Remove Zones code - FFE +1 to Vish's points. I know there are some folks coming online in the Folsom timeline that can help out with the new stuff, but this feels a bit like going backwards. -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has. On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken? 1.b) if yes, is it fixable 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release? Vish On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote: As part of the new (and optional) Zones code coming down the pipe, part of this is to remove the old Zones implementation. More info in the merge prop: https://review.openstack.org/#change,3629 So, can I? can I? Huh? ___ Mailing list: https://launchpad.net
Re: [Openstack] Remove Zones code - FFE
Maybe Resource Pool can fit better Lean On Mon, Feb 13, 2012 at 9:59 PM, Martin Paulo martin.pa...@gmail.comwrote: Please not 'shards' Sharding as a concept is so intertwined with databases IMHO that it will serve to confuse even more. Why not 'cluster'? Martin On 13 February 2012 09:50, Chris Behrens cbehr...@codestud.com wrote: Sorry, I'm late. Really getting down to the wire here. :) I've thrown up a version here: https://review.openstack.org/#change,4062 I've not functionally tested it yet, but there's really good test coverage for the zones service itself. I also have added a test_compute_zones which tests that all of the compute tests pass while using the new ComputeZonesAPI class. There's a couple bugs I note in the review and then I think I'm missing pushing some instance updates to the top in libvirt code. And missing an update for instance deletes in the compute manager. Going to hit those up today and finish this off. One other comment: It's been suggested we not call this stuff 'Zones' anymore. It gets confused with availability zones and so forth. Since this is really a way to shard nova, it has been suggested to call this 'Shards'. :) Not sure I dig that name completely, although it makes sense. Thoughts? - Chris On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote: Awesome Chris !!! Lean On Thu, Feb 9, 2012 at 3:26 PM, Alejandro Comisario alejandro.comisa...@mercadolibre.com wrote: Niceee !! Alejandro. On 02/09/2012 02:02 PM, Chris Behrens wrote: I should be pushing something up by end of day... Even if it's not granted an FFE, I'll have a need to keep my branch updated and working, so I should at least always have a branch pushed up to a github account somewhere until F1 opens up. So, I guess worst case... there'll be a branch somewhere for you to play with. :) - Chris On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote: Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKenty jos...@pistoncloud.com mailto:jos...@pistoncloud.com , Vishvananda Ishaya vishvana...@gmail.com mailto:vishvana...@gmail.com Cc: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull the trigger. -S *From:* Joshua McKenty [ jos...@pistoncloud.com mailto:jos...@pistoncloud.com ] *Sent:* Wednesday, February 01, 2012 4:45 PM *To:* Vishvananda Ishaya *Cc:* Sandy Walsh; openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] Remove Zones code - FFE +1 to Vish's points. I know there are some folks coming online in the Folsom timeline that can help out with the new stuff, but this feels a bit like going backwards. -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has. On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken? 1.b) if yes, is it fixable 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release? Vish On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote: As part of the new (and optional) Zones code coming down the pipe
Re: [Openstack] Remove Zones code - FFE
agreed.. -1 on shard, +1 on cluster Yun On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulo martin.pa...@gmail.com wrote: Please not 'shards' Sharding as a concept is so intertwined with databases IMHO that it will serve to confuse even more. Why not 'cluster'? Martin On 13 February 2012 09:50, Chris Behrens cbehr...@codestud.com wrote: Sorry, I'm late. Really getting down to the wire here. :) I've thrown up a version here: https://review.openstack.org/#change,4062 I've not functionally tested it yet, but there's really good test coverage for the zones service itself. I also have added a test_compute_zones which tests that all of the compute tests pass while using the new ComputeZonesAPI class. There's a couple bugs I note in the review and then I think I'm missing pushing some instance updates to the top in libvirt code. And missing an update for instance deletes in the compute manager. Going to hit those up today and finish this off. One other comment: It's been suggested we not call this stuff 'Zones' anymore. It gets confused with availability zones and so forth. Since this is really a way to shard nova, it has been suggested to call this 'Shards'. :) Not sure I dig that name completely, although it makes sense. Thoughts? - Chris On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote: Awesome Chris !!! Lean On Thu, Feb 9, 2012 at 3:26 PM, Alejandro Comisario alejandro.comisa...@mercadolibre.com wrote: Niceee !! Alejandro. On 02/09/2012 02:02 PM, Chris Behrens wrote: I should be pushing something up by end of day... Even if it's not granted an FFE, I'll have a need to keep my branch updated and working, so I should at least always have a branch pushed up to a github account somewhere until F1 opens up. So, I guess worst case... there'll be a branch somewhere for you to play with. :) - Chris On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote: Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKenty jos...@pistoncloud.com mailto:jos...@pistoncloud.com , Vishvananda Ishaya vishvana...@gmail.com mailto:vishvana...@gmail.com Cc: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull the trigger. -S *From:* Joshua McKenty [ jos...@pistoncloud.com mailto:jos...@pistoncloud.com ] *Sent:* Wednesday, February 01, 2012 4:45 PM *To:* Vishvananda Ishaya *Cc:* Sandy Walsh; openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] Remove Zones code - FFE +1 to Vish's points. I know there are some folks coming online in the Folsom timeline that can help out with the new stuff, but this feels a bit like going backwards. -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has. On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken? 1.b) if yes, is it fixable 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release? Vish On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote: As part of the new (and optional) Zones code coming down the pipe, part of this is to remove the old Zones implementation. More info in the merge prop: https://review.openstack.org/#change
Re: [Openstack] Remove Zones code - FFE
+1 on shards / partitions / anything to avoid the naming confusion with availability zones. (congrats on the branch! Looking forward to trying it!) From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Chris Behrens [cbehr...@codestud.com] Sent: Sunday, February 12, 2012 6:50 PM To: Leandro Reox Cc: openstack@lists.launchpad.net; Chris Behrens Subject: Re: [Openstack] Remove Zones code - FFE Sorry, I'm late. Really getting down to the wire here. :) I've thrown up a version here: https://review.openstack.org/#change,4062 I've not functionally tested it yet, but there's really good test coverage for the zones service itself. I also have added a test_compute_zones which tests that all of the compute tests pass while using the new ComputeZonesAPI class. There's a couple bugs I note in the review and then I think I'm missing pushing some instance updates to the top in libvirt code. And missing an update for instance deletes in the compute manager. Going to hit those up today and finish this off. One other comment: It's been suggested we not call this stuff 'Zones' anymore. It gets confused with availability zones and so forth. Since this is really a way to shard nova, it has been suggested to call this 'Shards'. :) Not sure I dig that name completely, although it makes sense. Thoughts? - Chris On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote: Awesome Chris !!! Lean On Thu, Feb 9, 2012 at 3:26 PM, Alejandro Comisario alejandro.comisa...@mercadolibre.com wrote: Niceee !! Alejandro. On 02/09/2012 02:02 PM, Chris Behrens wrote: I should be pushing something up by end of day... Even if it's not granted an FFE, I'll have a need to keep my branch updated and working, so I should at least always have a branch pushed up to a github account somewhere until F1 opens up. So, I guess worst case... there'll be a branch somewhere for you to play with. :) - Chris On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote: Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKenty jos...@pistoncloud.com mailto:jos...@pistoncloud.com , Vishvananda Ishaya vishvana...@gmail.com mailto:vishvana...@gmail.com Cc: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull the trigger. -S *From:* Joshua McKenty [ jos...@pistoncloud.com mailto:jos...@pistoncloud.com ] *Sent:* Wednesday, February 01, 2012 4:45 PM *To:* Vishvananda Ishaya *Cc:* Sandy Walsh; openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] Remove Zones code - FFE +1 to Vish's points. I know there are some folks coming online in the Folsom timeline that can help out with the new stuff, but this feels a bit like going backwards. -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has. On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken? 1.b) if yes, is it fixable 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release? Vish On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote: As part of the new
Re: [Openstack] Remove Zones code - FFE
Niceee !! Alejandro. On 02/09/2012 02:02 PM, Chris Behrens wrote: I should be pushing something up by end of day... Even if it's not granted an FFE, I'll have a need to keep my branch updated and working, so I should at least always have a branch pushed up to a github account somewhere until F1 opens up. So, I guess worst case... there'll be a branch somewhere for you to play with. :) - Chris On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote: Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walshsandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKentyjos...@pistoncloud.com mailto:jos...@pistoncloud.com, Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com Cc: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.netopenstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull the trigger. -S *From:* Joshua McKenty [jos...@pistoncloud.com mailto:jos...@pistoncloud.com] *Sent:* Wednesday, February 01, 2012 4:45 PM *To:* Vishvananda Ishaya *Cc:* Sandy Walsh; openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] Remove Zones code - FFE +1 to Vish's points. I know there are some folks coming online in the Folsom timeline that can help out with the new stuff, but this feels a bit like going backwards. -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has. On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken? 1.b) if yes, is it fixable 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release? Vish On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote: As part of the new (and optional) Zones code coming down the pipe, part of this is to remove the old Zones implementation. More info in the merge prop: https://review.openstack.org/#change,3629 So, can I? can I? Huh? ___ 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 ___ 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 ___ 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 ___ 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] Remove Zones code - FFE
Awesome Chris !!! Lean On Thu, Feb 9, 2012 at 3:26 PM, Alejandro Comisario alejandro.comisa...@mercadolibre.com wrote: Niceee !! Alejandro. On 02/09/2012 02:02 PM, Chris Behrens wrote: I should be pushing something up by end of day... Even if it's not granted an FFE, I'll have a need to keep my branch updated and working, so I should at least always have a branch pushed up to a github account somewhere until F1 opens up. So, I guess worst case... there'll be a branch somewhere for you to play with. :) - Chris On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote: Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walsh sandy.wa...@rackspace.commailto:sandy.wa...@rackspace.com sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKenty jos...@pistoncloud.commailto:jos...@pistoncloud.com jos...@pistoncloud.com, Vishvananda Ishaya vishvana...@gmail.com mailto:vishvana...@gmail.com vishvana...@gmail.com Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull the trigger. -S *From:* Joshua McKenty [jos...@pistoncloud.commailto:jos...@pistoncloud.com jos...@pistoncloud.com] *Sent:* Wednesday, February 01, 2012 4:45 PM *To:* Vishvananda Ishaya *Cc:* Sandy Walsh; openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.net *Subject:* Re: [Openstack] Remove Zones code - FFE +1 to Vish's points. I know there are some folks coming online in the Folsom timeline that can help out with the new stuff, but this feels a bit like going backwards. -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has. On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken? 1.b) if yes, is it fixable 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release? Vish On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote: As part of the new (and optional) Zones code coming down the pipe, part of this is to remove the old Zones implementation. More info in the merge prop:https://review.openstack.org/#change,3629 So, can I? can I? Huh? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net 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 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 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] Remove Zones code - FFE
Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKenty jos...@pistoncloud.com mailto:jos...@pistoncloud.com, Vishvananda Ishaya vishvana...@gmail.com mailto:vishvana...@gmail.com Cc: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull the trigger. -S *From:* Joshua McKenty [jos...@pistoncloud.com mailto:jos...@pistoncloud.com] *Sent:* Wednesday, February 01, 2012 4:45 PM *To:* Vishvananda Ishaya *Cc:* Sandy Walsh; openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] Remove Zones code - FFE +1 to Vish's points. I know there are some folks coming online in the Folsom timeline that can help out with the new stuff, but this feels a bit like going backwards. -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has. On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken? 1.b) if yes, is it fixable 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release? Vish On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote: As part of the new (and optional) Zones code coming down the pipe, part of this is to remove the old Zones implementation. More info in the merge prop: https://review.openstack.org/#change,3629 So, can I? can I? Huh? ___ 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 ___ 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 ___ 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 ___ 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] Remove Zones code - FFE
Well, I can actually say with confidence that the replacement would be stable by essex release. In fact, I expect the first commit to be a completely working solution that solves a number of problems with the original implementation. I don't think there's any issue getting something committed by the 15th if there's not much bickering on the review. The code is dead simple (currently a 500 line diff) and requires almost no modification of nova core. The only modifications to nova core are: Specify a different compute API class to use Modify rpc code to allow some kwargs to Connection __init__ so you can specify a specific rabbit server to use to send a message to a zone Add 2 new rpc methods: cast_to_zone and call_to_zone (which use the above change) Add a few zone_api.update_instance() calls in some places in compute so that we can push instance updates to top level zone. Migration for zones DB table to add rpc credential information. Besides that, the rest of the code is standalone. There's absolutely no concern that it'll make non-zones less stable. The few zone_api.update_instance() type calls would be no-ops when zones is turned off. As far as meeting a 2/15 date, here's what I have left: 1) clean up some things in my compute API subclass 2) finish writing tests (Vish: I was joking when I asked if you meant 15th of March ;) After what I would plan to push for the first commit, there's some refactoring desired to better share functionality between the zone scheduler and the host scheduler, but it'd be nothing required for Essex if we want to wait on that. And there's a desire to fold this new 'zones' nova service I'm creating into the current scheduler as potentially just a different scheduler driver. There's 1 thing that would be lost in what I'd propose: zone scheduling would initially be random zone selection. Either way, I think I'll throw something up for review by mid next week to see what thoughts are. I'd like to at least share what this looks like at the moment. If we still decide to wait for F1, cool. - Chris On Feb 2, 2012, at 1:27 AM, Vishvananda Ishaya wrote: I talked with chris a bit offline, and I'm a little concerned that we will be pushing too hard to try and get this into a working state by Essex. I think even if we to slam it in we will be faced with bugs that will make the essex version potentially as broken as the current zones code is. It is probably much more reasonable to target F1 as a delivery date for this feature. Alejandro, is your team ok with deploying milestone releases? I know it would take a lot of pressure off of Chris, Sandy, et. al. since they are trying to meet some pretty hard delivery dates as it is. Vish On Feb 1, 2012, at 3:44 PM, Alejandro Comisario wrote: Sounds pretty good Vish. Since we are mostly deployers, and the ones who are gonna try the new code from day zero, whats good for Sandy, its good for us. Alejandro. On 02/01/2012 06:57 PM, Vishvananda Ishaya wrote: Thanks for the feedback. It is good to get input from one of the largest openstack installs! So it sounds like the existing code is pretty broken. Based on this feedback I would like to propose the following: 1) cut out zones code (meaning merge the existing branch) 2) grant an FFe for the new rpc based zone code as long is it can be merged without heavily modifying core. This means: a) it should be deployable with the feature disabled b) it should only include minor modifications to core components c) if a major change is needed to distributed_scheduler (for example), consider leaving the existing version in, and copying the code to a new file (distributed_scheduler_v2) and doing the modifications there. That way we can minimize chances of breakage d) it needs to be merged by the 15th Does that seem reasonable? Vish On Feb 1, 2012, at 1:42 PM, Alejandro Comisario wrote: Hi guys. Its true that we are trying to make multizones work, actually we did, but we get into an instance were listing all vms from the parent zone ( where is has to go thru all the child zones ) is buggy ( if not impossible by now ). So, if there is a new zone architecture that actually works ( we want to stop using our own deployer to do that ) or has a chance to be fully working when 2012-1 is out, (we would prefer not to wait till Folsom) we are totally into it ! since by now, we were actually waiting for this new Zones code to come out to try again. Alejandro. On 02/01/2012 06:17 PM, Nathanael Burton wrote: +1 On Feb 1, 2012 4:13 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: I would prefer that if it can be done super-super fast. :) Vish On Feb 1, 2012, at 1:04 PM, Chris Behrens wrote: I wonder if we can use some of the architecture of the new code and move the current implementation to that model. It'd preserve the existing functionality, set us up for
Re: [Openstack] Remove Zones code - FFE
Chris Behrens wrote: Well, I can actually say with confidence that the replacement would be stable by essex release. In fact, I expect the first commit to be a completely working solution that solves a number of problems with the original implementation. I don't think there's any issue getting something committed by the 15th if there's not much bickering on the review. The code is dead simple (currently a 500 line diff) and requires almost no modification of nova core. The only modifications to nova core are: Specify a different compute API class to use Modify rpc code to allow some kwargs to Connection __init__ so you can specify a specific rabbit server to use to send a message to a zone Add 2 new rpc methods: cast_to_zone and call_to_zone (which use the above change) Add a few zone_api.update_instance() calls in some places in compute so that we can push instance updates to top level zone. Migration for zones DB table to add rpc credential information. Besides that, the rest of the code is standalone. There's absolutely no concern that it'll make non-zones less stable. The few zone_api.update_instance() type calls would be no-ops when zones is turned off. It still introduces a bit of disturbance in the Force, if only by loss of focus on bugfixing. From where I'm standing it boils down to how broken the current zone code is... and how much better the replacement code would be. I'll admit I have trouble properly evaluating how functional zone code is with my couple laptops, so I'll trust you guys (Chris, Vish, Alejandro) on that: if the new code is significantly more functional than the old one, and the whole thing does not really touch non-zone code, I'd say go for it... by the 15th at the latest ! -- 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] Remove Zones code - FFE
Thierry et. al. Responses inline. On 02/02/2012 06:03 AM, Thierry Carrez wrote: Chris Behrens wrote: Well, I can actually say with confidence that the replacement would be stable by essex release. In fact, I expect the first commit to be a completely working solution that solves a number of problems with the original implementation. I don't think there's any issue getting something committed by the 15th if there's not much bickering on the review. The code is dead simple (currently a 500 line diff) and requires almost no modification of nova core. The only modifications to nova core are: Specify a different compute API class to use Modify rpc code to allow some kwargs to Connection __init__ so you can specify a specific rabbit server to use to send a message to a zone Add 2 new rpc methods: cast_to_zone and call_to_zone (which use the above change) Add a few zone_api.update_instance() calls in some places in compute so that we can push instance updates to top level zone. Migration for zones DB table to add rpc credential information. There's 1 thing that would be lost in what I'd propose: zone scheduling would initially be random zone selection. There's actually no concern for us in the scheduler for being random actually, we prefer this since our strategy is more aligned with the spread first scheduling method. Besides that, the rest of the code is standalone. There's absolutely no concern that it'll make non-zones less stable. The few zone_api.update_instance() type calls would be no-ops when zones is turned off. It still introduces a bit of disturbance in the Force, if only by loss of focus on bugfixing. From where I'm standing it boils down to how broken the current zone code is... and how much better the replacement code would be. I'll admit I have trouble properly evaluating how functional zone code is with my couple laptops, so I'll trust you guys (Chris, Vish, Alejandro) on that: if the new code is significantly more functional than the old one, and the whole thing does not really touch non-zone code, I'd say go for it... by the 15th at the latest ! So, if Chris is confident to merge the new zone code to 2/15 we'll be pleased to test it, to continue to our new features early adoption philosophy :D As we said before, today we are covering our need of multizone across our datacenters with our in-house custom scheduling api, one that we want to deprecate asap as we move to Essex making direct calls to the parent zone ( nova api ) doing this in a native way. For us, multizone is a MUST for taking Essex into production, so if you Chris can make it to 2/15 we will be testing all this new code on 2/15 one minute later after commit :D so we can give you as much feedback as you need almost immediately. Vish, if multizone actually worked since E-2 we were thinking about going with E-3 into prod and putting all our efforts till we wait for 2012-1, this is not what we prefer, but since we didnt find a feature more attractive in diablo than cactus and multizone code in diablo was pretty much broken than Essex. We have to make a balance between what we need and what openstack actually gives us ( in that case, we have to develop ourselves without digging into nova-core source code) So definitely its a +1 for merging the code to 2/15. Best. Alejandro. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Remove Zones code - FFE
As part of the new (and optional) Zones code coming down the pipe, part of this is to remove the old Zones implementation. More info in the merge prop: https://review.openstack.org/#change,3629 So, can I? can I? Huh? ___ 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] Remove Zones code - FFE
I would prefer that if it can be done super-super fast. :) Vish On Feb 1, 2012, at 1:04 PM, Chris Behrens wrote: I wonder if we can use some of the architecture of the new code and move the current implementation to that model. It'd preserve the existing functionality, set us up for the new implementation, and fits in with 'cleanup' for E4, etc. On Feb 1, 2012, at 2:41 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken? 1.b) if yes, is it fixable 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release? Vish On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote: As part of the new (and optional) Zones code coming down the pipe, part of this is to remove the old Zones implementation. More info in the merge prop: https://review.openstack.org/#change,3629 So, can I? can I? Huh? ___ 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] Remove Zones code - FFE
+1 On Feb 1, 2012 4:13 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: I would prefer that if it can be done super-super fast. :) Vish On Feb 1, 2012, at 1:04 PM, Chris Behrens wrote: I wonder if we can use some of the architecture of the new code and move the current implementation to that model. It'd preserve the existing functionality, set us up for the new implementation, and fits in with 'cleanup' for E4, etc. On Feb 1, 2012, at 2:41 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken? 1.b) if yes, is it fixable 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release? Vish On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote: As part of the new (and optional) Zones code coming down the pipe, part of this is to remove the old Zones implementation. More info in the merge prop: https://review.openstack.org/#change,3629 So, can I? can I? Huh? ___ 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 ___ 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] Remove Zones code - FFE
Hi guys. Its true that we are trying to make multizones work, actually we did, but we get into an instance were listing all vms from the parent zone ( where is has to go thru all the child zones ) is buggy ( if not impossible by now ). So, if there is a new zone architecture that actually works ( we want to stop using our own deployer to do that ) or has a chance to be fully working when 2012-1 is out, (we would prefer not to wait till Folsom) we are totally into it ! since by now, we were actually waiting for this new Zones code to come out to try again. Alejandro. On 02/01/2012 06:17 PM, Nathanael Burton wrote: +1 On Feb 1, 2012 4:13 PM, Vishvananda Ishaya vishvana...@gmail.com mailto:vishvana...@gmail.com wrote: I would prefer that if it can be done super-super fast. :) Vish On Feb 1, 2012, at 1:04 PM, Chris Behrens wrote: I wonder if we can use some of the architecture of the new code and move the current implementation to that model. It'd preserve the existing functionality, set us up for the new implementation, and fits in with 'cleanup' for E4, etc. On Feb 1, 2012, at 2:41 PM, Vishvananda Ishaya vishvana...@gmail.com mailto:vishvana...@gmail.com wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken? 1.b) if yes, is it fixable 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release? Vish On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote: As part of the new (and optional) Zones code coming down the pipe, part of this is to remove the old Zones implementation. More info in the merge prop: https://review.openstack.org/#change,3629 So, can I? can I? Huh? ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack 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] Remove Zones code - FFE
Sounds pretty good Vish. Since we are mostly deployers, and the ones who are gonna try the new code from day zero, whats good for Sandy, its good for us. Alejandro. On 02/01/2012 06:57 PM, Vishvananda Ishaya wrote: Thanks for the feedback. It is good to get input from one of the largest openstack installs! So it sounds like the existing code is pretty broken. Based on this feedback I would like to propose the following: 1) cut out zones code (meaning merge the existing branch) 2) grant an FFe for the new rpc based zone code as long is it can be merged without heavily modifying core. This means: a) it should be deployable with the feature disabled b) it should only include minor modifications to core components c) if a major change is needed to distributed_scheduler (for example), consider leaving the existing version in, and copying the code to a new file (distributed_scheduler_v2) and doing the modifications there. That way we can minimize chances of breakage d) it needs to be merged by the 15th Does that seem reasonable? Vish On Feb 1, 2012, at 1:42 PM, Alejandro Comisario wrote: Hi guys. Its true that we are trying to make multizones work, actually we did, but we get into an instance were listing all vms from the parent zone ( where is has to go thru all the child zones ) is buggy ( if not impossible by now ). So, if there is a new zone architecture that actually works ( we want to stop using our own deployer to do that ) or has a chance to be fully working when 2012-1 is out, (we would prefer not to wait till Folsom) we are totally into it ! since by now, we were actually waiting for this new Zones code to come out to try again. Alejandro. On 02/01/2012 06:17 PM, Nathanael Burton wrote: +1 On Feb 1, 2012 4:13 PM, Vishvananda Ishaya vishvana...@gmail.com mailto:vishvana...@gmail.com wrote: I would prefer that if it can be done super-super fast. :) Vish On Feb 1, 2012, at 1:04 PM, Chris Behrens wrote: I wonder if we can use some of the architecture of the new code and move the current implementation to that model. It'd preserve the existing functionality, set us up for the new implementation, and fits in with 'cleanup' for E4, etc. On Feb 1, 2012, at 2:41 PM, Vishvananda Ishaya vishvana...@gmail.com mailto:vishvana...@gmail.com wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken? 1.b) if yes, is it fixable 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release? Vish On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote: As part of the new (and optional) Zones code coming down the pipe, part of this is to remove the old Zones implementation. More info in the merge prop: https://review.openstack.org/#change,3629 So, can I? can I? Huh? ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack 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 https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack
Re: [Openstack] Remove Zones code - FFE
Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull the trigger. -S From: Joshua McKenty [jos...@pistoncloud.com] Sent: Wednesday, February 01, 2012 4:45 PM To: Vishvananda Ishaya Cc: Sandy Walsh; openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE +1 to Vish's points. I know there are some folks coming online in the Folsom timeline that can help out with the new stuff, but this feels a bit like going backwards. -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has. On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken? 1.b) if yes, is it fixable 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release? Vish On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote: As part of the new (and optional) Zones code coming down the pipe, part of this is to remove the old Zones implementation. More info in the merge prop: https://review.openstack.org/#change,3629 So, can I? can I? Huh? ___ 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 ___ 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] Remove Zones code - FFE
I talked with chris a bit offline, and I'm a little concerned that we will be pushing too hard to try and get this into a working state by Essex. I think even if we to slam it in we will be faced with bugs that will make the essex version potentially as broken as the current zones code is. It is probably much more reasonable to target F1 as a delivery date for this feature. Alejandro, is your team ok with deploying milestone releases? I know it would take a lot of pressure off of Chris, Sandy, et. al. since they are trying to meet some pretty hard delivery dates as it is. Vish On Feb 1, 2012, at 3:44 PM, Alejandro Comisario wrote: Sounds pretty good Vish. Since we are mostly deployers, and the ones who are gonna try the new code from day zero, whats good for Sandy, its good for us. Alejandro. On 02/01/2012 06:57 PM, Vishvananda Ishaya wrote: Thanks for the feedback. It is good to get input from one of the largest openstack installs! So it sounds like the existing code is pretty broken. Based on this feedback I would like to propose the following: 1) cut out zones code (meaning merge the existing branch) 2) grant an FFe for the new rpc based zone code as long is it can be merged without heavily modifying core. This means: a) it should be deployable with the feature disabled b) it should only include minor modifications to core components c) if a major change is needed to distributed_scheduler (for example), consider leaving the existing version in, and copying the code to a new file (distributed_scheduler_v2) and doing the modifications there. That way we can minimize chances of breakage d) it needs to be merged by the 15th Does that seem reasonable? Vish On Feb 1, 2012, at 1:42 PM, Alejandro Comisario wrote: Hi guys. Its true that we are trying to make multizones work, actually we did, but we get into an instance were listing all vms from the parent zone ( where is has to go thru all the child zones ) is buggy ( if not impossible by now ). So, if there is a new zone architecture that actually works ( we want to stop using our own deployer to do that ) or has a chance to be fully working when 2012-1 is out, (we would prefer not to wait till Folsom) we are totally into it ! since by now, we were actually waiting for this new Zones code to come out to try again. Alejandro. On 02/01/2012 06:17 PM, Nathanael Burton wrote: +1 On Feb 1, 2012 4:13 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: I would prefer that if it can be done super-super fast. :) Vish On Feb 1, 2012, at 1:04 PM, Chris Behrens wrote: I wonder if we can use some of the architecture of the new code and move the current implementation to that model. It'd preserve the existing functionality, set us up for the new implementation, and fits in with 'cleanup' for E4, etc. On Feb 1, 2012, at 2:41 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken? 1.b) if yes, is it fixable 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release? Vish On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote: As part of the new (and optional) Zones code coming down the pipe, part of this is to remove the old Zones implementation. More info in the merge prop: https://review.openstack.org/#change,3629 So, can I? can I? Huh? ___ 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 ___ 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
