Re: [openstack-dev] [all] Proposal: Architecture Working Group
Hi all! I really like the idea of the group, so count me in! Ghe Rivero Quoting Clint Byrum (2016-06-17 23:52:43) > ar·chi·tec·ture > ˈärkəˌtek(t)SHər/ > noun > noun: architecture > > 1. > > the art or practice of designing and constructing buildings. > > synonyms:building design, building style, planning, building, > construction; > > formalarchitectonics > > "modern architecture" > > the style in which a building is designed or constructed, especially with > regard to a specific period, place, or culture. > > plural noun: architectures > > "Victorian architecture" > > 2. > > the complex or carefully designed structure of something. > > "the chemical architecture of the human brain" > > the conceptual structure and logical organization of a computer or > computer-based system. > > "a client/server architecture" > > synonyms:structure, construction, organization, layout, design, build, > anatomy, makeup; > > informalsetup > > "the architecture of a computer system" > > > Introduction > = > > OpenStack is a big system. We have debated what it actually is [1], > and there are even t-shirts to poke fun at the fact that we don't have > good answers. > > But this isn't what any of us wants. We'd like to be able to point > at something and proudly tell people "This is what we designed and > implemented." > > And for each individual project, that is a possibility. Neutron can > tell you they designed how their agents and drivers work. Nova can > tell you that they designed the way conductors handle communication > with API nodes and compute nodes. But when we start talking about how > they interact with each other, it's clearly just a coincidental mash of > de-facto standards and specs that don't help anyone make decisions when > refactoring or adding on to the system. > > Oslo and cross-project initiatives have brought some peace and order > to the implementation and engineering processes, but not to the design > process. New ideas still start largely in the project where they are > needed most, and often conflict with similar decisions and ideas in other > projects [dlm, taskflow, tooz, service discovery, state machines, glance > tasks, messaging patterns, database patterns, etc. etc.]. Often times this > creates a log jam where none of the projects adopt a solution that would > align with others. Most of the time when things finally come to a head > these things get done in a piecemeal fashion, where it's half done here, > 1/3 over there, 1/4 there, and 3/4 over there..., which to the outside > looks like chaos, because that's precisely what it is. > > And this isn't always a technical design problem. OpenStack, for instance, > isn't really a micro service architecture. Of course, it might look like > that in diagrams [2], but we all know it really isn't. The compute node is > home to agents for every single concern, and the API interactions between > the services is too tightly woven to consider many of them functional > without the same lockstep version of other services together. A game to > play is ask yourself what would happen if a service was isolated on its > own island, how functional would its API be, if at all. Is this something > that we want? No. But there doesn't seem to be a place where we can go > to actually design, discuss, debate, and ratify changes that would help > us get to the point of gathering the necessary will and capability to > enact these efforts. > > Maybe nova-compute should be isolated from nova, with an API that > nova, cinder and neutron talk to. Maybe we should make the scheduler > cross-project aware and capable of scheduling more than just nova > instances. Maybe we should have experimental groups that can look at how > some of this functionality could perhaps be delegated to non-openstack > projects. We hear that Mesos, for example to help with the scheduling > aspects, but how do we discuss these outside hijacking threads on the > mailing list? These are things that we all discuss in the hallways > and bars and parties at the summit, but because they cross projects at > the design level, and are inherently a lot of social and technical and > exploratory work, Many of us fear we never get to a place of turning > our dreams into reality. > > So, with that, I'd like to propose the creation of an Architecture Working > Group. This group's charge would not be design by committee, but a place > for architects to share their designs and ga
Re: [openstack-dev] [nova] Using image metadata to sanity check supplied authentication data at nova 'create' or 'recreate' time?
I think nova should completely ignore this issue and boot the image no matter what. This is an operational 'workflow', and nova doesn't need to know about the image internals at all. If it boots, then is not nova problem. Ghe Rivero Quoting Clif Houck (2016-06-06 23:41:12) > Hello all, > > At Rackspace we're running into an interesting problem: Consider a user > who boots an instance in Nova with an image which only supports SSH > public-key authentication, but the user doesn't provide a public key in > the boot request. As far as I understand it, today Nova will happily > boot that image and it may take the user some time to realize their > mistake when they can't login to the instance. > > I've been thinking about a solution to this problem. Ideally, the Nova > API would quickly return an HTTP code indicating a problem with the > request and reject the `create` or `recreate` request if the proper > credentials were not included as part of the request. > > So in the example above, instead of Nova accepting the create request, > Nova would check the requested image's meta-data and ensure at least > one form of authentication is supported AND has credentials available > to place on the image during provisioning. Basically, ensure the > requester has a way to login remotely. > > I've put up a short specification on this proposed addition here: > https://review.openstack.org/#/c/326073/ > and the blueprint is here: > https://blueprints.launchpad.net/nova/+spec/auth-based-on-image-metadat > a > > I think one of the glaring weaknesses of this proposal is it would > require a call to the image API to get image meta-data during `create` > or `recreate`. This could be alleviated by caching image meta-data in > Nova, since I wouldn't expect image meta-data to change often. > > There's also the question of the image meta-data itself. I don't think > there is any existing standard to describe, using metadata, what remote > login/authentication methods a particular image supports. One way could > be to provide a set of configuration options for the operator to > define. That way, each operator could define their own metadata > describing each authentication method supported by their images. > > Hoping this will elicit some opinions on how to go about solving this, > or if I've missed something that already exists that solves this > problem. > > Any thoughts welcome. > > Thanks, > Clif Houck > > __ > 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] [infra][shade] Proposing Ricardo Carrillo Cruz for Shade core
Quoting Monty Taylor (2016-05-31 15:00:10) > On 05/31/2016 08:53 AM, David Shrewsbury wrote: > > Ricardo has been working with shade for a while now, has been great at > > helping out with reviews, and has offered some quality code contributions. > > He has showed a good understanding of the code base and coding guidelines, > > and has been helping to review (and adding to) the new OpenStack Ansible > > modules that depend so highly on shade. > > > > Shade could use more cores as our user base has grown and I think he'd be > > an awesome addition. > > I wholeheartedly concur. Ricky has been doing a great job. Having him in > shade-core would be great. ++ Shade is getting a lot of attention lately, and more cores will help. Ghe Rivero __ 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] [requirements] Bootstrapping new team for Requirements.
On 07/05/16 17:02, Davanum Srinivas wrote: Dirk, Haïkel, Igor, Alan, Tony, Ghe, Please see brain dump here - https://etherpad.openstack.org/p/requirements-tasks Nice starting point. Reading through all of it right now. Looking at time overlap, it seems that most of you are in one time range and Tony and I are outliers http://www.timeanddate.com/worldclock/meetingtime.html?iso=20160506&p1=43&p2=240&p3=195&p4=166&p5=83&p6=281&p7=141) So one choice for time is 7:00 AM or 8:00 AM my time which will be 9:00/10:00 PM for Tony. Are there other options that anyone sees? Please let me know which days work as well. I can do it almost any time, but will prefer to avoid Friday afternoons... Ghe Rivero __ 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][osc] Use of openstack client for admin commands
On 04/05/16 22:53, Jay Pipes wrote: On 05/04/2016 01:08 PM, Chris Dent wrote: The plans for generic resource pools[1] include a suite of new commands for creating and updating resource pools. In today's Nova API meeting[2] and afterwards in #openstack-nova[3] we discussed two issues: * Since the placement API associated with resource pools is eventually going to be hoisted out of nova it will be developed in a decoupled fashion within the nova tree. It makes sense to also hoist the client libraries in the same fashion. The canonical plan for CLIs is to plug in to OSC. * There's some confusion on whether commands that are destined for admins and services but not end users are "supposed" to be in OSC. Since then the spec has been updated to reflect using OSC but the question of whether this is in fact the right place for this style of commands remains open. Not just for this situation, but generally. Is there an official word on this? If not, should we make one? My position is that if it's an HTTP API (as opposed to something like a sqlalchemy-migrate sync command) then it belongs in a client that speaks the OpenStack HTTP APIs. That is OSC as far as I can tell. I don't see a difference between "admin" commands and "standard" commands. There is a very blurry line between "admin" and "standard" commands in most of the cases. (In shade, is already split between operatorcloud.py and openstackcloud.py, and for any new capability to include, the first discussion, always, is where to put it) Splitting it, will only frustrate operators and users trying to remember which function is included in each command (and knowing Murphy's law, they will always choose the wrong one). So, please, just one command to rule them all. Ghe Rivero __ 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] Should be instance_dir in all nova compute node same ?
Is there any specific reason why this is require that way? or just a "feature"? Ghe Rivero On 03/05/16 11:42, Matthew Booth wrote: On Fri, Apr 29, 2016 at 2:47 AM, Eli Qiao <mailto:liyong.q...@intel.com>> wrote: hi team, Is there any require that all compute node's instance_dir should be same? Yes. This is assumed in many places, certainly in cold migration/resize. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) __ 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] [TripleO] core cleanup
+1, I'm no longer involved in TripleO, so there is no reason to be core. Ghe Rivero Quoting James Slagle (2016-03-14 16:30:21) > On Mon, Mar 14, 2016 at 10:26 AM, Dan Prince wrote: > > Looking at the stats for the last 180 days I'd like to propose we > > cleanup TripleO core a bit: > > > > http://russellbryant.net/openstack-stats/tripleo-reviewers-180.txt > > > > There are a few reviewers with low numbers of reviews (just added to > > the tripleo-ui team, jtomasek and flfuchs). I think those will ramp up > > soon as the UI repos become part of upstream. > > > > For the rest of the numbers I roughly looked at those below the 100 > > reviews mark. So I'd like to propose we cut the following users from > > TripleO core: > > > > stevenk > > jprovazn > > tomas-8c8 > > tchaypo > > ghe.rivero > > lsmola > > pblaho > > cmsj > > > > > > > > If existing TripleO core members could review the above list and +/- 1 > > over the next week that would be great so we can proceed with the > > cleanup. > > +1 > > -- > -- James Slagle > -- > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] (no subject)
From: Ghe Rivero Subject: Re: [openstack-dev] [all] A proposal to separate the design summit Quoting Clayton O'Neill (2016-02-22 10:27:04) > Is the expectation that the ops mid-cycle would continue separately, > or be held with the meeting formerly known as the Design Summit? > > Personally I’d prefer they be held together, but scheduled with the > thought that operators aren’t likely to be interested in work > sessions, but that a good number of us would be interested in > cross-project and some project specific planning sessions. This would > also open up the possibility of having some sessions specific intended > for operator/developer feedback sessions. +1 Ghe Rivero > On Mon, Feb 22, 2016 at 12:15 PM, Lauren Sell wrote: > > > >> On Feb 22, 2016, at 8:52 AM, Clayton O'Neill wrote: > >> > >> I think this is a great proposal, but like Matt I’m curious how it > >> might impact the operator sessions that have been part of the Design > >> Summit and the Operators Mid-Cycle. > >> > >> As an operator I got a lot out of the cross-project designs sessions > >> in Tokyo, but they were scheduled at the same time as the Operator > >> sessions. On the other hand, the work sessions clearly aren’t as > >> useful to me. It would be nice would be worked out so that the new > >> design summit replacement was in the same location, and scheduled so > >> that the operator specific parts were overlapping the work sessions > >> instead of the more big picture sessions. > > > > Great question. The current plan is to maintain the ops summit and > > mid-cycle activities. > > > > The new format would allow us to reduce overlap between ops summit and > > cross project sessions at the main event, both for the operators and > > developers who want to be involved in either activity. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] A proposal to separate the design summit
+1 Ghe Rivero Quoting Monty Taylor (2016-02-22 08:31:44) > On 02/22/2016 07:24 AM, Russell Bryant wrote: > > > > > > On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez > <mailto:thie...@openstack.org>> wrote: > > > > Hi everyone, > > > > TL;DR: Let's split the events, starting after Barcelona. > > > > > > This proposal sounds fantastic. Thank you very much to those that help > > put it together. > > Totally agree. I think it's an excellent way to address the concerns and > balance all of the diverse needs we have. > > Thank you very much! > > > __ > 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] [gate] RFC dropping largeops tests
+1, although I would like to keep them to find scale bottlenecks. Maybe when the new infra-cloud is up (we'll have full control over it, includind hw access), we can pin these tests just to it. Ghe Rivero Quoting Sean Dague (2016-02-10 13:33:44) > The largeops tests at this point are mostly finding out that some of our > new cloud providers are slow - http://tinyurl.com/j5u4nf5 > > This is fundamentally a performance test, with timings having been tuned > to pass 98% of the time on two clouds that were very predictable in > performance. We're now running on 4 clouds, and the variance between > them all, and between every run on each can be as much as a factor of 2. > > We could just bump all the timeouts again, but that's basically the same > thing as dropping them. > > These tests are not instrumented in a way that any real solution can be > addressed in most cases. Tests without a path forward, that are failing > good patches a lot, are very much the kind of thing we should remove > from the system. > > -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] [all][tc] Stabilization cycles: Elaborating on the idea to move it forward
Quoting Flavio Percoco (2016-01-25 16:06:36) > On 20/01/16 13:23 -0430, Flavio Percoco wrote: > >Thoughts? Feedback? > > Hey Folks, > > Thanks a lot for the feedback. Great comments and proposals in the many > replies. > I've gone through the whole thread and collected the most common feedback. > Here's the summary: > > - The general idea of planning some sort of stabilization for a project is > good > but considering a cycle for it is terrible. It'd be easier if development > cycles would be shorter but the 6-month based development cycles don't allow > for planning this properly. > > - Therefore, milestones are more likely to be good for this but there has to > be > a good plan. What will happen with on-going features? How does a project > decide what to merge or not? Is it really going to help with reviews/bugs > backlog? or would this just increase the bakclog? There is still a option about having a sorter development cycle. As Thierry said in a previous message in this thread: "It is not entirely impossible that due to events organization we'll accidentally have a shorter cycle (say, 4 months instead of 6) in the future here and there. I could totally see projects take advantage of such a short cycle to place a "stabilization cycle" or another limited-feature-addition period." Would be nice to have more info about it. I guess if he mentioned it, it's because they foundation already faced that possibility. Ghe Rivero > - We shouldn't need any governance resolution/reference for this. Perhaps a > chapter/section on the project team guide should do it. > > - As other changes in the commuity, it'd be awesome to get feedback from a > project doing this before we start encouraging other projects to do the > same. > > > I'll work on adding something to the project team guide that covers the above > points. > > did I miss something? Anything else that we should add and or consider? > > Cheers, > Flavio > > -- > @flaper87 > Flavio Percoco > > > __ > 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] [oslo][osdk] PrettyTable needs a home in OpenStack
#2 makes more sense. Ghe Rivero Quoting Flavio Percoco (2016-01-08 14:06:28) > Greetings, > > As some of you know already, google code is going to be shutdown. Some > projects we're using are hosted and, unfortunately, some of them are > unmaintained and perhaps going away. > > One of these projects is PrettyTable. This point was raised by Erno in > this patch[0] from jd__. PrettyTable is not just being used in several > openstack specific projects but it's also a transitive dependency for > all client libraries using cliff. > > With all that in mind, I've contacted the author of the library and > asked him if it'd be ok for us (OpenStack) to adopt this library. The > author accepted and granted me access to the project on pypi. > > I'm saying all the above because we now need to find a home for it in > OpenStack. > > I've identified 2 possible places: > > 1) Oslo, as we maintaing cross-project libraries and some of them are > not in the oslo namespace > > 2) OpenStack Client team as they maintain cliff already and it'd > perhaps make more sense to have this library there. > > One thing to note is that this library has been quite stable, which > means it won't, hopefully, add too much work to the team. > > Thoughts? > > [0] https://review.openstack.org/#/c/234340/ > > -- > @flaper87 > Flavio Percoco > > > __ > 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] Announcing the OpenStack Health Dashboard
I love it! Thanks for the great job. Ghe Rivero Quoting Matthew Treinish (2015-12-04 21:38:29) > Hi Everyone, > > As some people may have seen already we've been working on creating a test > results dashboard up and running to visualize the state of the tests running > in > the gate. You can get to the dashboard here: > > http://status.openstack.org/openstack-health/#/ > > It's still early for this project (we only started on it back in Sept.), so > not > everything is really polished yet and there are still a couple of issues and > limitations. > > The biggest current limitation is based on the data store. We're using > subunit2sql as the backend for all the data and right now we only are > collecting > results for tempest and grenade runs in the gate and periodic queues. This is > configurable, as any job that emits a subunit stream can use the same > mechanism, > and it is something we will likely change in the future. > > We also don't have any results for runs that fail before tempest starts > running, > since we need a subunit stream to populate the DB with results. However, we > have > several proposed paths to fix this, so it's just a matter of time. But for > right > now if a job fails before tests start running it isn't counted on the > dashboard. > > The code for everything lives here: > > http://git.openstack.org/cgit/openstack/openstack-health/ > > If you find an issue feel free to file a bug here: > > https://bugs.launchpad.net/openstack-health > > We're eager to see this grow to enable the dashboard to suit the needs of > anyone > looking at the gate results. > > We're tracking work items that need to be done here: > > https://etherpad.openstack.org/p/openstack-health-tracking > > Please feel free to contribute if you have an idea on how to improve the > dashboard, or want to take on one of the existing TODO items. The only way > we'll > be able to grow this into something that fits everyone's needs is if more > people > get involved in improving it. > > Thanks, > > Matthew Treinish > > > __ > 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] [os-client-config][infra] Proposing adding infra-core to core
I'm ok with that. The current core group is small and the project is critical enough to have them as backup. Ghe Rivero Quoting Monty Taylor (2015-12-03 17:50:17) > Hey all, > > os-client-config is now in the critical path for Infra's Nodepool, > meaning that there are some places where a bug surfacing in it can take > down the entire CI infrastructure. Infra also uses many more of the > advanced features in clouds.yaml than most other people, so the surface > area that could be tickled is higher than day-to-day use via > openstackclient. > > While this is unlikely to happen, because it's not a high-volume > changing project, it would still be nice to have a safety valve. > > For that reason, and because the os-client-config core group is small in > the first place, I'd like to add the infra-core group as a subgroup to > to os-client-config-core. > > Monty > > __ > 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] [os-client-config] Proposing Morgan Fainberg for core
+1 Quoting Monty Taylor (2015-12-03 17:44:13) > Hey all, > > I'd like to propose that we include Morgan Fainberg as core on > os-client-config. He's in the over/under on matching other active > reviewers on the project, and he's got a good understanding of the > related problem space. Also, he's interested and active, which for a > low-volume project like occ is a godsend. > > Monty > > __ > 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][policy] Exposing hypervisor details to users
Quoting Clint Byrum (2015-11-06 09:07:20) > Whether they are VMs or real machines, our tools > should strive to be about the user and their workload, and not about the > operator and their technology. +1 This should be in a poster in every office. Ghe Rivero __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] -1 due to line length violation in commit messages
If anyone disagrees with the commit format, please, go ahead and fix it (It's really easy using the gerrit web) For such cosmetic changes (and others similars), we should not wait for the author to do it. Sometimes, for a stupid comma, and with all the TZ, a change can need more than a day to be fixed and approved. Ghe Rivero Quoting Ihar Hrachyshka (2015-09-29 18:05:37) > > On 25 Sep 2015, at 16:44, Ihar Hrachyshka wrote: > > > > Hi all, > > > > releases are approaching, so it’s the right time to start some bike > > shedding on the mailing list. > > > > Recently I got pointed out several times [1][2] that I violate our commit > > message requirement [3] for the message lines that says: "Subsequent lines > > should be wrapped at 72 characters.” > > > > I agree that very long commit message lines can be bad, f.e. if they are > > 200+ chars. But <= 79 chars?.. Don’t think so. Especially since we have 79 > > chars limit for the code. > > > > We had a check for the line lengths in openstack-dev/hacking before but it > > was killed [4] as per openstack-dev@ discussion [5]. > > > > I believe commit message lines of <=80 chars are absolutely fine and should > > not get -1 treatment. I propose to raise the limit for the guideline on > > wiki accordingly. > > > > Comments? > > > > [1]: https://review.openstack.org/#/c/224728/6//COMMIT_MSG > > [2]: https://review.openstack.org/#/c/227319/2//COMMIT_MSG > > [3]: > > https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_Git_commit_message_structure > > [4]: https://review.openstack.org/#/c/142585/ > > [5]: > > http://lists.openstack.org/pipermail/openstack-dev/2014-December/thread.html#52519 > > > > Ihar > > Thanks everyone for replies. > > Now I realize WHY we do it with 72 chars and not 80 chars (git log output). > :) I updated the wiki page with how to configure Vim to enforce the rule. I > also removed the notion of gating on commit messages because we have them > removed since recently. > > Ihar > > > __ > 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] [tc] [all] thinking additional tags
Quoting Thierry Carrez (2015-07-08 18:51:42) > Sean Dague wrote: > > Personally, I'm running out of steam on tags for this cycle, but Zane > > brought up a good point in the TC meeting yesterday, which was that "it > > would be nice to have tags for criteria that we used to use for > > integration requirements". I strongly agree with that perspective. > > [...] > > Thanks for bringing that up. As mentioned at the TC meeting yesterday I > plan to set up a small TC workgroup to aggressively look for missing > tags and define them. Russell already signed up, and as all TC > workgroups it can include non-TC members (it's actually a great way to > do succession planning at the TC). > > I'm still stuck on (re)defining the release tags to match the Liberty > release models, but I plan to start working on that soon after. > > Who is in? I'm in! Ghe Rivero > -- > Thierry Carrez (ttx) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic][oslo] Stepping down from oslo-ironic liaison
My focus on the Ironic project has been decreasing in the last cycles, so it's about time to relinquish my position as a oslo-ironic liaison so new contributors can take over it and help ironic to be the vibrant project it is. So long, and thanks for all the fish, Ghe Rivero -- Pinky: "Gee, Brain, what do you want to do tonight?" The Brain: "The same thing we do every night, Pinky—try to take over the world!" .''`. Pienso, Luego Incordio : :' : `. `' `-www.debian.orgwww.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?
Quoting Morgan Fainberg (2015-04-04 02:55:59) > I am looking forward to the Liberty cycle and seeing the special casing we do > for SQLite in our migrations (and elsewhere). My inclination is that we should > (similar to the deprecation of eventlet) deprecate support for SQLite in > Keystone. In Liberty we will have a full functional test suite that can (and > will) be used to validate everything against much more real environments > instead of in-process ?eventlet-like? test-keystone-services; the ?Restful > test > cases? will no longer be part of the standard unit tests (as they are > functional testing). With this change I?m inclined to say SQLite (being the > non-production usable DB) what it is we should look at dropping migration > support for SQLite and the custom work-arounds. > > Most deployers and developers (as far as I know) use devstack and MySQL or > Postgres to really suss out DB interactions. > > I am looking for feedback from the community on the general stance for SQLite, > and more specifically the benefit (if any) of supporting it in Keystone. > > -- > Morgan Fainberg +1 __ 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] [TripleO] nominating James Polley for tripleo-core
+1 On 14 Jan 2015 19:15, "Clint Byrum" wrote: > Hello! It has been a while since we expanded our review team. The > numbers aren't easy to read with recent dips caused by the summit and > holidays. However, I believe James has demonstrated superb review skills > and a commitment to the project that shows broad awareness of the > project. > > Below are the results of a meta-review I did, selecting recent reviews > by James with comments and a final score. I didn't find any reviews by > James that I objected to. > > https://review.openstack.org/#/c/133554/ -- Took charge and provided > valuable feedback. +2 > https://review.openstack.org/#/c/114360/ -- Good -1 asking for better > commit message and then timely follow-up +1 with positive comments for > more improvement. +2 > https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec. > 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this > is only really about 7 - 10 working days and acceptable. +2 > https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of > recent change with alternatives to the approach submitted as patches. > https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in > agreement with everyone else. +1 > https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with > consideration for other reviewers. +2 > https://review.openstack.org/#/c/113983/ -- Thorough spec review with > grammar pedantry noted as something that would not prevent a positive > review score. +2 > > All current tripleo-core members are invited to vote at this time. Thank > you! > > __ > 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] [Ironic] Changing our weekly meeting format
I agree that a lot of time is missed with the announcement and status reports, but mostly because irc is a slow bandwidth communication channel (like waiting several minutes for a 3 lines announcement to be written) I propose that any announcement and project status must be written in advanced to an etherpad, and during the irc meeting just have a slot for people to discuss anything that need further explanation, only mentioning the topic but not the content. Ghe Rivero On Nov 13, 2014 5:08 PM, "Peeyush Gupta" wrote: > +1 > > I agree with Lucas. Sounds like a good idea. I guess if we could spare > more time for discussing new features and requirements rather than > asking for status, that would be helpful for everyone. > > On 11/13/2014 05:45 PM, Lucas Alvares Gomes wrote: > > This was discussed in the Contributor Meetup on Friday at the Summit > > but I think it's important to share on the mail list too so we can get > > more opnions/suggestions/comments about it. > > > > In the Ironic weekly meeting we dedicate a good time of the meeting to > > do some announcements, reporting bug status, CI status, oslo status, > > specific drivers status, etc... It's all good information, but I > > believe that the mail list would be a better place to report it and > > then we can free some time from our meeting to actually discuss > > things. > > > > Are you guys in favor of it? > > > > If so I'd like to propose a new format based on the discussions we had > > in Paris. For the people doing the status report on the meeting, they > > would start adding the status to an etherpad and then we would have a > > responsible person to get this information and send it to the mail > > list once a week. > > > > For the meeting itself we have a wiki page with an agenda[1] which > > everyone can edit to put the topic they want to discuss in the meeting > > there, I think that's fine and works. The only change about it would > > be that we may want freeze the agenda 2 days before the meeting so > > people can take a look at the topics that will be discussed and > > prepare for it; With that we can move forward quicker with the > > discussions because people will be familiar with the topics already. > > > > Let me know what you guys think. > > > > [1] https://wiki.openstack.org/wiki/Meetings/Ironic > > > > Lucas > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Peeyush Gupta > gpeey...@linux.vnet.ibm.com > > > > ___ > 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] [Triple-O] Openstack Onboarding
On 22/10/14 14:40, James Slagle wrote: > On Tue, Oct 21, 2014 at 1:08 PM, Clint Byrum wrote: >> So Tuskar would be a part of that deployment cloud, and would ask you >> things about your hardware, your desired configuration, and help you >> get the inventory loaded. >> >> So, ideally our gate would leave the images we test as part of the >> artifacts for build, and we could just distribute those as part of each >> release. That probably wouldn't be too hard to do, but those images >> aren't exactly small so I would want to have some kind of strategy for >> distributing them and limiting the unique images users are exposed to so >> we're not encouraging people to run CD by downloading each commit's image. > > I think the downloadable images would be great. We've done such a > thing for RDO. And (correct me if I'm wrong), but I think the Helion > community distro does so as well? If that's the use case that seems to > work well downstream, it'd be nice to have a similar model upstream as > well. There has been a patch hanging around for some time to retrieve images and use them for a deployment. https://review.openstack.org/#/c/85130/ I rebased it one week ago, but apparently needs a new one. Will do today. Ghe Rivero ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Meeting time
I vote for Mondays and Thursdays. Ghe Rivero On 08/10/14 10:46, Mehdi Abaakouk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - Mondays at 1600 UTC [1]: #openstack-meeting-alt, #openstack-meeting-3 - Thursdays at 1600 UTC [2]: #openstack-meeting-3 - Thursdays at 1700 UTC [3]: #openstack-meeting-3 - Fridays at 1600 UTC (current time, may be ok when DST ends) [4]: #openstack-meeting-alt, #openstack-meeting-3 I vote for Mondays at 1600 UTC - --- Mehdi Abaakouk mail: sil...@sileht.net irc: sileht -BEGIN PGP SIGNATURE- Version: OpenPGP.js v.1.20131017 Comment: http://openpgpjs.org wsFcBAEBCAAQBQJUNPnLCRAYkrQvzqrryAAAYrsP/3YV2hsDPye3LN8msmKh XuQrVXrWsJtwFezfd0nxZXjEcoWzOS4eRWUh3Khw6FM0AISTDL1yQH9CReEW ZPY60NPBunhdCYJIsIwVfOyQH6ucc7Z1nqwt30Nrb0eEMYvyrM2EYnFbkmkS QzyshpCn7wGVjzHm6DCE/orMNkggSNehUySgFoUkdfmEcwkkXyCtCBXRLrOB x9Of8tSPnwWRUELLQaI8V+xmkpf0cbcwJatz5X4OKa4Enjw/sdlGlnSv12xo 1HkmAXr30gpkI4DjqIbNdVASaKt+C0Y6YQlIALI/R6qzADxCo6IJ84ITAPlE iNM6uQ837I5yV65sYqYIwSIIlG/AurFOjqmLDfXwHCdE4DrRCF193yBVRlHY wWKhHSKoQ3KUBCZAQUdR13oxOOIKEgkUTYRhuq51dy4lZsAz69faLVUGWLSh aoMmGBJCDOWkgwYDTpcTj+bH8aj4SaN6GhMfx8l4ddZmpLPepbzOgAg/HjnY 6+HAx3ZnNUdyDET9HFvgfF7jNf1bCeHzukd6eJ6uId+M6ctkuDPkb2ADAGu3 73CBJphvO1AzeJSykupgXWRln4qoUf4u4PExaqCL6sYWqYLuS7KC+K2fAQSV /80rvlywoKRPJHVsTYKc96ageKwRtQOML1uZxuuVZUUV33fUPfH3+FBqMgUb 1kyS =9Ly5 -END PGP SIGNATURE- ___ 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] sign up for oslo liaisons for kilo cycle
Last cycle the Ironic liaison wasn't a core reviewer and things worked. So I agree with the idea of relaxing the recommendation. Ghe Rivero (Ironic liaison) On 07/10/14 14:50, Doug Hellmann wrote: On Oct 7, 2014, at 7:55 AM, Ihar Hrachyshka wrote: Signed PGP part On 06/10/14 17:56, Doug Hellmann wrote: The Oslo team is responsible for managing code shared between projects. There are a LOT more projects than Oslo team members, so we created the liaison program at the beginning of the Juno cycle, asking each team that uses Oslo libraries to provide one volunteer liaison. Our liaisons facilitate communication and work with us to make the application code changes needed as code moves out of the incubator and into libraries. With this extra help in place, we were able to successfully graduate 7 new libraries and begin having them adopted across OpenStack. With the change-over to the new release cycle, it’s time to ask for volunteers to sign up to be liaisons again. If you are interested in acting as a liaison for your project, please sign up on the wiki page [1]. It would be very helpful to have a full roster before the summit, so we can make sure liaisons are invited to participate in any relevant discussions there. Thanks, Doug [1] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons Quoting the page: "The liaison should be a core reviewer for the project." Is it a reasonable limitation? I suspect that being an Oslo liaison usually does not really require the core status. Any team member with visible level of participation in the project and decent communication skills should be able to do the job. Why I ask: I would probably consider signing up for the liaison program from Neutron side if 1) the program rules would not be that tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be against it. We need someone who can push patches into the project and understands the code well enough to be able to do that without delay. Usually that means a core reviewer. If the Neutron team commits to working closely with you on patches to avoid delays, that would achieve the same ends. Doug ___ 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] [TripleO] Proposal to add Jon Paul Sullivan and Alexis Lee to core review team
+1 El 10/07/2014 10:12, "Macdonald-Wallace, Matthew" < matthew.macdonald-wall...@hp.com> escribió: > +1 from me. > > Matt > > > -Original Message- > > From: Clint Byrum [mailto:cl...@fewbar.com] > > Sent: 09 July 2014 16:52 > > To: openstack-dev@lists.openstack.org > > Subject: [openstack-dev] [TripleO] Proposal to add Jon Paul Sullivan and > Alexis > > Lee to core review team > > > > Hello! > > > > I've been looking at the statistics, and doing a bit of review of the > reviewers, and > > I think we have an opportunity to expand the core reviewer team in > TripleO. We > > absolutely need the help, and I think these two individuals are well > positioned to > > do that. > > > > I would like to draw your attention to this page: > > > > http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt > > > > Specifically these two lines: > > > > > +---+---++ > > | Reviewer | Reviews -2 -1 +1 +2 +A+/- % | > Disagreements* | > > > +---+---++ > > | jonpaul-sullivan | 1880 43 145 0 077.1% | 28 ( > 14.9%) | > > | lxsli | 1860 23 163 0 087.6% | 27 ( > 14.5%) | > > > > Note that they are right at the level we expect, 3 per work day. And > I've looked > > through their reviews and code contributions: it is clear that they > understand > > what we're trying to do in TripleO, and how it all works. I am a little > dismayed at > > the slightly high disagreement rate, but looking through the > disagreements, > > most of them were jp and lxsli being more demanding of submitters, so I > am less > > dismayed. > > > > So, I propose that we add jonpaul-sullivan and lxsli to the TripleO core > reviewer > > team. > > > > ___ > > 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] [TripleO] Alternating meeting time for more TZ friendliness
Hi @all, I like the idea of alternate meetings, so everybody get a chance to make it at decent hours (I can't complaint about that). About the suggested time(any time will have it upsides and downs) 0700UTC, could be a good option (Sorry for the people on the East Coast, but I think our 'population' there is minimal), although something earlier is ok to me. See you all in Atlanta! Ghe Rivero On 05/06/2014 02:58 AM, James Polley wrote: > Actually, it's probably best that we don't do the first meeting at a > US-unfriendly timezone in a week that the summit is on in Atlanta. > > Maybe the week after summit, or even the second week after summit? > > > On Tue, May 6, 2014 at 10:49 AM, James Polley <mailto:j...@jamezpolley.com>> wrote: > > To revive this thread... I'd really like to see us trying out > alternate meeting times for a while. > > > > Tuesdays at 14:00 UTC on #openstack-meeting-alt is available. > > Looking at the iCal feed it looks like it's actually taken by > Solum. But in any case: > > On Thu, Mar 20, 2014 at 11:17 AM, Robert > Collins <mailto:robe...@robertcollins.net>> wrote: > > I think we need a timezone to cover the current impossible > regions: > > - Australia > - China / Japan > - India > > > 1400UTC is midnight Sydney time, 11pm Tokyo, 7:30pm New Delhi. > Personally that's worse for me than 1700UTC. > > I'd prefer to move it significantly later than 1900UTC, especially > if we want a time that's civilized (or at least, achievable) in > India. 0700UTC seems ideal to me - 5pm Sydney, 4pm Tokyo, 12:30pm > New Delhi. It's not friendly to the US (midnight SF, 3am NYC). > but it should work well for Europe - 8am London, and it gets later > in the day as you go east. > > What would we need to do to try this time out next week? > > > On Thu, Mar 20, 2014 at 8:03 PM, <mailto:j...@ioctl.org>> wrote: > > On Wed, 19 Mar 2014, Sullivan, Jon Paul wrote: > > > > From: James Slagle [mailto:james.sla...@gmail.com > <mailto:james.sla...@gmail.com>] > > > Sent: 18 March 2014 19:58 > > > Subject: [openstack-dev] [TripleO] Alternating meeting > time for more TZ > > > friendliness > > > > > > Our current meeting time is Tuesdays at 19:00 UTC. I > think this works > > > ok for most folks in and around North America. > > > > > > It was proposed during today's meeting to see if there is > interest is an > > > alternating meeting time every other week so that we can > be a bit more > > > friendly to those folks that currently can't attend. > > > If that interests you, speak up :). > > > > Speaking up! :D > > Also interested. > > > Tuesdays at 14:00 UTC on #openstack-meeting-alt is available. > > Relatively speaking, that's actually sociable. > > -- > Update your address books: j...@ioctl.org > <mailto:j...@ioctl.org> http://ioctl.org/jan/ > perl -e 's?ck?t??print:perl==pants if $_="Just Another Perl > Hacker\n"' > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] should we have an IRC meeting next week ?
Hi all! I can attend, but since is the recomended 'Off Week' (https://wiki.openstack.org/wiki/Icehouse_Release_Schedule) (Yeah. It's weird a week start on Thursday) we could skip it. Ghe Rivero On 05/01/2014 04:07 PM, Matt Wagner wrote: > On 30/04/14 15:37 -0700, Devananda van der Veen wrote: >> Hi all, >> >> Just a reminder that May 5th is our next scheduled meeting day, but I >> probably won't make it, because I'll be just getting back from one >> trip and >> start two consecutive weeks of conference travel early the next morning. >> Chris Krelle (nobodycam) has offered to chair that meeting in my >> absence. >> The agenda looks pretty light at this point, and any serious discussions >> should just be punted to the summit anyway, so if folks want to >> cancel the >> meeting, I think that's fine. > > I would attend, though I personally have nothing to propose. > > > ___ > 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] review hour?
+1 for the alternate slots. Ghe Rivero El 21/04/2014 17:57, "mar...@redhat.com" escribió: > > On 21/04/14 18:29, Kyle Mestery wrote: > > On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com wrote: > >> Hi, > >> > >> I think both PTL candidates mentioned process improvements wrt > >> contributions and reviews in their candidacy announcements. As a new > >> Neutron dev I have seen that it is easy for reviews to go unnoticed, > >> especially when they are stand-alone bug fixes that aren't part of a > >> particular blueprint group (and so aren't discussed/highlighted at the > >> various sub-team meetings). Of course this is also compounded by a > >> seemingly heavy backlog of reviews. I realise that all core/non-core > >> devs are doing as much as they can and though more cores will help, it > >> takes a long time to develop people into this role. > >> > >> I was wondering if a 'review hour' would help. This is something Lucas > >> Gomez told me about; the Ironic core team has a weekly hour slot in > >> which they discuss x number of reviews and approve or -1 them. Besides > >> getting reviews cleared quicker, it also opens the process up. It will > >> allow new contributors to (more quickly) learn about the kinds of things > >> core reviewers look for in a patch and also give real-time feedback > >> (e.g. could just use #openstack-neutron for discussion during the hour). > >> I feel that this could have an impact on the review backlog even if this > >> only tackling the oldest 5 reviews for example. > >> > >> Do any of the core devs think this would be a good thing, and do you > >> think you have the time for it? > >> > > This is an interesting idea Marios, thanks for proposing it! Are you > > saying we should have a "Review Hour" on IRC, where we walk through XX > > number of reviews as a team? That's an interesting idea actually, and > > I'd be in favor of something like this. We could rotate timeslots so > > as to get everyone on the team (both core and non-core) a chance to > > participate. > > > > Can you attend our weekly meeting today [1] where we can discuss this as a team? > > Thanks very much for responding Kyle, I was worried about my message > sounding 'complainy' - I will try my best to attend the meeting today, > though it is at midnight here (CET +1hrs) so I typically only get to > catch up on the logs. > > Depending on whether others think setting up the "irc review hour" is a > good idea, one side effect would be that we then have a second 'neutron > meeting' slot during the week (even if this is only for reviews). If we > pick this time carefully we could even alternate between 'weekly > meeting' and 'review meeting' to make it easier for folks in Europe to > join the weekly meeting (and make it less harsh for people in Asia > Pacific who have to get up very early for the current slot [1]). Though > this is of course just speculation and I'm really getting ahead of > myself (I was going to include this last thought in my original email > but it was already long enough) > > thanks, marios > > > [1] [1] > http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140421&p1=137&p2=179&p3=136&p4=37&p5=166&p6=248&p7=196&p8=47 > > > > > Thanks! > > Kyle > > > > [1] https://wiki.openstack.org/wiki/Network/Meetings > > > >> thanks, marios > >> > >> ___ > >> 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
Re: [openstack-dev] [tripleo] Default paths in os-*-config projects
+1 for the use of /usr/share and keeping the compatibility for a couple of releases. Ghe Rivero On 04/15/2014 03:30 AM, Clint Byrum wrote: > Excerpts from Ben Nemec's message of 2014-04-14 15:41:23 -0700: >> Right now the os-*-config projects default to looking for their files in >> /opt/stack, with an override env var provided for other locations. For >> packaging purposes it would be nice if they defaulted to a more >> FHS-compliant location like /var/lib. For devtest we could either >> override the env var or simply install the appropriate files to /var/lib. >> >> This was discussed briefly in IRC and everyone seemed to be onboard with >> the change, but Robert wanted to run it by the list before we make any >> changes. If anyone objects to changing the default, please reply here. >> I'll take silence as agreement with the move. :-) >> > +1 from me for doing FHS compliance. :) > > /var/lib is not actually FHS compliant as it is for "Variable state > information". os-collect-config does have such things, and does use > /var/lib. But os-refresh-config reads executables and os-apply-config > reads templates, neither of which will ever be "variable state > information". > > /usr/share would be the right place, as it is "Architecture independent > data". I suppose if somebody wants to compile a C program as an o-r-c > script we could rethink that, but I'd just suggest they drop it in a bin > dir and exec it from a one line shell script in the /usr/share. > > So anyway, I suggest: > > /usr/share/os-apply-config/templates > /usr/share/os-refresh-config/scripts > > With the usual hierarchy underneath. > > We'll need to continue to support the non-FHS paths for at least a few > releases as well. > > ___ > 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] [tripleo] /bin/bash vs. /bin/sh
+1 to use bash as the default shell. So far, all major distros use bash as the default one (except Debian which uses dash). An about rewriting the code in Python, I agree that shell is complicated for large programs, but writing anything command oriented in other than shell is a nightmare. But there are some parts that can benefit from that. Ghe Rivero On 04/15/2014 11:05 AM, Chris Jones wrote: > Hi > > On 15 April 2014 09:14, Daniel P. Berrange <mailto:berra...@redhat.com>> wrote: > > I supose that rewriting the code to be in Python is out of the > question ? IMHO shell is just a terrible language for doing any > program that is remotely complicated (ie longer than 10 lines of > > > I don't think it's out of the question - where something makes sense > to switch to Python, that would seem like a worthwhile thing to be > doing. I do think it's a different question though - we can quickly > flip things from /bin/sh to /bin/bash without affecting their > suitability for replacement with python. > > -- > Cheers, > > Chris > > > ___ > 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] starting regular meetings
1600 UTC for me is ok. Later than that in Europe (Friday afternoon/night) could be a problem. Ghe Rivero On 04/14/2014 10:56 PM, Doug Hellmann wrote: > That may work. Let's see what the team members in Europe say about the > proposed times. > > Doug > > On Mon, Apr 14, 2014 at 3:04 PM, Joshua Harlow wrote: >> Lets try that (1600) out and see how it goes :) >> >> I've seen other projects setup alternating times, maybe we could do that >> too? >> >> One week @ 1600UTC, next week @ 2000UTC (and so-on). >> >> -Original Message- >> From: Doug Hellmann >> Date: Monday, April 14, 2014 at 11:53 AM >> To: Joshua Harlow >> Cc: "OpenStack Development Mailing List (not for usage questions)" >> >> Subject: Re: [openstack-dev] [oslo] starting regular meetings >> >>> Balancing Europe and Pacific TZs is going to be a challenge. I can't >>> go at 1800 or 1900, myself, and those are pushing a little late in >>> Europe anyway. >>> >>> How about 1600? >>> http://www.timeanddate.com/worldclock/converted.html?iso=20140414T16&p1=0&; >>> p2=2133&p3=195&p4=224 >>> >>> We would need to move to another room, but that's not a big deal. >>> >>> Doug >>> >>> On Mon, Apr 14, 2014 at 1:54 PM, Joshua Harlow >>> wrote: >>>> Is anything around 1800 UTC or 1900 UTC possible? >>>> >>>> I'll try to be there, 1400 UTC is pretty early for us pacific coast >>>> folk. >>>> >>>> -Original Message- >>>> From: Doug Hellmann >>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >>>> >>>> Date: Monday, April 14, 2014 at 9:07 AM >>>> To: OpenStack Development Mailing List >>>> >>>> Subject: [openstack-dev] [oslo] starting regular meetings >>>> >>>>> The Oslo team has had a regular meeting slot on Friday at 1400 UTC. In >>>>> the past, we only held meetings irregularly when we had something >>>>> definite to discuss. During Juno, I expect us to need to coordinate >>>>> more closely with the new liaison team as well as internally, so I >>>>> would like to start holding regular weekly meetings. >>>>> >>>>> Is the Friday 1400 UTC time slot inconvenient enough to anyone that >>>>> you couldn't make a regular meeting? We can work out another slot, if >>>>> needed. >>>>> >>>>> Since there isn't likely to be time to find another slot this week, >>>>> please plan to join the meeting in #openstack-meeting this week on 18 >>>>> Apr. If you have anything you would like to discuss, please add it to >>>>> the agenda: >>>>> https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting >>>>> >>>>> Doug >>>>> >>>>> ___ >>>>> 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] [TripleO] reviewer update march [additional cores]
+1 for the -core changes On 04/08/2014 01:50 AM, Robert Collins wrote: > tl;dr: 3 more core members to propose: > bnemec > greghaynes > jdon > > > On 4 April 2014 08:55, Chris Jones wrote: >> Hi >> >> +1 for your proposed -core changes. >> >> Re your question about whether we should retroactively apply the 3-a-day >> rule to the 3 month review stats, my suggestion would be a qualified no. >> >> I think we've established an agile approach to the member list of -core, so >> if there are a one or two people who we would have added to -core before the >> goalposts moved, I'd say look at their review quality. If they're showing >> the right stuff, let's get them in and helping. If they don't feel our new >> goalposts are achievable with their workload, they'll fall out again >> naturally before long. > So I've actioned the prior vote. > > I said: "Bnemec, jdob, greg etc - good stuff, I value your reviews > already, but..." > > So... looking at a few things - long period of reviews: > 60 days: > |greghaynes | 1210 22 99 0 081.8% | > 14 ( 11.6%) | > | bnemec | 1160 38 78 0 067.2% | > 10 ( 8.6%) | > | jdob | 870 15 72 0 082.8% | > 4 ( 4.6%) | > > 90 days: > > | bnemec | 1450 40 105 0 072.4% | > 17 ( 11.7%) | > |greghaynes | 1420 23 119 0 083.8% | > 22 ( 15.5%) | > | jdob | 1060 17 89 0 084.0% | > 7 ( 6.6%) | > > Ben's reviews are thorough, he reviews across all contributors, he > shows good depth of knowledge and awareness across tripleo, and is > sensitive to the pragmatic balance between 'right' and 'good enough'. > I'm delighted to support him for core now. > > Greg is very active, reviewing across all contributors with pretty > good knowledge and awareness. I'd like to see a little more contextual > awareness though - theres a few (but not many) reviews where looking > at how the big picture of things fitting together more would have been > beneficial. *however*, I think that's a room-to-improve issue vs > not-good-enough-for-core - to me it makes sense to propose him for > core too. > > Jay's reviews are also very good and consistent, somewhere between > Greg and Ben in terms of bigger-context awareness - so another > definite +1 from me. > > -Rob > > > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] review days
> What time would work for you? How about Thursdays at 8am PST? Works for me! Ghe Rivero ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] os-*-config in tripleo repositories
Hi all, On Thu, Jan 09, 2014 at 01:13:53PM +, Derek Higgins wrote: > It looks like we have some duplication and inconsistencies on the 3 > os-*-config elements in the tripleo repositories > > os-apply-config (duplication) : >We have two elements that install this > diskimage-builder/elements/config-applier/ > tripleo-image-elements/elements/os-apply-config/ > >As far as I can tell the version in diskimage-builder isn't used by > tripleo and the upstart file is broke > ./dmesg:[ 13.336184] init: Failed to spawn config-applier main > process: unable to execute: No such file or directory > >To avoid confusion I propose we remove > diskimage-builder/elements/config-applier/ (or deprecated if we have a > suitable process) but would like to call it out here first to see if > anybody is using it or thinks its a bad idea? Too late, it's already removed :) http://git.openstack.org/cgit/openstack/diskimage-builder/commit/?id=63a4c1e9d52d57e0f82a6fa2f89f745592f1a2de > inconsistencies > os-collect-config, os-refresh-config : these are both installed from > git into the global site-packages > os-apply-config : installed from a released tarball into its own venv > > To be consistent with the other elements all 3 I think should be > installed from git into its own venv, thoughts? > > If no objections I'll go ahead an do this next week, > I will add another one: Some elements are already using the old os-config-applier dir to store the configuration templates. It works, but I think is time to move them to os-apply-config to avoid confusion. Ghe Rivero ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
I haven't look at the review proposed yet one week ago, but some time ago, we needed something similar for Ironic (nova, ironic and cinder share almost the same code for the glance driver), but didn't make it. In case someone wants to take a look: https://review.openstack.org/#/c/33327/ I'll take a look to the bp and the solutions proposed to see if something can be reused. Ghe Rivero On Tue, Oct 29, 2013 at 1:19 PM, John Garbutt wrote: > Going back to Joe's comment: > > Can both of these cases be covered by configuring the keystone catalog? > +1 > > If both v1 and v2 are present, pick v2, otherwise just pick what is in > the catalogue. That seems cool. Not quite sure how the multiple glance > endpoints works in the keystone catalog, but should work I assume. > > We hard code nova right now, and so we probably want to keep that route > too? > > From: "Russell Bryant" > > On 10/17/2013 03:12 PM, Eddie Sheffield wrote: > >> Might I propose a compromise? > >> > >> 1) For the VERY short term, keep the config value and get the change > otherwise reviewed and hopefully accepted. > >> > >> 2) Immediately file two blueprints: > >>- python-glanceclient - expose a way to discover available versions > >>- nova - depends on the glanceclient bp and allowing autodiscovery > of glance version > >> and making the config value optional (tho not deprecated / > removed) > > > > Supporting both seems reasonable. At least then *most* people don't > > need to worry about it and it "just works", but the override is there if > > necessary, since multiple people seem to be expressing a desire to have > > it available. > > +1 > > > Can we just do this all at once? Adding this to glanceclient doesn't > > seem like a huge task. > > I worry about us never getting the full solution, but it seems to have > got complicated. > > On 28 October 2013 15:13, Eddie Sheffield > wrote: > > So...I've been working on this some more and hit a bit of a snag. The > Glanceclient change was easy, but I see now that doing this in nova will > require a pretty huge change in the way things work. Currently, the API > version is grabbed from the config value, the appropriate driver is > instantiated, and calls go through that. The problem comes in that the > actually glance server isn't communicated with until very late in the > process. Nothing "sees" the servers at the level where the driver is > determined. Also there isn't a single glance server but a list of them, and > in the even of certain communication failures the list is cycled through > until success or a number of retries has passed. > > > > So to change this to auto configuring will require turning this upside > down, cycling through the servers at a higher level, choosing the > appropriate driver for that server, and handling retries at that same level. > > > > Doable, but a much larger task than I first was thinking. > > > > Also, I don't really want the added overhead of getting the api versions > before every call, so I'm thinking that going through the list of servers > at startup and discovering the versions then and caching that somehow would > be helpful as well. > > > > Thoughts? > > I do worry about that overhead. But with Joe's comment, does it not > just boil down to caching the keystone catalog in the context? > > I am not a fan of all the specific talk to glance code we have in > nova, moving more of that into glanceclient can only be a good thing. > For the XenServer itegration, for efficiency reasons, we need glance > to talk from dom0, so it has dom0 making the final HTTP call. So we > would need a way of extracting that info from the glance client. But > that seems better than having that code in nova. > > John > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Pinky: "Gee, Brain, what do you want to do tonight?" The Brain: "The same thing we do every night, Pinky—try to take over the world!" .''`. Pienso, Luego Incordio : :' : `. `' `-www.debian.orgwww.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Nominating Lucas Gomes to ironic core
+1 On Fri, Oct 25, 2013 at 2:18 AM, Devananda van der Veen < devananda@gmail.com> wrote: > Hi all, > > I'd like to nominate Lucas Gomes for ironic-core. He's been consistently > doing reviews for several months and has led a lot of the effort on the API > and client libraries. > > Thanks for the great work! > -Deva > > http://russellbryant.net/openstack-stats/ironic-reviewers-90.txt > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Pinky: "Gee, Brain, what do you want to do tonight?" The Brain: "The same thing we do every night, Pinky—try to take over the world!" .''`. Pienso, Luego Incordio : :' : `. `' `-www.debian.orgwww.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TRIPLEO] Derekh for tripleo core
+1 On Wed, Aug 28, 2013 at 10:18 AM, Lucas Alvares Gomes wrote: > > So - calling for votes for Derek to become a TripleO core reviewer! > > +1 > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Pinky: "Gee, Brain, what do you want to do tonight?" The Brain: "The same thing we do every night, Pinky—try to take over the world!" .''`. Pienso, Luego Incordio : :' : `. `' `-www.debian.orgwww.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Nomination to add Chris Krelle to ironic core
+1 On Wed, Jul 31, 2013 at 6:10 PM, Devananda van der Veen < devananda@gmail.com> wrote: > Hi, > > I'd like to propose to add Chris (NobodyCam) to ironic-core. He has been > doing a lot of good reviews and running the weekly meetings when I've been > unavailable due to travel. > > > Cheers, > Devananda > > > ** > http://russellbryant.net/openstack-stats/ironic-reviewers-90.txt > > +---+---+ > |Reviewer | Reviews (-2|-1|+1|+2) (+/- ratio) | > +---+---+ > | devananda ** | 175 (5|40|0|130) (74.3%) | > | nobodycam | 98 (0|36|62|0) (63.3%) | > |anteaya| 81 (0|15|66|0) (81.5%) | > | lucasagomes | 38 (0|7|31|0) (81.6%) | > | prykhodchenko | 28 (0|10|18|0) (64.3%) | > | jiangwt100 | 19 (0|1|18|0) (94.7%) | > | lifeless ** | 15 (0|12|0|3) (20.0%) | > | jogo |7 (0|4|3|0) (42.9%)| > | sdague ** |7 (0|4|0|3) (42.9%)| > |mtaylor| 4 (0|4|0|0) (0.0%)| > | markmc|2 (0|1|1|0) (50.0%)| > | yuriyz| 1 (0|1|0|0) (0.0%)| > | ghe.rivero |1 (0|0|1|0) (100.0%) | > | eglynn|1 (0|0|1|0) (100.0%) | > | doug-hellmann |1 (0|0|1|0) (100.0%) | > | dmllr |1 (0|0|1|0) (100.0%) | > | danms |1 (0|0|1|0) (100.0%) | > +---+---+ > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Pinky: "Gee, Brain, what do you want to do tonight?" The Brain: "The same thing we do every night, Pinky—try to take over the world!" .''`. Pienso, Luego Incordio : :' : `. `' `-www.debian.orgwww.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Glance Image List
As admin, use the parameter is_public='none' to retrieve all the images(using v1 api). With v2 api, there is no need for a extra parameter (also as admin). Ghe Rivero On Mon, Jul 29, 2013 at 11:29 PM, Nikhil Komawar < nikhil.koma...@rackspace.com> wrote: > you could always try using the user as an admin or an admin user itself! > > > > thanks, > > -Nikhil > > > > -Original Message- > From: "Jacob Godin" > Sent: Monday, July 29, 2013 5:22pm > To: "openstack-dev@lists.openstack.org" > > Subject: [openstack-dev] Glance Image List > > Hey all, > Does anyone know if there is builtin functionality to list images for all > tenants? If not, is there a best practice? I'm using Python APIs. > Thanks! > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Pinky: "Gee, Brain, what do you want to do tonight?" The Brain: "The same thing we do every night, Pinky—try to take over the world!" .''`. Pienso, Luego Incordio : :' : `. `' `-www.debian.orgwww.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] mid-cycle sprint?
On Thu, Jul 11, 2013 at 9:43 AM, Clint Byrum wrote: > Excerpts from Robert Collins's message of 2013-07-10 20:54:26 -0700: > > Clint suggested we do a mid-cycle sprint at the weekly meeting a > > fortnight ago, but ETIME and stuff - so I'm following up. > > > > HP would be delighted to host a get-together of TripleO contributors > > [or 'I will be contributing soon, honest'] folk. > > > > We're proposing a late August / early Sept time - a couple weeks > > before H3, so we can be dealing with features that have landed // > > ensuring necessary features *do* land. > > > > That would give a start date of the 19th or 26th August. Probable > > venue of either Sunnyvale, CA or Seattle. > > Wife booked a trip out of town August 27 - Sep 2 so that time frame is > unavailable to me. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > I'll be in DebConf13 (Switzerland) the week of August 11th-17th so I prefer the week of the 19th. Ghe Rivero -- Pinky: "Gee, Brain, what do you want to do tonight?" The Brain: "The same thing we do every night, Pinky—try to take over the world!" .''`. Pienso, Luego Incordio : :' : `. `' `-www.debian.orgwww.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
