[openstack-dev] [Resend] [api] Who owns API versioning and deprecation policy?
After reading the following pages, it’s unclear what the current API deprecation policy is and who owns it. (The first spec implies that a change took place in May 2015, but is silent on what and why.) Any hints? An authoritative doc would be useful, something other than an IRC log or mailing list reference. Geoff http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html https://wiki.openstack.org/wiki/API_Working_Group https://wiki.openstack.org/wiki/Application_Ecosystem_Working_Group __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Resend] [api] Who owns API versioning and deprecation policy?
Thanks. I’ll figure out which of my colleagues should get involved. Geoff On Aug 21, 2015, at 2:10 PM, Everett Toews everett.to...@rackspace.com wrote: On Aug 21, 2015, at 3:13 PM, Geoff Arnold ge...@geoffarnold.com wrote: After reading the following pages, it’s unclear what the current API deprecation policy is and who owns it. (The first spec implies that a change took place in May 2015, but is silent on what and why.) Any hints? An authoritative doc would be useful, something other than an IRC log or mailing list reference. Geoff http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html https://wiki.openstack.org/wiki/API_Working_Group https://wiki.openstack.org/wiki/Application_Ecosystem_Working_Group The API Working Group does. Guidelines for microversioning [1] and when to bump a microversion [2] are currently in review. Naturally your feedback is welcome. We have yet to provide guidance on deprecation. If you’d like to create a guideline on deprecation, here’s How to Contribute [3]. If you want to throw some ideas around we’re in #openstack-api or feel free to drop by one of our meetings [4]. Everett [1] https://review.openstack.org/#/c/187112/ [2] https://review.openstack.org/#/c/187896/ [3] https://wiki.openstack.org/wiki/API_Working_Group#How_to_Contribute [4] https://wiki.openstack.org/wiki/Meetings/API-WG __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Mercador] Meeting this week
The Mercador meeting this week will be a break-out from the Keystone sprint (as well as on IRC). See https://wiki.openstack.org/wiki/Meetings/MercadorTeamMeeting https://wiki.openstack.org/wiki/Meetings/MercadorTeamMeeting Geoff__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Product] Product WG considering holding a mid-cycle sprint
My apologies: I seem to have triggered a bug in Doodle. The support staff are on the case; I’ll update you when I have more information. On Jun 29, 2015, at 5:33 PM, Geoff Arnold ge...@geoffarnold.com wrote: [Note: I’m copying this to openstack-dev in case there are potential participants who have not yet joined the product-wg list.] The OpenStack Product WG is considering whether to hold a 2-day mid-cycle sprint to accelerate its work. We understand that scheduling during the summer is difficult, and we will only hold this meeting if we can get critical mass. If you are seriously interested in participating, please respond to this poll by selecting dates and indicating your preferred (or required) locations in the comments. Doodle poll link: https://doodle.com/sskuwycqfa3vhu9e https://doodle.com/sskuwycqfa3vhu9e Geoff Arnold ___ Product-wg mailing list product...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Product] Product WG considering holding a mid-cycle sprint
[Note: I’m copying this to openstack-dev in case there are potential participants who have not yet joined the product-wg list.] The OpenStack Product WG is considering whether to hold a 2-day mid-cycle sprint to accelerate its work. We understand that scheduling during the summer is difficult, and we will only hold this meeting if we can get critical mass. If you are seriously interested in participating, please respond to this poll by selecting dates and indicating your preferred (or required) locations in the comments. Doodle poll link: https://doodle.com/sskuwycqfa3vhu9e https://doodle.com/sskuwycqfa3vhu9e Geoff Arnold__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Product] Product WG considering holding a mid-cycle sprint
OK, let’s try again. Anyone who is interested in participating in a Product WG sprint, please complete this Doodle poll: https://doodle.com/sskuwycqfa3vhu9e Thanks, Geoff On Jun 29, 2015, at 6:34 PM, Geoff Arnold ge...@geoffarnold.com wrote: My apologies: I seem to have triggered a bug in Doodle. The support staff are on the case; I’ll update you when I have more information. On Jun 29, 2015, at 5:33 PM, Geoff Arnold ge...@geoffarnold.com wrote: [Note: I’m copying this to openstack-dev in case there are potential participants who have not yet joined the product-wg list.] The OpenStack Product WG is considering whether to hold a 2-day mid-cycle sprint to accelerate its work. We understand that scheduling during the summer is difficult, and we will only hold this meeting if we can get critical mass. If you are seriously interested in participating, please respond to this poll by selecting dates and indicating your preferred (or required) locations in the comments. Doodle poll link: https://doodle.com/sskuwycqfa3vhu9e https://doodle.com/sskuwycqfa3vhu9e Geoff Arnold ___ Product-wg mailing list product...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg ___ Product-wg mailing list product...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [mercador] Meeting schedule
My apologies for the delay in getting things set up. The weekly meeting for the Mercador project will be held each Friday at 1700 UTC. The first meeting will be this Friday, June 26. The meetings will take place on IRC in #openstack-meeting. The agenda will be tracked at https://wiki.openstack.org/wiki/Meetings/MercadorTeamMeeting (Yes, it’s not in Eavesdrop yet, but the update has merged.) Geoff __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Liberty mid-cycle meetups?
I’ve been trying to pull together a list of Liberty mid-cycle meetups from emails, Etherpads, wikis, etc. Many of the usual suspects are missing. Can we use this thread to gather the full list? (Alternatively, if there’s an authoritative source that I’ve missed, please share the link.) What I have so far: Kolla— San Jose, CA — TBD Murano — Virtual — TBD Nova — Rochester, MN— July 21-23 Keystone — Boston, MA — July 15-17 Neutron — Fort Collins, CO — June 24-26 Cinder — Fort Collins, CO — August 4-7 Barbican — Laurel, MD — August 5-7 Ironic — Seattle, WA — August 12-14 (tentative) Thanks, Geoff __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] UPDATED: [new][mercador] Announcing Mercador, a project to federate OpenStack cloud services.
[Updated with additional information.] Hello, I'm pleased to announce the development of a new project called Mercador (Portuguese for “merchant”). Mercador will provide a mechanism for integrating OpenStack cloud services from one cloud service provider (CSP) into the set of services published by a second CSP. The mechanism is intended to be completely transparent to cloud service users, and to require minimal changes for participating CSPs. It is based on the concept of a virtual region, and builds on the hierarchical multitenant and Keystone-to-Keystone identity federation work in Kilo. This project is hosted on StackForge, initialized as a set of empty cookiecutter[1] repos: https://github.com/stackforge/mercador-pub https://github.com/stackforge/mercador-sub https://github.com/stackforge/python-mercadorclient Planning information for the project will be captured on Trello: https://trello.com/b/6tlmk3z4/mercador-stackforge-project Please join us via iRC on #openstack-mercador on freenode. I am holding a Doodle poll to select times for our first meeting. (I’ve reformatted the poll since the original announcement.) This Doodle poll will close June 8th and meeting times will be announced on the mailing list at that time. At our first IRC meeting, we will be selecting the core team members, so if you’re interested in participating in this project, please try to attend. http://doodle.com/fsdm6ry6aytqf7w8 The initial core team includes: Geoff Arnold David Cheperdak Orran Krieger Raildo Mascena For more details, check out our Wiki: https://wiki.openstack.org/wiki/Mercador In anticipation of a lively debate, I’m appending an FAQ [2] Regards, Geoff Arnold -- [1] https://github.com/openstack-dev/cookiecutter [2] FAQ Q. What exactly is this project going to build? A. The first deliverable is a system which will allow resources from CSP A to be made available to users of an OpenStack cloud operated by CSP B. We plan to demonstrate this in Tokyo. Q. Can’t we do that today? CERN already does this, and it was the theme of the Identity Federation demonstration at the Vancouver summit. A. Those examples all require administrators to collaborate on the static configuration of the various clouds. This system will support automated dynamic configuration. Q. How? A. The administrator of CSP A defines a set of “Virtual Regions”, each mapped into a Keystone Domain within one of her Regions. Then the admin of CSP B can select an available Virtual Region and make it available to his users just as though it was a regular Region of cloud B. (It shows up in Keystone and Horizon like other regions.) Q. How do the users of CSP B experience this? A. Users shouldn’t be able to tell the difference between one of CSP B’s own regions and a virtual region sourced from CSP A. (It should pass RefStack.) Q. How is this implemented? A. CSP A deploys a “publisher” service to define and publish Virtual Regions. CSP B deploys a “subscriber” service which talks to “publishers” to bind virtual regions. And there’s a CLI tool. Q. Is that all? A. The “publisher” is straightforward. The “subscriber” needs to be able to dynamically reconfigure Keystone and Horizon. This may require some minor changes. Q. How is resource allocation policy managed? How does CSP A control what’s available in a Virtual Region? A. In Kilo, the Keystone team implemented Hierarchical Multitenancy (HMT), but the rest of OpenStack isn’t HMT-aware. We need quotas in Nova, Cinder, etc. to be extended to support HMT. Q. This doesn’t meet my expectations for Service Federation. To me, Federation implies [insert list of cool intercloud functionality]. A. We’re concentrating on this one mechanism, which we think will be a foundation for a lot of interesting innovations. We’re collaborating with some of those, like the team from the Massachusetts Open Cloud. Q. There’s more to federation than simply wiring up the OpenStack services. What about operations and business integration – logging, metrics, billing, service assurance? A. You’re right. However right now most of those things are out of scope for OpenStack. We expect that the functionality we’re going to build will wind up being embedded in various OSS and BSS workflows. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [new][mercador] Announcing Mercador, a project to federate OpenStack cloud services.
Hello, I'm pleased to announce the development of a new project called Mercador (Portuguese for “merchant”). Mercador will provide a mechanism for integrating OpenStack cloud services from one cloud service provider (CSP) into the set of services published by a second CSP. The mechanism is intended to be completely transparent to cloud service users, and to require minimal changes for participating CSPs. It is based on the concept of a virtual region, and builds on the hierarchical multitenant and Keystone-to-Keystone identity federation work in Kilo. This project will begin as a StackForge project based upon a set of empty cookiecutter[1] repos. Please join us via iRC on #openstack-mercador on freenode. [Repository info to come.] I am holding a Doodle poll to select times for our first meeting. This Doodle poll will close June 8th and meeting times will be announced on the mailing list at that time. At our first IRC meeting, we will be selecting the core team members, so if you’re interested in participating in this project, please try to attend. http://doodle.com/fsdm6ry6aytqf7w8 http://doodle.com/fsdm6ry6aytqf7w8 The initial core team includes: Geoff Arnold (Cisco) David Cheperdak (Cisco) Orran Krieger (MOC) For more details, check out our Wiki: https://wiki.openstack.org/wiki/Mercador https://wiki.openstack.org/wiki/Mercador However, in view of the lively debates which have followed recent project announcements, I’m appending an FAQ [2] Regards, Geoff Arnold -- [1] https://github.com/openstack-dev/cookiecutter https://github.com/openstack-dev/cookiecutter [2] FAQ Q. What exactly is this project going to build? A. The first deliverable is a system which will allow resources from CSP A to be made available to users of an OpenStack cloud operated by CSP B. We plan to demonstrate this in Tokyo. Q. Can’t we do that today? CERN already does this, and it was the theme of the Identity Federation demonstration at the Vancouver summit. A. Those examples all require administrators to collaborate on the static configuration of the various clouds. This system will support automated dynamic configuration. Q. How? A. The administrator of CSP A defines a set of “Virtual Regions”, each mapped into a Keystone Domain within one of her Regions. Then the admin of CSP B can select an available Virtual Region and make it available to his users just as though it was a regular Region of cloud B. (It shows up in Keystone and Horizon like other regions.) Q. How do the users of CSP B experience this? A. Users shouldn’t be able to tell the difference between one of CSP B’s own regions and a virtual region sourced from CSP A. (It should pass RefStack.) Q. How is this implemented? A. CSP A deploys a “publisher” service to define and publish Virtual Regions. CSP B deploys a “subscriber” service which talks to “publishers” to bind virtual regions. And there’s a CLI tool. Q. Is that all? A. The “publisher” is straightforward. The “subscriber” needs to be able to dynamically reconfigure Keystone and Horizon. This may require some minor changes. Q. How is resource allocation policy managed? How does CSP A control what’s available in a Virtual Region? A. In Kilo, the Keystone team implemented Hierarchical Multitenancy (HMT), but the rest of OpenStack isn’t HMT-aware. We need quotas in Nova, Cinder, etc. to be extended to support HMT. Q. This doesn’t meet my expectations for Service Federation. To me, Federation implies [insert list of cool intercloud functionality]. A. We’re concentrating on this one mechanism, which we think will be a foundation for a lot of interesting innovations. We’re collaborating with some of those, like the team from the Massachusetts Open Cloud. Q. There’s more to federation than simply wiring up the OpenStack services. What about operations and business integration – logging, metrics, billing, service assurance? A. You’re right. However right now most of those things are out of scope for OpenStack. We expect that the functionality we’re going to build will wind up being embedded in various OSS and BSS workflows. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] Midcycle planning
Yes please. I’ll be making private accommodation requirements. I have family in the area. Geoff On May 30, 2015, at 9:28 AM, Adam Young ayo...@redhat.com wrote: Now that we are through the summit, it is time to plan the Midcycle. We have had a consensus that the Keystone Midcycle would be in Boston this summer, from 15-17 July, held at Boston University. I've started a Trello Board to manage the details. https://trello.com/b/SXrl6UQ5/midcycle-planning. It is world readable, but you need to be a member to be able to edit it. Let me know if you feel the need to be able to edit it, or to receive notifications. If you are planning to attend, please let me know and I will add you to the list. There are a list of hotels with prices researched a couple weeks ago. Some of the details have changed since then. The least expensive option by far is to stay in the BU dorms; if you would like to do this, we need to know soon, as we have to reserve the rooms quickly. The exact room at BU has not been determined, but it will be in the vicinity opf the Physics and Computer Science buildings. Future notifications will be from Trello unless you request of me otherwise. Thanks, All. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?
+1 There seems to be a significant disconnect between Heat, Horizon and Keystone on the subject of multi-region configurations, and the documentation isn’t helpful. At the very least, it would be useful if discussions at the summit could result in a decent Wiki page on the subject. Geoff On May 13, 2015, at 9:49 PM, Morgan Fainberg morgan.fainb...@gmail.com wrote: On May 13, 2015, at 21:34, David Lyle dkly...@gmail.com mailto:dkly...@gmail.com wrote: On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com mailto:mga...@iweb.com wrote: When using AVAILABLE_REGIONS, you get a dropdown at login time to choose your region which is in fact your keystone endpoint. Once logged in, you get a new dropdown at the top right to switch between the keystone endpoints. This means you can configure an Horizon installation to login to multiple independent OpenStack installations. So I don't fully understand what enhancing the multi-region support in Keystone would mean. Would you be able to configure Horizon to login to multiple independent OpenStack installations? Mathieu On 2015-05-13 5:06 PM, Geoff Arnold wrote: Further digging suggests that we might consider deprecating AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in Keystone. It wouldn’t take a lot; the main points: * Implement the Regions API discussed back in the Havana time period - https://etherpad.openstack.org/p/havana-availability-zone-and-region-management https://etherpad.openstack.org/p/havana-availability-zone-and-region-management - but with full CRUD * Enhance the Endpoints API to allow filtering by region Supporting two different multi region models is problematic if we’re serious about things like multi-region Heat. Thoughts? Geoff On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com mailto:ge...@geoffarnold.com mailto:ge...@geoffarnold.com mailto:ge...@geoffarnold.com wrote: I’m looking at implementing dynamically-configured multi-region support for service federation, and the prior art on multi-region support in Horizon is pretty sketchy. This thread: http://lists.openstack.org/pipermail/openstack/2014-January/004372.html http://lists.openstack.org/pipermail/openstack/2014-January/004372.html is the only real discussion I’ve found, and it’s pretty inconclusive. More precisely, if I configure a single Horizon with AVAILABLE_REGIONS pointing at two different Keystones with region names “X” and “Y, and each of those Keystones returns a service catalog with multiple regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s Horizon going to do? Or rather, what’s it expected to do? Yes, I’m being lazy: I could actually configure this to see what happens, but hopefully it was considered during the design. Geoff PS I’ve added Heat to the subject, because from a quick read of https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat it looks as if Heat won’t support the AVAILABLE_REGIONS model. That seems like an unfortunate disconnect. Horizon only supports authenticating to one keystone endpoint at a time, specifically to one of the entries in AVAILABLE_REGIONS as defined in settings.py. Once you have an authenticated session in Horizon, the region selection support is merely for filtering between regions registered with the keystone endpoint you authenticated to, where the list of regions is determined by parsing the service catalog returned to you with your token. What's really unclear to me is what you are intending to ask. AVAILABLE_REGIONS is merely a list of keystone endpoints. They can be backed by a different IdP per endpoint and thus not share a token store. Or, they can just be keystone endpoints that are geographically different but backed by the same IdP, which may or may not share a token store. The funny thing is, for Horizon, it doesn't matter. They are all supported. But as one keystone endpoint may not know about another, unless nested, this has to be done with settings as it's not typically discoverable. If you are asking about token sharing between keystones which the thread you linked seems to indicate. Then yes, you can have a synced token store. But that is an exercise left to the operator. I'd like to quickly go on record and say that a token store sync like this is not recommended. It is possible to work around this in Kilo with some limited data sync (resource, assignment) and the use of Fernet tokens. However, as you introduce higher latencies and WAN transit this type of syncing becomes more and more prone to error. It would be possible to make DOA multi keystone aware, but before we dive too far into this I'd like to get a clear view of what exactly the use
Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?
That’s interesting, because I wasn’t aware that “cloud” was part of the formal OpenStack taxonomy. Historically, we defined a region as a set of endpoints, supplied by an instance of Keystone. You seem to be saying that a cloud is a collection of regions configured in the same Keystone. [citation needed] Puzzled. Geoff On May 14, 2015, at 7:56 AM, Zane Bitter zbit...@redhat.com wrote: On 14/05/15 10:39, Geoff Arnold wrote: +1 There seems to be a significant disconnect between Heat, Horizon and Keystone on the subject of multi-region configurations, and the documentation isn’t helpful. At the very least, it would be useful if discussions at the summit could result in a decent Wiki page on the subject. The terminology I (and Heat) have always used is that regions are sets of endpoints configured in the same Keystone. Where you have a different Keystone auth URL that is straight up a separate cloud, no matter how you slice it. The confusion here seems to be that Horizon is using the name AVAILABLE_REGIONS to denote available Keystone auth URLS - i.e. different clouds, not different regions at all. Looked at through that lens, things seem a bit easier to understand. Heat supports multi-region trees of stacks (i.e. you can created a nested stack in another region). Multi-cloud support has been considered, but afaik has not yet landed. Figuring out where to store the credentials securely is tricky. cheers, Zane. Geoff On May 13, 2015, at 9:49 PM, Morgan Fainberg morgan.fainb...@gmail.com mailto:morgan.fainb...@gmail.com wrote: On May 13, 2015, at 21:34, David Lyle dkly...@gmail.com mailto:dkly...@gmail.com wrote: On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com mailto:mga...@iweb.com wrote: When using AVAILABLE_REGIONS, you get a dropdown at login time to choose your region which is in fact your keystone endpoint. Once logged in, you get a new dropdown at the top right to switch between the keystone endpoints. This means you can configure an Horizon installation to login to multiple independent OpenStack installations. So I don't fully understand what enhancing the multi-region support in Keystone would mean. Would you be able to configure Horizon to login to multiple independent OpenStack installations? Mathieu On 2015-05-13 5:06 PM, Geoff Arnold wrote: Further digging suggests that we might consider deprecating AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in Keystone. It wouldn’t take a lot; the main points: * Implement the Regions API discussed back in the Havana time period -https://etherpad.openstack.org/p/havana-availability-zone-and-region-management - but with full CRUD * Enhance the Endpoints API to allow filtering by region Supporting two different multi region models is problematic if we’re serious about things like multi-region Heat. Thoughts? Geoff On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com mailto:ge...@geoffarnold.com mailto:ge...@geoffarnold.com mailto:ge...@geoffarnold.com wrote: I’m looking at implementing dynamically-configured multi-region support for service federation, and the prior art on multi-region support in Horizon is pretty sketchy. This thread: http://lists.openstack.org/pipermail/openstack/2014-January/004372.html is the only real discussion I’ve found, and it’s pretty inconclusive. More precisely, if I configure a single Horizon with AVAILABLE_REGIONS pointing at two different Keystones with region names “X” and “Y, and each of those Keystones returns a service catalog with multiple regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s Horizon going to do? Or rather, what’s it expected to do? Yes, I’m being lazy: I could actually configure this to see what happens, but hopefully it was considered during the design. Geoff PS I’ve added Heat to the subject, because from a quick read of https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat it looks as if Heat won’t support the AVAILABLE_REGIONS model. That seems like an unfortunate disconnect. Horizon only supports authenticating to one keystone endpoint at a time, specifically to one of the entries in AVAILABLE_REGIONS as defined in settings.py. Once you have an authenticated session in Horizon, the region selection support is merely for filtering between regions registered with the keystone endpoint you authenticated to, where the list of regions is determined by parsing the service catalog returned to you with your token. What's really unclear to me is what you are intending to ask. AVAILABLE_REGIONS is merely
Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?
+1 A wiki page laying out a mutually agreeable taxonomy seems like a good starting point. Geoff On May 14, 2015, at 7:47 AM, Anne Gentle annegen...@justwriteclick.com wrote: On Thu, May 14, 2015 at 9:39 AM, Geoff Arnold ge...@geoffarnold.com mailto:ge...@geoffarnold.com wrote: +1 There seems to be a significant disconnect between Heat, Horizon and Keystone on the subject of multi-region configurations, and the documentation isn’t helpful. At the very least, it would be useful if discussions at the summit could result in a decent Wiki page on the subject. We have a cross-project session and spec started about the service catalog: https://review.openstack.org/#/c/181393/ https://review.openstack.org/#/c/181393/ http://sched.co/3BL3 http://sched.co/3BL3 I hope more than a wiki page comes of it. :) Anne Geoff On May 13, 2015, at 9:49 PM, Morgan Fainberg morgan.fainb...@gmail.com mailto:morgan.fainb...@gmail.com wrote: On May 13, 2015, at 21:34, David Lyle dkly...@gmail.com mailto:dkly...@gmail.com wrote: On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com mailto:mga...@iweb.com wrote: When using AVAILABLE_REGIONS, you get a dropdown at login time to choose your region which is in fact your keystone endpoint. Once logged in, you get a new dropdown at the top right to switch between the keystone endpoints. This means you can configure an Horizon installation to login to multiple independent OpenStack installations. So I don't fully understand what enhancing the multi-region support in Keystone would mean. Would you be able to configure Horizon to login to multiple independent OpenStack installations? Mathieu On 2015-05-13 5:06 PM, Geoff Arnold wrote: Further digging suggests that we might consider deprecating AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in Keystone. It wouldn’t take a lot; the main points: * Implement the Regions API discussed back in the Havana time period - https://etherpad.openstack.org/p/havana-availability-zone-and-region-management https://etherpad.openstack.org/p/havana-availability-zone-and-region-management - but with full CRUD * Enhance the Endpoints API to allow filtering by region Supporting two different multi region models is problematic if we’re serious about things like multi-region Heat. Thoughts? Geoff On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com mailto:ge...@geoffarnold.com mailto:ge...@geoffarnold.com mailto:ge...@geoffarnold.com wrote: I’m looking at implementing dynamically-configured multi-region support for service federation, and the prior art on multi-region support in Horizon is pretty sketchy. This thread: http://lists.openstack.org/pipermail/openstack/2014-January/004372.html http://lists.openstack.org/pipermail/openstack/2014-January/004372.html is the only real discussion I’ve found, and it’s pretty inconclusive. More precisely, if I configure a single Horizon with AVAILABLE_REGIONS pointing at two different Keystones with region names “X” and “Y, and each of those Keystones returns a service catalog with multiple regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s Horizon going to do? Or rather, what’s it expected to do? Yes, I’m being lazy: I could actually configure this to see what happens, but hopefully it was considered during the design. Geoff PS I’ve added Heat to the subject, because from a quick read of https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat it looks as if Heat won’t support the AVAILABLE_REGIONS model. That seems like an unfortunate disconnect. Horizon only supports authenticating to one keystone endpoint at a time, specifically to one of the entries in AVAILABLE_REGIONS as defined in settings.py. Once you have an authenticated session in Horizon, the region selection support is merely for filtering between regions registered with the keystone endpoint you authenticated to, where the list of regions is determined by parsing the service catalog returned to you with your token. What's really unclear to me is what you are intending to ask. AVAILABLE_REGIONS is merely a list of keystone endpoints. They can be backed by a different IdP per endpoint and thus not share a token store. Or, they can just be keystone endpoints that are geographically different but backed by the same IdP, which may or may not share a token store. The funny thing is, for Horizon, it doesn't matter. They are all supported. But as one keystone endpoint may not know about another, unless nested, this has to be done with settings as it's not typically discoverable. If you are asking about token sharing between keystones which the thread you linked seems
Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?
If we don’t want to deprecate AVAILABLE_REGIONS, we certainly need to clean up the ambiguity. And to be honest, the existing documentation for both multi-region” schemes (AVAILABLE_REGIONS and Keystone based) is completely inadequate. Geoff On May 14, 2015, at 1:13 PM, Mathieu Gagné mga...@iweb.com wrote: On 2015-05-14 12:34 AM, David Lyle wrote: Horizon only supports authenticating to one keystone endpoint at a time, specifically to one of the entries in AVAILABLE_REGIONS as defined in settings.py. Once you have an authenticated session in Horizon, the region selection support is merely for filtering between regions registered with the keystone endpoint you authenticated to, where the list of regions is determined by parsing the service catalog returned to you with your token. What's really unclear to me is what you are intending to ask. I'm asking to NOT remove the feature provided by AVAILABLE_REGIONS which is what you described: support for multiple keystone endpoint (or OpenStack installations) in one Horizon installation. If you are asking about token sharing between keystones which the thread you linked seems to indicate. Then yes, you can have a synced token store. But that is an exercise left to the operator. I'm not suggesting token sharing. I'm merely trying to explain that AVAILABLE_REGIONS answers a different need than multi-regions in the same keystone endpoint which Horizon already supports fine. Those are 2 features answering different needs and AVAILABLE_REGIONS shouldn't be removed as suggested previously: we might consider deprecating AVAILABLE_REGIONS in Horizon. -- Mathieu __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?
Further digging suggests that we might consider deprecating AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in Keystone. It wouldn’t take a lot; the main points: Implement the Regions API discussed back in the Havana time period - https://etherpad.openstack.org/p/havana-availability-zone-and-region-management https://etherpad.openstack.org/p/havana-availability-zone-and-region-management - but with full CRUD Enhance the Endpoints API to allow filtering by region Supporting two different multi region models is problematic if we’re serious about things like multi-region Heat. Thoughts? Geoff On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com wrote: I’m looking at implementing dynamically-configured multi-region support for service federation, and the prior art on multi-region support in Horizon is pretty sketchy. This thread: http://lists.openstack.org/pipermail/openstack/2014-January/004372.html is the only real discussion I’ve found, and it’s pretty inconclusive. More precisely, if I configure a single Horizon with AVAILABLE_REGIONS pointing at two different Keystones with region names “X” and “Y, and each of those Keystones returns a service catalog with multiple regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s Horizon going to do? Or rather, what’s it expected to do? Yes, I’m being lazy: I could actually configure this to see what happens, but hopefully it was considered during the design. Geoff PS I’ve added Heat to the subject, because from a quick read of https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat it looks as if Heat won’t support the AVAILABLE_REGIONS model. That seems like an unfortunate disconnect. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?
I’m looking at implementing dynamically-configured multi-region support for service federation, and the prior art on multi-region support in Horizon is pretty sketchy. This thread: http://lists.openstack.org/pipermail/openstack/2014-January/004372.html is the only real discussion I’ve found, and it’s pretty inconclusive. More precisely, if I configure a single Horizon with AVAILABLE_REGIONS pointing at two different Keystones with region names “X” and “Y, and each of those Keystones returns a service catalog with multiple regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s Horizon going to do? Or rather, what’s it expected to do? Yes, I’m being lazy: I could actually configure this to see what happens, but hopefully it was considered during the design. Geoff PS I’ve added Heat to the subject, because from a quick read of https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat it looks as if Heat won’t support the AVAILABLE_REGIONS model. That seems like an unfortunate disconnect. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Why the Cloud Service Federation project is a good subject for the Cross-project track.
tl;dr I’d like to use a slot in the cross-project track to discuss the best way of managing cross-project, multi-cycle initiatives, using the forthcoming Cloud Service Federation (Broker) project to make it concrete rather than theoretical. Desired outcome: recommendations to Product group, verticals, TC on the right governance for such initiatives. [Doug asked me to expand on my earlier proposal, and get your feedback.] There’s a lot of interest in the broad topic of Federation of OpenStack services, by which I mean the delivery and consumption of cloud services using multiple independently operated clouds. There are various use cases, including reseller, broker, and cloud-bursting, each with specific requirements. For many people, “federation” is interpreted as an identity management problem; here we’re taking a broader view. During Kilo, the Keystone team implemented a number of features (hierarchical multitenancy, Keystone-to-Keystone, and others) which are key enabling technologies for broader service federation. We (I work for Cisco Intercloud Services) are planning to launch a Stackforge project to develop a complete solution for one of the use cases: a Broker system which supports the aggregation of virtual regions for resale or other consumption patterns. Why would this be of interest in the cross-project session, and what would we want to get out of such a discussion? Well, the Broker project will depend on new work in various projects. At a minimum, we anticipate that it will involve Horizon (DB-backed configuration, as in Keystone), Nova (quotas), Glance (resource ownership and visibility), and Ceilometer (domain-aggregated queries). There will be more. In some cases, we expect the work to extend over a couple of cycles. If this were a unique case, we’d probably resort to the traditional approach of filing multiple blueprints and working one-on-one with PTLs. However, there is reason to believe that this kind of situation is going to become more common. We have several working groups (Win The Enterprise, NFV, etc.) that are developing systems-level requirements for OpenStack, and whose success will depend on multiple-project, multiple-cycle coordination. The Product Management group which was formed after Paris is proposing to play a role in this area - is that the right approach? Meanwhile we are moving towards a new tag-based project governance framework (not to mention a new branding regime). So my purpose in bringing the Cloud Service Federation project to the cross-project track is to discuss how we want to handle this kind of systems-level initiative (“epic”, if you like). How should we manage the dependencies and priorities? Are the existing methods adequate, or do we need a more formal approach? This kind of discussion is often frustrating in the abstract, as we saw at several sessions in Paris. Thanks to the Keystone team’s work in Kilo, we’re about to launch a very specific, concrete project, and I think this will make the discussion of alternative governance more productive. Geoff __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy and Glance?
Yes. 100% upstream. And although I’ve referred to it as “reseller” (following the previous Keystone BP), it’s a much more generic pattern. Long term, I think it turns into something like a supply chain framework for services. Geoff On Apr 28, 2015, at 3:51 AM, Tim Bell tim.b...@cern.ch wrote: Geoff, Would the generic parts of your “reseller” solution by contributed to the upstream projects (e.g. glance, horizon, ceilometer) ? It would be good to get the core components understanding hierarchical multitenancy for all the use cases. The nova quota work is being submitted upstream for Liberty by Sajeesh (https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api) The cinder quota proposal is also underway (https://blueprints.launchpad.net/cinder/+spec/cinder-nested-quota-driver https://blueprints.launchpad.net/cinder/+spec/cinder-nested-quota-driver) Tim From: Geoff Arnold [mailto:ge...@geoffarnold.com] Sent: 28 April 2015 08:11 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy and Glance? Use cases: https://wiki.openstack.org/wiki/HierarchicalMultitenancy https://wiki.openstack.org/wiki/HierarchicalMultitenancy Blueprints: (Kilo): https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy https://blueprints.launchpad.net/keystone/+spec/reseller https://blueprints.launchpad.net/keystone/+spec/reseller (Liberty): https://blueprints.launchpad.net/nova/+spec/multiple-level-user-quota-management https://blueprints.launchpad.net/nova/+spec/multiple-level-user-quota-management https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api (Pending): https://blueprints.launchpad.net/horizon/+spec/hierarchical-projects https://blueprints.launchpad.net/horizon/+spec/hierarchical-projects https://blueprints.launchpad.net/horizon/+spec/inherited-roles https://blueprints.launchpad.net/horizon/+spec/inherited-roles As for adoption, it’s hard to say. The HMT work in Keystone was a necessary starting point, but in order to create a complete solution we really need the corresponding changes in Nova (quotas), Glance (resource visibility), Horizon (UI scoping), and probably Ceilometer (aggregated queries). We (Cisco) are planning to kick off a Stackforge project to knit all of these things together into a complete “reseller” federation system. I’m assuming that there will be other system-level compositions of the various pieces. Geoff On Apr 27, 2015, at 9:48 PM, Tripp, Travis S travis.tr...@hp.com mailto:travis.tr...@hp.com wrote: Geoff, Getting a spec on HMT would be helpful, as Nikhil mentioned. As a general question, what it the current adoption of domains / vs hierarchical projects? Is there a wiki or something that highlights what the desired path forward is with regard to domains? Thanks, Travis On 4/27/15, 7:16 PM, Geoff Arnold ge...@geoffarnold.com mailto:ge...@geoffarnold.com wrote: Good points. I¹ll add some details. I¹m sure the Reseller guys will have some comments. Geoff On Apr 27, 2015, at 3:32 PM, Nikhil Komawar nikhil.koma...@rackspace.com mailto:nikhil.koma...@rackspace.com wrote: Thanks Geoff. Added some notes and questions. -Nikhil From: Geoff Arnold ge...@geoffarnold.com mailto:ge...@geoffarnold.com Sent: Monday, April 27, 2015 5:50 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy and Glance? In preparation for Vancouver, I¹ve been looking for blueprints and design summit discussions involving the application of the Keystone hierarchical multitenancy work to other OpenStack projects. One obvious candidate is Glance, where, for example, we might want domain-local resource visibility as a default. Despite my searches, I wasn¹t able to find anything. Did I miss something obvious? I¹ve added a paragraph to https://etherpad.openstack.org/p/liberty-glance-summit-topics https://etherpad.openstack.org/p/liberty-glance-summit-topics to make sure it doesn¹t get overlooked. Cheers, Geoff _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _ _ OpenStack
Re: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy and Glance?
Use cases: https://wiki.openstack.org/wiki/HierarchicalMultitenancy https://wiki.openstack.org/wiki/HierarchicalMultitenancy Blueprints: (Kilo): https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy https://blueprints.launchpad.net/keystone/+spec/reseller https://blueprints.launchpad.net/keystone/+spec/reseller (Liberty): https://blueprints.launchpad.net/nova/+spec/multiple-level-user-quota-management https://blueprints.launchpad.net/nova/+spec/multiple-level-user-quota-management https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api (Pending): https://blueprints.launchpad.net/horizon/+spec/hierarchical-projects https://blueprints.launchpad.net/horizon/+spec/hierarchical-projects https://blueprints.launchpad.net/horizon/+spec/inherited-roles https://blueprints.launchpad.net/horizon/+spec/inherited-roles As for adoption, it’s hard to say. The HMT work in Keystone was a necessary starting point, but in order to create a complete solution we really need the corresponding changes in Nova (quotas), Glance (resource visibility), Horizon (UI scoping), and probably Ceilometer (aggregated queries). We (Cisco) are planning to kick off a Stackforge project to knit all of these things together into a complete “reseller” federation system. I’m assuming that there will be other system-level compositions of the various pieces. Geoff On Apr 27, 2015, at 9:48 PM, Tripp, Travis S travis.tr...@hp.com wrote: Geoff, Getting a spec on HMT would be helpful, as Nikhil mentioned. As a general question, what it the current adoption of domains / vs hierarchical projects? Is there a wiki or something that highlights what the desired path forward is with regard to domains? Thanks, Travis On 4/27/15, 7:16 PM, Geoff Arnold ge...@geoffarnold.com wrote: Good points. I¹ll add some details. I¹m sure the Reseller guys will have some comments. Geoff On Apr 27, 2015, at 3:32 PM, Nikhil Komawar nikhil.koma...@rackspace.com wrote: Thanks Geoff. Added some notes and questions. -Nikhil From: Geoff Arnold ge...@geoffarnold.com Sent: Monday, April 27, 2015 5:50 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy and Glance? In preparation for Vancouver, I¹ve been looking for blueprints and design summit discussions involving the application of the Keystone hierarchical multitenancy work to other OpenStack projects. One obvious candidate is Glance, where, for example, we might want domain-local resource visibility as a default. Despite my searches, I wasn¹t able to find anything. Did I miss something obvious? I¹ve added a paragraph to https://etherpad.openstack.org/p/liberty-glance-summit-topics to make sure it doesn¹t get overlooked. Cheers, Geoff _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone][Glance] Hierarchical multitenancy and Glance?
In preparation for Vancouver, I’ve been looking for blueprints and design summit discussions involving the application of the Keystone hierarchical multitenancy work to other OpenStack projects. One obvious candidate is Glance, where, for example, we might want domain-local resource visibility as a default. Despite my searches, I wasn’t able to find anything. Did I miss something obvious? I’ve added a paragraph to https://etherpad.openstack.org/p/liberty-glance-summit-topics to make sure it doesn’t get overlooked. Cheers, Geoff __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy and Glance?
Good points. I’ll add some details. I’m sure the Reseller guys will have some comments. Geoff On Apr 27, 2015, at 3:32 PM, Nikhil Komawar nikhil.koma...@rackspace.com wrote: Thanks Geoff. Added some notes and questions. -Nikhil From: Geoff Arnold ge...@geoffarnold.com Sent: Monday, April 27, 2015 5:50 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy and Glance? In preparation for Vancouver, I’ve been looking for blueprints and design summit discussions involving the application of the Keystone hierarchical multitenancy work to other OpenStack projects. One obvious candidate is Glance, where, for example, we might want domain-local resource visibility as a default. Despite my searches, I wasn’t able to find anything. Did I miss something obvious? I’ve added a paragraph to https://etherpad.openstack.org/p/liberty-glance-summit-topics to make sure it doesn’t get overlooked. Cheers, Geoff __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Introducing the Cloud Service Federation project (cross-project design summit proposal)
I’ve discussed this with the Keystone team, especially the Reseller folks, but not as deeply as we need to. The biggest challenge that I see with doing this inside any existing project is the Aggregator system. It’s an independent deployment that doesn’t include any of the core OpenStack IaaS services - there’s no Nova, no networking (Nova or Neutron), no Glance, no Cinder. It’s just Horizon, Keystone, and a bunch of orchestration logic to wire up the virtual regions. Just assembling the bits into a deployable and testable system is going to be significantly different from a regular OpenStack cloud. Even though OpenStack is composed of relatively independent services, there’s an assumed context which affects just about everything. I really wouldn’t ask Keystone to take on the responsibility for such a thing. Better to build it in Stackforge, get some experience with it, and figure out where it lives later on. In spite of all that, we believe that this belongs in the “big tent” OpenStack, because it builds on existing OpenStack component services, and it’s value depends on interoperability. If you deploy the Virtual Region service as part of your OpenStack cloud, any Aggregator should be able to re-present your virtual regions to its users (subject to obvious security and operational policies). We’ve used the Reseller use case to describe the workflows, but there are a number of equally important use cases for this architecture. Geoff On Apr 15, 2015, at 10:03 PM, Miguel Angel Ajo Pelayo mangel...@redhat.com mailto:mangel...@redhat.com wrote: Sounds like a very interesting idea. Have you talked to the keystone folks?, I would do this work into the keystone project itself (just a separate daemon). This still looks like identity management (federated, but identity) I know the burden of working with a mainstream project could be higher, but benefits are also higher: it becomes more useful (it becomes automatically available for everyone) and also passes through the review process of the general keystone contributors, thus getting a more robust code. Best regards, Miguel On 16/4/2015, at 6:24, Geoff Arnold ge...@geoffarnold.com mailto:ge...@geoffarnold.com wrote: Yeah, we’ve taken account of: https://github.com/openstack/keystone-specs/blob/master/specs/juno/keystone-to-keystone-federation.rst https://github.com/openstack/keystone-specs/blob/master/specs/juno/keystone-to-keystone-federation.rst http://blog.rodrigods.com/playing-with-keystone-to-keystone-federation/ http://blog.rodrigods.com/playing-with-keystone-to-keystone-federation/ http://docs.openstack.org/developer/keystone/configure_federation.html http://docs.openstack.org/developer/keystone/configure_federation.html One of the use cases we’re wrestling with requires fairly strong anonymization: if user A purchases IaaS services from reseller B, who sources those services from service provider C, nobody at C (OpenStack admin, root on any box) should be able to identify that A is consuming resources; all that they can see is that the requests are coming from B. It’s unclear if we should defer this requirement to a future version, or whether there’s something we need to (or can) do now. The main focus of Cloud Service Federation is managing the life cycle of virtual regions and service chaining. It builds on the Keystone federated identity work over the last two cycles, but identity is only part of the problem. However, I recognize that we do have an issue with terminology. For a lot of people, “federation” is simply interpreted as “identity federation”. If there’s a better term than “cloud service federation”, I’d love to hear it. (The Cisco term “Intercloud” is accurate, but probably inappropriate!) Geoff On Apr 15, 2015, at 7:07 PM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 04/15/2015 04:23 PM, Geoff Arnold wrote: That’s the basic idea. Now, if you’re a reseller of cloud services, you deploy Horizon+Aggregator/Keystone behind your public endpoint, with your branding on Horizon. You then bind each of your Aggregator Regions to a Virtual Region from one of your providers. As a reseller, you don’t actually deploy the rest of OpenStack. As for tokens, there are at least two variations, each with pros and cons: proxy and pass-through. Still working through implications of both. Geoff Read the Keysteon to Keystone (K2K) docs in the Keystone spec repo, as that addresses some of the issues here. On Apr 15, 2015, at 12:49 PM, Fox, Kevin M kevin@pnnl.gov mailto:kevin@pnnl.gov wrote: So, an Aggregator would basically be a stripped down keystone that basically provided a dynamic service catalog that points to the registered other regions? You could then point a horizon, cli, or rest api at the aggregator service? I guess if it was an identity provider too, it can
Re: [openstack-dev] [all] Introducing the Cloud Service Federation project (cross-project design summit proposal)
Joe: you have identified many of the challenges of trying to work with multiple OpenStack clouds from different providers with different configurations, resources, etc. Nevertheless, people are doing it, and doing so successfully. (I know several teams that are running across multiple public and private clouds.) Packaging solutions like Docker may help with some of the low-level compatibility issues. This proposal is intended to remove one source of friction. There’s a lot more to be done. One interesting avenue for research is going to be the development of a virtual region metadata schema that will allow a tenant (or a broker) to determine the characteristics of virtual regions. (Such a model might be a useful complement to the RefStack work.) Geoff On Apr 16, 2015, at 3:00 PM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Apr 16, 2015 at 12:16 AM, Geoff Arnold ge...@geoffarnold.com mailto:ge...@geoffarnold.com wrote: I’ve discussed this with the Keystone team, especially the Reseller folks, but not as deeply as we need to. The biggest challenge that I see with doing this inside any existing project is the Aggregator system. It’s an independent deployment that doesn’t include any of the core OpenStack IaaS services - there’s no Nova, no networking (Nova or Neutron), no Glance, no Cinder. It’s just Horizon, Keystone, and a bunch of orchestration logic to wire up the virtual regions. Just assembling the bits into a deployable and testable system is going to be significantly different from a regular OpenStack cloud. Even though OpenStack is composed of relatively independent services, there’s an assumed context which affects just about everything. I really wouldn’t ask Keystone to take on the responsibility for such a thing. Better to build it in Stackforge, get some experience with it, and figure out where it lives later on. In spite of all that, we believe that this belongs in the “big tent” OpenStack, because it builds on existing OpenStack component services, and it’s value depends on interoperability. If you deploy the Virtual Region service as part of your OpenStack cloud, any Aggregator should be able to re-present your virtual regions to its users (subject to obvious security and operational policies). We’ve used the Reseller use case to describe the workflows, but there are a number of equally important use cases for this architecture. 'interoperability' is where I can see a lot of issues arising. If I am using a reseller with regions from two different providers that are configured even slightly differently, using the two regions interchangeably will become exceedingly difficult quickly. There are many cases where the same API when powered by different drivers and slightly different configurations result in very different end user behavior. A few example issues: * Glance images maintained by the cloud provider would be different across providers. * Policy files dictating what API calls a given user can use can differ across providers. * Network models. There is no single network model for OpenStack. * CPU performance. OpenStack has no way of saying 1VCPU in provider X is equivalent to 1.5 VCPUs under provider Y. * Config driver vs. metadata service. * Those are just a few issues I can think of off the top of my head but there are many many more. I can see this model working for only the simplest of use cases. Maintaining a cohesive experience across multiple providers who may not be working together is very difficult. But perhaps I am missing something. Geoff On Apr 15, 2015, at 10:03 PM, Miguel Angel Ajo Pelayo mangel...@redhat.com mailto:mangel...@redhat.com wrote: Sounds like a very interesting idea. Have you talked to the keystone folks?, I would do this work into the keystone project itself (just a separate daemon). This still looks like identity management (federated, but identity) I know the burden of working with a mainstream project could be higher, but benefits are also higher: it becomes more useful (it becomes automatically available for everyone) and also passes through the review process of the general keystone contributors, thus getting a more robust code. Best regards, Miguel On 16/4/2015, at 6:24, Geoff Arnold ge...@geoffarnold.com mailto:ge...@geoffarnold.com wrote: Yeah, we’ve taken account of: https://github.com/openstack/keystone-specs/blob/master/specs/juno/keystone-to-keystone-federation.rst https://github.com/openstack/keystone-specs/blob/master/specs/juno/keystone-to-keystone-federation.rst http://blog.rodrigods.com/playing-with-keystone-to-keystone-federation/ http://blog.rodrigods.com/playing-with-keystone-to-keystone-federation/ http://docs.openstack.org/developer/keystone/configure_federation.html http://docs.openstack.org/developer/keystone/configure_federation.html One of the use cases we’re
Re: [openstack-dev] [all] Introducing the Cloud Service Federation project (cross-project design summit proposal)
That’s the basic idea. Now, if you’re a reseller of cloud services, you deploy Horizon+Aggregator/Keystone behind your public endpoint, with your branding on Horizon. You then bind each of your Aggregator Regions to a Virtual Region from one of your providers. As a reseller, you don’t actually deploy the rest of OpenStack. As for tokens, there are at least two variations, each with pros and cons: proxy and pass-through. Still working through implications of both. Geoff On Apr 15, 2015, at 12:49 PM, Fox, Kevin M kevin@pnnl.gov wrote: So, an Aggregator would basically be a stripped down keystone that basically provided a dynamic service catalog that points to the registered other regions? You could then point a horizon, cli, or rest api at the aggregator service? I guess if it was an identity provider too, it can potentially talk to the remote keystone and generate project scoped tokens, though you'd need project+region scoped tokens, which I'm not sure exists today? Thanks, Kevin From: Geoff Arnold [ge...@geoffarnold.com] Sent: Wednesday, April 15, 2015 12:05 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [all] Introducing the Cloud Service Federation project (cross-project design summit proposal) tl;dr We want to implement a new system which we’re calling an Aggregator which is based on Horizon and Keystone, and that can provide access to virtual Regions from multiple independent OpenStack providers. We plan on developing this system as a project in Stackforge, but we need help right now in identifying any unexpected dependencies. For the last 6-7 years, there has been great interest in the potential for various business models involving multiple clouds and/or cloud providers. These business models include but are not limited to, federation, reseller, broker, cloud-bursting, hybrid and intercloud. The core concept of this initiative is to go beyond the simple dyadic relationship between a cloud service provider and a cloud service consumer to a more sophisticated “supply chain” of cloud services, dynamically configured, and operated by different business entities. This is an ambitious goal, but there is a general sense that OpenStack is becoming stable and mature enough to support such an undertaking. Until now, OpenStack has focused on the logical abstraction of a Region as the basis for cloud service consumption. A user interacts with Horizon and Keystone instances for a Region, and through them gains access to the services and resources within the specified Region. A recent extension of this model has been to share Horizon and Keystone instances between several Regions. This simplifies the user experience and enables single sign on to a “single pane of glass”. However, in this configuration all of the services, shared or otherwise, are still administered by a single entity, and the configuration of the whole system is essentially static and centralized. We’re proposing that the first step in realizing the Cloud Service Federation use cases is to enable the administrative separation of interface and region: to create a new system which provides the same user interface as today - Horizon, Keystone - but which is administratively separate from the Region(s) which provide the actual IaaS resources. We don’t yet have a good name for this system; we’ve been referring to it as the “Aggregator”. It includes slightly-modified Horizon and Keystone services, together with a subsystem which configures these services to implement the mapping of “Aggregator Regions” to multiple, administratively independent, “Provider Regions”. Just as the User-Provider relationship in OpenStack is “on demand”, we want the Aggregator-Provider mappings to be dynamic, established by APIs, rather than statically configured. We want to achieve this without substantially changing the user experience, and with no changes to applications or to core OpenStack services. The Aggregator represents an additional way of accessing a cloud; it does not replace the existing Horizon and Keystone. The functionality and workflow is as follows: A user, X, logs into the Horizon interface provided by Aggregator A. The user sees two Regions, V1 and V2, and selects V1. This Region is actually provided by OpenStack service provider P; it’s the Region which P knows as R4. X now creates a new tenant project, T. Leveraging the Hierarchical Multitenancy work in Kilo, T is actually instantiated as a subproject of a Domain in R4, thus providing namespace isolation and quota management. Now X can deploy and operate her project T as she is used to, using Horizon, CLI, or other client-side tools. UI and API requests are forwarded by the Aggregator to P’s Region R4. [I’ll transfer this to the wiki and add diagrams.] As noted
[openstack-dev] [all] Introducing the Cloud Service Federation project (cross-project design summit proposal)
to implement it within the OpenStack process. It’s too complicated for any one of the existing OpenStack projects to take it on; large-scale proposals rarely do well in this community. So we intend to start this work as a new Stackforge project, with the objective of completing a first version during the Liberty cycle. To meet this goal, we must identify all of the features or fixes that we’ll need in other OpenStack projects, and submit them for the Liberty cycle. (This is time critical!) Hopefully each of these changes will be small enough that it can be accepted without too much debate. The two projects most affected will be Keystone and Horizon; in many cases, we will need to replace a static configuration with something more dynamic. We think the time is right to begin this work. The Keystone team paved the way during Kilo with their work on Hierarchical Multitenancy, and during the Liberty cycle we expect to see work in other projects that will build on this. (Hierarchical quotas, aggregated Ceilometer queries, that kind of thing). By starting the Cloud Service Federation project within Stackforge, we hope to avoid the “complexity antibodies”. However we really need to get this proposal in front of OpenStack developers, because it’s critically important to identify unexpected dependencies as soon as possible. For this reason, we’d like to discuss it in Vancouver as part of the cross-project track in the Design Summit. Geoff Arnold Cisco Cloud Services geoff(at)geoffarnold.com geoarnol(at)cisco.com @geoffarnold __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Introducing the Cloud Service Federation project (cross-project design summit proposal)
Yeah, we’ve taken account of: https://github.com/openstack/keystone-specs/blob/master/specs/juno/keystone-to-keystone-federation.rst https://github.com/openstack/keystone-specs/blob/master/specs/juno/keystone-to-keystone-federation.rst http://blog.rodrigods.com/playing-with-keystone-to-keystone-federation/ http://blog.rodrigods.com/playing-with-keystone-to-keystone-federation/ http://docs.openstack.org/developer/keystone/configure_federation.html http://docs.openstack.org/developer/keystone/configure_federation.html One of the use cases we’re wrestling with requires fairly strong anonymization: if user A purchases IaaS services from reseller B, who sources those services from service provider C, nobody at C (OpenStack admin, root on any box) should be able to identify that A is consuming resources; all that they can see is that the requests are coming from B. It’s unclear if we should defer this requirement to a future version, or whether there’s something we need to (or can) do now. The main focus of Cloud Service Federation is managing the life cycle of virtual regions and service chaining. It builds on the Keystone federated identity work over the last two cycles, but identity is only part of the problem. However, I recognize that we do have an issue with terminology. For a lot of people, “federation” is simply interpreted as “identity federation”. If there’s a better term than “cloud service federation”, I’d love to hear it. (The Cisco term “Intercloud” is accurate, but probably inappropriate!) Geoff On Apr 15, 2015, at 7:07 PM, Adam Young ayo...@redhat.com wrote: On 04/15/2015 04:23 PM, Geoff Arnold wrote: That’s the basic idea. Now, if you’re a reseller of cloud services, you deploy Horizon+Aggregator/Keystone behind your public endpoint, with your branding on Horizon. You then bind each of your Aggregator Regions to a Virtual Region from one of your providers. As a reseller, you don’t actually deploy the rest of OpenStack. As for tokens, there are at least two variations, each with pros and cons: proxy and pass-through. Still working through implications of both. Geoff Read the Keysteon to Keystone (K2K) docs in the Keystone spec repo, as that addresses some of the issues here. On Apr 15, 2015, at 12:49 PM, Fox, Kevin M kevin@pnnl.gov wrote: So, an Aggregator would basically be a stripped down keystone that basically provided a dynamic service catalog that points to the registered other regions? You could then point a horizon, cli, or rest api at the aggregator service? I guess if it was an identity provider too, it can potentially talk to the remote keystone and generate project scoped tokens, though you'd need project+region scoped tokens, which I'm not sure exists today? Thanks, Kevin From: Geoff Arnold [ge...@geoffarnold.com] Sent: Wednesday, April 15, 2015 12:05 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [all] Introducing the Cloud Service Federation project (cross-project design summit proposal) tl;dr We want to implement a new system which we’re calling an Aggregator which is based on Horizon and Keystone, and that can provide access to virtual Regions from multiple independent OpenStack providers. We plan on developing this system as a project in Stackforge, but we need help right now in identifying any unexpected dependencies. For the last 6-7 years, there has been great interest in the potential for various business models involving multiple clouds and/or cloud providers. These business models include but are not limited to, federation, reseller, broker, cloud-bursting, hybrid and intercloud. The core concept of this initiative is to go beyond the simple dyadic relationship between a cloud service provider and a cloud service consumer to a more sophisticated “supply chain” of cloud services, dynamically configured, and operated by different business entities. This is an ambitious goal, but there is a general sense that OpenStack is becoming stable and mature enough to support such an undertaking. Until now, OpenStack has focused on the logical abstraction of a Region as the basis for cloud service consumption. A user interacts with Horizon and Keystone instances for a Region, and through them gains access to the services and resources within the specified Region. A recent extension of this model has been to share Horizon and Keystone instances between several Regions. This simplifies the user experience and enables single sign on to a “single pane of glass”. However, in this configuration all of the services, shared or otherwise, are still administered by a single entity, and the configuration of the whole system is essentially static and centralized. We’re proposing that the first step in realizing the Cloud Service Federation use cases is to enable
Re: [openstack-dev] [all] Design Summit - Cross-project track - Session suggestions
Thanks Thierry. I really like the Google Docs form to submit new proposals. Now if someone could please fix the form so that the Topic fields in new entries are word-wrapped correctly… ;-) Geoff On Apr 9, 2015, at 7:33 AM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, If you have ideas for nice cross-project topics to discuss at the Design Summit in Vancouver, now is the time to propose them. Given the number of people involved, the etherpad last time ended up as a pile of unusable junk that took a while for the track lead to process, so for this time we opted for an open Google form with results on a Google spreadsheet where anyone can post comments. Here are the suggestions already posted: https://docs.google.com/spreadsheets/d/1vCTZBJKCMZ2xBhglnuK3ciKo3E8UMFo5S5lmIAYMCSE/edit?usp=sharing (You should be able to post comments there.) Here is the form to suggest new ideas: http://goo.gl/forms/S69HM6XEeb We expect to process those starting the week of April 27, so it would be great to submit your suggestions before EOD April 26. Regards, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][FFE] - Reseller Implementation
Glad to see this FFE. The Cisco Cloud Services team is very interested in the Reseller use case, and in a couple of possible extensions of the work. http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html covers the Keystone use cases, but there are several other developments required in other OpenStack projects to come up with a complete reseller “solution”. For my information, has anyone put together an overarching blueprint which captures the top level Reseller use cases and identifies all of the sub-projects and their dependencies? If so, wonderful. If not, we might try to work on this in the new Product Management WG. I mentioned “extensions” to http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html . There are two that we’re thinking about: - the multi-provider reseller: adding the user story where Martha buys OpenStack services from two or more providers and presents them to her customers through a single Horizon instance - stacked reseller: Martha buys OpenStack services from a provider, Alex, and also from a reseller, Chris, who purchases OpenStack services from multiple providers In each case, the unit of resale is a “virtual region”: a provider region subsetted using HMT/domains, with IdP supplied by the reseller, and constrained by resource consumption policies (e.g. Nova AZ “foo” is not available to customers of reseller “bar”). I strongly doubt that any of this is particularly original, but I haven’t seen it written up anywhere. Cheers, Geoff Arnold Cisco Cloud Services geoar...@cisco.com mailto:geoar...@cisco.com ge...@geoffarnold.com mailto:ge...@geoffarnold.com @geoffarnold On Mar 19, 2015, at 11:22 AM, Raildo Mascena rail...@gmail.com wrote: In addition, In the last keystone meeting in March 17 in the IRC channel http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2015-03-17.log we decided that Henry Nash (keystone core) will sponsor this feature as a FFE. Cheers, Raildo On Tue, Mar 17, 2015 at 5:36 PM Raildo Mascena rail...@gmail.com mailto:rail...@gmail.com wrote: Hi Folks, We’ve discussed a lot in the last Summit about the Reseller use case. OpenStack needs to grow support for hierarchical ownership of objects.This enables the management of subsets of users and projects in a way that is much more comfortable for private clouds, besides giving to public cloud providers the option of reselling a piece of their cloud. More detailed information can be found in the spec for this change at: https://review.openstack.org/#/c/139824 https://review.openstack.org/#/c/139824 The current code change for this is split into 8 patches (to make it easier to review). We currently have 7 patches in code review and we are finishing the last one. Here is the workflow of our patches: 1- Adding a field to enable the possibility to have a project with the domain feature: https://review.openstack.org/#/c/157427/ https://review.openstack.org/#/c/157427/ 2- Change some constraints and create some options to list projects (for is_domain flag, for parent_id): https://review.openstack.org/#/c/159944/ https://review.openstack.org/#/c/159944/ https://review.openstack.org/#/c/158398/ https://review.openstack.org/#/c/158398/ https://review.openstack.org/#/c/161378/ https://review.openstack.org/#/c/161378/ https://review.openstack.org/#/c/158372/ https://review.openstack.org/#/c/158372/ 3- Reflect domain operations to project table, mapping domains to projects that have the is_domain attribute set to True. In addition, it changes the read operations to use only the project table. Then, we will drop the Domain Table. https://review.openstack.org/#/c/143763/ https://review.openstack.org/#/c/143763/ https://review.openstack.org/#/c/161854/ https://review.openstack.org/#/c/161854/ (Only patch with work in progress) 4- Finally, the inherited role will not be applied to a subdomain and its sub hierarchy. https://review.openstack.org/#/c/164180/ https://review.openstack.org/#/c/164180/ Since we have the implementation almost completed, waiting for code review, I am requesting an FFE to enable the implementation of this last patch and work to have this implementation merged in Kilo. Raildo __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org
Re: [openstack-dev] [TripleO] Meetup Reminder
Clint: do you have a more precise agenda for the meetup? I like what Morgan’s proposing for the Keystone midcycle next week: Day 1: architecture and requirements Day 2: detail design work Day 3: hackathon Cheers, Geoff On Jan 4, 2015, at 12:55 PM, Clint Byrum cl...@fewbar.com wrote: Happy New Year! Just a friendly reminder to those of you who are interested in TripleO, we have a three-day Meetup scheduled for February 18-20 in Seattle, WA. All are welcome, though space is limited to 30 participants. Thus far we have 8 people signed up in the etherpad: https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup Please do add yourself to the list if you intend to come. There is information on hotels and we will add any event notifications and agenda items that come up. Thanks, and see you all there! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and managed services
There are (at least) two ways of expressing differentiation: - through an API extension, visible to the tenant - though an internal policy mechanism, with specific policies inferred from tenant or network characteristics Both have their place. Please don't fall into the trap of thinking that differentiation requires API extension. Sent from my iPhone - please excuse any typos or creative spelling corrections! On Mar 25, 2014, at 1:36 PM, Eugene Nikanorov enikano...@mirantis.com wrote: Hi John, On Tue, Mar 25, 2014 at 7:26 AM, John Dewey j...@dewey.ws wrote: I have a similar concern. The underlying driver may support different functionality, but the differentiators need exposed through the top level API. Not really, whole point of the service is to abstract the user from specifics of backend implementation. So for any feature there is a common API, not specific to any implementation. There probably could be some exception to this guide line that lays in the area of admin API, but that's yet to be discussed. I see the SSL work is well underway, and I am in the process of defining L7 scripting requirements. However, I will definitely need L7 scripting prior to the API being defined. Is this where vendor extensions come into play? I kinda like the route the Ironic guy safe taking with a “vendor passthru” API. I may say that core team has rejected 'vendor extensions' idea due to potential non-uniform user API experience. That becomes even worse with flavors introduced, because users don't know what vendor is backing up the service they have created. 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] L3 router service integration with Service Type Framework
I’m getting a “Not allowed here” error when I click through to the BP. (Yes, I’m subscribed.) On Oct 24, 2013, at 11:56 AM, Gary Duan gd...@varmour.com wrote: Hi, I've registered a BP for L3 router service integration with service framework. https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type In general, the implementation will align with how LBaaS is integrated with the framework. One consideration we heard from several team members is to be able to support vendor specific features and extensions in the service plugin. Any comment is welcome. Thanks, Gary ___ 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
