Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
Hello, +1 to 'let's work towards having a single Node Profile (flavor) associated with each Deployment Role (pages 12 13 of the latest mockups[1])' Good start. We could have also more flavors per role now, user just would have to be advised: You are using one image for multiple hardware, so be sure it's compatible. So it probably make sense to limit it for one flavor per role for now. Regards Ladislav On 02/03/2014 12:23 PM, Tomas Sedovic wrote: My apologies for firing this off and then hiding under the FOSDEM rock. In light of the points raised by Devananda and Robert, I no longer think fiddling with the scheduler is the way to go. Note this was never intended to break/confuse all TripleO users -- I considered it a cleaner equivalent to entering incorrect HW specs (i.e. instead of doing that you would switch to this other filter in nova.conf). Regardless, I stand corrected on the distinction between heterogeneous hardware all the way and having a flavour per service definition. That was a very good point to raise. I'm fine with both approaches. So yeah, let's work towards having a single Node Profile (flavor) associated with each Deployment Role (pages 12 13 of the latest mockups[1]), optionally starting with requiring all the Node Profiles to be equal. Once that's working fine, we can look into the harder case of having multiple Node Profiles within a Deployment Role. Is everyone comfortable with that? Tomas [1]: http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-27_tripleo-ui-icehouse.pdf On 03/02/14 00:21, Robert Collins wrote: On 3 February 2014 08:45, Jaromir Coufal jcou...@redhat.com wrote: However, taking a step back, maybe the real answer is: a) homogeneous nodes b) document. . . - **unsupported** means of demoing Tuskar (set node attributes to match flavors, hack the scheduler, etc) Why are people calling it 'hack'? It's an additional filter to nova-scheduler...? It doesn't properly support the use case; its extra code to write and test and configure that is precisely identical to mis-registering nodes. - our goals of supporting heterogeneous nodes for the J-release. I wouldn't talk about J-release. I would talk about next iteration or next step. Nobody said that we are not able to make it in I-release. +1 Does this seem reasonable to everyone? Mainn Well +1 for a) and it's documentation. However me and Robert, we look to have different opinions on what 'homogeneous' means in our context. I think we should clarify that. So I think my point is more this: - either this iteration is entirely limited to homogeneous hardware, in which case, document it, not workarounds or custom schedulers etc. - or it isn't limited, in which case we should consider the options: - flavor per service definition - custom scheduler - register nodes wrongly -Rob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 2014/03/02 12:23, Tomas Sedovic wrote: My apologies for firing this off and then hiding under the FOSDEM rock. In light of the points raised by Devananda and Robert, I no longer think fiddling with the scheduler is the way to go. Note this was never intended to break/confuse all TripleO users -- I considered it a cleaner equivalent to entering incorrect HW specs (i.e. instead of doing that you would switch to this other filter in nova.conf). Regardless, I stand corrected on the distinction between heterogeneous hardware all the way and having a flavour per service definition. That was a very good point to raise. I'm fine with both approaches. So yeah, let's work towards having a single Node Profile (flavor) associated with each Deployment Role (pages 12 13 of the latest mockups[1]), optionally starting with requiring all the Node Profiles to be equal. I think here is a small misinterpretation. All Node Profiles don't have to be equal. We just support one Node Profile association per role. Once that's working fine, we can look into the harder case of having multiple Node Profiles within a Deployment Role. Is everyone comfortable with that? Tomas [1]: http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-27_tripleo-ui-icehouse.pdf +1 for this approach. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 2014/03/02 00:21, Robert Collins wrote: [snip] However me and Robert, we look to have different opinions on what 'homogeneous' means in our context. I think we should clarify that. So I think my point is more this: - either this iteration is entirely limited to homogeneous hardware, in which case, document it, not workarounds or custom schedulers etc. - or it isn't limited, in which case we should consider the options: - flavor per service definition It was confirmed that this solution doesn't have to be big chunk of work worth splitting into different iterations, so +1 for this solution in the first iteration. - custom scheduler - register nodes wrongly -Rob Thanks all for clarification. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
My apologies for firing this off and then hiding under the FOSDEM rock. In light of the points raised by Devananda and Robert, I no longer think fiddling with the scheduler is the way to go. Note this was never intended to break/confuse all TripleO users -- I considered it a cleaner equivalent to entering incorrect HW specs (i.e. instead of doing that you would switch to this other filter in nova.conf). Regardless, I stand corrected on the distinction between heterogeneous hardware all the way and having a flavour per service definition. That was a very good point to raise. I'm fine with both approaches. So yeah, let's work towards having a single Node Profile (flavor) associated with each Deployment Role (pages 12 13 of the latest mockups[1]), optionally starting with requiring all the Node Profiles to be equal. Once that's working fine, we can look into the harder case of having multiple Node Profiles within a Deployment Role. Is everyone comfortable with that? Tomas [1]: http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-27_tripleo-ui-icehouse.pdf On 03/02/14 00:21, Robert Collins wrote: On 3 February 2014 08:45, Jaromir Coufal jcou...@redhat.com wrote: However, taking a step back, maybe the real answer is: a) homogeneous nodes b) document. . . - **unsupported** means of demoing Tuskar (set node attributes to match flavors, hack the scheduler, etc) Why are people calling it 'hack'? It's an additional filter to nova-scheduler...? It doesn't properly support the use case; its extra code to write and test and configure that is precisely identical to mis-registering nodes. - our goals of supporting heterogeneous nodes for the J-release. I wouldn't talk about J-release. I would talk about next iteration or next step. Nobody said that we are not able to make it in I-release. +1 Does this seem reasonable to everyone? Mainn Well +1 for a) and it's documentation. However me and Robert, we look to have different opinions on what 'homogeneous' means in our context. I think we should clarify that. So I think my point is more this: - either this iteration is entirely limited to homogeneous hardware, in which case, document it, not workarounds or custom schedulers etc. - or it isn't limited, in which case we should consider the options: - flavor per service definition - custom scheduler - register nodes wrongly -Rob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 2014/30/01 12:59, Ladislav Smola wrote: On 01/30/2014 12:39 PM, Jiří Stránský wrote: On 01/30/2014 11:26 AM, Tomas Sedovic wrote: [snip] I am for implementing support for Heterogeneous hardware properly, lifeless should post what he recommends soon, so I would rather discuss that. We should be able to do simple version in I. Nobody ever said that any implementation of heterogeneous should be wrong or poor. This is misinterpretation. Lowest common denominator doesn't solve storage vs. compute node. If we really have similar hardware, we don't care about, we can just fill the nova-baremetal/ironic specs the same as the flavor. I disagree with this point. This approach of yours will bring super huge confusion for the end user. Asking user to enter same values for different hardware specs will be huge mistake. User is required to enter the reality, it's up to us, how we will help him to make his life easier. Why would we want to see in UI that the hardware is different, when we can't really determine what goes where. Because it is reality. And as you say assume homogenous hardware and treat it as such. So showing in UI that the hardware is different doesn't make any sense then. This might be just wrong wording, but 'assume homogenous hardware and treat it as such' is meant in a way - we deploy roles on nodes randomly, because we assume similar HW - as a *first* step. Right after that, we add functionality for user to define flavors. So the solution for similar hardware is already there. I don't see this as an incremental step, but as ugly hack that is not placed anywhere on the roadmap. Regards, Ladislav -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 2014/30/01 19:29, Tzu-Mainn Chen wrote: Wouldn't lying about the hardware specs when registering nodes be problematic for upgrades? Users would have to re-register their nodes. +1 for problematic area here One reason why a custom filter feels attractive is that it provides us with a clear upgrade path: Icehouse * nodes are registered with correct attributes * create a custom scheduler filter that allows any node to match * users are informed that for this release, Tuskar will not differentiate between heterogeneous hardware J-Release * implement the proper use of flavors within Tuskar, allowing Tuskar to work with heterogeneous hardware I don't think that this is J-release issue. We are very likely to handle this in I-release. * work with nova regarding scheduler filters (if needed) * remove the custom scheduler filter Mainn -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 2014/30/01 23:33, Devananda van der Veen wrote: I was responding based on Treat similar hardware configuration as equal. When there is a very minor difference in hardware (eg, 1TB vs 1.1TB disks), enrolling them with the same spec (1TB disk) is sufficient to solve all these issues and mask the need for multiple flavors, and the hardware wouldn't need to be re-enrolled. I disagree here, of course user can register HW as they wish, it's their responsibility. But asking them to register nodes as equal (even if they are close) is going to be mess and huge confusion for users. You would actually ask user to enter non-real data - so that he can use our deployment tool somehow. From my point of view, this is not right approach and I would better see him entering correct information and us working with it. My suggestion does not address the desire to support significant variation in hardware specs, such as 8GB RAM vs 64GB RAM, in which case, there is no situation in which I think those differences should be glossed over, even as a short-term hack in Icehouse. if our baremetal flavour said 16GB ram and 1TB disk, it would also match a node with 24GB ram or 1.5TB disk. I think this will lead to a lot of confusion, and difficulty with inventory / resource management. I don't think it's suitable even as a first-approximation. Put another way, I dislike the prospect of removing currently-available functionality (an exact-match scheduler and support for multiple flavors) to enable ease-of-use in a UI. I would say this is not for ease-of-use in the UI. It's for bringing user functionality to deploy in the UI. Then, in next iteration, to support them by picking HW they care about. Not that I dislike UIs or anything... it just feels like two steps backwards. If the UI is limited to homogeneous hardware, accept that; don't take away heterogeneous hardware support from the rest of the stack. It's not about taking away support for heterogeneous HW from the whole stack. I see the proposal more like adding another filter (possibility) for nova-scheduler. Anyway, it sounds like Robert has a solution in mind, so this is all moot :) Cheers, Devananda Cheers -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 1 February 2014 10:03, Tzu-Mainn Chen tzuma...@redhat.com wrote: So after reading the replies on this thread, it seems like I (and others advocating a custom scheduler) may have overthought things a bit. The reason this route was suggested was because of conflicting goals for Icehouse: a) homogeneous nodes (to simplify requirements) b) support diverse hardware sets (to allow as many users as possible to try Tuskar) Option b) requires either a custom scheduler or forcing nodes to have the same attributes, and the answer to that question is where much of the debate lies. Not really. It all depends on how you define 'support diverse hardware sets'. The point I've consistently made is that by working within the current scheduler we can easily deliver homogeneous support *within* a given 'service role'. So that is (a), not 'every single node is identical. A (b) of supporting arbitrary hardware within a single service role is significantly more complex, and while I think its entirely doable, it would be a mistake to tackle this within I (and possibly J). I don't think users will be impaired by us delaying however. However, taking a step back, maybe the real answer is: a) homogeneous nodes b) document. . . - **unsupported** means of demoing Tuskar (set node attributes to match flavors, hack the scheduler, etc) - our goals of supporting heterogeneous nodes for the J-release. Does this seem reasonable to everyone? No, because a) is overly scoped. I think we should have a flavor attribute in the definition of a service role, and no unsupported hacks needed; and J goals should be given a chunk of time to refine in Atlanta. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 2014/30/01 21:28, Robert Collins wrote: On 30 January 2014 23:26, Tomas Sedovic tsedo...@redhat.com wrote: Hi all, I've seen some confusion regarding the homogenous hardware support as the first step for the tripleo UI. I think it's time to make sure we're all on the same page. Here's what I think is not controversial: 1. Build the UI and everything underneath to work with homogenous hardware in the Icehouse timeframe 2. Figure out how to support heterogenous hardware and do that (may or may not happen within Icehouse) The first option implies having a single nova flavour that will match all the boxes we want to work with. It may or may not be surfaced in the UI (I think that depends on our undercloud installation story). I don't agree that (1) implies a single nova flavour. In the context of the discussion it implied avoiding doing our own scheduling, and due to the many moving parts we never got beyond that. I think that homogeneous hardware implies single flavor. That's from the definition 'homogeneous'. Question is, how we treat it then. My expectation is that (argh naming of things) a service definition[1] will specify a nova flavour, right from the get go. That gives you homogeneous hardware for any service [control/network/block-storage/object-storage]. If a service definition specifies a nova flavor, then (based on the fact that we have 4 hard-coded roles) we are supporting heterogeneous HW (because we would allow user to specify 4 flavors). What we agreed on in the beginning is homogeneous HW - which links to the fact that we have only one flavor. We should really start with something *simple* and increment on that: 1) one flavor, no association to any role. This is what I see under homogeneous HW - MVP0. (As an addition for the sake of usability we wanted to add 'no care' filter - so that it picks node without need for specifying requirements). 2) association with role - one flavor per role - homogeneous hardware. 3) support multiple node profiles per role. Why to complicate things from the very beginning (1)? Jaromir's wireframes include the ability to define multiple such definitions, so two definitions for compute, for instance (e.g. one might be KVM, one Xen, or one w/GPUs and the other without, with a different host aggregate configured). As long as each definition has a nova flavour, users with multiple hardware configurations can just create multiple definitions, done. That is not entirely policy driven, so for longer term you want to be able to say 'flavour X *or* Y can be used for this', but as a early iteration it seems very straight forward to me. Now, someone (I don't honestly know who or when) proposed a slight step up from point #1 that would allow people to try the UI even if their hardware varies slightly: 1.1 Treat similar hardware configuration as equal I think this is a problematic idea, because of the points raised elsewhere in the thread. But more importantly, it's totally unnecessary. If one wants to handle minor variations in hardware (e.g. 1TB vs 1.1TB disks) just register them as being identical, with the lowest common denominator - Nova will then treat them as equal. -Rob -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 2014/31/01 22:03, Tzu-Mainn Chen wrote: So after reading the replies on this thread, it seems like I (and others advocating a custom scheduler) may have overthought things a bit. The reason this route was suggested was because of conflicting goals for Icehouse: a) homogeneous nodes (to simplify requirements) b) support diverse hardware sets (to allow as many users as possible to try Tuskar) Option b) requires either a custom scheduler or forcing nodes to have the same attributes, and the answer to that question is where much of the debate lies. I think these two goals are pretty accurate. However, taking a step back, maybe the real answer is: a) homogeneous nodes b) document. . . - **unsupported** means of demoing Tuskar (set node attributes to match flavors, hack the scheduler, etc) Why are people calling it 'hack'? It's an additional filter to nova-scheduler...? - our goals of supporting heterogeneous nodes for the J-release. I wouldn't talk about J-release. I would talk about next iteration or next step. Nobody said that we are not able to make it in I-release. Does this seem reasonable to everyone? Mainn Well +1 for a) and it's documentation. However me and Robert, we look to have different opinions on what 'homogeneous' means in our context. I think we should clarify that. -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
Excerpts from Jaromir Coufal's message of 2014-02-02 11:19:25 -0800: On 2014/30/01 23:33, Devananda van der Veen wrote: I was responding based on Treat similar hardware configuration as equal. When there is a very minor difference in hardware (eg, 1TB vs 1.1TB disks), enrolling them with the same spec (1TB disk) is sufficient to solve all these issues and mask the need for multiple flavors, and the hardware wouldn't need to be re-enrolled. I disagree here, of course user can register HW as they wish, it's their responsibility. But asking them to register nodes as equal (even if they are close) is going to be mess and huge confusion for users. You would actually ask user to enter non-real data - so that he can use our deployment tool somehow. From my point of view, this is not right approach and I would better see him entering correct information and us working with it. I totally understand the desire to have it all make sense to users. I wonder if the desire to have something working well in the next 30 days should override the desire. My thought is that early adopters are used to this sort of work-around. Accept this bit of weirdness, and you get all this awesomeness. In this case Register hardware with similar specs as identical specs, and you will get automatic deployment over heterogeneous hardware. If we keep the scope narrow enough, those users only have to wait a few more months to be able to make their hardware registrations more accurate. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 1 February 2014 10:03, Tzu-Mainn Chen tzuma...@redhat.com wrote: So after reading the replies on this thread, it seems like I (and others advocating a custom scheduler) may have overthought things a bit. The reason this route was suggested was because of conflicting goals for Icehouse: a) homogeneous nodes (to simplify requirements) b) support diverse hardware sets (to allow as many users as possible to try Tuskar) Option b) requires either a custom scheduler or forcing nodes to have the same attributes, and the answer to that question is where much of the debate lies. Not really. It all depends on how you define 'support diverse hardware sets'. The point I've consistently made is that by working within the current scheduler we can easily deliver homogeneous support *within* a given 'service role'. So that is (a), not 'every single node is identical. A (b) of supporting arbitrary hardware within a single service role is significantly more complex, and while I think its entirely doable, it would be a mistake to tackle this within I (and possibly J). I don't think users will be impaired by us delaying however. However, taking a step back, maybe the real answer is: a) homogeneous nodes b) document. . . - **unsupported** means of demoing Tuskar (set node attributes to match flavors, hack the scheduler, etc) - our goals of supporting heterogeneous nodes for the J-release. Does this seem reasonable to everyone? No, because a) is overly scoped. I think we should have a flavor attribute in the definition of a service role, and no unsupported hacks needed; and J goals should be given a chunk of time to refine in Atlanta. Fair enough. It's my fault for being imprecise, but in my email I meant homogeneous as homogeneous per service role. That being said, are people on board with: a) a single flavor per service role for Icehouse? b) documentation as suggested above? A single flavor per service role shouldn't be significantly harder than a single flavor for all service roles (multiple flavors per service role is where tricky issues start to creep in). Mainn -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
So after reading the replies on this thread, it seems like I (and others advocating a custom scheduler) may have overthought things a bit. The reason this route was suggested was because of conflicting goals for Icehouse: a) homogeneous nodes (to simplify requirements) b) support diverse hardware sets (to allow as many users as possible to try Tuskar) Option b) requires either a custom scheduler or forcing nodes to have the same attributes, and the answer to that question is where much of the debate lies. However, taking a step back, maybe the real answer is: a) homogeneous nodes b) document. . . - **unsupported** means of demoing Tuskar (set node attributes to match flavors, hack the scheduler, etc) - our goals of supporting heterogeneous nodes for the J-release. Does this seem reasonable to everyone? Mainn - Original Message - On 30 January 2014 23:26, Tomas Sedovic tsedo...@redhat.com wrote: Hi all, I've seen some confusion regarding the homogenous hardware support as the first step for the tripleo UI. I think it's time to make sure we're all on the same page. Here's what I think is not controversial: 1. Build the UI and everything underneath to work with homogenous hardware in the Icehouse timeframe 2. Figure out how to support heterogenous hardware and do that (may or may not happen within Icehouse) The first option implies having a single nova flavour that will match all the boxes we want to work with. It may or may not be surfaced in the UI (I think that depends on our undercloud installation story). I don't agree that (1) implies a single nova flavour. In the context of the discussion it implied avoiding doing our own scheduling, and due to the many moving parts we never got beyond that. My expectation is that (argh naming of things) a service definition[1] will specify a nova flavour, right from the get go. That gives you homogeneous hardware for any service [control/network/block-storage/object-storage]. Jaromir's wireframes include the ability to define multiple such definitions, so two definitions for compute, for instance (e.g. one might be KVM, one Xen, or one w/GPUs and the other without, with a different host aggregate configured). As long as each definition has a nova flavour, users with multiple hardware configurations can just create multiple definitions, done. That is not entirely policy driven, so for longer term you want to be able to say 'flavour X *or* Y can be used for this', but as a early iteration it seems very straight forward to me. Now, someone (I don't honestly know who or when) proposed a slight step up from point #1 that would allow people to try the UI even if their hardware varies slightly: 1.1 Treat similar hardware configuration as equal I think this is a problematic idea, because of the points raised elsewhere in the thread. But more importantly, it's totally unnecessary. If one wants to handle minor variations in hardware (e.g. 1TB vs 1.1TB disks) just register them as being identical, with the lowest common denominator - Nova will then treat them as equal. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On Fri, Jan 31, 2014 at 1:03 PM, Tzu-Mainn Chen tzuma...@redhat.com wrote: So after reading the replies on this thread, it seems like I (and others advocating a custom scheduler) may have overthought things a bit. The reason this route was suggested was because of conflicting goals for Icehouse: a) homogeneous nodes (to simplify requirements) b) support diverse hardware sets (to allow as many users as possible to try Tuskar) Option b) requires either a custom scheduler or forcing nodes to have the same attributes, and the answer to that question is where much of the debate lies. However, taking a step back, maybe the real answer is: a) homogeneous nodes b) document. . . - **unsupported** means of demoing Tuskar (set node attributes to match flavors, hack the scheduler, etc) - our goals of supporting heterogeneous nodes for the J-release. Does this seem reasonable to everyone? +1 -Deva ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
Hi all, I've seen some confusion regarding the homogenous hardware support as the first step for the tripleo UI. I think it's time to make sure we're all on the same page. Here's what I think is not controversial: 1. Build the UI and everything underneath to work with homogenous hardware in the Icehouse timeframe 2. Figure out how to support heterogenous hardware and do that (may or may not happen within Icehouse) The first option implies having a single nova flavour that will match all the boxes we want to work with. It may or may not be surfaced in the UI (I think that depends on our undercloud installation story). Now, someone (I don't honestly know who or when) proposed a slight step up from point #1 that would allow people to try the UI even if their hardware varies slightly: 1.1 Treat similar hardware configuration as equal The way I understand it is this: we use a scheduler filter that wouldn't do a strict match on the hardware in Ironic. E.g. if our baremetal flavour said 16GB ram and 1TB disk, it would also match a node with 24GB ram or 1.5TB disk. The UI would still assume homogenous hardware and treat it as such. It's just that we would allow for small differences. This *isn't* proposing we match ARM to x64 or offer a box with 24GB RAM when the flavour says 32. We would treat the flavour as a lowest common denominator. Nor is this an alternative to a full heterogenous hardware support. We need to do that eventually anyway. This is just to make the first MVP useful to more people. It's an incremental step that would affect neither point 1. (strict homogenous hardware) nor point 2. (full heterogenous hardware support). If some of these assumptions are incorrect, please let me know. I don't think this is an insane U-turn from anything we've already agreed to do, but it seems to confuse people. At any rate, this is not a huge deal and if it's not a good idea, let's just drop it. Tomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 01/30/2014 11:26 AM, Tomas Sedovic wrote: 1.1 Treat similar hardware configuration as equal The way I understand it is this: we use a scheduler filter that wouldn't do a strict match on the hardware in Ironic. E.g. if our baremetal flavour said 16GB ram and 1TB disk, it would also match a node with 24GB ram or 1.5TB disk. The UI would still assume homogenous hardware and treat it as such. It's just that we would allow for small differences. This *isn't* proposing we match ARM to x64 or offer a box with 24GB RAM when the flavour says 32. We would treat the flavour as a lowest common denominator. Nor is this an alternative to a full heterogenous hardware support. We need to do that eventually anyway. This is just to make the first MVP useful to more people. It's an incremental step that would affect neither point 1. (strict homogenous hardware) nor point 2. (full heterogenous hardware support). If some of these assumptions are incorrect, please let me know. I don't think this is an insane U-turn from anything we've already agreed to do, but it seems to confuse people. I think having this would allow users with almost-homogeous hardware use TripleO. If someone already has precisely homogenous hardware, they won't notice a difference. So i'm +1 for this idea. The condition should be that it's easy to implement, because imho it's something that will get dropped when support for fully heterogenous hardware is added. Jirka ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 01/30/2014 12:39 PM, Jiří Stránský wrote: On 01/30/2014 11:26 AM, Tomas Sedovic wrote: 1.1 Treat similar hardware configuration as equal The way I understand it is this: we use a scheduler filter that wouldn't do a strict match on the hardware in Ironic. E.g. if our baremetal flavour said 16GB ram and 1TB disk, it would also match a node with 24GB ram or 1.5TB disk. The UI would still assume homogenous hardware and treat it as such. It's just that we would allow for small differences. This *isn't* proposing we match ARM to x64 or offer a box with 24GB RAM when the flavour says 32. We would treat the flavour as a lowest common denominator. Nor is this an alternative to a full heterogenous hardware support. We need to do that eventually anyway. This is just to make the first MVP useful to more people. It's an incremental step that would affect neither point 1. (strict homogenous hardware) nor point 2. (full heterogenous hardware support). If some of these assumptions are incorrect, please let me know. I don't think this is an insane U-turn from anything we've already agreed to do, but it seems to confuse people. I think having this would allow users with almost-homogeous hardware use TripleO. If someone already has precisely homogenous hardware, they won't notice a difference. So i'm +1 for this idea. The condition should be that it's easy to implement, because imho it's something that will get dropped when support for fully heterogenous hardware is added. Jirka Hello, I am for implementing support for Heterogeneous hardware properly, lifeless should post what he recommends soon, so I would rather discuss that. We should be able to do simple version in I. Lowest common denominator doesn't solve storage vs. compute node. If we really have similar hardware, we don't care about, we can just fill the nova-baremetal/ironic specs the same as the flavor. Why would we want to see in UI that the hardware is different, when we can't really determine what goes where. And as you say assume homogenous hardware and treat it as such. So showing in UI that the hardware is different doesn't make any sense then. So the solution for similar hardware is already there. I don't see this as an incremental step, but as ugly hack that is not placed anywhere on the roadmap. Regards, Ladislav ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 1/30/14, 5:26 AM, Tomas Sedovic wrote: Hi all, I've seen some confusion regarding the homogenous hardware support as the first step for the tripleo UI. I think it's time to make sure we're all on the same page. Here's what I think is not controversial: 1. Build the UI and everything underneath to work with homogenous hardware in the Icehouse timeframe 2. Figure out how to support heterogenous hardware and do that (may or may not happen within Icehouse) The first option implies having a single nova flavour that will match all the boxes we want to work with. It may or may not be surfaced in the UI (I think that depends on our undercloud installation story). Now, someone (I don't honestly know who or when) proposed a slight step up from point #1 that would allow people to try the UI even if their hardware varies slightly: 1.1 Treat similar hardware configuration as equal The way I understand it is this: we use a scheduler filter that wouldn't do a strict match on the hardware in Ironic. E.g. if our baremetal flavour said 16GB ram and 1TB disk, it would also match a node with 24GB ram or 1.5TB disk. The UI would still assume homogenous hardware and treat it as such. It's just that we would allow for small differences. This *isn't* proposing we match ARM to x64 or offer a box with 24GB RAM when the flavour says 32. We would treat the flavour as a lowest common denominator. Does Nova already handle this? Or is it built on exact matches? I guess my question is -- what is the benefit of doing this? Is it just so people can play around with it? Or is there a lasting benefit long-term? I can see one -- match to the closest, but be willing to give me more than I asked for if that's all that's available. Is there any downside to this being permanent behavior? I think the lowest-common-denominator match will be familiar to sysadmins, too. Want to do RAID striping across a 500GB and a 750GB disk? You'll get a striped 500GB volume. -- Matt Wagner Software Engineer, Red Hat signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 30/01/14 15:53, Matt Wagner wrote: On 1/30/14, 5:26 AM, Tomas Sedovic wrote: Hi all, I've seen some confusion regarding the homogenous hardware support as the first step for the tripleo UI. I think it's time to make sure we're all on the same page. Here's what I think is not controversial: 1. Build the UI and everything underneath to work with homogenous hardware in the Icehouse timeframe 2. Figure out how to support heterogenous hardware and do that (may or may not happen within Icehouse) The first option implies having a single nova flavour that will match all the boxes we want to work with. It may or may not be surfaced in the UI (I think that depends on our undercloud installation story). Now, someone (I don't honestly know who or when) proposed a slight step up from point #1 that would allow people to try the UI even if their hardware varies slightly: 1.1 Treat similar hardware configuration as equal The way I understand it is this: we use a scheduler filter that wouldn't do a strict match on the hardware in Ironic. E.g. if our baremetal flavour said 16GB ram and 1TB disk, it would also match a node with 24GB ram or 1.5TB disk. The UI would still assume homogenous hardware and treat it as such. It's just that we would allow for small differences. This *isn't* proposing we match ARM to x64 or offer a box with 24GB RAM when the flavour says 32. We would treat the flavour as a lowest common denominator. Does Nova already handle this? Or is it built on exact matches? It's doing an exact match as far as I know. This would likely involve writing a custom filter for nova scheduler and updating nova.conf accordingly. I guess my question is -- what is the benefit of doing this? Is it just so people can play around with it? Or is there a lasting benefit long-term? I can see one -- match to the closest, but be willing to give me more than I asked for if that's all that's available. Is there any downside to this being permanent behavior? Absolutely not a long term thing. This is just to let people play around with the MVP until we have the proper support for heterogenous hardware in. It's just an idea that would increase the usefulness of the first version and should be trivial to implement and take out. If neither is the case or if we will in fact manage to have a proper heterogenous hardware support early (in Icehouse), it doesn't make any sense to do this. I think the lowest-common-denominator match will be familiar to sysadmins, too. Want to do RAID striping across a 500GB and a 750GB disk? You'll get a striped 500GB volume. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
As far as nova-scheduler and Ironic go, I believe this is a solved problem. Steps are: - enroll hardware with proper specs (CPU, RAM, disk, etc) - create flavors based on hardware specs - scheduler filter matches requests exactly There are, I suspect, three areas where this would fall short today: - exposing to the user when certain flavors shouldn't be picked, because there is no more hardware available which could match it - ensuring that hardware is enrolled with the proper specs // trouble-shooting when it is not - a UI that does these well If I understand your proposal correctly, you're suggesting that we introduce non-deterministic behavior. If the scheduler filter falls back to $flavor when $flavor is not available, even if the search is in ascending order and upper-bounded by some percentage, the user is still likely to get something other than what they requested. From a utilization and inventory-management standpoint, this would be a headache, and from a user standpoint, it would be awkward. Also, your proposal is only addressing the case where hardware variance is small; it doesn't include a solution for deployments with substantially different hardware. I don't think introducing a non-deterministic hack when the underlying services already work, just to provide a temporary UI solution, is appropriate. But that's just my opinion. Here's an alternate proposal to support same-arch but different cpu/ram/disk hardware environments: - keep the scheduler filter doing an exact match - have the UI only allow the user to define one flavor, and have that be the lowest common denominator of available hardware - assign that flavor's properties to all nodes -- basically lie about the hardware specs when enrolling them - inform the user that, if they have heterogeneous hardware, they will get randomly chosen nodes from their pool, and that scheduling on heterogeneous hardware will be added in a future UI release This will allow folks who are using TripleO at the commandline to take advantage of their heterogeneous hardware, instead of crippling already-existing functionality, while also allowing users who have slightly (or wildly) different hardware specs to still use the UI. Regards, Devananda On Thu, Jan 30, 2014 at 7:14 AM, Tomas Sedovic tsedo...@redhat.com wrote: On 30/01/14 15:53, Matt Wagner wrote: On 1/30/14, 5:26 AM, Tomas Sedovic wrote: Hi all, I've seen some confusion regarding the homogenous hardware support as the first step for the tripleo UI. I think it's time to make sure we're all on the same page. Here's what I think is not controversial: 1. Build the UI and everything underneath to work with homogenous hardware in the Icehouse timeframe 2. Figure out how to support heterogenous hardware and do that (may or may not happen within Icehouse) The first option implies having a single nova flavour that will match all the boxes we want to work with. It may or may not be surfaced in the UI (I think that depends on our undercloud installation story). Now, someone (I don't honestly know who or when) proposed a slight step up from point #1 that would allow people to try the UI even if their hardware varies slightly: 1.1 Treat similar hardware configuration as equal The way I understand it is this: we use a scheduler filter that wouldn't do a strict match on the hardware in Ironic. E.g. if our baremetal flavour said 16GB ram and 1TB disk, it would also match a node with 24GB ram or 1.5TB disk. The UI would still assume homogenous hardware and treat it as such. It's just that we would allow for small differences. This *isn't* proposing we match ARM to x64 or offer a box with 24GB RAM when the flavour says 32. We would treat the flavour as a lowest common denominator. Does Nova already handle this? Or is it built on exact matches? It's doing an exact match as far as I know. This would likely involve writing a custom filter for nova scheduler and updating nova.conf accordingly. I guess my question is -- what is the benefit of doing this? Is it just so people can play around with it? Or is there a lasting benefit long-term? I can see one -- match to the closest, but be willing to give me more than I asked for if that's all that's available. Is there any downside to this being permanent behavior? Absolutely not a long term thing. This is just to let people play around with the MVP until we have the proper support for heterogenous hardware in. It's just an idea that would increase the usefulness of the first version and should be trivial to implement and take out. If neither is the case or if we will in fact manage to have a proper heterogenous hardware support early (in Icehouse), it doesn't make any sense to do this. I think the lowest-common-denominator match will be familiar to sysadmins, too. Want to do RAID striping across a 500GB and a 750GB disk? You'll get a striped 500GB volume.
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
Wouldn't lying about the hardware specs when registering nodes be problematic for upgrades? Users would have to re-register their nodes. One reason why a custom filter feels attractive is that it provides us with a clear upgrade path: Icehouse * nodes are registered with correct attributes * create a custom scheduler filter that allows any node to match * users are informed that for this release, Tuskar will not differentiate between heterogeneous hardware J-Release * implement the proper use of flavors within Tuskar, allowing Tuskar to work with heterogeneous hardware * work with nova regarding scheduler filters (if needed) * remove the custom scheduler filter Mainn - Original Message - As far as nova-scheduler and Ironic go, I believe this is a solved problem. Steps are: - enroll hardware with proper specs (CPU, RAM, disk, etc) - create flavors based on hardware specs - scheduler filter matches requests exactly There are, I suspect, three areas where this would fall short today: - exposing to the user when certain flavors shouldn't be picked, because there is no more hardware available which could match it - ensuring that hardware is enrolled with the proper specs // trouble-shooting when it is not - a UI that does these well If I understand your proposal correctly, you're suggesting that we introduce non-deterministic behavior. If the scheduler filter falls back to $flavor when $flavor is not available, even if the search is in ascending order and upper-bounded by some percentage, the user is still likely to get something other than what they requested. From a utilization and inventory-management standpoint, this would be a headache, and from a user standpoint, it would be awkward. Also, your proposal is only addressing the case where hardware variance is small; it doesn't include a solution for deployments with substantially different hardware. I don't think introducing a non-deterministic hack when the underlying services already work, just to provide a temporary UI solution, is appropriate. But that's just my opinion. Here's an alternate proposal to support same-arch but different cpu/ram/disk hardware environments: - keep the scheduler filter doing an exact match - have the UI only allow the user to define one flavor, and have that be the lowest common denominator of available hardware - assign that flavor's properties to all nodes -- basically lie about the hardware specs when enrolling them - inform the user that, if they have heterogeneous hardware, they will get randomly chosen nodes from their pool, and that scheduling on heterogeneous hardware will be added in a future UI release This will allow folks who are using TripleO at the commandline to take advantage of their heterogeneous hardware, instead of crippling already-existing functionality, while also allowing users who have slightly (or wildly) different hardware specs to still use the UI. Regards, Devananda On Thu, Jan 30, 2014 at 7:14 AM, Tomas Sedovic tsedo...@redhat.com wrote: On 30/01/14 15:53, Matt Wagner wrote: On 1/30/14, 5:26 AM, Tomas Sedovic wrote: Hi all, I've seen some confusion regarding the homogenous hardware support as the first step for the tripleo UI. I think it's time to make sure we're all on the same page. Here's what I think is not controversial: 1. Build the UI and everything underneath to work with homogenous hardware in the Icehouse timeframe 2. Figure out how to support heterogenous hardware and do that (may or may not happen within Icehouse) The first option implies having a single nova flavour that will match all the boxes we want to work with. It may or may not be surfaced in the UI (I think that depends on our undercloud installation story). Now, someone (I don't honestly know who or when) proposed a slight step up from point #1 that would allow people to try the UI even if their hardware varies slightly: 1.1 Treat similar hardware configuration as equal The way I understand it is this: we use a scheduler filter that wouldn't do a strict match on the hardware in Ironic. E.g. if our baremetal flavour said 16GB ram and 1TB disk, it would also match a node with 24GB ram or 1.5TB disk. The UI would still assume homogenous hardware and treat it as such. It's just that we would allow for small differences. This *isn't* proposing we match ARM to x64 or offer a box with 24GB RAM when the flavour says 32. We would treat the flavour as a lowest common denominator. Does Nova already handle this? Or is it built on exact matches? It's doing an exact match as far as I know.
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 30 January 2014 23:26, Tomas Sedovic tsedo...@redhat.com wrote: Hi all, I've seen some confusion regarding the homogenous hardware support as the first step for the tripleo UI. I think it's time to make sure we're all on the same page. Here's what I think is not controversial: 1. Build the UI and everything underneath to work with homogenous hardware in the Icehouse timeframe 2. Figure out how to support heterogenous hardware and do that (may or may not happen within Icehouse) The first option implies having a single nova flavour that will match all the boxes we want to work with. It may or may not be surfaced in the UI (I think that depends on our undercloud installation story). I don't agree that (1) implies a single nova flavour. In the context of the discussion it implied avoiding doing our own scheduling, and due to the many moving parts we never got beyond that. My expectation is that (argh naming of things) a service definition[1] will specify a nova flavour, right from the get go. That gives you homogeneous hardware for any service [control/network/block-storage/object-storage]. Jaromir's wireframes include the ability to define multiple such definitions, so two definitions for compute, for instance (e.g. one might be KVM, one Xen, or one w/GPUs and the other without, with a different host aggregate configured). As long as each definition has a nova flavour, users with multiple hardware configurations can just create multiple definitions, done. That is not entirely policy driven, so for longer term you want to be able to say 'flavour X *or* Y can be used for this', but as a early iteration it seems very straight forward to me. Now, someone (I don't honestly know who or when) proposed a slight step up from point #1 that would allow people to try the UI even if their hardware varies slightly: 1.1 Treat similar hardware configuration as equal I think this is a problematic idea, because of the points raised elsewhere in the thread. But more importantly, it's totally unnecessary. If one wants to handle minor variations in hardware (e.g. 1TB vs 1.1TB disks) just register them as being identical, with the lowest common denominator - Nova will then treat them as equal. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
- Original Message - On 30 January 2014 23:26, Tomas Sedovic tsedo...@redhat.com wrote: Hi all, I've seen some confusion regarding the homogenous hardware support as the first step for the tripleo UI. I think it's time to make sure we're all on the same page. Here's what I think is not controversial: 1. Build the UI and everything underneath to work with homogenous hardware in the Icehouse timeframe 2. Figure out how to support heterogenous hardware and do that (may or may not happen within Icehouse) The first option implies having a single nova flavour that will match all the boxes we want to work with. It may or may not be surfaced in the UI (I think that depends on our undercloud installation story). I don't agree that (1) implies a single nova flavour. In the context of the discussion it implied avoiding doing our own scheduling, and due to the many moving parts we never got beyond that. My expectation is that (argh naming of things) a service definition[1] will specify a nova flavour, right from the get go. That gives you homogeneous hardware for any service [control/network/block-storage/object-storage]. Jaromir's wireframes include the ability to define multiple such definitions, so two definitions for compute, for instance (e.g. one might be KVM, one Xen, or one w/GPUs and the other without, with a different host aggregate configured). As long as each definition has a nova flavour, users with multiple hardware configurations can just create multiple definitions, done. That is not entirely policy driven, so for longer term you want to be able to say 'flavour X *or* Y can be used for this', but as a early iteration it seems very straight forward to me. Now, someone (I don't honestly know who or when) proposed a slight step up from point #1 that would allow people to try the UI even if their hardware varies slightly: 1.1 Treat similar hardware configuration as equal I think this is a problematic idea, because of the points raised elsewhere in the thread. But more importantly, it's totally unnecessary. If one wants to handle minor variations in hardware (e.g. 1TB vs 1.1TB disks) just register them as being identical, with the lowest common denominator - Nova will then treat them as equal. Thanks for the reply! So if I understand correctly, the proposal is for: Icehouse: one flavor per service role, so nodes are homogeneous per role J: multiple flavors per service role That sounds reasonable; the part that gives me pause is when you talk about handling variations in hardware by registering the nodes as equal. If those differences vanish, then won't there be problems in the future when we might be able to properly handle those variations? Or do you propose that we only allow minor variations to be registered as equal, so that the UI has to understand the concept of minor variances? Mainn ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
Wouldn't lying about the hardware specs when registering nodes be problematic for upgrades? Users would have to re-register their nodes. This was my first impression too, the line basically lie about the hardware specs when enrolling them. It feels more wrong to have the user provide false data than it does to ignore that data for Icehouse. I'd rather have the data correct now and ignore it than tell users when they upgrade to Juno they have to re-enter all of their node data. It's not heterogenous v. homogeneous support. It's whether or not we use the data. We can capture it now and not provide the user the ability to differentiate what something is deployed on. That's a heterogeneous enrivonment, but just a lack of fine-grained control over where the instances fall. And all of this is simply for the time constraints of Icehouse's first pass. A known, temporary limitation. One reason why a custom filter feels attractive is that it provides us with a clear upgrade path: Icehouse * nodes are registered with correct attributes * create a custom scheduler filter that allows any node to match * users are informed that for this release, Tuskar will not differentiate between heterogeneous hardware J-Release * implement the proper use of flavors within Tuskar, allowing Tuskar to work with heterogeneous hardware * work with nova regarding scheduler filters (if needed) * remove the custom scheduler filter Mainn As far as nova-scheduler and Ironic go, I believe this is a solved problem. Steps are: - enroll hardware with proper specs (CPU, RAM, disk, etc) - create flavors based on hardware specs - scheduler filter matches requests exactly There are, I suspect, three areas where this would fall short today: - exposing to the user when certain flavors shouldn't be picked, because there is no more hardware available which could match it - ensuring that hardware is enrolled with the proper specs // trouble-shooting when it is not - a UI that does these well If I understand your proposal correctly, you're suggesting that we introduce non-deterministic behavior. If the scheduler filter falls back to $flavor when $flavor is not available, even if the search is in ascending order and upper-bounded by some percentage, the user is still likely to get something other than what they requested. From a utilization and inventory-management standpoint, this would be a headache, and from a user standpoint, it would be awkward. Also, your proposal is only addressing the case where hardware variance is small; it doesn't include a solution for deployments with substantially different hardware. I don't think introducing a non-deterministic hack when the underlying services already work, just to provide a temporary UI solution, is appropriate. But that's just my opinion. Here's an alternate proposal to support same-arch but different cpu/ram/disk hardware environments: - keep the scheduler filter doing an exact match - have the UI only allow the user to define one flavor, and have that be the lowest common denominator of available hardware - assign that flavor's properties to all nodes -- basically lie about the hardware specs when enrolling them - inform the user that, if they have heterogeneous hardware, they will get randomly chosen nodes from their pool, and that scheduling on heterogeneous hardware will be added in a future UI release This will allow folks who are using TripleO at the commandline to take advantage of their heterogeneous hardware, instead of crippling already-existing functionality, while also allowing users who have slightly (or wildly) different hardware specs to still use the UI. Regards, Devananda On Thu, Jan 30, 2014 at 7:14 AM, Tomas Sedovic tsedo...@redhat.com mailto:tsedo...@redhat.com wrote: On 30/01/14 15:53, Matt Wagner wrote: On 1/30/14, 5:26 AM, Tomas Sedovic wrote: Hi all, I've seen some confusion regarding the homogenous hardware support as the first step for the tripleo UI. I think it's time to make sure we're all on the same page. Here's what I think is not controversial: 1. Build the UI and everything underneath to work with homogenous hardware in the Icehouse timeframe 2. Figure out how to support heterogenous hardware and do that (may or may not happen within Icehouse) The first option implies having a single nova flavour that will match all the boxes we want to work with. It may or may not be surfaced in the
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
I was responding based on Treat similar hardware configuration as equal. When there is a very minor difference in hardware (eg, 1TB vs 1.1TB disks), enrolling them with the same spec (1TB disk) is sufficient to solve all these issues and mask the need for multiple flavors, and the hardware wouldn't need to be re-enrolled. My suggestion does not address the desire to support significant variation in hardware specs, such as 8GB RAM vs 64GB RAM, in which case, there is no situation in which I think those differences should be glossed over, even as a short-term hack in Icehouse. if our baremetal flavour said 16GB ram and 1TB disk, it would also match a node with 24GB ram or 1.5TB disk. I think this will lead to a lot of confusion, and difficulty with inventory / resource management. I don't think it's suitable even as a first-approximation. Put another way, I dislike the prospect of removing currently-available functionality (an exact-match scheduler and support for multiple flavors) to enable ease-of-use in a UI. Not that I dislike UIs or anything... it just feels like two steps backwards. If the UI is limited to homogeneous hardware, accept that; don't take away heterogeneous hardware support from the rest of the stack. Anyway, it sounds like Robert has a solution in mind, so this is all moot :) Cheers, Devananda On Thu, Jan 30, 2014 at 1:30 PM, Jay Dobies jason.dob...@redhat.com wrote: Wouldn't lying about the hardware specs when registering nodes be problematic for upgrades? Users would have to re-register their nodes. This was my first impression too, the line basically lie about the hardware specs when enrolling them. It feels more wrong to have the user provide false data than it does to ignore that data for Icehouse. I'd rather have the data correct now and ignore it than tell users when they upgrade to Juno they have to re-enter all of their node data. It's not heterogenous v. homogeneous support. It's whether or not we use the data. We can capture it now and not provide the user the ability to differentiate what something is deployed on. That's a heterogeneous enrivonment, but just a lack of fine-grained control over where the instances fall. And all of this is simply for the time constraints of Icehouse's first pass. A known, temporary limitation. One reason why a custom filter feels attractive is that it provides us with a clear upgrade path: Icehouse * nodes are registered with correct attributes * create a custom scheduler filter that allows any node to match * users are informed that for this release, Tuskar will not differentiate between heterogeneous hardware J-Release * implement the proper use of flavors within Tuskar, allowing Tuskar to work with heterogeneous hardware * work with nova regarding scheduler filters (if needed) * remove the custom scheduler filter Mainn As far as nova-scheduler and Ironic go, I believe this is a solved problem. Steps are: - enroll hardware with proper specs (CPU, RAM, disk, etc) - create flavors based on hardware specs - scheduler filter matches requests exactly There are, I suspect, three areas where this would fall short today: - exposing to the user when certain flavors shouldn't be picked, because there is no more hardware available which could match it - ensuring that hardware is enrolled with the proper specs // trouble-shooting when it is not - a UI that does these well If I understand your proposal correctly, you're suggesting that we introduce non-deterministic behavior. If the scheduler filter falls back to $flavor when $flavor is not available, even if the search is in ascending order and upper-bounded by some percentage, the user is still likely to get something other than what they requested. From a utilization and inventory-management standpoint, this would be a headache, and from a user standpoint, it would be awkward. Also, your proposal is only addressing the case where hardware variance is small; it doesn't include a solution for deployments with substantially different hardware. I don't think introducing a non-deterministic hack when the underlying services already work, just to provide a temporary UI solution, is appropriate. But that's just my opinion. Here's an alternate proposal to support same-arch but different cpu/ram/disk hardware environments: - keep the scheduler filter doing an exact match - have the UI only allow the user to define one flavor, and have that be the lowest common denominator of available hardware - assign that flavor's properties to all nodes -- basically lie about the hardware specs when enrolling them - inform the user that, if they have heterogeneous hardware, they will get randomly chosen nodes from
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 30/01/14 16:14 -0500, Tzu-Mainn Chen wrote: Thanks for the reply! So if I understand correctly, the proposal is for: Icehouse: one flavor per service role, so nodes are homogeneous per role J: multiple flavors per service role That sounds reasonable; the part that gives me pause is when you talk about handling variations in hardware by registering the nodes as equal. If those differences vanish, then won't there be problems in the future when we might be able to properly handle those variations? Or do you propose that we only allow minor variations to be registered as equal, so that the UI has to understand the concept of minor variances? Back to your original point, the idea of are we going to allow seems fraught with peril. Do we have some kind of tolerance for what hardware the user is allowed to register after they register their first one? This sounds like a recipe for user frustration Mainn ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Jordan O'Mara jomara at redhat.com Red Hat Engineering, Raleigh pgpYmCvfhgVO3.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
