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.net<mailto: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<mailto: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
