Re: [openstack-dev] [Neutron] Flavor framework proposal
Folks, Initial implementation is here: https://review.openstack.org/#/c/105982/ It's pretty much complete (in terms of code parts) but may require some adjustments and of course fixes. I'm working on the client to test this end-to-end. Thanks, Eugene. P.S. Almost got it under 1k lines! On Thu, Jul 17, 2014 at 7:36 AM, Stephen Balukoff sbaluk...@bluebox.net wrote: Hi Salvatore! Thank you for reading through my book-length e-mail and responding to all my points! Unfortunately, I have more responses for you, inline: On Wed, Jul 16, 2014 at 4:22 PM, Salvatore Orlando sorla...@nicira.com wrote: Hi Stephen, Thanks for your exhaustive comments! I'm always happy to exhaust others with my comments. ;) I think your points are true and valid for most cloud operators; besides the first all the point you provided indeed pertain operators and vendors. However you can't prove, I think, the opposite - that is to say that no cloud operator will find multi-service flavors useful. At the end of the day Openstack is always about choice - in this case the choice of having flavours spanning services or flavours limited to a single service. This discussion however will just end up slowly drifting into the realm of the theoretical and hypotethical and therefore won't bring anything good to our cause. Who know, in a few post we might just end up calling godwin's law! That's certainly true. But would you be willing to agree that both the model and logic behind single-service_type flavors is likely to be simpler to implement, troubleshoot, and maintain than multi-service_type flavors? If you agree, then I would say: Let's go with single-service_type flavors for now so that we can actually get an implementation done by Juno (and thus free up development that is currently being blocked by lack of flavors), and leave the more complicated multi-service_type flavors for some later date when there's a more obvious need for them. For what it's worth, I'm not against multi-service_type flavors if someone can come up with a good usage scenario that is best solved using the same. But I think it's more complication than we want or need right now, and shooting for it now is likely to ensure we wouldn't get flavors in time for Juno. There are other considerations which could be made, but since they're dependent on features which do not yet exist (NFV, service insertion, chaining and steering) I think there is no point in arguing over it. Agreed. Though, I don't think single-service flavors paint us into a corner here at all. Again, things get complicated enough when it comes to service insertion, chaining, steering, etc. that what we'll really need at that point is actual orchestration. Flavors alone will not solve these problems, and orchestration can work with many single-service flavors to provide the illusion of multi-service flavors. Don't take it the wrong way - but this is what I mean by theoretical and hypothetical. I agree with you. I think that's totally possible. But there are so many pieces which are yet missing from the puzzle that this discussion is probably worthless. Anyway, I started it, and I'm the one to be punished for it! Hah! Indeed. Ok, I'll stop speculating down that path for now, eh. ;) In conclusion I think the idea makes sense, and is a minor twist in the current design which should not either make the feature too complex neither prevent any other use case for which the flavours are being conceived. For the very same reason however, it is worth noting that this is surely not an aspect which will cause me or somebody else to put a veto on this work item. I don't think this is a minor twist in the current design, actually: * We'll have to deal with cases like the above where no valid service profiles can be found for a given kind of flavor (which we can avoid entirely if a flavor can have service profiles valid for only one kind of service). Point taken, but does not require a major change to the design since a service flavour like this should probably be caught by a validation routine. Still you'd need more pervasive validation in different points of the API. ... which sounds like significantly more complication to me. But at this point, we're arguing over what a minor twist is, which is not likely to lead to anywhere useful... * When and if tags/capabilities/extensions get introduced, we would need to provide an additional capabilities list on the service profiles in order to be able to select which service profiles provide the capabilities requested. Might be... but I don't see how that would be worse with multiple service types, especially if profiles are grouped by type. Presumably, with single-service_type flavors, all service profiles associated with the flavor should be capable of providing all the features advertised as being provided by the flavor (first in the 'description' and possibly
Re: [openstack-dev] [Neutron] Flavor framework proposal
To the earlier question on whether we had defined what we wanted to solve with the flavors framework, a high level requirement was captured in the following approved spec for advanced services: https://review.openstack.org/#/c/92200 On Wed, Jul 16, 2014 at 5:18 AM, Eugene Nikanorov enikano...@mirantis.com wrote: Some comments inline: Agreed-- I think we need to more fully flesh out how extension list / tags should work here before we implement it. But this doesn't prevent us from rolling forward with a version 1 of flavors so that we can start to use some of the benefits of having flavors (like the ability to use multiple service profiles with a single driver/provider, or multiple service profiles for a single kind of service). Agree here. Yes, I think there are many benefits we can get out of the flavor framework without having to have an extensions list / tags at this revision. But I'm curious: Did we ever define what we were actually trying to solve with flavors? Maybe that's the reason the discussion on this has been all of the place: People are probably making assumptions about the problem we're trying to solve and we need to get on the same page about this. Yes, we did! The original problem has several aspects aspects: 1) providing users with some information about what service implementation they get (capabilities) 2) providing users with ability to specify (choose, actually) some implementation details that don't relate to a logical configuration (capacity, insertion mode, HA mode, resiliency, security standards, etc) 3) providing operators a way to setup different modes of one driver 4) providing operators to seamlessly change drivers backing up existing logical configurations (now it's not so easy to do because logical config is tightly coupled with provider/driver) The proposal we're discussing right is mostly covering points (2), (3) and (4) which is already a good thing. So for now I'd propose to put 'information about service implementation' in the description to cover (1) I'm currently implementing the proposal (API and DB parts, no integration with services yet) Thanks, Eugene. ___ 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] [Neutron] Flavor framework proposal
Hi Salvatore! Thank you for reading through my book-length e-mail and responding to all my points! Unfortunately, I have more responses for you, inline: On Wed, Jul 16, 2014 at 4:22 PM, Salvatore Orlando sorla...@nicira.com wrote: Hi Stephen, Thanks for your exhaustive comments! I'm always happy to exhaust others with my comments. ;) I think your points are true and valid for most cloud operators; besides the first all the point you provided indeed pertain operators and vendors. However you can't prove, I think, the opposite - that is to say that no cloud operator will find multi-service flavors useful. At the end of the day Openstack is always about choice - in this case the choice of having flavours spanning services or flavours limited to a single service. This discussion however will just end up slowly drifting into the realm of the theoretical and hypotethical and therefore won't bring anything good to our cause. Who know, in a few post we might just end up calling godwin's law! That's certainly true. But would you be willing to agree that both the model and logic behind single-service_type flavors is likely to be simpler to implement, troubleshoot, and maintain than multi-service_type flavors? If you agree, then I would say: Let's go with single-service_type flavors for now so that we can actually get an implementation done by Juno (and thus free up development that is currently being blocked by lack of flavors), and leave the more complicated multi-service_type flavors for some later date when there's a more obvious need for them. For what it's worth, I'm not against multi-service_type flavors if someone can come up with a good usage scenario that is best solved using the same. But I think it's more complication than we want or need right now, and shooting for it now is likely to ensure we wouldn't get flavors in time for Juno. There are other considerations which could be made, but since they're dependent on features which do not yet exist (NFV, service insertion, chaining and steering) I think there is no point in arguing over it. Agreed. Though, I don't think single-service flavors paint us into a corner here at all. Again, things get complicated enough when it comes to service insertion, chaining, steering, etc. that what we'll really need at that point is actual orchestration. Flavors alone will not solve these problems, and orchestration can work with many single-service flavors to provide the illusion of multi-service flavors. Don't take it the wrong way - but this is what I mean by theoretical and hypothetical. I agree with you. I think that's totally possible. But there are so many pieces which are yet missing from the puzzle that this discussion is probably worthless. Anyway, I started it, and I'm the one to be punished for it! Hah! Indeed. Ok, I'll stop speculating down that path for now, eh. ;) In conclusion I think the idea makes sense, and is a minor twist in the current design which should not either make the feature too complex neither prevent any other use case for which the flavours are being conceived. For the very same reason however, it is worth noting that this is surely not an aspect which will cause me or somebody else to put a veto on this work item. I don't think this is a minor twist in the current design, actually: * We'll have to deal with cases like the above where no valid service profiles can be found for a given kind of flavor (which we can avoid entirely if a flavor can have service profiles valid for only one kind of service). Point taken, but does not require a major change to the design since a service flavour like this should probably be caught by a validation routine. Still you'd need more pervasive validation in different points of the API. ... which sounds like significantly more complication to me. But at this point, we're arguing over what a minor twist is, which is not likely to lead to anywhere useful... * When and if tags/capabilities/extensions get introduced, we would need to provide an additional capabilities list on the service profiles in order to be able to select which service profiles provide the capabilities requested. Might be... but I don't see how that would be worse with multiple service types, especially if profiles are grouped by type. Presumably, with single-service_type flavors, all service profiles associated with the flavor should be capable of providing all the features advertised as being provided by the flavor (first in the 'description' and possibly later programmatically via an extensions list). This means we don't have to check to see whether a service profile associated with the flavor can provide for all the extensions advertised in the flavor description because by creating the association, the operator is implying it can. * The above point makes things much more complicated when it comes to scheduling algorithms for choosing which
[openstack-dev] [Neutron] Flavor framework proposal
Hi folks! I've noticed progress on the flavor framework discussion slowing down over the last week. We would really like to see this happen for Juno because it's critical for many of the features we'd also like to get into Juno for LBaaS. I understand there are other Neutron extensions which will need it too. The proposal under discussion is here: https://review.openstack.org/#/c/102723/ One of the things I've seen come up frequently in the comments is the idea that a single flavor would apply to more than one service type (service type being 'LBaaS', 'FWaaS', 'VPNaaS', etc.). I've commented extensively on this, and my opinion is that this doesn't make a whole lot of sense. However, there are people who have a different view on this, so I would love to hear from them: Could you describe a specific usage scenario where this makes sense? What are the characteristics of a flavor that applies to more than one service type? Let's see if we can come to some conclusions on this so that we can get flavors into Juno, please! Thanks, Stephen -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Flavor framework proposal
I think I've provided some examples in the review. However, the point is mostly to simplify usage from a user perspective - allowing consumers of the neutron API to use the same flavour object for multiple services. There are other considerations which could be made, but since they're dependent on features which do not yet exist (NFV, service insertion, chaining and steering) I think there is no point in arguing over it. In conclusion I think the idea makes sense, and is a minor twist in the current design which should not either make the feature too complex neither prevent any other use case for which the flavours are being conceived. For the very same reason however, it is worth noting that this is surely not an aspect which will cause me or somebody else to put a veto on this work item. Another aspect to consider is how the flavours will work when the advanced service type they refer to is not consumable through the neutron API, which would be the case with an independent load balancing API endpoint. But this is probably another story. Salvatore On 15 July 2014 21:21, Stephen Balukoff sbaluk...@bluebox.net wrote: Hi folks! I've noticed progress on the flavor framework discussion slowing down over the last week. We would really like to see this happen for Juno because it's critical for many of the features we'd also like to get into Juno for LBaaS. I understand there are other Neutron extensions which will need it too. The proposal under discussion is here: https://review.openstack.org/#/c/102723/ One of the things I've seen come up frequently in the comments is the idea that a single flavor would apply to more than one service type (service type being 'LBaaS', 'FWaaS', 'VPNaaS', etc.). I've commented extensively on this, and my opinion is that this doesn't make a whole lot of sense. However, there are people who have a different view on this, so I would love to hear from them: Could you describe a specific usage scenario where this makes sense? What are the characteristics of a flavor that applies to more than one service type? Let's see if we can come to some conclusions on this so that we can get flavors into Juno, please! Thanks, Stephen -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ 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] [Neutron] Flavor framework proposal
Hi Stephen, So, as was discussed, existing proposal has some aspects which better to be postponed, like extension list on the flavor (instead of tags). Particularly that idea has several drawbacks: - it makes public API inflexible - turning features on/off is not what flavors should be doing, it's a task for policy framework and not flavors - flavor-based rest call dispatching is quite complex solution giving no benefits for service plugins While this is not explicitly written in proposal - that's what implied there. I think that one is a major blocker of the proposal right now, it deserves future discussion and not essential to the problem flavors are supposed to solve. Other than that, I personally don't have much disagreements on the proposal. The question about service type on the flavor is minor IMO. We can allow it to be NULL, which would mean multiservice flavor. However, multiservice flavors may put some minor requirements to driver API (that's mainly because of how flavor plugin interacts with service plugins) Thanks, Eugene. On Tue, Jul 15, 2014 at 11:21 PM, Stephen Balukoff sbaluk...@bluebox.net wrote: Hi folks! I've noticed progress on the flavor framework discussion slowing down over the last week. We would really like to see this happen for Juno because it's critical for many of the features we'd also like to get into Juno for LBaaS. I understand there are other Neutron extensions which will need it too. The proposal under discussion is here: https://review.openstack.org/#/c/102723/ One of the things I've seen come up frequently in the comments is the idea that a single flavor would apply to more than one service type (service type being 'LBaaS', 'FWaaS', 'VPNaaS', etc.). I've commented extensively on this, and my opinion is that this doesn't make a whole lot of sense. However, there are people who have a different view on this, so I would love to hear from them: Could you describe a specific usage scenario where this makes sense? What are the characteristics of a flavor that applies to more than one service type? Let's see if we can come to some conclusions on this so that we can get flavors into Juno, please! Thanks, Stephen -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ 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] [Neutron] Flavor framework proposal
Hi Salvatore and Eugene, Responses inline: On Tue, Jul 15, 2014 at 12:59 PM, Salvatore Orlando sorla...@nicira.com wrote: I think I've provided some examples in the review. I was hoping for specific examples. The discussion I've seen so far has been vague enough that it's difficult to see what people mean. It's also possible you gave specific examples but these were buried in comments on previous revisions (one of my biggest gripes with the way Gerrit works. :P ) Could you please give a specific example of what you mean, as well as how it simplifies the user experience? However, the point is mostly to simplify usage from a user perspective - allowing consumers of the neutron API to use the same flavour object for multiple services. Actually, I would argue the having a single flavor valid for several different services complicates the user experience (and vastly complicates the operator experience). This is because: * Flavors are how Operators will provide different service levels, or different feature sets for similar kinds of service. Users interested in paying for those services are likely to be more confused if a single flavor lists features for several different kinds of service. * Billing becomes more incomprehensible when the same flavor is used for multiple kinds of service. Users and Operators should not expect to pay the same rate for a Gold FWaaS instance and Gold VPNaaS instance, so why complicate things by putting them under the same flavor? * Because of the above concerns, it's likely that Operators will only deploy service profiles in a flavor for a single type of service anyway. But from the user's perspective, it's not apparent when looking at the list of flavors, which are valid for which kinds of service. What if a user tries to deploy a LBaaS service using a flavor that only has FWaaS service profiles associated with it? Presumably, the system must respond with an error indicating that no valid service profiles could be found for that service in that flavor. But this isn't very helpful to the user and is likely to lead to increased support load for the Operator who will need to explain this. * A single-service flavor is going to be inherently easier to understand than a multi-service flavor. * Single-service flavors do not preclude the ability for vendors to have multi-purpose appliances serve multiple roles in an OpenStack cloud. There are other considerations which could be made, but since they're dependent on features which do not yet exist (NFV, service insertion, chaining and steering) I think there is no point in arguing over it. Agreed. Though, I don't think single-service flavors paint us into a corner here at all. Again, things get complicated enough when it comes to service insertion, chaining, steering, etc. that what we'll really need at that point is actual orchestration. Flavors alone will not solve these problems, and orchestration can work with many single-service flavors to provide the illusion of multi-service flavors. In conclusion I think the idea makes sense, and is a minor twist in the current design which should not either make the feature too complex neither prevent any other use case for which the flavours are being conceived. For the very same reason however, it is worth noting that this is surely not an aspect which will cause me or somebody else to put a veto on this work item. I don't think this is a minor twist in the current design, actually: * We'll have to deal with cases like the above where no valid service profiles can be found for a given kind of flavor (which we can avoid entirely if a flavor can have service profiles valid for only one kind of service). * When and if tags/capabilities/extensions get introduced, we would need to provide an additional capabilities list on the service profiles in order to be able to select which service profiles provide the capabilities requested. * The above point makes things much more complicated when it comes to scheduling algorithms for choosing which service profile to use when multiple can meet the need for a given service. What does 'weight' mean if all but two low-weight service profiles get eliminated as not suitable? Another aspect to consider is how the flavours will work when the advanced service type they refer to is not consumable through the neutron API, which would be the case with an independent load balancing API endpoint. But this is probably another story. As far as I'm aware, flavors will only ever apply to advanced services consumable through the Neutron API. If this weren't the case, what's the point of having a flavor describing the service at all? If you're talking about Octavia here-- well, our plan is to have Octavia essentially be an other load balancer vendor, interfaced through a driver in the Neutron LBaaS extension. (This is also why so many developers interested in seeing Octavia come to light are spending all their time right now improving Neutron
Re: [openstack-dev] [Neutron] Flavor framework proposal
Hi Eugene, I understand the argument with preferring tags over extensions to turn/features on and off since that is more fine grained. Now you are bringing up the policy framework to actually controlling which features are available. So let’s look at this example: As an operator I want to offer a load balancer without TLS – so based on my understanding of flavors I would · Create a flavor which does not have a TLS extension/tags · Add some description on my homepage “Flavor Bronze - the reliable TLS less load balancer” · Use profiles to link that flavor to some haproxy and also some hardware load balancer aka F6 o Set parameters in my profile to disable TLS for the F6 LB Now, the user asks for a “Bronze: load balancer and I give him an F6. So he can go ahead and enable TLS via the TLS API (since flavors don’t control API restrictions) and go his merry way – unless I also use some to-be-developed policy extension to restrict access to certain API features. I am just wondering if this is what we are trying to build – and then why would we need tags and extensions if the heavy lifting is done with the policy framework… German From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Tuesday, July 15, 2014 2:07 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Flavor framework proposal Hi Stephen, So, as was discussed, existing proposal has some aspects which better to be postponed, like extension list on the flavor (instead of tags). Particularly that idea has several drawbacks: - it makes public API inflexible - turning features on/off is not what flavors should be doing, it's a task for policy framework and not flavors - flavor-based rest call dispatching is quite complex solution giving no benefits for service plugins While this is not explicitly written in proposal - that's what implied there. I think that one is a major blocker of the proposal right now, it deserves future discussion and not essential to the problem flavors are supposed to solve. Other than that, I personally don't have much disagreements on the proposal. The question about service type on the flavor is minor IMO. We can allow it to be NULL, which would mean multiservice flavor. However, multiservice flavors may put some minor requirements to driver API (that's mainly because of how flavor plugin interacts with service plugins) Thanks, Eugene. On Tue, Jul 15, 2014 at 11:21 PM, Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote: Hi folks! I've noticed progress on the flavor framework discussion slowing down over the last week. We would really like to see this happen for Juno because it's critical for many of the features we'd also like to get into Juno for LBaaS. I understand there are other Neutron extensions which will need it too. The proposal under discussion is here: https://review.openstack.org/#/c/102723/ One of the things I've seen come up frequently in the comments is the idea that a single flavor would apply to more than one service type (service type being 'LBaaS', 'FWaaS', 'VPNaaS', etc.). I've commented extensively on this, and my opinion is that this doesn't make a whole lot of sense. However, there are people who have a different view on this, so I would love to hear from them: Could you describe a specific usage scenario where this makes sense? What are the characteristics of a flavor that applies to more than one service type? Let's see if we can come to some conclusions on this so that we can get flavors into Juno, please! Thanks, Stephen -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] [Neutron] Flavor framework proposal
Hi Stephen, +1 Admittedly, since Stephen and I come from an operator centric world we have sometimes trouble grasping other use cases so I am wondering if you can provide one which would help us understand the need for grouping multiple different devices (LB, VPN, FW) under a single flavor. Thanks, German From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Tuesday, July 15, 2014 3:06 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Flavor framework proposal Hi Salvatore and Eugene, Responses inline: On Tue, Jul 15, 2014 at 12:59 PM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: I think I've provided some examples in the review. I was hoping for specific examples. The discussion I've seen so far has been vague enough that it's difficult to see what people mean. It's also possible you gave specific examples but these were buried in comments on previous revisions (one of my biggest gripes with the way Gerrit works. :P ) Could you please give a specific example of what you mean, as well as how it simplifies the user experience? However, the point is mostly to simplify usage from a user perspective - allowing consumers of the neutron API to use the same flavour object for multiple services. Actually, I would argue the having a single flavor valid for several different services complicates the user experience (and vastly complicates the operator experience). This is because: * Flavors are how Operators will provide different service levels, or different feature sets for similar kinds of service. Users interested in paying for those services are likely to be more confused if a single flavor lists features for several different kinds of service. * Billing becomes more incomprehensible when the same flavor is used for multiple kinds of service. Users and Operators should not expect to pay the same rate for a Gold FWaaS instance and Gold VPNaaS instance, so why complicate things by putting them under the same flavor? * Because of the above concerns, it's likely that Operators will only deploy service profiles in a flavor for a single type of service anyway. But from the user's perspective, it's not apparent when looking at the list of flavors, which are valid for which kinds of service. What if a user tries to deploy a LBaaS service using a flavor that only has FWaaS service profiles associated with it? Presumably, the system must respond with an error indicating that no valid service profiles could be found for that service in that flavor. But this isn't very helpful to the user and is likely to lead to increased support load for the Operator who will need to explain this. * A single-service flavor is going to be inherently easier to understand than a multi-service flavor. * Single-service flavors do not preclude the ability for vendors to have multi-purpose appliances serve multiple roles in an OpenStack cloud. There are other considerations which could be made, but since they're dependent on features which do not yet exist (NFV, service insertion, chaining and steering) I think there is no point in arguing over it. Agreed. Though, I don't think single-service flavors paint us into a corner here at all. Again, things get complicated enough when it comes to service insertion, chaining, steering, etc. that what we'll really need at that point is actual orchestration. Flavors alone will not solve these problems, and orchestration can work with many single-service flavors to provide the illusion of multi-service flavors. In conclusion I think the idea makes sense, and is a minor twist in the current design which should not either make the feature too complex neither prevent any other use case for which the flavours are being conceived. For the very same reason however, it is worth noting that this is surely not an aspect which will cause me or somebody else to put a veto on this work item. I don't think this is a minor twist in the current design, actually: * We'll have to deal with cases like the above where no valid service profiles can be found for a given kind of flavor (which we can avoid entirely if a flavor can have service profiles valid for only one kind of service). * When and if tags/capabilities/extensions get introduced, we would need to provide an additional capabilities list on the service profiles in order to be able to select which service profiles provide the capabilities requested. * The above point makes things much more complicated when it comes to scheduling algorithms for choosing which service profile to use when multiple can meet the need for a given service. What does 'weight' mean if all but two low-weight service profiles get eliminated as not suitable? Another aspect to consider is how the flavours will work when the advanced service type they refer to is not consumable through the neutron API, which would be the case
