Re: [openstack-dev] [Storlets] Swift copy middlleware
wrote on 16/05/2016 04:32:58 AM: > From: > To: > Date: 16/05/2016 04:36 AM > Subject: Re: [openstack-dev] [Storlets] Swift copy middlleware > > > I agree with Kota, and I think this is the easiest way to fix the problem. > I noticed that placing storlets_middleware outside copy may require > some changes about slo handling, > because now it is assumed that storlets_middleware is placed > "inside" slo, right? > (I noticed this just after sending my previous e-mail :-( ) > > I think we had better make sure about what should be fixed in each > solutions, at this time. > Agree. Here is what I see at a high level: Option 1: Putting the storlet middleware at the left of the copy middleware: - Minimal code changes. We do need to take care of the utility Functions check_copy_from_header and check_destination_header I think are now private to the copy middleware. - Have some duplicate with the copy middleware, unless we can use it as "an API" Option 2: Leave the middleware where it is, and make sure we do not execute the storlet in both the get and the put. - Relies on internal perhaps not documented and not backwards Compatible way to determine that the GET/PUT are copy middleware generated. Personally, I prefer option 2, but need to better understand what We are relying on for knowing the GET/PUT are generated by the copy Middleware. __ 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] [tc] [all] [glance] On operating a high throughput or otherwise team
Erno, TBH, you clearly haven't taken the time to understand what I meant to say here. Clearly, thus self-justifying my email about ML discussions. Hence, I do not want to spend too much time writing a response. There are a few things that struck, so comments inline. Also, I do not want to comment on your response to Chris' feedback -- his feedback is something I need more time to internalize. On 5/15/16 12:45 PM, Erno Kuvaja wrote: > I'm not sure why I'm spending one of these very rare sunny Sunday > afternoons on this but perhaps it's just important enough. > > Thanks Nikhil and Chris for such a verbal start for the discussion. I > will at least try to keep my part shorter. I will quote both of your > e-mails by name from which one it came from. > > Nikhil: > """Lately I have been involved in discussions that have resulted in giving > a wrong idea to the approach I take in operating the (Glance) team(s).""" > > At very start, please change your approach and start leading the team > instead of trying to operate it. This is community rather than huge > team in big enterprise and our contributors have different > corporational and cultural backgrounds and reasonings why they are > contributing into it, not organization with resources in PTLs disposal. > Firstly, here's a definition of leadership from a _wiki_ like page ( http://www.businessdictionary.com/definition/leadership.html ) see point # 4 under the involvement. Think about it more before commenting. Secondly, this email is not about leadership, this is about communication which is the most essential part of operations. If you did not get that part, I have no words. Since you agree this is a community, balance in the ecosystem is of prime importance. The way you maintain that is through operating it. Think about it more, and more, and more. > Nikhil: > """We are developing something that is usable, operationally friendly and > that it's easier to contribute & maintain but, many strong influencers > are missing on the most important need for OpenStack -- efficient way of > communication.""" > > With the community size of OpenStack spanning probably about every > timezone that has land we can communicate how much we ever want and > not reach everybody in time. After all the individual projects are > responsible for the release and providing that something that their > mission statement mandates. We can put all our efforts to communicate > being nice, friendly and easy but if we do not deliver we do not need > to do this for long. > > Nikhil: > """Also, many people like to work on the assumption that all the > tools of communication are equivalent or useful and there are no > side-effects of using them ever.""" > """I think people prefer to use ML a lot and I am not a great fan of the > same.""" > > This is great to recognize, now lets work on that and get the > expectations right. > Community wide the primary mean is the mailing list (and just perhaps > extending to specs and gerrit reviews). You don't like it, I don't > like it, but it's what we have to deal with. You haven't understood the bottom line here. Read my comments on the intent. > Secondary would be the more real time forums, namely IRC and design > summits. > Anything apart from that (yes; hangouts, bluejeans, midcycles are > great for building the team and filing out misunderstandings and > disagreements on individual level) is tertiary and worthless unless > used purely to bring the discussion to the primary media. This is the > only way to include the community asynchronous way without expecting > that 2/3 of the timezones needs to participate at inconvenient or > impossible times or find the funding to travel. > > Nikhil: > """Multi-cast medium of communication is more disruptive as it involves a > possibility of divergence from the topic, strongly polarizing opinions > due to the small possibility of catching of the intent. So, let us use > it 'judiciously' and preferably only as a newspaper.""" > > Seriously? If you want to publish in unidirectional manner, please > write a blog* like everyone else, but don't try to transform our > primary communications to such. Thankfully this opening was already > start for right direction. > * "BLOGGING; Never Before Have So Many People with So Little to Say > Said So Much to So Few." > - Despair, Inc. http://despair.com/products/blogging > > Nikhil: > """Though, I think every team needs to be synchronous about their approach > and not use delayed mechanisms like ML or gerrit.""" > > 10AM IST (UTC +0100) seems to be good time, half an hour every morning > should be fine to get me synced up after I've gone through the > pressing stuff from e-mails and 17:00 IST (UTC +0100) is probably good > time for another to keep us in synchronous. I'm sure the rest of the > team is willing to sacrifice half an hour of their mornings and > evenings for same. Hopefully you can facilitate, or perhaps the > synchronous approach is not that good after a
Re: [openstack-dev] [Congress] Nominating Anusha Ramineni and Eric Kao for core reviewer
+1. On 2016/05/14 9:16, Tim Hinrichs wrote: Hi all, I'm writing to nominate Anusha Ramineni and Eric Kao as Congress core reviewers. Both Anusha and Eric have been active and consistent contributors in terms of code, reviewing, and interacting with the community since September--for all of Mitaka and a few months before that. Anusha was so active in Mitaka that she committed more code than the other core reviewers, and wrote the 2nd most reviews over all. She took on stable-maintenance, is the first person to fix gate breakages, and manages to keep Congress synchronized with the rest of the OpenStack projects we depend on. She's taken on numerous tasks in migrating to our new distributed architecture, especially around the API. She manages to write honest yet kind reviews, and has discussions at the same level as the rest of the cores. Eric also committed more code in Mitaka than the other core reviewers. He has demonstrated his ability to design and implement solutions and work well with the community through the review process. In particular, he completed the Congress migration to Python3 (including dealing with the antlr grammar), worked through difficult problems with the new distributed architecture (e.g. message sequencing, test-nondeterminism), and is now designing an HA deployment architecture. His reviews and responses are both thoughtful and thorough and engages in discussions at the same level as the rest of the core team. Anusha and Eric: it's great working with you both! Tim __ 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 -- 室井 雅仁(Masahito MUROI) Software Innovation Center, NTT Tel: +81-422-59-4539 __ 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] [Storlets] Swift copy middlleware
> I agree with Kota, and I think this is the easiest way to fix the problem. I noticed that placing storlets_middleware outside copy may require some changes about slo handling, because now it is assumed that storlets_middleware is placed "inside" slo, right? (I noticed this just after sending my previous e-mail :-( ) I think we had better make sure about what should be fixed in each solutions, at this time. Thanks, Takashi -Original Message- From: kajina...@nttdata.co.jp [mailto:kajina...@nttdata.co.jp] Sent: Monday, May 16, 2016 10:20 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Storlets] Swift copy middlleware Hi Eran and Kota, > For temprary, that would work but I thought we could (*not sure*) fix the > issue just replace the order of pipeline, right? (i.e. storlets handler > should be the left of copy middleware) That is because the storlets middlware > have the logic to translate COPY/PUT(X-COPY-FROM) into GET(no storelets > running)/PUT(execute at Proxy). If it happens before the request reaching to > copy middleware, it looks like just PUT or GET at copy middleware itself (so > nothing to oparate there). I agree with Kota, and I think this is the easiest way to fix the problem. On the other hand, it's not efficient that Storlets has its original implementation about COPY inside it, which is very similar to copy middleware. As we discussed at Bristol, we had better make Storlets get rid of its original implementation and reuse ServerSideComyMiddleware or ServerSideCopyWebContext in copy middleware, to reduce that duplicated work, as the next step. # I need a deep dive about copy middleware patch, now. > I believe that for Storlets what would happen is that both PUT and GET > cause a storlet invocation, where in fact we want that invocation to > happen Eithrer in the GET or in the PUT (but not both) I believe that > if we are OK with running the storlet on the put, we can use The > swift_source SSC as an indicator that the get is generated from the > Copy middleware and disregard the X-Run-Storlet header. I also like this idea, if possible. Dealing with COPY only in the one point (in copy middleware) looks better, because it enables us to maintain the functionality more easily. Thanks, Takashi -Original Message- From: Kota TSUYUZAKI [mailto:tsuyuzaki.k...@lab.ntt.co.jp] Sent: Monday, May 16, 2016 9:25 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Storlets] Swift copy middlleware Hey Eran, This is what I was concerning in Bristol Hackathon :/ > As a quick and temporary resolution I have changes the tox.ini > dependency to be 2.7.0 Instead of master. We still need, however, to > port the code accordingly, For temprary, that would work but I thought we could (*not sure*) fix the issue just replace the order of pipeline, right? (i.e. storlets handler should be the left of copy middleware) That is because the storlets middlware have the logic to translate COPY/PUT(X-COPY-FROM) into GET(no storelets running)/PUT(execute at Proxy). If it happens before the request reaching to copy middleware, it looks like just PUT or GET at copy middleware itself (so nothing to oparate there). I'll start to make sure my thought in this week but thanks to raise a flag to the community :) Thanks, Kota (2016/05/16 3:42), Eran Rom wrote: > Today the Swift team has merged copy middleware - congrats! > For us, however, it breaks the copy code path, which in fact can get > much simpler now. > > As a quick and temporary resolution I have changes the tox.ini > dependency to be 2.7.0 Instead of master. We still need, however, to > port the code accordingly, > > Here is a suggestion: > The copy middleware will process the COPY / PUT & X-Copy-From and will: > 1. Do a GET of the source object > 2. Do a PUT to the target object > > I believe that for Storlets what would happen is that both PUT and GET > cause a storlet invocation, where in fact we want that invocation to > happen Eithrer in the GET or in the PUT (but not both) I believe that > if we are OK with running the storlet on the put, we can use The > swift_source SSC as an indicator that the get is generated from the > Copy middleware and disregard the X-Run-Storlet header. > > Thoughts? > > Thanks, > Eran > > > > > > __ > 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] [Storlets] Swift copy middlleware
Hi Eran and Kota, > For temprary, that would work but I thought we could (*not sure*) fix the > issue just replace the order of pipeline, right? (i.e. storlets handler > should be the left of copy middleware) That is because the storlets middlware > have the logic to translate COPY/PUT(X-COPY-FROM) into GET(no storelets > running)/PUT(execute at Proxy). If it happens before the request reaching to > copy middleware, it looks like just PUT or GET at copy middleware itself (so > nothing to oparate there). I agree with Kota, and I think this is the easiest way to fix the problem. On the other hand, it's not efficient that Storlets has its original implementation about COPY inside it, which is very similar to copy middleware. As we discussed at Bristol, we had better make Storlets get rid of its original implementation and reuse ServerSideComyMiddleware or ServerSideCopyWebContext in copy middleware, to reduce that duplicated work, as the next step. # I need a deep dive about copy middleware patch, now. > I believe that for Storlets what would happen is that both PUT and GET > cause a storlet invocation, where in fact we want that invocation to > happen Eithrer in the GET or in the PUT (but not both) I believe that > if we are OK with running the storlet on the put, we can use The > swift_source SSC as an indicator that the get is generated from the > Copy middleware and disregard the X-Run-Storlet header. I also like this idea, if possible. Dealing with COPY only in the one point (in copy middleware) looks better, because it enables us to maintain the functionality more easily. Thanks, Takashi -Original Message- From: Kota TSUYUZAKI [mailto:tsuyuzaki.k...@lab.ntt.co.jp] Sent: Monday, May 16, 2016 9:25 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Storlets] Swift copy middlleware Hey Eran, This is what I was concerning in Bristol Hackathon :/ > As a quick and temporary resolution I have changes the tox.ini > dependency to be 2.7.0 Instead of master. We still need, however, to > port the code accordingly, For temprary, that would work but I thought we could (*not sure*) fix the issue just replace the order of pipeline, right? (i.e. storlets handler should be the left of copy middleware) That is because the storlets middlware have the logic to translate COPY/PUT(X-COPY-FROM) into GET(no storelets running)/PUT(execute at Proxy). If it happens before the request reaching to copy middleware, it looks like just PUT or GET at copy middleware itself (so nothing to oparate there). I'll start to make sure my thought in this week but thanks to raise a flag to the community :) Thanks, Kota (2016/05/16 3:42), Eran Rom wrote: > Today the Swift team has merged copy middleware - congrats! > For us, however, it breaks the copy code path, which in fact can get > much simpler now. > > As a quick and temporary resolution I have changes the tox.ini > dependency to be 2.7.0 Instead of master. We still need, however, to > port the code accordingly, > > Here is a suggestion: > The copy middleware will process the COPY / PUT & X-Copy-From and will: > 1. Do a GET of the source object > 2. Do a PUT to the target object > > I believe that for Storlets what would happen is that both PUT and GET > cause a storlet invocation, where in fact we want that invocation to > happen Eithrer in the GET or in the PUT (but not both) I believe that > if we are OK with running the storlet on the put, we can use The > swift_source SSC as an indicator that the get is generated from the > Copy middleware and disregard the X-Run-Storlet header. > > Thoughts? > > Thanks, > Eran > > > > > > __ > 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] [magnum] Discuss the idea of manually managing the bay nodes
On Sun, May 15, 2016 at 10:49:39PM +, Hongbin Lu wrote: > Hi all, > > This is a continued discussion from the design summit. For recap, Magnum > manages bay nodes by using ResourceGroup from Heat. This approach works but > it is infeasible to manage the heterogeneity across bay nodes, which is a > frequently demanded feature. As an example, there is a request to provision > bay nodes across availability zones [1]. There is another request to > provision bay nodes with different set of flavors [2]. For the request > features above, ResourceGroup won't work very well. > > The proposal is to remove the usage of ResourceGroup and manually create Heat > stack for each bay nodes. For example, for creating a cluster with 2 masters > and 3 minions, Magnum is going to manage 6 Heat stacks (instead of 1 big Heat > stack as right now): > * A kube cluster stack that manages the global resources > * Two kube master stacks that manage the two master nodes > * Three kube minion stacks that manage the three minion nodes > > The proposal might require an additional API endpoint to manage nodes or a > group of nodes. For example: > $ magnum nodegroup-create --bay XXX --flavor m1.small --count 2 > --availability-zone us-east-1 > $ magnum nodegroup-create --bay XXX --flavor m1.medium --count 3 > --availability-zone us-east-2 ... > > Thoughts? > > [1] https://blueprints.launchpad.net/magnum/+spec/magnum-availability-zones > [2] https://blueprints.launchpad.net/magnum/+spec/support-multiple-flavor > > Best regards, > Hongbin Seriously, I'm suggesting Magnum to use Senlin for this task. Senlin has an API that provides rich operations you will need to manage a cluster of things, where the "thing" here can be a Heat stack or a Nova server. A "thing" is modeled as a Profile in Senlin, so it is pretty easy and straightforward for Magnum to feed in the HOT templates (possibly with parameters and environments?) to Senlin and offload the group management task from Magnum. Speaking of cross-AZ placement, Senlin has a policy plugin for this purpose already. Regarding bay nodes bearing different set of flavors, Senlin also permits that. I believe by offloading these operations to Senlin, Magnum can remain focusing on getting COE management and get it done well. I also believe that Senlin team will be very responsive to your requirements if there are needs to tune the Senlin API/policy/mechanism. Regards, Qiming __ 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] [nova][neutron] Is it still valid/supported to create a network with a br- id?
On Sun, May 15, 2016 at 3:56 PM, Sean M. Collins wrote: > Matt Riedemann wrote: >> The nova create-server API allows passing a network id that's prefixed with >> br- [1]. That was added due to this bug from Folsom [2]. >> >> I'm wondering if that's still valid? Looking at the network.id data model in >> Neutron it doesn't look like it would be [3]. > > Wow. That bug is awful. Network IDs should be UUIDs and ONLY UUIDs. I agree, I'm having flashbacks to the dark days right now > Just because some vendor plugin decides that their going to break the > Networking API contract and define their own ID scheme, > doesn't mean that we should fix it to help them. The networking API at the time (quantum 1.0/1.1, the 2.0 that we know and loath today was added about 20 days prior, but not yet stable, or deployed anywhere), used identifiers that were opaque strings. The docs used uuid's as the identifiers for the examples, but the api punted on validation to individual plugins. > That commit shouldn't have been accepted into Nova, Obviously I disagree, see below for the history. > and I don't think > that we should support anything but a UUID for a network id. Period. Which is why this was fixed in the 2.0 api by checking the network identifer for uuid-ness. This was the result of the fun of shoe-horning every vendor's backend into quantum, without quantum being the authority. Not to mention that the reason it was prefixed with `br-` in the first place was established in the nova network api. It exposed out the bridge that implemented the network in the nova api, So the return from list networks on the nova side would list out things like br-public, br-int, etc. This got carried over into the quantum api when the project was founded. I think we can all agree that this compat shim should be dropped now that the v2.0 neutron api is merged and used (for quite sometime). Happy Hacking! 7-11 __ 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] [tricircle] [Blueprint] Stateless design definition
Hi, Shinobu, You found a bug, yeah. The design has been moved to the master branch, so the description: 'Note: Stateless proposal is working on the “experiment” branch:' 'https://github.com/openstack/tricircle/tree/experiment' Just been removed from the design blueprint as you mentioned. Best Regards Chaoyi Huang ( Joe Huang ) -Original Message- From: Shinobu Kinjo [mailto:shinobu...@gmail.com] Sent: Saturday, May 14, 2016 2:37 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [tricircle] [Blueprint] Stateless design definition Hi Team, In page1, we define "stateless design" as follows: Note: Stateless proposal is working on the “experiment” branch: https://github.com/openstack/tricircle/tree/experiment But, in section 7, we define this design as follows: A PoC was done to verify the feasibility of stateless architecture. Since the feedback of this PoC was very positive, sorce codes of the stateless design was moved to the master branch of the Tricircle git repository Since that, I am thinking of deleting former description (definition in page1). Make sense? Cheers, Shinobu -- Email: shin...@linux.com shin...@redhat.com __ 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] [Storlets] Swift copy middlleware
Hey Eran, This is what I was concerning in Bristol Hackathon :/ > As a quick and temporary resolution I have changes the tox.ini dependency > to be 2.7.0 > Instead of master. We still need, however, to port the code accordingly, For temprary, that would work but I thought we could (*not sure*) fix the issue just replace the order of pipeline, right? (i.e. storlets handler should be the left of copy middleware) That is because the storlets middlware have the logic to translate COPY/PUT(X-COPY-FROM) into GET(no storelets running)/PUT(execute at Proxy). If it happens before the request reaching to copy middleware, it looks like just PUT or GET at copy middleware itself (so nothing to oparate there). I'll start to make sure my thought in this week but thanks to raise a flag to the community :) Thanks, Kota (2016/05/16 3:42), Eran Rom wrote: > Today the Swift team has merged copy middleware - congrats! > For us, however, it breaks the copy code path, which in fact can get much > simpler now. > > As a quick and temporary resolution I have changes the tox.ini dependency > to be 2.7.0 > Instead of master. We still need, however, to port the code accordingly, > > Here is a suggestion: > The copy middleware will process the COPY / PUT & X-Copy-From and will: > 1. Do a GET of the source object > 2. Do a PUT to the target object > > I believe that for Storlets what would happen is that both PUT and GET > cause a storlet invocation, where in fact we want that invocation to > happen > Eithrer in the GET or in the PUT (but not both) > I believe that if we are OK with running the storlet on the put, we can > use > The swift_source SSC as an indicator that the get is generated from the > Copy middleware and disregard the X-Run-Storlet header. > > Thoughts? > > Thanks, > Eran > > > > > > __ > 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] [magnum] Discuss the idea of manually managing the bay nodes
Hi, I think, user also want to specify the deleting node. So we should manage “node” individually. For example: $ magnum node-create —bay … $ magnum node-list —bay $ magnum node-delete $NODE_UUID Anyway, if magnum want to manage a lifecycle of container infrastructure. This feature is necessary. Thanks -yuanying 2016年5月16日(月) 7:50 Hongbin Lu : > Hi all, > > > > This is a continued discussion from the design summit. For recap, Magnum > manages bay nodes by using ResourceGroup from Heat. This approach works but > it is infeasible to manage the heterogeneity across bay nodes, which is a > frequently demanded feature. As an example, there is a request to provision > bay nodes across availability zones [1]. There is another request to > provision bay nodes with different set of flavors [2]. For the request > features above, ResourceGroup won’t work very well. > > > > The proposal is to remove the usage of ResourceGroup and manually create > Heat stack for each bay nodes. For example, for creating a cluster with 2 > masters and 3 minions, Magnum is going to manage 6 Heat stacks (instead of > 1 big Heat stack as right now): > > * A kube cluster stack that manages the global resources > > * Two kube master stacks that manage the two master nodes > > * Three kube minion stacks that manage the three minion nodes > > > > The proposal might require an additional API endpoint to manage nodes or a > group of nodes. For example: > > $ magnum nodegroup-create --bay XXX --flavor m1.small --count 2 > --availability-zone us-east-1 …. > > $ magnum nodegroup-create --bay XXX --flavor m1.medium --count 3 > --availability-zone us-east-2 … > > > > Thoughts? > > > > [1] > https://blueprints.launchpad.net/magnum/+spec/magnum-availability-zones > > [2] https://blueprints.launchpad.net/magnum/+spec/support-multiple-flavor > > > > Best regards, > > Hongbin > __ > 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] [cross-project][infra][keystone] Moving towards a Identity v3-only on Devstack - Next Steps
On 13 May 2016 at 04:15, Sean Dague wrote: > On 05/12/2016 01:47 PM, Morgan Fainberg wrote: > > This also comes back to the conversation at the summit. We need to > > propose the timeline to turn over for V3 (regardless of > > voting/non-voting today) so that it is possible to set the timeline that > > is expected for everything to get fixed (and where we are > > expecting/planning to stop reverting while focusing on fixing the > > v3-only changes). > > > > I am going to ask the Keystone team to set forth the timeline and commit > > to getting the pieces in order so that we can make v3-only voting rather > > than playing the propose/revert game we're currently doing. A proposed > > timeline and gameplan will only help at this point. > > A timeline would be good (proposed below), but there are also other bits > of the approach we should consider. > That was my job to get sent to the TC. I'll get on it. > > I would expect, for instance, > gate-tempest-dsvm-neutron-identity-v3-only-full to be on keystone, and > it does not appear to be. Is there a reason why? > To test that keystone works with keystone v3? Otherwise what you're doing is making it so that keystone's gate breaks every time neutron does something that's not v3 compatible which brings it to our attention but otherwise just gets in the way. The hope was to push the check job failure back to the service so that its not purely keystone's job to run around and fix all the other services when the incompatible change is discovered. > > With that on keystone, devstack-gate, devstack, tempest the integrated > space should be pretty well covered. There really is no need to also go > stick this on glance, nova, cinder, neutron, swift I don't think, > because they only really use keystone through pretty defined interfaces. > Initially i would have agreed, and there has been a voting job on devstack with keystone v3 only that proves that all of these services can work together for at least a cycle. Where we got stung was all the plugins and configuration options used in these services that don't get tested by that integrated gate job. The hope was that by pushing these jobs out to the services we would get more coverage of the service specific configurations - but I can see that might not be working. > Then some strategic use of nv jobs on things we know would have some > additional interactions here (because we know they are currently broken > or they do interesting things) like ironic, heat, trove, would probably > be pretty useful. > > That starts building up the list of known breaks the keystone folks are > tracking, which should get a drum beat every week in email about > outstanding issues, and issues fixed. > > The goal of gate-tempest-dsvm-neutron-identity-v3-only-full should not > be for that to be voting, ever. It should be to use that as a good > indicator that changing the default in devstack (and thus in the > majority of upstream jobs) to not ever enable v2. > > Because of how v3 support exists in projects (largely hidden behind > keystoneauth), it is really unlikely to rando regress once fixed. There > just aren't that many knobs a project has that would make that happen. > So I think we can make forward progress without a voting backstop until > we get to a point where we can just throw the big red switch (with > warning) on a Monday (probably early in the Otaca cycle) and say there > you go. It's now the project job to handle it. And they'll all get fair > warning for the month prior to the big red switch. > I agree. Very early in the Otaca cycle is also the timeframe we had discussed at summit so it looks like there is a good consensus there and i'll get that proposal to TC this week. For now we maintain the v3-only jobs as non-voting and we continue to push the changes particularly to projects that are not tested in the default devstack integrated gate test. PS. I assume i'm right in assuming it's just impossible/infeasable to have project-config changes determine all the jobs that are affected by a change and run those as the project-config gate. It seems like one of the last few places where we can commit something that breaks everyone and have never noticed. -Sean > > -- > Sean Dague > http://dague.net > > __ > 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] [nova][neutron] Is it still valid/supported to create a network with a br- id?
> On May 15, 2016, at 10:17 AM, Matt Riedemann > wrote: > >> On 5/15/2016 10:56 AM, Sean M. Collins wrote: >> Matt Riedemann wrote: >>> The nova create-server API allows passing a network id that's prefixed with >>> br- [1]. That was added due to this bug from Folsom [2]. >>> >>> I'm wondering if that's still valid? Looking at the network.id data model in >>> Neutron it doesn't look like it would be [3]. >> >> Wow. That bug is awful. Network IDs should be UUIDs and ONLY UUIDs. >> >> Just because some vendor plugin decides that their going to break the >> Networking API contract and define their own ID scheme, >> doesn't mean that we should fix it to help them. >> >> That commit shouldn't have been accepted into Nova, and I don't think >> that we should support anything but a UUID for a network id. Period. > > Yeah, I agree. Remember, this was Folsom, when Neutron was a young and brash > Quantum. > > I was just trying to sort out if there is still anything out there in the > stadium that relies on this working. If not, I'll microversion it out of > support for the Nova API when we add support for auto-allocated-topology. I agree with Sean. Even if there is anything that relies on non uuid, it's totally fair to break it. Doug > > -- > > Thanks, > > Matt Riedemann > > > __ > 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] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback
> On 14 May 2016, at 5:36 AM, Flavio Percoco wrote: > >> On 5/12/16 9:20 PM, Sam Morrison wrote: >> >> We find glance registry quite useful. Have a central glance-registry api >> is useful when you have multiple datacenters all with glance-apis and >> talking back to a central registry service. I guess they could all talk back >> to the central DB server but currently that would be over the public >> Internet for us. Not really an issue, we can work around it. >> >> The major thing that the registry has given us has been rolling upgrades. >> We have been able to upgrade our registry first then one by one upgrade our >> API servers (we have about 15 glance-apis) > > I'm curious to know how you did this upgrade, though. Did you shutdown your > registry nodes, upgraded the database and then re-started them? Did you > upgraded > one registry node at a time? > > I'm asking because, as far as I can tell, the strategy you used for upgrading > the registry nodes is the one you would use to upgrade the glance-api nodes > today. Shutting down all registry nodes would live you with unusable > glance-api > nodes anyway so I'd assume you did a partial upgrade or something similar to > that. Yeah, if glance supported versioned objects then yes this would be great. We only have 3 glance-registries and so upgrading these first is a lot easier than upgrading all ~15 of our glance-apis at once. Sam __ 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] [magnum] Discuss the idea of manually managing the bay nodes
Hi all, This is a continued discussion from the design summit. For recap, Magnum manages bay nodes by using ResourceGroup from Heat. This approach works but it is infeasible to manage the heterogeneity across bay nodes, which is a frequently demanded feature. As an example, there is a request to provision bay nodes across availability zones [1]. There is another request to provision bay nodes with different set of flavors [2]. For the request features above, ResourceGroup won't work very well. The proposal is to remove the usage of ResourceGroup and manually create Heat stack for each bay nodes. For example, for creating a cluster with 2 masters and 3 minions, Magnum is going to manage 6 Heat stacks (instead of 1 big Heat stack as right now): * A kube cluster stack that manages the global resources * Two kube master stacks that manage the two master nodes * Three kube minion stacks that manage the three minion nodes The proposal might require an additional API endpoint to manage nodes or a group of nodes. For example: $ magnum nodegroup-create --bay XXX --flavor m1.small --count 2 --availability-zone us-east-1 $ magnum nodegroup-create --bay XXX --flavor m1.medium --count 3 --availability-zone us-east-2 ... Thoughts? [1] https://blueprints.launchpad.net/magnum/+spec/magnum-availability-zones [2] https://blueprints.launchpad.net/magnum/+spec/support-multiple-flavor Best regards, Hongbin __ 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] [Storlets] Swift copy middlleware
Today the Swift team has merged copy middleware - congrats! For us, however, it breaks the copy code path, which in fact can get much simpler now. As a quick and temporary resolution I have changes the tox.ini dependency to be 2.7.0 Instead of master. We still need, however, to port the code accordingly, Here is a suggestion: The copy middleware will process the COPY / PUT & X-Copy-From and will: 1. Do a GET of the source object 2. Do a PUT to the target object I believe that for Storlets what would happen is that both PUT and GET cause a storlet invocation, where in fact we want that invocation to happen Eithrer in the GET or in the PUT (but not both) I believe that if we are OK with running the storlet on the put, we can use The swift_source SSC as an indicator that the get is generated from the Copy middleware and disregard the X-Run-Storlet header. Thoughts? Thanks, Eran __ 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] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary
On 16:06 May 14, Nikhil Komawar wrote: > On 5/14/16 2:35 PM, Mike Perez wrote: > > Reading this thread, Nikhil who is speaking for the quota team is worried > > about > > the amount of overhead caused by governance, instead of first focusing on > > making something actually exist. I see quite a few people in this thread > > speaking up that it should be part of the big tent either standalone or oslo > > lib. > > > > I can't speak for the Oslo folks, but as a member of the TC here are the > > requirements for the standalone route [1]. You would propose an agenda item > > to > > the TC, and we would review that the project meets those requirements. > > Considering the project does Open Design and has an Open Community - my > > guesses > > on "probably would be followed" is Open Development and Open Source since we > > don't have anything but a specification that exists to go off of. > > > > It sounds like the biggest hang up in going the oslo route is the oslo > > spec. So > > question to the oslo folks, would you be interested in reviewing the > > cross-project specification and allowing to be an oslo lib? That way the > > team > > can focus on working on the library, and the community is happy it's part of > > OpenStack already. > > > > > > > > Thanks Mike for helping us move forward. > > After having been suggested yesterday, I have added this agenda item for > the Oslo team meeting to get the answers > https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting . > > Also, can you please re-reference as the link did not come through? [1] - http://governance.openstack.org/reference/new-projects-requirements.html -- Mike Perez __ 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] [cross-project][quotas][delimiter]My thoughts on how Delimiter uses generation-id for sequencing
Amrith, your code in SQL statements below is identical to mine in Python with two exceptions that make your code less scalable and more problematic: 1) You have your generation on a "resources" table instead of a "consumers" table, which means you have an extremely high likelihood of needing to retry your UPDATE statements and SELECTs because all consumers in the system share a single serialization point (the resources.generation field for the resource class). 2) The Delimiter library (i.e. "the quota system") *should not own resources*. Resources are owned by the individual services themselves, not some separate quota library. The quota library does not have knowledge of nor access to the allocations, inventories, or resource_providers database tables. In fact, the quota library should not assume *anything* about how usage and inventory information is stored or even that it is in a transactional RDBMS. The Python code I used as an example was deliberately trying to keep the quota library as a consistent interface for how to deal with the check-consume pattern without needing the quota library to know anything at all about how the actual resource usage and inventory information was stored. Best, -jay On 05/15/2016 01:55 PM, Amrith Kumar wrote: Qijing, As a simple example, let's assume that I use this schema. I realize that it does not provide the resource provider thing that Jay talked about in a previous (couple of weeks ago) email, but I believe that it serves to illustrate how the generations are used. create table resources ( resource_id varchar(36) primary key, resourcevarchar(32), generation integer ) engine=innodb; create table allocations ( consumer_id varchar(36), resource_id varchar(36), amountinteger, foreign key (resource_id) references resources(resource_id) ) engine=innodb; I've also populated it with this sample data. insert into resources values ('b587d300-1a94-11e6-8478-000c291e9f7b', 'memory', 3); insert into resources values ('b587ddb1-1a94-11e6-8478-000c291e9f7b', 'cpu', 3); insert into resources values ('b587de7d-1a94-11e6-8478-000c291e9f7b', 'disk', 3); insert into allocations values ( '61412e76-1a95-11e6-8478-000c291e9f7b', 'b587d300-1a94-11e6-8478-000c291e9f7b', 1024 ), ( '61412e76-1a95-11e6-8478-000c291e9f7b', 'b587ddb1-1a94-11e6-8478-000c291e9f7b',6 ), ( '61412e76-1a95-11e6-8478-000c291e9f7b', 'b587de7d-1a94-11e6-8478-000c291e9f7b',10240 ), ( '61412e76-1a95-11e6-8478-000c291e9f7b', 'b587d300-1a94-11e6-8478-000c291e9f7b', 2048 ), ( '61412e76-1a95-11e6-8478-000c291e9f7b', 'b587ddb1-1a94-11e6-8478-000c291e9f7b',2 ), ( '61412e76-1a95-11e6-8478-000c291e9f7b', 'b587de7d-1a94-11e6-8478-000c291e9f7b', 512 ), ( 'be03c4f7-1a96-11e6-8478-000c291e9f7b', 'b587d300-1a94-11e6-8478-000c291e9f7b', 2048 ), ( 'be03c4f7-1a96-11e6-8478-000c291e9f7b', 'b587ddb1-1a94-11e6-8478-000c291e9f7b',2 ), ( 'be03c4f7-1a96-11e6-8478-000c291e9f7b', 'b587de7d-1a94-11e6-8478-000c291e9f7b', 512 ); That gives me this as a starting point. mysql> select distinct resource from resources; +--+ | resource | +--+ | memory | | cpu | | disk | +--+ 3 rows in set (0.00 sec) mysql> select distinct consumer_id from allocations; +--+ | consumer_id | +--+ | 61412e76-1a95-11e6-8478-000c291e9f7b | | be03c4f7-1a96-11e6-8478-000c291e9f7b | +--+ 2 rows in set (0.00 sec) - Assume that the consumer (61412e76-1a95-11e6-8478-000c291e9f7b) has a CPU quota of 12, we can see that the user has not yet hit his quota. mysql> select sum(amount) from resources, allocations where resources.resource_id = allocations.resource_id and resources.resource = 'cpu' and consumer_id = '61412e76-1a95-11e6-8478-000c291e9f7b'; +-+ | sum(amount) | +-+ | 8 | +-+ 1 row in set (0.00 sec) In this situation, assume that this consumer wishes to consume two CPU's. Here's what quota library would do. The caller of quota library would provide something like: consumer_id: 61412e76-1a95-11e6-8478-000c291e9f7b resource: cpu quota: 12 request: 2 Here's what the quota library would do. mysql> select resources.resource_id, generation, sum(amount) from resources, allocations where resources.resource_id = allocations.resource_id and resources.resource = 'cpu' and consumer_id = '61412e76-1a95-11e6-8478-000c291e9f7b' group by resources.resource_id, generation\g +--++-+ | resource_id | generation | sum(amount) | +--++-+ | b587ddb1-1a94-11e6-8478-000c291e9f7b | 3 | 8 | +--++-
Re: [openstack-dev] [cross-project][quotas][delimiter]My thoughts on how Delimiter uses generation-id for sequencing
Qijing, As a simple example, let's assume that I use this schema. I realize that it does not provide the resource provider thing that Jay talked about in a previous (couple of weeks ago) email, but I believe that it serves to illustrate how the generations are used. create table resources ( resource_id varchar(36) primary key, resourcevarchar(32), generation integer ) engine=innodb; create table allocations ( consumer_id varchar(36), resource_id varchar(36), amountinteger, foreign key (resource_id) references resources(resource_id) ) engine=innodb; I've also populated it with this sample data. insert into resources values ('b587d300-1a94-11e6-8478-000c291e9f7b', 'memory', 3); insert into resources values ('b587ddb1-1a94-11e6-8478-000c291e9f7b', 'cpu', 3); insert into resources values ('b587de7d-1a94-11e6-8478-000c291e9f7b', 'disk', 3); insert into allocations values ( '61412e76-1a95-11e6-8478-000c291e9f7b', 'b587d300-1a94-11e6-8478-000c291e9f7b', 1024 ), ( '61412e76-1a95-11e6-8478-000c291e9f7b', 'b587ddb1-1a94-11e6-8478-000c291e9f7b',6 ), ( '61412e76-1a95-11e6-8478-000c291e9f7b', 'b587de7d-1a94-11e6-8478-000c291e9f7b',10240 ), ( '61412e76-1a95-11e6-8478-000c291e9f7b', 'b587d300-1a94-11e6-8478-000c291e9f7b', 2048 ), ( '61412e76-1a95-11e6-8478-000c291e9f7b', 'b587ddb1-1a94-11e6-8478-000c291e9f7b',2 ), ( '61412e76-1a95-11e6-8478-000c291e9f7b', 'b587de7d-1a94-11e6-8478-000c291e9f7b', 512 ), ( 'be03c4f7-1a96-11e6-8478-000c291e9f7b', 'b587d300-1a94-11e6-8478-000c291e9f7b', 2048 ), ( 'be03c4f7-1a96-11e6-8478-000c291e9f7b', 'b587ddb1-1a94-11e6-8478-000c291e9f7b',2 ), ( 'be03c4f7-1a96-11e6-8478-000c291e9f7b', 'b587de7d-1a94-11e6-8478-000c291e9f7b', 512 ); That gives me this as a starting point. mysql> select distinct resource from resources; +--+ | resource | +--+ | memory | | cpu | | disk | +--+ 3 rows in set (0.00 sec) mysql> select distinct consumer_id from allocations; +--+ | consumer_id | +--+ | 61412e76-1a95-11e6-8478-000c291e9f7b | | be03c4f7-1a96-11e6-8478-000c291e9f7b | +--+ 2 rows in set (0.00 sec) - Assume that the consumer (61412e76-1a95-11e6-8478-000c291e9f7b) has a CPU quota of 12, we can see that the user has not yet hit his quota. mysql> select sum(amount) from resources, allocations where resources.resource_id = allocations.resource_id and resources.resource = 'cpu' and consumer_id = '61412e76-1a95-11e6-8478-000c291e9f7b'; +-+ | sum(amount) | +-+ | 8 | +-+ 1 row in set (0.00 sec) In this situation, assume that this consumer wishes to consume two CPU's. Here's what quota library would do. The caller of quota library would provide something like: consumer_id: 61412e76-1a95-11e6-8478-000c291e9f7b resource: cpu quota: 12 request: 2 Here's what the quota library would do. mysql> select resources.resource_id, generation, sum(amount) from resources, allocations where resources.resource_id = allocations.resource_id and resources.resource = 'cpu' and consumer_id = '61412e76-1a95-11e6-8478-000c291e9f7b' group by resources.resource_id, generation\g +--++-+ | resource_id | generation | sum(amount) | +--++-+ | b587ddb1-1a94-11e6-8478-000c291e9f7b | 3 | 8 | +--++-+ 1 row in set (0.00 sec) -- it can now determine that the quota of 12 won't be violated by allocating two more. So it goes ahead and does this. mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> insert into allocations values ( '61412e76-1a95-11e6-8478-000c291e9f7b', 'b587ddb1-1a94-11e6-8478-000c291e9f7b', 2); Query OK, 1 row affected (0.00 sec) And then does this: mysql> update resources set generation = generation + 1 -> where resource_id = 'b587ddb1-1a94-11e6-8478-000c291e9f7b' -> and generation = 3; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 It observes that 1 row was matched, so the allocation succeeded and therefore it does this. mysql> commit; Query OK, 0 rows affected (0.01 sec) --- Assume now that consumer 'be03c4f7-1a96-11e6-8478-000c291e9f7b' with a cpu quota of 50 comes along and wants 4 more. The library does this. mysql> select resources.resource_id, generation, sum(amount) from resources, allocations where resources.resource_id = allocations.resource_id and resources.resource = 'cpu' and consumer_id = 'be03c4f7-1a96-11e6-8478-000c291e9f7b' group by resources.resource_id, generation; +--++-+ | resource_id | gene
Re: [openstack-dev] [cross-project][quotas][delimiter]My thoughts on how Delimiter uses generation-id for sequencing
I'm not thrilled that there are two API's one for a quota check and one for a consumption, and where it is up to the caller to properly return the results of one to the other. I'd much rather have consume accept the quotas and the request and 'just do it'. With that approach, the generation id's and things are entirely out of the requesters reach. I'll send a simple example illustrating the use of generations (which I hope will be simpler than Jay's example below). -amrith On Sun, 2016-05-15 at 11:06 -0400, Jay Pipes wrote: > On 05/15/2016 04:16 AM, Qijing Li wrote: > > Hi Vilobh, > > > > Here is my thoughts on how Delimiter uses generation-id to guarantee > > sequencing. Please correct me if I understand it wrong. > > > > First, the Delimiter need to introduce another model ResourceProvider > > who has two attributes: > > > > * resource_id > > * generation_id > > We will need generations for *consumers* of resources as well. The > generation for a provider of a resource is used when updating that > particular provider's view of its inventory. For quotas to work > effectively, we need each service to keep a generation for each consumer > of resources in the system. > > > The followings are the steps of how to consume a quota: > > > > Step 1. Check if there is enough available quota > > When you refer to quota above, you are using incorrect terminology. The > quota is the *limit* that a consumer of a resource has for a particular > class of resources. There is no such thing as "available quota". What > you are referring to above is whether the requested amount of resources > for a particular consumer would exceed that consumer's quota for a resource. > > > If yes, then get the $generation_id //by querying the model > > ResourceProvider with the given resource_id which is the point in time > > view of resource usage. > > The generation for a resource provider is not used when *checking* if > quota would be exceeded for a consumer's request of a particular > resource class. The generation for a resource provider is used when > *consuming* resources on a particular resource provider. This > consumption process doesn't have anything to do with Delimiter, though. > It is an internal mechanism of each service whether it uses heavy > locking techniques or whether it uses a generation and retries to ensure > a consistent view. > > Please see example code below. > > > If no, terminate the process of consuming the quota and return the > > message of “No enough quotas available." > > Yes. > > > Step 2. Consume the quota. > > > > 2.1 Begin transaction > > > > 2.2 Update the QuotaUsage model: QuotaUsage.in_use = > > QuotaUsage.in_use + amount of quota requested. > > No. The above is precisely why there are lots of problems in the > existing system. The QuotaUsage model and database tables need to go > away entirely. They represent a synchronicity problem because they > contain duplicate data (the amount/sum used) from the actual resource > usage tables in the services. > > Delimiter should not be responsible for updating any service's view of > resource usage. That is the responsibility of the service itself to do > this. All Delimiter needs to do is supply an interface/object model by > which services should represent usage records and an interface by which > services can determine if a consumer has concurrently changed its > consumption of resources in that service. > > > 2.3 Get the $generation_id by querying the ResourceProvider by the > > given resource_id. > > > > If the $generation_id is larger than the $generation_id in Step > > 1, then roll back transaction and GOTO step 1. > > > > this case means there is someone else has changed the > > QuotaUsage during this process. > > > > If the $generation_id is the same as the $generation_id in Step > > 1, then increase the ResourceProvider.generation_id by one and > > > > Commit the transaction. Done! > > > > Note: no case the $generation_id is less than the > > $generation_id in Step 1 because the $generation_id is nondecreasing. > > No, sorry, the code in my earlier response to Vilobh and Nikhil was > confusing. The consumer's generation is what needs to be supplied by > Delimiter. The resource provider's generation is used by the service > itself to ensure a consistent view of usages across multiple concurrent > consumers. The resource provider's generation is an internal mechanism > the service could use to prevent multiple consumers from exceeding the > provider's available resources. > > Here is what I think needs to be the "interface" that Delimiter facilitates: > > ```python > import sqlalchemy as sa > from sqlalchemy import sql > > import delimiter > from delimiter import objects as d_objects > from nova import objects as n_objects > from nova.db.sqlalchey import tables as n_tables > > > class NoRowsMatched(Exception): > pass >
Re: [openstack-dev] [tc] [all] [glance] On operating a high throughput or otherwise team
I'm not sure why I'm spending one of these very rare sunny Sunday afternoons on this but perhaps it's just important enough. Thanks Nikhil and Chris for such a verbal start for the discussion. I will at least try to keep my part shorter. I will quote both of your e-mails by name from which one it came from. Nikhil: """Lately I have been involved in discussions that have resulted in giving a wrong idea to the approach I take in operating the (Glance) team(s).""" At very start, please change your approach and start leading the team instead of trying to operate it. This is community rather than huge team in big enterprise and our contributors have different corporational and cultural backgrounds and reasonings why they are contributing into it, not organization with resources in PTLs disposal. Nikhil: """We are developing something that is usable, operationally friendly and that it's easier to contribute & maintain but, many strong influencers are missing on the most important need for OpenStack -- efficient way of communication.""" With the community size of OpenStack spanning probably about every timezone that has land we can communicate how much we ever want and not reach everybody in time. After all the individual projects are responsible for the release and providing that something that their mission statement mandates. We can put all our efforts to communicate being nice, friendly and easy but if we do not deliver we do not need to do this for long. Nikhil: """Also, many people like to work on the assumption that all the tools of communication are equivalent or useful and there are no side-effects of using them ever.""" """I think people prefer to use ML a lot and I am not a great fan of the same.""" This is great to recognize, now lets work on that and get the expectations right. Community wide the primary mean is the mailing list (and just perhaps extending to specs and gerrit reviews). You don't like it, I don't like it, but it's what we have to deal with. Secondary would be the more real time forums, namely IRC and design summits. Anything apart from that (yes; hangouts, bluejeans, midcycles are great for building the team and filing out misunderstandings and disagreements on individual level) is tertiary and worthless unless used purely to bring the discussion to the primary media. This is the only way to include the community asynchronous way without expecting that 2/3 of the timezones needs to participate at inconvenient or impossible times or find the funding to travel. Nikhil: """Multi-cast medium of communication is more disruptive as it involves a possibility of divergence from the topic, strongly polarizing opinions due to the small possibility of catching of the intent. So, let us use it 'judiciously' and preferably only as a newspaper.""" Seriously? If you want to publish in unidirectional manner, please write a blog* like everyone else, but don't try to transform our primary communications to such. Thankfully this opening was already start for right direction. * "BLOGGING; Never Before Have So Many People with So Little to Say Said So Much to So Few." - Despair, Inc. http://despair.com/products/blogging Nikhil: """Though, I think every team needs to be synchronous about their approach and not use delayed mechanisms like ML or gerrit.""" 10AM IST (UTC +0100) seems to be good time, half an hour every morning should be fine to get me synced up after I've gone through the pressing stuff from e-mails and 17:00 IST (UTC +0100) is probably good time for another to keep us in synchronous. I'm sure the rest of the team is willing to sacrifice half an hour of their mornings and evenings for same. Hopefully you can facilitate, or perhaps the synchronous approach is not that good after all? Chris: """The fundamental problem is that we don't have shared understanding and we don't do what is needed to build share understanding.""" This seems to be so spot on. We might be appear talking about same thing, having agreement what we should do and months later realize that we were not talking about same thing at all and start from the beginning. Chris: """My experience of most OpenStack communications is that the degree of shared understanding on some very fundamental things (e.g. "What are we building?") is extremely low. It's really not that surprising that there is discomfort.""" I'm not sure if you meant that but this issue seems to span across all the layers. By that I mean that if you ask few persons that question 'What are we building?' you get different responses regardless if that is component, project or OpenStack tent level. What I do not know is at which level it would be the best to start solving. Can people agree what their project or component is doing if they don't agree on the big picture or is it impossible to agree on the big picture if they can't agree what they are doing at the component/project level. Chris: """people, although they may not agree on the solution, wil
Re: [openstack-dev] [nova][neutron] Is it still valid/supported to create a network with a br- id?
On 5/15/2016 10:56 AM, Sean M. Collins wrote: Matt Riedemann wrote: The nova create-server API allows passing a network id that's prefixed with br- [1]. That was added due to this bug from Folsom [2]. I'm wondering if that's still valid? Looking at the network.id data model in Neutron it doesn't look like it would be [3]. Wow. That bug is awful. Network IDs should be UUIDs and ONLY UUIDs. Just because some vendor plugin decides that their going to break the Networking API contract and define their own ID scheme, doesn't mean that we should fix it to help them. That commit shouldn't have been accepted into Nova, and I don't think that we should support anything but a UUID for a network id. Period. Yeah, I agree. Remember, this was Folsom, when Neutron was a young and brash Quantum. I was just trying to sort out if there is still anything out there in the stadium that relies on this working. If not, I'll microversion it out of support for the Nova API when we add support for auto-allocated-topology. -- Thanks, Matt Riedemann __ 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] [nova][neutron] Is it still valid/supported to create a network with a br- id?
Matt Riedemann wrote: > The nova create-server API allows passing a network id that's prefixed with > br- [1]. That was added due to this bug from Folsom [2]. > > I'm wondering if that's still valid? Looking at the network.id data model in > Neutron it doesn't look like it would be [3]. Wow. That bug is awful. Network IDs should be UUIDs and ONLY UUIDs. Just because some vendor plugin decides that their going to break the Networking API contract and define their own ID scheme, doesn't mean that we should fix it to help them. That commit shouldn't have been accepted into Nova, and I don't think that we should support anything but a UUID for a network id. Period. -- Sean M. Collins __ 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] [cross-project][quotas][delimiter]My thoughts on how Delimiter uses generation-id for sequencing
On 05/15/2016 04:16 AM, Qijing Li wrote: Hi Vilobh, Here is my thoughts on how Delimiter uses generation-id to guarantee sequencing. Please correct me if I understand it wrong. First, the Delimiter need to introduce another model ResourceProvider who has two attributes: * resource_id * generation_id We will need generations for *consumers* of resources as well. The generation for a provider of a resource is used when updating that particular provider's view of its inventory. For quotas to work effectively, we need each service to keep a generation for each consumer of resources in the system. The followings are the steps of how to consume a quota: Step 1. Check if there is enough available quota When you refer to quota above, you are using incorrect terminology. The quota is the *limit* that a consumer of a resource has for a particular class of resources. There is no such thing as "available quota". What you are referring to above is whether the requested amount of resources for a particular consumer would exceed that consumer's quota for a resource. If yes, then get the $generation_id //by querying the model ResourceProvider with the given resource_id which is the point in time view of resource usage. The generation for a resource provider is not used when *checking* if quota would be exceeded for a consumer's request of a particular resource class. The generation for a resource provider is used when *consuming* resources on a particular resource provider. This consumption process doesn't have anything to do with Delimiter, though. It is an internal mechanism of each service whether it uses heavy locking techniques or whether it uses a generation and retries to ensure a consistent view. Please see example code below. If no, terminate the process of consuming the quota and return the message of “No enough quotas available." Yes. Step 2. Consume the quota. 2.1 Begin transaction 2.2 Update the QuotaUsage model: QuotaUsage.in_use = QuotaUsage.in_use + amount of quota requested. No. The above is precisely why there are lots of problems in the existing system. The QuotaUsage model and database tables need to go away entirely. They represent a synchronicity problem because they contain duplicate data (the amount/sum used) from the actual resource usage tables in the services. Delimiter should not be responsible for updating any service's view of resource usage. That is the responsibility of the service itself to do this. All Delimiter needs to do is supply an interface/object model by which services should represent usage records and an interface by which services can determine if a consumer has concurrently changed its consumption of resources in that service. 2.3 Get the $generation_id by querying the ResourceProvider by the given resource_id. If the $generation_id is larger than the $generation_id in Step 1, then roll back transaction and GOTO step 1. this case means there is someone else has changed the QuotaUsage during this process. If the $generation_id is the same as the $generation_id in Step 1, then increase the ResourceProvider.generation_id by one and Commit the transaction. Done! Note: no case the $generation_id is less than the $generation_id in Step 1 because the $generation_id is nondecreasing. No, sorry, the code in my earlier response to Vilobh and Nikhil was confusing. The consumer's generation is what needs to be supplied by Delimiter. The resource provider's generation is used by the service itself to ensure a consistent view of usages across multiple concurrent consumers. The resource provider's generation is an internal mechanism the service could use to prevent multiple consumers from exceeding the provider's available resources. Here is what I think needs to be the "interface" that Delimiter facilitates: ```python import sqlalchemy as sa from sqlalchemy import sql import delimiter from delimiter import objects as d_objects from nova import objects as n_objects from nova.db.sqlalchey import tables as n_tables class NoRowsMatched(Exception): pass class ConcurrentConsumption(Exception) pass def nova_check(quotas, request_spec): """ Do a verification that the resources requested by the supplied user and tenant involved in the request specification do not cause the user or tenant's quotas to be exceeded. :param request_spec: `delimiter.objects.RequestSpec` object containing requested resource amounts, the requesting user and project, etc. :returns `delimiter.objects.QuotaCheckResult` object containing the boolean result of the check, the resource classes that violated quotas, and a generation for the user. """ res = d_objects.QuotaCheckResult() alloc_tbl = n_tables.ALLOCATIONS cons_tbl = n_tables.CONS
Re: [openstack-dev] [tc] supporting Go
On Sat, May 14, 2016 at 7:13 PM, Clint Byrum wrote: > Excerpts from Dieterly, Deklan's message of 2016-05-14 01:18:20 +: > > Python 2.x will not be supported for much longer, and let¹s face it, > > Python is easy, but it just does not scale. Nor does Python have the > > performance characteristics that large, distributed systems require. > Maybe > > Java could replace Python in OpenStack as the workhorse language. > > Which is why we've been pushing toward python 3 for years now. It's > default for python apps in distros now, gates are holding the line at the > unit test level now, so we just need a push toward integration testing > and I truly believe we'll be seeing people use python3 and pypy to run > OpenStack in the next year. > Kuryr kubernetes integration is python 3 only, as it is asyncio based. I would be surprised if new projects and subprojects don't go to python3 directly. > > And regarding not scaling: That's precisely what's being discussed, > and it seems like there are plenty of options for pushing python further > that aren't even half explored yet. Meanwhile, if enough people agree, > perhaps go is a good option for those areas where we just can't push > Python further without it already looking like another language anyway. > > __ > 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] [cross-project][quotas][delimiter]My thoughts on how Delimiter uses generation-id for sequencing
Qijing, I don't believe that this is correct. I promised to send a description to the ML, I'll do that today. -amrith On Sun, 2016-05-15 at 01:16 -0700, Qijing Li wrote: > Hi Vilobh, > > Here is my thoughts on how Delimiter uses generation-id to guarantee > sequencing. Please correct me if I understand it wrong. > > First, the Delimiter need to introduce another model ResourceProvider > who has two attributes: > > * resource_id > * generation_id > > The followings are the steps of how to consume a quota: > > Step 1. Check if there is enough available quota > > If yes, then get the $generation_id by querying the model > ResourceProvider with the given resource_id which is the point in time > view of resource usage. > > If no, terminate the process of consuming the quota and return the > message of “No enough quotas available." > > Step 2. Consume the quota. > >2.1 Begin transaction > >2.2 Update the QuotaUsage model: QuotaUsage.in_use = > QuotaUsage.in_use + amount of quota requested. > >2.3 Get the $generation_id by querying the ResourceProvider by the > given resource_id. > > If the $generation_id is larger than the $generation_id in > Step 1, then roll back transaction and GOTO step 1. > >this case means there is someone else has changed the > QuotaUsage during this process. > > If the $generation_id is the same as the $generation_id in > Step 1, then increase the ResourceProvider.generation_id by one and > > Commit the transaction. Done! > > Note: no case the $generation_id is less than the > $generation_id in Step 1 because the $generation_id is nondecreasing. > > > — Qijing > > > __ > 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 signature.asc Description: This is a digitally signed message part __ 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] [tc] [all] [glance] On operating a high throughput or otherwise team
Hey Nikhil, found this all very interesting. Given your next to last paragraph where you ask for a "judiciary" it sounds like there is more going on here than I'm aware of, so apologies if my comments are not entirely germane: I found some of your analysis very interesting and related to things I've been thinking about since joining the community two years ago, and wanted to respond. I've probably missed some nuance in my effort to pick out the critical bits. The analysis you do to lay in the background (OpenStack process is slow, code is communication, people make a lot of assumptions that make it harder to converge on action) is rather astute but from my standpoint the apparent conclusion you make (to make up for inefficiencies in existing communication styles let's have more synchronous communication and synchronous participation) is unfortunate for a project at the scale (on many dimensions) of OpenStack. The fundamental problem is that we don't have shared understanding and we don't do what is needed to build share understanding. In fact we actively work against building it. TL;DR: When we are apart we need to write more; when we are together we need to talk more but with less purpose. I mostly agree (and have been crowing) that: many strong influencers are missing on the most important need for OpenStack -- efficient way of communication. but disagree that getting people into so-called "high bandwidth" meetings is the solution. Neither audio/video meetings nor IRC meetings are of any use unless the participants have already established the basic shared understanding that is required for the communication that happens in the meeting to make any sense. Most people in the OpenStack don't have that shared understanding and without that shared understanding the assumption problem you describe compounds. People make a list of goals that they believe are mutually shared but they are actually just a list of words for which everyone has a different interpretation. (Part of the reason, I think, that people have a tendency to be disruptive in IRC meetings is because it is incredibly obvious that no one is talking about the same thing even though they claim to be. The meeting is already just so much noise, why not add more? People act out because they are squirming in the face of lack of coherent meaning. TC meetings are classic and sometime hilarious examples of this: People talking over one another, ostensibly about the same topic, but from entirely different foundations. Without the foundations there's no real point having the conversations, especially in a medium where the foundations can't be built.) We could improve this situation by altering how we are using our communication tools to be more oriented towards establishing the foundations. In a past life we used to talk about this collaborative process as a sequence of "shared": * Developing shared language and share understanding is a prerequisite for * Developing shared goals which are a prerequisite for * Share actions Shared language is developed through hanging out and shooting the breeze, talking things over in the broad sense, finding common ground. It is the phase where you figure out what matters in the very broad sense. This is the sort of stuff that happens in the hallways at summit, late at night in open ended conversations at IRC. The undirected and unplanned sense-making. This stage is difficult for OpenStack newcomers or short-timers but because there are so many newcomers and short-timers it is critical that we figure out ways to make it easier. There must be discoverable and digestible (thus not etherpads nor IRC logs) artifacts from those conversations, ways in which the oral history becomes the written history. Yes, this means more work for the old-timers, but as you correctly point out Nikhil: communicating this sort of stuff should really be their primary activity. This myth-building happens to some extent already but there is not a strong culture in OpenStack of pointing people at the history. It's more common as a newbie to rock up in IRC with a question and get a brief synchronous answer when it would be better to be pointed at a written artifact that provides contextualizing background. It's important to note: At this stage being pointed at etherpads, gerrit reviews and IRC logs won't cut it. We're talking here about building shared language. There are two issues with those media: * They are already embedded in context of the language (that is, they only make sense if you already "get it). * The UX on etherpads, gerrit and IRC logs for extracting meaning is dismal. If you're sending people to raw etherpads to help them learn something you are a cruel person. Etherpads are references, not digests. The current expense of summits is such that participants go in with an eye to coming out of it with goals not realizing that they first need to establish the shared language. As a commercially driven open sourc
[openstack-dev] [Infra][Kuryr] New sub projects created
Hello all, We have created the following repositories as part of Kuryr: https://github.com/openstack?utf8=%E2%9C%93&query=kuryr Would love if anyone from Infra that has access can allow kuryr-core team to also be able to review/merge code in these new repositories. Would also love if the TC can approve Kuryr deliverables as reflected by this change in this following patch: https://review.openstack.org/#/c/314057/ Thanks Gal. __ 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] [openstack-ansible] LBaaSv2 / Octavia support
On 14 May 2016 at 00:27, Major Hayden wrote: > > For what it's worth, I have a (somewhat dated) branch with Octavia support > in Github[1]. > > > Great stuff! - that's covered everything I've been looking at so far, except that we're not wanting to run neutron-server (and therefore the octavia api) on the same boxes as the Neutron L3 agent (where I understand we need to run the worker). This isn't the place for usage questions, I was wondering how you deal with that separation or if it's not yet been worked into the branch? I will assume that SSL certs haven't been dealt to yet? I expect to be throwing Barbican into the mix shortly to deal with that, maybe Anchor too. > > We would definitely be happy to help with any questions you have while > you're using OpenStack-Ansible. It's always nice to have feedback from new > users, especially those who are used to other deployment frameworks. The > OpenStack-Ansible contributors have done a lot to "smooth off" the rough > edges of OpenStack deployments, but we find new things that surprise us > from time to time. :) > > I'll run up a test env asap, seems that using your branch with some minor updates might be just what we need. Any updates will of course be shared :) > Feel free to join #openstack-ansible on Freenode or hang out with us > during our IRC meetings on Thursday[2]. > Ugh - I really need to live in a country with a decent timezone. I'm in UTC+12 - will lurk around a bit and see who's online at the same time as I am, and the whole project looks to be pretty friendly for newcomers. I work funny hours but 4am isn't when I'm at my best. > > [1] https://github.com/major/openstack-ansible/tree/octavia > [2] https://wiki.openstack.org/wiki/Meetings/openstack-ansible > > > __ 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] [cross-project][quotas][delimiter]My thoughts on how Delimiter uses generation-id for sequencing
Hi Vilobh, Here is my thoughts on how Delimiter uses generation-id to guarantee sequencing. Please correct me if I understand it wrong. First, the Delimiter need to introduce another model ResourceProvider who has two attributes: - resource_id - generation_id The followings are the steps of how to consume a quota: Step 1. Check if there is enough available quota If yes, then get the $generation_id by querying the model ResourceProvider with the given resource_id which is the point in time view of resource usage. If no, terminate the process of consuming the quota and return the message of “No enough quotas available." Step 2. Consume the quota. 2.1 Begin transaction 2.2 Update the QuotaUsage model: QuotaUsage.in_use = QuotaUsage.in_use + amount of quota requested. 2.3 Get the $generation_id by querying the ResourceProvider by the given resource_id. If the $generation_id is larger than the $generation_id in Step 1, then roll back transaction and GOTO step 1. this case means there is someone else has changed the QuotaUsage during this process. If the $generation_id is the same as the $generation_id in Step 1, then increase the ResourceProvider.generation_id by one and Commit the transaction. Done! Note: no case the $generation_id is less than the $generation_id in Step 1 because the $generation_id is nondecreasing. — Qijing __ 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