On Apr 27, 2014, at 8:35 AM, Eugene Nikanorov <enikano...@mirantis.com<mailto:enikano...@mirantis.com>> wrote:
On Fri, Apr 25, 2014 at 4:03 AM, Eugene Nikanorov <enikano...@mirantis.com<mailto:enikano...@mirantis.com>> wrote: Speaking of SSL - we have a few few project-wise issues such as lack of secure storage, lack of secure messaging, requirement to have opensource impl of SSL API (which yet to be added). There's also a patch on review that is worth looking at, because someone has already put efforts into both design and code. And before throwing away all those efforts we need to be sure it completely not suitable with the rest of API. Where are these proposed patches your referring too. I don't seem them in openstack-neutron or in neutron-spec or the icehouse code in github? The closest thing I find is radware mentioning it as apart of the restClient driver. 3. L7 is also a separate work, it will not be accounted in 'API improvement' blueprint. You can sync with Samuel for this as we already have pretty detailed blueprints on that. Please provide an example of how "multiple pools" will actually be used without L7. As said above, the bp targets just the baseline for L7: removing 'root object' role from the Pool, to actually allow multiple pools in configuration when L7 rules are added. And again: "Let's move the discussion off the mailing list where it's been happening over to the system where apparently others have been pressing forward without the obvious knowledge or consent of the people having the discussion. Oh, and by the way, because we've already written code here, a lot of what you propose is tacitly no longer up for discussion." 4. Attribute differences in REST resources. This falls into two categories: - existing attributes that should belong to one or another resource, The devil's in the details here. I was very specific about which attributes belong to which objects because getting this wrong has serious implications for use cases. (For example, if "neutron_subnet" is an attribute of a pool, then this implies all members of the pool must be in the same neutron_subnet. And this breaks the use case that was described on the mailing list during the SSL re-encryption discussion where some members are in the same subnet, and some are across the internet on the other side of a VPN or otherwise.) Right. I should have said it's a work item for me - to look closely through your doc and address the differences. Also, that is exactly the kind of work item where gerrit helps a lot. You also need to define which attributes are immutable after creation of the object, and which can be changed with later updates (and how). This also has implications for use cases. Well, this is usually defined in the code, I can add this to the spec as well. I hoped to avoid duplicate work. If your proposal doesn't define this level of detail, then your proposal isn't addressing the use cases and is therefore incomplete. I'm working on that. - attributes that should be added (e.g. they didn't exist in current API) Right. As I said last week, my intention was to try to address as many concerns and feature requests from the mailing list discussions, wiki pages, and google documents / spreadsheets as possible. I was hoping to take a stab at HA as well, but the result of that discussion so far is that we're nowhere near having any idea how to accomplish this in a way that is going to be generically possible for all operators. I mean: You all do realize that if there's a key missing feature that one operator absolutely needs in order to continue their business operations, that isn't addressed in our proposals... then that operator is NOT going to use our product, right? And that doesn't mean you need to offer all features out of the gate-- but you ought to have put some thought into how you're going to do it when the time comes. This proposal is trying to be that plan for how we're eventually going to do it. It will, of course, be developed incrementally. So, what are we arguing about? I'm just doing the small part that fixes relationship issue with the obj model. It is true that I haven't had the time to fill out all the use cases we thought about, or that became apparent from mailing list discussions as we were writing our API revision proposal-- our main drive was to get the proposal out the door. My plan was (and still is) to back-fill these use cases in the right place (which I'm no longer sure is the google doc that Samuel created, or the gerrit system) once we got the API proposal out. So I do apologize that I'm making reference to stuff that has been considered but not shared thus far and realize that not having it in the shared document weakens my position. I had to sleep. The first class is better to be addressed in the blueprint review. The second class could be a small action items/blueprints or even bugs. Example: 1) "custom_503" - that attribute deserves it's own miniblueprint, I'd keep it out of scope of 'API improvement' work. 2) ipv6_subnet_id/addressv6 - that IMO also deserves it's own miniblueprint (whole thing about ipv6 support) Yep, custom_503 is extremely minor, and its use case is "User would like to have custom error 503 page displayed on HTTP / HTTPS requests when no servers are available in the back-end pool(s)." IPv6 discussions are quite a bit more involved-- but I will note that at least one major vendor mentioned this as a high priority item, (and it turns out it's easy to address in the model) which is why we threw it in this proposal. They're welcome to propose bp on the ipv6 support and implement it. So, I'd like to make the following action items out of the document: 1. Extract 'core API' - VIPs/Listeners/Pools/Members/Healthmonitors. This action item is actually the blueprint that I've filed and that's what I'm going to implement "that's what I'm going to implement"-- ie. Discussion is closed on this. I'm not sure I get your point here. Just reiterating: 'root object' moved to VIP, listeners added - that's what i'm addressing. Once we have that, you can actually develop patches on everything else and be sure that you have not redone everything if underlying design is changed. 2. Work on defining single-call API that goes along with single object core API (above) Your document already does a very good job on this front. Thank you. It's nice to know some of my work is being paid attention to. 3. Extract 'Loadbalancer' portion of API into additional Doc/blueprint. I deserves it's own discussion and use cases. I think separating it will also help to reduce discussion contention. Fine, though I would say that justifying the "VIP-centric" approach becomes more difficult if we're not starting to think about how we're going to address operator concerns (like, say, HA) and how these potentially intersect and/or interface with user concerns. Well, I'd also would like to hear from those, who don't want neutron to provide 'virtualized appliance' functionality. I think that meanwhile we may treat VIP as 'loadbalancer' object and apply HA features directly to it. 4. Work with https://review.openstack.org/#/c/89903/ to define proper attribute placement of existing attributes Given that you totally ignored (or planned to ignore) the work you knew I was doing on this API proposal in writing the above blueprint... does my opinion on the attribute placement even matter at this point? Sorry again for offensive phrasing, i didn't mean that. That was meant to be is a work item more for me than for you, but i hoped to get some inline comments on gerrit. At the end I'd like to emphasize that I was not planning to implement everything and account for all cases. The scope is to add listeners and move 'root object' role from Pool to the VIP, that's it, and that's what is on spec review. Thanks, Eugene. _______________________________________________ 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
