Re: [openstack-dev] Gerrit downtime and upgrade on 2014-04-28
On Fri, Apr 25, 2014 at 6:10 PM, Zaro wrote: > Gerrit 2.8 allows setting label values on patch sets either thru the > command line[1] or REST API[2]. Since we will setup WIP as a -1 score > on a label this will just be a matter of updating git-review to set > the label on new patchsets. I'm no sure if there's a bug entered in > our the issue tracker for this but you are welcome to create one. > This probably would need more than just an update since currently git-review is using (AFAICT) the SSH api or perhaps a mix. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] Accepted sessions - ACTION REQUIRED
Hi, if you're in the CC list for this email, you've proposed a session which has been (tentatively - final confirmation tomorrow or so) accepted for the Juno summit. Please ensure that you take care of the following required steps for these proposals: - There must be a dedicated etherpad for the session (many have them already - but check you have one) - The etherpad must be added to https://wiki.openstack.org/wiki/Summit/Juno/Etherpads - Please write up either in the etherpad or in email, the discussion and send to the dev list so that we are not meeting the topic for the first time at the summit - summit bandwidth is expensive, and we expect all attendees to have had the time to look at and think about the topic before the discussion happens. Let me know if you need pointers or assistance with this, of course. Thank you! -Rob TripleO Tuskar Direction for Juno http://summit.openstack.org/cfp/details/300 Tzu-Mainn Chen Unreviewed 1,1,1,1,11,1,1,1 TripleO TripleO Development and Testing Environment http://summit.openstack.org/cfp/details/369 Ben Nemec Unreviewed .5,.5,1,1,1,1 TripleO TripleO and Docker http://summit.openstack.org/cfp/details/342 James Slagle Unreviewed .5,1,1 (interesting topic, seems early for this in that we may have more pressing things),1,11,1,1 CI/testing TripleO Unit testing TripleO and Friends http://summit.openstack.org/cfp/details/368 Ben Nemec Unreviewed .5,1,1,.5,1 TripleO TripleO CI http://summit.openstack.org/cfp/details/269 Derek Higgins Unreviewed 1,.5,1,.5,1,1,1,1 TripleO TripleO core network configuration (everything except Neutron) http://summit.openstack.org/cfp/details/101Dan Prince Unreviewed .5,.5,1,.5,1,1,1,1.1 TripleO TripleO and Neutron http://summit.openstack.org/cfp/details/274 Roman Podolyaka Unreviewed .5,.5,1 TripleO TripleO Dev/Ops Session http://summit.openstack.org/cfp/details/176 Tom Fifield Unreviewed .5,.5,1,1,1 (could be a good session but note that Tom scheduled this same session in every single track?, might dilute the topic here a bit)1,1,1 -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] May/deferred sessions
Thanks for submitting your session(s) - unfortunately summit space is limited and while the selection is not yet final its likely your session(s) below won't be included. Please do feel free to raise the discussion topic at the TripleO program pod during the week though - that is there specifically to allow free form discussion and collaboration during the week. -Rob -- TripleO Elements as an install source http://summit.openstack.org/cfp/details/312 James Slagle Unreviewed .5,1,1,11,1,1,1,1 TripleO Maintenance and evolution of a Tripleo system http://summit.openstack.org/cfp/details/378 Cian O'Driscoll Unreviewed 1,1,1 (topic is too broad though),1 Deferred TripleO Windows Disk Image Builder http://summit.openstack.org/cfp/details/226 Om Kumar Unreviewed TripleO Automated Hyper-V Compute deployment using TripleO http://summit.openstack.org/cfp/details/203 Om Kumar Unreviewed TripleO TripleO Roadmap http://summit.openstack.org/cfp/details/347 Ryan Brady Unreviewed .5, TripleO Documentation Improvement http://summit.openstack.org/cfp/details/329 Ryan Brady Unreviewed 1,1,1 Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Summit] Topic review for Atlanta
On 22 April 2014 20:45, Thierry Carrez wrote: > Robert Collins wrote: >> I've pulled the summit talks into an etherpad >> (https://etherpad.openstack.org/p/tripleo-icehouse-summit) - btw, who >> can review these within the system itself? > > As the lead for the TripleO topic, you should be able to review them > (you should have a "Review topic" button near the top of the page). Let > me know if that's not the case. OH, *I* can, but I wanted to know how thats delegated, and if there were any default delegations (e.g. -core reviewers). -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Summit] Topic review for Atlanta
I've collated the votes and put a proposed selection of talks (some sessions merged) up; I'm going to push a draft timetable as soon as I finish clicking on the clicky thing .:). If your session has been selected you now need to: - ensure there is an etherpad for it - link it into the global list of etherpads - make any feedback changes reviewers may have requested. Cheers, Ro b On 22 April 2014 12:01, Robert Collins wrote: > I've pulled the summit talks into an etherpad > (https://etherpad.openstack.org/p/tripleo-icehouse-summit) - btw, who > can review these within the system itself? > > Anyhow - please put comments in the etherpad and help select the > sessions we'll do during the summit. > > I think we need to ensure reasonable coverage for: > - CI > - Finishing HA > - Upgrades > - Tuskar > > which arguably leaves just 2 slots for $whatever > > It seems to me we should focus on things where either: > - we need to build basic consensus > - crowdsourcing is at play > > I say that because we have many things being tackled and face time in > the summit is precious - things that are straight engineering are not > a particularly effective use of the time of a room with 30-80 people > in it. > > -Rob > > -- > Robert Collins > Distinguished Technologist > HP Converged Cloud -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Summit schedule draft
On 28/04/14 05:02, Michael Still wrote: Hi. I've just pushed a draft summit schedule to sched.org. I'd be interested in people who proposed a session that was accepted checking if their session time clashes with other commitments that they have, as well as people who are passionate about a given proposal ensuring that they're available at the scheduled time. Bear in mind that this is a non-trivial problem though... There's only so much schedule shuffling that can be done. Thanks, Michael Nova session: Next steps in live upgrade clashes with neutron session: Nova-Net to Neutron migration 2:40pm on Wednesday. Since these are both specifically about upgrades that involve nova, perhaps there's enough of a shared audience they should go in separate times? Regards, Tom ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ceilometer] should we limit threshold value to be postive
Hi, developers, When I test the ceilometer threshold alarm, I find that there is no limitation for the threshold value, which means we can set it to negative value, but I didn't find any volume of meters will be negative, (if I'm wrong, please let me know, thanks) So, my question is: should we add such limitation, or keep current situation because it is intended? Thanks ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] keystoneclient and project-less v3 tokens
On Thu, 2014-04-17 at 19:58 +0300, Roman Bodnarchuk wrote:
> Hello,
>
> I am trying to make sure that a user can't do anything useful with an
> unscoped token, and got to the following code in
> keystoneclient.middleware.auth_token:
>
> if _token_is_v2(token_info) and not auth_ref.project_id:
> raise InvalidUserToken('Unable to determine tenancy.')
>
> This check is performed on every request, and successfully forbids any
> request authenticated by a project-less token. But only for v2 tokens!
>
> In case service is using v3 of Keystone api, the request successfully
> passes auth_token middleware filter, and it becomes the task of each
> specific service to handle unscopedness of passed token.
>
> While Nova seem to be handling this well (basing on several tests I
> made), I was able to fetch a list of available images from Glance using
> a token of projectless user.
>
> Is this a desired behavior of keystoneclient?
> Why do we check existence of project_id only for v2 tokens?
>
> Thanks,
> Roman
Hmm, that is fairly old code. Submitted before v3 tokens were even on
the scene it looks like.
As an educated guess here i expect that it's because a v3 token can be
scoped to multiple things. It can be scoped to a project, a domain or a
service - or not at all (which would be the same thing as scoping it to
the keystone service).
The more correct way to do this would be to enforce the need for a
project scope on the service that requires the project scope. Not all
services or all actions will need a project scope and there is no reason
to prevent them access to the service if a project scope is unneeded.
On the other hand whilst that is a good justification for leaving things
as they are i'm guessing the _reason_ that it is enforced in v2 and some
scope is not enforced in v3 is mostly an accident.
Jamie
> ___
> 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] [Cinder][Nova][Keystone][docs] Version responses links
On 19:19 Sun 27 Apr , Andreas Jaeger wrote: > So, my proposal would be: > * Remove WADL links > * Have PDF links to go http://docs.openstack.org > * For those current links to the site http://docs.openstack.org: Take > care that they point either to a current file or get redirected to > http://docs.openstack.org/index.html Andreas, Thanks for starting this. As I mentioned, I started this with Cinder [1], but I was linking directly to the API spec version with the corresponding version. I'm curious on what others think the approach should be here. [1] - https://review.openstack.org/#/c/73856/ -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][blueprint] Accelerate the booting process of a number of vms via VMThunder
Jay, Huiba, Chris, Solly, Zhiyan, and everybody else, I am so excited that two of the proposals: Image Upload Plugin( http://summit.openstack.org/cfp/details/353) and Data transfer service Plugin(http://summit.openstack.org/cfp/details/352) have been merged together and scheduled in the coming design summit. If you show up in Atlanta, please come this session( http://junodesignsummit.sched.org/event/c00119362c07e4cb203d1c4053add187) and start our discussion, on Wednesday, May 14 • 11:50am - 12:30pm. I will propose a common image transfer library for all the OpenStack projects to to upload and download the images. If it is approved, with this library, Huiba, you can feel free to implement the transfer protocols you like. Best wishes, Vincent Hou (侯胜博) Staff Software Engineer, Open Standards and Open Source Team, Emerging Technology Institute, IBM China Software Development Lab Tel: 86-10-82450778 Fax: 86-10-82453660 Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193 地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193 Sheng Bo Hou/China/IBM@IBMCN 2014/04/27 22:33 Please respond to "OpenStack Development Mailing List \(not for usage questions\)" To "OpenStack Development Mailing List \(not for usage questions\)" , cc Subject Re: [openstack-dev] [Nova][blueprint] Accelerate the booting process of a number of vms via VMThunder I have done a little test for the image download and upload. I created an API for the image access, containing copyFrom and sendTo. I moved the image download and upload code from XenApi into the implementation for Http with some modifications, and the code worked for libvirt as well. copyFrom means to download the image and return the image data, and different hypervisors can choose to save it in a file or import it to the datastore; sendTo is used to upload the image and the image data is passed in as a parameter. I also did an investigation about how each hypervisor is doing the image upload and download. For the download: libvirt, hyper-v and baremetal use the code image_service.download to download the image and save it into a file. vmwareapi uses the code image_service.download to download the image and import it into the datastore. XenAPi uses image_service.download to download the image for VHD image. For the upload: They use image_service.upload to upload the image. I think we can conclude that it is possible to have a common image transfer library with different implementations for different protocols. This is a small demo code for the library: https://review.openstack.org/#/c/90601/(Jay, is it close to the library as you mentioned?). I just replaced the upload and download part with the http implementation for the imageapi and it worked fine. Best wishes, Vincent Hou (侯胜博) Staff Software Engineer, Open Standards and Open Source Team, Emerging Technology Institute, IBM China Software Development Lab Tel: 86-10-82450778 Fax: 86-10-82453660 Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193 地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193 Solly Ross 2014/04/25 01:46 Please respond to "OpenStack Development Mailing List \(not for usage questions\)" To "OpenStack Development Mailing List (not for usage questions)" , cc Subject Re: [openstack-dev] [Nova][blueprint] Accelerate the booting process of a number of vms via VMThunder Something to be aware of when planing an image transfer library is that individual drivers might have optimized support for image transfer in certain cases (especially when dealing with transferring between different formats, like raw to qcow2, etc). This builds on what Christopher was saying -- there's actually a reason why we have code for each driver. While having a common image copying library would be nice, I think a better way to do it would be to have some sort of library composed of building blocks, such that each driver could make use of common functionality while still tailoring the operation to the quirks of the particular drivers. Best Regards, Solly Ross - Original Message - From: "Christopher Lefelhocz" To: "OpenStack Development Mailing List (not for usage questions)" Sent: Thursday, April 24, 2014 11:17:41 AM Subject: Re: [openstack-dev] [Nova][blueprint] Accelerate the booting process of a number of vms via VMThunder Apologies for coming to this discussion late... On 4/22/14 6:21 PM, "Jay Pipes" wrote: > >Right, a good solution would allow for some flexibility via multiple >transfer drivers. +1. In particular I don't think this discussion should degenerate into zero-copy vs. pre caching. I see both as possible solutions depending on deployer/environment needs. > >> Jay P
Re: [openstack-dev] [all] Branchless Tempest QA Spec - final draft
Hi Matthew, Thanks for your response. 2014-04-28 11:02 GMT+09:00 Matthew Treinish : > On Mon, Apr 28, 2014 at 01:01:00AM +, Kenichi Oomichi wrote: >> >> Now we are working for adding Nova API responses checks to Tempest[1] to >> block backward incompatible changes. >> With this work, Tempest checks each response(status code, response body) >> and raises a test failure exception if detecting something unexpected. >> For example if some API parameter, which is defined as 'required' Tempest >> side, does not exist in response body, Tempest test fails. >> >> We are defining API parameters as 'required' if they are not API extensions >> or they are not depended on Nova configuration. In addition now Tempest >> allows additional API parameters, that means Tempest does not fail even if >> Nova response includes unexpected API parameters. Because I think the removal >> of API parameter causes backward incompatible issue but the addition does not >> cause it. > > So, AIUI we can only add parameters to an API with a new extension. The API > change guidelines also say that adding new properties must be conditional: > > https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Considered_OK > > Adding or removing a parameter to an API is a backwards incompatible change > IMO > for the exact reasons you mentioned here. If we have to worry about it in > tempest then end users do as well. > > This is also why there are a bunch of nova v2 extensions that just add > properties to an existing API. I think in v3 the proposal was to do this with > microversioning of the plugins. (we don't have a way to configure > microversioned v3 api plugins in tempest yet, but we can cross that bridge > when > the time comes) Either way it will allow tempest to have in config which > behavior to expect. Good point, my current understanding is: When adding new API parameters to the existing APIs, these parameters should be API extensions according to the above guidelines. So we have three options for handling API extensions in Tempest: 1. Consider them as optional, and cannot block the incompatible changes of them. (Current) 2. Consider them as required based on tempest.conf, and can block the incompatible changes. 3. Consider them as required automatically with microversioning, and can block the incompatible changes. Now current implementation is the option 1 on the bp work, but I prefer the option 3. That would be smart way. >> In this situation, there is a problem related to branchless Tempest. >> When we define new API parameter as 'required', Tempest against old release >> would fail. > > So I feel that if we are marking something in the API as required in tempest > makes the test fail in a previous release than that should be considered a bug > in the old release (assuming it was correct to mark it as required), and that > should be backportable fix. When I said the above my comment, I didn't consider the option you provided. and the above 'required' change is just my bug;) >> I think we need to define new parameters, which do not depended on the >> configuration, as 'required' in Tempest when we have added them in the >> development cycle because of blocking backward incompatible changes in >> the future. However these parameters are new and old releases don't contain >> them, so the Tempest change causes failures against old releases tests. > > I agree we should mark the required parameters as those that are used without > any extensions. If we can also conditionally check those not marked as > required > based on the enabled extensions or features in the tempest config that would > provide the best coverage. +1 > So for master branch development on tempest I think we should only concern > ourselves with getting these things to work against Juno and Icehouse. I think > Havana support using master is a lost cause at this point so we'll keep the > stable branch around until it's EOL. So hopefully we can lock down things in > tempest with the new api attribute tests quickly so we can block the Juno > additions that would violate the stability guidelines. It would be a shame if > we managed to allow a breaking API change into an API since the release. (but > hopefully it would be an easy backport or revert) +1, nice direction. >> Case: add new parameter 'A' in Juno cycle >> >>IcehouseJunoK L >> --*---*---*---*-- >> Nova:new parameter 'A' >> Tempest: define 'A' as 'required' >>block 'A' removal block >> .. >>test fails due to non-existent 'A' > > So in this example I feel that parameter 'A' can only be added as an > extension. > (or some other condition) If it's not then it's a breaking api change which > will > be caught which is the desired behavior from tempest here. Yes, right. Thanks for clarify it. >> I have
[openstack-dev] [Neutron][LBaaS] API and Object Model Direction
I'm making a new thread continuing from [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal I think this warrants its own thread since the discussion doesn't pertain directly to Stephen's proposal. Eugene, What I think what Stephen is trying to say is that in the previous IRC meeting it was explicitly said that the object model would follow the API decision. Meaning, an API that was decided on would then in turn have its own object model. Object model diagrams were also requested with each API proposal. This most recent meeting happened and a reversal happend. Now you're saying the current object model will just be changed somewhat and an API that is decided on will have to work with that object model. If that is the case then 1) there was some wasted work by people, 2) this same thing can and probably will happen with the API wasting even more time. Also, you made a comment basically implying that until people actually contribute code, they're opinion doesn't matter. That's a great way to alienate people and lose out on valuable insight from people who may have a lot of experience. Also, I think many of us newbies have contributed in other ways than code. Sure, there's no metric to measure these contributions but they should count for something. Anyway, that comment is probably insight into what the reason is for this new direction. In the end, if people feel like their opinion doesn't matter and anything they do is just a waste a time, most people won't even bother. I will participate in the neutron-specs blueprints. I actually do like that it is a place to actually make decisions, though it is tough to actually get anything in a good format. I'm not sure if all of this is a misunderstanding. I just think it should be known of our perception of what has taken place and what is taking place. If our perception is way off then I think the reality of the situation should be made more clear. Thanks, Brandon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Service VMs
Hi Balaji. Although I don't have specific opinion on name itself, can you share its origin? googlability for virtue seems okay, but I'm bit worried about legal stuff. thanks, On Thu, Apr 24, 2014 at 05:55:43AM +, "balaj...@freescale.com" wrote: > +1 for the proposal to make it as separate project. > > Can we name it as 'Virtue'!!. > > Any suggestions/comments. > > Regards, > Balaji.P > > > -Original Message- > > From: Kyle Mestery [mailto:mest...@noironetworks.com] > > Sent: Wednesday, April 23, 2014 7:17 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Cc: isaku yamahata > > Subject: Re: [openstack-dev] [neutron] Service VMs > > > > On Tue, Apr 22, 2014 at 5:49 PM, Isaku Yamahata > > wrote: > > > Hi. Keyle, thank you for starting this discussion to make progress. > > > > > > On Mon, Apr 21, 2014 at 08:41:19PM -0500, Kyle Mestery > > > wrote: > > > > > >> On Mon, Apr 21, 2014 at 4:20 PM, Doug Hellmann > > >> wrote: > > >> > On Mon, Apr 21, 2014 at 3:07 PM, Kyle Mestery > > wrote: > > >> >> For the upcoming Summit there are 3 sessions filed around "Service > > >> >> VMs" in Neutron. After discussing this with a few different > > >> >> people, I'd like to propose the idea that the "Service VM" work be > > >> >> moved out of Neutron and into it's own project on stackforge. > > >> >> There are a few reasons for this: > > >> > > > >> > How long do you anticipate the project needing to live on > > >> > stackforge before it can move to a place where we can introduce > > >> > symmetric gating with the projects that use it? > > > > > > To be honest, I'm not sure how long it will take. We will see after > > > the summit. > > > At this point, my feeling is > > > - before the summit, preliminary discussion, preparation for the > > > summit > > > - discuss at the summit (including project name?) > > > - after the summit, create its own project on stackforge and start > > > its own activity like weekly IRC meeting. > > > import neutron code repo as the first code base, and > > cleaning/stripping > > > it up and so on. > > > > > > What do you think? > > > > > I think this is a good starting plan. > > > > > > > >> The patches for this (look at the BP here [1]) have been in review > > >> for a while now as WIP. I think it's reasonable to expect that moving > > >> this to stackforge would let the authors and others interested > > >> collaborate faster. I expect this would take a cycle on stackforge > > >> before we could talk about other projects using this. But honestly, > > >> that's a better question for Isaku and Bob. > > > > > > In fact, this is not the first time that such opinion is claimed. > > > But this is the first time to get much feedback. > > > It's good timing to give it a consideration. > > > > > > Just to make it clear, the session slot will be allocated to discuss > > > on this? At least it would be valuable to share the current status and > > > to discuss on its future direction, and which part will be separated > > > out and which part will remain in Neutron. > > > > > Yes, I will keep this summit session so we can discuss it in Atlanta and > > move forward from there. > > > > > > > >> > Who is going to drive the development work? > > >> > > > >> For that, I'm thinking Isaku and Bob (copied above) would be the ones > > >> driving it. But anyone else who is interested should feel free to > > >> jump in as well. > > > > > > I'm willing to take the responsibility (and to share it with Bob). > > > Also others to help are very welcome. > > > > > > thanks, > > > > > >> Thanks, > > >> Kyle > > >> > > >> [1] > > >> https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms > > >> > > >> > Doug > > >> > > > >> >> > > >> >> 1. There is nothing Neutron specific about service VMs. > > >> >> 2. Service VMs can perform services for other OpenStack projects. > > >> >> 3. The code is quite large and may be better served being inside > > >> >> it's own project. > > >> >> > > >> >> Moving the work out of Neutron and into it's own project would > > >> >> allow for separate velocity for this project, and for code to be > > >> >> shared for the Service VM work for things other than Neutron > > services. > > >> >> > > >> >> I'm starting this email thread now to get people's feedback on > > >> >> this and see what comments other have. I've specifically copied > > >> >> Isaku and Bob, who both filed summit sessions on this and have > > >> >> done a lot of work in this area to date. > > >> >> > > >> >> Thanks, > > >> >> Kyle > > >> >> > > >> >> ___ > > >> >> 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] [nova] Summit schedule draft
2014-04-28 11:00 GMT+09:00 Michael Still : > On Mon, Apr 28, 2014 at 11:24 AM, Kenichi Oomichi > wrote: >> Hi Michael, >> >> Thanks for the schedule draft. >> I'd like to pick one comment about it. >> >> Now sessions related to Nova v3 API are scheduled like: >> - 5:20pm May 14: "Nova V3 API" >> - 5:00pm May 15: "Nova V2 on V3 API implementation POC" >> >> but "Nova V3 API" session needs some inputs from "Nova V2 on V3 API >> implementation POC". >> So I would appreciate if considering re-schedule of them. > > So, it sounds like just swapping the order of these two might fix the issue? Yes, that would fix the issue. Thanks for considering. Thanks Ken'ichi Ohmichi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Branchless Tempest QA Spec - final draft
On Mon, Apr 28, 2014 at 01:01:00AM +, Kenichi Oomichi wrote: > > Hi, > > Sorry for my late response, but I'd like to discuss this again. > > Now we are working for adding Nova API responses checks to Tempest[1] to > block backward incompatible changes. > With this work, Tempest checks each response(status code, response body) > and raises a test failure exception if detecting something unexpected. > For example if some API parameter, which is defined as 'required' Tempest > side, does not exist in response body, Tempest test fails. > > We are defining API parameters as 'required' if they are not API extensions > or they are not depended on Nova configuration. In addition now Tempest > allows additional API parameters, that means Tempest does not fail even if > Nova response includes unexpected API parameters. Because I think the removal > of API parameter causes backward incompatible issue but the addition does not > cause it. So, AIUI we can only add parameters to an API with a new extension. The API change guidelines also say that adding new properties must be conditional: https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Considered_OK Adding or removing a parameter to an API is a backwards incompatible change IMO for the exact reasons you mentioned here. If we have to worry about it in tempest then end users do as well. This is also why there are a bunch of nova v2 extensions that just add properties to an existing API. I think in v3 the proposal was to do this with microversioning of the plugins. (we don't have a way to configure microversioned v3 api plugins in tempest yet, but we can cross that bridge when the time comes) Either way it will allow tempest to have in config which behavior to expect. > > In this situation, there is a problem related to branchless Tempest. > When we define new API parameter as 'required', Tempest against old release > would fail. So I feel that if we are marking something in the API as required in tempest makes the test fail in a previous release than that should be considered a bug in the old release (assuming it was correct to mark it as required), and that should be backportable fix. > > I think we need to define new parameters, which do not depended on the > configuration, as 'required' in Tempest when we have added them in the > development cycle because of blocking backward incompatible changes in > the future. However these parameters are new and old releases don't contain > them, so the Tempest change causes failures against old releases tests. I agree we should mark the required parameters as those that are used without any extensions. If we can also conditionally check those not marked as required based on the enabled extensions or features in the tempest config that would provide the best coverage. So for master branch development on tempest I think we should only concern ourselves with getting these things to work against Juno and Icehouse. I think Havana support using master is a lost cause at this point so we'll keep the stable branch around until it's EOL. So hopefully we can lock down things in tempest with the new api attribute tests quickly so we can block the Juno additions that would violate the stability guidelines. It would be a shame if we managed to allow a breaking API change into an API since the release. (but hopefully it would be an easy backport or revert) > > Case: add new parameter 'A' in Juno cycle > >IcehouseJunoK L > --*---*---*---*-- > Nova:new parameter 'A' > Tempest: define 'A' as 'required' >block 'A' removal block > .. >test fails due to non-existent 'A' So in this example I feel that parameter 'A' can only be added as an extension. (or some other condition) If it's not then it's a breaking api change which will be caught which is the desired behavior from tempest here. Thanks, Matt Treinish > > > I have not found enough idea for this yet. > > Thanks > Ken'ichi Ohmichi > > --- > [1]: https://blueprints.launchpad.net/tempest/+spec/nova-api-attribute-test > > > -Original Message- > > From: Sean Dague [mailto:s...@dague.net] > > Sent: Monday, April 14, 2014 10:22 PM > > To: OpenStack Development Mailing List > > Subject: [openstack-dev] [all] Branchless Tempest QA Spec - final draft > > > > As we're coming up on the stable/icehouse release the QA team is looking > > pretty positive at no longer branching Tempest. The QA Spec draft for > > this is here - > > http://docs-draft.openstack.org/77/86577/2/check/gate-qa-specs-docs/3f84796/doc/build/html/specs/branchless-tempest. > > html > > and hopefully address a lot of the questions we've seen so far. > > > > Additional comments are welcome on the review - > > https://review.openstack.org/#/c/86577/ > > or as responses on this ML thread. > >
Re: [openstack-dev] [nova] Summit schedule draft
On Mon, Apr 28, 2014 at 11:24 AM, Kenichi Oomichi wrote: > Hi Michael, > > Thanks for the schedule draft. > I'd like to pick one comment about it. > > Now sessions related to Nova v3 API are scheduled like: > - 5:20pm May 14: "Nova V3 API" > - 5:00pm May 15: "Nova V2 on V3 API implementation POC" > > but "Nova V3 API" session needs some inputs from "Nova V2 on V3 API > implementation POC". > So I would appreciate if considering re-schedule of them. So, it sounds like just swapping the order of these two might fix the issue? Cheers, Michael ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Summit schedule draft
Hi Michael, Thanks for the schedule draft. I'd like to pick one comment about it. Now sessions related to Nova v3 API are scheduled like: - 5:20pm May 14: "Nova V3 API" - 5:00pm May 15: "Nova V2 on V3 API implementation POC" but "Nova V3 API" session needs some inputs from "Nova V2 on V3 API implementation POC". So I would appreciate if considering re-schedule of them. Thanks Ken'ichi Ohmichi --- > -Original Message- > From: Michael Still [mailto:mi...@stillhq.com] > Sent: Monday, April 28, 2014 6:03 AM > To: OpenStack Development Mailing List > Subject: [openstack-dev] [nova] Summit schedule draft > > Hi. > > I've just pushed a draft summit schedule to sched.org. I'd be > interested in people who proposed a session that was accepted checking > if their session time clashes with other commitments that they have, > as well as people who are passionate about a given proposal ensuring > that they're available at the scheduled time. > > Bear in mind that this is a non-trivial problem though... There's only > so much schedule shuffling that can be done. > > Thanks, > Michael > > -- > Rackspace Australia > > ___ > 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] [all] Branchless Tempest QA Spec - final draft
Hi, Sorry for my late response, but I'd like to discuss this again. Now we are working for adding Nova API responses checks to Tempest[1] to block backward incompatible changes. With this work, Tempest checks each response(status code, response body) and raises a test failure exception if detecting something unexpected. For example if some API parameter, which is defined as 'required' Tempest side, does not exist in response body, Tempest test fails. We are defining API parameters as 'required' if they are not API extensions or they are not depended on Nova configuration. In addition now Tempest allows additional API parameters, that means Tempest does not fail even if Nova response includes unexpected API parameters. Because I think the removal of API parameter causes backward incompatible issue but the addition does not cause it. In this situation, there is a problem related to branchless Tempest. When we define new API parameter as 'required', Tempest against old release would fail. I think we need to define new parameters, which do not depended on the configuration, as 'required' in Tempest when we have added them in the development cycle because of blocking backward incompatible changes in the future. However these parameters are new and old releases don't contain them, so the Tempest change causes failures against old releases tests. Case: add new parameter 'A' in Juno cycle IcehouseJunoK L --*---*---*---*-- Nova:new parameter 'A' Tempest: define 'A' as 'required' block 'A' removal block .. test fails due to non-existent 'A' I have not found enough idea for this yet. Thanks Ken'ichi Ohmichi --- [1]: https://blueprints.launchpad.net/tempest/+spec/nova-api-attribute-test > -Original Message- > From: Sean Dague [mailto:s...@dague.net] > Sent: Monday, April 14, 2014 10:22 PM > To: OpenStack Development Mailing List > Subject: [openstack-dev] [all] Branchless Tempest QA Spec - final draft > > As we're coming up on the stable/icehouse release the QA team is looking > pretty positive at no longer branching Tempest. The QA Spec draft for > this is here - > http://docs-draft.openstack.org/77/86577/2/check/gate-qa-specs-docs/3f84796/doc/build/html/specs/branchless-tempest. > html > and hopefully address a lot of the questions we've seen so far. > > Additional comments are welcome on the review - > https://review.openstack.org/#/c/86577/ > or as responses on this ML thread. > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder][Nova][Keystone][docs] Version responses links
On Sun, Apr 27, 2014 at 12:19 PM, Andreas Jaeger wrote:
> The documentation team noticed that we have links in the version
> responses of several APIs that contain URLs that do not exist at all.
>
> For example, cinder includes a link to
> "
> http://jorgew.github.com/block-storage-api/content/os-block-storage-1.0.pdf
> "
> - and jorgew.github.com does not exist as host at all.
>
> The links we're concerned about are the links to WADL and PDF files.
>
> Even if we update the links to point to valid URLs, it takes away any
> flexibility for the documentation team to move files around on the
> server.
>
> Diane Fleming and myself therefore propose to remove all the WADL
> links completely and have the PDF links just point to
> http://docs.openstack.org. So, moving forward with Juno (unless this
> gets backported), the content would be valid.
>
> But what about existing installations that already include links? Some
> of the existing links work - or worked a few months ago before some
> files got moved around. We could try to fix docs.openstack.org so that
> the WADL and PDF links to docs.openstack.org (so, not the cinder example
> above) work somehow:
> 1) Add redirects to current versions of WADL and PDF
> 2) Add redirects to just http://docs.openstack.org/index.html
>
> Since this affects several projects and is somehow user visible, we
> brought it up for discussion here. Note that some of these links seems
> to be broken for a very long time. The proposed changes do not break
> programs using the API - just users that look at the result of it in
> existing installations.
>
> So, my proposal would be:
> * Remove WADL links
>
I think this is fine going forward (as we're focusing on the JSON
interfaces), but I'm curious to know if anyone thinks this would be a
backportable change. I'd like to consider it, but while these are
documentation links, a WADL link is potentially designed for machine
consumption, so this could potentially break someone. I don't know that we
maintain our WADLs well enough for them to be useful in the real world,
though.
> * Have PDF links to go http://docs.openstack.org
As mentioned in the code review below, this needs to be revised to
text/html if it's going to point directly to a website rather than a PDF. I
imagine this change should also be backportable for those APIs that have
been broken for "a very long time."
>
> * For those current links to the site http://docs.openstack.org: Take
> care that they point either to a current file or get redirected to
> http://docs.openstack.org/index.html
>
> What do you think?
>
> Andreas
>
> For more details see these bugs:
> cinder v2: https://bugs.launchpad.net/cinder/+bug/1313116
> cinder v1: https://bugs.launchpad.net/cinder/+bug/1313118
> nova v2 and v3: https://bugs.launchpad.net/nova/+bug/1313119
> identity v2.0 and v3: https://bugs.launchpad.net/keystone/+bug/1313127
>
> A patch for Cinder is at https://review.openstack.org/90554
>
> --
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
> ___
> 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] [openstack-sdk-php] Questions about user-facing documentation
Thanks for your inputs, Matt and Anne. I’m punting on the first question (re: publishing) for now. It sounds like this is a larger discussion and we can make progress on the PHP SDK user-facing documentation without answering it right away. I’ll bring it up again if we don’t have an answer by the time we have something worth publishing. Based on your inputs I’ve created this spec: https://wiki.openstack.org/wiki/OpenStack-SDK-PHP/UserFacingDocumentation. Feel free to comment on it. I intend to start implementing it within a week or so. Thank you, Shaunak On Apr 21, 2014, at 11:40 AM, Anne Gentle wrote: > Great questions, Shaunak. Yep I've been thinking about this for a while but > not sure I have complete conclusions. More below. > > > On Wed, Apr 16, 2014 at 9:06 PM, Shaunak Kashyap > wrote: > Hi folks, > > As part of working on > https://blueprints.launchpad.net/openstack-sdk-php/+spec/sphinx-docs, I’ve > been looking at > http://git.openstack.org/cgit/stackforge/openstack-sdk-php/tree/doc. > > Before I start making any changes toward that BP, however, I wanted to put > forth a couple of overarching questions and proposals to the group: > > 1. Where and how should the user guide (i.e. Sphinx-generated docs) be > published? > > Just to give some context and background, we have a User Guide with a Python > SDK chapter: http://docs.openstack.org/user-guide/content/ > > A PHP SDK chapter might be a good addition, if you look at what we have and a > pattern that exists, but I'd REALLY like us to break out of the book model > and try to create a developer portal with a more page-centered model. > > What's that? For REST APIs, developers typically expect: > developer.example.com - for docs, examples, code, links to download dev kits. > api.example.com - for the actual api endpoints. > > What's tough for us is that there are thousands of OpenStack endpoints by > now. A few years back we created api.openstack.org, but didn't realize > there's an existing pattern of what devs look for from REST APIs. My bad, I > hope we can correct that by creating developer.openstack.org. > > > > I know there’s http://docs.openstack.org/. It seems like the logical place > for these to be linked off of but where would that link go and what is the > process of publishing our Sphinx-generated docs to that place? > > > What's tough about correcting our doc domains going forward is that we have > docs.openstack.org/developer for all the contributor dev docs. I do want to > continue to separate out the audiences: the contributors are Python devs, the > app devs are all languages. I'd like developer.openstack.org to be that > landing point for all language devs looking to consume OpenStack cloud > resources from any provider. > > Another difficulty is, how do we govern and review this content? Or do we? > Does it fall under the Documentation Program mission? Right now our mission > states we only cover "core" projects (the definition being just a handful of > projects) and users as top priority. So I see a developer portal as a user > priority. I'm not trying to do a land-grab as a PTL here, but trying to serve > users as best we can, and this is definitely an underserved audience. The TC > has a stance of "code or it doesn't count" so stackforge seems like a good > starting place. Then core teams can form with deliverables, one of which can > be docs. I think we're on the right track here, just making sure I state the > potential decision point on how to govern SDKs and their docs and form > communities around them. > > > 2. How should the user guide(s) be organized? > > If I were a developer, I’m probably looking to use a particular OpenStack > service (as opposed to learning about the PHP SDK without a particular > orientation). So I propose organizing the PHP SDK user guide accordingly: as > a set of user guides, each showing how to use the OpenStack PHP SDK for a > particular service. Of course, Identity is common to all so it’s > documentation would somehow be included in each user guide. This is similar > to how OpenStack organizes its REST API user guides - one per service (e.g. > http://docs.openstack.org/api/openstack-object-storage/1.0/content/). > > Agreed. Please use the service name not our crazy code names. :) > > > Further, within each user guide, I propose ordering the content according to > popularity of use cases for that service (with some other constraints such as > introducing concepts first, grouping similar concepts, etc.). This ensures > that the reader can get what they want, from their perspective. Particularly, > beginners would get what they came for without having to read too far into > the documentation. As an example, I think > http://git.openstack.org/cgit/stackforge/openstack-sdk-php/tree/doc/oo-tutorial.md > does a fine job of walking the user through common Object Store use cases. I > would just extend it to gradually
Re: [openstack-dev] [Heat][Summit] Input wanted - real world heat spec
On 25/04/14 11:29, Clint Byrum wrote: > Also by loading the whole stack we've allowed resources to bleed into > other resource. Currently to read Metadata for a single item that > entails _a lot_ of queries to the database because we end up having to > load the entire stack. We can't continue that as stacks grow in size. As an aside, this changeset[1] results in a stack load requiring _one_ query instead of _a lot_. Clint's argument still stands though. [1] https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bug/1306743,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Design summit preparation - Next steps for Heat Software Orchestration
On 23/04/14 04:42, Thomas Spatzier wrote: > Hi all, > > following up on Zane's request from end of last week, I wanted to kick off > some discussion on the ML around a design summit session proposal titled " > Next steps for Heat Software Orchestration". I guess there will be things > that can be sorted out this way and others that can be refined so we can > have a productive session in Atlanta. I am basically copying the complete > contents of the session proposal below so we can iterate on various points. > If it turns out that we need to split off threads, we can do that at a > later point. > > The session proposal itself is here: > http://summit.openstack.org/cfp/details/306 > > And here are the details: > > With the Icehouse release, Heat includes implementation for software > orchestration (Kudos to Steve Baker and Jun Jie Nan) which enables clean > separation of any kind of software configuration from compute instances and > thus enables a great new set of features. The implementation for software > orchestration in Icehouse has probably been the major chunk of work to > achieve a first end-to-end flow for software configuration thru scripts, > Chef or Puppet, but there is more work to be done to enable Heat for more > software orchestration use cases beyond the current support. > Below are a couple of use cases, and more importantly, thoughts on design > options of how those use cases can be addressed. > > #1 Enable software components for full lifecycle: > With the current design, "software components" defined thru SoftwareConfig > resources allow for only one config (e.g. one script) to be specified. > Typically, however, a software component has a lifecycle that is hard to > express in a single script. For example, software must be installed > (created), there should be support for suspend/resume handling, and it > should be possible to allow for deletion-logic. This is also in line with > the general Heat resource lifecycle. > By means of the optional 'actions' property of SoftwareConfig it is > possible today to specify at which lifecycle action of a SoftwareDeployment > resource the single config hook shall be executed at runtime. However, for > modeling complete handling of a software component, this would require a > number of separate SoftwareConfig and SoftwareDeployment resources to be > defined which makes a template more verbose than it would have to be. > As an optimization, SoftwareConfig could allow for providing several hooks > to address all default lifecycle operations that would then be triggered > thru the respective lifecycle actions of a SoftwareDeployment resource. > Resulting SoftwareConfig definitions could then look like the one outlined > below. I think this would fit nicely into the overall Heat resource model > for actions beyond stack-create (suspend, resume, delete). Furthermore, > this will also enable a closer alignment and straight-forward mapping to > the TOSCA Simple Profile YAML work done at OASIS and the heat-translator > StackForge project. > > So in a short, stripped-down version, SoftwareConfigs could look like > > my_sw_config: > type: OS::Heat::SoftwareConfig > properties: > create_config: # the hook for software install > suspend_config: # hook for suspend action > resume_config: # hook for resume action > delete_config: # hook for delete action > > When such a SoftwareConfig gets associated to a server via > SoftwareDeployment, the SoftwareDeployment resource lifecycle > implementation could trigger the respective hooks defined in SoftwareConfig > (if a hook is not defined, a no-op is performed). This way, all config > related to one piece of software is nicely defined in one place. OS::Heat::SoftwareConfig itself needs to remain ignorant of heat lifecycle phases, since it is just a store of config. Currently there are 2 ways to build configs which are lifecycle aware: 1. have a config/deployment pair, each with different deployment actions 2. have a single config/deployment, and have the config script do conditional logic on the derived input value deploy_action Option 2. seem reasonable for most cases, but having an option which maps better to TOSCA would be nice. Clint's StructuredConfig example would get us most of the way there, but a dedicated config resource might be easier to use. The deployment resource could remain agnostic to the contents of this resource though. The right place to handle this on the deployment side would be in the orc script 55-heat-config, which could infer whether the config was a lifecycle config, then invoke the required config based on the value of deploy_action. > > #2 Enable add-hoc actions on software components: > Apart from basic resource lifecycle hooks, it would be desirable to allow > for invocation of add-hoc actions on software. Examples would be the ad-hoc > creation of DB backups, application of patches, or creation of users for an > application. Such hooks (implemented as scripts,
Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
Hi, > You knew from the action items that came out of the IRC meeting of April > 17 that my team would be working on an API revision proposal. You also knew > that this proposal was to be accompanied by an object model diagram and > glossary, in order to clear up confusion. You were in that meeting, you saw > the action items being created. Heck, you even added the "to prepare API > for SSL and L7" directive for my team yourself! > > The implied but not stated assumption about this work was that it would be > fairly evaluated once done, and that we would be given a short window (ie. > about a week) in which to fully prepare and state our proposal. > > Your actions, though, were apparently to produce your own version of the > same in blueprint form without notifying anyone in the group that you were > going to be doing this, let alone my team. How could you have given my API > proposal a fair shake prior to publishing your blueprint, if both came out > on the same day? (In fact, I'm lead to believe that you and other Neutron > LBaaS developers hadn't even looked at my proposal before the meeting on > 4/24, where y'all started determining product direction, apparently by > edict.) > > Therefore, looking honestly at your actions on this and trying to give you > the benefit of the doubt, I still must assume that you never intended to > seriously consider our proposal. > That's strange to hear because the spec on review is a part of what is proposed in the document made by you and your team. Once again I'm not sure what this heated discussion is all about. The doc does good job and we will continue discussing it, while a part of it (spec about VIPs/Listeners/Pools) is on review where we, as lbaas subteam, actually can finalize a part of it. > Do you now understand why I find this offensive? Can you also understand > how others, seeing how this was handled, might now be reluctant to > participate? > People may find different things to be offensive. I can also say much on this, but would not like not continue the conversation in this direction. Right, so *if* we decide to go with my proposal, we need to first decide > which parts we're actually going to go with-- > I don't expect my proposal to be complete or perfect by any means, and we > need to have honest discussion of this first. Then, once we've more-or-less > come to a consensus on this overall direction, > I'm not sure i understand what you mean by 'overall direction'. Was there ever an idea of not supporting HA, or L7, or SSL or to not satisfy other requirements? The discussion could be on how to do it, then. it makes sense to think about how to split up the work into digestible, > parallelize-able chunks that can be tackled by the various interested > parties working on this project. (My team actually wanted to propose a > road map and attach it to the proposal, but there simply wasn't time if we > wanted to get the API out before the next IRC meeting in enough time for > people to have had a chance to look at it.) > > Why embark on this process at all if we don't have any real idea of what > the end-goal looks like? > I hope this will not look offensive if I say that the 'end goal' was discussed at Grizzly, Havana and Icehouse summit and even before. While not every requirement was discussed on the summits, there was quite clear understanding of the dependencies between features. And I don't mean that 'roadmap is fixed' or anything like that, I'm just saying that thinking about the end-goal is not something we've started to do 1.5 months ago. So speaking about 'holistic view', please tell, how L7 and SSL are related, does one depend on another or affect another? > Right-- so paraphrasing what I think you're saying: "Let's consider how > we're going to tackle the SSL and L7 problems at a later date, once we've > fixed the object model to be compatible with how we're going to tackle SSL > and L7." This implies you've already considered how to tackle SSL and L7 in > making your object model change proposal! > That was mostly about L7, but for sure subteam has considered and designed L7, and I also assume you've seen those design docs made by Sam: on your diagrams I see the same objects and relationship as in Samuel's doc. My point is: Unless you have already considered how to do SSL and L7, then > any object model change proposal is essentially pointless. > Why make these changes unless we already know we're going to do SSL and L7 > in some way that is compatible with the proposed changes? > > Evaluating these things *necessarily* must happen at the same time (ie. > holistically) or the object model proposal is pointless and unjustified. > Actually implementing the design will happen first with the core object > model changes, and then the SSL and L7 features. > ... > But I think I've already made my point that not considering things like > SSL and L7 in any proposal means there's no clear indication that core > object model changes will
Re: [openstack-dev] Request for Input on multi-domain identifiers.
Somewhat surprised this got zero responses. Some comments inline from me.
On 04/15/2014 10:39 PM, Adam Young wrote:
As we get closer to the summit, I'd like to make sure we have resolution
on one of the most critical issues in Keystone. How to deal with users
coming out of multiple data sources.
The issue is that a userid out of one domain must fill two requirements:
1. one userid cannot conflict with a userid from any other domain
Why is this the case? Or perhaps I am misunderstanding what you mean by
"userid". To me, a userid is a unique identifier for the user within the
Keystone system -- in other words, the UUID that is globally unique for
the user. There may be many usernames in other domains that map to the
same user UUID in a Keystone system. But only the UUID should ever
"leave Keystone" -- i.e. be transmitted out of the auth_token middleware
and end up in the other project databases.
2. we must be able to map from the userid back to the domain backend
that issued it.
Yup, agreed. But Keystone should do this and only Keystone. I see no
valid reason to leak domain and username information outside of Keystone.
We are trying to avoid an approach where we shadow the LDAP or Federated
identity provider data in a SQL backend specific to Keystone. That kind
of data duplication has a host of problems we would rather not have to
address. Instead, we need to come up with a way to layer on the User ID
scheme on top of the data from LDAP.
I suspect the scheme is going to end up being something like:
user the same field for username an userid.
The actual userid value will be composed of two parts. One will be the
username from LDAP, the other will be assigned by Keystone based on the
domain id. The last instalment we had a suggestion that looked like:
ayoung@@redhat.
The @@ is to make sure we don;t trip over some place that decided to use
email address, but still gives a separator character that is URL safe.
If you are talking about the above being the user ID that gets
transmitted to other project endpoints, then -1 from me. If you are
talking about the above being the format of a "user identifier" that
gets passed to the Keystone auth_token middleware, then verified by
Keystone and the real user UUID is then used by the other project
endpoints, then I'm fine with that.
Also, I don't really understand why you need this to be URL-safe...
Isn't this transferred as an HTTP header?
There is some concern with the length of the field. Most of the
services have userid as 64chars long, and we are pushing to syncronize
all the projects on that length. UUIDs ar 32 chars long, and Nova was
the last to assume that as userid was a UUID. Still, we can't go beyond
the 64 char limit without some pain.
I am a big -1 on expanding the length of the user ID fields in Nova or
any other project's database. UUIDs should be the *only* thing stored in
non-Keystone databases, and IMO, the only appropriate way forward is the
following:
1) Change the Keystone auth_token middleware to only return the user
UUID value (once any mapping/translation has occurred)
2) Design data migration scripts for any environment that has non-UUID
values in the user ID fields in their databases and translate the
non-UUID value to the UUID value
3) Change the data storage for these types of fields to CHAR(32) or
BINARY(16)
One question is whether we are stuck with requirement 2. For example,
if we said that a user login was always done with: domain name and
username, we would never have to look up a user by pure userid.
Again, I'm 100% against having these things live outside of Keystone.
Within Keystone, having whatever mapping system is needed is perfectly fine.
If we can loosen up on the "map userid back to domain" requirement, we
can get away with something more like sha256("%s%S" %(username,
domain_name)) for the userid. This has the benefit of looking just
like a UUID and fitting into the same size filed in the databases.
-1. We have experienced the pain in Nova of having to map between
internal UUIDs and non-UUID identifier values with the EC2 server
identifiers. I'd much prefer any such translation of identifiers for the
user and domain level be firmly behind Keystone's walls.
Best,
-jay
Resolving this issue is key to both Multiple LDAP and Federation.
___
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] [nova] Summit schedule draft
Hi Michael, Thanks for sharing the schedule. A quick glance shows me that all scheduler-related sessions will happen on Friday, that's fine :-) Just a quick note, Climate (now Blazar) was identified as a good opportunity for scheduling in Nova but the session will happen on Tuesday afternoon [1]. FYI, this session is aiming to discuss about how Climate should integrate with Nova/Gantt. Btw, I'll update tomorrow the etherpad [2] for scheduler-related sessions with dates and times, including this above session. Thanks, -Sylvain [1] http://junodesignsummit.sched.org/event/a848270c309b10517d4d186fecaf768f#.U119rvl_vrw [2] https://etherpad.openstack.org/p/Gantt-summit-sessions 2014-04-27 23:02 GMT+02:00 Michael Still : > Hi. > > I've just pushed a draft summit schedule to sched.org. I'd be > interested in people who proposed a session that was accepted checking > if their session time clashes with other commitments that they have, > as well as people who are passionate about a given proposal ensuring > that they're available at the scheduled time. > > Bear in mind that this is a non-trivial problem though... There's only > so much schedule shuffling that can be done. > > Thanks, > Michael > > -- > Rackspace Australia > > ___ > 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
[openstack-dev] [nova] Summit schedule draft
Hi. I've just pushed a draft summit schedule to sched.org. I'd be interested in people who proposed a session that was accepted checking if their session time clashes with other commitments that they have, as well as people who are passionate about a given proposal ensuring that they're available at the scheduled time. Bear in mind that this is a non-trivial problem though... There's only so much schedule shuffling that can be done. Thanks, Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder][Nova][Keystone][docs] Version responses links
The documentation team noticed that we have links in the version
responses of several APIs that contain URLs that do not exist at all.
For example, cinder includes a link to
"http://jorgew.github.com/block-storage-api/content/os-block-storage-1.0.pdf";
- and jorgew.github.com does not exist as host at all.
The links we're concerned about are the links to WADL and PDF files.
Even if we update the links to point to valid URLs, it takes away any
flexibility for the documentation team to move files around on the
server.
Diane Fleming and myself therefore propose to remove all the WADL
links completely and have the PDF links just point to
http://docs.openstack.org. So, moving forward with Juno (unless this
gets backported), the content would be valid.
But what about existing installations that already include links? Some
of the existing links work - or worked a few months ago before some
files got moved around. We could try to fix docs.openstack.org so that
the WADL and PDF links to docs.openstack.org (so, not the cinder example
above) work somehow:
1) Add redirects to current versions of WADL and PDF
2) Add redirects to just http://docs.openstack.org/index.html
Since this affects several projects and is somehow user visible, we
brought it up for discussion here. Note that some of these links seems
to be broken for a very long time. The proposed changes do not break
programs using the API - just users that look at the result of it in
existing installations.
So, my proposal would be:
* Remove WADL links
* Have PDF links to go http://docs.openstack.org
* For those current links to the site http://docs.openstack.org: Take
care that they point either to a current file or get redirected to
http://docs.openstack.org/index.html
What do you think?
Andreas
For more details see these bugs:
cinder v2: https://bugs.launchpad.net/cinder/+bug/1313116
cinder v1: https://bugs.launchpad.net/cinder/+bug/1313118
nova v2 and v3: https://bugs.launchpad.net/nova/+bug/1313119
identity v2.0 and v3: https://bugs.launchpad.net/keystone/+bug/1313127
A patch for Cinder is at https://review.openstack.org/90554
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] Meeting minutes
Agree with Dina, we should support V2 here. Sorry, I had no time for delivering a new client, but as V1 and V2 are quite identical, I can take this blueprint. -Sylvain 2014-04-27 17:44 GMT+02:00 Dina Belova : > Christian, variant #2 looks good to me) > > > On Fri, Apr 25, 2014 at 9:59 PM, Martinez, Christian < > christian.marti...@intel.com> wrote: > >> Hello, >> >> One comment regarding >> https://blueprints.launchpad.net/climate/+spec/before-end-notification-crud: >> >> One of Dina’s comments on the https://review.openstack.org/#/c/89833/was >> that it is her intention to not add this functionality into v1 API. >> >> If that’s the case, then the changes I proposed for the climateclient at >> https://review.openstack.org/#/c/89837/ won’t make sense since the >> client only works with v1 API. >> >> I see a couple of options here: >> >> · Give support for v1 and change the client accordantly >> >> · Give support only on v2, and open a bp for climateclient v2 >> support. >> >> >> >> Hope I make myself clear. >> >> I’ll be waiting for your feedback J >> >> >> >> Regards, >> >> Christian >> >> *From:* Sylvain Bauza [mailto:sylvain.ba...@gmail.com] >> *Sent:* Friday, April 25, 2014 1:04 PM >> *To:* OpenStack Development Mailing List (not for usage questions) >> *Subject:* [openstack-dev] [Climate] Meeting minutes >> >> >> >> Hi, >> >> >> >> Sorry again about my non-presence for 20 mins, I had an IRC >> client/connection issue. >> >> That impacted much the discussions, feel free to reply to this email with >> any concerns you didn't had time to raise on the meeting, so we could >> continue. >> >> >> >> That said, meeting minutes can be found here : >> >> >> >> (18:00:32) openstack: Minutes: >> http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.html >> (18:00:33) openstack: Minutes (text): >> http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.txt >> (18:00:34) openstack: Log: >> http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.log.html >> >> >> >> Thanks, >> >> -Sylvain >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > > ___ > 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] [Climate] Meeting minutes
Christian, variant #2 looks good to me) On Fri, Apr 25, 2014 at 9:59 PM, Martinez, Christian < christian.marti...@intel.com> wrote: > Hello, > > One comment regarding > https://blueprints.launchpad.net/climate/+spec/before-end-notification-crud: > > One of Dina’s comments on the https://review.openstack.org/#/c/89833/ was > that it is her intention to not add this functionality into v1 API. > > If that’s the case, then the changes I proposed for the climateclient at > https://review.openstack.org/#/c/89837/ won’t make sense since the client > only works with v1 API. > > I see a couple of options here: > > · Give support for v1 and change the client accordantly > > · Give support only on v2, and open a bp for climateclient v2 > support. > > > > Hope I make myself clear. > > I’ll be waiting for your feedback J > > > > Regards, > > Christian > > *From:* Sylvain Bauza [mailto:sylvain.ba...@gmail.com] > *Sent:* Friday, April 25, 2014 1:04 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* [openstack-dev] [Climate] Meeting minutes > > > > Hi, > > > > Sorry again about my non-presence for 20 mins, I had an IRC > client/connection issue. > > That impacted much the discussions, feel free to reply to this email with > any concerns you didn't had time to raise on the meeting, so we could > continue. > > > > That said, meeting minutes can be found here : > > > > (18:00:32) openstack: Minutes: > http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.html > (18:00:33) openstack: Minutes (text): > http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.txt > (18:00:34) openstack: Log: > http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.log.html > > > > Thanks, > > -Sylvain > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][blueprint] Accelerate the booting process of a number of vms via VMThunder
I have done a little test for the image download and upload. I created an API for the image access, containing copyFrom and sendTo. I moved the image download and upload code from XenApi into the implementation for Http with some modifications, and the code worked for libvirt as well. copyFrom means to download the image and return the image data, and different hypervisors can choose to save it in a file or import it to the datastore; sendTo is used to upload the image and the image data is passed in as a parameter. I also did an investigation about how each hypervisor is doing the image upload and download. For the download: libvirt, hyper-v and baremetal use the code image_service.download to download the image and save it into a file. vmwareapi uses the code image_service.download to download the image and import it into the datastore. XenAPi uses image_service.download to download the image for VHD image. For the upload: They use image_service.upload to upload the image. I think we can conclude that it is possible to have a common image transfer library with different implementations for different protocols. This is a small demo code for the library: https://review.openstack.org/#/c/90601/(Jay, is it close to the library as you mentioned?). I just replaced the upload and download part with the http implementation for the imageapi and it worked fine. Best wishes, Vincent Hou (侯胜博) Staff Software Engineer, Open Standards and Open Source Team, Emerging Technology Institute, IBM China Software Development Lab Tel: 86-10-82450778 Fax: 86-10-82453660 Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193 地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193 Solly Ross 2014/04/25 01:46 Please respond to "OpenStack Development Mailing List \(not for usage questions\)" To "OpenStack Development Mailing List (not for usage questions)" , cc Subject Re: [openstack-dev] [Nova][blueprint] Accelerate the booting process of a number of vms via VMThunder Something to be aware of when planing an image transfer library is that individual drivers might have optimized support for image transfer in certain cases (especially when dealing with transferring between different formats, like raw to qcow2, etc). This builds on what Christopher was saying -- there's actually a reason why we have code for each driver. While having a common image copying library would be nice, I think a better way to do it would be to have some sort of library composed of building blocks, such that each driver could make use of common functionality while still tailoring the operation to the quirks of the particular drivers. Best Regards, Solly Ross - Original Message - From: "Christopher Lefelhocz" To: "OpenStack Development Mailing List (not for usage questions)" Sent: Thursday, April 24, 2014 11:17:41 AM Subject: Re: [openstack-dev] [Nova][blueprint] Accelerate the booting process of a number of vms via VMThunder Apologies for coming to this discussion late... On 4/22/14 6:21 PM, "Jay Pipes" wrote: > >Right, a good solution would allow for some flexibility via multiple >transfer drivers. +1. In particular I don't think this discussion should degenerate into zero-copy vs. pre caching. I see both as possible solutions depending on deployer/environment needs. > >> Jay Pipes has suggested we figure out a blueprint for a separate >> library dedicated to the data(byte) transfer, which may be put in oslo >> and used by any projects in need (Hoping Jay can come in:-)). Huiba, >> Zhiyan, everyone else, do you think we come up with a blueprint about >> the data transfer in oslo can work? > >Yes, so I believe the most appropriate solution is to create a library >-- in oslo or a standalone library like taskflow -- that would offer a >simple byte streaming library that could be used by nova.image to expose >a neat and clean task-based API. > >Right now, there is a bunch of random image transfer code spread >throughout nova.image and in each of the virt drivers there seems to be >different re-implementations of similar functionality. I propose we >clean all that up and have nova.image expose an API so that a virt >driver could do something like this: > >from nova.image import api as image_api > >... > >task = image_api.copy(from_path_or_uri, to_path_or_uri) ># do some other work >copy_task_result = task.wait() > >Within nova.image.api.copy(), we would use the aforementioned transfer >library to move the image bits from the source to the destination using >the most appropriate method. If I understand correctly, we'll create some common library around this. It would be good to understand the details a bit better. I've thought a bit about this issue. The one area that I get stuck at is providing a common set of downloads which work across drivers effectively. Part of th
Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
> > On Fri, Apr 25, 2014 at 4:03 AM, Eugene Nikanorov > wrote: > >> Hi Stephen, >> >> Thanks for the great document. As I promised, I'll try to make a few >> action items out if it. >> First of all, I'd like to say that the API you have proposed is very >> close to what is proposed in the blueprint >> https://review.openstack.org/#/c/89903/ with several differences I'd >> like to address here and make them action items. >> > > Ok, the above blueprint was uploaded on April 23rd, literally the day I > sent my API proposal to the mailing list. And this was after it was known > via the action items in the previous week's IRC meeting that my team and I > would be working hard over the next week to produce an API proposal > revision, based on the excellent work of the Rackspace team from the > previous week. > > I can understand having a "plan B" in case I missed a deadline there > (after all, I wasn't all that confident we'd get it done in time, but I > worked through the weekend and pulled some very long days to get it done)-- > but it's pretty offensive to me to realize that the action items from the > previous week's meeting apparently weren't being taken seriously. > I'm not sure which of my actions exactly has offended you, was it submitting a blueprint to neutron-spec? I've been working on the several proposals, including the one on review since the start of Icehouse, preparing wikis, docs, and even an attempt to actually implement the proposal, so I'm not sure what exactly I did wrong. I was not thinking about beating anyone to submit blueprint first, it was on launchpad since the end of havana anyway and i've just renewed it and followed the new process. That not only was there apparently never an intent to seriously consider my > proposal, but now, if I want to be heard, I'm going to have to familiarize > myself with your proposal and fight tooth and nail to be heard to fix any > brokenness I will almost certainly find in it. And I have to do this with > very little confidence that my voice is going to be heard. > I think our disconnect comes from the fact that whole discussion that started in the end of Havana from fixing the API in the way that L7 & multiple listeners are possible, came to the discussion of 'what lbaas API of the dream should look like'. Your document does great job of addressing the latter, but it's hardly a single action item/single blueprint/single patch. > Gee. Thanks. > Sorry, In fact I should have meant that some of those action items are for me actually, your doc is very detailed, while spec on review yet is not. I'll try to bring it to some accordance to your doc. > >> So, first of all, I think that API described in the doc seems to account >> for all cases we had in mind, i didn't check on case-by-cases basis, it's >> just a first glance impression looking at REST resource set and their >> attributes. >> > > As an aside, let's us please, please, please get these use cases out of > being "in mind" and into a unified, digestible, revision-controlled > document. I guarantee you haven't thought of some of the use cases I have > in mind. > > >> General idea of the whole API/obj model improvement is that we create a >> baseline for all advanced features/usecases that we have in the roadmap. >> Which means that those features then can be added incrementally. >> Incrementally means that resources or attributes might be added, but >> workflow remains and backward compatibility is preserved. That was not the >> case with multiple listeners and L7. >> > > I would argue that that wasn't the case for SSL either in the old model. > And even the model I proposed doesn't address HA yet. > The model shouldn't immediately address HA. You just have to make sure that once you decided to add HA, you don't have to redesign the rest of it (but that probably requires some ideas on how to add HA) > It's assumed that the object model proposed won't affect the ability of > vendors to implement HA in whatever way makes sense for their > organization... but we don't really know that until we see some rough > models on that front. > > Anyway, I think the point remains that the whole reason for the API and > object model revision was to be more forward thinking, specifically about > those features that are currently sorely lacking from Neutron LBaaS, and > which both users and operators clearly need before the solution can be > deployed on a wide scale. > > And yes, of course this is a design that will necessarily be implemented > incrementally! First priority should be to deliver at least the same level > of functionality that the old api / object model delivers. But, again, I > think it's a really good idea to be forward thinking about these sorts of > things. If I'm planning a road trip from Denver to New York, I like to > consider at a high level at least what kind of route will take me there (so > I can be sure that I don't realize 500 miles into the trip that I've been > driving toward L.A
Re: [openstack-dev] [Neutron][LBaaS]SSL and L7 conent switching APIs
Hi, The work to design the APIs concerning L7 content switching and SSL termination has started a bit before the Icehouse summit, it involved the ML in a very active fashion. The ML was silent on this because we have completed the discussion and moved to implementation. We got to a very advanced state in completing the code which got stopped due to the discussion about the core model (VIPs, Pools, etc.) The blue prints WIKIs and code are public (https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules and https://blueprints.launchpad.net/neutron/+spec/lbaas-ssl-termination ). Please take the time to review and discuss on ML if something is missing so we can talk about this at the summit. -Sam. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
Hi Eugene, Apologies for the delay in my response. It took me a while to figure out how to say what I wanted to say here as diplomatically as possible. In the end, I decided I couldn't be diplomatic about some of the things that I think needed to be said. I don't play games of politics very well at the best of times, so I do apologize that I will undoubtedly offend some of you with what I say in this e-mail. So just to get this off my chest, here's the elephant in the room I think needs to be addressed up front: Prior to last Thursday morning's IRC meeting, for the last couple of months we've been having a spirited and productive discussion around both user requirements, operator requirements, use cases, definitions of terms, product roadmap and api and object model revisions all having to do with Neutron LBaaS. These discussions have mostly been on the mailing list, with supplemental materials created on the OpenStack wiki, on google documents, and google spreadsheets. On occasion, references to blueprint documents have been made, but little discussion of these blueprints has been happening, and certainly not among the people on the mailing list. (Most of the stuff in the blueprints is just referencing mailing list discussions, or gerrit "discussions" where the only things commenting are CI systems anyway.) Further, the IRC meetings have usually been too short to get much done, and sub-project leadership has specifically been encouraging follow-up discussions to happen on the mailing list. A lot of good things have come from the discussion including, as far as I can tell, the first-ever actual feature usage data survey from operators' user bases. (As far as I can tell prior to this, decisions about product direction prior to this were being made based on what "someone thinks we'll need" instead of what end-users are asking for and operators are actually doing.) I believe part of the reason we've seen the amount of enthusiasm we have, as well as the re-involvement of organizations that had previously "gone off to do their own thing" as far as load balancing is concerned is *because* this discussion has been no-holds barred, no suggestion is off the table, and no opinion unheard. Ideas have stood on their own merit. As of Thursday morning, however, I suddenly see a huge re-emphasis on moving back to using the blueprint system, using gerrit, and otherwise forcing this discussion back into the usual "Neutron workflow" (which is neither friendly to newcomers, nor, as far as I can tell, really very useful for discussing potentially sweeping changes-- incremental changes, sure, but what if we really need to rebuild a big chunk of this from the ground up? How does that discussion happen in such a granular system? What is the point of having code-level discussions when the higher level design is what is off?) Further, I'm detecting an air both in that IRC meeting and in your response to my API proposal below that certain things are "off the table" for discussion. Specifically, I'm detecting pressure from, well, you apparently, that features like L7 and SSL were decided upon months ago, that work is already well underway on these features, and therefore the window has already closed on changing direction for Juno. (Nevermind the fact that we've only seen serious participation from so many cloud providers in the last 4 weeks, and nevermind the fact that the usage survey shows that development priorities for this project are clearly off.) Granted, I understand that a system for coordinating so many contributors (blueprint and gerrit) is necessary to make forward progress. What I have a problem with is the sudden and shocking nature with which this participation is now apparently being forced as an attempt to stifle the discussion that has been going on (and which, I think, has been enormously productive). In contemplating "why now?" and "why like this?" for the timing of this, I can only make two possible guesses as to the motivation: 1. I'm guessing Neutron LBaaS is suddenly getting pressure from Neutron core to "get people in line," or none of the changes we're proposing will be approved. And if Neutron LBaaS needs the cooperation of Neutron core in order to get features pushed through, then the LBaaS sub-project is stuck in the mud at the whim of Neutron core leadership. Comments to the effect of "we're generating so much documentation and material so quickly that nobody in the main neutron project can keep up" as made in the IRC meeting, and the fact that we've had many object model proposals rejected by Neutron core with rather vague justification seem to lend credibility to this guess. The only thing I'll point out here is that if you try to put the brakes on this literally right after we suddenly have the willing and enthusiastic participation of so many big players in this space, what makes you think they won't take displeasure at this dictatorial approach to sub project leadership and go off to do
