Re: [openstack-dev] [oslo] Updates from the Summit
Please add it Gorka. thanks, dims On Thu, May 28, 2015 at 6:23 AM, Gorka Eguileor gegui...@redhat.com wrote: On Wed, May 27, 2015 at 08:47:42AM -0400, Davanum Srinivas wrote: Hi Team, Here are the etherpads from the summit[1]. I remember that in Taskflow's Fishbowl session we discussed not only pause/yield option but abort/cancel for long running tasks as well, but reviewing the Etherpad now I don't see it there. Should I just add it to Ideas for Liberty section or there's a specific reason why it wasn't included? Cheers, Gorka. Some highlights are as follows: Oslo.messaging : Took status of the existing zmq driver, proposed a new driver in parallel to the existing zmq driver. Also looked at possibility of using Pika with RabbitMQ. Folks from pivotal promised to help with our scenarios as well. Oslo.rootwrap : Debated daemon vs a new privileged service. The Nova change to add rootwrap as daemon is on hold pending progress on the privsep proposal/activity. Oslo.versionedobjects : We had a nice presentation from Dan about what o.vo can do and a deepdive into what we could do in next release. Taskflow : Josh and team came up with several new features and how to improve usability We will also have several new libraries in Liberty (oslo.cache, oslo.service, oslo.reports, futurist, automaton etc). We talked about our release processes, functional testing, deprecation strategies and debated a but about how best to move to async models as well. Please see etherpads for detailed information. thanks, dims [1] https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Oslo -- 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 __ 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] Updates from the Summit
Flavio, PIka is an unknown quantity at the moment as none of us have touched it. It was brought up by rabbitmq folks. So someone should look at it. We don't have have enough info either to say we should use Pika by itself or as a kombu driver. We may have to make that determination at some point in the future if indeed pika is so much better. We don't have anyone in the Kombu community either...and Pika will need to pass the python34, licensing etc as well to be considered in addition to the performance. thanks, dims On Thu, May 28, 2015 at 7:08 AM, Flavio Percoco fla...@redhat.com wrote: On 27/05/15 10:24 -0700, Joshua Harlow wrote: Thanks dims! indeed, thanks. [snip] Also for the pika one, I'd really like to understand why not kombu. I don't know enough of the background, but from that session it looks like we need to do some comparative analysis (and imho get feedback from asksol[1] and others) before we go to deep down that rabbit hole (no jump to another 'greener pasture' imho should be done without all of this, to avoid pissing off the two [kombu, pika] communities). I couldn't attend this session but I'd also like to understand what's the idea behind using pika instead of kombu. FWIW, older versions of kombu used pika and it was moved away from it. One of the reasons was that pika was not stable enough at that time. This could've changed. If pika is just better than the amqp lib used by Kombu, wouldn't it be better to just contribute back to kombu? Cheers, Flavio My 2 cents :-P [1] https://github.com/ask -Josh Davanum Srinivas wrote: Hi Team, Here are the etherpads from the summit[1]. Some highlights are as follows: Oslo.messaging : Took status of the existing zmq driver, proposed a new driver in parallel to the existing zmq driver. Also looked at possibility of using Pika with RabbitMQ. Folks from pivotal promised to help with our scenarios as well. Oslo.rootwrap : Debated daemon vs a new privileged service. The Nova change to add rootwrap as daemon is on hold pending progress on the privsep proposal/activity. Oslo.versionedobjects : We had a nice presentation from Dan about what o.vo can do and a deepdive into what we could do in next release. Taskflow : Josh and team came up with several new features and how to improve usability We will also have several new libraries in Liberty (oslo.cache, oslo.service, oslo.reports, futurist, automaton etc). We talked about our release processes, functional testing, deprecation strategies and debated a but about how best to move to async models as well. Please see etherpads for detailed information. thanks, dims [1] https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Oslo __ 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 -- @flaper87 Flavio Percoco __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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] [Ironic][oslo] Stepping down from oslo-ironic liaison
That's right. The oslo team is OK with the liaison to other teams not being a core reviewer. -- dims On Thu, May 28, 2015 at 3:35 AM, Flavio Percoco fla...@redhat.com wrote: On 28/05/15 09:20 +0200, Victor Stinner wrote: Oh, on the wiki page I read that The liaison should be a core reviewer for the project, but does not need to be the PTL.. I'm not a core reviewer for nova. Is it an issue? This was more like a general recommendation, I guess. I don't think the liaison has to be a core reviewer at all. Cheers, Flavio On the wiki page, I see that John Villalovos (happycamp) is the Nova liaison for Oslo, not Joe Goron. I don't understand. Victor Le 27/05/2015 20:44, Joe Gordon a écrit : On Wed, May 27, 2015 at 3:20 AM, Davanum Srinivas dava...@gmail.com mailto:dava...@gmail.com wrote: Victor, Nice, yes, Joe was the liaison with Nova so far. Yes, please go ahead and add your name in the wiki for Nova as i believe Joe is winding down the oslo liaison as well. https://wiki.openstack.org/wiki/CrossProjectLiaisons#Oslo Yup, thank you Victor! thanks, dims On Wed, May 27, 2015 at 5:12 AM, Victor Stinner vstin...@redhat.com mailto:vstin...@redhat.com wrote: Hi, By the way, who is the oslo liaison for nova? If there is nobody, I would like to take this position. Victor Le 25/05/2015 18:45, Ghe Rivero a écrit : My focus on the Ironic project has been decreasing in the last cycles, so it's about time to relinquish my position as a oslo-ironic liaison so new contributors can take over it and help ironic to be the vibrant project it is. So long, and thanks for all the fish, Ghe Rivero -- Pinky: Gee, Brain, what do you want to do tonight? The Brain: The same thing we do every night, Pinky—try to take over the world! .''`. Pienso, Luego Incordio : :' : `. `' `- www.debian.org http://www.debian.org http://www.debian.org www.openstack.com http://www.openstack.com http://www.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://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://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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] Updates from the Summit
Flavio, yay! :) -- dims On Thu, May 28, 2015 at 9:24 AM, Flavio Percoco fla...@redhat.com wrote: On 28/05/15 07:34 -0400, Davanum Srinivas wrote: Flavio, PIka is an unknown quantity at the moment as none of us have touched it. It was brought up by rabbitmq folks. So someone should look at it. We don't have have enough info either to say we should use Pika by itself or as a kombu driver. We may have to make that determination at some point in the future if indeed pika is so much better. We don't have anyone in the Kombu community either...and Pika will need to pass the python34, licensing etc as well to be considered in addition to the performance. I'm here from the Kombu community[0] (although I haven't done much lately). I think we should consider contributing back before dropping kombu if we ever get to the point where we think pika is better than whatever kombu is using. Flavio [0] https://github.com/orgs/celery/people thanks, dims On Thu, May 28, 2015 at 7:08 AM, Flavio Percoco fla...@redhat.com wrote: On 27/05/15 10:24 -0700, Joshua Harlow wrote: Thanks dims! indeed, thanks. [snip] Also for the pika one, I'd really like to understand why not kombu. I don't know enough of the background, but from that session it looks like we need to do some comparative analysis (and imho get feedback from asksol[1] and others) before we go to deep down that rabbit hole (no jump to another 'greener pasture' imho should be done without all of this, to avoid pissing off the two [kombu, pika] communities). I couldn't attend this session but I'd also like to understand what's the idea behind using pika instead of kombu. FWIW, older versions of kombu used pika and it was moved away from it. One of the reasons was that pika was not stable enough at that time. This could've changed. If pika is just better than the amqp lib used by Kombu, wouldn't it be better to just contribute back to kombu? Cheers, Flavio My 2 cents :-P [1] https://github.com/ask -Josh Davanum Srinivas wrote: Hi Team, Here are the etherpads from the summit[1]. Some highlights are as follows: Oslo.messaging : Took status of the existing zmq driver, proposed a new driver in parallel to the existing zmq driver. Also looked at possibility of using Pika with RabbitMQ. Folks from pivotal promised to help with our scenarios as well. Oslo.rootwrap : Debated daemon vs a new privileged service. The Nova change to add rootwrap as daemon is on hold pending progress on the privsep proposal/activity. Oslo.versionedobjects : We had a nice presentation from Dan about what o.vo can do and a deepdive into what we could do in next release. Taskflow : Josh and team came up with several new features and how to improve usability We will also have several new libraries in Liberty (oslo.cache, oslo.service, oslo.reports, futurist, automaton etc). We talked about our release processes, functional testing, deprecation strategies and debated a but about how best to move to async models as well. Please see etherpads for detailed information. thanks, dims [1] https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Oslo __ 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 -- @flaper87 Flavio Percoco __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims -- @flaper87 Flavio Percoco -- 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] [Ironic][oslo] Stepping down from oslo-ironic liaison
Thanks Doug! On Thu, May 28, 2015 at 10:10 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Davanum Srinivas (dims)'s message of 2015-05-28 06:02:24 -0400: That's right. The oslo team is OK with the liaison to other teams not being a core reviewer. I've updated the wiki to reflect that. Doug __ 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
[openstack-dev] [nova-docker] Looking for volunteers to take care of nova-docker
Hi all, So the feedback during the Vancouver summit from some of the nova cores was that, we needed volunteers to take care of the nova-docker driver before it can be considered to merge in the Nova tree. As an exercise is resposibility, we need people who can reinstate the nova-docker non-voting job (essentially revert [1]) and keep an eye on the output of the job every day to make sure when the CI jobs run against the nova reviews, they stay green. I've cc'ed some folks who expressed interest in the past, please reply back to this thread if you wish to join this effort and specifically if you can volunteer for watching and fixing the CI as issues arise (keeping up with Nova trunk and requirements etc). If there are no volunteers here, nova-docker will stay in sourceforge. So folks who are using it, please step up. Thanks, dims [1] https://review.openstack.org/#/c/150887/ -- 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] [Ironic][oslo] Stepping down from oslo-ironic liaison
Tan, Awesome, please update the page here: https://wiki.openstack.org/wiki/CrossProjectLiaisons thanks, dims On Tue, May 26, 2015 at 9:04 PM, Tan, Lin lin@intel.com wrote: Hi Doug and guys, I would like to work as oslo-ironic liasison to sync Ironic with Oslo. I will attend the regular Oslo meeting for sure. My IRC name is lintan, and Launchpad id is tan-lin-good Thanks Tan -Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: Tuesday, May 26, 2015 9:17 PM To: openstack-dev Subject: Re: [openstack-dev] [Ironic][oslo] Stepping down from oslo-ironic liaison Excerpts from Ghe Rivero's message of 2015-05-25 09:45:47 -0700: My focus on the Ironic project has been decreasing in the last cycles, so it's about time to relinquish my position as a oslo-ironic liaison so new contributors can take over it and help ironic to be the vibrant project it is. So long, and thanks for all the fish, Ghe Rivero Thanks for your help as liaison, Ghe, the Oslo team appreciates your effort! Doug __ 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] [Ironic][oslo] Stepping down from oslo-ironic liaison
Victor, Nice, yes, Joe was the liaison with Nova so far. Yes, please go ahead and add your name in the wiki for Nova as i believe Joe is winding down the oslo liaison as well. https://wiki.openstack.org/wiki/CrossProjectLiaisons#Oslo thanks, dims On Wed, May 27, 2015 at 5:12 AM, Victor Stinner vstin...@redhat.com wrote: Hi, By the way, who is the oslo liaison for nova? If there is nobody, I would like to take this position. Victor Le 25/05/2015 18:45, Ghe Rivero a écrit : My focus on the Ironic project has been decreasing in the last cycles, so it's about time to relinquish my position as a oslo-ironic liaison so new contributors can take over it and help ironic to be the vibrant project it is. So long, and thanks for all the fish, Ghe Rivero -- Pinky: Gee, Brain, what do you want to do tonight? The Brain: The same thing we do every night, Pinky—try to take over the world! .''`. Pienso, Luego Incordio : :' : `. `' `- www.debian.org http://www.debian.org www.openstack.com http://www.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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
[openstack-dev] [oslo] Updates from the Summit
Hi Team, Here are the etherpads from the summit[1]. Some highlights are as follows: Oslo.messaging : Took status of the existing zmq driver, proposed a new driver in parallel to the existing zmq driver. Also looked at possibility of using Pika with RabbitMQ. Folks from pivotal promised to help with our scenarios as well. Oslo.rootwrap : Debated daemon vs a new privileged service. The Nova change to add rootwrap as daemon is on hold pending progress on the privsep proposal/activity. Oslo.versionedobjects : We had a nice presentation from Dan about what o.vo can do and a deepdive into what we could do in next release. Taskflow : Josh and team came up with several new features and how to improve usability We will also have several new libraries in Liberty (oslo.cache, oslo.service, oslo.reports, futurist, automaton etc). We talked about our release processes, functional testing, deprecation strategies and debated a but about how best to move to async models as well. Please see etherpads for detailed information. thanks, dims [1] https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Oslo -- 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.vmware release 0.13.0 (liberty)
Joe, Given that the code once lived in nova and the team across has spent quite a bit of time to turn it into a library which at last count was adopted by 6 projects at least. i'd like to give the team some credit. openstack/ceilometer/test-requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/cinder/requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/congress/requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/glance/requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/glance_store/test-requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/nova/test-requirements.txt:oslo.vmware=0.11.1,!=0.13.0 # Apache-2.0 Shit happens! the team that works on oslo.vmware overlaps nova too and others. There were several solutions that came up quickly as well. we can't just say nothing should ever break or we should not use 0.x.x then we can never make progress. This is not going to get any better either with the big tent coming up. All that matters is how quickly we can recover and move on with our collective sanity intact. Let's work on that in addition as well. I'd also want to give some more say in the actual folks who are contributing and working on the code as well in the specific discussion. Anyway, with the global-requirements block of 0.13.0, nova should unclog and we'll try to get something out soon in 0.13.1 to keep @haypo's python34 effort going as well. +1000 to release fewer unexpectedly incompatible libraries and continue working on improving how we handle dependencies in general. i'd like to hear specific things we can do that we are not doing both for libraries under our collective care as well as things we use from the general python community. thanks, dims On Wed, May 27, 2015 at 1:52 PM, Joe Gordon joe.gord...@gmail.com wrote: On Wed, May 27, 2015 at 12:54 AM, Gary Kotton gkot...@vmware.com wrote: Hi, I prefer the patched posted by Sabari. The patch has two changes: It fixes unit tests In the even that an instance spawn fails then it catches an exception to warn the admin that the guestId may be invalid. The only degradation may be that the warning will no longer be there. I think that the admin can get this information from the logged exception too. So this breakage takes us into some strange waters. oslo.vmware is at version 0.x.x which according to semver [0] means Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. If that is accurate, then nova should not be using oslo.vmware, since we shouldn't use an unstable library in production. If we are treating the API as stable then semver says we need to rev the major version (MAJOR version when you make incompatible API changes). What I am trying to say is, I don't know how you can say the nova unit tests are 'wrong.' either nova using oslo.vmware is 'wrong' or oslo.vmware breaking the API is 'wrong'. With OpenStack being so large and having so many dependencies (many of them openstack owned), we should focus on making sure we release fewer unexpectedly incompatible libraries and continue working on improving how we handle dependencies in general (lifeless has a big arch he is working on here AFAIK). So I am not in favor of the nova unit test change as a fix here. [0] http://semver.org/ Thanks Gary From: Sabari Murugesan sabari.b...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Wednesday, May 27, 2015 at 6:20 AM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] oslo.vmware release 0.13.0 (liberty) Matt I posted a patch https://review.openstack.org/#/c/185830/1 to fix the nova tests and make it compatible with the oslo.vmware 0.13.0 release. I am fine with the revert and g-r blacklist as oslo.vmware broke the semver but we can also consider this patch as an option. Thanks Sabari On Tue, May 26, 2015 at 2:53 PM, Davanum Srinivas dava...@gmail.com wrote: Vipin, Gary, Can you please accept the revert or figure out the best way to handle this? thanks, dims On Tue, May 26, 2015 at 5:41 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 5/26/2015 4:19 PM, Matt Riedemann wrote: On 5/26/2015 9:53 AM, Davanum Srinivas wrote: We are gleeful to announce the release of: oslo.vmware 0.13.0: Oslo VMware library With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware For more details, please see the git log history below and: http://launchpad.net/oslo.vmware/+milestone/0.13.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.vmware Changes in oslo.vmware 0.12.0..0.13.0 - 5df9daa Add ToolsUnavailable exception 286cb9e Add support for dynamicProperty 7758123 Remove support for Python 3.3 11e7d71 Updated from global
Re: [openstack-dev] [nova-docker] Looking for volunteers to take care of nova-docker
Bich, Sure thing, just start on #nova-docker irc channel and we can talk there -- dims On Wed, May 27, 2015 at 11:28 AM, Bich Le l...@platform9.com wrote: I'd like to contribute. But I may need some help / pointers in getting started (I have experience with running and hacking openstack, but this would be my first time contributing). Thanks. Bich Le Platform9 On Wed, May 27, 2015 at 3:48 AM, Davanum Srinivas dava...@gmail.com wrote: Hi all, So the feedback during the Vancouver summit from some of the nova cores was that, we needed volunteers to take care of the nova-docker driver before it can be considered to merge in the Nova tree. As an exercise is resposibility, we need people who can reinstate the nova-docker non-voting job (essentially revert [1]) and keep an eye on the output of the job every day to make sure when the CI jobs run against the nova reviews, they stay green. I've cc'ed some folks who expressed interest in the past, please reply back to this thread if you wish to join this effort and specifically if you can volunteer for watching and fixing the CI as issues arise (keeping up with Nova trunk and requirements etc). If there are no volunteers here, nova-docker will stay in sourceforge. So folks who are using it, please step up. Thanks, dims [1] https://review.openstack.org/#/c/150887/ -- Davanum Srinivas :: https://twitter.com/dims -- 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] Updates from the Summit
Josh, thanks. yes, the kombu vs pika is just a research thing someone should look at. no blueprint, no spec, so not approved in anyway :) -- dims On Wed, May 27, 2015 at 1:24 PM, Joshua Harlow harlo...@outlook.com wrote: Thanks dims! Good write up, Other things I noted (more controversial ones); is that we need to come up with a concurrency strategy (and/or guidelines, and/or best practices). At least I feel this will be a way that works and imho implies that one concurrency strategy will (likely) not fit every project; at the best we can do is try to offer best practices. Also for the pika one, I'd really like to understand why not kombu. I don't know enough of the background, but from that session it looks like we need to do some comparative analysis (and imho get feedback from asksol[1] and others) before we go to deep down that rabbit hole (no jump to another 'greener pasture' imho should be done without all of this, to avoid pissing off the two [kombu, pika] communities). My 2 cents :-P [1] https://github.com/ask -Josh Davanum Srinivas wrote: Hi Team, Here are the etherpads from the summit[1]. Some highlights are as follows: Oslo.messaging : Took status of the existing zmq driver, proposed a new driver in parallel to the existing zmq driver. Also looked at possibility of using Pika with RabbitMQ. Folks from pivotal promised to help with our scenarios as well. Oslo.rootwrap : Debated daemon vs a new privileged service. The Nova change to add rootwrap as daemon is on hold pending progress on the privsep proposal/activity. Oslo.versionedobjects : We had a nice presentation from Dan about what o.vo can do and a deepdive into what we could do in next release. Taskflow : Josh and team came up with several new features and how to improve usability We will also have several new libraries in Liberty (oslo.cache, oslo.service, oslo.reports, futurist, automaton etc). We talked about our release processes, functional testing, deprecation strategies and debated a but about how best to move to async models as well. Please see etherpads for detailed information. thanks, dims [1] https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Oslo __ 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.messaging][zeromq] Next step
Alec, Here are the slides: http://www.slideshare.net/davanum/oslomessaging-new-0mq-driver-proposal All the 0mq patches to date should be either already merged in trunk or waiting for review on trunk. Oleksii, Li Ma, Can you please address the other questions? thanks, Dims On Tue, May 26, 2015 at 11:43 AM, Alec Hothan (ahothan) ahot...@cisco.com wrote: Looking at what is the next step following the design summit meeting on 0MQ as the etherpad does not provide too much information. Few questions: - would it be possible to have the slides presented (showing the proposed changes in the 0MQ driver design) to be available somewhere? - is there a particular branch in the oslo messaging repo that contains 0MQ related patches - I'm more particularly interested by James Page's patch to pool the 0MQ connections but there might be other - question for Li Ma, are you deploying with the straight upstream 0MQ driver or with some additional patches? The per node proxy process (which is itself some form of broker) needs to be removed completely if the new solution is to be made really broker-less. This will also eliminate the only single point of failure in the path and reduce the number of 0MQ sockets (and hops per message) by half. I think it was proposed that we go on with the first draft of the new driver (which still keeps the proxy server but reduces the number of sockets) before eventually tackling the removal of the proxy server? Thanks Alec __ 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
[openstack-dev] oslo.log release 1.2.0 (liberty)
We are thrilled to announce the release of: oslo.log 1.2.0: oslo.log library With source available at: http://git.openstack.org/cgit/openstack/oslo.log For more details, please see the git log history below and: http://launchpad.net/oslo.log/+milestone/1.2.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.log Changes in oslo.log 1.1.0..1.2.0 7730773 Use proper deprecation for use-syslog-rfc-format option 33f5c6f Replace RFCSysLogHandler by a syslog() based one 36c925e Make remove_in=0 (no removal) use a better syntax 37166ac Remove is_compatible from versionutils e9a11f4 Add versionutils options to list_opts 3a4dc52 Add versionutils to API documentation cc713ab Advertise support for Python3.4 / Remove support for Python 3.3 39da8f9 Updated from global requirements 00036e7 Updated from global requirements 187881e Remove run_cross_tests.sh dbae3bf Deprecate WritableLogger - used for eventlet logging b457dae Log deprecation message when catching deprecated exceptions 27f7fe5 Change misleading TRACE to ERROR 6472777 Provide an API to let tempest control the log file 07d2641 fix pep8 errors c750167 Add pypi download + version badges 494074b Update to latest hacking 6a53053 move versionutils into place e10dccf Add liberty release name to versionutils Diffstat (except docs and test files) - README.rst | 15 +- openstack-common.conf| 5 +- openstack/common/versionutils.py | 260 - oslo_log/_options.py | 12 +- oslo_log/handlers.py | 43 - oslo_log/log.py | 71 --- oslo_log/loggers.py | 7 +- oslo_log/versionutils.py | 250 requirements.txt | 5 +- setup.cfg| 2 +- test-requirements.txt| 2 +- tox.ini | 2 +- 20 files changed, 741 insertions(+), 711 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index f38fc04..3bfd17a 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ -pbr=0.6,!=0.7,1.0 +pbr=0.11,2.0 @@ -9 +9 @@ iso8601=0.1.9 -oslo.config=1.9.3 # Apache-2.0 +oslo.config=1.11.0 # Apache-2.0 @@ -13,0 +14 @@ oslo.serialization=1.4.0 # Apache-2.0 +debtcollector=0.3.0 # Apache-2.0 diff --git a/test-requirements.txt b/test-requirements.txt index b551d65..7f335ce 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -5 +5 @@ -hacking=0.9.1,0.10 +hacking=0.10.0,0.11 -- 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.vmware release 0.13.0 (liberty)
Vipin, Gary, Can you please accept the revert or figure out the best way to handle this? thanks, dims On Tue, May 26, 2015 at 5:41 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 5/26/2015 4:19 PM, Matt Riedemann wrote: On 5/26/2015 9:53 AM, Davanum Srinivas wrote: We are gleeful to announce the release of: oslo.vmware 0.13.0: Oslo VMware library With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware For more details, please see the git log history below and: http://launchpad.net/oslo.vmware/+milestone/0.13.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.vmware Changes in oslo.vmware 0.12.0..0.13.0 - 5df9daa Add ToolsUnavailable exception 286cb9e Add support for dynamicProperty 7758123 Remove support for Python 3.3 11e7d71 Updated from global requirements 883c441 Remove run_cross_tests.sh 1986196 Use suds-jurko on Python 2 84ab8c4 Updated from global requirements 6cbde19 Imported Translations from Transifex 8d4695e Updated from global requirements 1668fef Raise VimFaultException for unknown faults 15dbfb2 Imported Translations from Transifex c338f19 Add NoDiskSpaceException 25ec49d Add utility function to get profiles by IDs 32c61ee Add bandit to tox for security static analysis f140b7e Add SPBM WSDL for vSphere 6.0 Diffstat (except docs and test files) - bandit.yaml| 130 +++ openstack-common.conf |2 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-error.po |9 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-info.po |3 - .../fr/LC_MESSAGES/oslo.vmware-log-warning.po | 10 - oslo.vmware/locale/fr/LC_MESSAGES/oslo.vmware.po | 86 +- oslo.vmware/locale/oslo.vmware.pot | 48 +- oslo_vmware/api.py | 10 +- oslo_vmware/exceptions.py | 13 +- oslo_vmware/objects/datastore.py |6 +- oslo_vmware/pbm.py | 18 + oslo_vmware/service.py |2 +- oslo_vmware/wsdl/6.0/core-types.xsd| 237 + oslo_vmware/wsdl/6.0/pbm-messagetypes.xsd | 186 oslo_vmware/wsdl/6.0/pbm-types.xsd | 806 ++ oslo_vmware/wsdl/6.0/pbm.wsdl | 1104 oslo_vmware/wsdl/6.0/pbmService.wsdl | 16 + requirements-py3.txt | 27 - requirements.txt |8 +- setup.cfg |2 +- test-requirements-bandit.txt |1 + tox.ini| 14 +- 27 files changed, 2645 insertions(+), 262 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index 807bcfc..dd5a1aa 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ -pbr=0.6,!=0.7,1.0 +pbr=0.11,2.0 @@ -23,3 +23,3 @@ PyYAML=3.1.0 -suds=0.4 -eventlet=0.16.1,!=0.17.0 -requests=2.2.0,!=2.4.0 +suds-jurko=0.6 +eventlet=0.17.3 +requests=2.5.2 diff --git a/test-requirements-bandit.txt b/test-requirements-bandit.txt new file mode 100644 index 000..38c39e1 --- /dev/null +++ b/test-requirements-bandit.txt @@ -0,0 +1 @@ +bandit==0.10.1 There is now a blocking vmware unit tests bug in nova due to the oslo.vmware 0.13.0 release: https://bugs.launchpad.net/nova/+bug/1459021 Since the vmware driver unit test code in nova likes to stub out external APIs there is probably a bug in the nova unit tests rather than an issue in oslo.vmware, but I'm not very familiar so I can't really say. I have a revert for oslo.vmware here: https://review.openstack.org/#/c/185744/ And a block on the 0.13.0 version in global-requirements here: https://review.openstack.org/#/c/185748/ -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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
[openstack-dev] oslo.vmware release 0.13.0 (liberty)
We are gleeful to announce the release of: oslo.vmware 0.13.0: Oslo VMware library With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware For more details, please see the git log history below and: http://launchpad.net/oslo.vmware/+milestone/0.13.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.vmware Changes in oslo.vmware 0.12.0..0.13.0 - 5df9daa Add ToolsUnavailable exception 286cb9e Add support for dynamicProperty 7758123 Remove support for Python 3.3 11e7d71 Updated from global requirements 883c441 Remove run_cross_tests.sh 1986196 Use suds-jurko on Python 2 84ab8c4 Updated from global requirements 6cbde19 Imported Translations from Transifex 8d4695e Updated from global requirements 1668fef Raise VimFaultException for unknown faults 15dbfb2 Imported Translations from Transifex c338f19 Add NoDiskSpaceException 25ec49d Add utility function to get profiles by IDs 32c61ee Add bandit to tox for security static analysis f140b7e Add SPBM WSDL for vSphere 6.0 Diffstat (except docs and test files) - bandit.yaml| 130 +++ openstack-common.conf |2 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-error.po |9 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-info.po |3 - .../fr/LC_MESSAGES/oslo.vmware-log-warning.po | 10 - oslo.vmware/locale/fr/LC_MESSAGES/oslo.vmware.po | 86 +- oslo.vmware/locale/oslo.vmware.pot | 48 +- oslo_vmware/api.py | 10 +- oslo_vmware/exceptions.py | 13 +- oslo_vmware/objects/datastore.py |6 +- oslo_vmware/pbm.py | 18 + oslo_vmware/service.py |2 +- oslo_vmware/wsdl/6.0/core-types.xsd| 237 + oslo_vmware/wsdl/6.0/pbm-messagetypes.xsd | 186 oslo_vmware/wsdl/6.0/pbm-types.xsd | 806 ++ oslo_vmware/wsdl/6.0/pbm.wsdl | 1104 oslo_vmware/wsdl/6.0/pbmService.wsdl | 16 + requirements-py3.txt | 27 - requirements.txt |8 +- setup.cfg |2 +- test-requirements-bandit.txt |1 + tox.ini| 14 +- 27 files changed, 2645 insertions(+), 262 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index 807bcfc..dd5a1aa 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ -pbr=0.6,!=0.7,1.0 +pbr=0.11,2.0 @@ -23,3 +23,3 @@ PyYAML=3.1.0 -suds=0.4 -eventlet=0.16.1,!=0.17.0 -requests=2.2.0,!=2.4.0 +suds-jurko=0.6 +eventlet=0.17.3 +requests=2.5.2 diff --git a/test-requirements-bandit.txt b/test-requirements-bandit.txt new file mode 100644 index 000..38c39e1 --- /dev/null +++ b/test-requirements-bandit.txt @@ -0,0 +1 @@ +bandit==0.10.1 -- 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
[openstack-dev] oslo.messaging release 1.11.0 (liberty)
,!=0.17.0 +eventlet=0.17.3 @@ -26 +26,3 @@ PyYAML=3.1.0 -kombu=2.5.0 +# we set the amqp version to ensure heartbeat works +amqp=1.4.0 +kombu=3.0.7 @@ -29 +31 @@ kombu=2.5.0 -oslo.middleware=1.0.0 # Apache-2.0 +oslo.middleware=1.2.0 # Apache-2.0 @@ -32 +34 @@ oslo.middleware=1.0.0 # Apache-2.0 -futures=2.1.6 +futures=3.0 diff --git a/test-requirements-py3.txt b/test-requirements-py3.txt index 22b4c4e..71fe497 100644 --- a/test-requirements-py3.txt +++ b/test-requirements-py3.txt @@ -19,0 +20,3 @@ redis=2.10.0 +# for test_impl_zmq +pyzmq=14.3.1 # LGPL+BSD + -- 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
[openstack-dev] [oslo] No meeting today
Hi all, Sorry for the late notice, since it is a US holiday and we all just met last week at the summit. Let's skip today's meeting and talk next week. thanks, dims -- 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] [Ironic][oslo] Stepping down from oslo-ironic liaison
Thanks a lot for your work Ghe and best wishes and hope to see you back. -- dims On Mon, May 25, 2015 at 9:45 AM, Ghe Rivero g...@debian.org wrote: My focus on the Ironic project has been decreasing in the last cycles, so it's about time to relinquish my position as a oslo-ironic liaison so new contributors can take over it and help ironic to be the vibrant project it is. So long, and thanks for all the fish, Ghe Rivero -- Pinky: Gee, Brain, what do you want to do tonight? The Brain: The same thing we do every night, Pinky—try to take over the world! .''`. Pienso, Luego Incordio : :' : `. `' `-www.debian.orgwww.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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][service] oslo.service puplic repositiry review request
Hi Elena, This looks good to me. thanks, dims On Thu, May 21, 2015 at 7:38 AM, Elena Ezhova eezh...@mirantis.com wrote: Hi, all! As the spec for the graduation of oslo.service [1] is about to merge I have created a public repository on github [2] with oslo.service initial version, which is the next step in graduation of a library according to [3]. I would like to ask everyone interested to review it so we can proceed with the graduation process. Thanks, Elena [1] https://review.openstack.org/#/c/142659/9 [2] https://github.com/eezhova/oslo.service [3] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary __ 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] Changes to oslo.log section of Oslo Wiki page for source repo and bug reporting
Andreas, Thanks! 1. https://launchpad.net/oslo is an umbrella and oslo.log is under it. If you try to create a bug from https://bugs.launchpad.net/oslo you will be prompted to enter/choose oslo.log. So either way the bug created from either urls ends up int he same plate. So either url is ok. 2. Can you please switch it to http://git.openstack.org/cgit/openstack/oslo.log/ ? If you see http://git.openstack.org/ you will see all the projects thanks, dims On Thu, May 21, 2015 at 1:35 PM, Andreas Maier mai...@de.ibm.com wrote: Hi, I'd like to notify the Oslo community of these two changes to the oslo.log section on the Oslo Wiki page: 1. There were conflicting statements about where bugs against oslo.log should be created: - The CONTRIBUTING.rst file in oslo.log suggests: https://bugs.launchpad.net/oslo.log - The oslo.log section on the Oslo Wiki page mentions: https://bugs.launchpad.net/oslo Based on where bugs are currently open, I suspected that the information on the Oslo Wiki page would be outdated, and updated it accordingly. 2. There was no link to a source repo yet for oslo.log on the Oslo Wiki page, so I added one to the github.com repo. If any of that was a bad idea, please let me know. Andy __ 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] needed, driver for oslo.db thursday session
Thanks Jeremy, Mike, Roman, Victor, Please see remote connection details in: https://etherpad.openstack.org/p/YVR-oslo-db-plans The schedule time for the session is in: https://libertydesignsummit.sched.org/event/3571aa54b364c62e097da8cd32d97258 Hope you can make it :) yes, please pick one of the 2 choices there (either sip or google hangout) and drop a note in the etherpad which one you want me to connect to thanks, dims On Tue, May 19, 2015 at 10:17 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-05-19 09:06:56 -0700 (-0700), Davanum Srinivas wrote: Ouch. Thanks for the heads up Roman We have https://wiki.openstack.org/wiki/Infrastructure/Conferencing which we used yesterday to successfully bridge Clark B. into an I18n tooling session via Jitsi over the normal conference wireless network with the built-in mic/speaker in Jim's laptop. Feel free to use it in your sessions, just try to pick a random conference number between 6000 and 7999 so nobody steps on the toes of other sessions which might be using it (maybe add your conference room number to 6000 or something?). Let me or other Infra people know if you have any questions about or trouble using it! -- Jeremy Stanley __ 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
[openstack-dev] [oslo] Inviting Robert Collins to Oslo core
Hi Team, I'd like to invite Robert Collins (aka lifeless) as an Oslo core. Robert has been a long time contributor to a whole bunch of OpenStack projects and a member of our TC. Robert indicated that he can help across Oslo projects this cycle, so let's please welcome him. Here's my +1. thanks, Dims [1] http://stackalytics.com/?user_id=lifelessrelease=all [2] https://www.openstack.org/foundation/tech-committee/ -- 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] needed, driver for oslo.db thursday session
Mike, Thanks for the heads up. Wow 26 hours. crazy! No worries. we'll make something out of the session and report back -- dims On Tue, May 19, 2015 at 7:24 AM, Mike Bayer mba...@redhat.com wrote: ouch ! maybe next summit will be on the Lost island. another easy place to get to ! :) On 5/19/15 9:08 AM, Roman Podoliaka wrote: Hi all, Just FYI, due to problems with obtaining a Canadian visa, neither Victor Sergeyev, nor I made it to Vancouver. I hope someone else from Oslo team can replace Mike as a session driver. Thanks, Roman On Tue, May 19, 2015 at 3:53 AM, Mike Bayer mba...@redhat.com wrote: Hello - It is my extreme displeasure and frustration to announce that due to an incredibly unfortunate choice of airline, I had to cancel my entire trip to the Openstack summit after spending 26 hours in my home airport waiting for my airline to produce a working airplane (which they did not). I will not be able to attend in person the Thursday oslo.db session I was to drive, so a replacement will be needed. I am also lamenting not being able to meet so many of you who I hoped very much to meet. Hope you all enjoy the summit and I hope our paths can cross at future events. - mike __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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] needed, driver for oslo.db thursday session
Ouch. Thanks for the heads up Roman -- dims On Tue, May 19, 2015 at 6:08 AM, Roman Podoliaka rpodoly...@mirantis.com wrote: Hi all, Just FYI, due to problems with obtaining a Canadian visa, neither Victor Sergeyev, nor I made it to Vancouver. I hope someone else from Oslo team can replace Mike as a session driver. Thanks, Roman On Tue, May 19, 2015 at 3:53 AM, Mike Bayer mba...@redhat.com wrote: Hello - It is my extreme displeasure and frustration to announce that due to an incredibly unfortunate choice of airline, I had to cancel my entire trip to the Openstack summit after spending 26 hours in my home airport waiting for my airline to produce a working airplane (which they did not). I will not be able to attend in person the Thursday oslo.db session I was to drive, so a replacement will be needed. I am also lamenting not being able to meet so many of you who I hoped very much to meet. Hope you all enjoy the summit and I hope our paths can cross at future events. - mike __ 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] [nova-docker] Status update
Adam, Please follow the discussion on the nova-spec review: https://review.openstack.org/#/c/128753/ At the moment, we need folks actively watching the project in terms of reviews, gate/check job failures, keeping up with Nova trunk etc. Please let me know if you or anyone else is interested. thanks, dims On Tue, May 19, 2015 at 10:48 AM, ADAMS, STEVEN E sa2...@att.com wrote: Has there been any decision made on if and when the nova-docker driver will move back to the Nova tree and out of Stackforge? -Steve Adams __ 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] [nova][cinder][neutron][security] Rootwrap discussions at OSSG mid-cycle
Brant, I started work to use rootwrap as daemon in Nova fyi: https://review.openstack.org/#/c/180695/ Don't know if this will help -- dims On Thu, May 14, 2015 at 11:55 AM, Brant Knudson b...@acm.org wrote: On Thu, May 14, 2015 at 2:48 AM, Angus Lees g...@inodes.org wrote: On Wed, 13 May 2015 at 02:16 Thierry Carrez thie...@openstack.org wrote: Lucas Fisher wrote: We spent some time at the OSSG mid-cycle meet-up this week discussing root wrap, looking at the existing code, and considering some of the mailing list discussions. Summary of our discussions: https://github.com/hyakuhei/OSSG-Security-Practices/blob/master/ossg_rootwrap.md The one line summary is we like the idea of a privileged daemon with higher level interfaces to the commands being run. It has a number of advantages such as easier to audit, enables better input sanitization, cleaner interfaces, and easier to take advantage of Linux capabilities, SELinux, AppArmour, etc. The write-up has some more details. For those interested in that topic and willing to work on the next stage, we'll have a work session on the future of rootwrap in the Oslo track at the Design Summit in Vancouver: http://sched.co/3B2B Fwiw, I've continued work on my privsep proposal(*) and how it interacts with existing rootwrap. I look forward to discussing it and alternatives at the session. (*) https://review.openstack.org/#/c/155631 - Gus As part of the OSSG work, I started prototyping changes in Nova where the goal is to 1) Get all the code that's calling rootwrap into one place so that it's easy to find, and get tests for this code. 2) Next (or even in step 1 if it's easy enough), tighten the interfaces, so that rather than providing a function to do chmod %s %s it would only allow whatever chmod nova actually has to do, maybe passing in a server ID rather than a bare file name. With this, we should be able to tighten up the rootwrap filters in the same way, or switch to privsep or whatever we decide to do in the future. So maybe it looks like rearranging deckchairs on the titanic, but in this case the deckchairs are blocking the emergency exits. I didn't get too far in it to even see how viable the approach is since I was working on other things. I'll put this session on my calendar. - Brant __ 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] [nova-docker] [magnum] [nova] Returning nova-docker to Nova Tree
Thanks for this response Daniel!. On Tue, May 12, 2015 at 4:59 AM, Daniel P. Berrange berra...@redhat.com wrote: On Mon, May 11, 2015 at 03:58:59PM -0400, Russell Bryant wrote: On 05/11/2015 03:51 PM, Adrian Otto wrote: I invite Nova and nova-docker team members to join us to discuss this topic, and give us your input. If the Magnum team is interested in helping to maintain it, why not just keep it as a separate repo? What's the real value in bringing it into the Nova tree? Well if that's the question you have to really ask why any of the current drivers are in tree. I don't really think it makes sense to single out Docker for special treatment, requiring them to justify why they want to be in tree. IMHO if we want drivers to live out of tree we should push them all out, if we want drivers to live in tree then we should actively welcome in any driver that has a team of people willing to maintain it, not require justification for wanting to be in tree. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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] [all][oslo] disabling pypy unit test jobs for oslo
requirements jobs are stuck as well :( http://logs.openstack.org/30/170830/6/check/gate-requirements-pypy/732dc33/console.html#_2015-05-11_01_25_22_506 -- dims On Mon, May 11, 2015 at 6:19 AM, Steven Hardy sha...@redhat.com wrote: On Mon, May 11, 2015 at 11:52:13AM +0200, Julien Danjou wrote: On Fri, May 08 2015, Doug Hellmann wrote: The jobs running unit tests under pypy are failing for several Oslo libraries for reasons that have nothing to do with the libraries themselves, as far as I can tell (they pass locally). I have proposed a change to mark the jobs as non-voting [1] until someone can fix them, but we need a volunteer to look at the failure and understand why they fail. Does anyone want to step up to do that? If we don't have a volunteer in the next couple of weeks, I'll go ahead and remove the jobs so we can use those test nodes for other jobs. I'm willing to take a look at those, do you have any link to a review/job that failed? I suspect we're impacted by the same issue for python-heatclient, nearly all of our patches are failing the pypy job, e.g: http://logs.openstack.org/56/178756/4/gate/gate-python-heatclient-pypy/66e4dcc/console.html The error error: option --single-version-externally-managed not recognized looks a lot like bug 1290562 which was closed months ago. I've raised https://bugs.launchpad.net/python-heatclient/+bug/1453095, because I didn't know what component (other than heatclient) this could be assigned to. I'm attempting the bug 1290562 workaround here: https://review.openstack.org/#/c/181851/ If we can't figure out what the problem is, I guess we'll have to temporarily disable our pypy job too, any insights appreciated! :) Steve __ 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] [all][oslo] disabling pypy unit test jobs for oslo
Thanks Sean, filed this review to mark them as non-voting to start with: https://review.openstack.org/181870 -- dims On Mon, May 11, 2015 at 7:51 AM, Sean Dague s...@dague.net wrote: It appears that we've basically run out of interest / time in realistically keeping pypy working in our system. With the focus on really getting python 3.4 working, it seems like it would just be better to drop pypy entirely in the system. In the last couple of years we've not seen any services realistically get to the point of being used for any of the services. And as seen by this last failure, pypy is apparently not keeping up with upstream tooling changes. -Sean On 05/11/2015 06:50 AM, Davanum Srinivas wrote: requirements jobs are stuck as well :( http://logs.openstack.org/30/170830/6/check/gate-requirements-pypy/732dc33/console.html#_2015-05-11_01_25_22_506 -- dims On Mon, May 11, 2015 at 6:19 AM, Steven Hardy sha...@redhat.com wrote: On Mon, May 11, 2015 at 11:52:13AM +0200, Julien Danjou wrote: On Fri, May 08 2015, Doug Hellmann wrote: The jobs running unit tests under pypy are failing for several Oslo libraries for reasons that have nothing to do with the libraries themselves, as far as I can tell (they pass locally). I have proposed a change to mark the jobs as non-voting [1] until someone can fix them, but we need a volunteer to look at the failure and understand why they fail. Does anyone want to step up to do that? If we don't have a volunteer in the next couple of weeks, I'll go ahead and remove the jobs so we can use those test nodes for other jobs. I'm willing to take a look at those, do you have any link to a review/job that failed? I suspect we're impacted by the same issue for python-heatclient, nearly all of our patches are failing the pypy job, e.g: http://logs.openstack.org/56/178756/4/gate/gate-python-heatclient-pypy/66e4dcc/console.html The error error: option --single-version-externally-managed not recognized looks a lot like bug 1290562 which was closed months ago. I've raised https://bugs.launchpad.net/python-heatclient/+bug/1453095, because I didn't know what component (other than heatclient) this could be assigned to. I'm attempting the bug 1290562 workaround here: https://review.openstack.org/#/c/181851/ If we can't figure out what the problem is, I guess we'll have to temporarily disable our pypy job too, any insights appreciated! :) Steve __ 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 -- 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
[openstack-dev] Who is using nova-docker? (Re: [nova-docker] Status update)
Good points, Dan and John. At this point it may be useful to see who is actually using nova-docker. Can folks who are using any version of nova-docker, please speak up with a short description of their use case? Thanks, dims On Mon, May 11, 2015 at 10:06 AM, Dan Smith d...@danplanet.com wrote: +1 Agreed nested containers are a thing. Its a great reason to keep our LXC driver. I don't think that's a reason we should keep our LXC driver, because you can still run containers in containers with other things. If anything, using a nova vm-like container to run application-like containers inside them is going to beg the need to tweak more detailed things on the vm-like container to avoid restricting the application one, I think. IMHO, the reason to keep the seldom-used, not-that-useful LXC driver in nova is because it's nearly free. It is the libvirt driver with a few conditionals to handle different things when necessary for LXC. The docker driver is a whole other nova driver to maintain, with even less applicability to being a system container (IMHO). I am keen we set the right expectations here. If you want to treat docker containers like VMs, thats OK. I guess a remaining concern is the driver dropping into diss-repair if most folks end up using Magnum when they want to use docker. I think this is likely the case and I'd like to avoid getting into this situation again. IMHO, this is not our target audience, it's very much not free to just put it into the tree because meh, some people might like it instead of the libvirt-lxc driver. --Dan __ 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
[openstack-dev] [oslo] Adding Mehdi Abaakouk (sileht) to oslo-core
Dear Oslo folks, I'd like to propose adding Mehdi Abaakouk to oslo-core. He is already leading the oslo.messaging team and helping with Tooz, and futurist efforts. I am hoping to get Mehdi more involved across the board in Oslo. Thanks, Dims -- 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.config] MultiStrOpt VS. ListOpt
ZhiQiang, Please log a bug and we can try to do what jd suggested. -- dims On Wed, May 6, 2015 at 9:21 AM, Julien Danjou jul...@danjou.info wrote: On Wed, May 06 2015, ZhiQiang Fan wrote: I come across a problem that crudini cannot handle MultiStrOpt[1], I don't know why such type configuration option is needed. It seems ListOpt is a better choice. Currently I find lots of MultiStrOpt options in both Nova and Ceilometer, and I think other projects have too. Here are my questions: 1) how can I update such type of option without manually rewrite the config file? (like devstack scenario) 2) Is there any way to migrate MultiStrOpt to ListOpt? The ListOpt will take last specified value while MultiStrOpt takes all, so the compatibility is a big problem Any hints? I didn't check extensively, but this is something I hit regularly. It seems to me we have to two types doing more or less the same things and mapping to the same data structure (i.e. list). We should unify them. -- Julien Danjou // Free Software hacker // http://julien.danjou.info __ 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] Adding Joshua Harlow to oslo-core
+1 from me!! -- dims On Tue, May 5, 2015 at 10:47 AM, Julien Danjou jul...@danjou.info wrote: Hi fellows, I'd like to propose that we add Joshua Harlow to oslo-core. He is already maintaining some of the Oslo libraries (taskflow, tooz…) and he's helping on a lot of other ones for a while now. Let's bring him in for real! -- Julien Danjou -- Free Software hacker -- http://julien.danjou.info __ 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
[openstack-dev] [all] Sign up for oslo liaisons for liberty cycle
[ re-sending an almost identical email from Doug sent just before kilo cycle :) ] The Oslo team is responsible for managing code shared between projects. There are a LOT more projects than Oslo team members, so we created the liaison program at the beginning of the Juno cycle, asking each team that uses Oslo libraries to provide one volunteer liaison. Our liaisons facilitate communication and work with us to make the application code changes needed as code moves out of the incubator and into libraries. With this extra help in place, we were able to successfully graduate 7 new libraries and begin having them adopted across OpenStack. With the change-over to the new release cycle, it’s time to ask for volunteers to sign up to be liaisons again. If you are interested in acting as a liaison for your project, please sign up on the wiki page [1]. It would be very helpful to have a full roster before the summit, so we can make sure liaisons are invited to participate in any relevant discussions there. If you are curious about the current state of planning for Liberty, please peek at [2] and [3]. Thanks, Dims [1] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons [2] https://etherpad.openstack.org/p/liberty-oslo-summit-planning [3] https://libertydesignsummit.sched.org/overview/type/design+summit/Oslo -- 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] [pbr] pbr-release includes oslo-core?
Not sure about the history, but +1 to remove oslo-core from that group. -- dims On Mon, May 4, 2015 at 6:59 PM, Robert Collins robe...@robertcollins.net wrote: Clark and I spotted this when releasing 0.11 - pbr-release, the group of folk that can cut a release, includes oslo-release (expected) and also unexpectedly oslo-core. https://review.openstack.org/#/admin/groups/387,members This means that folk that are olso-core, but can't release regular libraries can release the one special-case library in oslo (pbr, because setup_requires) - this doesn't make sense to me or Clark :). Anyone with insight please shout out now, if we don't hear anything back justifying this, I'll remove oslo-core from pbr-release later this week. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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] [pbr] regular releases, and path to 1.0
+1 to call the current master as 1.0 +1 to more frequent releases (not sure if it should be every monday though!) -- dims On Mon, May 4, 2015 at 3:53 PM, Robert Collins robe...@robertcollins.net wrote: Hi, I'd like to talk about how often we can and should release pbr, and what criteria we should use for 1.0. tl;dr: release weekly [outside of organisation-wide-freezes], do a 1.0 immediately. pbr, like all our libraries affects everything when its released, but unlike everything else in oslo, it is an open ended setup_requires dependency. It's like this because of https://github.com/pypa/pip/issues/2666 - when setuptools encounters a setup_requires constraint that conflicts with an already installed version, it just gives up. Until thats fixed, if we express pbr constraints like pbr 1.0 we'll cause everything that has previously released to hard-fail to install as soon as anything in the environment has pulled in a pbr that doesn't match the constraint. This will get better once we have pip handle setup_requires with more scaffolding... we can in principle get to the point where we can version the pbr setup_requires dependencies. However - thats future, and indefinite at this point. So, for pbr we need to have wide open constraints in setup_requires, and it must be in setup_requires (otherwise pip can't build egg info at all and thus can't probe the install_requires dependencies). The consequence of this is that pbr has to be ultra conservative - we're not allowed any deliberate API breaks for the indefinite future, and even once the tooling supports it we'd have to wait for all the current releases of things that couldn't be capped to semantic versioning limits, to be unsupported. So - we're at least 18 months away from any possible future where API breaks - a 2.0 - are possible without widespread headaches. In light of this, I'd like to make two somewhat related proposals. Firstly, I'd like to just call the current master 1.0: its stable, we're supporting it, its not going anywhere rash, it has its core feature set. Those are the characteristics of 1.0 in most projects :). Its not a big splashy 1.0 but who cares..., and there's more we need, but thats what 1.x is for. Secondly, I'd like to release every Monday (assuming no pending reverts): I'd like to acknowledge the reality that we have approximately zero real world testing of master - we're heavily dependent on our functional tests. The only two reasons to wait for releasing are a) to get more testing, and we don't get that, and b) to let -core notice mistakes and back things out. Waiting to release once an improvement is in master just delays giving the benefits to our users. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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
[openstack-dev] [nova-docker] Status update
Anyone still interested in this work? :) * there's a stable/kilo branch now (see http://git.openstack.org/cgit/stackforge/nova-docker/). * CI jobs are running fine against both nova trunk and nova's stable/kilo branch. * there's an updated nova-spec to get code back into nova tree (see https://review.openstack.org/#/c/128753/) Thanks, dims -- 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] [nova] Proposal to add Melanie Witt to nova-core
+1 from me as well! (Ditto as Ed, not a core). -- dims On Thu, Apr 30, 2015 at 9:00 AM, Ed Leafe e...@leafe.com wrote: On Apr 30, 2015, at 6:30 AM, John Garbutt j...@johngarbutt.com wrote: I propose we add Melanie to nova-core. I know I'm not core, so my vote doesn't count, but I think that this would be a great addition. +1 -- Ed Leafe __ 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] Who is allowed to vote for TC candidates
One concrete suggestion based on my experience working with Kris Lindgren on Heartbeat patch: http://markmail.org/message/gifrt5f3mslco24j I could have added a Co-Tested-By (or Co-Operator - get it? :) in my commit message which would have signaled a concrete contribution/feedback with specific folks in the operator community. This could be done not just for code, could be for reviews or documentation etc as well. WDYT? thanks, dims On Thu, Apr 30, 2015 at 9:06 PM, Adam Lawson alaw...@aqorn.com wrote: I think it's easy to quantify a code contributor since we have systems that monitor activity - who contributed, what they contributed and when. But we don't have a system that monitors operator activity and honestly, that's the question mark for which I really don't have any answers. That might be our first hurdle - how define the difference between a causal user making remarks on the mailing lists and someone who works with the technology and engages. We'd have to quantify them differently somehow. Maybe attending an operators meeting would qualify someone to vote? On Apr 30, 2015 5:35 PM, Stefano Maffulli stef...@openstack.org wrote: On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote: I've seen the number of threads to discuss Ops topics increase in openstack-dev and the influence of Ops - even just points of views inherited from the feedback we've got - on reviews has gotten better as well. Fantastic, that has always been the intention. If it's a matter of having more Ops voting for the TC, we do have a process in place that we could likely improve. Other than that, I believe Thierry and Doug have explained perfectly the issues related to having these 2 groups merged from a *governance* perspective. I noticed that this round of elections we had TC *candidates* that at least I consider more operators than strictly 'dev'. That, to me, is a huge sign of the progress we've made to integrate the two categories. To me the real big question is: how are candidates from the operators side going to get a better chance of being elected next time? And what's the role of the User Committee in all this? /stef __ 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] [Congress] [Murano] Congress devstack installation is failing in murano gate job
So, summarizing some chatter on #openstack-dev: Action item for unblocking the gate job: 1. Remove the -U in the shell script that installs thirdparty-requirements.txt in congress' repo. If that's not enough: 2. make sure congress' stable/kilo requirements.txt/test-requirements.txt is sync'ed with the global stable/kilo. -- dims On Wed, Apr 29, 2015 at 11:32 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Brant Knudson's message of 2015-04-29 09:17:08 -0500: On Wed, Apr 29, 2015 at 9:11 AM, Sean Dague s...@dague.net wrote: On 04/29/2015 10:05 AM, Sean Dague wrote: On 04/29/2015 09:29 AM, Filip Blaha wrote: Hi Serg I checked devstack log [1] and it seems that stevedore==1.4.0 was installed due to congress 2015-04-29 11:12:16.120 http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_16_120 | Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 It is last entry in log mentioning installation stevedore [1] http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz Not, it was installed due to keystonemiddleware - http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_02_13_727 Actually, it's more insideous than this. It's installed at 1.4.0 there, then it's downgraded to 1.3.0 when glance is installed, and then it's pushed back to 1.4.0 because of: http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_08_418 pip install -U should not be used in the general case, only in *very* specific cases. Whatever is hardcoding -U is the source of your problem. -Sean -- Sean Dague http://dague.net There's a review posted to update keystonemiddleware's requirements: https://review.openstack.org/#/c/173972/ . It was broken for a while after the branch was created due to pycadf installing oslo.messaging. For some reason it's working now even without the pycadf changes, but Doug H has a -2 on it. I'd like to know what the reqs are supposed to be for all the stable/kilo libraries -- I assumed we wanted them all to match global-requirements. We're in the process of figuring out how we want to deal with the caps. Adding caps to the requirements of libraries introduces challenges, so we're considering removing those and having applications cap all of their transitive dependencies. We need more time to think about it, and we're going to have a summit session in a couple of weeks, so we're not going to land patches now that we might have to undo later on. We also want to be mindful that changing the requirements of the library may involve breaking semver if we release a new stable version, and we only want to do that once per library if we do it at all. Doug I think all of our tox.ini's have -U: http://git.openstack.org/cgit/openstack/nova/tree/tox.ini#n6 - Brant __ 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] [Congress] [Murano] Congress devstack installation is failing in murano gate job
Perfect. thanks Ruslan. -- dims On Wed, Apr 29, 2015 at 2:47 PM, Ruslan Kamaldinov rkamaldi...@mirantis.com wrote: On Wed, Apr 29, 2015 at 6:46 PM, Davanum Srinivas dava...@gmail.com wrote: So, summarizing some chatter on #openstack-dev: Action item for unblocking the gate job: 1. Remove the -U in the shell script that installs thirdparty-requirements.txt in congress' repo. This patch to Congress stable/kilo resolved the issue with failing job gate-murano-congress-devstack-dsvm: https://review.openstack.org/#/c/178777/ If that's not enough: 2. make sure congress' stable/kilo requirements.txt/test-requirements.txt is sync'ed with the global stable/kilo. -- 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 -- 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] [Congress] [Murano] Congress devstack installation is failing in murano gate job
Serg, The congress stable/kilo requirements: http://git.openstack.org/cgit/openstack/congress/tree/requirements.txt?h=stable/kilo#n13 Do not match the global stable/kilo requirements: http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt?h=stable/kilo#n123 So let's get that fixed first. It may help unblock gate-murano-congress-devstack-dsvm stable/kilo job. -- dims On Wed, Apr 29, 2015 at 9:56 AM, Serg Melikyan smelik...@mirantis.com wrote: Sean, Filip, Exact versions of installed libraries may be found here: http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/pip-freeze.txt.gz stevedore==1.4.0 On Wed, Apr 29, 2015 at 4:38 PM, Filip Blaha filip.bl...@hp.com wrote: sorry I sent wrong link http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz In this log is : Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 Filip On 04/29/2015 03:21 PM, Sean Dague wrote: I just looked at this run (linked in this message) - http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz stevedore==1.3.0 is installed, never 1.4 The failure is completely unrelated to anything there - http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz#_2015-04-12_14_06_25_237 On 04/29/2015 09:12 AM, Serg Melikyan wrote: Hi Filip, In thirdparty-requirements for stable/kilo python-muranoclient should have following version: python-muranoclient=0.5.6,0.6.0. But I am not sure that this will fix the issue, since we don't clearly know why stevedore==1.4.0 is installed. I see that python-keystoneclient does not have cap for stevedore in stable/kilo, but still not 100% that it is a reason why 1.4.0 is installed. [1] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 On Wed, Apr 29, 2015 at 3:46 PM, Filip Blaha filip.bl...@hp.com mailto:filip.bl...@hp.com wrote: Hello We are facing an issue with Congress devstack installation in our gate job testing murano-congress integration (policy enforcement) [1] . Congress devstack scripts install stevedore==1.4.0 as a dependency of python-muranoclient without specified version [2]. However heat requirement in stable/kilo is stevedore=1.3.0,1.4.0 so heat engine is unable to start. Is possible to fix by specifying murano client version not to be in confilct with heat requirements? [1] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/murano.yaml#L42 [2] https://github.com/openstack/congress/blob/stable/kilo/thirdparty-requirements.txt#L4 http://logs.openstack.org/04/171504/6/check/gate-murano-congress-devstack-dsvm/3b2d7e1/logs/devstacklog.txt.gz [3] https://github.com/openstack/heat/blob/stable/kilo/requirements.txt#L47 Filip __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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] Improving OpenStack documentation around RabbitMQ
Michael, Have you seen this? https://github.com/openstack/ha-guide/tree/master/doc/high-availability-guide/ha_aa_rabbitmq That url was built from this github repo: https://github.com/openstack/ha-guide/tree/master/doc/high-availability-guide/ha_aa_rabbitmq There's a weekly meeting for the HA documentation to meet people working on the HA guide: https://wiki.openstack.org/wiki/Meetings#HA_Guide_Update_Meeting Thanks, dims On Tue, Apr 28, 2015 at 9:15 AM, Christian Berendt christ...@berendt.io wrote: Hello Michael. Just moving your thread to the correct mailling list. Sorry for my previous mail. Thunderbird autocompletion used the unsubscribe alias and not the correct mailinglist :( Christian. On 04/28/2015 02:58 PM, Michael Klishin wrote: Hi, I'm a RabbitMQ engineering team member and we'd like to help improve OpenStack docs around it. I've been reading the docs and making notes of what can be improved. We'd be happy to contribute the changes. However, we're not very familiar with the OpenStack development process and have a few questions before we start. As far as I understand, OpenStack Kilo is about to ship. Does this mean we can only contribute documentation improvements for the release after it? Are there maintenance releases that doc improvements could go into? If so, how is this reflected in repository branches? Should the changes we propose be discussed on this list or in GitHub issues [1]? Finally, we are considering adding a doc guide dedicated to OpenStack on rabbitmq.com (we have one for EC2, for instance). Note that we are not looking to replace what's on docs.openstack.org, only provide a guide that can go into more details. Does this sound like a good idea to the OpenStack community? Should we keep everything on docs.openstack.org? Would it be OK if we link to rabbitmq.com guides in any changes we contribute? I don't think OpenStack Juno docs have a lot of external links: is that by design? Thanks. 1. https://github.com/openstack/openstack-manuals -- MK Staff Software Engineer, Pivotal/RabbitMQ __ 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 -- Christian Berendt Cloud Computing Solution Architect Mail: bere...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 __ 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] [magnum] Proposal for Madhuri Kumari to join Core Team
+1 from me. welcome Madhuri! On Tue, Apr 28, 2015 at 11:14 AM, Steven Dake (stdake) std...@cisco.com wrote: Hi folks, I would like to nominate Madhuri Kumari to the core team for Magnum. Please remember a +1 vote indicates your acceptance. A –1 vote acts as a complete veto. Why Madhuri for core? She participates on IRC heavily She has been heavily involved in a really difficult project to remove Kubernetes kubectl and replace it with a native python language binding which is really close to be done (TM) She provides helpful reviews and her reviews are of good quality Some of Madhuri’s stats, where she performs in the pack with the rest of the core team: reviews: http://stackalytics.com/?release=kilomodule=magnum-group commits: http://stackalytics.com/?release=kilomodule=magnum-groupmetric=commits Please feel free to vote if your a Magnum core contributor. Regards -steve __ 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] docker with Juno devstack
Murali, Are you using the juno branch of nova-docker? -- dims On Tue, Apr 28, 2015 at 4:09 AM, Murali B mbi...@gmail.com wrote: Hi I would like to spawn docker image using the devstack. Able to bring-up the devstack with compute_driver = novadocker.virt.docker.DockerDriver. created the .docker image in glance. when I try to create docker image using nova boot --flavor 1 --image image-id --nic net-id=net-id dock command I am seeing the below ^[[01;31m2015-04-27 18:17:12.213 TRACE nova.compute.manager ^[[01;35m[instance: a4752d27-041c-4b5f-b025-cd803343f013] ^[[00mTraceback (most recent call last): ^[[01;31m2015-04-27 18:17:12.213 TRACE nova.compute.manager ^[[01;35m[instance: a4752d27-041c-4b5f-b025-cd803343f013] ^[[00m File /opt/stack/nova/nova/compute/manager.py, line 2303, in _build_resources ^[[01;31m2015-04-27 18:17:12.213 TRACE nova.compute.manager ^[[01;35m[instance: a4752d27-041c-4b5f-b025-cd803343f013] ^[[00myield resources ^[[01;31m2015-04-27 18:17:12.213 TRACE nova.compute.manager ^[[01;35m[instance: a4752d27-041c-4b5f-b025-cd803343f013] ^[[00m File /opt/stack/nova/nova/compute/manager.py, line 2173, in _build_and_run_instance ^[[01;31m2015-04-27 18:17:12.213 TRACE nova.compute.manager ^[[01;35m[instance: a4752d27-041c-4b5f-b025-cd803343f013] ^[[00m flavor=flavor) ^[[01;31m2015-04-27 18:17:12.213 TRACE nova.compute.manager ^[[01;35m[instance: a4752d27-041c-4b5f-b025-cd803343f013] ^[[00m File /usr/local/lib/python2.7/dist-packages/novadocker/virt/docker/driver.py, line 423, in spawn ^[[01;31m2015-04-27 18:17:12.213 TRACE nova.compute.manager ^[[01;35m[instance: a4752d27-041c-4b5f-b025-cd803343f013] ^[[00m 'mem_limit': self._get_memory_limit_bytes(instance), ^[[01;31m2015-04-27 18:17:12.213 TRACE nova.compute.manager ^[[01;35m[instance: a4752d27-041c-4b5f-b025-cd803343f013] ^[[00m File /usr/local/lib/python2.7/dist-packages/novadocker/virt/docker/driver.py, line 336, in _get_memory_limit_bytes ^[[01;31m2015-04-27 18:17:12.213 TRACE nova.compute.manager ^[[01;35m[instance: a4752d27-041c-4b5f-b025-cd803343f013] ^[[00mreturn instance.flavor.memory_mb * units.Mi ^[[01;31m2015-04-27 18:17:12.213 TRACE nova.compute.manager ^[[01;35m[instance: a4752d27-041c-4b5f-b025-cd803343f013] ^[[00mAttributeError: 'Instance' object has no attribute 'flavor' ^[[01;31m2015-04-27 18:17:12.213 TRACE nova.compute.manager ^[[01;35m[instance: a4752d27-041c-4b5f-b025-cd803343f013] ^[[00m 2015-04-27 18:17:12.214 ^[[01;36mAUDIT nova.compute.manager [^[[01;36mreq-d5179c71-527b-45c7-b7ec-3c67a171627c ^[[00;36madmin demo^[[01;36m] ^[[01;35m[instance: a4752d27-041c-4b5f-b025-cd803343f013] ^[[01;36mTerminating instance^[[00m your help is appreciated to overcome this error Thanks -Murali __ 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] [all] Proposed Liberty release schedule
@ttx, +1 from me. -- dims On Mon, Apr 27, 2015 at 8:19 AM, Thierry Carrez thie...@openstack.org wrote: Thierry Carrez wrote: [...] In summary, here is the proposed Liberty common schedule: liberty-1: June 25th liberty-2: July 30th liberty-3: September 3rd final release: October 15th Let me know if you see issues with it, like crazy holidays somewhere that would ruin it. No feedback, so I'm planning to officialize it this week after the TC and Cross-project meeting. Speak now or forever hold your peace ! -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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] So... why exactly? Was: [magnum] Discovery Mechanism For Swarm Bay
Jay, In Paris, we had one spec and zero core. By the time we hit Vancouver, we will have a few scenarios working with 3 milestones. Come vancouver, We'll definitely know for sure if there is appetite and interest in the community for this set of abstractions and packaging we have currently in progress/proposed in the developer/deployer community. Interesting times as they say :) Thanks, dims On Thu, Apr 16, 2015 at 6:21 PM, Jay Pipes jaypi...@gmail.com wrote: On 04/16/2015 05:29 PM, Adrian Otto wrote: This approach addresses all three concerns laid out above. The same approach should apply both to CoreOS and Swarm Bay so the user experience is consistent. So, the above comment got me thinking... why does the user experience need to be consistent? It's not like developers are going to deploy stuff on Docker Swarm *and* Fleet/CoreOS *and* Kubernetes. Developers who want to deploy on container clusters generally have already picked one of them -- Mesos, Kubernetes, Docker Swarm, Fleet, etc. What is the benefit of having an abstraction layer that tries to make the usage of these different developer tools RESTful and consistent? Why wouldn't the developer/deployer simply install Kubernetes or Mesos or Docker Swarm in one or more VMs using Heat/Murano and use the native API of their container cluster orchestration tool of choice? It's a bit like saying that we need to make a SQL-as-a-Service API endpoint that installs multiple database servers into VMs and offers some ANSI SQL via REST API service to communicate with multiple database servers. It just doesn't make any logical sense to me. Database developers want to use the native APIs of their preferred database server, not some lowest-common-denominator SQL over REST interface. Can someone enlighten me please? Best, -jay __ 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] Add request_utils module in oslo-incubator
Abhishek, I'd support picking another existing oslo library instead of oslo-incubator itself. Can you please review to see where this would fit? -- dims On Tue, Apr 14, 2015 at 6:36 AM, Kekane, Abhishek abhishek.kek...@nttdata.com wrote: Hi Devs, Earlier request_utils module was removed from oslo-incubator [1] as it was not used. Now we want to use this module for logging request-id across openstack-services [2]. I have submitted a patch [3] to add request_utils module back to oslo-incubator. If anyone has suggestions please let me know. [1] https://review.openstack.org/#/c/150370/ [2] https://review.openstack.org/#/c/156508/ [3] https://review.openstack.org/#/c/170074/ Thanks Regards, Abhishek Kekane __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. __ 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] [Nova] VMware CI
Gary, John, Just to speed things up, i filed a backport: https://review.openstack.org/#/c/172710/ thanks, dims On Sun, Apr 12, 2015 at 4:23 AM, John Garbutt j...@johngarbutt.com wrote: I have updated the bug so it's high priority and tagged with kilo-rc-potential, and added your note from below as a comment on the bug. It looks like it might be worth a backport so it gets into RC2? Can anyone take that bit on please? Thanks, John On Sunday, April 12, 2015, Gary Kotton gkot...@vmware.com wrote: Hi, Can a core please take a look at https://review.openstack.org/#/c/171037. The CI is broken due to commit e7ae5bb7fbdd5b79bde8937958dd0a645554a5f0. Thanks Gary __ 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
[openstack-dev] [Oslo] Common Libraries PTL Candidacy
Hi Everyone, After shadowing Doug for a while, It's going to be a really hard job filling Doug's shoes. I am very thankful and very glad we had him so long to guide us. I'd like to continue his good work going forward. We've achieved a lot last couple of cycles, and the proof is the almost empty oslo-incubator and the numerous libraries that we have shipped. There is a lot of work yet to be done in adoption of our oslo libraries in Liberty and beyond. We now have a good handle on the release process, working with our CI, stable branches etc. We should figure out how to help other projects pick up lessons we learned as well. I'd also like to concentrate on getting more participation and expertise in some of our really critical projects like oslo.messaging, oslo.db etc. We have some very good solutions like Taskflow which could use some help with adoption in existing projects like Nova. I'd like to figure out how to do that as well. If you would like to have me as your PTL, i'd need your help and patience to make things happen :) Thanks, 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] not running for PTL for liberty cycle
Many Many thanks for all the great work and leadership Doug! -- dims On Fri, Apr 3, 2015 at 8:50 AM, Doug Hellmann d...@doughellmann.com wrote: Team, I have decided not to run for PTL for Oslo for the next cycle. Serving as PTL for the last three releases has been a rewarding experience, and I think we’ve made some great strides together as a team. Now it’s time for me to step down and let someone else take the lead position. I am still committed to the mission, and I will be contributing to Oslo, but I do also want to work on some other projects that I won’t have time for if I stay in the PTL role. We have several good candidates for PTL on the team, and I expect us to have no trouble finding someone willing to step up and run. Thanks, Doug __ 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] [nova] meaning of 'Triaged' in bug tracker
+1 Sean! On Mon, Mar 30, 2015 at 10:00 AM, Sean Dague s...@dague.net wrote: I've been attempting to clean up the bug tracker, one of the continued inconsistencies that are in the Nova tracker is the use of 'Triaged'. https://wiki.openstack.org/wiki/BugTriage If the bug contains the solution, or a patch, set the bug status to Triaged In OpenStack the Triaged state means the solution is provided in the bug at enough specification that a patch can be spun. We're ignoring the Launchpad language here specifically. We had about 180 bugs in Triaged this morning, some untouched for 2 years. I'm moving everything that looks valid without a solution to 'Confirmed'. A bunch of other issues look like they can be invalidated in the process (through code greps). In future, please be careful about putting things into Triaged that don't have a solution. Triaged should always end up as a pretty small number of things. -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] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver
+1 to keep it together. -- dims On Tue, Mar 24, 2015 at 12:17 PM, Flavio Percoco fla...@redhat.com wrote: On 24/03/15 11:03 -0500, Ben Nemec wrote: On 03/24/2015 10:31 AM, Li Ma wrote: On Mon, Mar 23, 2015 at 9:24 PM, Doug Hellmann d...@doughellmann.com wrote: The goal we set at the Kilo summit was to have a group of people interested in zmq start contributing to the driver, and I had hoped to the library overall. How do we feel that is going? That sounds great. I hope so. One way to create a separate group to manage the zmq driver is to move it to a separate repository. Is the internal API for messaging drivers stable enough to do that? Actually I'm not intended to move it to a separate repository. I just want to make sure if it is possible to make a fixed online meeting for zmq driver. And personally I'd prefer not to split the repo. I'd rather explore the idea of driver maintainers whose +1 on driver code counts as +2, like we had/have with incubator. Splitting the repo brings up some sticky issues with requirements syncs and such. I'd like to think that with only three different drivers we don't need the overhead of managing separate repos, but maybe I'm being optimistic. :-) Kind of off topic since that's not what is being proposed here, but two different people have mentioned it so I wanted to note my preference in case it comes up again. +1 I don't think this needs to be split if the only thing needed is some extra grants. However, this is not to be forgotten in the long run where more complex scenarious may appear. Cheers, Flavio -- @flaper87 Flavio Percoco __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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][TaskFlow] Proposal for new core reviewer (min pae)
+1 from me. -- dims On Mon, Mar 23, 2015 at 4:58 PM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Joshua Harlow's message of 2015-03-23 10:40:09 -0700: Greetings all stackers, I propose that we add Min Pae[1] to the taskflow-core team[2]. Min has been actively contributing to taskflow for a while now, both in helping prove taskflow out (by being a user via the project that he is using it in @ https://wiki.openstack.org/wiki/Cue) and helping with the review load when he can. He has provided quality reviews and is doing an awesome job with the various taskflow concepts and helping make taskflow the best library it can be! Overall I think he would make a great addition to the core review team. Please respond with +1/-1. Thanks much! Min Pae's review stats look a little low, but after talking with Josh I'm comfortable with the amount of discussion and helping that has happened outside of existing reviews. The usual process is to give nominations a week to collect comments, so let's do that. Doug __ 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] [Nova] Liberty specs are now open
Neil, yes, see example - https://review.openstack.org/#/c/155116/ - you file against the /approved directory -- dims On Fri, Mar 20, 2015 at 2:41 PM, Neil Jerram neil.jer...@metaswitch.com wrote: Neil Jerram neil.jer...@metaswitch.com writes: Hi Michael, Michael Still mi...@stillhq.com writes: For specs approved in Juno or Kilo, there is a fast track approval process for Liberty. The steps to get your spec re-approved are: - Copy your spec from the specs/oldrelease/approved directory to the specs/liberty/approved directory. [...] Perhaps I'm misunderstanding, or have failed to pull the latest nova-specs repo correctly, but I don't see a specs/liberty/approved directory. Do you mean just specs/liberty ? Ah, I guess the intention may be that a proposed spec patch would _create_ the specs/liberty/approved directory. Is that right? Neil __ 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.config][kolla] modular backends for oslo.cfg
Chmouel, Nice! Ben added a topic Alternative file formats for oslo.config for Liberty[1]. this would be great if we can talk about alternative backends as well :) -- dims [1] https://etherpad.openstack.org/p/liberty-oslo-summit-planning On Thu, Mar 19, 2015 at 8:31 AM, Chmouel Boudjnah chmo...@chmouel.com wrote: Hello, While on a long oversea flight with Sebastien Han we were talking how he had implemented ceph-docker with central configuration over etcd. We quickly came up to the conclusion that if we wanted to have that in Kolla it would be neat if it was done straight from oslo.config so that would quickly override the default keys in a central point. There is multiple advantage to use that method not just for containers but as well to avoid issues when orchestrating an openstack deployment. I have heard arguments that this should be the job of an ansible/puppet/chef tool and while I completely agree I just don't think it has to write to files the tool would just write to the etcd database. I have quickly came up with a quick and dirty POC on oslo.cfg here : https://github.com/chmouel/oslo.config/commit/01ee54dd5219b1434eaac422055b58e77694d89f and the demo : https://gist.github.com/chmouel/05fb715f96344161268c What others thinks about it ? I believe if we wanted to do that we would have to add a stevesdor based modular backend support directly to oslo.cfg first and have an etcd backend implemented. Chmouel PS: I am using etcd here cause it's easy and fancy but this could be any backends like a DB/NoSQL/Swift or whatever if we wanted __ 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] oslo.concurrency runtime dependency on fixtures/testtools
Alan, We are debating this on: https://review.openstack.org/#/c/157135/ Please hop on :) -- dims On Thu, Mar 12, 2015 at 5:28 AM, Alan Pevec ape...@gmail.com wrote: Hi, hijacking this thread to point out something that feels wrong in the dependency chain which jumped out: Colecting testtools=0.9.22 (from fixtures=0.3.14-oslo.concurrency=1.4.1-keystone==2015.1.dev395) fixtures is imported in oslo_concurrency/fixture/lockutils.py but that's not really used at _runtime_ Cheers, Alan __ 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] Deprecation warnings considered harmful?
Thanks for shining the light everyone, https://review.openstack.org/#/c/163756/ Please if you see more let us know (#openstack-oslo or launchpad) ASAP. -- dims On Thu, Mar 12, 2015 at 6:38 AM, Boris Bobrov bbob...@mirantis.com wrote: On Thursday 12 March 2015 12:59:10 Duncan Thomas wrote: So, assuming that all of the oslo depreciations aren't going to be fixed before release What makes you think that? In my opinion it's just one component's problem. These particular deprecation warnings are a result of still on-going migration from oslo.package to oslo_package. Ironically, all components except oslo have already moved to the new naming scheme. I think that these warnings are just a single, not systemic problem. for something we know about at release time? For bugs we know about at release time we have bugreports. Filing a bug is pretty easy ;) https://bugs.launchpad.net/oslo.db/+bug/1431268 On 12 March 2015 at 11:41, Boris Bobrov bbob...@mirantis.com wrote: On Thursday 12 March 2015 12:24:57 Duncan Thomas wrote: ubuntu@devstack-multiattach:~/devstack$ cinder-manage db sync /usr/local/lib/python2.7/dist-packages/oslo_db/_i18n.py:19: DeprecationWarning: The oslo namespace package is deprecated. Please use oslo_i18n instead. from oslo import i18n /opt/stack/cinder/cinder/openstack/common/policy.py:98: DeprecationWarning: The oslo namespace package is deprecated. Please use oslo_config instead. from oslo.config import cfg /opt/stack/cinder/cinder/openstack/common/policy.py:99: DeprecationWarning: The oslo namespace package is deprecated. Please use oslo_serialization instead. from oslo.serialization import jsonutils /opt/stack/cinder/cinder/objects/base.py:25: DeprecationWarning: The oslo namespace package is deprecated. Please use oslo_messaging instead. from oslo import messaging /usr/local/lib/python2.7/dist-packages/oslo_concurrency/openstack/common/ fi leutils.py:22: DeprecationWarning: The oslo namespace package is deprecated. Please use oslo_utils instead. from oslo.utils import excutils What are normal, none developer users supposed to do with such warnings, other than: a) panic or b) Assume openstack is beta quality and then panic Non developer users are supposed to file a bug, leave installation and usage to professional devops who know how to handle logs or and stop using non- stable branch. -- С наилучшими пожеланиями, Boris _ _ 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 -- С наилучшими пожеланиями, Boris __ 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] [Openstack-operators] [all][qa][gabbi][rally][tempest] Extend rally verfiy to unify work with Gabbi, Tempest and all in-tree functional tests
Boris, 1. Suppose a project say Nova wants to enable this Rally Integration for its functional tests, what does that project have to do? (other than the existing well defined tox targets) 2. Is there a test project with Gabbi based tests that you know of? 3. What changes if any are needed in Gabbi to make this happen? Guessing going forward, we can setup weekly Rally jobs against different projects so we can compare performance over time etc? thanks, dims On Fri, Mar 6, 2015 at 6:47 PM, Boris Pavlovic bo...@pavlovic.me wrote: Hi stackers, Intro (Gabbi) - Gabbi is amazing tool that allows you to describe in human readable way what API requests to execute and what you are expecting as a result. It Simplifies a lot API testing. It's based on unittest so it can be easily run using tox/tester/nose and so on.. Intro (Functional in-tree tests) --- Keeping all tests in one project like Tempest, that is maintained by one team, was not enough scalable approach. To scale things, projects started maintaining their own functional tests in their own tree. This resolves scale issues and now new features can be merged with functional tests. The Problem - As far as you know there are a lot of OpenStack projects with their own functional tests / gabbi tests in tree. It becomes hard for developers, devops and operators to work with them. (Like it's hard to install OpenStack by hands without DevStack. ) Usually, end users are choosing 2 approach: 1) Make own tests 2) Make scripts that runs somehow all these tests Small Intro (Rally) Rally idea is to make tool that simplifies all kinds of testing of multiple OpenStack clouds. It should be for human and as well simple to integrated in CI/CD process. Rally automates all testing process (managing testing systems / running tests / storing results / working with results) At this moment there are 3 major parts: *) deployment - manages OpenStack deployments (creates or uses existing) *) verify - manages fully tempest (installs/configurtion/running/parsing output/storing results/working with results) *) task - own rally testing framework that allows you to do all kinds of testing functional/load/performance/scale/load/volume and others. I can say that rally verify command that automates work with Tempest is very popular. More details here: https://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/ Proposal to make the life better -- Recently Yair Fried and Prasanth Anbalagan proposed a great idea to extend rally verify command to add ability to run in-tree functional tests in the same way as tempest. In other words to have next syntax: rally verify project command Something like this: rally verify swift start # 1. Check is installed swift for active rally deployment. # IF NO: # Downloads from default (our specified place) swift # Switch to master or specified tag # Installs in venv swift # Configure swift functional test config for active deployment # 2. Run swift functional test # 3. Parse subunit output and store to Rally DB (for future work) rally verify swift list # List all swift verification runs rally verify swift show UUID# Shows results rally verify swift compare UUID1 UUID2 # Compare results of two runs Why it makes sense? 1) Unification of testing process. There is a simple to learn set of command rally verify project cmd that works for all projects in the same way. End users like such things=) 2) Simplification of testing process. rally verify project start - will automate all steps, so you won't need to install project manually, and configure functional test, collect and somewhere store results. 3) Avoiding duplication of effort We don't need to implement part of rally verify functionality in every project. It is better to implement it in one place with plugin support. Adding new project means implementing new plugin (in most case it will be just functional test conf generation) 4) Reusing already existing code Most of the code that we need is already implemented in Rally, it requires just small refactoring and generalization. Thoughts? Best regards, Boris Pavlovic ___ OpenStack-operators mailing list openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- Davanum Srinivas :: https://twitter.com/dims
[openstack-dev] oslo.config 1.9.2 release
The Oslo team is pumped to announce the release of: oslo.config 1.9.2: Oslo Configuration API For more details, please see the git log history below and: http://launchpad.net/oslo.config/+milestone/1.9.2 Please report issues through launchpad: http://bugs.launchpad.net/oslo.config Changes in oslo.config 1.9.1..1.9.2 --- dc28858 print better message when choices has an empty string 9db5247 None in config choices breaks oslo-config-generator Diffstat (except docs and test files) - oslo_config/generator.py| 11 ++- 4 files changed, 37 insertions(+), 5 deletions(-) -- 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] [horizon] Do No Evil
Possibly a better venue would be the legal-discuss@ mailing list? -- dims On Sat, Mar 7, 2015 at 12:57 PM, Michael Krotscheck krotsch...@gmail.com wrote: On Sat, Mar 7, 2015 at 8:15 AM Ian Wells ijw.ubu...@cack.org.uk wrote: With apologies for derailing the question, but would you care to tell us what evil you're planning on doing? I find it's always best to be informed about these things. Me? What? Me? Evil? None, of course. Nope. Nothing at all. Do not look behind the curtain. If someone like BigEvilCorp wanted to install Horizon though, and saw that we used tooling that included a do no evil license in it? Lawyers get touchy, so do governments. There's some discussion on this here that suggests no small amount of consternation: https://github.com/jshint/jshint/issues/1234 The actual license in question. https://github.com/jshint/jshint/blob/master/src%2Fjshint.js (Why yes, it *is* a Saturday morning.) Anyone wanna hack on a bower mirror puppet module with me? Michael __ 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] [nova][ec2-api] Functional tests for EC2-API in nova
Alex, It's better do a experimental one first before trying to a non-voting: http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml#n1509 -- dims On Mon, Mar 2, 2015 at 7:24 AM, Alexandre Levine alev...@cloudscaling.com wrote: All, We've finished setting up the functional testing for the stackforge EC2 API project. New test suite consists of 96 API and scenario tests covering almost (tags functionality and client tokens absent) all of the functionality initially covered by original EC2 API tests in Tempest and much more. Also this test suite is periodically run against AWS to ensure its compatibility with Amazon. Now it works as a gating for this standalone EC2 API project, however the question is: Does it make sense and do we want to somehow employ this test suite against nova's API (without VPC-related tests, which leaves 54 tests altogether)? Internally we did this and it seems that nova's EC2 API is sound enough (it still does what it did, say, a year ago), however it's still quite short of some features and compatibility. So our tests run against it produce the following results: With nova-network: http://logs.openstack.org/02/160302/1/check/check-functional-nova-network-dsvm-ec2api/ab1af0d/console.html With neutron: http://logs.openstack.org/02/160302/1/check/check-functional-neutron-dsvm-ec2api/f478a19/console.html And the review which we used to run the tests: https://review.openstack.org/#/c/160302/ So if we do want to somehow set this up against nova's EC2 API, I'm not sure how to most effectively do this. Non-voting job in Nova fetching tests from stackforge/ec2-api and running them as we did in the review above? Best regards, Alex Levine __ 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] Ideas about Openstack Cinder for GSOC 2015
Harry, hop on to #openstack-gsoc and #openstack-cinder as well. -- dims On Fri, Feb 27, 2015 at 9:26 AM, Anne Gentle annegen...@justwriteclick.com wrote: Hi Harry, I don't see a cinder mentor listed but you could certainly contact the Project Technical Lead for Cinder, Mike Perez, and see if he knows of a mentor and possible project. Anne On Fri, Feb 27, 2015 at 3:50 AM, harryxiyou harryxi...@gmail.com wrote: Hi all, I cannot find the proper idea about Openstack Cinder for GSOC 2015 here[1]. Could anyone please give me some clues? [1] https://wiki.openstack.org/wiki/GSoC2015 Thanks, Harry __ 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 -- Anne Gentle annegen...@justwriteclick.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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][openstackclient] transferring maintenance of cliff to the OpenStack client team
+1 to the move! On Feb 26, 2015 6:43 PM, Ben Nemec openst...@nemebean.com wrote: On 02/26/2015 03:57 PM, Doug Hellmann wrote: The team behind the unified command line tool is preparing to ask the TC to allow us to become an official team. The openstack/python-openstackclient repository will be managed by this new team, and I suggested we also consider transferring ownership of openstack/cliff from Oslo at the same time. Cliff was created specifically to meet the needs to python-openstackclient, and it is still primarily maintained by folks who will be members of the new team. Some projects outside of OpenStack have adopted it, so I think it makes sense to keep it as a separate repository and continue to release it that way (Oslo doesn’t have to be the only project team to do that, after all). Dean will be submitting a governance change to create the new program, but before we do that I wanted to get general feedback from the team about the ownership change. We’ll repeat what we did with PyCADF and hacking when we transferred those, and offer anyone in oslo-core the chance to continue reviewing cliff code if they want to be on the cliff-core team. Please let me know if you have objections or comments. Makes sense to me. +1 to the move. Thanks, Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][oslo] Dealing with database connection sharing issues
+1 to fix Oslo's service module any ways, irrespective of this bug. +1 to The db library shouldn't be concerned with whether or not it's in a forked process -- that's not its job -- dims On Fri, Feb 20, 2015 at 10:17 AM, Doug Hellmann d...@doughellmann.com wrote: On Thu, Feb 19, 2015, at 09:45 PM, Mike Bayer wrote: Doug Hellmann d...@doughellmann.com wrote: 5) Allow this sort of connection sharing to continue for a deprecation period with apppropriate logging, then make it a hard failure. This would provide services time to find and fix any sharing problems they might have, but would delay the timeframe for a final fix. 6-ish) Fix oslo-incubator service.py to close all file descriptors after forking. I'm not sure why 6 is slower, can someone elaborate on that? So, option “A”, they call engine.dispose() the moment they’re in a fork, the activity upon requesting a connection from the pool is: look in pool, no connections present, create a connection and return it. This feels like something we could do in the service manager base class, maybe by adding a post fork hook or something. Josh's patch to forcibly close all file descriptors may be something else we want, but if we can reset open connections cleanly when we know how, that feels better than relying on detecting broken sockets. Option “5”, the way the patch is right now to auto-invalidate on detection of new fork, the activity upon requesting a connection is from the pool is: look in pool, connection present, check that os.pid() matches what we’ve associated with the connection record, if not, we raise an exception indicating “invalid”, this is immediately caught, sets the connection record as “invalid”, the connection record them immediately disposes that file descriptor, makes a new connection and returns that. Option “6”, the new fork starts, the activity upon requesting a connection from the pool is: look in pool, connection present, perform the oslo.db “ping” event, ping event emits “SELECT 1” to the MySQLdb driver, driver attempts to emit this statement on the socket, socket communication fails, MySQLdb converts to an exception, exception is raised, SQLAlchemy catches the exception, sends it to a parser to determine the nature of the exception, we see that it’s a “disconnect” exception, we set the “invalidate” flag on the exception, we re-raise, oslo.db’s exc_filters then catch the exception, more string parsers get involved, we determine we need to raise an oslo.db.DBDisconnect exception, we raise that, the “SELECT 1” ping handler catches that, we then emit “SELECT 1” again so that it reconnects, we then hit the connection record that’s in “invalid” state so it knows to reconnect, it reconnects and the “SELECT 1” continues on the new connection and we start up. So essentially option “5” (the way the gerrit is right now) has a subset of the components of “6”; “6” has the additional steps of: emit a doomed statement on the closed socket, then when it fails raise / catch / parse / reraise / catch / parse / reraise that exception. Option “5” just has, check the pid, raise / catch an exception. IMO the two options are: “5”, check the pid and recover or “3” make it a hard failure. And I don't think we want the database library doing anything with this case at all. Recovery code is tricky, and often prevents valid use cases (perhaps the parent *meant* for the child to reuse the open connection and isn't going to continue using it so there won't be a conflict). The bug here is in the way the application, using Oslo's service module, is forking. We should fix the service module to make it possible to fork correctly, and to have that be the default behavior. The db library shouldn't be concerned with whether or not it's in a forked process -- that's not its job. Doug __ 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] [magnum] Propose removing Dmitry Guryanov from magnum-core
-1 On Tue, Feb 17, 2015 at 12:19 AM, Steven Dake (stdake) std...@cisco.com wrote: -1 From: Steven Dake std...@cisco.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, February 16, 2015 at 8:20 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: [openstack-dev] [magnum] Propose removing Dmitry Guryanov from magnum-core The initial magnum core team was founded at a meeting where several people committed to being active in reviews and writing code for Magnum. Nearly all of the folks that made that initial commitment have been active in IRC, on the mailing lists, or participating in code reviews or code development. Out of our core team of 9 members [1], everyone has been active in some way except for Dmitry. I propose removing him from the core team. Dmitry is welcome to participate in the future if he chooses and be held to the same high standards we have held our last 4 new core members to that didn’t get an initial opt-in but were voted in by their peers. Please vote (-1 remove, abstain, +1 keep in core team) - a vote of +1 from any core acts as a veto meaning Dmitry will remain in the core team. [1] https://review.openstack.org/#/admin/groups/473,members __ 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] [Magnum] Scheduling for Magnum
I second that. my first instinct is the same as Steve. -- dims On Sat, Feb 7, 2015 at 1:24 PM, Steven Dake (stdake) std...@cisco.com wrote: From: Eric Windisch e...@windisch.us Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Saturday, February 7, 2015 at 10:09 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Magnum] Scheduling for Magnum 1) Cherry pick scheduler code from Nova, which already has a working a filter scheduler design. 2) Integrate swarmd to leverage its scheduler[2]. I see #2 as not an alternative but possibly an also. Swarm uses the Docker API, although they're only about 75% compatible at the moment. Ideally, the Docker backend would work with both single docker hosts and clusters of Docker machines powered by Swarm. It would be nice, however, if scheduler hints could be passed from Magnum to Swarm. Regards, Eric Windisch Adrian Eric, I would prefer to keep things simple and just integrate directly with swarm and leave out any cherry-picking from Nova. It would be better to integrate scheduling hints into Swarm, but I’m sure the swarm upstream is busy with requests and this may be difficult to achieve. Regards -steve __ 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] [infra][project-config][oslo.messaging] Pre-driver requirements split-up initiative
Sounds good to me Doug. +1 for a spec since this will affect every project. -- dims On Fri, Feb 6, 2015 at 11:12 AM, Doug Hellmann d...@doughellmann.com wrote: On Fri, Feb 6, 2015, at 07:37 AM, Denis Makogon wrote: Hello to All. As part of oslo.messaging initiative to split up requirements into certain list of per messaging driver dependencies https://review.openstack.org/#/c/83150/ it was figured that we need to find a way to use pip inner dependencies and we were able to do that, short info our solution and how it works: - This is how regular requirements.txt looks: dep1 … dep n - This is how looks requirements.txt with inner dependencies: dep1 -r somefolder/another-requirements.txt -r completelyanotherfolder/another-requirements.txt … dep n That’s what we’ve did for oslo.messaging. But we’ve faced with problem that was defined as openstack-infra/project-config tool issue, this tool called project-requirements-change https://github.com/openstack-infra/project-config/blob/master/jenkins/scripts/project-requirements-change.py .As you can see it’s not able to handle inner dependencies in any of requirements.txt files, as you can see this tool expects to parse only explicit set of requirements (see regular requirements.txt definition above). So, i decided to fix that tool to make it able to look over inner dependencies, and here’s https://review.openstack.org/#/c/153227/ what i have for yesterday, Taking into account suggestion from Monty Taylor i’m bringing this discussion to much wider audience. And the question is: aren’t we doing something complex or are there any less complex ways to accomplish the initial idea of splitting requirements? After re-reading this message, and discussing it with a few folks in the infra channel on IRC, I'm a little concerned that we don't have enough background to fully understand the problem and proposed solution. bnemec pointed out that the discussion happened before we had the spec process, but now that we do have that process I think the best next step is to have a spec written in oslo-specs describing the problem we're trying to solve and the approaches that were discussed. This may really just be summarizing the existing discussions, but let's get all of that information into a single document before we go any further. Doug Kind regards, Denis M. IRC: denis_makogon at Freenode __ 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] [nova] stuck patches at the nova IRC meeting
LOL :) -- dims On Thu, Feb 5, 2015 at 4:22 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 2/5/2015 10:54 AM, Sean Dague wrote: On 02/05/2015 11:50 AM, Daniel P. Berrange wrote: On Thu, Feb 05, 2015 at 10:42:48AM -0600, Ed Leafe wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/2015 09:02 AM, Alexis Lee wrote: May I suggest stricter moderation? EG a short phase to propose items, then work through them 1 by 1. Or, we take items one by one according to who shouts fastest but ask people not to interrupt. Or how about going through the ones listed on the agenda, rather than having a free-for-all shouting match? Indeed, I thought that was the whole point of putting them in the agenda in the first place :-) Agreed, I think it just got away from us today with lots of first time attendees. We'll just have to be a little clearer next time. -Sean Lots of first time attendees on the day of feature freeze? Weird... -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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] [OpenStack Foundation] Finding people to work on the EC2 API in Nova
Alexandre, very cool. Next step would be what we call a dsvm job that uses this devstack hook. Example i am most familiar is is nova-docker's check-tempest-dsvm-docker job: https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/nova-docker.yaml (also see zuul/layout.yaml) thanks, dims On Thu, Feb 5, 2015 at 7:01 AM, Alexandre Levine alev...@cloudscaling.com wrote: Davanum, We've added the devstack support. It's in our stackforge repository. https://github.com/stackforge/ec2-api/tree/master/contrib/devstack Best regards, Alex Levine On 1/31/15 2:21 AM, Davanum Srinivas wrote: Alexandre, Randy, Are there plans afoot to add support to switch on stackforge/ec2-api in devstack? add tempest tests etc? CI Would go a long way in alleviating concerns i think. thanks, dims On Fri, Jan 30, 2015 at 1:24 PM, Bias, Randy randy.b...@emc.com wrote: As you know we have been driving forward on the stack forge project and it¹s our intention to continue to support it over time, plus reinvigorate the GCE APIs when that makes sense. So we¹re supportive of deprecating from Nova to focus on EC2 API in Nova. I also think it¹s good for these APIs to be able to iterate outside of the standard release cycle. --Randy VP, Technology, EMC Corporation Formerly Founder CEO, Cloudscaling (now a part of EMC) +1 (415) 787-2253 [google voice] TWITTER: twitter.com/randybias LINKEDIN: linkedin.com/in/randybias ASSISTANT: ren...@emc.com On 1/29/15, 4:01 PM, Michael Still mi...@stillhq.com wrote: Hi, as you might have read on openstack-dev, the Nova EC2 API implementation is in a pretty sad state. I wont repeat all of those details here -- you can read the thread on openstack-dev for detail. However, we got here because no one is maintaining the code in Nova for the EC2 API. This is despite repeated calls over the last 18 months (at least). So, does the Foundation have a role here? The Nova team has failed to find someone to help us resolve these issues. Can the board perhaps find resources as the representatives of some of the largest contributors to OpenStack? Could the Foundation employ someone to help us our here? I suspect the correct plan is to work on getting the stackforge replacement finished, and ensuring that it is feature compatible with the Nova implementation. However, I don't want to preempt the design process -- there might be other ways forward here. I feel that a continued discussion which just repeats the last 18 months wont actually fix the situation -- its time to break out of that mode and find other ways to try and get someone working on this problem. Thoughts welcome. Michael -- Rackspace Australia ___ Foundation mailing list foundat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation __ 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] [nova][libvirt] Logging interactions of libvirt + QEMU in Nova
Daniel, Kashyap, One question that came up on IRC was, how/where to configure say a directory where core dumps from qemu would end up. Sean was seeing a scenario where he noticed a core dump from qemu in dmesg/syslog and was wondering how to specify a directory to capture a core dump if/when it occurs. thanks, dims On Wed, Feb 4, 2015 at 8:48 AM, Kashyap Chamarthy kcham...@redhat.com wrote: On Wed, Feb 04, 2015 at 10:27:34AM +, Daniel P. Berrange wrote: On Wed, Feb 04, 2015 at 11:23:34AM +0100, Kashyap Chamarthy wrote: Heya, I noticed a ping (but couldn't respond in time) on #openstack-nova IRC about turning on logging in libvirt to capture Nova failures. This was discussed on this list previously by Daniel Berrange, just spelling it out here for reference and completness' sake. (1) To see the interactions between libvirt and QEMU, in /etc/libvirt/libvirtd.conf, have these two config attributes: . . . log_filters=1:libvirt 1:qemu 1:conf 1:security 3:event 3:json 3:file 1:util You really want 3:object in there /before/ 1:util too otherwise you'll be spammed with object ref/unref messages Thanks for this detail. log_outputs=1:file:/var/tmp/libvirtd.log Use /var/log/libvirt/libvirtd.log instead of /var/tmp Ah, yeah, it was an incorrect copy/paste. -- /kashyap __ 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] [nova][libvirt] Logging interactions of libvirt + QEMU in Nova
Daniel, The last tip on this page possibly? http://wiki.stoney-cloud.org/wiki/Debugging_Qemu -- dims On Wed, Feb 4, 2015 at 11:18 AM, Daniel P. Berrange berra...@redhat.com wrote: On Wed, Feb 04, 2015 at 11:15:18AM -0500, Davanum Srinivas wrote: Daniel, Kashyap, One question that came up on IRC was, how/where to configure say a directory where core dumps from qemu would end up. Sean was seeing a scenario where he noticed a core dump from qemu in dmesg/syslog and was wondering how to specify a directory to capture a core dump if/when it occurs. That's really outside the scope of libvirt. On Fedora/RHEL there is the abrt program, which captures core dumps from any process in the entire OS and has configurable actions for where to save them. IIUC Ubuntu has some general purpose core dump handler too but I don't know much about it myself. They all work by hooking into the kernel's core_pattern sysctl knob to redirect core dumps to their own binary instead of using $CWD Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- 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][nova][cinder] removing request_utils from oslo-incubator
Doug, So the ball is in the Nova core(s) court? -- dims On Wed, Feb 4, 2015 at 12:16 PM, Doug Hellmann d...@doughellmann.com wrote: About 12 hours ago in #openstack-oslo ankit_ag asked about the request_utils module that was removed from oslo-incubator and how to proceed to get it into nova. The module was deleted a few days ago [1] because nothing was actually using it and it appeared to be related to a nova blueprint [2], the spec for which was abandoned at the end of juno [3]. The one copy that had been synced into cinder wasn’t being used, and was also deleted [4] as part of this housekeeping work. As I said in the review, we removed the code from the incubator because it appeared to be a dead end. If that impression is incorrect, we should get the spec and blueprint resurrected (probably as a cross-project spec rather than just in nova) and then we can consider the best course for proceeding with the implementation. Doug [1] https://review.openstack.org/#/c/150370/ [2] https://blueprints.launchpad.net/nova/+spec/log-request-id-mappings [3] https://review.openstack.org/#/c/106878/ [4] https://review.openstack.org/#/c/150369/ __ 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] [OpenStack Foundation] Finding people to work on the EC2 API in Nova
Alex, Very cool. thanks. -- dims On Sat, Jan 31, 2015 at 1:04 AM, Alexandre Levine alev...@cloudscaling.com wrote: Davanum, Now that the picture with the both EC2 API solutions has cleared up a bit, I can say yes, we'll be adding the tempest tests and doing devstack integration. Best regards, Alex Levine On 1/31/15 2:21 AM, Davanum Srinivas wrote: Alexandre, Randy, Are there plans afoot to add support to switch on stackforge/ec2-api in devstack? add tempest tests etc? CI Would go a long way in alleviating concerns i think. thanks, dims On Fri, Jan 30, 2015 at 1:24 PM, Bias, Randy randy.b...@emc.com wrote: As you know we have been driving forward on the stack forge project and it¹s our intention to continue to support it over time, plus reinvigorate the GCE APIs when that makes sense. So we¹re supportive of deprecating from Nova to focus on EC2 API in Nova. I also think it¹s good for these APIs to be able to iterate outside of the standard release cycle. --Randy VP, Technology, EMC Corporation Formerly Founder CEO, Cloudscaling (now a part of EMC) +1 (415) 787-2253 [google voice] TWITTER: twitter.com/randybias LINKEDIN: linkedin.com/in/randybias ASSISTANT: ren...@emc.com On 1/29/15, 4:01 PM, Michael Still mi...@stillhq.com wrote: Hi, as you might have read on openstack-dev, the Nova EC2 API implementation is in a pretty sad state. I wont repeat all of those details here -- you can read the thread on openstack-dev for detail. However, we got here because no one is maintaining the code in Nova for the EC2 API. This is despite repeated calls over the last 18 months (at least). So, does the Foundation have a role here? The Nova team has failed to find someone to help us resolve these issues. Can the board perhaps find resources as the representatives of some of the largest contributors to OpenStack? Could the Foundation employ someone to help us our here? I suspect the correct plan is to work on getting the stackforge replacement finished, and ensuring that it is feature compatible with the Nova implementation. However, I don't want to preempt the design process -- there might be other ways forward here. I feel that a continued discussion which just repeats the last 18 months wont actually fix the situation -- its time to break out of that mode and find other ways to try and get someone working on this problem. Thoughts welcome. Michael -- Rackspace Australia ___ Foundation mailing list foundat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation __ 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] [OpenStack Foundation] Finding people to work on the EC2 API in Nova
Alexandre, Randy, Are there plans afoot to add support to switch on stackforge/ec2-api in devstack? add tempest tests etc? CI Would go a long way in alleviating concerns i think. thanks, dims On Fri, Jan 30, 2015 at 1:24 PM, Bias, Randy randy.b...@emc.com wrote: As you know we have been driving forward on the stack forge project and it¹s our intention to continue to support it over time, plus reinvigorate the GCE APIs when that makes sense. So we¹re supportive of deprecating from Nova to focus on EC2 API in Nova. I also think it¹s good for these APIs to be able to iterate outside of the standard release cycle. --Randy VP, Technology, EMC Corporation Formerly Founder CEO, Cloudscaling (now a part of EMC) +1 (415) 787-2253 [google voice] TWITTER: twitter.com/randybias LINKEDIN: linkedin.com/in/randybias ASSISTANT: ren...@emc.com On 1/29/15, 4:01 PM, Michael Still mi...@stillhq.com wrote: Hi, as you might have read on openstack-dev, the Nova EC2 API implementation is in a pretty sad state. I wont repeat all of those details here -- you can read the thread on openstack-dev for detail. However, we got here because no one is maintaining the code in Nova for the EC2 API. This is despite repeated calls over the last 18 months (at least). So, does the Foundation have a role here? The Nova team has failed to find someone to help us resolve these issues. Can the board perhaps find resources as the representatives of some of the largest contributors to OpenStack? Could the Foundation employ someone to help us our here? I suspect the correct plan is to work on getting the stackforge replacement finished, and ensuring that it is feature compatible with the Nova implementation. However, I don't want to preempt the design process -- there might be other ways forward here. I feel that a continued discussion which just repeats the last 18 months wont actually fix the situation -- its time to break out of that mode and find other ways to try and get someone working on this problem. Thoughts welcome. Michael -- Rackspace Australia ___ Foundation mailing list foundat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation __ 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] [Magnum] Proposed Changes to Magnum Core
Welcome Hongbin. +1 from me! On Wed, Jan 28, 2015 at 2:27 PM, Adrian Otto adrian.o...@rackspace.com wrote: Magnum Cores, I propose the following addition to the Magnum Core group[1]: + Hongbin Lu (hongbin034) 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 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
teng...@linux.vnet.ibm.com 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
teng...@linux.vnet.ibm.com 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,
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
teng...@linux.vnet.ibm.com 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, 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 teng...@linux.vnet.ibm.com 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 teng...@linux.vnet.ibm.com 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] 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 ayo...@redhat.com 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] [tc][python-clients] More freedom for all python clients
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] [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 kevin.mitch...@rackspace.com 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 kevin.mitch...@rackspace.com 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] [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 jsbry...@electronicjungle.net 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] [Magnum] Proposed Changes to Magnum Core
+1 from me. Welcome Jay! On Jan 2, 2015 7:02 PM, Adrian Otto adrian.o...@rackspace.com 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] [Magnum] Proposed Changes to Magnum Core
+1 welcome! On Dec 26, 2014 3:48 PM, Adrian Otto adrian.o...@rackspace.com 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] [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 amit.gan...@rackspace.com wrote: Is there an ETA for this fix? Thanks Amit. On Dec 17, 2014, at 3:38 PM, Jeremy Stanley fu...@yuggoth.org 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] [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 mrie...@linux.vnet.ibm.com 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] [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 fu...@yuggoth.org 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] [oslo] deprecation 'pattern' library??
Surprisingly deprecator is still available on pypi On Thu, Dec 11, 2014 at 2:04 AM, Julien Danjou jul...@danjou.info 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][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 s...@dague.net 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
[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] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward
/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
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 mrie...@linux.vnet.ibm.com 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
[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] 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 fu...@yuggoth.org 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
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 mord...@inaugust.com 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 jaypi...@gmail.com 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] [oslo] scheduling a review day
Sounds good Doug. -- dims On Fri, Nov 21, 2014 at 12:07 PM, Doug Hellmann d...@doughellmann.com 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
