Re: [openstack-dev] [oslo][db] Nominating Mike Bayer for the oslo.db core reviewers team
+1 from me!! On Fri, Aug 15, 2014 at 4:30 PM, Morgan Fainberg wrote: > > -Original Message- > From: Doug Hellmann > Reply: OpenStack Development Mailing List (not for usage questions) > > > Date: August 15, 2014 at 13:29:15 > To: Ben Nemec >, OpenStack Development Mailing List > (not for usage questions) > > Subject: Re: [openstack-dev] [oslo][db] Nominating Mike Bayer for the > oslo.db core reviewers team > >> >> On Aug 15, 2014, at 10:00 AM, Ben Nemec wrote: >> >> > On 08/15/2014 08:20 AM, Russell Bryant wrote: >> >> On 08/15/2014 09:13 AM, Jay Pipes wrote: >> >>> On 08/15/2014 04:21 AM, Roman Podoliaka wrote: >> >>>> Hi Oslo team, >> >>>> >> >>>> I propose that we add Mike Bayer (zzzeek) to the oslo.db core >> >>>> reviewers team. >> >>>> >> >>>> Mike is an author of SQLAlchemy, Alembic, Mako Templates and some >> >>>> other stuff we use in OpenStack. Mike has been working on OpenStack >> >>>> for a few months contributing a lot of good patches and code reviews >> >>>> to oslo.db [1]. He has also been revising the db patterns in our >> >>>> projects and prepared a plan how to solve some of the problems we have >> >>>> [2]. >> >>>> >> >>>> I think, Mike would be a good addition to the team. >> >>> >> >>> Uhm, yeah... +10 :) >> >> >> >> ^2 :-) >> >> >> > >> > What took us so long to do this? :-) >> > >> > +1 obviously. >> >> I did think it would be a good idea to wait a *little* while and make sure >> we weren’t going >> to scare him off. ;-) >> >> Seriously, Mike has been doing a great job collaborating with the existing >> team and helping >> us make oslo.db sane. >> >> +1 >> >> Doug > > > Big +1 from me. Mike has been great across the board (I know I’m not oslo > core) > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Issues with POSIX semaphores and other locks in lockutils
Ben, +1 to the plan you outlined. -- dims On Wed, Aug 20, 2014 at 4:13 PM, Ben Nemec wrote: > On 08/20/2014 01:03 PM, Vishvananda Ishaya wrote: >> This may be slightly off-topic but it is worth mentioning that the use of >> threading.Lock[1] >> which was included to make the locks thread safe seems to be leading to a >> deadlock in eventlet[2]. >> It seems like we have rewritten this too many times in order to fix minor >> pain points and are >> adding risk to a very important component of the system. >> >> [1] https://review.openstack.org/#/c/54581 >> [2] https://bugs.launchpad.net/nova/+bug/1349452 > > This is pretty much why I'm pushing to just revert to the file locking > behavior we had up until a couple of months ago, rather than > implementing some new shiny lock thing that will probably cause more > subtle issues in the consuming projects. It's become clear to me that > lockutils is too deeply embedded in the other projects, and there are > too many implementation details that they rely on, to make significant > changes to its default code path. > >> >> On Aug 18, 2014, at 2:05 PM, Pádraig Brady wrote: >> >>> On 08/18/2014 03:38 PM, Julien Danjou wrote: >>>> On Thu, Aug 14 2014, Yuriy Taraday wrote: >>>> >>>> Hi Yuriy, >>>> >>>> […] >>>> >>>>> Looking forward to your opinions. >>>> >>>> This looks like a good summary of the situation. >>>> >>>> I've added a solution E based on pthread, but didn't get very far about >>>> it for now. >>> >>> In my experience I would just go with the fcntl locks. >>> They're auto unlocked and well supported, and importantly, >>> supported for distributed processes. >>> >>> I'm not sure how problematic the lock_path config is TBH. >>> That is adjusted automatically in certain cases where needed anyway. >>> >>> Pádraig. >>> >>> ___ >>> 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 -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Launchpad tracking of oslo projects
Sounds like a good plan going forward @ttx.
On Fri, Aug 22, 2014 at 5:59 AM, Thierry Carrez wrote:
> TL;DR:
> Let's create an Oslo projectgroup in Launchpad to track work across all
> Oslo libraries. In library projects, let's use milestones connected to
> published versions rather than the common milestones.
>
> Long version:
> As we graduate more Oslo libraries (which is awesome), tracking Oslo
> work in Launchpad (bugs, milestones...) has become more difficult.
>
> There used to be only one Launchpad project ("oslo", which covered the
> oslo incubator). It would loosely follow the integrated milestones
> (juno-1, juno-2...), get blueprints and bugs targeted to those, get tags
> pushed around those development milestones: same as the integrated
> projects, just with no source code tarball uploads.
>
> When oslo.messaging graduated, a specific Launchpad project was created
> to track work around it. It still had integrated development milestones
> -- only at the end it would publish a 1.4.0 release instead of a 2014.2
> one. That approach creates two problems. First, it's difficult to keep
> track of "oslo" work since it now spans two projects. Second, the
> release management logic of marking bugs "Fix released" at development
> milestones doesn't really apply (bugs should rather be marked released
> when a published version of the lib carries the fix). Git tags and
> Launchpad milestones no longer align, which creates a lot of confusion.
>
> Then as more libraries appeared, some of them piggybacked on the general
> "oslo" Launchpad project (generally adding tags to point to the specific
> library), and some others created their own project. More confusion ensues.
>
> Here is a proposal that we could use to solve that, until StoryBoard
> gets proper milestone support and Oslo is just migrated to it:
>
> 1. Ask for an "oslo" project group in Launchpad
>
> This would solve the first issue, by allowing to see all oslo work on
> single pages (see examples at [1] or [2]). The trade-off here is that
> Launchpad projects can't be part of multiple project groups (and project
> groups can't belong to project groups). That means that Oslo projects
> will no longer be in the "openstack" Launchpad projectgroup. I think the
> benefits outweigh the drawbacks here: the openstack projectgroup is not
> very strict anyway so I don't think it's used in people workflows that much.
>
> 2. Create one project per library, adopt tag-based milestones
>
> Each graduated library should get its own project (part of the oslo
> projectgroup). It should use the same series/cycles as everyone else
> ("juno"), but it should have milestones that match the alpha release
> tags, so that you can target work to it and mark them "fix released"
> when that means the fix is released. That would solve the issue of
> misaligned tags/milestones. The trade-off here is that you lose the
> common milestone rhythm (although I guess you can still align some
> alphas to the common development milestones). That sounds a small price
> to pay to better communicate which version has which fix.
>
> 3. Rename "oslo" project to "oslo-incubator"
>
> Keep the Launchpad "oslo" project as-is, part of the same projectgroup,
> to cover oslo-incubator work. This can keep the common development
> milestones, since the incubator doesn't do "releases" anyway. However,
> it has to be renamed to "oslo-incubator" so that it doesn't conflict
> with the projectgroup namespace. Once it no longer contains graduated
> libs, that name makes much more sense anyway.
>
>
> This plan requires Launchpad admin assistance to create a projectgroup
> and rename a project, so I'd like to get approval on it before moving to
> ask them for help.
>
> Comments, thoughts ?
>
> [1] https://blueprints.launchpad.net/openstack
> [2] https://bugs.launchpad.net/openstack
>
> --
> Thierry Carrez (ttx)
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Davanum Srinivas :: http://davanum.wordpress.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] library feature freeze and final releases
Doug, plan is good. Same criteria will mean exception for oslo.log as well -- dims On Tue, Sep 2, 2014 at 9:20 AM, Doug Hellmann wrote: > Oslo team, > > We need to consider how we are going to handle the approaching feature freeze > deadline (4 Sept). We should, at this point, be focusing reviews on changes > associated with blueprints. We will have time to finish graduation work and > handle bugs between the freeze and the release candidate deadline, but > obviously it’s OK to review those now, too. > > I propose that we apply the feature freeze rules to the incubator and any > library that has had a release this cycle and is being used by any other > project, but that libraries still being graduated not be frozen. I think that > gives us exceptions for oslo.concurrency, oslo.serialization, and > oslo.middleware. All of the other libraries should be planning to freeze new > feature work this week. > > The app RC1 period starts 25 Sept, so we should be prepared to tag our final > releases of libraries before then to ensure those final releases don’t > introduce issues into the apps when they are released. We will apply 1.0 tags > to the same commits that have the last alpha in the release series for each > library, and then focus on fixing any bugs that come up during the release > candidate period. I propose that we tag our releases on 18 Sept, to give us a > few days to fix any issues that arise before the RC period starts. > > Please let me know if you spot any issues with this plan. > > Doug > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] instance lock and class lock
Zang MingJie, Can you please consider submitting a review against oslo.concurrency? http://git.openstack.org/cgit/openstack/oslo.concurrency/tree/oslo/concurrency That will help everyone who will adopt/use that library. thanks, dims On Wed, Sep 3, 2014 at 1:45 AM, Zang MingJie wrote: > Hi all: > > currently oslo provides lock utility, but unlike other languages, it is > class lock, which prevent all instances call the function. IMO, oslo should > provide an instance lock, only lock current instance to gain better > concurrency. > > I have written a lock in a patch[1], please consider pick it into oslo > > [1] > https://review.openstack.org/#/c/114154/4/neutron/openstack/common/lockutils.py > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] instance lock and class lock
given the code size, a BP may be a over stretch. I'd just file a review + bug -- dims On Fri, Sep 5, 2014 at 1:29 AM, Zang MingJie wrote: > does it require bp or bug report to submit oslo.concurrency patch ? > > > On Wed, Sep 3, 2014 at 7:15 PM, Davanum Srinivas wrote: >> >> Zang MingJie, >> >> Can you please consider submitting a review against oslo.concurrency? >> >> >> http://git.openstack.org/cgit/openstack/oslo.concurrency/tree/oslo/concurrency >> >> That will help everyone who will adopt/use that library. >> >> thanks, >> dims >> >> On Wed, Sep 3, 2014 at 1:45 AM, Zang MingJie wrote: >> > Hi all: >> > >> > currently oslo provides lock utility, but unlike other languages, it is >> > class lock, which prevent all instances call the function. IMO, oslo >> > should >> > provide an instance lock, only lock current instance to gain better >> > concurrency. >> > >> > I have written a lock in a patch[1], please consider pick it into oslo >> > >> > [1] >> > >> > https://review.openstack.org/#/c/114154/4/neutron/openstack/common/lockutils.py >> > >> > ___ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> >> >> -- >> Davanum Srinivas :: http://davanum.wordpress.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 > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Anticipated Final Release Versions for Juno
LGTM Doug. for oslo.vmware - we need a fresh rev for use by Nova to fix the following bug: https://bugs.launchpad.net/nova/+bug/1341954 thanks, dims On Mon, Sep 8, 2014 at 2:32 PM, Doug Hellmann wrote: > I spent some time today looking over our current set of libraries trying to > anticipate which will be ready for 1.0 (or later) and which are still > considered pre-release. I came up with this set of anticipated version > numbers for our final juno releases. Please let me know if you see any > surprises on the list. > > 1.0 or later > > oslo.config - 1.4.0 > oslo.i18n - 1.0.0 > oslo.messaging - 1.4.0 > oslo.rootwrap - 1.3.0 > oslo.serialization - 1.0.0 > oslosphinx - 2.2.0 > oslotest - 1.1.0 > oslo.utils - 1.0.0 > cliff - 1.7.x > stevedore - 1.0.0 > > Alphas or Pre-releases (Trying for 1.0 for Kilo) > > oslo.concurrency - < 1.0 > oslo.log - 0.1.0 > oslo.middleware - 0.1.0 > pbr - < 1.0 > taskflow - < 1.0 > > Unknown > > oslo.db - I think we said 1.0.0 but I need to confirm. > oslo.vmware - I’ll need to talk to the vmware team to see where things stand > with their release plans. > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers
Rados, personally, i'd want a human to do the +W. Also the critieria would include a 3) which is the CI for the driver if applicable. On Thu, Sep 11, 2014 at 9:53 AM, Radoslav Gerganov wrote: > On 09/11/2014 04:30 PM, Sean Dague wrote: >> >> On 09/11/2014 09:09 AM, Gary Kotton wrote: >>> >>> >>> >>> On 9/11/14, 2:55 PM, "Thierry Carrez" wrote: >>> >>>> Sean Dague wrote: >>>>> >>>>> [...] >>>>> Why don't we start with "let's clean up the virt interface and make it >>>>> more sane", as I don't think there is any disagreement there. If it's >>>>> going to take a cycle, it's going to take a cycle anyway (it will >>>>> probably take 2 cycles, realistically, we always underestimate these >>>>> things, remember when no-db-compute was going to be 1 cycle?). I don't >>>>> see the need to actually decide here and now that the split is clearly >>>>> at least 7 - 12 months away. A lot happens in the intervening time. >>>> >>>> >>>> Yes, that sounds like the logical next step. We can't split drivers >>>> without first doing that anyway. I still think "people need smaller >>>> areas of work", as Vish eloquently put it. I still hope that refactoring >>>> our test architecture will let us reach the same level of quality with >>>> only a fraction of the tests being run at the gate, which should address >>>> most of the harm you see in adding additional repositories. But I agree >>>> there is little point in discussing splitting virt drivers (or anything >>>> else, really) until the internal interface below that potential split is >>>> fully cleaned up and it becomes an option. >>> >>> >>> How about we start to try and patch gerrit to provide +2 permissions for >>> people >>> Who can be assigned Œdriver core¹ status. This is something that is >>> relevant to Nova and Neutron and I guess Cinder too. >> >> >> If you think that's the right solution, I'd say go and investigate it >> with folks that understand enough gerrit internals to be able to figure >> out how hard it would be. Start a conversation in #openstack-infra to >> explore it. >> >> My expectation is that there is more complexity there than you give it >> credit for. That being said one of the biggest limitations we've had on >> gerrit changes is we've effectively only got one community member, Kai, >> who does any of that. If other people, or teams, were willing to dig in >> and own things like this, that might be really helpful. > > > I don't think we need to modify gerrit to support this functionality. We can > simply have a gerrit job (similar to the existing CI jobs) which is run on > every patch set and checks if: > 1) the changes are only under /nova/virt/XYZ and /nova/tests/virt/XYZ > 2) it has two +1 from maintainers of driver XYZ > > if the above conditions are met, the job will post W+1 for this patchset. > Does that make sense? > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] oslo.vmware 0.6.0 released
The Oslo team is pleased to release version 0.6.0 of oslo.vmware. This release includes: $ git log --oneline --no-merges 0.5.0..0.6.0 f36cd7f Add DuplicateName exception 81ef9d4 Add 'details' property to VMwareDriverException 5571e9f Enable oslo.i18n for oslo.vmware 6c24953 Add API to enable calling module to register an exception b72ab3e Imported Translations from Transifex ffd9a6d Add docs target and generate api docs 4938dff Updated from global requirements e2f0469 Work toward Python 3.4 support and testing 9c6a20e warn against sorting requirements 6c5e449 Add exception for TaskInProgress d51fdbe Updated from global requirements 9273388 Refactoring to reduce noise in log files c4437af Imported Translations from Transifex a3f8146 Add missing session parameter to get_summary 74832f4 Updated from global requirements d9ada2a Switch off caching to prevent cache poisoning by local attacker abb4e82 Support for copying streamOptimized disk to file e434d1b Add support for the DatastoreURL object e5c22fa Add methods to the Datastore objects d33c195 Imported Translations from Transifex 788e944 Add Pylint testenv environment 6316a6f Port the Datastore and DatastorePath objects d76620b Log additional details of suds faults 9a9649f Fix seek and tell in BlockingQueue Please report issues to the bug tracker: https://bugs.launchpad.net/oslo.vmware -- dims -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo-vmware] Propose adding Radoslav to core team
+1 to Rados for oslo.vmware team -- dims On Mon, Sep 15, 2014 at 12:37 PM, Gary Kotton wrote: > Hi, > I would like to propose Radoslav to be a core team member. Over the course > of the J cycle he has been great with the reviews, bug fixes and updates to > the project. > Can the other core team members please update with your votes if you agree > or not. > Thanks > Gary > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] What's holding nova development back?
Sean, I have tabs opened to: http://status.openstack.org/elastic-recheck/gate.html http://status.openstack.org/elastic-recheck/data/uncategorized.html and periodically catch up on openstack-qa on IRC as well, i just did not realize this wsgi gate bug was hurting the gate this much. So, could we somehow indicate (email? or one of the web pages above?) where occassional helpers can watch and pitch in when needed. thanks, dims On Mon, Sep 15, 2014 at 5:55 PM, Sean Dague wrote: > On 09/15/2014 05:52 PM, Brant Knudson wrote: >> >> >> On Mon, Sep 15, 2014 at 4:30 PM, Michael Still > <mailto:mi...@stillhq.com>> wrote: >> >> On Tue, Sep 16, 2014 at 12:30 AM, Russell Bryant > <mailto:rbry...@redhat.com>> wrote: >> > On 09/15/2014 05:42 AM, Daniel P. Berrange wrote: >> >> On Sun, Sep 14, 2014 at 07:07:13AM +1000, Michael Still wrote: >> >>> Just an observation from the last week or so... >> >>> >> >>> The biggest problem nova faces at the moment isn't code review >> latency. Our >> >>> biggest problem is failing to fix our bugs so that the gate is >> reliable. >> >>> The number of rechecks we've done in the last week to try and land >> code is >> >>> truly startling. >> >> >> >> I consider both problems to be pretty much equally as important. I >> don't >> >> think solving review latency or test reliabilty in isolation is >> enough to >> >> save Nova. We need to tackle both problems as a priority. I tried to >> avoid >> >> getting into my concerns about testing in my mail on review team >> bottlenecks >> >> since I think we should address the problems independantly / in >> parallel. >> > >> > Agreed with this. I don't think we can afford to ignore either one of >> them. >> >> Yes, that was my point. I don't mind us debating how to rearrange >> hypervisor drivers. However, if we think that will solve all our >> problems we are confused. >> >> So, how do we get people to start taking bugs / gate failures more >> seriously? >> >> Michael >> >> >> What do you think about having an irc channel for working through gate >> bugs? I've always found looking at gate failures frustrating because I >> seem to be expected to work through these by myself, and maybe >> somebody's already looking at it or has more information that I don't >> know about. There have been times already where a gate bug that could >> have left everything broken for a while wound up fixed pretty quickly >> because we were able to find the right person hanging out in irc. >> Sometimes all it takes is for someone with the right knowledge to be >> there. A hypothetical exchange: >> >> rechecker: I got this error where the tempest-foo test failed ... http://... >> tempest-expert: That test calls the compute-bar nova API >> nova-expert: That API calls the network-baz neutron API >> neutron-expert: When you call that API you need to also call this other >> API to poll for it to be done... is nova doing that? >> nova-expert: Nope. Fix on the way. > > Honestly, the #openstack-qa channel is a completely appropriate place > for that. Plus it already has a lot of the tempest experts. > Realistically anyone that works on these kinds of fixes tend to be there. > > -Sean > > -- > Sean Dague > http://dague.net > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] final review push for releases thursday
Doug, One merged, Three in gate. -- dims On Mon, Sep 15, 2014 at 5:48 PM, Doug Hellmann wrote: > We’re down to 2 bugs, both of which have patches up for review. > > James Carey has a fix for the decoding error we’re seeing in mask_password(). > It needs to land in oslo.utils and oslo-incubator: > > - utils: https://review.openstack.org/#/c/121657/ > - incubator: https://review.openstack.org/#/c/121632/ > > Robert Collins has a fix for pbr breaking on tags that don’t look like > version numbers, with 1 dependency: > > - https://review.openstack.org/#/c/114403/ > - https://review.openstack.org/#/c/108271/ (dependency) > > If we knock these out Tuesday we can cut releases of the related libs to give > us a day or so with unit tests running before the final versions are tagged > on Thursday. > > Doug > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)
I was trying request-ifying oslo.vmware and ran into this as well: https://review.openstack.org/#/c/121956/ And we don't seem to have urllib3 in global-requirements either. Should we do that first? -- dims On Wed, Sep 17, 2014 at 1:05 PM, Clint Byrum wrote: > This is where Debian's "one urllib3 to rule them all" model fails in > a modern fast paced world. Debian is arguably doing the right thing by > pushing everyone to use one API, and one library, so that when that one > library is found to be vulnerable to security problems, one update covers > everyone. Also, this is an HTTP/HTTPS library.. so nobody can make the > argument that security isn't paramount in this context. > > But we all know that the "app store" model has started to bleed down into > backend applications, and now you just ship the virtualenv or docker > container that has your app as you tested it, and if that means you're > 20 versions behind on urllib3, that's your problem, not the OS vendor's. > > I think it is _completely_ irresponsible of requests, a library, to > embed another library. But I don't know if we can avoid making use of > it if we are going to be exposed to objects that are attached to it. > > Anyway, Thomas, if you're going to send the mob with pitchforks and > torches somewhere, I'd say send them to wherever requests makes its > home. OpenStack is just buying their mutated product. > > Excerpts from Donald Stufft's message of 2014-09-17 08:22:48 -0700: >> Looking at the code on my phone it looks completely correct to use the >> vendored copy here and it wouldn't actually work otherwise. >> >> > On Sep 17, 2014, at 11:17 AM, Donald Stufft wrote: >> > >> > I don't know the specific situation but it's appropriate to do this if >> > you're using requests and wish to interact with the urllib3 that requests >> > is using. >> > >> >> On Sep 17, 2014, at 11:15 AM, Thomas Goirand wrote: >> >> >> >> Hi, >> >> >> >> I'm horrified by what I just found. I have just found out this in >> >> glanceclient: >> >> >> >> File "/tests/test_ssl.py", line 19, in >> >> from requests.packages.urllib3 import poolmanager >> >> ImportError: No module named packages.urllib3 >> >> >> >> Please *DO NOT* do this. Instead, please use urllib3 from ... urllib3. >> >> Not from requests. The fact that requests is embedding its own version >> >> of urllib3 is an heresy. In Debian, the embedded version of urllib3 is >> >> removed from requests. >> >> >> >> In Debian, we spend a lot of time to "un-vendorize" stuff, because >> >> that's a security nightmare. I don't want to have to patch all of >> >> OpenStack to do it there as well. >> >> >> >> And no, there's no good excuse here... >> >> >> >> Thomas Goirand (zigo) >> >> >> >> _______ >> >> 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 -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder][Nova][Oslo] Moving Brick out of Cinder
+1 to Doug's comments. On Wed, Sep 17, 2014 at 1:02 PM, Doug Hellmann wrote: > > On Sep 16, 2014, at 6:02 PM, Flavio Percoco wrote: > >> On 09/16/2014 11:55 PM, Ben Nemec wrote: >>> Based on my reading of the wiki page about this it sounds like it should >>> be a sub-project of the Storage program. While it is targeted for use >>> by multiple projects, it's pretty specific to interacting with Cinder, >>> right? If so, it seems like Oslo wouldn't be a good fit. We'd just end >>> up adding all of cinder-core to the project anyway. :-) >> >> +1 I think the same arguments and conclusions we had on glance-store >> make sense here. I'd probably go with having it under the Block Storage >> program. > > I agree. I’m sure we could find some Oslo contributors to give you advice > about APIs if you like, but I don’t think the library needs to be part of > Oslo to be reusable. > > Doug > >> >> Flavio >> >>> >>> -Ben >>> >>> On 09/16/2014 12:49 PM, Ivan Kolodyazhny wrote: >>>> Hi Stackers! >>>> >>>> I'm working on moving Brick out of Cinder for K release. >>>> >>>> There're a lot of open questions for now: >>>> >>>> - Should we move it to oslo or somewhere on stackforge? >>>> - Better architecture of it to fit all Cinder and Nova requirements >>>> - etc. >>>> >>>> Before starting discussion, I've created some proof-of-concept to try it. I >>>> moved Brick to some lib named oslo.storage for testing only. It's only one >>>> of the possible solution to start work on it. >>>> >>>> All sources are aviable on GitHub [1], [2]. >>>> >>>> [1] - I'm not sure that this place and name is good for it, it's just a >>>> PoC. >>>> >>>> [1] https://github.com/e0ne/oslo.storage >>>> [2] https://github.com/e0ne/cinder/tree/brick - some tests still failed. >>>> >>>> Regards, >>>> Ivan Kolodyazhny >>>> >>>> On Mon, Sep 8, 2014 at 4:35 PM, Ivan Kolodyazhny wrote: >>>> >>>>> Hi All! >>>>> >>>>> I would to start moving Cinder Brick [1] to oslo as was described on >>>>> Cinder mid-cycle meetup [2]. Unfortunately I missed meetup so I want be >>>>> sure that nobody started it and we are on the same page. >>>>> >>>>> According to the Juno 3 release, there was not enough time to discuss [3] >>>>> on the latest Cinder weekly meeting and I would like to get some feedback >>>>> from the all OpenStack community, so I propose to start this discussion on >>>>> mailing list for all projects. >>>>> >>>>> I anybody didn't started it and it is useful at least for both Nova and >>>>> Cinder I would to start this work according oslo guidelines [4] and >>>>> creating needed blueprints to make it finished until Kilo 1 is over. >>>>> >>>>> >>>>> >>>>> [1] https://wiki.openstack.org/wiki/CinderBrick >>>>> [2] https://etherpad.openstack.org/p/cinder-meetup-summer-2014 >>>>> [3] >>>>> http://lists.openstack.org/pipermail/openstack-dev/2014-September/044608.html >>>>> [4] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary >>>>> >>>>> Regards, >>>>> Ivan Kolodyazhny. >>>>> >>>> >>>> >>>> >>>> ___ >>>> 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 >>> >> >> >> -- >> @flaper87 >> Flavio Percoco >> >> ___ >> 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 -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] zeromq work for kilo
gt;> >> >> >> that's still WIP but again we'll get any changes submitted for review >> >> ASAP. >> > >> > That’s good to have, but I don’t necessarily consider it a requirement >> > for in-project functional tests. >> > >> >> >> >> 4) and some improvements that we would like to make longer term >> >> >> >> a) Connection re-use on outbound messaging avoiding the current tcp >> >> setup overhead for every sent message. This may also bring further >> >> performance benefits due to underlying messaging batching in ZMQ. >> > >> > This sounds like it would be a good thing to do, but making what we have >> > work correctly and testing it feels more important for now. >> > >> >> >> >> b) Moving from tcp PUSH/PULL sockets between servers to DEALER/DEALER >> >> (or something similar) to allow for heartbeating and more immediate >> >> failure detection >> > >> > I would need to understand how much of a rewrite that represents before >> > commenting further. >> > >> >> >> >> c) Crypto support >> > >> > There are some other discussions about adding crypto to messaging, and I >> > hope we can do that without having to touch each driver, if possible. >> > >> >> >> >> Cheers >> >> >> >> James >> >> >> >> -- >> >> James Page >> >> Ubuntu and Debian Developer >> >> james.p...@ubuntu.com >> >> jamesp...@debian.org >> >> >> > >> > >> > ___ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> >> -- >> @flaper87 >> Flavio Percoco >> >> ___ >> 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 > -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Oslo final releases ready
w00t! -- dims On Thu, Sep 18, 2014 at 10:04 AM, Doug Hellmann wrote: > All of the final releases for the Oslo libraries for the Juno cycle are > available on PyPI. I’m working on a couple of patches to the global > requirements list to update the baseline in the applications. In all cases, > the final release is a second tag on a previously released version. > > - oslo.config - 1.4.0 (same as 1.4.0.0a5) > - oslo.db - 1.0.0 (same as 0.5.0) > - oslo.i18n - 1.0.0 (same as 0.4.0) > - oslo.messaging - 1.4.0 (same as 1.4.0.0a5) > - oslo.rootwrap - 1.3.0 (same as 1.3.0.0a3) > - oslo.serialization - 1.0.0 (same as 0.3.0) > - oslosphinx - 2.2.0 (same as 2.2.0.0a3) > - oslotest - 1.1.0 (same as 1.1.0.0a2) > - oslo.utils - 1.0.0 (same as 0.3.0) > - cliff - 1.7.0 (previously tagged, so not a new release) > - stevedore - 1.0.0 (same as 1.0.0.0a2) > > Congratulations and *Thank You* to the Oslo team for doing an amazing job > with graduations this cycle! > > Doug > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The recent gate performance and how it affects you
Anita, Joe, I need help with adding debug message in: https://review.openstack.org/#/c/56316/ to track down: Bug: https://bugs.launchpad.net/bugs/1251784 => message:"Connection to neutron failed: Maximum attempts reached" AND filename:"logs/screen-n-cpu.txt" Title: nova+neutron scheduling error: Connection to neutron failed: Maximum attempts reached -- dims On Wed, Nov 20, 2013 at 5:43 PM, Anita Kuno wrote: > On 11/20/2013 05:10 PM, Michael Still wrote: >> On Thu, Nov 21, 2013 at 7:44 AM, Clark Boylan wrote: >> >>> How do we avoid this in the future? Step one is reviewers that are >>> approving changes (or reverifying them) should keep an eye on the gate >>> queue. >> >> Talking on the -infra IRC channel just now, it has become clear to me >> that we need to stop approving _any_ change for now until we have the >> gate fixed. All we're doing at the moment is rechecking over and over >> because the gate is too unreliable to actually pass changes. This is >> making debugging the gate significantly harder. >> >> Could cores please refrain from approving code until the gate issues >> are resolved? >> >> Thanks, >> Michael >> > We are talking in -neutron and Mark McClain sent out an email to all > cores expressing this objective. He is also -2 any patch in check that > is not directly related to a gate blocking bug fix. Neutron is in > holding until we get the all clear from -infra. > > Thanks Michael, > Anita. > > _______ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The recent gate performance and how it affects you
Nice! Joe. thanks, -- dims On Wed, Nov 20, 2013 at 7:15 PM, Joe Gordon wrote: > Dims, we think https://review.openstack.org/#/c/57509/ will fix 125178. > > > On Wed, Nov 20, 2013 at 3:58 PM, Davanum Srinivas wrote: >> >> Anita, Joe, >> >> I need help with adding debug message in: >> https://review.openstack.org/#/c/56316/ >> >> to track down: >> Bug: https://bugs.launchpad.net/bugs/1251784 => message:"Connection to >> neutron failed: Maximum attempts reached" AND >> filename:"logs/screen-n-cpu.txt" Title: nova+neutron scheduling error: >> Connection to neutron failed: Maximum attempts reached >> >> -- dims >> >> >> >> On Wed, Nov 20, 2013 at 5:43 PM, Anita Kuno wrote: >> > On 11/20/2013 05:10 PM, Michael Still wrote: >> >> On Thu, Nov 21, 2013 at 7:44 AM, Clark Boylan >> >> wrote: >> >> >> >>> How do we avoid this in the future? Step one is reviewers that are >> >>> approving changes (or reverifying them) should keep an eye on the gate >> >>> queue. >> >> >> >> Talking on the -infra IRC channel just now, it has become clear to me >> >> that we need to stop approving _any_ change for now until we have the >> >> gate fixed. All we're doing at the moment is rechecking over and over >> >> because the gate is too unreliable to actually pass changes. This is >> >> making debugging the gate significantly harder. >> >> >> >> Could cores please refrain from approving code until the gate issues >> >> are resolved? >> >> >> >> Thanks, >> >> Michael >> >> >> > We are talking in -neutron and Mark McClain sent out an email to all >> > cores expressing this objective. He is also -2 any patch in check that >> > is not directly related to a gate blocking bug fix. Neutron is in >> > holding until we get the all clear from -infra. >> > >> > Thanks Michael, >> > Anita. >> > >> > ___ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> -- >> Davanum Srinivas :: http://davanum.wordpress.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 > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Gate failures
Gary, There's a blow-by-blow account in this etherpad - https://etherpad.openstack.org/p/critical-patches-gatecrash-November-2013 On Sat, Nov 23, 2013 at 11:12 AM, Gary Kotton wrote: > Hi, > To whoever fixed the gate – Thanks! Can someone please let us know what the > problems were. > Thanks > Gary > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Unwedging the gate
e in bug fix mode, we got > this one fixed as well > > https://bugs.launchpad.net/bugs/1251784 "nova+neutron scheduling error: > Connection to neutron failed: Maximum attempts reached > > Fix https://review.openstack.org/#/c/57509/ > > Uncovered on mailing list > (http://lists.openstack.org/pipermail/openstack-dev/2013-November/019906.html) > > Nova had a very old version of oslo's local.py which is used for managing > references to local variables in coroutines. The old version had a pretty > significant bug that basically meant non-weak references to variables were > not managed properly. This fix has made the nova neutron interactions much > more reliable. > > This fixed the number 2 bug on our list of top gate bugs > (http://lists.openstack.org/pipermail/openstack-dev/2013-November/019826.html > )! > > > In addition to fixing 4 old bugs, we fixed two new bugs that were introduced > / exposed this week. > > https://bugs.launchpad.net/bugs/1251920 "Tempest failures due to failure to > return console logs from an instance Project" > > Bug: https://review.openstack.org/#/c/54363/ [Tempest] > > Fix(work around): https://review.openstack.org/#/c/57193/ > > After many false starts and banging our head against the wall, we identified > a change to tempest, https://review.openstack.org/54363 , that added a new > test around the same time as bug 1251920 became a problem. Forcing tempest > to skip this test had a very high incidence of success without any 1251920 > related failures. As a result we are working arond this bug by skipping that > test, until it can be run without major impact to the gate. > > The change that introduced this problematic test had to go through the gate > four times before it would merge, though only one of the 3 failed attemps > appears to have triggered 1251920. Or as Jeremy Stanley (fungi) said > "nondeterministic failures breed more nondeterministic failures, because > people are so used to having to reverify their patches to get them to merge > that they are doing so even when it's their patch which is introducing a > nondeterministic bug." > > https://bugs.launchpad.net/bugs/1252170 "tempest.scenario > test_resize_server_confirm failed in grenade" > > Fix https://review.openstack.org/#/c/57357/ > > Fix https://review.openstack.org/#/c/57572/ > > First we started running post Grenade upgrade tests in parallel (to fix > another bug) which would normally be fine, but Grenade wasn't configuring > the small flavors typically used by tempest so it was possible for the > devstack Jenkins slaves to run out of memory when starting many larger VMs > in parallel. To fix this devstack lib/tempest has been updated to create the > flavors only if they don't exist and Grenade is allowing tempest to use its > default instance flavors. > > > > Now that we have the gate back into working order, we are working on the > next steps to prevent this from happening again. The two most immediate > changes are: > > Doing a better job of triaging gate bugs > (http://lists.openstack.org/pipermail/openstack-dev/2013-November/020048.html > ). > > In the next few days we will remove 'reverify no bug' (although you will > still be able to run 'reverify bug x'. > > > Best, > Joe Gordon > Clark Boylan > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] When should things get added to Oslo.Incubator
Robert, I believe some code is in Ironic too [1]. The 2 choices are in Oslo are: 1) copy code to oslo-incubator 2) start a new oslo.objects(?) repo In the summit meeting, we have been trying to break existing code into libraries so #1 is probably counter-productive. If the code churn in the files are slowed down quite a bit, #2 is a much better option IMHO. It's still under oslo but as a separate library. [1] https://github.com/openstack/ironic/tree/master/ironic/objects On Tue, Dec 3, 2013 at 4:42 PM, Robert Collins wrote: > Hey - https://review.openstack.org/#/c/57022/7//COMMIT_MSG - I > strongly suggested here that reusing the Nova object code is the first > step towards an objects library, and that we should be putting it in > olso; there are some reasonable concerns about this being experimental > but... > > The Oslo wiki page says: > The process of developing a new Oslo API usually begins by taking code > which is common to some OpenStack projects and moving it into the > oslo-incubator repository. New APIs live in the incubator until they > have matured to meet the criteria described above. > > So if this code lands in solum as-is, its now common - to me that > means we should be going straight to oslo.incubator and working on > shared code. > > However there's clearly an expectation mismatch - so - any thoughts? > > -Rob > > > -- > Robert Collins > Distinguished Technologist > HP Converged Cloud > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] creating a default for oslo config variables within a project?
Should we update oslo-incubator first to?
default=os.environ.get("OSLO_LOCK_PATH") or tempfile.mkdtemp()
-- dims
On Tue, Dec 3, 2013 at 4:56 PM, Sean Dague wrote:
> This cinder patch - https://review.openstack.org/#/c/48935/
>
> Is blocked on failing upgrade because the updated oslo lockutils won't
> function until there is a specific configuration variable added to the
> cinder.conf.
>
> That work around is proposed here -
> https://review.openstack.org/#/c/52070/3
>
> However I think this is exactly the kind of forward breaks that we want
> to prevent with grenade, as cinder failing to function after a rolling
> upgrade because a config item wasn't added is exactly the kind of pain
> we are trying to prevent happening to ops.
>
> So the question is, how is this done correctly so that a default can be
> set in the cinder code for this value, and it not require a config
> change to work?
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Davanum Srinivas :: http://davanum.wordpress.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Top Gate Bugs
Hits >> FAILURE: 73 >> This has had some attempts made at fixing it but its still around. >> >> >> In addition to the existing bugs, we have some new bugs on the rise: >> >> 1) https://bugs.launchpad.net/bugs/1257626 >> Title: Timeout while waiting on RPC response - topic: "network", RPC >> method: "allocate_for_instance" info: "" >> Project: nova >> Hits >> FAILURE: 52 >> large-ops only bug. This has been around for at least two weeks, but >> we have seen this in higher numbers starting around December 3rd. This >> may be an infrastructure issue as the neutron-large-ops started >> failing more around the same time. >> >> 2) https://bugs.launchpad.net/bugs/1257641 >> Title: Quota exceeded for instances: Requested 1, but already used 10 >> of 10 instances >> Projects: nova, tempest >> Hits >> FAILURE: 41 >> Like the previous bug, this has been around for at least two weeks but >> appears to be on the rise. >> >> >> >> Raw Data: http://paste.openstack.org/show/54419/ >> >> >> best, >> Joe >> >> >> [0] failure rate = 1-(success rate gate-tempest-dsvm-neutron)*(success >> rate ...) * ... >> >> gate-tempest-dsvm-neutron = 0.00 >> gate-tempest-dsvm-neutron-large-ops = 11.11 >> gate-tempest-dsvm-full = 11.11 >> gate-tempest-dsvm-large-ops = 4.55 >> gate-tempest-dsvm-postgres-full = 10.00 >> gate-grenade-dsvm = 0.00 >> >> (I hope I got the math right here) >> >> [1] >> >> http://git.openstack.org/cgit/openstack-infra/elastic-recheck/tree/elastic_recheck/cmd/check_success.py >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > Let's add bug 1257644 [1] to the list. I'm pretty sure this is due to some > recent code [2][3] in the nova libvirt driver that is automatically > disabling the host when the libvirt connection drops. > > Joe said there was a known issue with libvirt connection failures so this > could be duped against that, but I'm not sure where/what that one is - maybe > bug 1254872 [4]? > > Unless I just don't understand the code, there is some funny logic going on > in the libvirt driver when it's automatically disabling a host which I've > documented in bug 1257644. It would help to have some libvirt-minded people > helping to look at that, or the authors/approvers of those patches. > > Also, does anyone know if libvirt will pass a 'reason' string to the > _close_callback function? I was digging through the libvirt code this > morning but couldn't figure out where the callback is actually called and > with what parameters. The code in nova seemed to just be based on the patch > that danpb had in libvirt [5]. > > This bug is going to raise a bigger long-term question about the need for > having a new column in the Service table for indicating whether or not the > service was automatically disabled, as Phil Day points out in bug 1250049 > [6]. That way the ComputeFilter in the scheduler could handle that case a > bit differently, at least from a logging/serviceability standpoint, e.g. > info/warning level message vs debug. > > [1] https://bugs.launchpad.net/nova/+bug/1257644 > [2] https://review.openstack.org/#/c/52189/ > [3] https://review.openstack.org/#/c/56224/ > [4] https://bugs.launchpad.net/nova/+bug/1254872 > [5] http://www.redhat.com/archives/libvir-list/2012-July/msg01675.html > [6] https://bugs.launchpad.net/nova/+bug/1250049 > > -- > > Thanks, > > Matt Riedemann > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Top Gate Bugs
I had the labels wrong - here's a slightly better link - http://bit.ly/1gdxYeg
On Fri, Dec 6, 2013 at 4:31 PM, Davanum Srinivas wrote:
> Joe,
>
> Looks like we may be a bit more stable now?
>
> Short URL: http://bit.ly/18qq4q2
>
> Long URL :
> http://graphite.openstack.org/graphlot/?from=-120hour&until=-0hour&target=color(alias(movingAverage(asPercent(stats.zuul.pipeline.gate.job.gate-tempest-dsvm-full.SUCCESS,sum(stats.zuul.pipeline.gate.job.gate-tempest-dsvm-full.{SUCCESS,FAILURE})),'6hours'),%20'gate-tempest-dsvm-postgres-full'),'ED9121')&target=color(alias(movingAverage(asPercent(stats.zuul.pipeline.gate.job.gate-tempest-dsvm-postgres-full.SUCCESS,sum(stats.zuul.pipeline.gate.job.gate-tempest-dsvm-postgres-full.{SUCCESS,FAILURE})),'6hours'),%20'gate-tempest-dsvm-neutron-large-ops'),'00F0F0')&target=color(alias(movingAverage(asPercent(stats.zuul.pipeline.gate.job.gate-tempest-dsvm-neutron.SUCCESS,sum(stats.zuul.pipeline.gate.job.gate-tempest-dsvm-neutron.{SUCCESS,FAILURE})),'6hours'),%20'gate-tempest-dsvm-neutron'),'00FF00')&target=color(alias(movingAverage(asPercent(stats.zuul.pipeline.gate.job.gate-tempest-dsvm-neutron-large-ops.SUCCESS,sum(stats.zuul.pipeline.gate.job.gate-tempest-dsvm-neutron-large-ops.
{SUCCESS,FAILURE})),'6hours'),%20'gate-tempest-dsvm-neutron-large-ops'),'00c868')&target=color(alias(movingAverage(asPercent(stats.zuul.pipeline.check.job.check-grenade-dsvm.SUCCESS,sum(stats.zuul.pipeline.check.job.check-grenade-dsvm.{SUCCESS,FAILURE})),'6hours'),%20'check-grenade-dsvm'),'800080')&target=color(alias(movingAverage(asPercent(stats.zuul.pipeline.gate.job.gate-tempest-dsvm-large-ops.SUCCESS,sum(stats.zuul.pipeline.gate.job.gate-tempest-dsvm-large-ops.{SUCCESS,FAILURE})),'6hours'),%20'gate-tempest-dsvm-neutron-large-ops'),'E080FF')
>
> -- dims
>
>
> On Fri, Dec 6, 2013 at 11:28 AM, Matt Riedemann
> wrote:
>>
>>
>> On Wednesday, December 04, 2013 7:22:23 AM, Joe Gordon wrote:
>>>
>>> TL;DR: Gate is failing 23% of the time due to bugs in nova, neutron
>>> and tempest. We need help fixing these bugs.
>>>
>>>
>>> Hi All,
>>>
>>> Before going any further we have a bug that is affecting gate and
>>> stable, so its getting top priority here. elastic-recheck currently
>>> doesn't track unit tests because we don't expect them to fail very
>>> often. Turns out that assessment was wrong, we now have a nova py27
>>> unit test bug in gate and stable gate.
>>>
>>> https://bugs.launchpad.net/nova/+bug/1216851
>>> Title: nova unit tests occasionally fail migration tests for mysql and
>>> postgres
>>> Hits
>>> FAILURE: 74
>>> The failures appear multiple times for a single job, and some of those
>>> are due to bad patches in the check queue. But this is being seen in
>>> stable and trunk gate so something is definitely wrong.
>>>
>>> ===
>>>
>>>
>>> Its time for another edition of of 'Top Gate Bugs.' I am sending this
>>> out now because in addition to our usual gate bugs a few new ones have
>>> cropped up recently, and as we saw a few weeks ago it doesn't take
>>> very many new bugs to wedge the gate.
>>>
>>> Currently the gate has a failure rate of at least 23%! [0]
>>>
>>> Note: this email was generated with
>>> http://status.openstack.org/elastic-recheck/ and
>>> 'elastic-recheck-success' [1]
>>>
>>> 1) https://bugs.launchpad.net/bugs/1253896
>>> Title: test_minimum_basic_scenario fails with SSHException: Error
>>> reading SSH protocol banner
>>> Projects: neutron, nova, tempest
>>> Hits
>>> FAILURE: 324
>>> This one has been around for several weeks now and although we have
>>> made some attempts at fixing this, we aren't any closer at resolving
>>> this then we were a few weeks ago.
>>>
>>> 2) https://bugs.launchpad.net/bugs/1251448
>>> Title: BadRequest: Multiple possible networks found, use a Network ID
>>> to be more specific.
>>> Project: neutron
>>> Hits
>>> FAILURE: 141
>>>
>>> 3) https://bugs.launchpad.net/bugs/1249065
>>> Title: Tempest failure: tempest/scenario/test_snapshot_pattern.py
>>> Project: nova
>>> Hits
>>> FAILURE: 112
>>> This is a bug in nova's neutron code.
>>>
>>> 4) https://bugs.launchpad.net/bugs/12501
Re: [openstack-dev] OK to Use Flufl.enum
Adam, I don't see it in the global requirements [1], needs to be added there first i think. -- dims [1] https://github.com/openstack/requirements/blob/master/global-requirements.txt On Tue, Dec 10, 2013 at 5:24 AM, Flavio Percoco wrote: > On 09/12/13 19:45 -0800, Alex Gaynor wrote: >> >> Would it make sense to use the `enum34` package, which is a backport of >> teh >> enum package from py3k? > > > +1 > > This is what we were using in Marconi. > > >> >> Alex >> >> >> On Mon, Dec 9, 2013 at 7:37 PM, Adam Young wrote: >> >>While Python 3 has enumerated types, Python 2 does not, and the >> standard >>package to provide id, Flufl.enum, is not yet part of our code base. >> Is >>there any strong objection to including Flufl.enum? >> >>http://pythonhosted.org/flufl.enum/ >> >>It makes for some very elegant code, especially for enumerated integer >>types. >> >>For an example See ScopeType in >> >> >> https://review.openstack.org/#/c/55908/4/keystone/contrib/revoke/core.py >> >>Line 62. >> >>the getter/setter in RevokeEvent do not need to do any conditional >> logic if >>passed either an integer or a ScopeType. >> >> >>___ >>OpenStack-dev mailing list >>OpenStack-dev@lists.openstack.org >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> -- >> "I disapprove of what you say, but I will defend to the death your right >> to say >> it." -- Evelyn Beatrice Hall (summarizing Voltaire) >> "The people's good is the highest law." -- Cicero >> GPG Key fingerprint: 125F 5C67 DFE9 4084 > > >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > @flaper87 > Flavio Percoco > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] [qa] oslo.config generator scrambling tempest config files
Sean, Do you already have this in tempest copy of the code? https://review.openstack.org/#/c/60401/ - that will help going forward. -- dims On Fri, Jan 3, 2014 at 7:53 AM, Sean Dague wrote: > So maybe I only just noticed it, but we moved to using the oslo.config > generator in Tempest, and it's largely succeeding at creating really > large config diffs and moving sections around all over the place. > > Exhibit A: https://review.openstack.org/#/c/60434/14/etc/tempest.conf.sample > > Which means it's generating a lot of noise, and I don't really > understand why. It would seem that a config generator should be order > stable. Anyone familiar enough with this to know why? And why this > doesn't seem to be an issue with other projects? > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [rfc] drop XML from v3 API entirely
+1 to drop XML from v3 API On Mon, Jan 13, 2014 at 9:38 AM, Sean Dague wrote: > I know we've been here before, but I want to raise this again while there is > still time left in icehouse. > > I would like to propose that the Nova v3 API removes the XML payload > entirely. It adds complexity to the Nova code, and it requires duplicating > all our test resources, because we need to do everything onces for JSON and > once for XML. Even worse, the dual payload strategy that nova employed > leaked out to a lot of other projects, so they now think maintaining 2 > payloads is a good thing (which I would argue it is not). > > As we started talking about reducing tempest concurrency in the gate, I was > starting to think a lot about what we could shed that would let us keep up a > high level of testing, but bring our overall time back down. The fact that > Nova provides an extremely wide testing surface makes this challenging. > > I think it would be a much better situation if the Nova API is a single > payload type. The work on the jsonschema validation is also something where > I think we could get to a fully discoverable API, which would be huge. > > If we never ship v3 API with XML as stable, we can deprecate it entirely, > and let it die with v2 ( probably a year out ). > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Hat Tip to fungi
+1 :) -- dims On Thu, Jan 16, 2014 at 10:25 AM, Kyle Mestery wrote: > > On Jan 16, 2014, at 9:17 AM, Jay Pipes wrote: > >> On Thu, 2014-01-16 at 08:44 -0500, Anita Kuno wrote: >>> Thank you, fungi. >>> >>> You have kept openstack-infra running for that last 2 weeks as the sole >>> plate-spinner whilst the rest of us were conferencing, working on the >>> gerrit upgrade or getting our laptop stolen. >>> >>> You spun up and configured two new Jenkinses (Jenkinsii?) and then deal >>> with the consequences of one expansion of our system slowing down >>> another. With Jim's help from afar, Zuul is now on a faster server. [0] >>> >>> All this while dealing with the every day business of keeping -infra >>> operating. >>> >>> I am so grateful for all you do. >>> >>> I tip my hat to you, sir. >> >> Seconded. >> > Third’ed? Either way, thank you Fungi for all that you do for OpenStack! > > Kyle > >> -jay >> >> >> ___ >> 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 -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Gate issues
Gary, Here's the bug - https://bugs.launchpad.net/nova/+bug/1271331 The oslo change has been merged - https://review.openstack.org/#/c/68275/ Can't yet find a Nova merge of the change. -- dims On Thu, Jan 23, 2014 at 9:11 AM, Gary Kotton wrote: > Hi, > 1 in 3 failures today are due to: > > 2014-01-23 11:54:03.879 | > 2014-01-23 11:54:03.880 | Traceback (most recent call last): > 2014-01-23 11:54:03.880 | File "nova/tests/compute/test_compute.py", line > 577, in test_poll_volume_usage_with_data > 2014-01-23 11:54:03.880 | self.compute._last_vol_usage_poll) > 2014-01-23 11:54:03.880 | File "/usr/lib/python2.7/unittest/case.py", line > 420, in assertTrue > 2014-01-23 11:54:03.880 | raise self.failureException(msg) > 2014-01-23 11:54:03.880 | AssertionError: _last_vol_usage_poll was not > properly updated <1390477654.28> > 2014-01-23 11:54:03.880 | > == > 2014-01-23 11:54:03.880 | FAIL: > nova.tests.db.test_sqlite.TestSqlite.test_big_int_mapping > 2014-01-23 11:54:03.880 | tags: worker-1 > 2014-01-23 11:54:03.880 | > -- > 2014-01-23 11:54:03.880 | Empty attachments: > 2014-01-23 11:54:03.880 | pythonlogging:'' > 2014-01-23 11:54:03.881 | stderr > 2014-01-23 11:54:03.881 | stdout > 2014-01-23 11:54:03.881 | > 2014-01-23 11:54:03.881 | Traceback (most recent call last): > 2014-01-23 11:54:03.881 | File "nova/tests/db/test_sqlite.py", line 53, in > test_big_int_mapping > 2014-01-23 11:54:03.881 | output, _ = utils.execute(get_schema_cmd, > shell=True) > 2014-01-23 11:54:03.881 | File "nova/utils.py", line 166, in execute > 2014-01-23 11:54:03.881 | return processutils.execute(*cmd, **kwargs) > 2014-01-23 11:54:03.881 | File "nova/openstack/common/processutils.py", > line 168, in execute > 2014-01-23 11:54:03.881 | result = obj.communicate() > 2014-01-23 11:54:03.881 | File "/usr/lib/python2.7/subprocess.py", line > 754, in communicate > 2014-01-23 11:54:03.882 | return self._communicate(input) > 2014-01-23 11:54:03.882 | File "/usr/lib/python2.7/subprocess.py", line > 1314, in _communicate > 2014-01-23 11:54:03.882 | stdout, stderr = > self._communicate_with_select(input) > 2014-01-23 11:54:03.882 | File "/usr/lib/python2.7/subprocess.py", line > 1438, in _communicate_with_select > 2014-01-23 11:54:03.882 | data = os.read(self.stdout.fileno(), 1024) > 2014-01-23 11:54:03.882 | OSError: [Errno 11] Resource temporarily > unavailable > 2014-01-23 11:54:03.882 | > == > 2014-01-23 11:54:03.882 | FAIL: process-returncode > 2014-01-23 11:54:03.882 | tags: worker-1 > 2014-01-23 11:54:03.882 | > -- > 2014-01-23 11:54:03.882 | Binary content: > 2014-01-23 11:54:03.882 | traceback (test/plain; charset="utf8") > 2014-01-23 11:54:03.883 | > == > 2014-01-23 11:54:03.883 | FAIL: process-returncode > 2014-01-23 11:54:03.883 | tags: worker-3 > 2014-01-23 11:54:03.883 | > ------ > 2014-01-23 11:54:03.883 | Binary content: > > > Any ideas? > > Thanks > > Gary > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Lots of gating failures because of testtools
Robert, Here's a merge request for subunit https://code.launchpad.net/~subunit/subunit/trunk/+merge/203723 -- dims On Wed, Jan 29, 2014 at 6:51 AM, Sean Dague wrote: > On 01/29/2014 06:24 AM, Sylvain Bauza wrote: >> Le 29/01/2014 12:07, Ivan Melnikov a écrit : >>> I also filed a bug for taskflow, feel free to add your projects there if >>> it's affected, too: https://bugs.launchpad.net/taskflow/+bug/1274050 >>> >> >> >> Climate is also impacted, we can at least declare a recheck with this >> bug number. >> -Sylvain > > Right, but until a testtools fix is released, it won't pass. So please > no rechecks until we have a new testtools from Robert that fixes things. > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] VMware tools in oslo-incubator or straight to oslo.vmware
Doug, I can help with shepherding this effort as well. -- dims On Thu, Jan 30, 2014 at 5:51 PM, Doug Hellmann wrote: > > On Thu, Jan 30, 2014 at 12:38 PM, Vipin Balachandran > wrote: >> >> This library is highly specific to VMware drivers in OpenStack and not a >> generic VMware API client. As Doug mentioned, this library won't be useful >> outside OpenStack. Also, it has some dependencies on openstack.common code >> as well. Therefore it makes sense if we make this code as part of OSLO. > > > I think we have consensus that, assuming you are committing to API > stability, this set of code does not need to go through the incubator before > becoming a library. How stable is the current API? > > If it stable and is not going to be useful to anyone outside of OpenStack, > we can create an oslo.vmware library for it. I can start working with -infra > next week to set up the repository. > > We will need someone on your team to be designated as the lead maintainer, > to coordinate with the Oslo PTL for release management issues and bug > triage. Is that you, Vipin? > > We will also need to have a set of reviewers for the new repository. I'll > add oslo-core, but it will be necessary for a few people familiar with the > code to also be included. If you have anyone from nova or cinder who should > be a reviewer, we can add them, too. Please send me a list of names and the > email addresses used in gerrit so I can add them to the reviewer list when > the repository is created. > > Doug > > >> >> >> >> By the way, a work in progress review has been posted for the VMware >> cinder driver integration with the OSLO common code >> (https://review.openstack.org/#/c/70108/). The nova integration is currently >> under progress. >> >> >> >> Thanks, >> >> Vipin >> >> >> >> From: Doug Hellmann [mailto:doug.hellm...@dreamhost.com] >> Sent: Wednesday, January 29, 2014 4:06 AM >> To: Donald Stufft >> Cc: OpenStack Development Mailing List (not for usage questions); Vipin >> Balachandran >> Subject: Re: [openstack-dev] [oslo] VMware tools in oslo-incubator or >> straight to oslo.vmware >> >> >> >> >> >> >> >> On Tue, Jan 28, 2014 at 5:06 PM, Donald Stufft wrote: >> >> >> On Jan 28, 2014, at 5:01 PM, Julien Danjou wrote: >> >> > On Tue, Jan 28 2014, Doug Hellmann wrote: >> > >> >> There are several reviews related to adding VMware interface code to >> >> the >> >> oslo-incubator so it can be shared among projects (start at >> >> https://review.openstack.org/#/c/65075/7 if you want to look at the >> >> code). >> >> >> >> I expect this code to be fairly stand-alone, so I wonder if we would be >> >> better off creating an oslo.vmware library from the beginning, instead >> >> of >> >> bringing it through the incubator. >> >> >> >> Thoughts? >> > >> > This sounds like a good idea, but it doesn't look OpenStack specific, so >> > maybe building a non-oslo library would be better. >> > >> > Let's not zope it! :) >> >> +1 on not making it an oslo library. >> >> >> >> Given the number of issues we've seen with stackforge libs in the gate, >> I've changed my default stance on this point. >> >> >> >> It's not clear from the code whether Vipin et al expect this library to be >> useful for anyone not working with both OpenStack and VMware. Either way, I >> anticipate having the library under the symmetric gating rules and managed >> by the one of the OpenStack teams (oslo, nova, cinder?) and VMware >> contributors should make life easier in the long run. >> >> >> >> As far as the actual name goes, I'm not set on "oslo.vmware" it was just a >> convenient name for the conversation. >> >> >> >> Doug >> >> >> >> >> >> >> > >> > -- >> > Julien Danjou >> > # Free Software hacker # independent consultant >> > # http://julien.danjou.info >> >> > ___ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> - >> Donald Stufft >> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >> DCFA >> >> > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] VMware tools in oslo-incubator or straight to oslo.vmware
Hi Vipin, Doug, I've followed instructions from Doug and this page [1]. Will give Infra folks a bit of time and then ping them in a day or so. Git Repo on Github : https://github.com/dims/oslo.vmware Request to create Gerrit Groups : https://bugs.launchpad.net/openstack-ci/+bug/1275817 Review request to create stackforge repo and jenkins jobs : https://review.openstack.org/#/c/70761/ -- dims [1] http://ci.openstack.org/stackforge.html On Fri, Jan 31, 2014 at 8:51 AM, Doug Hellmann wrote: > Thanks, Vipin, > > Dims is going work on setting up your repository and help you configure the > review team. Give us a few days to get the details sorted out. > > Doug > > > On Fri, Jan 31, 2014 at 7:39 AM, Vipin Balachandran > wrote: >> >> The current API is stable since this is used by nova and cinder for the >> last two releases. Yes, I can act as the maintainer. >> >> >> >> Here is the list of reviewers: >> >> Arnaud Legendre >> >> Davanum Srinivas (dims) >> >> garyk >> >> Kartik Bommepally >> >> Sabari Murugesan >> >> Shawn Hartsock >> >> Subbu >> >> Vui Lam >> >> >> >> From: Doug Hellmann [mailto:doug.hellm...@dreamhost.com] >> Sent: Friday, January 31, 2014 4:22 AM >> To: Vipin Balachandran >> Cc: Donald Stufft; OpenStack Development Mailing List (not for usage >> questions) >> >> >> Subject: Re: [openstack-dev] [oslo] VMware tools in oslo-incubator or >> straight to oslo.vmware >> >> >> >> >> >> On Thu, Jan 30, 2014 at 12:38 PM, Vipin Balachandran >> wrote: >> >> This library is highly specific to VMware drivers in OpenStack and not a >> generic VMware API client. As Doug mentioned, this library won't be useful >> outside OpenStack. Also, it has some dependencies on openstack.common code >> as well. Therefore it makes sense if we make this code as part of OSLO. >> >> >> >> I think we have consensus that, assuming you are committing to API >> stability, this set of code does not need to go through the incubator before >> becoming a library. How stable is the current API? >> >> >> >> If it stable and is not going to be useful to anyone outside of OpenStack, >> we can create an oslo.vmware library for it. I can start working with -infra >> next week to set up the repository. >> >> >> >> We will need someone on your team to be designated as the lead maintainer, >> to coordinate with the Oslo PTL for release management issues and bug >> triage. Is that you, Vipin? >> >> >> >> We will also need to have a set of reviewers for the new repository. I'll >> add oslo-core, but it will be necessary for a few people familiar with the >> code to also be included. If you have anyone from nova or cinder who should >> be a reviewer, we can add them, too. Please send me a list of names and the >> email addresses used in gerrit so I can add them to the reviewer list when >> the repository is created. >> >> >> >> Doug >> >> >> >> >> >> >> >> By the way, a work in progress review has been posted for the VMware >> cinder driver integration with the OSLO common code >> (https://review.openstack.org/#/c/70108/). The nova integration is currently >> under progress. >> >> >> >> Thanks, >> >> Vipin >> >> >> >> From: Doug Hellmann [mailto:doug.hellm...@dreamhost.com] >> Sent: Wednesday, January 29, 2014 4:06 AM >> To: Donald Stufft >> Cc: OpenStack Development Mailing List (not for usage questions); Vipin >> Balachandran >> Subject: Re: [openstack-dev] [oslo] VMware tools in oslo-incubator or >> straight to oslo.vmware >> >> >> >> >> >> >> >> On Tue, Jan 28, 2014 at 5:06 PM, Donald Stufft wrote: >> >> >> On Jan 28, 2014, at 5:01 PM, Julien Danjou wrote: >> >> > On Tue, Jan 28 2014, Doug Hellmann wrote: >> > >> >> There are several reviews related to adding VMware interface code to >> >> the >> >> oslo-incubator so it can be shared among projects (start at >> >> https://review.openstack.org/#/c/65075/7 if you want to look at the >> >> code). >> >> >> >> I expect this code to be fairly stand-alone, so I wonder if we would be >> >> better off creating an oslo.vmware library from the beginning, instead >> >> of >> >> bringing it through the incubator.
Re: [openstack-dev] [Nova][vmware] A new VMwareAPISession
Shawn, We are waiting on this infra review to pass - to create the oslo.vmware git repo. https://review.openstack.org/#/c/70761/ -- dims On Thu, Feb 6, 2014 at 5:23 PM, Shawn Hartsock wrote: > Hi folks, > > Just following up on what we were talking about in IRC. > > The BP: > https://blueprints.launchpad.net/nova/+spec/vmware-soap-session-management > > Is supposed to capture some of this work/discussion. Earlier in > Icehouse we had thought that having some kind of pseudo transaction > that could encompass a set of calls would be a nice way to allow a > method to "roll back" to some point and re-try a set of API calls as a > unit. This proved to be messy so I've abandoned that line of work. > Instead, (as pointed out by Matthew) the session details should not be > exposed at all above the Vim object. I think this is generally a good > direction the only problems would be timing of releases and refactors. > > The core change I would like to propose to fit well with this idea of > restructuring around the Vim object revolves around how to verify and > terminate a session. > > In particular, vim.SessionIsActive and vim.TerminateSession ... these > are intended as a system administrator's control API so a root user > could evict other users. Think of administrating a session through > these API as using 'kill -KILL ' where this might be appropriate > if you were a root or super user cleaning out a session list. If you > were to log out of SSH using 'kill -KILL -1' it would work but it > would also be a little silly and would by pass logout scripts. > > Individual users have the ability to check if their session is logged > in by using vim.CurrentTime or > ServiceContent.sessionManager.currentSession (you should see that > sessionManager and currentSession are not None). To log out your own > session there's a method you can used called vim.Logout which will > only affect the current session. The vim.TerminateSession can force > *any* open session off line so if there was a session ID bug in your > code you could randomly knock other driver instances off line which > could cause interesting unreproducible bugs for other users of the > system. > > References (reading very carefully): > * > http://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.wssdk.apiref.doc/vim.SessionManager.html > * > http://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.wssdk.apiref.doc/vim.SessionManager.html#logout > * > http://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.wssdk.apiref.doc/vim.SessionManager.html#sessionIsActive > > ... IN PROGRESS ... > https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:session-management-refactor,n,z > > I will be shuffling this patch set around to reflect these changes. > I've tried to communicate the real purpose of this refactor, not to > introduce new API but to change how sessions are logged out and/or > validated. > > As for > https://blueprints.launchpad.net/oslo/+spec/vmware-api > > I know we're trying to keep this a light weight fork-lift but as we > address other problems it's becoming clear to me we need to > incorporate certain key fixes. > > I emailed with Vipin about https://review.openstack.org/#/c/65075/ he > is currently waiting for someone to direct him toward the correct > place to start committing this code. I'll have to refactor > https://review.openstack.org/#/c/63229/ so it can be used along side > that library. > > I do have a question: > * if Vipin manages to ship an Oslo lib in icehouse is it too late for > us to change Nova over to that lib in Nova since the BP proposal > deadlines are past? > > -- > # Shawn.Hartsock > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] several oslo library repositories have moved
Thierry, They are listed in projects.yaml already: https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/projects.yaml#L1760 I did push a review to add them to projects.txt in requirements repo: https://review.openstack.org/#/c/72330/ -- dims On Mon, Feb 10, 2014 at 5:44 AM, Thierry Carrez wrote: > Doug Hellmann wrote: >> The Oslo program has adopted cliff, pycadf, stevedore, and taskflow, >> promoting them from stackforge, so we can establish symmetric gating >> with the rest of OpenStack. In order to do that, the git repositories >> were moved from "stackforge/*" to "openstack/*" > > Doug, > > If you adopted those projects you should also push the corresponding > change to the governance repo (projects.yaml). All projects under > openstack*/ must be accounted for. > > Thanks, > > -- > Thierry Carrez (ttx) > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] several oslo library repositories have moved
Done. https://review.openstack.org/#/c/72335/ thanks for the pointer :) -- dims On Mon, Feb 10, 2014 at 7:49 AM, Thierry Carrez wrote: > Davanum Srinivas wrote: >> They are listed in projects.yaml already: >> https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/projects.yaml#L1760 >> >> I did push a review to add them to projects.txt in requirements repo: >> https://review.openstack.org/#/c/72330/ > > Oops. I meant: > > http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml > > -- > Thierry Carrez (ttx) > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Fwd: [Openstack] [GSoC] Call for Mentors and Participants
Hi all, Apologies if you saw this already. Since we have a really tight deadline to drum up mentor and student participation, forwarding this once to the openstack-dev mailing list. The deadline is this Friday the 14th. thanks, dims On Sun, Feb 9, 2014 at 5:34 PM, Davanum Srinivas wrote: > > Hi everyone, > > Anyone wishing to get involved, please flesh out the wiki with topics, > ideas or by listing your name as a mentor or someone looking for a > mentee. This is the most important part of our application, we need to > show enough mentors and project proposals for OpenStack to be accepted > as a participating Organization. Please don't forget to add your > contact details, link to blueprints, reviews, anything that would help > flesh out topics/projects/ideas. > > https://wiki.openstack.org/wiki/GSoC2014 > > Anyone wishing to help fill up the application, Here's our etherpad > for our Application for GSoC 2014. Many thanks to Anne Gentle for > digging up our application for 2012. > > https://etherpad.openstack.org/p/gsoc2014orgapp > > Thanks, > Dims. > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openst...@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -- -Debo~ -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [GSoC] Participate as participant
Robber, Adding your name in wiki is good, we have prepared the organization application for OpenStack Foundation and submitted it. We will hear from them in on 24th (http://www.google-melange.com/gsoc/events/google/gsoc2013) if OpenStack Foundation has been accepted into the GSoC program or not. -- dims On Tue, Feb 18, 2014 at 7:32 AM, Robber Phex wrote: > I mean, should I CC this mail to openst...@lists.openstack.org? > > Because I see this: > "Get in touch with mentors and students through the openstack-dev mailing > list" from wiki. > > > On Tue, Feb 18, 2014 at 6:39 PM, Damon Wang wrote: >> >> Hi Robber, >> >> There are a number of discussions at OpenStack mail-list, you can find >> them at mail-archive. >> >> Hope it helps >> >> Damon >> >> >> 2014-02-18 17:15 GMT+08:00 Robber Phex : >>> >>> And, should I CC this mail to OpenStack maillist? >>> >>> >>> On Tue, Feb 18, 2014 at 5:14 PM, Robber Phex >>> wrote: >>>> >>>> Hello everyone, >>>> >>>> I am RobberPhex, a junior in Donghua University(Shanghai, China). I want >>>> to participate in GSoC this year as Student. I know that OpenStack as a >>>> potential org in GSoC, so I decide to participate. >>>> >>>> I am a Student major in software engineering. In 2012 August, I first >>>> touch OpenStack. After that, I learn OpenStack (included KVM, Python). In >>>> 2013 December, I deploy OpenStack on Server. >>>> For participation, in this winter vacation, I read a book that about >>>> Python, and I try to write Python program (in Github). >>>> >>>> But, I cannot decide (sub)project to participate. If a mentor can guide >>>> me with a easy or medium difficulty project in Openstack, I would be very >>>> grateful. >>>> >>>> BTW, I have added my name to OpenStack GSoC 2014 page. >>>> >>>> Thanks. >>>> >>>> -- >>>> Regards, >>>> RobberPhex >>>> >>>> About me: http://about.me/RobberPhex >>> >>> >>> >>> >>> -- >>> Regards, >>> RobberPhex >>> >>> About me: http://about.me/RobberPhex >>> >>> ___ >>> 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 >> > > > > -- > Regards, > RobberPhex > > About me: http://about.me/RobberPhex > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] OpenStack and GSoC 2014
Hi all, We're in! Just got notified by Admin Team that our Organization Application has been accepted. I've updated the etherpad with the full responses from them. https://etherpad.openstack.org/p/gsoc2014orgapp thanks, dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] GSoC 2014
Andrew, Please see some details regarding projects/ideas/mentors etc in our wiki - https://wiki.openstack.org/wiki/GSoC2014 You can also talk to some of us on #openstack-gsoc irc channel. -- dims On Tue, Feb 25, 2014 at 11:55 AM, Andrew Chul wrote: > Hi, guys! My name is Andrew Chul, I'm from Russia. I had graduated National > Research University "Moscow Power Engineering Institute" a few years ago. > And then I've started to getting post-graduated education in "Smolensk > University of Humanities". > > > The time for filing of an application for participating in projects is > coming and I'm looking forward of 10th March. I've seen your project in the > list of organizations which will take part in Google Summer of Code 2014. > And I need to say that my eyes exploded interest to your project. Why? I > dreamed about such project. I'm very interesting in such areas, as machine > learning, artificial intelligence. And, primarily, I'm developer on php, but > active develop myself in Python. > > > So, 10th March will coming soon and I will fill an application to > participating in your project. I hope that I will be able to work side by > side with you in such interesting and cognitive project. Thank you for > attention. > > > -- > Best regards, Andrew Chul. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] GSoC 2014 shared library for vmware
Hi Masaru, Please get in touch with Arnaud (cc'ed). He has graciously stepped up as a mentor. You can also talk to people on #openstack-vmware and #openstack-Oslo IRC channels. Take a look at the code so far as well - https://github.com/openstack/oslo.vmware Thanks, Dims On Feb 26, 2014 9:26 PM, "Masaru Nomura" wrote: > Hi, > > I'm Masaru Nomura, an MSc student studying computing. My main interests > are OS, VM and programming languages. I'm quite interested in working on an > Oslo project (Implement a re-usable shared library for vmware). > > I've finished reading guide.md (thanks Cabrera, it's helpful to fill in > gaps quickly :) ) and I've been checking some modules, such as nova, cinder > and pyvmomi, to expand on an idea of a new API design. As far as I > understand, it seems some libraries, such as vim.py, that take > responsibility for SOAP calls will be excluded from the current API as > PyVmomi can take this role instead. > > It would be great if somebody could give me some advice of how I can > proceed with the project. Actually, I'm a newbie to OpenStack dev, so any > suggestions would be pleased :) > > Thanks, > Masaru > GitHub : https://github.com/monkey-mas > > ___ > 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] How do I mark one option as deprecating another one ?
Phil,
Correct. We don't have this functionality in oslo.config. Please
create a new feature/enhancement request against oslo
thanks,
dims
On Thu, Feb 27, 2014 at 4:47 AM, Day, Phil wrote:
> Hi Denis,
>
>
>
> Thanks for the pointer, but I looked at that and I my understanding is that
> it only allows me to retrieve a value by an old name, but doesn't let me
> know that the old name has been used. So If all I wanted to do was change
> the name/group of the config value it would be fine. But in my case I need
> to be able to implement:
>
> If new_value_defined:
>
> do_something
>
> else if old_value_defined:
>
> warn_about_deprectaion
>
> do_something_else
>
>
>
> Specifically I want to replace tenant_name based authentication with
> tenant_id - so I need to know which has been specified.
>
>
>
> Phil
>
>
>
>
>
> From: Denis Makogon [mailto:dmako...@mirantis.com]
> Sent: 26 February 2014 14:31
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] How do I mark one option as deprecating another
> one ?
>
>
>
> Here what oslo.config documentation says.
>
>
> Represents a Deprecated option. Here's how you can use it
>
> oldopts = [cfg.DeprecatedOpt('oldfoo', group='oldgroup'),
>cfg.DeprecatedOpt('oldfoo2', group='oldgroup2')]
> cfg.CONF.register_group(cfg.OptGroup('blaa'))
> cfg.CONF.register_opt(cfg.StrOpt('foo', deprecated_opts=oldopts),
>group='blaa')
>
> Multi-value options will return all new and deprecated
> options. For single options, if the new option is present
> ("[blaa]/foo" above) it will override any deprecated options
> present. If the new option is not present and multiple
> deprecated options are present, the option corresponding to
> the first element of deprecated_opts will be chosen.
>
> I hope that it'll help you.
>
>
> Best regards,
>
> Denis Makogon.
>
>
>
> On Wed, Feb 26, 2014 at 4:17 PM, Day, Phil wrote:
>
> Hi Folks,
>
>
>
> I could do with some pointers on config value deprecation.
>
>
>
> All of the examples in the code and documentation seem to deal with the
> case of "old_opt" being replaced by "new_opt" but still returning the same
> value
>
> Here using deprecated_name and / or deprecated_opts in the definition of
> "new_opt" lets me still get the value (and log a warning) if the config
> still uses "old_opt"
>
>
>
> However my use case is different because while I want deprecate old-opt,
> new_opt doesn't take the same value and I need to different things
> depending on which is specified, i.e. If old_opt is specified and new_opt
> isn't I still want to do some processing specific to old_opt and log a
> deprecation warning.
>
>
>
> Clearly I can code this up as a special case at the point where I look for
> the options - but I was wondering if there is some clever magic in
> oslo.config that lets me declare this as part of the option definition ?
>
>
>
>
>
>
>
> As a second point, I thought that using a deprecated option automatically
> logged a warning, but in the latest Devstack wait_soft_reboot_seconds is
> defined as:
>
>
>
> cfg.IntOpt('wait_soft_reboot_seconds',
>
>default=120,
>
>help='Number of seconds to wait for instance to shut down
> after'
>
> ' soft reboot request is made. We fall back to hard
> reboot'
>
> ' if instance does not shutdown within this window.',
>
>deprecated_name='libvirt_wait_soft_reboot_seconds',
>
>deprecated_group='DEFAULT'),
>
>
>
>
>
>
>
> but if I include the following in nova.conf
>
>
>
> libvirt_wait_soft_reboot_seconds = 20
>
>
>
>
>
> I can see the new value of 20 being used, but there is no warning logged
> that I'm using a deprecated name ?
>
>
>
> Thanks
>
> Phil
>
>
>
>
> ___
> 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
>
--
Davanum Srinivas :: http://davanum.wordpress.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [GSoC 2014] Proposal Template
Hi, Is there something we can adopt? can you please send me some pointers to templates from other communities? -- dims On Tue, Mar 4, 2014 at 1:46 PM, Masaru Nomura wrote: > Hi, > > > I have a question about an application format as I can't find it on wiki > page. Is there any specific information I should provide within a proposal? > I checked other communities and some of them have an application template, > so I would just like to make it clear. > > > Thank you, > > Masaru Nomura > > IRC : massa [freenode] > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [GSOC] Guidance for "Add a New Storage Backend" project.
Sai, Please get in touch with Arnaud for oslo.vmware He has graciously stepped up as a mentor. You can also talk to people on #openstack-vmware and #openstack-Oslo IRC channels. Take a look at the code so far as well - https://github.com/openstack/oslo.vmware -- dims On Sun, Mar 2, 2014 at 2:19 PM, saikrishna sripada wrote: > Hi Srinivas/Alej/All, > > Adding to my earlier mail, > > I found "Implement a re-usable shared library for vmware (oslo.vmware) to be > consumed by various OpenStack projects like Nova, Cinder or Glance" also > interesting. > Please help me choose the project and guide me further about contributing > and selection criteria for geting selected in GSOC 2014 and also to > contribute to the project after GSOC. > > Best Regards, > --sai krishna. > > > -- Forwarded message -- > From: saikrishna sripada > Date: Mon, Mar 3, 2014 at 12:11 AM > Subject: Fwd: [GSOC] Guidance for "Add a New Storage Backend" project. > To: openstack-dev@lists.openstack.org, "cpp.cabrera" > > > Hi All/Alej, > > I am a M.S student from India.My current research work is on Computer > Networks, Cloud computing.I have been following involving with openstack > since the past one year. I have contributed to open-stack in the past but > its just bits and pieces here and there. I always thought of picking a > blueprint and implementing it is doable by me with some guidance. Luckily I > found open-stack participating in GSOC 2014.As for me its possible to > implement the"Add a New Storage Backend"project. With my past experience > with the openstack project I am sure I could help your project both during > GSOC and after. Please reply me if you find my idea interesting. > > > Now about me: > I am Sai Krishna, M.S in computer science student at IIIT-Hyderabad > university, Hyderabad.I am good with c++ and python programming. I am > currently working on a tool which uses Bloom filter for Packet attribution > systems (trace back the source of malicious packet efficiently). I am also > having experience building command line modules and handling alarms in > various network elements of Nokia Siemens networks(currently Nokia solutions > networks). I have also worked in deploying openstack on fedora and Ubuntu > distributions and integrating foreman to compute node for auto-discovery > feature. Also fixed two bugs in Glance and keystone modules. > > My study on the task : > Links: > https://wiki.openstack.org/wiki/GSoC2014/Queues/Storage > > https://github.com/cabrera/python-openstack-and-you/blob/master/src/guide.md > - I am familiar with git, gerrit, contributing to openstack. Please check > the handle krishna1256 for my contributions to openstack. > > Kindly bare with my english and Guide me on a head start for working with > the "Add a New Storage Backend" project. > > Thanks and Regards, > --sai krishna. > > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [GSOC] Guidance for "Add a New Storage Backend" project.
Sai, On Sun, Mar 2, 2014 at 2:19 PM, saikrishna sripada wrote: > Hi Srinivas/Alej/All, > > Adding to my earlier mail, > > I found "Implement a re-usable shared library for vmware (oslo.vmware) to be > consumed by various OpenStack projects like Nova, Cinder or Glance" also > interesting. > Please help me choose the project and guide me further about contributing > and selection criteria for geting selected in GSOC 2014 and also to > contribute to the project after GSOC. > > Best Regards, > --sai krishna. > > > -- Forwarded message -- > From: saikrishna sripada > Date: Mon, Mar 3, 2014 at 12:11 AM > Subject: Fwd: [GSOC] Guidance for "Add a New Storage Backend" project. > To: openstack-dev@lists.openstack.org, "cpp.cabrera" > > > Hi All/Alej, > > I am a M.S student from India.My current research work is on Computer > Networks, Cloud computing.I have been following involving with openstack > since the past one year. I have contributed to open-stack in the past but > its just bits and pieces here and there. I always thought of picking a > blueprint and implementing it is doable by me with some guidance. Luckily I > found open-stack participating in GSOC 2014.As for me its possible to > implement the"Add a New Storage Backend"project. With my past experience > with the openstack project I am sure I could help your project both during > GSOC and after. Please reply me if you find my idea interesting. > > > Now about me: > I am Sai Krishna, M.S in computer science student at IIIT-Hyderabad > university, Hyderabad.I am good with c++ and python programming. I am > currently working on a tool which uses Bloom filter for Packet attribution > systems (trace back the source of malicious packet efficiently). I am also > having experience building command line modules and handling alarms in > various network elements of Nokia Siemens networks(currently Nokia solutions > networks). I have also worked in deploying openstack on fedora and Ubuntu > distributions and integrating foreman to compute node for auto-discovery > feature. Also fixed two bugs in Glance and keystone modules. > > My study on the task : > Links: > https://wiki.openstack.org/wiki/GSoC2014/Queues/Storage > > https://github.com/cabrera/python-openstack-and-you/blob/master/src/guide.md > - I am familiar with git, gerrit, contributing to openstack. Please check > the handle krishna1256 for my contributions to openstack. > > Kindly bare with my english and Guide me on a head start for working with > the "Add a New Storage Backend" project. > > Thanks and Regards, > --sai krishna. > > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [GSOC][Gantt]Cross-services Scheduler
Hi Fang, Agree with Russell. Also please update the wiki with your information https://wiki.openstack.org/wiki/GSoC2014 and also information about the mentor/ideas as well (if you have not yet done so already). You can reach out to folks on #openstack-gsoc and #openstack-nova IRC channels as well thanks, dims On Wed, Mar 5, 2014 at 10:12 AM, Russell Bryant wrote: > On 03/05/2014 09:59 AM, 方祯 wrote: >> Hi: >> I'm Fang Zhen, an M.S student from China. My current research work is on >> scheduling policy on cloud computing. I have been following the >> openstack for about 2 years.I always thought of picking a blueprint and >> implementing it with the community's guidance.Luckily, open-stack >> participates GSOC this year and is is impossible for me to implement >> "Cross-services Scheduler" of Openstack-Gantt project.And also, I'm sure >> that I can continue to help to openstack after GSOC. > > Thanks for your interest in OpenStack! > > I think the project as you've described it is far too large to be able > to implement in one GSoC term. If you're interested in scheduling, > perhaps we can come up with a specific enhancement to Nova's current > scheduler that would be more achievable in the time allotted. I want to > make sure we're setting you up for success, and I think helping scope > the project is a big early part of that. > > -- > Russell Bryant > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Wednesday Bug Day
If you haven't seen Tracy's bug triage page yet, here it is: http://54.201.139.117/nova-bugs.html -- dims On Tue, Nov 18, 2014 at 7:27 PM, Joe Gordon wrote: > Hi All, > > At the kilo nova meeting up in Paris, We had a lengthy discussion on better > bug management. One of the action items was to make every Wednesday a bug > day nova in #openstack-nova [0]. So tomorrow will be our first attempt at > "Bug Wednesday." One of the issues we found with previous bug meeting > efforts was holding them off in a meeting room away from most of the nova > developers. Instead we are trying to set aside all of Wednesday as the day > where nova developers get together and discuss potential bugs, bug fixes in > #openstack-nova. So if you found a bug or are working on a bug fix and would > like feedback (or a review), join #openstack-nova and we, the nova team, > will try to help out. > > best, > Joe > > > P.S. We are not sure if this will work, but at the meetup we agreed it was > at least worth a try. > > [0] https://etherpad.openstack.org/p/kilo-nova-meetup > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] scheduling a review day
Sounds good Doug. -- dims On Fri, Nov 21, 2014 at 12:07 PM, Doug Hellmann wrote: > We have a bit of a backlog in the Oslo review queue. Before we add a bunch of > new reviews for Kilo work, I’d like to see if we can clear some of the > existing reviews. One idea I had was setting aside a “review day”, where we > spend a work day on reviews together, coordinating and doing fast > turn-arounds via IRC. > > I know most of the team works on projects other than Oslo, including > company-focused work, so I don’t think we want to try to go more than a day > and that we would need time to coordinate other schedules to allow the time. > How many people could/would participate in a review day like this on 4 > December? > > Doug > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] removing XML testing completely from Tempest
+1 to cleanup. -- dims On Mon, Nov 24, 2014 at 12:50 PM, Monty Taylor wrote: > On 11/24/2014 12:36 PM, Lance Bragstad wrote: >> We are in the process of removing XML support from Keystone [1] and have >> provided >> configuration options to Tempest for testing XML in older releases [2]. >> However, the >> identity client is still tightly coupled to XML test cases. We can either >> fix the 309 test cases >> that use the XML identity client or let those cases be removed from >> Tempest. I'd like to let this >> air out a bit before I start fixing the identity client XML issues, in case >> XML testing is completely >> removed from Tempest. > > I fully support and am excited about removing the xml api support. > >> [1] https://review.openstack.org/#/c/125738/ >> [2] https://review.openstack.org/#/c/127641/ >> https://review.openstack.org/#/c/130874/ >> https://review.openstack.org/#/c/126564/ >> >> On Mon, Nov 24, 2014 at 8:03 AM, Jay Pipes wrote: >> >>> On 11/24/2014 08:56 AM, Sean Dague wrote: >>> >>>> Having XML payloads was never a universal part of OpenStack services. >>>> During the Icehouse release the TC declared that being an OpenStack >>>> service requires having a JSON REST API. Projects could do what they >>>> wanted beyond that. Lots of them deprecated and have been removing the >>>> XML cruft since then. >>>> >>>> Tempest is a tool to test the OpenStack API. OpenStack hasn't had an XML >>>> API for a long time. >>>> >>>> Given that current branchless Tempest only supports as far back as >>>> Icehouse anyway, after these changes were made, I'd like to propose that >>>> all the XML code in Tempest should be removed. If a project wants to >>>> support something else beyond a JSON API that's on that project to test >>>> and document on their own. >>>> >>>> We've definitively blocked adding new XML tests in Tempest anyway, but >>>> getting rid of the XML debt in the project will simplify it quite a bit, >>>> make it easier for contributors to join in, and seems consistent with >>>> the direction of OpenStack as a whole. >>>> >>> >>> But Sean, without XML support, we will lose all of our enterprise >>> customers! >>> >>> -jay >>> >>> >>> ___ >>> 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 -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] sqlalchemy-migrate call for reviews
Looks like there is a review in the queue - https://review.openstack.org/#/c/111485/ -- dims On Sat, Nov 29, 2014 at 6:28 PM, Jeremy Stanley wrote: > To anyone who reviews sqlalchemy-migrate changes, there are people > talking to themselves on GitHub about long-overdue bug fixes because > the Gerrit review queue for it is sluggish and they apparently don't > realize the SQLAM reviewers don't look at Google Code issues[1] and > GitHub pull request comments[2]. > > [1] https://code.google.com/p/sqlalchemy-migrate/issues/detail?id=171 > [2] https://github.com/stackforge/sqlalchemy-migrate/pull/5 > > -- > Jeremy Stanley > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] oslo.utils 1.1.0 released
The Oslo team is pleased to announce the release of oslo.utils 1.1.0. This release includes several bug fixes as well as many other changes. For more details, please see the git log history below and https://launchpad.net/oslo.utils/+milestone/1.1.0 Please report issues through launchpad: https://launchpad.net/oslo.utils $ git log --no-color --oneline --no-merges 1.0.0..1.1.0 ed9a695 Add get_my_ip() fb28c02 Updated from global requirements dbc02d0 Add 'auth_password' in _SANITIZE_KEYS for strutils f0cce3c Updated from global requirements b8d5872 Activate pep8 check that _ is imported 45b7166 Add uuidutils to oslo.utils 3b9df71 Add pbr to installation requirements 7b32a91 Updated from global requirements 760dbc7 Add is_int_like() function 5d034e5 Hide auth_token and new_pass a74d9ee Imported Translations from Transifex c7ef2c2 Add history/changelog to docs 563a990 Imported Translations from Transifex c6bdcce Support building wheels (PEP-427) cac930c Imported Translations from Transifex d4e87e8 Improve docstrings for IP verification functions b5ab4d0 Imported Translations from Transifex baacebc Add ip address validation 5d3b3da Fix how it appears we need to use mock_anything to avoid 'self' errors dba9f9a Updated from global requirements 614a849 Move over a reflection module that taskflow uses f02f8df Make safe_encode func case-insensitive e54a359 Enable mask_password to handle byte code strings f79497e Updated from global requirements 08a348c Add the ability to extract the query params from a urlsplit fa77453 Work toward Python 3.4 support and testing 8a858b7 warn against sorting requirements $ git diff --stat --no-color 1.0.0..1.1.0 | egrep -v '(/tests/|^ doc)' .../en_GB/LC_MESSAGES/oslo.utils-log-critical.po | 21 -- .../en_GB/LC_MESSAGES/oslo.utils-log-info.po | 21 -- .../locale/fr/LC_MESSAGES/oslo.utils-log-error.po | 32 +++ .../fr/LC_MESSAGES/oslo.utils-log-warning.po | 33 +++ oslo.utils/locale/fr/LC_MESSAGES/oslo.utils.po | 38 +++ oslo/utils/encodeutils.py | 6 + oslo/utils/netutils.py | 101 oslo/utils/reflection.py | 208 +++ oslo/utils/strutils.py | 24 +- oslo/utils/uuidutils.py| 44 requirements.txt | 9 +- setup.cfg | 3 + test-requirements.txt | 12 +- tests/test_excutils.py | 3 +- tests/test_netutils.py | 80 ++ tests/test_reflection.py | 279 + tests/test_strutils.py | 38 +++ tests/test_uuidutils.py| 51 tests/tests_encodeutils.py | 65 - tox.ini| 3 +- $ git diff -U0 --no-color 1.0.0..1.1.0 *requirements*.txt | sed -e 's/^/ /g' diff --git a/requirements.txt b/requirements.txt index 4421ce9..c508f12 100644 --- a/requirements.txt +++ b/requirements.txt @@ -0,0 +1,5 @@ +# The order of packages is significant, because pip processes them in the order +# of appearance. Changing the order has an impact on the overall integration +# process, which may cause wedges in the gate later. + +pbr>=0.6,!=0.7,<1.0 @@ -4 +9,3 @@ iso8601>=0.1.9 -oslo.i18n>=0.2.0 # Apache-2.0 +oslo.i18n>=1.0.0 # Apache-2.0 +netaddr>=0.7.12 +netifaces>=0.10.4 diff --git a/test-requirements.txt b/test-requirements.txt index 043d97f..0fab2b3 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -0,0 +1,4 @@ +# The order of packages is significant, because pip processes them in the order +# of appearance. Changing the order has an impact on the overall integration +# process, which may cause wedges in the gate later. + @@ -8,2 +12,2 @@ testscenarios>=0.4 -testtools>=0.9.34 -oslotest>=1.1.0.0a1 +testtools>=0.9.36,!=1.2.0 +oslotest>=1.2.0 # Apache-2.0 @@ -17,2 +21,2 @@ coverage>=3.6 -sphinx>=1.1.2,!=1.2.0,<1.3 -oslosphinx>=2.2.0.0a2 +sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3 +oslosphinx>=2.2.0 # Apache-2.0 -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] oslo.i18n 1.1.0 released
The Oslo team is pleased to announce the release of oslo.i18n 1.1.0. For more details, please see the git log history below and https://launchpad.net/oslo.i18n/+milestone/1.1.0 Please report issues through launchpad: https://launchpad.net/oslo.i18n $ git log --no-color --oneline --no-merges 1.0.0..1.1.0 5a163eb Imported Translations from Transifex 1fc63ac Add note for integration modules in libraries 2fe3f73 Activate pep8 check that _ is imported d67767b Add pbr to installation requirements 3583c89 Updated from global requirements 497f8d3 Updated from global requirements 624c52c Remove extraneous vim editor configuration comments 9b6a9c2 Make clear in docs to use _LE() when using LOG.exception() 999a112 Support building wheels (PEP-427) 47c5d73 Imported Translations from Transifex 3041689 Fix coverage testing 04752ee Imported Translations from Transifex 26edee1 Use same indentation in doc/source/usage 12f14da Imported Translations from Transifex c9f2b63 Imported Translations from Transifex af4fc2c Updated from global requirements efbe658 Remove unused/mutable default args f721da7 Fixes a small syntax error in the doc examples 0624f8d Work toward Python 3.4 support and testing $ git diff --stat --no-color 1.0.0..1.1.0 | egrep -v '(/tests/|^ doc)' .../en_GB/LC_MESSAGES/oslo.i18n-log-critical.po| 21 --- .../en_GB/LC_MESSAGES/oslo.i18n-log-error.po | 21 --- .../locale/en_GB/LC_MESSAGES/oslo.i18n-log-info.po | 21 --- .../en_GB/LC_MESSAGES/oslo.i18n-log-warning.po | 21 --- oslo.i18n/locale/fr/LC_MESSAGES/oslo.i18n.po | 35 +++ .../it/LC_MESSAGES/oslo.i18n-log-critical.po | 21 --- .../locale/it/LC_MESSAGES/oslo.i18n-log-error.po | 21 --- .../locale/it/LC_MESSAGES/oslo.i18n-log-info.po| 21 --- .../locale/it/LC_MESSAGES/oslo.i18n-log-warning.po | 21 --- oslo.i18n/locale/ko_KR/LC_MESSAGES/oslo.i18n.po| 33 +++ oslo.i18n/locale/zh_CN/LC_MESSAGES/oslo.i18n.po| 31 ++ oslo/__init__.py | 2 - requirements.txt | 5 ++ setup.cfg | 3 + test-requirements.txt | 10 +++- tests/test_gettextutils.py | 3 +- tox.ini| 3 +- 19 files changed, 184 insertions(+), 206 deletions(-) $ git diff -U0 --no-color 1.0.0..1.1.0 *requirements*.txt | sed -e 's/^/ /g' diff --git a/requirements.txt b/requirements.txt index b25096e..5bef251 100644 --- a/requirements.txt +++ b/requirements.txt @@ -0,0 +1,5 @@ +# The order of packages is significant, because pip processes them in the order +# of appearance. Changing the order has an impact on the overall integration +# process, which may cause wedges in the gate later. + +pbr>=0.6,!=0.7,<1.0 diff --git a/test-requirements.txt b/test-requirements.txt index a4acbb6..1fe2384 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -0,0 +1,3 @@ +# The order of packages is significant, because pip processes them in the order +# of appearance. Changing the order has an impact on the overall integration +# process, which may cause wedges in the gate later. @@ -3,2 +6,2 @@ hacking>=0.9.2,<0.10 -sphinx>=1.1.2,!=1.2.0,<1.3 -oslosphinx>=2.2.0.0a2 +sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3 +oslosphinx>=2.2.0 # Apache-2.0 @@ -6 +9,2 @@ oslosphinx>=2.2.0.0a2 -oslotest>=1.1.0.0a1 +oslotest>=1.2.0 # Apache-2.0 +coverage>=3.6 -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] oslo.vmware 0.8.0 released
The Oslo team is pleased to announce the release of oslo.vmware 0.8.0. For more details, please see the git log history below and https://launchpad.net/oslo.vmware/+milestone/0.8.0 Please report issues through launchpad: https://launchpad.net/oslo.vmware $ git log --no-color --oneline --no-merges 0.7.0..0.8.0 969bfba Switch to use requests/urllib3 and enable cacert validation 5b9408f Updated from global requirements 9d9bf2f Updated from global requirements 1ebbc4d Enable support for python 3.x 4dc0ded Updated from global requirements 589ba43 Activate pep8 check that _ is imported $ git diff --stat --no-color 0.7.0..0.8.0 | egrep -v '(/tests/|^ doc)' oslo/vmware/api.py | 2 +- oslo/vmware/exceptions.py| 30 -- oslo/vmware/image_transfer.py| 3 +- oslo/vmware/objects/datastore.py | 2 +- oslo/vmware/pbm.py | 4 +- oslo/vmware/rw_handles.py| 215 --- oslo/vmware/service.py | 19 ++-- oslo/vmware/vim_util.py | 4 +- requirements-py3.txt | 24 + requirements.txt | 1 + test-requirements.txt| 4 +- tests/objects/test_datastore.py | 2 +- tests/test_api.py| 7 +- tests/test_image_transfer.py | 3 +- tests/test_pbm.py| 8 +- tests/test_rw_handles.py | 35 +++ tests/test_service.py| 33 -- tox.ini | 12 ++- 18 files changed, 240 insertions(+), 168 deletions(-) $ git diff -U0 --no-color 0.7.0..0.8.0 *requirements*.txt | sed -e 's/^/ /g' diff --git a/requirements-py3.txt b/requirements-py3.txt new file mode 100644 index 000..b14f525 --- /dev/null +++ b/requirements-py3.txt @@ -0,0 +1,24 @@ +# The order of packages is significant, because pip processes them in the order +# of appearance. Changing the order has an impact on the overall integration +# process, which may cause wedges in the gate later. + +stevedore>=1.1.0 # Apache-2.0 +netaddr>=0.7.12 + +# for timeutils +iso8601>=0.1.9 + +# for jsonutils +six>=1.7.0 + +oslo.i18n>=1.0.0 # Apache-2.0 +oslo.utils>=1.0.0 # Apache-2.0 +Babel>=1.3 + +# for the routing notifier +PyYAML>=3.1.0 + +suds-jurko>=0.6 +eventlet>=0.15.2 +requests>=2.2.0,!=2.4.0 +urllib3>=1.7.1 diff --git a/requirements.txt b/requirements.txt index c019874..6939fd3 100644 --- a/requirements.txt +++ b/requirements.txt @@ -23,0 +24 @@ requests>=2.2.0,!=2.4.0 +urllib3>=1.7.1 diff --git a/test-requirements.txt b/test-requirements.txt index 61fd4eb..cfaa103 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -7 +7 @@ hacking>=0.9.2,<0.10 -pylint==0.25.2 +pylint>=1.3.0 # GNU GPL v2 @@ -16 +16 @@ testscenarios>=0.4 -testtools>=0.9.36 +testtools>=0.9.36,!=1.2.0 -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] global or per-project specific ssl config options, or both?
+1 to @markmc's "default is global value and override for project specific key" suggestion. -- dims On Wed, Dec 3, 2014 at 11:57 PM, Matt Riedemann wrote: > I've posted this to the 12/4 nova meeting agenda but figured I'd socialize > it here also. > > SSL options - do we make them per-project or global, or both? Neutron and > Cinder have config-group specific SSL options in nova, Glance is using oslo > sslutils global options since Juno which was contentious for a time in a > separate review in Icehouse [1]. > > Now [2] wants to break that out for Glance, but we also have a patch [3] for > Keystone to use the global oslo SSL options, we should be consistent, but > does that require a blueprint now? > > In the Icehouse patch, markmc suggested using a DictOpt where the default > value is the global value, which could be coming from the oslo [ssl] group > and then you could override that with a project-specific key, e.g. cinder, > neutron, glance, keystone. > > [1] https://review.openstack.org/#/c/84522/ > [2] https://review.openstack.org/#/c/131066/ > [3] https://review.openstack.org/#/c/124296/ > > -- > > Thanks, > > Matt Riedemann > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward
cascading solution: > https://wiki.openstack.org/wiki/OpenStack_cascading_solution > [3]Cascading PoC: https://github.com/stackforge/tricircle > [4]Vodafone use case (9'02" to 12'30"): > https://www.youtube.com/watch?v=-KOJYvhmxQI > [5]Telefonica use case: > http://www.telefonica.com/en/descargas/mwc/present_20140224.pdf > [6]ETSI NFV use cases: > http://www.etsi.org/deliver/etsi_gs/nfv/001_099/001/01.01.01_60/gs_nfv001v010101p.pdf > [7]Cascading thread before design summit: > http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-td54115.html > > Best Regards > Chaoyi Huang (joehuang) > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Remove XML support from Nova API
Hi Team, We currently have disabled XML support when https://review.openstack.org/#/c/134332/ merged. I've prepared a followup patch series to entirely remove XML support [1] soon after we ship K1. I've marked it as WIP for now though all tests are working fine. Looking forward to your feedback. thanks, dims [1] https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:nuke-xml,n,z -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][docker][containers][qa] nova-docker CI failing a lot on unrelated nova patches
Sean, fyi, got it stable now for the moment. http://logstash.openstack.org/#eyJzZWFyY2giOiIgYnVpbGRfbmFtZTpcImNoZWNrLXRlbXBlc3QtZHN2bS1kb2NrZXJcIiBBTkQgbWVzc2FnZTpcIkZpbmlzaGVkOlwiIEFORCBidWlsZF9zdGF0dXM6XCJGQUlMVVJFXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjE3MjgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIiLCJzdGFtcCI6MTQxODIyMzEwMjcyOX0= with https://review.openstack.org/#/c/138714/ thanks, dims On Wed, Dec 10, 2014 at 6:37 AM, Sean Dague wrote: > On 12/09/2014 06:18 PM, Eric Windisch wrote: >> >> While gating on nova-docker will prevent patches that cause >> nova-docker to break 100% to land, it won't do a lot to prevent >> transient failures. To fix those we need people dedicated to making >> sure nova-docker is working. >> >> >> >> What would be helpful for me is a way to know that our tests are >> breaking without manually checking Kibana, such as an email. > > I know that periodic jobs can do this kind of notification, if you ask > about it in #openstack-infra there might be a solution there. > > However, having a job in infra on Nova is a thing that comes with an > expectation that someone is staying engaged on the infra and Nova sides > to ensure that it's running correctly, and debug it when it's wrong. > It's not a set it and forget it. > > It's already past the 2 weeks politeness boundary before it's considered > fair game to just delete it. > > Creating the job is < 10% of the work. Long term maintenance is > important. I'm still not getting the feeling that there is really a long > term owner on this job. I'd love that not to be the case, but simple > things like the fact that the directory structure was all out of whack > make it clear no one was regularly looking at it. > > -Sean > > -- > Sean Dague > http://dague.net > > _______ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] deprecation 'pattern' library??
Surprisingly "deprecator" is still available on pypi On Thu, Dec 11, 2014 at 2:04 AM, Julien Danjou wrote: > On Wed, Dec 10 2014, Joshua Harlow wrote: > > > […] > >> Or in general any other comments/ideas about providing such a deprecation >> pattern library? > > +1 > >> * debtcollector > > made me think of "loanshark" :)" > > -- > Julien Danjou > -- Free Software hacker > -- http://julien.danjou.info > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] 'SetuptoolsVersion' object does not support indexing 2014-12-14 12:38:38.563 |
Jeremy, Gary, I have a patch in progress: Nova - https://review.openstack.org/141654/ Oslo-incubator - https://review.openstack.org/#/c/141653/ thanks, dims On Sun, Dec 14, 2014 at 10:09 AM, Jeremy Stanley wrote: > On 2014-12-14 13:40:56 + (+), Gary Kotton wrote: >> Anyone familiar with the cause of this – seems like all unit tests >> are failing. An example is below: > [...] >> 2014-12-14 12:38:38.596 | File >> "nova/openstack/common/versionutils.py", line 200, in is_compatible >> 2014-12-14 12:38:38.596 | if same_major and (requested_parts[0] != >> current_parts[0]): >> 2014-12-14 12:38:38.596 | TypeError: 'SetuptoolsVersion' object does not >> support indexing > > Setuptools 8 was released to PyPI yesterday, so versionutils.py is > probably tickling some behavior change in it. > -- > Jeremy Stanley > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] - Revert change of default ephemeral fs to ext4
Matt, i'll take a stab at it thanks, dims On Tue, Dec 16, 2014 at 5:18 PM, Matt Riedemann wrote: > > > On 12/30/2013 7:30 PM, Clint Byrum wrote: >> >> Excerpts from Day, Phil's message of 2013-12-30 11:05:17 -0800: >>> >>> Hi, so it seems we were saying the same thing - new vms get a shared >>> "blank" (empty) file system, not blank disc. How big a problem it is that >>> in many cases this will be the already created ext3 disk and not ext4 >>> depends I guess on how important consistency is to you (to me its pretty >>> important). Either way the change as it stands wont give all new vms an >>> ext4 fs as intended, so its flawed in that regard. >>> >>> Like you I was thinking that we may have to move away from "default" >>> being in the file name to fix this. >>> >> >> Indeed, "default"'s meaning is mutable and thus it is flawed as a >> cache key. >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > jogo brought this bug up in IRC today [1]. The bug report says that we > should put in the Icehouse release notes that ext3 is going to be changed to > ext4 in Juno but that never happened. So question is, now that we're well > into Kilo, what can be done about this now? The thread here talks about > doing more than just changing the default value like in the original change > [2], but is someone willing to work on that? > > [1] https://bugs.launchpad.net/nova/+bug/1266262 > [2] https://review.openstack.org/#/c/63209/ > > -- > > Thanks, > > Matt Riedemann > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [python-*client] py33 jobs seem to be failing
Amit, from chatter on infra irc,. should be almost done if not already done. if you see any jobs fail recheck, you may want to hop onto irc. thanks, dims On Fri, Dec 19, 2014 at 11:19 AM, Amit Gandhi wrote: > Is there an ETA for this fix? > > Thanks > Amit. > > >> On Dec 17, 2014, at 3:38 PM, Jeremy Stanley wrote: >> >> On 2014-12-17 11:09:59 -0500 (-0500), Steve Martinelli wrote: >> [...] >>> The stack trace leads me to believe that docutils or sphinx is the >>> culprit, but neither has released a new version in the time the >>> bug has been around, so I'm not sure what the root cause of the >>> problem is. >> >> It's an unforeseen interaction between new PBR changes to support >> Setuptools 8 and the way docutils supports Py3K by running 2to3 >> during installation (entrypoint scanning causes pre-translated >> docutils to be loaded into the execution space through the egg-info >> writer PBR grew to be able to record Git SHA details outside of >> version strings). A solution is currently being developed. >> -- >> Jeremy Stanley >> >> ___ >> 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 -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Magnum] Proposed Changes to Magnum Core
+1 welcome! On Dec 26, 2014 3:48 PM, "Adrian Otto" wrote: > Magnum Cores, > > I propose the following addition to the Magnum Core group[1]: > > + Motohiro/Yuanying Otsuka (ootsuka) > > Please let me know your votes by replying to this message. > > Thanks, > > Adrian > > [1] https://review.openstack.org/#/admin/groups/473,members Current > Members > > ___ > 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] [Magnum] Proposed Changes to Magnum Core
+1 from me. Welcome Jay! On Jan 2, 2015 7:02 PM, "Adrian Otto" wrote: > Magnum Cores, > > I propose the following addition to the Magnum Core group[1]: > > + Jay Lau (jay-lau-513) > > Please let me know your votes by replying to this message. > > Thanks, > > Adrian > > [1] https://review.openstack.org/#/admin/groups/473,members Current > Members > > ___ > 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] dropping namespace packages
Jay, I have a hacking rule in nova already [1] and am updating the rule in the 3 reviews i have for oslo_utils, oslo_middleware and oslo_config [2] in Nova thanks, dims [1] https://github.com/openstack/nova/blob/master/nova/hacking/checks.py#L452 [2] https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:remove-oslo-namespace,n,z On Sat, Jan 10, 2015 at 9:26 PM, Jay S. Bryant wrote: > Ihar, > > I agree that we should do something to enforce using the appropriate > namespace so that we don't have the wrong usage sneak in. > > I haven't gotten any rules written yet. Have had to attend to a family > commitment the last few days. Hope that I can tackle the namspace changes > next week. > > Jay > > On 01/08/2015 12:24 PM, Ihar Hrachyshka wrote: >> >> On 01/08/2015 07:03 PM, Doug Hellmann wrote: >>> >>> I’m not sure that’s something we need to enforce. Liaisons should be >>> updating projects now as we release libraries, and then we’ll consider >>> whether we can drop the namespace packages when we plan the next cycle. >> >> >> Without a hacking rule, there is a chance old namespace usage will sneak >> in, and then we'll need to get back to updating imports. I would rather >> avoid that and get migration committed with enforcement. >> >> /Ihar >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ 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] Test failures due to oslo_concurrency?
Kevin, We are waiting for https://review.openstack.org/#/c/146940/ to land. then cut a fresh oslo.concurrency version. There's another requirements change as well, which when landed can help. https://review.openstack.org/#/c/146942/ thanks, dims On Tue, Jan 13, 2015 at 4:20 PM, Kevin L. Mitchell wrote: > Noticed that https://review.openstack.org/#/c/145626/ failed tests. > That's kind of curious, as all it does is alter HACKING.rst. > Investigation of the test failures[1] showed some UTF-8 decoding errors > that appeared to be coming from oslo_concurrency/processutils.py. Any > ideas? > > [1] > http://logs.openstack.org/26/145626/2/check/gate-nova-python27/b350bbc/console.html > -- > Kevin L. Mitchell > Rackspace > > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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][python-clients] More freedom for all python clients
t; requirements of non base-caas projects but I think this is a more >> welcoming (and non-blocking) way to do things until we've a better >> one. >> >> Hope the above makes some sense I blame the lack of coffee if it >> doesn't, >> Flavio > > We have the base infrastructure of that in devstack today with a SOFT > requirements update - > https://github.com/openstack-dev/devstack/blob/master/functions-common#L1696-L1704 > > If you are not in projects.txt, and you set your REQUIREMENTS_MODE=soft > in your devstack run, we will leave extra dependencies untouched. > Probably a few more bits required to make it really easy to expose, but > that direction is also feasable. > > The reason I brought up domains though is that some groups really want > the facility to have common requirements lists across a domain. Like the > OpenStack Docs team. They've currently inserted a ton of stuff in g-r > that really shouldn't be there because they have a lot of git trees, and > the synchronization is a nice feature. > > However, if there were domain specific lists, that would be fine. A > collection of projects that want to coordinate could all agree on a > domain specific set of lists, and off we go. Maybe that list wouldn't > even need to be contained in the main repo, it could be in a sub repo so > have different approvers. > > -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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] How to debug test cases in Openstack
Abhishek, In addition to the tips above, i put up a post for using py.test and testtools.run as well here: https://davanum.wordpress.com/2015/01/13/quickly-running-a-single-openstack-nova-test/ -- dims On Fri, Jan 16, 2015 at 11:44 AM, Adam Young wrote: > On 01/16/2015 12:37 AM, Abhishek Talwar/HYD/TCS wrote: > > Hi, > > I have been trying to debug the test cases in OpenStack, but I am not > getting successful with it. So if someone can help me with that. The last > response from the dev-list was to use " $ ./run_tests.sh -d [test module > path] " but this gives bDb quit error. > > > Depends on the project. The majority of the projects have moved over to > using tox. In Keystone, tox will run everything, which might be to much; > > > tox -epy27 > > is usually what I run for unit tests and > > tox -epep8 > > explicitly for pep8 testing. > > To run a specific file full of tests: > > tox -e py27 test_v3_auth > > works as does > > > tox -e py27 keysteon.tests.test_v3_auth.TestPKIZTokenAPIs > > > So kindly help me this. > -- > Thanks and Regards > Abhishek Talwar > > =-=-= > Notice: The information contained in this e-mail > message and/or attachments to it may contain > confidential or privileged information. If you are > not the intended recipient, any dissemination, use, > review, distribution, printing or copying of the > information contained in this e-mail message > and/or attachments to it are strictly prohibited. If > you have received this communication in error, > please notify us by reply e-mail or telephone and > immediately and permanently delete the message > and any attachments. 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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_log/oslo_config initialization
Qiming, Nova already uses oslo.config. there's a patch against nova to use oslo_log. Doug took the effort to do this so we'd not face issues once we release oslo_log, so yes, they have been tested together. Please hop onto #openstack-oslo to debug in real time. [1] https://review.openstack.org/#/c/147635/ On Wed, Jan 21, 2015 at 8:11 AM, Qiming Teng wrote: > On Wed, Jan 21, 2015 at 12:27:15PM +0200, Denis Makogon wrote: >> On Wed, Jan 21, 2015 at 12:16 PM, Qiming Teng >> wrote: >> >> > Hi, >> > >> > In the oslo_log 0.1.0 release, the setup() function demands for a conf >> > parameter, but I have failed to find any hint about setting this up. >> > >> > The problem is cfg.CONF() returns None, so the following code fails: >> > >> > conf = cfg.CONF(name='prog', project='project') >> > # conf is always None here, so the following call fails >> > log.setup(conf, 'project') >> > >> > Another attempt also failed, because it cannot find any options: >> > >> > log.setup(cfg.CONF, 'project') >> > >> > Any hint or sample code to setup logging if I'm abandoning the log >> > module from oslo.incubator? >> > >> > >> You might take a look at >> https://github.com/openstack/oslo.log/blob/master/oslo_log/_options.py >> Those options are what oslo_log expects to find in service configuration >> files. > > Okay, my guess is that both oslo_config and oslo_log are trying to > register_cli_options. I have to create a configuration object for > oslo_log to work, and it means CLI options are registered once. > Later on, when I'm calling log.register_options(), it is conflicting > with previous registration. > > So, I'm doubting whether these two packages have been tested together? > > Regards, > Qiming > >> > Regards, >> > Qiming >> > >> > >> > __ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> >> Kind regards, >> Denis M. > >> __ >> 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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_log/oslo_config initialization
Qiming,
Guessing you were looking at master. if you checkout the review i
pointed to, you will see what others on the thread have pointed you
to:
https://github.com/openstack/oslo.log/blob/master/doc/source/usage.rst
We are using register_options and setup. we should be adding
register_options in the future as need arises.
dims@dims-mac:~/openstack/nova$ find . -name "*.py" -exec grep -H
logging {} \; | grep -e "\.setup" -e "\.register_options" -e
"\.set_defaults"
./nova/cmd/all.py:logging.setup(CONF, "nova")
./nova/cmd/api.py:logging.setup(CONF, "nova")
./nova/cmd/api_ec2.py:logging.setup(CONF, "nova")
./nova/cmd/api_metadata.py:logging.setup(CONF, "nova")
./nova/cmd/api_os_compute.py:logging.setup(CONF, "nova")
./nova/cmd/cells.py:logging.setup(CONF, 'nova')
./nova/cmd/cert.py:logging.setup(CONF, "nova")
./nova/cmd/compute.py:logging.setup(CONF, 'nova')
./nova/cmd/conductor.py:logging.setup(CONF, "nova")
./nova/cmd/console.py:logging.setup(CONF, "nova")
./nova/cmd/consoleauth.py:logging.setup(CONF, "nova")
./nova/cmd/dhcpbridge.py:logging.setup(CONF, "nova")
./nova/cmd/manage.py:logging.setup(CONF, "nova")
./nova/cmd/network.py:logging.setup(CONF, "nova")
./nova/cmd/novncproxy.py:logging.setup(CONF, "nova")
./nova/cmd/novncproxy.py:logging.setup(CONF, "nova")
./nova/cmd/objectstore.py:logging.setup(config.CONF, "nova")
./nova/cmd/scheduler.py:logging.setup(CONF, "nova")
./nova/cmd/serialproxy.py:logging.setup(CONF, "nova")
./nova/cmd/spicehtml5proxy.py:logging.setup(CONF, "nova")
./nova/cmd/xvpvncproxy.py:logging.setup(config.CONF, "nova")
./nova/openstack/common/report/guru_meditation_report.py:
logging.setup(CONF, 'blah')
./nova/test.py:logging.register_options(CONF)
./nova/test.py:logging.setup(CONF, 'nova')
If you file a review with what you have, maybe we can help, again, pop
onto the #openstack-oslo channel to ask
-- dims
On Wed, Jan 21, 2015 at 10:25 AM, Qiming Teng
wrote:
> On Wed, Jan 21, 2015 at 08:25:57AM -0500, Davanum Srinivas wrote:
>> Qiming,
>>
>> Nova already uses oslo.config. there's a patch against nova to use
>> oslo_log. Doug took the effort to do this so we'd not face issues once
>> we release oslo_log, so yes, they have been tested together. Please
>> hop onto #openstack-oslo to debug in real time.
>>
>> [1] https://review.openstack.org/#/c/147635/
>>
>
> Well, just checked nova code, it seems openstack.common.log is still
> there. That means there are duplicated code such as the
> 'common_cli_opts' which resides in both openstack.common.log and
> oslo_log._options.
>
> I was getting the following error if I'm deleting openstack.common.log
> module:
>
> oslo_config.cfg.NoSuchOptError: no such option: log_config_append
>
> So ... even with oslo_log there, we still need openstack.common.log?
> Pretty confused and a little frustrated after two days of digging.
>
> Regards,
> Qiming
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Davanum Srinivas :: https://twitter.com/dims
__
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_log/oslo_config initialization
Qiming,
you are reading bits and pieces of my responses."if you checkout the
review" guess i give up!
-- dims
On Wed, Jan 21, 2015 at 11:18 PM, Qiming Teng
wrote:
> On Wed, Jan 21, 2015 at 10:55:37AM -0500, Davanum Srinivas wrote:
>> Qiming,
>>
>> Guessing you were looking at master. if you checkout the review i
>> pointed to, you will see what others on the thread have pointed you
>> to:
>> https://github.com/openstack/oslo.log/blob/master/doc/source/usage.rst
>>
>> We are using register_options and setup. we should be adding
>> register_options in the future as need arises.
>
> In most files listed below, the 'logging' refers to
> nova/openstack/common/log.py instead of oslo_log/log.py. No project can
> throw away openstack/common/log.py at the moment, because it breaks
> things in many ways.
>
>> dims@dims-mac:~/openstack/nova$ find . -name "*.py" -exec grep -H
>> logging {} \; | grep -e "\.setup" -e "\.register_options" -e
>> "\.set_defaults"
>> ./nova/cmd/all.py:logging.setup(CONF, "nova")
>> ./nova/cmd/api.py:logging.setup(CONF, "nova")
>> ./nova/cmd/api_ec2.py:logging.setup(CONF, "nova")
>> ./nova/cmd/api_metadata.py:logging.setup(CONF, "nova")
>> ./nova/cmd/api_os_compute.py:logging.setup(CONF, "nova")
>> ./nova/cmd/cells.py:logging.setup(CONF, 'nova')
>> ./nova/cmd/cert.py:logging.setup(CONF, "nova")
>> ./nova/cmd/compute.py:logging.setup(CONF, 'nova')
>> ./nova/cmd/conductor.py:logging.setup(CONF, "nova")
>> ./nova/cmd/console.py:logging.setup(CONF, "nova")
>> ./nova/cmd/consoleauth.py:logging.setup(CONF, "nova")
>> ./nova/cmd/dhcpbridge.py:logging.setup(CONF, "nova")
>> ./nova/cmd/manage.py:logging.setup(CONF, "nova")
>> ./nova/cmd/network.py:logging.setup(CONF, "nova")
>> ./nova/cmd/novncproxy.py:logging.setup(CONF, "nova")
>> ./nova/cmd/novncproxy.py:logging.setup(CONF, "nova")
>> ./nova/cmd/objectstore.py:logging.setup(config.CONF, "nova")
>> ./nova/cmd/scheduler.py:logging.setup(CONF, "nova")
>> ./nova/cmd/serialproxy.py:logging.setup(CONF, "nova")
>> ./nova/cmd/spicehtml5proxy.py:logging.setup(CONF, "nova")
>> ./nova/cmd/xvpvncproxy.py:logging.setup(config.CONF, "nova")
>> ./nova/openstack/common/report/guru_meditation_report.py:
>> logging.setup(CONF, 'blah')
>> ./nova/test.py:logging.register_options(CONF)
>> ./nova/test.py:logging.setup(CONF, 'nova')
>>
>> If you file a review with what you have, maybe we can help, again, pop
>> onto the #openstack-oslo channel to ask
>
> Okay, will do. Thanks.
>
> Regards,
> Qiming
>
>> -- dims
>>
>> On Wed, Jan 21, 2015 at 10:25 AM, Qiming Teng
>> wrote:
>> > On Wed, Jan 21, 2015 at 08:25:57AM -0500, Davanum Srinivas wrote:
>> >> Qiming,
>> >>
>> >> Nova already uses oslo.config. there's a patch against nova to use
>> >> oslo_log. Doug took the effort to do this so we'd not face issues once
>> >> we release oslo_log, so yes, they have been tested together. Please
>> >> hop onto #openstack-oslo to debug in real time.
>> >>
>> >> [1] https://review.openstack.org/#/c/147635/
>> >>
>> >
>> > Well, just checked nova code, it seems openstack.common.log is still
>> > there. That means there are duplicated code such as the
>> > 'common_cli_opts' which resides in both openstack.common.log and
>> > oslo_log._options.
>> >
>> > I was getting the following error if I'm deleting openstack.common.log
>> > module:
>> >
>> > oslo_config.cfg.NoSuchOptError: no such option: log_config_append
>> >
>> > So ... even with oslo_log there, we still need openstack.common.log?
>> > Pretty confused and a little frustrated after two days of digging.
>> >
>> > Regards,
>> > Qiming
>> >
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Davanum Srinivas :: https://twitter.com/dims
__
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] PGP keysigning party for Juno summit in Atlanta?
+1 to lock down the page May 7th. -- dims On Mon, Apr 28, 2014 at 6:42 PM, Jeremy Stanley wrote: > On 2014-04-26 17:05:41 -0700 (-0700), Clint Byrum wrote: >> Just a friendly reminder to add yourself to this list if you are >> interested in participating in the key signing in Atlanta: >> >> https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit > [...] > > It has a sign-up cutoff of two weeks ago, so I assume that was > merely a placeholder. Which begs the question how late is too late > for participants to be able to comfortably print out their copies > (assuming we do http://keysigning.org/methods/sassaman-efficient > this time)? Should lock down the page Wednesday May 7th? Sooner? > > Keep in mind that this week (April 27 through May 3) is supposed to > be a vacation week for the project, so people may not be around to > add themselves until Monday May 5th ;) > -- > Jeremy Stanley > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] PGP keysigning party for Juno summit in Atlanta?
How about 10:30 AM Break on Wednesday at the Developers Lounge (Do we have one this time?) -- dims On Tue, Apr 29, 2014 at 10:32 AM, Thomas Goirand wrote: > On 04/29/2014 06:42 AM, Jeremy Stanley wrote: >> On 2014-04-26 17:05:41 -0700 (-0700), Clint Byrum wrote: >>> Just a friendly reminder to add yourself to this list if you are >>> interested in participating in the key signing in Atlanta: >>> >>> https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit >> [...] >> >> It has a sign-up cutoff of two weeks ago, so I assume that was >> merely a placeholder. Which begs the question how late is too late >> for participants to be able to comfortably print out their copies >> (assuming we do http://keysigning.org/methods/sassaman-efficient >> this time)? Should lock down the page Wednesday May 7th? Sooner? >> >> Keep in mind that this week (April 27 through May 3) is supposed to >> be a vacation week for the project, so people may not be around to >> add themselves until Monday May 5th ;) > > Is there a date a place already schedule for the key signing party? > > Thomas > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] PGP keysigning party for Juno summit in Atlanta?
Awesome! thanks @fungi -- dims On Wed, Apr 30, 2014 at 6:47 PM, Jeremy Stanley wrote: > On 2014-04-29 18:01:44 + (+), Jeremy Stanley wrote: > [...] >> I'll check with the team handling venue logistics right now and >> update this thread with options. I'm also inquiring about the >> availability of a projector if we get one of the non-design-session >> breakout rooms, and I can bring a digital micro/macroscope which >> ought to do a fair job of showing everyone's photo IDs through it if >> so (which would enable us to use The 'Sassman-Projected' Method and >> significantly increase our throughput via parallelization). > > I was able to confirm a dedicated location (room 405, just one floor > up from the design summit sessions) Wednesday 10:30-11:00am with a > projector and seating for 50. We're getting close to that many on > the sign-up sheet already... chances are we'll be able to put each > ID up on the projector for 15-20 seconds, taking buffer time into > account at the beginning for walking to the room and reading the > master list checksum aloud. I've asked the organizers to list this > as "OpenStack Web of Trust: Key Signing" and have updated > https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit > accordingly. > -- > Jeremy Stanley > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] nominating Victor Stinner for the Oslo core reviewers team
Welcome Victor! On Tue, May 6, 2014 at 8:38 AM, Doug Hellmann wrote: > After a bit more than the usual waiting period, I have added Victor > Stinner to the oslo-core team today. > > Welcome to the team, Victor! > > On Mon, Apr 21, 2014 at 12:39 PM, Doug Hellmann > wrote: >> I propose that we add Victor Stinner (haypo on freenode) to the Oslo >> core reviewers team. >> >> Victor is a Python core contributor, and works on the development team >> at eNovance. He created trollius, a port of Python 3's tulip/asyncio >> module to Python 2, at least in part to enable a driver for >> oslo.messaging. He has been quite active with Python 3 porting work in >> Oslo and some other projects, and organized a sprint to work on the >> port at PyCon last week. The patches he has written for the python 3 >> work have all covered backwards-compatibility so that the code >> continues to work as before under python 2. >> >> Given his background, skills, and interest, I think he would be a good >> addition to the team. >> >> Doug > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Multiple instances of Keystone
If you are using devstack, it's simple to enable Keystone+Apache Httpd [1] APACHE_ENABLED_SERVICES+=key -- dims [1] https://github.com/openstack-dev/devstack/blob/master/README.md On Wed, May 14, 2014 at 11:46 AM, Vishvananda Ishaya wrote: > Keystone has specifically avoided including multiple process patches because > they want to encourage apache + mod_wsgi as the standard way of scaling the > keystone api. > > Vish > > On May 13, 2014, at 9:34 PM, Aniruddha Singh Gautam > wrote: > > Hi, > > Hope you are doing well… > > I was working on trying to apply the patch for running multiple instance of > Keystone. Somehow it does not work with following errors, I wish to still > debug it further, but thought that I will check with you if you can provide > some quick help. I was following > http://blog.gridcentric.com/?Tag=Scalability. I did the changes on Ice House > GA. > > Error > Traceback (most recent call last): > File > "/usr/lib/python2.7/dist-packages/keystone/openstack/common/threadgroup.py", > line 119, in wait > x.wait() > File > "/usr/lib/python2.7/dist-packages/keystone/openstack/common/threadgroup.py", > line 47, in wait > return self.thread.wait() > File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 168, > in wait > return self._exit_event.wait() > File "/usr/lib/python2.7/dist-packages/eventlet/event.py", line 116, in > wait > return hubs.get_hub().switch() > File "/usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 187, in > switch > return self.greenlet.switch() > File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 194, > in main > result = function(*args, **kwargs) > File > "/usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py", > line 449, in run_service > service.start() > AttributeError: 'tuple' object has no attribute 'start' > (keystone): 2014-05-13 08:17:37,073 CRITICAL AttributeError: 'tuple' object > has no attribute 'stop' > Traceback (most recent call last): > File "/usr/bin/keystone-all", line 162, in > serve(*servers) > File "/usr/bin/keystone-all", line 111, in serve > launcher.wait() > File > "/usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py", > line 352, in wait > self._respawn_children() > File > "/usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py", > line 342, in _respawn_children > self._start_child(wrap) > File > "/usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py", > line 282, in _start_child > status, signo = self._child_wait_for_exit_or_signal(launcher) > File > "/usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py", > line 240, in _child_wait_for_exit_or_signal > launcher.stop() > File > "/usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py", > line 95, in stop > self.services.stop() > File > "/usr/lib/python2.7/dist-packages/keystone/openstack/common/service.py", > line 419, in stop > service.stop() > AttributeError: 'tuple' object has no attribute 'stop' > > In logs I can find the new child processes, somehow probably they are > stopped and then it spawns another child processes. > > I also noticed that support for running multiple neutron servers in ICE > House GA. Any specific reason of not having same thing for Keystone (My > knowledge of Openstack is limited, so please bear with my dumb questions) > > > Best regards, > Aniruddha > > > > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received > this message in error, please notify the originator immediately. If you are > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of this > message. Aricent accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including damage from > virus." > ___ > 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 > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][nova] how to best deal with default periodic task spacing behavior
@Matt, Agree, My vote would be to change existing behavior. -- dims On Tue, May 20, 2014 at 10:15 AM, Matt Riedemann wrote: > Between patch set 1 and patch set 3 here [1] we have different solutions to > the same issue, which is if you don't specify a spacing value for periodic > tasks then they run whenever the periodic task processor runs, which is > non-deterministic and can be staggered if some tasks don't complete in a > reasonable amount of time. > > I'm bringing this to the mailing list to see if there are more opinions out > there, especially from operators, since patch set 1 changes the default > behavior to have the spacing value be the DEFAULT_INTERVAL (hard-coded 60 > seconds) versus patch set 3 which makes that behavior configurable so the > admin can set global default spacing for tasks, but defaults to the current > behavior of running every time if not specified. > > I don't like a new config option, but I'm also not crazy about changing > existing behavior without consensus. > > [1] https://review.openstack.org/#/c/93767/ > > -- > > Thanks, > > Matt Riedemann > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][vmware] Current state of the spawn refactor
Hi Michael, * Phase 1 has one review left - https://review.openstack.org/#/c/92691/ * I'll update the phase 2 patch shortly - https://review.openstack.org/#/c/87002/ * Once the 2 reviews above get approved, we will resurrect the oslo.vmware BP/review - https://review.openstack.org/#/c/70175/ There is a team etherpad that has a game plan we try to keep up-to-date - https://etherpad.openstack.org/p/vmware-subteam-juno. Based on discussions during the summit, We are hoping to get the 3 items above into juno-1. So we can work on the features mentioned in the etherpad. Tracy,GaryK,Others, please chime in. thanks, dims On Tue, May 27, 2014 at 5:31 PM, Michael Still wrote: > Hi. > > I've been looking at the current state of the vmware driver spawn > refactor work, and as best as I can tell phase one is now complete. > However, I can only find one phase two patch, and it is based on an > outdated commit. That patch is: > > https://review.openstack.org/#/c/87002/ > > There also aren't any phase three patches that I can see. What is the > current state of this work? Is it still targeting juno-1? > > Thanks, > Michael > > -- > Rackspace Australia > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Oslo logging eats system level tracebacks by default
+1 from me. On Wed, May 28, 2014 at 11:49 AM, Jay Pipes wrote: > On 05/28/2014 11:39 AM, Doug Hellmann wrote: >> >> On Wed, May 28, 2014 at 10:38 AM, Sean Dague wrote: >>> >>> When attempting to build a new tool for Tempest, I found that my python >>> syntax errors were being completely eaten. After 2 days of debugging I >>> found that oslo log.py does the following *very unexpected* thing. >>> >>> - replaces the sys.excepthook with it's own function >>> - eats the execption traceback unless debug or verbose are set to True >>> - sets debug and verbose to False by default >>> - prints out a completely useless summary log message at Critical >>> ([CRITICAL] [-] 'id' was my favorite of these) >>> >>> This is basically for an exit level event. Something so breaking that >>> your program just crashed. >>> >>> Note this has nothing to do with preventing stack traces that are >>> currently littering up the logs that happen at many logging levels, it's >>> only about removing the stack trace of a CRITICAL level event that's >>> going to very possibly result in a crashed daemon with no information as >>> to why. >>> >>> So the process of including oslo log makes the code immediately >>> undebuggable unless you change your config file to not the default. >>> >>> Whether or not there was justification for this before, one of the >>> things we heard loud and clear from the operator's meetup was: >>> >>> - Most operators are running at DEBUG level for all their OpenStack >>> services because you can't actually do problem determination in >>> OpenStack for anything < that. >>> - Operators reacted negatively to the idea of removing stack traces >>> from logs, as that's typically the only way to figure out what's going >>> on. It took a while of back and forth to explain that our initiative to >>> do that wasn't about removing them per say, but having the code >>> correctly recover. >>> >>> So the current oslo logging behavior seems inconsistent (we spew >>> exceptions at INFO and WARN levels, and hide all the important stuff >>> with a legitimately uncaught system level crash), undebuggable, and >>> completely against the prevailing wishes of the operator community. >>> >>> I'd like to change that here - https://review.openstack.org/#/c/95860/ >>> >>> -Sean >> >> >> I agree, we should dump as much detail as we can when we encounter an >> unhandled exception that causes an app to die. > > > +1 > > -jay > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][glance] Consistency around proposed server instance tagging API
+1 to 404 for a DELETE if the tag does not exist.
There's a good discussion in this paragraph from "RESTful Web APIs"
book -
http://books.google.com/books?id=wWnGQBAJ&lpg=PA36&ots=Ff9jCI293b&dq=restful%20http%20delete%20404%20sam%20ruby&pg=PA36#v=onepage&q=restful%20http%20delete%20404%20sam%20ruby&f=false
-- dims
On Wed, Jun 4, 2014 at 8:21 PM, Christopher Yeoh wrote:
>
> On Thu, Jun 5, 2014 at 4:14 AM, Jay Pipes wrote:
>>
>> Hi Stackers,
>>
>> I'm looking to get consensus on a proposed API for server instance tagging
>> in Nova:
>>
>> https://review.openstack.org/#/c/91444/
>>
>> In the proposal, the REST API for the proposed server instance tagging
>> looks like so:
>>
>> Remove a tag on a server:
>>
>> DELETE /v2/{project_id}/servers/{server_id}/tags/{tag}
>>
>> It is this last API call that has drawn the attention of John Garbutt
>> (cc'd). In Glance v2 API, if you attempt to delete a tag that does not
>> exist, then a 404 Not Found is returned. In my proposal, if you attempt to
>> delete a tag that does not exist for the server, a 204 No Content is
>> returned.
>>
>
> I think attempting to delete a tag that doesn't exist should return a 404.
> The user can always ignore the error if they know there's a
> chance that the tag they want to get rid of doesn't exist. But for those
> that believe it should exist its an error is more useful to them as
> it may be an indicator that something is wrong with their logic.
>
> Chris
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Davanum Srinivas :: http://davanum.wordpress.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][messaging] Further improvements and refactoring
Dina, Alexey, Do you mind filing some spec(s) please? http://markmail.org/message/yqhndsr3zrqcfwq4 http://markmail.org/message/kpk35uikcnodq3jb thanks, dims On Tue, Jun 10, 2014 at 7:03 AM, Dina Belova wrote: > Hello, stackers! > > > Oslo.messaging is future of how different OpenStack components communicate > with each other, and really I’d love to start discussion about how we can > make this library even better then it’s now and how can we refactor it make > more production-ready. > > > As we all remember, oslo.messaging was initially inspired to be created as a > logical continuation of nova.rpc - as a separated library, with lots of > transports supported, etc. That’s why oslo.messaging inherited not only > advantages of now did the nova.rpc work (and it were lots of them), but also > some architectural decisions that currently sometimes lead to the > performance issues (we met some of them while Ceilometer performance testing > [1] during the Icehouse). > > > For instance, simple testing messaging server (with connection pool and > eventlet) can process 700 messages per second. The same functionality > implemented using plain kombu (without connection pool and eventlet) driver > is processing ten times more - 7000-8000 messages per second. > > > So we have the following suggestions about how we may make this process > better and quicker (and really I’d love to collect your feedback, folks): > > > 1) Currently we have main loop running in the Executor class, and I guess > it’ll be much better to move it to the Server class, as it’ll make > relationship between the classes easier and will leave Executor only one > task - process the message and that’s it (in blocking or eventlet mode). > Moreover, this will make further refactoring much easier. > > 2) Some of the drivers implementations (such as impl_rabbit and impl_qpid, > for instance) are full of useless separated classes that in reality might be > included to other ones. There are already some changes making the whole > structure easier [2], and after the 1st issue will be solved Dispatcher and > Listener also will be able to be refactored. > > 3) If we’ll separate RPC functionality and messaging functionality it’ll > make code base clean and easily reused. > > 4) Connection pool can be refactored to implement more efficient connection > reusage. > > > Folks, are you ok with such a plan? Alexey Kornienko already started some of > this work [2], but really we want to be sure that we chose the correct > vector of development here. > > > Thanks! > > > [1] > https://docs.google.com/document/d/1ARpKiYW2WN94JloG0prNcLjMeom-ySVhe8fvjXG_uRU/edit?usp=sharing > > [2] > https://review.openstack.org/#/q/status:open+owner:akornienko+project:openstack/oslo.messaging,n,z > > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Gate still backed up - need assistance with nova-network logging enhancements
Hey Matt, There is a connection pool in https://github.com/boto/boto/blob/develop/boto/connection.py which could be causing issues... -- dims On Thu, Jun 12, 2014 at 10:50 AM, Matt Riedemann wrote: > > > On 6/10/2014 5:36 AM, Michael Still wrote: >> >> https://review.openstack.org/99002 adds more logging to >> nova/network/manager.py, but I think you're not going to love the >> debug log level. Was this the sort of thing you were looking for >> though? >> >> Michael >> >> On Mon, Jun 9, 2014 at 11:45 PM, Sean Dague wrote: >>> >>> Based on some back of envelope math the gate is basically processing 2 >>> changes an hour, failing one of them. So if you want to know how long >>> the gate is, take the length / 2 in hours. >>> >>> Right now we're doing a lot of revert roulette, trying to revert things >>> that we think landed about the time things went bad. I call this >>> roulette because in many cases the actual issue isn't well understood. A >>> key reason for this is: >>> >>> *nova network is a blackhole* >>> >>> There is no work unit logging in nova-network, and no attempted >>> verification that the commands it ran did a thing. Most of these >>> failures that we don't have good understanding of are the network not >>> working under nova-network. >>> >>> So we could *really* use a volunteer or two to prioritize getting that >>> into nova-network. Without it we might manage to turn down the failure >>> rate by reverting things (or we might not) but we won't really know why, >>> and we'll likely be here again soon. >>> >>> -Sean >>> >>> -- >>> Sean Dague >>> http://dague.net >>> >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> > > I mentioned this in the nova meeting today also but the assocated bug for > the nova-network ssh timeout issue is bug 1298472 [1]. > > My latest theory on that one is if there could be a race/network leak in the > ec2 third party tests in Tempest or something in the ec2 API in nova, > because I saw this [2] showing up in the n-net logs. My thinking is the > tests or the API are not tearing down cleanly and eventually network > resources are leaked and we start hitting those timeouts. Just a theory at > this point, but the ec2 3rd party tests do run concurrently with the > scenario tests so things could be colliding at that point, but I haven't had > time to dig into it, plus I have very little experience in those tests or > the ec2 API in nova. > > [1] https://bugs.launchpad.net/tempest/+bug/1298472 > [2] http://goo.gl/6f1dfw > > -- > > Thanks, > > Matt Riedemann > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [vmware] Proposed new Vim/PBM api
cc'ing Gary On Fri, Jun 13, 2014 at 11:49 AM, Matthew Booth wrote: > I've proposed a new Vim/PBM api in this blueprint for oslo.vmware: > https://review.openstack.org/#/c/99952/ > > This is just the base change. However, it is a building block for adding > a bunch of interesting new features, including: > > * Robust caching > * Better RetrievePropertiesEx > * WaitForUpdatesEx > * Non-polling task waiting > > It also gives us explicit session transactions, which are a requirement > for locking should that ever come to pass. > > Please read and discuss. There are a couple of points in there on which > I'm actively soliciting input. > > Matt > -- > Matthew Booth > Red Hat Engineering, Virtualisation Team > > Phone: +442070094448 (UK) > GPG ID: D33C3490 > GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] VMware ESX Driver Deprecation
+1 to Option #2. -- dims On Sun, Jun 15, 2014 at 11:15 AM, Gary Kotton wrote: > Hi, > In the Icehouse cycle it was decided to deprecate the VMware ESX driver. The > motivation for the decision was: > > The driver is not validated by Minesweeper > It is not clear if there are actually any users of the driver > > Prior to jumping into the proposal we should take into account that the > current ESX driver does not work with the following branches: > > Master (Juno) > Icehouse > Havana > > The above are due to VC features that were added over the course of these > cycles. > > On the VC side the ESX can be added to a cluster and the running VM’s will > continue to run. The problem is how that are tracked and maintained in the > Nova DB. > > Option 1: Moving the ESX(s) into a nova managed cluster. This would require > the nova DB entry for the instance running on the ESX to be updated to be > running on the VC host. If the VC host restarts at point during the above > then all of the running instances may be deleted (this is due to the fact > that _destroy_evacuated_instances is invoked when a nova compute is started > https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L673). > This would be disastrous for a running deployment. > > If we do decide to go for the above option we can perform a cold migration > of the instances from the ESX hosts to the VC hosts. The fact that the same > instance will be running on the ESX would require us to have a ‘noop’ for > the migration. This can be done by configuration variables but that will be > messy. This option would require code changes. > > Option 2: Provide the administrator with tools that will enable a migration > of the running VM’s. > > A script that will import OpenStack VM’s into the database – the script will > detect VM’s running on a VC and import them to the database. > A scrip that will delete VM’s running on a specific host > > The admin will use these as follows: > > Invoke the deletion script for the ESX > Add the ESX to a VC > Invoke the script for importing the OpenStack VM’s into the database > Start the nova compute with the VC driver > Terminate all Nova computes with the ESX driver > > This option requires the addition of the scripts. The advantage is that it > does not touch any of the running code and is done out of band. A variant of > option 2 would be to have a script that updates the host for the ESX VM’s to > the VC host. > > Due to the fact that the code is not being run at the moment I am in favor > of the external scripts as it will be less disruptive and not be on a > critical path. Any thoughts or comments? > > Thanks > Gary > > _______ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] All Clear on the western front (i.e. gate)
w00t! thanks for the hard work everyone. -- dims On Wed, Jun 18, 2014 at 7:17 AM, Sean Dague wrote: > I realized that folks may have been waiting for an 'all clear' on the > gate situation. It was a tiring couple of weeks, so took a little while > to get there. > > Due to a huge amount of effort, but a bunch of different people, a ton > of bugs were squashed to get the gate back to a high pass rate - > https://etherpad.openstack.org/p/gatetriage-june2014 > > Then jeblair came back from vacation and quickly sorted out a nodepool > bug that was starving our capacity, so now we aren't leaking deleted > nodes the same way. > > With both those, our capacity for changes goes way up. Because we have > more workers available at any time, and less round tripping on race > bugs. We also dropped the Nova v3 tests, which shaved 8 minutes (on > average) off of Tempest runs. Again, increasing throughput by getting > nodes back into the pool faster. > > The net of all these changes is that yesterday we merged 117 patches - > https://github.com/openstack/openstack/graphs/commit-activity (not a > record, that's 147 in one day, but definitely a top merge day). > > So if you were holding off on reviews / code changes because of the > state of things, you can stop now. And given the system is pretty > healthy, now is actually a pretty good time to put and keep it under > load to help evaluate where we stand. > > Thanks all, > > -Sean > > -- > Sean Dague > http://dague.net > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [GSoC 2014] Proposal Template
Thanks Masaru, I'd encourage other applicants to use add their own details and get their potential mentors to review their page. thanks, dims On Thu, Mar 6, 2014 at 5:58 AM, Masaru Nomura wrote: > Dear mentors and students, > > Hi, > > after a short talk with dims, I created an application template wiki > page[1]. Obviously, this is not a completed version, and I'd like your > opinions to improve it. :) > > I have : > 1) simply added information such as : > >・Personal Details (e.g. Name, Email, University and so on) > >・Project Proposal (e.g. Project, idea, implementation issues, and time > scheduling) > >・Background (e.g. Open source, academic or intern experience, or language > experience) > > > 2) linked this page on GSoC 2014 wiki page[2] > 3) created an example of my proposal page [3] (not completed yet!) > 4) linked the example to an Oslo project page[4] > > > Thank you, > Masaru > > [1] https://wiki.openstack.org/wiki/GSoC2014/StudentApplicationTemplate > [2] https://wiki.openstack.org/wiki/GSoC2014#Communication > [3] https://wiki.openstack.org/wiki/GSoC2014/Student/Masaru > [4] > https://wiki.openstack.org/wiki/GSoC2014/Incubator/SharedLib#Students.27_proposals > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [re]: [GSoC 2014] Proposal Template
Sai, There may be more than one person on a topic, so it would make sense to have additional questions per person. Yes, link to project idea is definitely needed. -- dims On Thu, Mar 6, 2014 at 11:41 AM, saikrishna sripada wrote: > Hi Masaru, > > I tried creating the project template following your suggestions.Thats > really helpful. Only one suggestion: > > Under the project description, We can give the link to actual project idea. > The remaining details like these can be removed here since this can be > redundant. > > What is the goal? > How will you achieve your goal? > What would be your milestone? > At which time will you complete a sub-task of your project? > > These details we will be filling any way in the Project template link just > which will be just below in the page. Please confirm. > > Thanks, > --sai krishna. > > Dear mentors and students, > > Hi, > > after a short talk with dims, I created an application template wiki > page[1]. Obviously, this is not a completed version, and I'd like your > opinions to improve it. :) > > I have : > 1) simply added information such as : > >・Personal Details (e.g. Name, Email, University and so on) > >・Project Proposal (e.g. Project, idea, implementation issues, and time > scheduling) > >・Background (e.g. Open source, academic or intern experience, or > language experience) > > 2) linked this page on GSoC 2014 wiki page[2] > 3) created an example of my proposal page [3] (not completed yet!) > 4) linked the example to an Oslo project page[4] > > > Thank you, > Masaru > > [1] > https://wiki.openstack.org/wiki/GSoC2014/StudentApplicationTemplate<https://wiki.openstack.org/wiki/GSoC2014/StudentApplicationTemplate#Link_your_page> > [2] https://wiki.openstack.org/wiki/GSoC2014#Communication > [3] https://wiki.openstack.org/wiki/GSoC2014/Student/Masaru > [4] > https://wiki.openstack.org/wiki/GSoC2014/Incubator/SharedLib#Students.27_proposals > > > > _______ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] OpenStack/GSoC
Hi, Mentors: * Please click on "My Dashboard" then "Connect with organizations" and request a connection as a mentor (on the GSoC web site - http://www.google-melange.com/) Students: * Please see the Application template you will need to fill in on the GSoC site. http://www.google-melange.com/gsoc/org2/google/gsoc2014/openstack * Please click on "My Dashboard" then "Connect with organizations" and request a connection Both Mentors and Students: Let's meet on #openstack-gsoc channel on Thursday 9:00 AM EDT / 13:00 UTC for about 30 mins to meet and greet since all application deadline is next week. If this time is not convenient, please send me a note and i'll arrange for another time say on friday as well. http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140313T09&p1=43&am=30 We need to get an idea of how many slots we need to apply for based on really strong applications with properly fleshed out project ideas and mentor support. Hoping the meeting on IRC will nudge the students and mentors work towards that goal. Thanks, dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] An analysis of code review in Nova
gt; https://blueprints.launchpad.net/nova/+spec/vmware-spawn-refactor > > That spurred some discussion around this same topic and I think highlights > one of the major issues, which is code quality and the design of the driver. > > For example, the driver's spawn method is huge and there are a lot of nested > methods within it. There are a lot of vmware patches and a lot of > blueprints, and a lot of them touch spawn. When I'm reviewing them, I'm > looking for new conditions and checking to see if those are unit tested > (positive/error cases) and a lot of the time I find it very difficult to > tell if they are or not. I think a lot of that has to do with how the > vmware tests are scaffolded with fakes to simulate a vcenter backend, but it > makes it very difficult if you're not extremely familiar with that code to > know if something is covered or not. > > And I've actually asked in bp reviews before, 'you have this new/changed > condition, where is it tested' and the response is more or less 'we plan on > refactoring this later and will add unit tests then' or 'it's hard to test > this path without a lot of changes to how the tests are working'. That's > unacceptable to me, and I generally give up on the review after that. > > So to move this all forward, I think that bp above should be top priority > for the vmware team in Juno to keep bp patches moving at the pace they do, > because the features and refactoring just keeps coming and at least for me > it's very hard to burn out on looking at those reviews. > > -- > > Thanks, > > Matt Riedemann > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack/GSoC
Andronidis, not sure, we can ask others on the irc meeting tomorrow. Please answer the questions on the template, and if you see the last one is about links to your proposal on the openstack wiki. On Wed, Mar 12, 2014 at 8:40 PM, Andronidis Anastasios wrote: > Hello everyone, > > I am a student and I can not see "Connections" anywhere. I also tried to > re-loging, but still nothing. Is it sure that this "Connections" link exists > in students too? > > I also have a second question, concerning the template on google-melange. Do > we have to just answer the questions on the template? Or shall we also paste > our proposal that we wrote on the openstack wiki? > > Kindly, > Anastasis > > On 12 Μαρ 2014, at 10:46 μ.μ., Sriram Subramanian > wrote: > >> Victoria, >> >> When you click "My Dashboard" on the left hand side, you will see >> Connections, Proposals etc on your right, in the dashboard. Right below >> "Connections", there are two links in smaller font, one which is the link to >> Connect (circled in blue in the attached snapshot). >> If you tried right after creating your profile, try logging out and in. When >> I created the profile, I remember having some issues around accessing >> profile (not the dashboard, but entire profile). >> >> thanks >> -Sriram >> >> >> On Wed, Mar 12, 2014 at 1:32 PM, Victoria Martínez de la Cruz >> wrote: >> Hi, >> >> Thanks for working on the template, it sure ease things for students. >> >> I can't find the "Connect with organizations" link, does anyone have the >> same problem? >> >> I confirm my assistance to tomorrow's meeting, thanks for organizing it! +1 >> >> Cheers, >> >> Victoria >> >> >> >> 2014-03-11 14:29 GMT-03:00 Davanum Srinivas : >> >> Hi, >> >> Mentors: >> * Please click on "My Dashboard" then "Connect with organizations" and >> request a connection as a mentor (on the GSoC web site - >> http://www.google-melange.com/) >> >> Students: >> * Please see the Application template you will need to fill in on the GSoC >> site. >> http://www.google-melange.com/gsoc/org2/google/gsoc2014/openstack >> * Please click on "My Dashboard" then "Connect with organizations" and >> request a connection >> >> Both Mentors and Students: >> Let's meet on #openstack-gsoc channel on Thursday 9:00 AM EDT / 13:00 >> UTC for about 30 mins to meet and greet since all application deadline >> is next week. If this time is not convenient, please send me a note >> and i'll arrange for another time say on friday as well. >> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140313T09&p1=43&am=30 >> >> We need to get an idea of how many slots we need to apply for based on >> really strong applications with properly fleshed out project ideas and >> mentor support. Hoping the meeting on IRC will nudge the students and >> mentors work towards that goal. >> >> Thanks, >> dims >> >> ___ >> 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 >> >> >> >> >> -- >> Thanks, >> -Sriram >> ___ >> 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 -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack/GSoC
FYI, here's the log for the OpenStack GSoC meeting we just wrapped up http://paste.openstack.org/show/73389/ On Tue, Mar 11, 2014 at 1:29 PM, Davanum Srinivas wrote: > Hi, > > Mentors: > * Please click on "My Dashboard" then "Connect with organizations" and > request a connection as a mentor (on the GSoC web site - > http://www.google-melange.com/) > > Students: > * Please see the Application template you will need to fill in on the GSoC > site. > http://www.google-melange.com/gsoc/org2/google/gsoc2014/openstack > * Please click on "My Dashboard" then "Connect with organizations" and > request a connection > > Both Mentors and Students: > Let's meet on #openstack-gsoc channel on Thursday 9:00 AM EDT / 13:00 > UTC for about 30 mins to meet and greet since all application deadline > is next week. If this time is not convenient, please send me a note > and i'll arrange for another time say on friday as well. > http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140313T09&p1=43&am=30 > > We need to get an idea of how many slots we need to apply for based on > really strong applications with properly fleshed out project ideas and > mentor support. Hoping the meeting on IRC will nudge the students and > mentors work towards that goal. > > Thanks, > dims -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum][Oslo] Next Release of oslo.messaging?
Adrian, We are too close to icehouse release candidates to bump up global requirements with new rev of oslo.messaging. So even if we all agree and cut a new rev of oslo.messaging it's too late for icehouse as release candidates are rolling next week. I'd definitely support a way to get python33 support via trollius or thread-exec that Joshua pointed out very soon. It may be a good idea to keep solum's py33 non-voting till we nail down all other other dependencies, so +1 for that as well. -- dims On Mon, Mar 17, 2014 at 7:29 PM, Adrian Otto wrote: > Doug Hellmann and Victror Stinner (+ oslo cores), > > Solum currently depends on a py33 gate. We want to use oslo.messaging, but > are worried that in the current state, we will be stuck without py33 support. > We hope that by adding the Trollius code[1], and getting a new release > number, that we can add the oslo.messaging library to our requirements and > proceed with our async messaging plan. > > I am seeking guidance from you on when the above might happen. If it's a > short time, we may just wait for it. If it's a long time, we may need to > relax our py33 gate to non-voting in order to prevent breakage of our > Stackforge CI while we work with the oslo.messaging code. We are also > considering doing an ugly workaround of creating a bunch of worker processes > on the same messaging topic until we can clear this concern. > > Thoughts? > > Thanks, > > Adrian > > [1] https://review.openstack.org/70948 > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Updating libvirt in gate jobs
Hi Team,
We have 2 choices
1) Upgrade to libvirt 0.9.8+ (See [1] for details)
2) Enable UCA and upgrade to libvirt 1.2.2+ (see [2] for details)
For #1, we received a patched deb from @SergeHallyn/@JamesPage and ran
tests on it in review https://review.openstack.org/#/c/79816/
For #2, @SergeHallyn/@JamesPage have updated UCA
("precise-proposed/icehouse") repo and we ran tests on it in review
https://review.openstack.org/#/c/74889/
For IceHouse, my recommendation is to request Ubuntu folks to push the
patched 0.9.8+ version we validated to public repos, then we can can
install/run gate jobs with that version. This is probably the smallest
risk of the 2 choices.
As soon as Juno begins, we can switch 1.2.2+ on UCA and request Ubuntu
folks to push the verified version where we can use it.
WDYT?
thanks,
dims
[1] https://bugs.launchpad.net/nova/+bug/1254872
[2] https://bugs.launchpad.net/nova/+bug/1228977
--
Davanum Srinivas :: http://davanum.wordpress.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] OpenStack/GSoC
Dear Students, Student application deadline is on Friday, March 21 [1] Once you finish the application process on the Google GSoC site. Please reply back to this thread to confirm that all the materials are ready to review. thanks, dims [1] http://www.google-melange.com/gsoc/events/google/gsoc2014 -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack/GSoC
Team, Here's what i see in the system so far. Mentors: ybudupi blint boris_42 coroner cppcabrera sriramhere arnaudleg greghaynes hughsaunders julim ddutta (Organization Administrator) dims (Organization Administrator) Projects: Cross-services Scheduler project. Artem Shepelev Artem Shepelev Proposal for Implementing an application-level FWaaS driver (Zorp) Dániel Csubák Openstack-OSLO :Add a New Backend to Oslo.Cache sai krishna How to detect network anomalies from telemetry data within Openstack mst89 OpenStack/Marconi: Py3k support Nataliia Develop a benchmarking suite and new storage backends to OpenStack Marconi Prashanth Raghu Developing Benchmarks for Virtual Machines of OpenStack with Rally Tzanetos Balitsaris Mentors, if you don't see your id, please send me a connection request in the google gsoc site. Students, if you don't see your proposal above, please hop onto #openstack-gsoc and #gsoc and get help making sure we can see it. thanks, dims On Thu, Mar 20, 2014 at 8:41 AM, Artem Shepelev wrote: > On 03/18/2014 07:19 PM, Davanum Srinivas wrote: > > Dear Students, > > Student application deadline is on Friday, March 21 [1] > > Once you finish the application process on the Google GSoC site. > Please reply back to this thread to confirm that all the materials are > ready to review. > > thanks, > dims > > [1] http://www.google-melange.com/gsoc/events/google/gsoc2014 > > Hello! > > I have just sumbitted my proposal. > If there are any questions or offers I'm ready to listen them and do what I > can. > > P.S.: For other students and mentors: there is no possibility to edit > proposals after the deadline (March 21, 19.00 UTC) > > -- > Best regards, > Artem Shepelev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack/GSoC
FYI, Latest list of projects: Implement a re-usable shared library for VMware(oslo.vmware) Masaru Nomura A pre-caching system for OpenStack Anastasis Andronidis Proposal for Implementing an application-level FWaaS driver (Zorp) Dániel Csubák Openstack-OSLO :Add a New Backend to Oslo.Cache sai krishna Implement a Fuzz testing framework that can be run on Tempest Manishanker Talusani How to detect network anomalies from telemetry data within Openstack mst89 Cross-services Scheduler project Artem Shepelev OpenStack/Marconi: Py3k support Nataliia Develop a benchmarking suite and new storage backends to OpenStack Marconi Prashanth Raghu Adding Redis as a Storage Backend to OpenStack Marconi Chenchong Qin Developing Benchmarks for Virtual Machines of OpenStack with Rally Tzanetos Balitsaris Add a new storage backend to the OpenStack Message Queuing Service Victoria Martínez de la Cruz Thanks, dims On Thu, Mar 20, 2014 at 9:05 AM, Davanum Srinivas wrote: > Team, > > Here's what i see in the system so far. > > Mentors: > ybudupi > blint > boris_42 > coroner > cppcabrera > sriramhere > arnaudleg > greghaynes > hughsaunders > julim > ddutta (Organization Administrator) > dims (Organization Administrator) > > Projects: > Cross-services Scheduler project. Artem Shepelev Artem Shepelev > Proposal for Implementing an application-level FWaaS driver (Zorp) Dániel > Csubák > Openstack-OSLO :Add a New Backend to Oslo.Cache sai krishna > How to detect network anomalies from telemetry data within Openstack mst89 > OpenStack/Marconi: Py3k support Nataliia > Develop a benchmarking suite and new storage backends to OpenStack > Marconi Prashanth Raghu > Developing Benchmarks for Virtual Machines of OpenStack with Rally > Tzanetos Balitsaris > > Mentors, if you don't see your id, please send me a connection request > in the google gsoc site. > Students, if you don't see your proposal above, please hop onto > #openstack-gsoc and #gsoc and get help making sure we can see it. > > thanks, > dims > > On Thu, Mar 20, 2014 at 8:41 AM, Artem Shepelev > wrote: >> On 03/18/2014 07:19 PM, Davanum Srinivas wrote: >> >> Dear Students, >> >> Student application deadline is on Friday, March 21 [1] >> >> Once you finish the application process on the Google GSoC site. >> Please reply back to this thread to confirm that all the materials are >> ready to review. >> >> thanks, >> dims >> >> [1] http://www.google-melange.com/gsoc/events/google/gsoc2014 >> >> Hello! >> >> I have just sumbitted my proposal. >> If there are any questions or offers I'm ready to listen them and do what I >> can. >> >> P.S.: For other students and mentors: there is no possibility to edit >> proposals after the deadline (March 21, 19.00 UTC) >> >> -- >> Best regards, >> Artem Shepelev >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Davanum Srinivas :: http://davanum.wordpress.com -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] OpenStack/GSoC 2014 - Reviewing Applications
Dear Students, We received the following proposals: AMES-Cloud (Nagashree Bhat) A pre-caching system for OpenStack (Anastasis Andronidis) Proposal for Implementing an application-level FWaaS driver ((Zorp) Dániel Csubák) Cassandra and Redis storage backend for Openstack marconi (Jeremy Henriques) Openstack-OSLO :Add a New Backend to Oslo.Cache (sai krishna) Implement a Fuzz testing framework that can be run on Tempest (Manishanker Talusani) How to detect network anomalies from telemetry data within Openstack (mst89) Implement a re-usable shared library for VMware(oslo.vmware) (Masaru Nomura) Cross-services Scheduler project (Artem Shepelev) OpenStack/Marconi: Py3k support (Nataliia) Improve benchmarking context mechanism in Rally (Kumar Rishabh) Develop a benchmarking suite and new storage backends to OpenStack Marconi (Prashanth Raghu) Adding Redis as a Storage Backend to OpenStack Marconi (Chenchong Qin) Auto Benchmarking System for OpenStack (RobberPhex) Developing Benchmarks for Virtual Machines of OpenStack with Rally (Tzanetos Balitsaris) Add a new storage backend to the OpenStack Message Queuing Service (Victoria Martínez de la Cruz) Dear Mentors (ddutta/flwang/julim/hughsaunders/greghaynes/annegentle/sriramhere/arnaudleg/coroner/boris_42/blint/ybudupi/cppcabrera), Please log into the Google GSoC web-site and review **all** proposals within a week (our own deadline - say 29th). 1) Please click "Wish to mentor" on the left hand side, if you are willing to mentor this project. Yes, we should have more than one mentor. This is a way to mention that you are willing to mentor, actual assignment will happen later i believe. So please switch this on for all projects you are interested in. 2) If you have a question about a proposal and need a response from the candidate, please leave a comment for them. If you want to ask a observation/question to other mentors or me, leave a comment marked "Private" 3) To assign a score. Please click on the number of start in "My score:" at the bottom 5 = amazing applicant, could be a module maintainer on completing the program 4 = strong applicant, will do a good job 3 = good applicant, but is somewhat inexperienced 2 = is unlikely to do a good job 1 = not a good candidate Please feel free to leave detailed notes on candidates you know well for other mentors (Please mark comments as "Private") If you are not able to help with this exercise, please let me know ASAP. If anyone else would like to step up and be a Mentor for any of these projects/students, please register in the Google GSoC site and let me know your "username". Thanks, dims -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack/GSoC 2014 - Reviewing Applications
Sriram, We'll have to check with a student if there are able to see it during this phase of the GSoC where mentors are evaluating the proposals. There is some information/guidance here: http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/userguide#depth_appreview http://en.flossmanuals.net/melange/student-application-period/ -- dims On Sat, Mar 22, 2014 at 6:34 PM, Sriram Subramanian wrote: > Davanum, are the scores private or is there a way to make them private? > > > On Sat, Mar 22, 2014 at 12:07 PM, Davanum Srinivas > wrote: >> >> Dear Students, >> >> We received the following proposals: >> >> AMES-Cloud (Nagashree Bhat) >> A pre-caching system for OpenStack (Anastasis Andronidis) >> Proposal for Implementing an application-level FWaaS driver >> ((Zorp) Dániel Csubák) >> Cassandra and Redis storage backend for Openstack marconi (Jeremy >> Henriques) >> Openstack-OSLO :Add a New Backend to Oslo.Cache (sai krishna) >> Implement a Fuzz testing framework that can be run on Tempest >> (Manishanker Talusani) >> How to detect network anomalies from telemetry data within Openstack >> (mst89) >> Implement a re-usable shared library for VMware(oslo.vmware) (Masaru >> Nomura) >> Cross-services Scheduler project (Artem Shepelev) >> OpenStack/Marconi: Py3k support (Nataliia) >> Improve benchmarking context mechanism in Rally (Kumar Rishabh) >> Develop a benchmarking suite and new storage backends to OpenStack >> Marconi (Prashanth Raghu) >> Adding Redis as a Storage Backend to OpenStack Marconi (Chenchong Qin) >> Auto Benchmarking System for OpenStack (RobberPhex) >> Developing Benchmarks for Virtual Machines of OpenStack with Rally >> (Tzanetos Balitsaris) >> Add a new storage backend to the OpenStack Message Queuing Service >> (Victoria Martínez de la Cruz) >> >> Dear Mentors >> (ddutta/flwang/julim/hughsaunders/greghaynes/annegentle/sriramhere/arnaudleg/coroner/boris_42/blint/ybudupi/cppcabrera), >> >> Please log into the Google GSoC web-site and review **all** proposals >> within a week (our own deadline - say 29th). >> >> 1) Please click "Wish to mentor" on the left hand side, if you are >> willing to mentor this project. >>Yes, we should have more than one mentor. This is a way to mention >> that you are willing to mentor, >>actual assignment will happen later i believe. So please switch >> this on for all projects you are >>interested in. >> >> 2) If you have a question about a proposal and need a response from >> the candidate, please leave >>a comment for them. If you want to ask a observation/question to >> other mentors or me, leave a >>comment marked "Private" >> >> 3) To assign a score. Please click on the number of start in "My >> score:" at the bottom >> 5 = amazing applicant, could be a module maintainer on completing >> the program >> 4 = strong applicant, will do a good job >> 3 = good applicant, but is somewhat inexperienced >> 2 = is unlikely to do a good job >> 1 = not a good candidate >> >> Please feel free to leave detailed notes on candidates you know well >> for other mentors (Please mark comments as "Private") >> >> If you are not able to help with this exercise, please let me know ASAP. >> >> If anyone else would like to step up and be a Mentor for any of these >> projects/students, please register in the Google GSoC site and let me >> know your "username". >> >> Thanks, >> dims >> >> >> >> -- >> Davanum Srinivas :: http://davanum.wordpress.com >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Thanks, > -Sriram > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] oslo removal of use_tpool conf option
I do agree with Chris that process-wise, there was a failure and we need a way to ensure that it does not happen again. (There was a config option lost in the shuffle w/o a deprecation period) On Thu, Apr 17, 2014 at 7:59 PM, Chris Behrens wrote: > > On Apr 17, 2014, at 4:26 PM, Joshua Harlow wrote: > > Just an honest question (no negativity intended I swear!). > > If a configuration option exists and only works with a patched eventlet why > is that option an option to begin with? (I understand the reason for the > patch, don't get me wrong). > > > Right, it’s a valid question. This feature has existed one way or another in > nova for quite a while. Initially the implementation in nova was wrong. I > did not know that eventlet was also broken at the time, although I > discovered it in the process of fixing nova’s code. I chose to leave the > feature because it’s something that we absolutely need long term, unless you > really want to live with DB calls blocking the whole process. I know I > don’t. Unfortunately the bug in eventlet is out of our control. (I made an > attempt at fixing it, but it’s not 100%. Eventlet folks currently have an > alternative up that may or may not work… but certainly is not in a release > yet.) We have an outstanding bug on our side to track this, also. > > The below is comparing apples/oranges for me. > > - Chris > > > Most users would not be able to use such a configuration since they do not > have this patched eventlet (I assume a newer version of eventlet someday in > the future will have this patch integrated in it?) so although I understand > the frustration around this I don't understand why it would be an option in > the first place. An aside, if the only way to use this option is via a > non-standard eventlet then how is this option tested in the community, aka > outside of said company? > > An example: > > If yahoo has some patched kernel A that requires an XYZ config turned on in > openstack and the only way to take advantage of kernel A is with XYZ config > 'on', then it seems like that’s a yahoo only patch that is not testable and > useable for others, even if patched kernel A is somewhere on github it's > still imho not something that should be a option in the community (anyone > can throw stuff up on github and then say I need XYZ config to use it). > > To me non-standard patches that require XYZ config in openstack shouldn't be > part of the standard openstack, no matter the company. If patch A is in the > mainline kernel (or other mainline library), then sure it's fair game. > > -Josh > > From: Chris Behrens > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Thursday, April 17, 2014 at 3:20 PM > To: OpenStack Development Mailing List > Subject: [openstack-dev] oslo removal of use_tpool conf option > > > I’m going to try to not lose my cool here, but I’m extremely upset by this. > > In December, oslo apparently removed the code for ‘use_tpool’ which allows > you to run DB calls in Threads because it was ‘eventlet specific’. I noticed > this when a review was posted to nova to add the option within nova itself: > > https://review.openstack.org/#/c/59760/ > > I objected to this and asked (more demanded) for this to be added back into > oslo. It was not. What I did not realize when I was reviewing this nova > patch, was that nova had already synced oslo’s change. And now we’ve > released Icehouse with a conf option missing that existed in Havana. > Whatever projects were using oslo’s DB API code has had this option > disappear (unless an alternative was merged). Maybe it’s only nova.. I don’t > know. > > Some sort of process broke down here. nova uses oslo. And oslo removed > something nova uses without deprecating or merging an alternative into nova > first. How I believe this should have worked: > > 1) All projects using oslo’s DB API code should have merged an alternative > first. > 2) Remove code from oslo. > 3) Then sync oslo. > > What do we do now? I guess we’ll have to back port the removed code into > nova. I don’t know about other projects. > > NOTE: Very few people are probably using this, because it doesn’t work > without a patched eventlet. However, Rackspace happens to be one that does. > And anyone waiting on a new eventlet to be released such that they could use > this with Icehouse is currently out of luck. > > - Chris > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] nominating Victor Stinner for the Oslo core reviewers team
+1 from me. On Mon, Apr 21, 2014 at 12:39 PM, Doug Hellmann wrote: > I propose that we add Victor Stinner (haypo on freenode) to the Oslo > core reviewers team. > > Victor is a Python core contributor, and works on the development team > at eNovance. He created trollius, a port of Python 3's tulip/asyncio > module to Python 2, at least in part to enable a driver for > oslo.messaging. He has been quite active with Python 3 porting work in > Oslo and some other projects, and organized a sprint to work on the > port at PyCon last week. The patches he has written for the python 3 > work have all covered backwards-compatibility so that the code > continues to work as before under python 2. > > Given his background, skills, and interest, I think he would be a good > addition to the team. > > Doug > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] OpenStack/GSoC - Welcome!
Hi Team, Please join me in welcoming the following students to our GSoC program [1]. Congrats everyone. Now the hard work begins :) Have fun as well. Artem Shepelev Kumar Rishabh Manishanker Talusani Masaru Nomura Prashanth Raghu Tzanetos Balitsaris Victoria Martínez de la Cruz -- dims [1] https://www.google-melange.com/gsoc/org2/google/gsoc2014/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Could we please use 1.4.1 for oslo.messaging *now*? (was: Oslo final releases ready)
Zigo, Ouch! Can you please open a bug in oslo.messaging, i'll mark it critical thanks, dims On Tue, Sep 23, 2014 at 4:35 AM, Thomas Goirand wrote: > On 09/18/2014 10:04 PM, Doug Hellmann wrote: >> All of the final releases for the Oslo libraries for the Juno cycle are >> available on PyPI. I’m working on a couple of patches to the global >> requirements list to update the baseline in the applications. In all cases, >> the final release is a second tag on a previously released version. >> >> - oslo.config - 1.4.0 (same as 1.4.0.0a5) >> - oslo.db - 1.0.0 (same as 0.5.0) >> - oslo.i18n - 1.0.0 (same as 0.4.0) >> - oslo.messaging - 1.4.0 (same as 1.4.0.0a5) >> - oslo.rootwrap - 1.3.0 (same as 1.3.0.0a3) >> - oslo.serialization - 1.0.0 (same as 0.3.0) >> - oslosphinx - 2.2.0 (same as 2.2.0.0a3) >> - oslotest - 1.1.0 (same as 1.1.0.0a2) >> - oslo.utils - 1.0.0 (same as 0.3.0) >> - cliff - 1.7.0 (previously tagged, so not a new release) >> - stevedore - 1.0.0 (same as 1.0.0.0a2) >> >> Congratulations and *Thank You* to the Oslo team for doing an amazing job >> with graduations this cycle! >> >> Doug > > Doug, > > Here in Debian, I have a *huge* mess with versionning with oslo.messaging. > > tl;dr: Because of that version number mess, please add a tag 1.4.1 to > oslo.messaging now and use it everywhere instead of 1.4.0. > > Longer version: > > What happened is that Chuck released a wrong version of Keystone (eg: > the trunk rather than the stable branch). Therefore, I uploaded a > version 1.4.0 beta version of olso.messaging in Debian Unstable/Jessie, > because I thought the Icehouse version of Keystone needed it. (Sid / > Jessie is supposed to keep Icehouse stuff only.) > > That would have been about fine, if only I didn't upgraded > oslo.messaging to the last version in Sid, because I didn't want to keep > a beta release in Jessie. Though this last version depends on > oslo.config 1.4.0.0~a5, then probably even more. > > So I reverted the 1.4.0.0 upload in Debian Sid, by uploading version > 1.4.0.0+really+1.3.1, which as its name may suggest, really is a 1.3.1 > version (I did that to avoid having an EPOC and need to re-upload > updates of all reverse dependencies of oslo.messaging). That's fine, > we're covered for Sid/Jessie. > > But then, the Debian Experimental version of oslo.messaging is lower > than the one in Sid/Jessie, so I have breakage there. > > If we declare a new 1.4.1, and have this fixed in our > global-requirements.txt, then everything goes back in order for me, I > get back on my feets. Otherwise, I'll have to deal with this, and make > fake version numbers which will not match anything real released by > OpenStack, which may lead to even more mistakes. > > So, could you please at least: > - add a "git tag 1.4.1" to oslo.messaging right now, matching 1.4.0 > > This will make sure that nobody will use 1.4.1 again, and that I'm fine > using this version number in Debian Experimental, which will be higher > than the one in Sid. > > And then, optionally, it would help me if you could (but I can leave > without it): > - Use 1.4.1 for oslo.messaging in global-requirements.txt > - Have every project that needs 1.4.0 bump to 1.4.1 as well > > This would be a lot less work than for me to declare an EPOC in the > oslo.messaging package, and fix all reverse dependencies. The affected > packages for Juno for me are: > - ceilometer > - cinder > - designate > - glance > - heat > - ironic > - keystone > - neutron > - nova > - oslo-config > - oslo.rootwrap > - oslo.i18n > - python-pycadf > > I'd have to upload updates for all of them even if we use 1.4.1 instead > of using an EPOC (eg: 1:1.4.0), but that's still much better for me to > use 1.4.1 than an EPOC. EPOC are ugly (because not visible in file > names) and confusing (it's easy to forget them), and non-reversible, so > I'd like to avoid it if possible. > > I'm sorry for the mess and added work. > Cheers, > > Thomas Goirand (zigo) > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
