Re: [openstack-dev] [neutron] Spec Proposal Deadline has passed, a note on Spec Approval Deadline
+1 Sent from my iPad On 2014-7-12, at 下午11:45, Miguel Angel Ajo Pelayo wrote: > +1 > > Sent from my Android phone using TouchDown (www.nitrodesk.com) > > > -Original Message- > From: Carl Baldwin [c...@ecbaldwin.net] > Received: Saturday, 12 Jul 2014, 17:04 > To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org] > Subject: Re: [openstack-dev] [neutron] Spec Proposal Deadline has passed, a > note on Spec Approval Deadline > > > +1 This spec had already been proposed quite some time ago. I'd like to see > this work get in to juno. > > Carl > > On Jul 12, 2014 9:53 AM, "Yuriy Taraday" wrote: > Hello, Kyle. > > On Fri, Jul 11, 2014 at 6:18 PM, Kyle Mestery > wrote: > Just a note that yesterday we passed SPD for Neutron. We have a > healthy backlog of specs, and I'm working to go through this list and > make some final approvals for Juno-3 over the next week. If you've > submitted a spec which is in review, please hang tight while myself > and the rest of the neutron cores review these. It's likely a good > portion of the proposed specs may end up as deferred until "K" > release, given where we're at in the Juno cycle now. > > Thanks! > Kyle > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > Please don't skip my spec on rootwrap daemon support: > https://review.openstack.org/#/c/93889/ > It got -2'd my Mark McClain when my spec in oslo wasn't approved but now > that's fixed but it's not easy to get hold of Mark. > Code for that spec (also -2'd by Mark) is close to be finished and requires > some discussion to get merged by Juno-3. > > -- > > Kind regards, Yuriy. > > ___ > 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][all] Branchless Tempest beyond pure-API tests, impact on backporting policy
> So I'm not sure that this should be a mandatory thing, but an > opt-in. My real concern is the manpower, who is going to take the > time to write all the test suites for all of the projects. I think > it would be better to add that on-demand as the extra testing is > required. That being said, I definitely view doing this as a good > thing and something to be encouraged, because tempest won't be able > to test everything. > > The other thing to also consider is duplicated effort between > projects. For an example, look at the CLI tests in Tempest, the > functional testing framework for testing CLI formatting was > essentially the same between all the clients which is why they're in > tempest. Under your proposal here, CLI tests should be moved back to > the clients. But, would that mean we have a bunch of copy and pasted > versions of the CLI test framework between all the project. > > I really want to avoid a situation where every project does the same > basic testing differently just in a rush to spin up functional > testing. I think coming up with a solution for a place with common > test patterns and frameworks that can be maintained independently of > all the projects and consumed for project specific testing is > something we should figure out first. (I'm not sure oslo would be > the right place for this necessarily) Yep, I'd have similar concerns about dupication of effort and divergence in a rush to spin up in-tree mini-Tempests across all the projects. So, I think it would be really great to have one or two really solid exemplar in-tree functional test suites in place, in order to allow the inevitable initial mistakes to be made the minimal number of times. Ideally the QA team would have an advisory, assisting role in getting these spun up so that the project gets the benefit of their domain expertise. Of course it would be preferable also to have the re-usable elements of the test infrastructure in a consumable form that the laggard projects can easily pick up without doing whole-scale copy'n'paste. > So I think that the contract unit tests work well specifically for > the ironic use case, but isn't a general solution. Mostly because > the Nova driver api is an unstable interface and there is no reason > for that to change. It's also a temporary thing because eventually > the driver will be moved into Nova and then the only cross-project > interaction between Ironic and Nova will be over the stable REST > APIs. > > I think in general we should try to avoid doing non REST API > cross-project communication. As I've pointed out before, I don't think it's feasible for ceilometer to switch to using only REST APIs for cross-project communication. However what we can do is finally grasp the nettle of "contractizing" notifications, as discussed on this related thread: http://lists.openstack.org/pipermail/openstack-dev/2014-July/039858.html The realistic time horizon for that is the K* cycle I suspect, but overall from that thread there seems to be some appetite for actually doing it finally. > So hopefully there won't be more of > these class of things, and if there are we can tackle them on a per > case basis. But, even if it's a non REST API I don't think we should > ever encourage or really allow any cross-project interactions over > unstable interfaces. Yes, if we go from discouragement to explicitly *disallowing* such interactions, that's probably something that would need to mandated at TC level IMO, with the appropriate grandfathering of existing usage. Is this something you or Sean (being a member of the TC) or I could drive? I'd be happy to draft some language for a governance patch, but having been to-and-fro the well before on such patches, I'm well aware that a TC member pushing it would add considerably to effectiveness. > As a solution for notifications I'd rather see a separate > notification white/grey (or any other monochrome shade) box test > suite. If as a project we say that notifications have to be > versioned for any change we can then enforce that easily with an > external test suite that contains the definitions for all the > notification. It then just makes a bunch of api calls and sits on > RPC verifying the notification format. (or something of that ilk) Do you mean a *single* external test suite? As opposed to multiple test suites, each validating the notifications emitted by each project? The reason I'm laboring this point is that such an over-arching testsuite feels a little Tempest-y. Seems it would have to spin up an entire devstack and then tickle the services into producing a range of notifications before consuming and verifying the events. Would that possibly be more lightweight if tested on a service-by-service basis? > I agree that normally whitebox testing needs to be tightly coupled > with the data models in the projects, but I feel like notifications > are slightly different. Mostly, because the basic format is the > same between all the p
Re: [openstack-dev] [Ironic] Nominating David Shrewsbury to ironic-core
+1 ! On Fri, Jul 11, 2014 at 11:50 PM, Devananda van der Veen wrote: > Hi all! > > While David (Shrews) only began working on Ironic in earnest four months > ago, he has been working on some of the tougher problems with our Tempest > coverage and the Nova<->Ironic interactions. He's also become quite active > in reviews and discussions on IRC, and demonstrated a good understanding of > the challenges facing Ironic today. I believe he'll also make a great > addition to the core team. > > Below are his stats for the last 90 days. > > Cheers, > Devananda > > +--+---++ > | Reviewer | Reviews -2 -1 +1 +2 +A+/- % | > Disagreements* | > +--+---++ > > 30 > | dshrews | 470 11 36 0 076.6% |7 ( > 14.9%) | > > 60 > | dshrews | 910 14 77 0 084.6% | 15 ( > 16.5%) | > > 90 > | dshrews | 1210 21 100 0 082.6% | 16 ( > 13.2%) | > > > ___ > 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] [Ironic] Nominating Jim Rollenhagen to ironic-core
+1 ! On Fri, Jul 11, 2014 at 11:50 PM, Devananda van der Veen wrote: > Hi all! > > It's time to grow the team :) > > Jim (jroll) started working with Ironic at the last mid-cycle, when "teeth" > became ironic-python-agent. In the time since then, he's jumped into Ironic > to help improve the project as a whole. In the last few months, in both > reviews and discussions on IRC, I have seen him consistently demonstrate a > solid grasp of Ironic's architecture and its role within OpenStack, > contribute meaningfully to design discussions, and help many other > contributors. I think he will be a great addition to the core review team. > > Below are his review stats for Ironic, as calculated by the > openstack-infra/reviewstats project with local modification to remove > ironic-python-agent, so we can see his activity in the main project. > > Cheers, > Devananda > > +--+---++ > | Reviewer | Reviews -2 -1 +1 +2 +A+/- % | > Disagreements* | > +--+---++ > > 30 > | jimrollenhagen | 290 8 21 0 072.4% |5 ( > 17.2%) | > > 60 > | jimrollenhagen | 760 16 60 0 078.9% | 13 ( > 17.1%) | > > 90 > | jimrollenhagen | 1060 27 79 0 074.5% | 25 ( > 23.6%) | > > 180 > | jimrollenhagen | 1570 41 116 0 073.9% | 35 ( > 22.3%) | > > > > ___ > 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][all] Old review expiration
On 07/11/2014 06:30 PM, Kevin L. Mitchell wrote: I decided to do some Nova reviews today, and I decided to do it by pulling up the list of all of them and start from the end. What I've found is a *lot* of reviews that have been idle for several months. I've even found one or two that were approved, but weren't merged due to depending on an outdated patch, and I found others that had several +1s but no -1s or +2s. Hi Vek :) I, too, tend to see a lot of such patches, as I try to review things that don't necessarily have a bunch of feedback already on them. Here are my general rules of thumb and/or ideas about these classes of patches: 1) If the patch was approved but failed to merge because of an abandoned or outdated dependent patchset, then I contact the patch submitter via email and just say "Hey, do you need help getting this patch going again? If not, please update the dependent patch or abandon the patch." 2) If the patch has 2 +2s from core reviewers but is not +W'd, then I will find a core on #openstack-nova and ask them to do a quick re-review and +W the patch if all looks good. 3) If the patch has a couple +1s but no -1 or +/-2s, then I actually get interested in the patch and will do a thorough review of it. I will leave my personal review, and do one of the following: a) If I think the patch is an important fix or feature piece (regardless of whether I think the patch is good or not), I will ping a core in #openstack-nova to get core opinion on the patch b) If I think the patch is NOT a particularly important fix or feature piece, I might ask some non-core reviewers to take a look and evaluate it. At least if the non-core reviewers review it (good or bad), then the patch will bump to the head of many patch queues and may get some extra eyeballs on it that way. There are 2 or 3 pages of these old reviews hanging at the end of the list, and it made me ask about the auto-expiration we used to have—I missed it in the Gerrit upgrade thread, but it turns out that, since core reviewers can now abandon/restore patches, the auto-expiration has been turned off. Given that we have so many old reviews hanging around on nova (and probably other projects), should we consider setting something like that back up? With nova, at least, the vast majority of them can't possibly merge because they're so old, so we need to at least have something to remind the developer that they need to rebase…and if they've forgotten the review or don't care about it anymore, we should either have it taken over or get the review abandoned. I didn't like the impersonal nature of the auto-expire thing, frankly. I prefer the current situation where deliberate action is needed, even if that means a little more work for the core review team. The other concern I have is the several reviews that no core dev looked at in an entire month, but I have no solutions to suggest there, unfortunately :( Patches of your own or patches of other folks? All the best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Spec Proposal Deadline has passed, a note on Spec Approval Deadline
+1 Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Carl Baldwin [c...@ecbaldwin.net] Received: Saturday, 12 Jul 2014, 17:04 To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org] Subject: Re: [openstack-dev] [neutron] Spec Proposal Deadline has passed, a note on Spec Approval Deadline +1 This spec had already been proposed quite some time ago. I'd like to see this work get in to juno. Carl On Jul 12, 2014 9:53 AM, "Yuriy Taraday" wrote: > Hello, Kyle. > > On Fri, Jul 11, 2014 at 6:18 PM, Kyle Mestery > wrote: > >> Just a note that yesterday we passed SPD for Neutron. We have a >> healthy backlog of specs, and I'm working to go through this list and >> make some final approvals for Juno-3 over the next week. If you've >> submitted a spec which is in review, please hang tight while myself >> and the rest of the neutron cores review these. It's likely a good >> portion of the proposed specs may end up as deferred until "K" >> release, given where we're at in the Juno cycle now. >> >> Thanks! >> Kyle >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > Please don't skip my spec on rootwrap daemon support: > https://review.openstack.org/#/c/93889/ > It got -2'd my Mark McClain when my spec in oslo wasn't approved but now > that's fixed but it's not easy to get hold of Mark. > Code for that spec (also -2'd by Mark) is close to be finished and > requires some discussion to get merged by Juno-3. > > -- > > Kind regards, Yuriy. > > ___ > 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] Treating notifications as a contract
> > A notification of compute.instance.create.start is naturally going to > > carry different types of data than a volume.snapshot.delete.end for > > example, but of course we'd seek to accommodate that difference within > > a generic structure as far as possible. > > Is it going to carry different types of data or different values on > identical keys. The goal would be that the "meaning" of a notification > for compute.instance.create.start and volume.snapshot.delete.end > should be found on the same set of keys. That's all "the proposal" is. OK, got it. :) So what we need to figure out is how exactly this common structure can be accommodated without reverting back to what Sandy called the "wild west" in another post. (i.e. the current scenario of a small set of common fields such as priority or timestamp, followed by a free-form payload dict that differs from one event type to another, or may even change from the old form of one event type to the new form of the same notification) > >> It may be, they have the same basic idea: "stuff that > >> happens" can be represented by a sequence of relatively stupid event- > >> like things. > > > > OK, I might be missing something here, but we seem to have a close > > approximation of that already: > > > > stuff happens ==> events pop out on the bus > > > > So is your point that our events aren't dumb enough? > > Events are too different in from, from event to event. > > > (e.g. encode too much structure, or carry too much data, or require > > too much interpretation?) > > Of these three, "require too much interpretation" is perhaps the best > match. OK, I think I can agree with the spirit of that. > > But overall, it doesn't look like too radical a change in format. > > No, it's not. What it is is a minor change that "everyone" could adopt > and thus be able to play in the party. Agreed, so I think we just need to tie down the benefits of such a non- radical change, and compare those to the potential costs and benefits of more locked-down schemata (i.e. more specific to individual event types). > > The metric-oriented view is subset/specialized aspect of something > > more generic. > > Okay, so we agree on that. Can we agree that it might be possible to > represent that generic thing with a common grammar? Yes, I think we can :) > >> No, you are seeing the evolution of my thinking: as I write about this > >> stuff and try to understand it, it becomes more clear (to me) that > >> samples ought to be treated as event-like thingies. > > > > OK, so that shift makes it a little difficult to follow and engage with. > > This is a mailing list for a distributed project, it is the sole place > where we can get some reasonable simulation of "having a chat" with a > wide body of interested parties. The point of having a chat is to > explore, think, and exchange and hone ideas. I certainly hope you > don't expect me and everyone else only to write to the list when we > have a fully researched proposal. This (apart from summits and > mid-cycles) is the most accessible place we have to which we can go to > create the information that allows us to do the compare and contrast > the eventually leads to creating proposals. Fully agreed that the ML is exactly the place for discussing and honing ideas, outside of the design summit and mid-cycle meetups. And I agree that there is no requirement for these ideas to be fully formed before bringing them to the list. > > OK, so perhaps I misread your earlier comments on samples and assumed > > a predisposition to ceilometer's requirements was being proposed? > > It seems that way. Throughout I've been saying notifications should be > easy for anyone to create and anyone to consume and have confidence > they are doing it right. Yep ... after discussing this on IRC, it seems that the confusion arose from me reading too much into your prior statement of: "to me ceilometer is a service for gathering metrics and then being able to do things with those metrics. anything with the proper creds ought to be able to send out a notification which is to be treated as a metric and ceilometer should consume it" i.e. assuming this to indicate a stronger equivalence between notifications and metrics/samples than you had intended. > > Can you start fleshing out exactly what you mean by a standard not > > necessarily predisposed to ceilometer, still sufficiently close to > > eliminate the need for a mapping layer on the ceilometer side? > > That's what I'm trying to do here in this discussion here on this list > because as far as I'm able to tell that's the one way to ensure that > the idea has some validity and I'm not missing important details. I > thought I was saying "how about this general idea, any merit? Help me > flesh it out?" but apparently it came across as something different. Apologies, I should have wrote: can you *continue* fleshing out ... Poor choice of words on my part. > That's a shame. If I we
Re: [openstack-dev] [neutron] Spec Proposal Deadline has passed, a note on Spec Approval Deadline
+1 This spec had already been proposed quite some time ago. I'd like to see this work get in to juno. Carl On Jul 12, 2014 9:53 AM, "Yuriy Taraday" wrote: > Hello, Kyle. > > On Fri, Jul 11, 2014 at 6:18 PM, Kyle Mestery > wrote: > >> Just a note that yesterday we passed SPD for Neutron. We have a >> healthy backlog of specs, and I'm working to go through this list and >> make some final approvals for Juno-3 over the next week. If you've >> submitted a spec which is in review, please hang tight while myself >> and the rest of the neutron cores review these. It's likely a good >> portion of the proposed specs may end up as deferred until "K" >> release, given where we're at in the Juno cycle now. >> >> Thanks! >> Kyle >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > Please don't skip my spec on rootwrap daemon support: > https://review.openstack.org/#/c/93889/ > It got -2'd my Mark McClain when my spec in oslo wasn't approved but now > that's fixed but it's not easy to get hold of Mark. > Code for that spec (also -2'd by Mark) is close to be finished and > requires some discussion to get merged by Juno-3. > > -- > > Kind regards, Yuriy. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Spec Proposal Deadline has passed, a note on Spec Approval Deadline
Hello, Kyle. On Fri, Jul 11, 2014 at 6:18 PM, Kyle Mestery wrote: > Just a note that yesterday we passed SPD for Neutron. We have a > healthy backlog of specs, and I'm working to go through this list and > make some final approvals for Juno-3 over the next week. If you've > submitted a spec which is in review, please hang tight while myself > and the rest of the neutron cores review these. It's likely a good > portion of the proposed specs may end up as deferred until "K" > release, given where we're at in the Juno cycle now. > > Thanks! > Kyle > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > Please don't skip my spec on rootwrap daemon support: https://review.openstack.org/#/c/93889/ It got -2'd my Mark McClain when my spec in oslo wasn't approved but now that's fixed but it's not easy to get hold of Mark. Code for that spec (also -2'd by Mark) is close to be finished and requires some discussion to get merged by Juno-3. -- Kind regards, Yuriy. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Barbican] Barebones CA
Just a quick update on this, I started work on a basic plugin but quickly found I was running out of time. I handed over to Tim Kelsey, who had a few concerns about the plumbing required to make this work, I’ve CC’d him on this thread. -Rob On 28/06/2014 08:03, "John Wood" wrote: >Hello folks, > >Just trying clarify things...are we talking about a dev plugin to >generate asymmetric keys, or else one to mimic working with a CA to >create SSL certificates via workflow (so including firing off >certificate-generated events, for example)? > >If we are talking about the former, then you would be interested in a >plugin that implements a method such as this one: >https://github.com/openstack/barbican/blob/master/barbican/plugin/interfac >e/secret_store.py#L167 > >If you are talking about the latter, then that would be a different type >of plugin that handles CA workflows, as proposed in this blueprint: >https://review.openstack.org/#/c/99221/ > >Thanks, >John > > >From: Nathan Kinder [nkin...@redhat.com] >Sent: Wednesday, June 25, 2014 9:43 PM >To: OpenStack Development Mailing List (not for usage questions); >a...@redhat.com >Subject: Re: [openstack-dev] [Barbican] Barebones CA > >On 06/25/2014 02:42 PM, Clark, Robert Graham wrote: >> >> Ok, I’ll hack together a dev plugin over the next week or so, other work >> notwithstanding. Where possible I’ll probably borrow from the dog tag >> plugin as I’ve not looked closely at the plugin infrastructure in >>Barbican >> recently. > >My understanding is that Barbican's plugin interface is currently in the >midst of a redesign, so be careful not to copy something that will be >changing shortly. > >-NGK > >> >> Is this something you’d like a blueprint for first? >> >> -Rob >> >> >> >> >> On 25/06/2014 18:30, "Ade Lee" wrote: >> >>> I think the plan is to create a Dogtag instance so that integration >>> tests can be run whenever code is checked in (both with and without a >>> Dogtag backend). >>> >>> Dogtag isn't that difficult to deploy, but being a Java app, it does >>> bring in a set of dependencies that developers may not want to deal >>>with >>> for basic/ devstack testing. >>> >>> So, I agree that a simple OpenSSL CA may be useful at least initially >>>as >>> a 'dev' plugin. >>> >>> Ade >>> >>> On Wed, 2014-06-25 at 16:31 +, Jarret Raim wrote: Rob, RedHat is working on a backend for Dogtag, which should be capable of doing something like that. That's still a bit hard to deploy, so it would make sense to extend the 'dev' plugin to include those features. Jarret On 6/24/14, 4:04 PM, "Clark, Robert Graham" wrote: > Yeah pretty much. > > That¹s something I¹d be interested to work on, if work isn¹t ongoing > already. > > -Rob > > > > > > On 24/06/2014 18:57, "John Wood" wrote: > >> Hello Robert, >> >> I would actually hope we have a self-contained certificate plugin >> implementation that runs 'out of the box' to enable certificate >> generation orders to be evaluated and demo-ed on local boxes. >> >> Is this what you were thinking though? >> >> Thanks, >> John >> >> >> >> >> From: Clark, Robert Graham [robert.cl...@hp.com] >> Sent: Tuesday, June 24, 2014 10:36 AM >> To: OpenStack List >> Subject: [openstack-dev] [Barbican] Barebones CA >> >> Hi all, >> >> I¹m sure this has been discussed somewhere and I¹ve just missed it. >> >> Is there any value in creating a basic ŒCA¹ and plugin to satisfy >> tests/integration in Barbican? I¹m thinking something that probably >> performs OpenSSL certificate operations itself, ugly but perhaps useful >> for some things? >> >> -Rob >> >> ___ >> 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 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 mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> ___ >> OpenSta
Re: [openstack-dev] [neutron][all] switch from mysqldb to another eventlet aware mysql client
+1. Well put. No one is arguing against this other approach. The two efforts can be taken independently. Carl On Jul 11, 2014 10:48 PM, "Mike Bayer" wrote: > > On 7/11/14, 11:26 PM, Jay Pipes wrote: > > Yep, couldn't agree more. > > > > Frankly, the steps you outline in the wiki above are excellent > > examples of where we can make significant gains in both performance > > and scalability. In addition to those you listed, the underlying > > database schemas themselves, with the excessive use of large VARCHAR > > fields, BLOB fields for JSONified values, and the general bad strategy > > of bunching heavily-read fields with infrequently-read fields in the > > same tables, are also a source of poor overall database performance. > Well the topic of schema modifications I actually left out of that > document entirely for starters - I made a conscious choice to focus > entirely on things that don't involve any apps changing any of their > fundamental approaches or schemas...at least just yet! :)I'm hoping > that as oslo.db improves and the patterns start to roll out, we can > start working on schema design too.Because yeah I've seen the giant > lists of VARCHAR everything and just said, OK well we're going to have > to get to that..just not right now :). > > > > ___ > 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] [oslo] Asyncio and oslo.messaging
On Fri, Jul 11, 2014 at 10:34 PM, Joshua Harlow wrote: > S, how about we can continue this in #openstack-state-management (or > #openstack-oslo). > > Since I think we've all made the point and different viewpoints visible > (which was the main intention). > > Overall, I'd like to see asyncio more directly connected into taskflow so > we can have the best of both worlds. > > We just have to be careful in letting people blow their feet off, vs. > being to safe; but that discussion I think we can have outside this thread. > That's what I was about to reply to Clint: "Let the user shoot ones feet, one can always be creative in doing that anyway". Sound good? > Sure. TBH I didn't think this thread is the right place for this discussion but "coroutines can't do that" kind of set me off :) -Josh > > On Jul 11, 2014, at 9:04 AM, Clint Byrum wrote: > > > Excerpts from Yuriy Taraday's message of 2014-07-11 03:08:14 -0700: > >> On Thu, Jul 10, 2014 at 11:51 PM, Josh Harlow > wrote: > >>> 2. Introspection, I hope this one is more obvious. When the coroutine > >>> call-graph is the workflow there is no easy way to examine it before it > >>> executes (and change parts of it for example before it executes). This > is a > >>> nice feature imho when it's declaratively and explicitly defined, you > get > >>> the ability to do this. This part is key to handling upgrades that > >>> typically happen (for example the a workflow with the 5th task was > upgraded > >>> to a newer version, we need to stop the service, shut it off, do the > code > >>> upgrade, restart the service and change 5th task from v1 to v1.1). > >>> > >> > >> I don't really understand why would one want to examine or change > workflow > >> before running. Shouldn't workflow provide just enough info about which > >> tasks should be run in what order? > >> In case with coroutines when you do your upgrade and rerun workflow, > it'll > >> just skip all steps that has already been run and run your new version > of > >> 5th task. > >> > > > > I'm kind of with you on this one. Changing the workflow feels like self > > modifying code. > > > >> 3. Dataflow: tasks in taskflow can not just declare workflow > dependencies > >>> but also dataflow dependencies (this is how tasks transfer things from > one > >>> to another). I suppose the dataflow dependency would mirror to > coroutine > >>> variables & arguments (except the variables/arguments would need to be > >>> persisted somewhere so that it can be passed back in on failure of the > >>> service running that coroutine). How is that possible without an > >>> abstraction over those variables/arguments (a coroutine can't store > these > >>> things in local variables since those will be lost)?It would seem like > this > >>> would need to recreate the persistence & storage layer[5] that taskflow > >>> already uses for this purpose to accomplish this. > >>> > >> > >> You don't need to persist local variables. You just need to persist > results > >> of all tasks (and you have to do it if you want to support workflow > >> interruption and restart). All dataflow dependencies are declared in the > >> coroutine in plain Python which is what developers are used to. > >> > > > > That is actually the problem that using declarative systems avoids. > > > > > >@asyncio.couroutine > >def add_ports(ctx, server_def): > >port, volume = yield from > asyncio.gather(ctx.run_task(create_port(server_def)), > > > ctx.run_task(create_volume(server_def)) > >if server_def.wants_drbd: > >setup_drbd(volume, server_def) > > > >yield from ctx.run_task(boot_server(volume_az, server_def)) > > > > > > Now we have a side effect which is not in a task. If booting fails, and > > we want to revert, we won't revert the drbd. This is easy to miss > > because we're just using plain old python, and heck it already even has > > a test case. > > > > I see this type of thing a lot.. we're not arguing about capabilities, > > but about psychological differences. There are pros and cons to both > > approaches. > > > > ___ > > 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 > -- Kind regards, Yuriy. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] proposal to remove Roman Prykhodchenko from the core team
It’s a stupid typo but it changes the sense of my last email; Of course I mean months, not month. On Jul 12, 2014, at 14:06, Roman Prykhodchenko wrote: > That is true, last month my work on Ironic is about interacting with > different third party stuff (migration, testing, etc.) that required more > attention than Ironic itself. > I will continue working on making Ironic better independent on my status in > Gerrit (just as I did before I was a core-reviewer) and hope I will be able > to put more attention to Ironic itself. > > On Jul 12, 2014, at 1:52, Devananda van der Veen > wrote: > >> While expanding the core review team is important, keeping the team's >> collective knowledge of the project consistent and accurate is equally >> important, and participation in reviews and design discussions is how we do >> that. >> >> Roman's (romcheg) review activity has been steadily dropping over the last >> six months, and even though he is working on the nova db -> ironic db >> migration tool, I don't feel that he is active enough in code reviews or the >> design process, and has not been for some time. While I would welcome him >> back to the core team if his review activity were to pick up again, I feel >> it's best to remove him at this time. >> >> Below are his stats at over the last six months. >> >> Regards, >> Devananda >> >> +--+---++ >> | Reviewer | Reviews -2 -1 +1 +2 +A+/- % | >> Disagreements* | >> +--+---++ >> >> 30 >> | prykhodchenko | 180 6 2 10 266.7% |4 ( >> 22.2%) | >> >> 60 >> | prykhodchenko | 440 14 6 24 1068.2% |6 ( >> 13.6%) | >> >> 90 >> | prykhodchenko | 590 18 6 35 1469.5% |6 ( >> 10.2%) | >> >> >> 180 >> | prykhodchenko | 1503 46 21 80 2867.3% | 12 ( >> 8.0%) | >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] proposal to remove Roman Prykhodchenko from the core team
That is true, last month my work on Ironic is about interacting with different third party stuff (migration, testing, etc.) that required more attention than Ironic itself. I will continue working on making Ironic better independent on my status in Gerrit (just as I did before I was a core-reviewer) and hope I will be able to put more attention to Ironic itself. On Jul 12, 2014, at 1:52, Devananda van der Veen wrote: > While expanding the core review team is important, keeping the team's > collective knowledge of the project consistent and accurate is equally > important, and participation in reviews and design discussions is how we do > that. > > Roman's (romcheg) review activity has been steadily dropping over the last > six months, and even though he is working on the nova db -> ironic db > migration tool, I don't feel that he is active enough in code reviews or the > design process, and has not been for some time. While I would welcome him > back to the core team if his review activity were to pick up again, I feel > it's best to remove him at this time. > > Below are his stats at over the last six months. > > Regards, > Devananda > > +--+---++ > | Reviewer | Reviews -2 -1 +1 +2 +A+/- % | > Disagreements* | > +--+---++ > > 30 > | prykhodchenko | 180 6 2 10 266.7% |4 ( > 22.2%) | > > 60 > | prykhodchenko | 440 14 6 24 1068.2% |6 ( > 13.6%) | > > 90 > | prykhodchenko | 590 18 6 35 1469.5% |6 ( > 10.2%) | > > > 180 > | prykhodchenko | 1503 46 21 80 2867.3% | 12 ( > 8.0%) | > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
