[openstack-dev] [Magnum] Use Liberty Magnum bits with Kilo/ Icehouse Openstack ?

A newbie question ... Is it described somewhere what exactly is the set of Liberty dependencies for Magnum ? Since a significant fraction of it is orchestration templates, one would expect it should be possible to run Liberty Magnum bits along with an Icehouse or Kilo version of Openstack. Can

Re: [openstack-dev] [Magnum] Use Liberty Magnum bits with Kilo/ Icehouse Openstack ?

HI, For Magnum, The community keep upstream development since Kilo. Magnum has some dependence on Keystone, Nova, Glance, Heat, Cinder. If you try to use Liberty Magnum against with Icehouse and Kilo OpenStack. It depends on related if heat templates include any non-icehouse, kilo resources.

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 01/28/2016 06:03 AM, Steven Dake (stdake) wrote: The TC set precedent in this first competition-induced review which is worth a good read for other projects thinking of competing with existing projects of which there are already plenty in OpenStack.. https://review.openstack.org/206789 Stev

Re: [openstack-dev] [api] service type vs. project name for use in headers

On 01/27/2016 08:31 PM, Dean Troyer wrote: On Wed, Jan 27, 2016 at 1:47 PM, michael mccune mailto:[email protected]>> wrote: i am not convinced that we would ever need to have a standard on how these names are chosen for the header values, or if we would even need to have header names

Re: [openstack-dev] [TripleO] spec-lite process for tripleo

On Wed, Jan 27, 2016 at 08:01:31PM -0700, Jason Rist wrote: > On 01/27/2016 09:21 AM, Derek Higgins wrote: > > Hi All, > > > > We briefly discussed feature tracking in this weeks tripleo meeting. I > > would like to provide a way for downstream consumers (and ourselves) to > > track new features a

[openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka

Save the Date: Global OpenStack Bug Smash Wednesday-Friday, March 2-4, 2016 RSVP by Friday, February 19 How can you help make the OpenStack Mitaka release stable and bug-free while having fun with your peers? Join Intel, Rackspace, Mirantis, IBM, HP, Huawei, CESI and others in a global bug smash

[openstack-dev] [sahara][stable] stable/kilo blocked for sahara

All changes to Sahara on stable/kilo are blocked on the version change patch here: https://review.openstack.org/#/c/273011/ But that can't land because the gate-tempest-dsvm-sahara job is failing: http://logs.openstack.org/11/273011/1/check/gate-tempest-dsvm-sahara/f5d427f/ It's failing becau

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

On Wed, Jan 27, 2016 at 10:22:54AM -0500, Dan Prince wrote: > On Wed, 2016-01-27 at 09:36 -0500, Dan Prince wrote: > > On Wed, 2016-01-27 at 14:32 +0100, Jiri Tomasek wrote: > > > On 01/26/2016 09:05 PM, Ben Nemec wrote: > > > > On 01/25/2016 04:36 PM, Dan Prince wrote: > > > > > On Mon, 2016-01-25

Re: [openstack-dev] [nova] Better tests for nova scheduler(esp. race conditions)?

> -Original Message- > From: Cheng, Yingxin [mailto:[email protected]] > Sent: January 28, 2016 04:21 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova] Better tests for nova scheduler(esp. > race conditions)? > > Thank you Nikola

Re: [openstack-dev] [mistral][stable] Inappropriate changes backported to stable/liberty

> On 27 Jan 2016, at 19:14, Matt Riedemann wrote: > > Starting with stable/liberty, each project now owns when to do point releases > for their stable branches (rather than a large coordinated stable branch > point release that the stable-maint-core team does). > > There are a couple of core

[openstack-dev] [Horizon] Handling 401 in new REST API

Hi fellow angular/REST Horizon developers, I'd like to propose that we handle HTTP 401 responses at the core of the new angular code interfacing to our new REST API so that *any* 401 just does basically what the Django code used to: redirect to the login page with a "from". What do y'all think?

Re: [openstack-dev] [telemetry][ceilometer] New project: collectd-ceilometer-plugin

On Thu, Jan 28 2016, Foley, Emma L wrote: > So, metrics are grouped by the type of resource they use, and each metric has > to be listed. > Grouping isn't a problem, but creating an exhaustive list might be, since > there > are 100+ plugins [1] in collectd which can provide statistics, although

Re: [openstack-dev] [Oslo] Improving deprecated options identification and documentation

> From: Ronald Bradford [mailto:[email protected]] > Sent: Wednesday, January 20, 2016 6:34 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Oslo] Improving deprecated options > identification and documentation > > Markus, > >  >> Yes, in

[openstack-dev] [Fuel] Overriding and removing VIPs from plugins

Folks, currently merge policy for network roles only allows to add new VIPs to already existing roles [1]. If a plugin supplies a VIP with a name that already exists but with different parameters, Nailgun will not allow to do that. We faced a need to override configuration of several VIPs by co

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

+1 to overriding VIPs On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko wrote: > Folks, > > currently merge policy for network roles only allows to add new VIPs to > already existing roles [1]. If a plugin supplies a VIP with a name that > already exists but with different parameters, Nailgun

Re: [openstack-dev] [api] service type vs. project name for use in headers

On Wed, 27 Jan 2016, Dean Troyer wrote: I think we would be better served in selecting these things thinking about the API consumers first. We already have enough for them to wade through, the API-WG is making great gains in herding those particular cats, I would hate to see giving back some o

Re: [openstack-dev] OpenStack installer

Hi Kevin! We'll see when Mitaka arrives. I still have some trust in the good old apt-get (or yum or dnf) upgrade method :) Br, György > -Original Message- > From: Kevin Carter [mailto:[email protected]] > Sent: 2016 január 27, szerda 23:03 > To: OpenStack Development Mailing Li

Re: [openstack-dev] [Fuel][Plugins] Tasks ordering between plugins

On 27.01.2016 14:44, Simon Pasquier wrote: > Hi, > > I see that tasks.yaml is going to be deprecated in the future MOS > versions [1]. I've got one question regarding the ordering of tasks > between different plugins. > With tasks.yaml, it was possible to coordinate the execution of tasks > betwee

Re: [openstack-dev] [api] service type vs. project name for use in headers

Couldn't agree more, Chris. -jay On 01/28/2016 11:06 AM, Chris Dent wrote: On Wed, 27 Jan 2016, Dean Troyer wrote: I think we would be better served in selecting these things thinking about the API consumers first. We already have enough for them to wade through, the API-WG is making great

[openstack-dev] project overlap (was Re: Announcing Ekko -- Scalable block-based backup for OpenStack)

On Thu, 28 Jan 2016, Jay Pipes wrote: It was Joe Gordon and others who advised that there was nothing in the project acceptance criteria that mentioned a lack of API overlap as a condition for inclusion. Let's be honest: From my perspective Joe (and others) had it in for Ceilometer and was ho

Re: [openstack-dev] [mistral][stable] Inappropriate changes backported to stable/liberty

On 1/28/2016 9:35 AM, Renat Akhmerov wrote: On 27 Jan 2016, at 19:14, Matt Riedemann wrote: Starting with stable/liberty, each project now owns when to do point releases for their stable branches (rather than a large coordinated stable branch point release that the stable-maint-core team

[openstack-dev] Announcing Debian Mitaka b2 packages with backports for Jessie and Trusty

Hi everyone, I'm delighted to announce the release of Debian packages for Mitaka b2. Debian Experimental === I have uploaded it all to Debian Experimental. This is the only place where you may find official packages. It will stay this way until Debian Bikesheds (Bikesheds is what

[openstack-dev] [all][i18n] Rework of translation setup

Projects that want to setup translations for their repositories run into a few common problems and we're addressing these now to make the setup for everybody easier. The problems they run into came from limitations of the current infra scripts, so we rework the infra scripts. We want to have a sim

Re: [openstack-dev] [neutron] https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers

Thanks! On 28/01/16 00:23, Armando M. wrote: > I'll kill it, as this should be superseded by the in-tree devref version. > > Thanks for pointing my attention to it. > > On 27 January 2016 at 23:40, Neil Jerram > wrote: > > Is there any part of the cited wiki

Re: [openstack-dev] [all][i18n] Rework of translation setup

Correction: b) affects also: openstack/ironic-inspector openstack/networking-l2gw openstack/networking-ovn openstack/neutron-fwaas openstack/neutron-lbaas openstack/neutron-lib openstack/vmware-nsx Andreas On 2016-01-28 13:13, Andreas Jaeger wrote: > Projects that want to setup translations for t

Re: [openstack-dev] [Neutron][L3] Orphaned process cleanup

Sean M. Collins wrote: Hi, I started poking a bit at https://bugs.launchpad.net/devstack/+bug/1535661 We have radvd processes that the l3 agent launches, and if the l3 agent is terminated these radvd processes continue to run. I think we should probably terminate them when the l3 agent is ter

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

> On 27 January 2016 at 08:10, Tzu-Mainn Chen < [email protected] > wrote: > > > Okay, so I initially thought we weren't making much progress on this > > > > discussion, but after some more thought and reading of the existing PoC, > > > > we're (maybe?) less far apart than I initially thought.

[openstack-dev] [Heat] Current state of get_live_state implementation

Hi all! I decided to post current state of convergence sensitive patches - get_live_state method implementation - which resources is ready for review. At first, if you need, you can learn about this feature from https://review.openstack.org/#/c/232368/ There's some refactoring of base get_live_s

Re: [openstack-dev] [TripleO] changes in irc alerts

On 01/27/2016 05:02 PM, James Slagle wrote: > On Tue, Jan 26, 2016 at 7:15 PM, Derek Higgins wrote: > >> Hi All, >> >> For the last few months we've been alerting the #tripleo irc channel when >> a card is open on the tripleo trello org, in the urgent list. >> >> When used I think it served a g

[openstack-dev] [puppet] separated controller/compute installations using puppet modules

Hi All, I have one very general question, we would like to deploy role-separated (compute & controller) openstack via puppet modules. Unfortunately puppet-openstack-integration supports only “all-in-one” scenarios. https://github.com/openstack/puppet-openstack-integration this project looks like

Re: [openstack-dev] [keystone] changes to keystone-core!

Hey, Thanks for trusting me. I will do my best to make OpenStack even better. Regards, Samuel On Wed, Jan 27, 2016 at 8:34 PM, Chen, Wei D wrote: > Hi, > > > > Many thanks to everyone for your patient guidance and mentoring me in the > past years! It’s your help to make me grow up from a new

Re: [openstack-dev] [keystone] changes to keystone-core!

On 01/28/2016 02:34 AM, Chen, Wei D wrote: > Hi, > > > > Many thanks to everyone for your patient guidance and mentoring me in the > past years! It's your help to make me grow up from a > newbie! > > > > As a core project in OpenStack, keystone has grown to be several > sub-projects, I

Re: [openstack-dev] [murano] Nominate Victor Ryzhenkin to Murano Core

+1 from me. Victor’s continued work on keeping our gates green and stable is invaluable. His contribution during M cycle is also very impressive. Looking forward to seeing him one of the cores. --  Kirill Zaitsev Murano team Software Engineer Mirantis, Inc On 27 January 2016 at 01:10:18, Stan L

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

+1 to overriding VIPs -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin wrote: > +1 to overriding VIPs > > On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko > wrote: > >> Folks, >> >> currently merge policy for network roles on

Re: [openstack-dev] [murano] Nominate Victor Ryzhenkin to Murano Core

Victor, welcome! On Thu, Jan 28, 2016 at 5:57 AM, Kirill Zaitsev wrote: > > +1 from me. Victor’s continued work on keeping our gates green and stable is > invaluable. His contribution during M cycle is also very impressive. Looking > forward to seeing him one of the cores. > > -- > Kirill Zaits

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 28/01/2016 1:03 AM, Steven Dake (stdake) wrote: > Choice is one of life's fundamental elements that make life interesting. > Let the Operators choose what they wish based upon technical merits rather > then "who was first to publish a project". yes, it's nice when competing entities exists in

Re: [openstack-dev] [murano] Nominate Victor Ryzhenkin to Murano Core

Thank you, folks! I will do my best! Cheers! --  Victor Ryzhenkin Junior QA Engeneer freerunner on #freenode Включено 28 января 2016 г. в 17:15:19, Serg Melikyan ([email protected]) написал: Victor, welcome! On Thu, Jan 28, 2016 at 5:57 AM, Kirill Zaitsev wrote: > > +1 from me. Victor’s

Re: [openstack-dev] [murano] Nominate Victor Ryzhenkin to Murano Core

Congratulations, Victor! =) 2016-01-28 16:20 GMT+02:00 Victor Ryzhenkin : > Thank you, folks! I will do my best! > > Cheers! > > -- > Victor Ryzhenkin > Junior QA Engeneer > freerunner on #freenode > > Включено 28 января 2016 г. в 17:15:19, Serg Melikyan ( > [email protected]) написал: > > V

Re: [openstack-dev] [api] service type vs. project name for use in headers

I'd like an answer on this specific issue. I agree with Chris and I wonder if our goal is consistency across services or an ideal standard. Nova has 'X-OpenStack-Nova-API-Version' and Manila has 'X-Openstack-Manila-Api-Version'. If we deviate from this, we should suggest that those projects add th

Re: [openstack-dev] [api] service type vs. project name for use in headers

On 01/28/2016 06:32 AM, Jay Pipes wrote: Couldn't agree more, Chris. -jay On 01/28/2016 11:06 AM, Chris Dent wrote: On Wed, 27 Jan 2016, Dean Troyer wrote: I think we would be better served in selecting these things thinking about the API consumers first. We already have enough for them to

Re: [openstack-dev] [glance] Glance Core team additions/removals

+1 to adding both Kairat and Brian! Welcome to the core team! Great to have you guys. On 1/26/16 9:41 AM, Flavio Percoco wrote: > > Greetings, > > I'd like us to have one more core cleanup for this cycle: > > Additions: > > - Kairat Kushaev > - Brian Rosmaita > > Both have done amazing reviews ei

[openstack-dev] [Fuel] [Plugin] 7.0 compute node re-deployment issue

Fuel team, Can someone please review the issues Rohan is having and provide answers/suggestions to help him complete his plugin? Thanks, Sheena *From:* Rohan PARULEKAR [mailto:[email protected]] *Sent:* Thursday, January 28, 2016 4:35 AM *To:* Sheena Gregson *Subject:

Re: [openstack-dev] [Magnum] Use Liberty Magnum bits with Kilo/ Icehouse Openstack ?

As Kai Qiang mentioned, in term of OpenStack projects, Magnum depends on Keystone, Nova, Glance, Heat, Cinder. If you are looking for the exact set of dependencies, you can find it here: https://github.com/openstack/magnum/blob/stable/liberty/requirements.txt . If you want to run Magnum with ol

Re: [openstack-dev] [puppet] separated controller/compute installations using puppet modules

The way I'd recommend is to write your own manifests that include the openstack modules. I'd use roles and profiles which make it easy to move things around, but two simple manifests will also work. As Emilien once said we give you the ingredients but don't cook for you. If you want to just do two

Re: [openstack-dev] [keystone] changes to keystone-core!

CONGRATULATIONS Dave and Samuel. Very well deserved!!! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: [email protected] Assistant: Kendra Witherspoon (919) 254-0680 From: "Steve Martinelli" To: openstack-dev Date: 01/27/2016 05:17 PM Subject

[openstack-dev] [oslo] Adding Dmitry Ukhlov to Oslo-Messaging-Core

Team, Dmitry has been focused solely on the Pika Driver this cycle: http://stackalytics.com/?user_id=dukhlov&metric=commits Now that we have Pika driver in master, i'd like to invite Dmitry to continue his work on all of Oslo.Messaging in addition to Pika. Clearly over time he will expand to othe

Re: [openstack-dev] [puppet] separated controller/compute installations using puppet modules

On 01/28/2016 10:14 AM, Matt Fischer wrote: > The way I'd recommend is to write your own manifests that include the > openstack modules. I'd use roles and profiles which make it easy to move > things around, but two simple manifests will also work. As Emilien once > said we give you the ingredien

Re: [openstack-dev] [oslo] Adding Dmitry Ukhlov to Oslo-Messaging-Core

Excerpts from Davanum Srinivas (dims)'s message of 2016-01-28 09:25:56 -0600: > Team, > > Dmitry has been focused solely on the Pika Driver this cycle: > http://stackalytics.com/?user_id=dukhlov&metric=commits > > Now that we have Pika driver in master, i'd like to invite Dmitry to > continue his

Re: [openstack-dev] [oslo] Adding Dmitry Ukhlov to Oslo-Messaging-Core

My big +1 for Dmitry! On Thu, Jan 28, 2016 at 5:40 PM, Doug Hellmann wrote: > Excerpts from Davanum Srinivas (dims)'s message of 2016-01-28 09:25:56 > -0600: > > Team, > > > > Dmitry has been focused solely on the Pika Driver this cycle: > > http://stackalytics.com/?user_id=dukhlov&metric=commit

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

Good idea, overally. How about multiple plugins? We don't have any sequence or priorities between them. What if one plugin assumes that VIP is present but other one wants to remove it? Aleksey Kasatkin On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk wrote: > +1 to overriding VIPs > > -- >

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

Roman, please provide more details on how VIPs are overridden. And how do you deal with multiple plugins. Aleksey Kasatkin On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin wrote: > Good idea, overally. > > How about multiple plugins? We don't have any sequence or priorities > between them. >

Re: [openstack-dev] [Fuel] Relieving CI/gate jenkins bottleneck

On 22.01.2016 13:56, Bogdan Dobrelya wrote: > On 22.01.2016 12:19, Matthew Mosesohn wrote: >> +1 for defaulting to upstream for CI. If we have a strong case where we >> need to make a patch in order to make unit tests pass, we could switch a >> module back to review.fuel-infra.org/puppet-modules/..

[openstack-dev] [watcher] Travel logistics for mid-cycle in Austin

Hi Watcher Team, For those of you attending the Watcher mid-cycle next week in Austin (Tue-Thurs), please take a quick look at the travel details [1] — particularly the bit about where to “check in” every day once you arrive to the IBM campus. As another FYI, light breakfast foods, lunch and an

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

Well, with merging instead of overriding, I believe, this problem with multiple plugins still exists, right? How are we handling this now for multiple plugins? Since VIPs is array I also vote for overriding, since merging it could be a pain (how do you remove existing element during array merge?).

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

> How are we handling this now for multiple plugins? OK, so right now we can only add VIPs to array, we can't remove them. So overriding would disable such possibility of adding VIPs from different plugins. But with [0] patch it will be still possible to add and to remove by providing empty array.

Re: [openstack-dev] [Fuel] Relieving CI/gate jenkins bottleneck

Hi, I disagree with Bogdan. We have the same case in OpenStack components. 1. As a compony we may have own patches on top of 'master'. 2. There is no way to use tags on upstream modules so it will be very hard to support it. If we need to deliver fix in previous release there won't be simple way

Re: [openstack-dev] [Horizon] Handling 401 in new REST API

I think that's the sane thing to do. David On Thu, Jan 28, 2016 at 2:55 AM, Richard Jones wrote: > Hi fellow angular/REST Horizon developers, > > I'd like to propose that we handle HTTP 401 responses at the core of the new > angular code interfacing to our new REST API so that *any* 401 just doe

Re: [openstack-dev] [Fuel] Relieving CI/gate jenkins bottleneck

On Thu, Jan 28, 2016 at 9:31 AM, Sergii Golovatiuk wrote: > Hi, > > I disagree with Bogdan. We have the same case in OpenStack components. > > 1. As a compony we may have own patches on top of 'master'. > 2. There is no way to use tags on upstream modules so it will be very hard > to support it. I

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

Hi, I agree with this view point. Let me provide Solum team's perspective on this. Solum currently uses Heat to deploy application docker containers that it creates. We have been looking at Magnum as an alternative deployment mechanism. The fact that Magnum is supporting containers endpoint is

Re: [openstack-dev] [api] service type vs. project name for use in headers

On Thu, 2016-01-28 at 11:06 +, Chris Dent wrote: > I think it is high time we resolve the question of whether the > api-wg guidelines are evaluating existing behaviors in OpenStack and > blessing the best or providing aspirational guidelines of practices > which are considered best at a more un

[openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Recently I tried started to use oslo.versionedobjects for a project. After playing around with it for a while, I noticed I could set "this is not a uuid" as the value of a UUIDField. After making sure I made no mistakes - I looked at the underlying code, and found:[0] class UUID(FieldType):

Re: [openstack-dev] [neutron][dvr]

Hi Sudhakar, I don’t think there was any specific reason behind this. But we can definitely check for the config flag and then add the topic ‘dvr_update’. Go ahead and file a bug and we can address it. Thanks Swami From: Sudhakar Gariganti [mailto:[email protected]] Sent: Wednesday, J

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

AFAIC, it is better to remove by name then. Otherwise, you do not know what VIPs you are removing. Another option - remove "built-in" VIPs using some specific expression. Anyway, you do not know where other VIPs (VIPs of other plugins) live so you cannot remove them this way. And the order of plug

Re: [openstack-dev] [Horizon] Handling 401 in new REST API

I am assuming that you meant redirecting on the server side. We already have a similar one in place on the client side. https://github.com/openstack/horizon/blob/master/horizon/static/framework/framework.module.js#L65   Currently, you're not able to hit the REST layer directly anyway, You get a "re

[openstack-dev] [Horizon] Recent integration tests failures

Hello, Horizoneers You may have noticed recent integration tests failures seemingly unrelated to you patches, with a stacktrace like: http://paste2.org/2Hk9138U I've already filed a bug for that, https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a Selenium issue, currently investigatin

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Graham, Quite unfair characterization of Oslo being -2 heavy. Please compare stats before making such an assertion: http://russellbryant.net/openstack-stats/oslo-reviewers-365.txt http://russellbryant.net/openstack-stats/nova-reviewers-365.txt http://russellbryant.net/openstack-stats/neutron-revi

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +: > Recently I tried started to use oslo.versionedobjects for a project. > > After playing around with it for a while, I noticed I could set "this is > not a uuid" as the value of a UUIDField. > > After making sure I made no mistak

Re: [openstack-dev] [puppet] separated controller/compute installations using puppet modules

Thanks to both of you guys for detailed answer with valuable hints, My interest is maybe slightly different as I don't have own recipe for cooking "special openstack", What I am looking for is some standardized method of openstack deployment, which is for me just a kind of entry point. Our inter

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Hayes, Graham wrote: Also, olso seem to be very-2 heavy. This means that alternative views on the review are very unlikely. My question is what is the difference between a-1 and a-2 for oslo? If this is the case I am sorry about it, and I'd also like to think that we (as the oslo team) need

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

On 28/01/2016 18:44, Davanum Srinivas wrote: > Graham, > > Quite unfair characterization of Oslo being -2 heavy. Please compare > stats before making such an assertion: OK - that was probably my frustration boiling over at the time. I should not have made that generalization. I had been involved i

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

On 01/28/2016 01:52 PM, Doug Hellmann wrote: > Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +: >> Recently I tried started to use oslo.versionedobjects for a project. >> >> After playing around with it for a while, I noticed I could set "this is >> not a uuid" as the value of

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

On 28/01/2016 18:54, Doug Hellmann wrote: > Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +: >> Recently I tried started to use oslo.versionedobjects for a project. >> >> After playing around with it for a while, I noticed I could set "this is >> not a uuid" as the value of a UUI

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

On 28/01/2016 19:13, Mike Bayer wrote: > > > On 01/28/2016 01:52 PM, Doug Hellmann wrote: >> Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +: >>> >>> The steps I had looked at doing was this: >>> >>> 1. Allow a "validate" flag on the Field __init__() defaulting to False. >>> 1.1

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Excerpts from Hayes, Graham's message of 2016-01-28 19:02:57 +: > On 28/01/2016 18:44, Davanum Srinivas wrote: > > Graham, > > > > Quite unfair characterization of Oslo being -2 heavy. Please compare > > stats before making such an assertion: > > OK - that was probably my frustration boiling o

[openstack-dev] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

Hi, As many of you have probably seen, most of the projects targeted for 2015.1.3 release have been tagged and have tarballs ready for release. However, pip 8 was released around the same time as the tarballs were attempted to be generated. Most of the projects are OK with this, but ceilometer d

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 27 January 2016 at 11:06, Flavio Percoco wrote: > FWIW, the current governance model does not prevent competition. That's > not to > be understood as we encourage it but rather than there could be services > with > some level of overlap that are still worth being separate. > There should alwa

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

> On Jan 28, 2016, at 1:32 PM, Doug Hellmann wrote: > > Excerpts from Hayes, Graham's message of 2016-01-28 19:02:57 +: >> On 28/01/2016 18:44, Davanum Srinivas wrote: >>> Graham, >>> >>> Quite unfair characterization of Oslo being -2 heavy. Please compare >>> stats before making such an as

Re: [openstack-dev] [Horizon] Handling 401 in new REST API

Hmm. That client-side redirect isn't working consistently then. More investigation required... On 29 January 2016 at 05:04, Thai Q Tran wrote: > I am assuming that you meant redirecting on the server side. We already > have a similar one in place on the client side. > https://github.com/openstac

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Excerpts from Hayes, Graham's message of 2016-01-28 19:17:54 +: > On 28/01/2016 18:54, Doug Hellmann wrote: > > Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +: > >> Recently I tried started to use oslo.versionedobjects for a project. > >> > >> After playing around with it fo

[openstack-dev] [release][oslo] futurist release 0.10.0 (mitaka)

We are satisfied to announce the release of: futurist 0.10.0: Useful additions to futures, from the future. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/futurist With package available at: https://pypi.python.org/

Re: [openstack-dev] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

On 2016-01-28 19:40:20 + (+), Dave Walker wrote: [...] > However, pip 8 was released around the same time as the tarballs were > attempted to be generated. Most of the projects are OK with this, but > ceilometer declares pbr!=0.7,<1.0,>=0.6 and then forces an update via > tox. [...] More

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

On 28/01/2016 20:16, Doug Hellmann wrote: > Excerpts from Hayes, Graham's message of 2016-01-28 19:17:54 +: >> On 28/01/2016 18:54, Doug Hellmann wrote: >>> Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +: Recently I tried started to use oslo.versionedobjects for a proje

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

> On Jan 28, 2016, at 1:10 PM, Mike Bayer wrote: > > > > On 01/28/2016 01:52 PM, Doug Hellmann wrote: >> Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +: >>> Recently I tried started to use oslo.versionedobjects for a project. >>> >>> After playing around with it for a whil

[openstack-dev] Any chances to backport port_security_enabled support into Heat for Kilo 2015.1.3?

Guys, This is important and Kilo is missing it: https://review.openstack.org/#/c/179989/ Is it possible to backport it to Kilo 2015.1.3? Currently, I am manually patching Kilo / Heat by using the following diff: https://review.openstack.org/gitweb?p=openstack%2Fheat.git;a=commitdiff;h=81

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/26/2016 01:48 PM, Kevin Carter wrote: > I personally think it'd be great to see this feature in OSA and I look > forward to reviewing the spec. The first draft of the spec is in Gerrit: https://review.openstack.org/#/c/273749/ I appreciat

Re: [openstack-dev] [Horizon] Recent integration tests failures

According to the results at https://review.openstack.org/#/c/273697/1 capping Selenium to be not greater than 2.49 fixes broken tests. Patch to global-requirements is here: https://review.openstack.org/#/c/273750/ On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev wrote: > Hello, Horizoneers > > You m

[openstack-dev] [Nova][Neutron] Scheduling with routed networks

Hi Nova and Neutron, It was a pleasure to attend the Nova mid-cycle in Bristol this week. I think we made a lot of progress. I spent a little time capturing the highlights of what we discussed about scheduling and routed networks in a new revision to the backlog spec [1] that I created a couple o

[openstack-dev] [puppet] let's start using reno

Last month, we decided [1] to give a try to reno, the release management tool in OpenStack. During the sprint, I worked with Doug to make it happen. We have now reno in place for puppet-keystone: http://docs.openstack.org/releasenotes/puppet-keystone/ What are the next steps: * our puppet-keyston

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Excerpts from Hayes, Graham's message of 2016-01-28 20:42:39 +: > On 28/01/2016 20:16, Doug Hellmann wrote: > > Excerpts from Hayes, Graham's message of 2016-01-28 19:17:54 +: > >> On 28/01/2016 18:54, Doug Hellmann wrote: > >>> Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +

[openstack-dev] [oslo] nominating Ronald Bradford for oslo-core

I am nominating Ronald Bradford (rbradfor) for oslo-core. Ronald has been working this cycle to learn about oslo.context, oslo.log, and oslo.config. He anticipates picking up the much-needed work on the app-agnostic-logging blueprint, and has already started making incremental changes related to t

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Ryan Rossiter wrote: As the-guy-in-nova-that-does-this-a-bunch, I’ve pushed a bunch of changes to nova because we didn’t have them yet in o.vo, and once they get released, I “re-sync” them back to nova to use the o.vo version, see: https://review.openstack.org/#/c/272641/ https://github.com/o

[openstack-dev] [oslo] nominating Alexis Lee for oslo-core

I am nominating Alexis Lee (lxsli) for oslo-core. Alexis has been working on adding configuration file reloading to oslo.config this cycle. The work isn't complete, but at this point he probably knows as much or more about the internals of that library as any of us. :-) He has also shown, with som

Re: [openstack-dev] [Neutron][Networking-ovn] Instances on the compute node can not get IP address from DHCP

Hi, Checked with Chen for ofproto/trace for the drop flow on controller node: sudo ovs-appctl ofproto/trace "recirc_id(0),tunnel(tun_id=0x1,src=9.197.45.38,dst=9.197.45.35,ttl=64,geneve({class=0x102/0x102,len=4/0x1,0x40003/0x40003}),flags(-df-csum+key)),in_port(7),skb_mark(0),eth_type(0x0800),ip

[openstack-dev] log processing project

hi folks, just querying before i do anything, i was wondering if there's a log processing project out there? or is everyone just using ELK stack? cheers, -- gord __ OpenStack Development Mailing List (not for usage questi

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

> On Jan 28, 2016, at 4:04 PM, Joshua Harlow wrote: > > Ryan Rossiter wrote: >> >> As the-guy-in-nova-that-does-this-a-bunch, I’ve pushed a bunch of changes to >> nova because we didn’t have them yet in o.vo, and once they get released, I >> “re-sync” them back to nova to use the o.vo version

Re: [openstack-dev] log processing project

Kolla wants to do a PoC [1] with Heka [2] [1]: https://review.openstack.org/#/c/270906/ [2]: https://github.com/mozilla-services/heka David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Thu, Jan 28, 2016 at 5:34 PM, gordon chung wrote: > hi folks,

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

> I know we have some projects (heat, I think?) that don't have UUIDs at > all. Are they using oslo.versionedobjects? I suppose we could move them > to a string field instead of a UUID field, instead of flipping the > enforcement flag on. Alternately, if we add a new class we wouldn't have > to eve

Re: [openstack-dev] [puppet] let's start using reno

At the beginning it will be hard, but this change came to help everyone. Congratulations for everyone that made this possible. 2016-01-28 18:25 GMT-03:00 Emilien Macchi : > Last month, we decided [1] to give a try to reno, the release management > tool in OpenStack. > > During the sprint, I worke

Re: [openstack-dev] [Neutron][Networking-ovn] Instances on the compute node can not get IP address from DHCP

Yes, I installed controller node at first, and then add the compute node. The last commit for ovs on controller nodes ovs is on "Jan 11", while the compute node has newer code with the last commit at Jan 20. I re-installed devstack on controller node, and everything looks fine now. Thanks very

Re: [openstack-dev] [oslo] nominating Ronald Bradford for oslo-core

+1 from me! -- Dims On Thu, Jan 28, 2016 at 4:00 PM, Doug Hellmann wrote: > I am nominating Ronald Bradford (rbradfor) for oslo-core. > > Ronald has been working this cycle to learn about oslo.context, > oslo.log, and oslo.config. He anticipates picking up the much-needed > work on the app-agnos

  1   2   >