Re: [openstack-dev] [neutron] Are routed TAP interfaces (and DHCP for them) in scope for Neutron?

I haven't yet had any responses to this, so reflagging it in case it was just missed in the helter skelter of activity that is the openstack-dev mailing list... On the other hand, if I need to describe more clearly what I'm on about, please don't be afraid to say that! Any comments and steer

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

- Original Message - > From: "Jeremy Stanley" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Friday, April 17, 2015 9:35:07 PM > Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in > DevStack [was: Status of the nova-network > t

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

On 20/04/15 13:39 -0700, Vipul Sabhaya wrote: On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M wrote: Another parallel is Manilla vs Swift. Both provides something like a share for users to store files. The former is a multitenant api to provision non multitenant file shares. The l

Re: [openstack-dev] [mistral] Break_on in Retry policy

Any more suggestions/thoughts here? Dmitri? More words: succeed-on / fail-on, success-expr / error-expr. -- Best Regards, Nikolay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-req

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

On 04/21/2015 09:56 AM, Flavio Percoco wrote: FWIW, the team is not messuring the success of the project on whether it's integrated with other services or not. The adoption in all possible areas play key parts in every project's life. While it's amazing that RDO - and I believe Ubuntu is packag

Re: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 23rd

Nice idea. Looked at the TOC page, pretty much covering variants of neutron nuts & bolts. Shall we include DNS into TOC somewhere? Regards, Yatin On Tue, Apr 21, 2015 at 10:22 AM, Guo, Ruijing wrote: > Hi, Edgar > > > > Some docs are still in private branch. Can we move to public branch for

Re: [openstack-dev] [Glance] Open glance-drivers to all glance-cores

On 20/04/15 19:34 +, Kuvaja, Erno wrote: -Original Message- From: Flavio Percoco [mailto:fla...@redhat.com] Sent: 20 April 2015 15:04 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Glance] Open glance-drivers to all glance-cores Hello Glance folks, and not Glance fol

Re: [openstack-dev] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFSSA iSCSI Driver

Diem Can you please look at why the Oracle CI is failing on every patch? Currently it appears you *do not* have working CI and *are not* eligible to be merged back in. Given we (Cinder core) set a second deadline for the 'nearly there' CI systems which you missed, and your CI is still not working,

Re: [openstack-dev] [neutron] Are routed TAP interfaces (and DHCP for them) in scope for Neutron?

Is it compatible with overlapping IPs? i.e. Will it give two different VMs the same IP address if the reservations are setup that way? If not, this approach won't work for many use cases so I think you will probably just have to write a new DHCP agent that operates in this distributed fashion. I h

[openstack-dev] TC Candidacy

Greetings, I'm announcing my candidacy for the Technical Comitee Elections. I wish I could say I've served as a TC member before but I haven't. However, there's always a first time for everything, isn't there? I'd like for Liberty to be that chance for me to be honored with a seat in OpenStack's

Re: [openstack-dev] [glance] Why no DB index on sort parameters

On 21/04/15 12:17 +0530, Ajaya Agrawal wrote: Hi All, I see that glance supports arbitrary sort parameters and the default is "created_at" while listing images. Is there any reason why we don't have index over these fields? If we have an index over these fields then we would avoid a full table s

Re: [openstack-dev] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFSSA iSCSI Driver

Duncan Thomas wrote: > Can you please look at why the Oracle CI is failing on every patch? > Currently it appears you *do not* have working CI and *are not* eligible > to be merged back in. Given we (Cinder core) set a second deadline for > the 'nearly there' CI systems which you missed, and your C

[openstack-dev] Cross-Project meeting, Tue April 21st, 21:00 UTC

Dear PTLs, cross-project liaisons and anyone else interested, We'll have a cross-project meeting today at 21:00 UTC, with the following agenda: * api-wg discussion * The following guidelines have been reached consensus within the api-wg and we'd like them to be reviewed by the CPLs ** tagging

[openstack-dev] [Ironic] [TripleO] Aborting in(tro)spection process in discoverd

Hi folks. Recently I got several requests to implement API aborting introspection in discoverd. This is useful mostly when debugging, when you know that introspection has failed, and you want to stop it right now. I've put a blueprint https://blueprints.launchpad.net/ironic-discoverd/+spec/ab

Re: [openstack-dev] [nova] Dropping DB Downgrades, need Turbo Hipster tests updated

Great, thank you for the quick turn around on this. -Sean On 04/21/2015 02:31 AM, Joshua Hesketh wrote: > Hey, > > turbo-hipster is no longer testing downgrades as per the TC decision. > The CI bot now passes on that change. > > Cheers, > Josh > > Rackspace Australia > > On 4/20/15 10

[openstack-dev] [neutron] neutron DB upgrade

Somebody can help me to understand why neutron DB is needed upgrade even in refresh installation unlike other components. >From my understanding, DB upgrade is risky and needed when upgrade. Release A should have schema A and Release B should have schema B. Only upgrade A to B need to upgrade

Re: [openstack-dev] [Ironic] [TripleO] Aborting in(tro)spection process in discoverd

In my opinion, Ironic has a (better) way for doing deploy aborts. During a deploy in a real-world case, major chunk of time for the deploy is spent in booting up the bare metal. The state of node during this time is wait-call-back. It is possible today to abort the deploy when state of the node

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

On 04/20/2015 07:12 PM, Steve Baker wrote: > On 21/04/15 11:01, Angus Salkeld wrote: >> >> >> On Tue, Apr 21, 2015 at 8:38 AM, Fox, Kevin M > > wrote: >> >> As an Op, a few things that come to mind in that category are: >> * RDO packaging (stated earlier). If its

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

On 21/04/15 08:51 -0400, Ryan Brown wrote: On 04/20/2015 07:12 PM, Steve Baker wrote: Absolutely agreed. Especially in a service like Zaqar where the vast majority of usage isn't by humans in a web interface, the horizon bit becomes mostly a dashboard/auditing/testing destination instead of a pri

Re: [openstack-dev] [neutron] neutron DB upgrade

On 21 April 2015 at 14:25, Guo, Ruijing wrote: > Somebody can help me to understand why neutron DB is needed upgrade even > in refresh installation unlike other components. > > From my understanding, DB upgrade is risky and needed when upgrade. > Alembic is a fairly reliable tool for managing D

Re: [openstack-dev] [neutron] neutron DB upgrade

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/21/2015 02:25 PM, Guo, Ruijing wrote: > Somebody can help me to understand why neutron DB is needed upgrade > even in refresh installation unlike other components. > refresh installation == minor version upgrade for a stable release? No, it s

Re: [openstack-dev] TC Candidacy

confirmed On 04/21/2015 04:47 AM, Flavio Percoco wrote: > Greetings, > > I'm announcing my candidacy for the Technical Comitee Elections. > > I wish I could say I've served as a TC member before but I haven't. > However, there's always a first time for everything, isn't there? I'd > like for Lib

Re: [openstack-dev] [glance] Why no DB index on sort parameters

On 4/21/15 2:47 AM, Ajaya Agrawal wrote: Hi All, I see that glance supports arbitrary sort parameters and the default is "created_at" while listing images. Is there any reason why we don't have index over these fields? If we have an index over these fields then we would avoid a full table s

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

I think getting operators to adopt it is key to getting other openstack projects to also adopt it. There is something of a chicken and the egg problem with the integration. Some of the projects you will want to integrate the most with are already considered pretty stable and may not want to rewr

Re: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 23rd

Hello, Which Docs are you referring? Please, point me to the specific Docs in private branches to find out the process to move them to public. Thanks, Edgar From: , Ruijing mailto:ruijing@intel.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstac

[openstack-dev] DVR and l2 population

Hi, As I understand it l2 population is not a requirement but it's strongly recommended. https://review.openstack.org/#/c/165311/ validates that OVS agent is configured with l2_population enabled when DVR is enabled. Now that DVR supports VLAN do we want to take back this validation ? Itzik

Re: [openstack-dev] [glance] Why no DB index on sort parameters

This is a good idea. We recently removed a unique constraint that may result into some queries being very slow especially those that involve "name" property. I would recommend sketching out a spec that identifies potential full table scans especially for queries that join over image_properties t

Re: [openstack-dev] [glance] Why no DB index on sort parameters

On 21/04/15 14:39 +, Nikhil Komawar wrote: This is a good idea. We recently removed a unique constraint that may result into some queries being very slow especially those that involve "name" property. I would recommend sketching out a spec that identifies potential full table scans especially

Re: [openstack-dev] [nova] Required data migrations in Kilo, need Turbo Hipster tests updated

> (We should also note that we can just merge a thing without turbo > hipster passing if we understand the reason for the test failure. > Sure, that breaks the rest of the turbo hipster runs, but we're not > 100% blocked here.) Indeed, the fact that it's failing actually proves the patch works, wh

Re: [openstack-dev] Fwd: Integration Gerrit with Launchpad

On 2015-04-21 10:45:02 +0900 (+0900), Kaneko Takehiro wrote: > Our project repository matches the project in Launchpad but the > bug status doesn't change(Triaged => In Progress). [...] The update_bug.py hook script in jeepyb tries to reassign a bug to the owner of the corresponding proposed chang

Re: [openstack-dev] [glance] Why no DB index on sort parameters

Rally is great overall however, we need good EXPLAIN examples on real world data. Smaller deployments might benefit from a simple sample performance analysis however, larger data sets can have impacts on areas that you never expect. A spec means that we document the indices proposed in the code

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

On 2015-04-21 03:19:04 -0400 (-0400), Attila Fazekas wrote: [...] > IMHO the OVS is less complex than netfilter (iptables, *tables), > if someone able to deal with reading the netfilter rules he should > be able to deal with OVS as well. In a simple DevStack setup, you really have that many iptabl

Re: [openstack-dev] [nova] Required data migrations in Kilo, need Turbo Hipster tests updated

Hey, So I can add support to turbo-hipster to apply migrate_flavor_data when it hits your migration (in fact I started to do this). This means the tests will pass on your change and continue to once it merges. I'll update the datasets after the next release but it'll probably be to a version

Re: [openstack-dev] [api] Minor changes to API

On 20 April 2015 at 17:52, David Kranz wrote: > On 04/20/2015 08:07 PM, Ian Wells wrote: > > Whatever your preference might be, I think it's best we lose the > ambiguity. And perhaps advertise that page a little more widely, actually > - I hadn't come across it in my travels. And perhaps impro

Re: [openstack-dev] [nova] Required data migrations in Kilo, need Turbo Hipster tests updated

> The migrate_flavor_data command didn't actually work on the CLI (unless > I'm missing something or did something odd). See > https://review.openstack.org/#/c/175890/ where I fix the requirement of > max_number. This likely means that operators have not bothered to do or > test the migrate_flavor_

[openstack-dev] [nova-docker] Where is the docker cgroups directory?

Hello, I am using nova-docker and unable to figure out where is the cgroups docker directory "/sys/fs/cgroup/cpuacct/docker" when using nova-docker hypervisor? While running a standalone docker installation the directory is located as pointed above. This is the directory used by docker to stor

Re: [openstack-dev] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!

HI Sukhdev, I also wonder how many folks are in that camp. Regardless, if we can go from 85 --> 2 (or any other much smaller number), then that is a good thing. Also, from an open source point of view, I’d like to see new contributors/vendors contributing effort on value-add innovation, and less

Re: [openstack-dev] [nova-docker] Where is the docker cgroups directory?

Hi, Somehow restarting compute node helped. Regards Ashish From: Ashish Jain (WT01 - BAS) Sent: Tuesday, April 21, 2015 9:06 PM To: openstack-dev@lists.openstack.org Subject: [nova-docker] Where is the docker cgroups directory? Hello, I am using nova-docke

Re: [openstack-dev] DVR and l2 population

Hi, with https://review.openstack.org/166707/ l2_population is only checked when tunneling is enabled. Thanks, Oleg On Tue, Apr 21, 2015 at 5:18 PM, Itzik Brown wrote: > Hi, > > As I understand it l2 population is not a requirement but it's strongly > recommended. > https://review.openstack.or

Re: [openstack-dev] [puppet] Weekly meeting #32

in the etherpad directly. > > See you tomorrow, > > [1] > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150421 > Thank you for your participation. You can read our meeting notes here: http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_op

Re: [openstack-dev] [keystone] keystonemiddleware stable/juno broken

On Sun, Apr 19, 2015 at 2:21 PM, Brant Knudson wrote: > > Ever since the stable/juno branch was created for keystonemiddleware it's > been broken and there are several changes piling up there. The fix for bug > 1408838 "Tests fail with new oslo.utils 1.2.1" allows the tests to pass. I > cherry-pi

Re: [openstack-dev] [neutron][lbaas] adding lbaas core

It’s been a week, welcome Phil. Thanks, doug > On Apr 13, 2015, at 2:39 PM, Doug Wiegley > wrote: > > Hi all, > > I'd like to nominate Philip Toohill as a neutron-lbaas core. Good guy, did a > bunch of work on the ref impl for lbaasv2, and and I'll let the numbers[1] > speak for themselves

Re: [openstack-dev] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFSSA iSCSI Driver

On 15:47 Apr 20, Diem Tran wrote: > Hi Mike, > > Oracle ZFSSA iSCSI CI is now reporting test results. It is configured > to run against the ZFSSA iSCSI driver. You can see the results here: > https://review.openstack.org/#/q/reviewer:%22Oracle+ZFSSA+CI%22,n,z > > Below are some patchsets that the

Re: [openstack-dev] [neutron][lbaas] adding lbaas core

Welcome Phil! From: Doug Wiegley Sent: Tuesday, April 21, 2015 11:54 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][lbaas] adding lbaas core It’s been a week, welcome Phil. Thanks, doug > On Ap

Re: [openstack-dev] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFSSA iSCSI Driver

On 09:57 Apr 21, Mike Perez wrote: > On 15:47 Apr 20, Diem Tran wrote: > > Hi Mike, > > > > Oracle ZFSSA iSCSI CI is now reporting test results. It is configured > > to run against the ZFSSA iSCSI driver. You can see the results here: > > https://review.openstack.org/#/q/reviewer:%22Oracle+ZFSSA+C

Re: [openstack-dev] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!

Hello Ramy Take me in account ☺ We used puppet modules located in system-config to install zuul and nodepool. Also there were a lot manual configuration. Maybe someday there will be a “green button” to set it up in moment. Thanks! From: Asselin, Ramy [mailto:ramy.asse...@hp.com] Sent: Monday,

[openstack-dev] [all][releases] upcoming library releases to unfreeze requirements in master

I'm working on releasing a *bunch* of libraries, including clients, from their master branches so we can thaw the requirements list for the liberty cycle. As with any big operation, this may be disruptive. I apologize in advance if it is, but we cannot thaw the requirements without making the relea

Re: [openstack-dev] [keystone] keystonemiddleware stable/juno broken

__ > Date: Tue, 21 Apr 2015 11:12:12 -0500 > From: b...@acm.org > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [keystone] keystonemiddleware stable/juno broken > > > > On Sun, Apr 19, 2015 at 2:21 PM, Brant Knudson > mailto:b...@acm.org>>

Re: [openstack-dev] [neutron][lbaas] adding lbaas core

Thank you! Phillip V. Toohill III Software Developer phone: 210-312-4366 mobile: 210-440-8374 From: Brandon Logan Sent: Tuesday, April 21, 2015 11:57 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutr

Re: [openstack-dev] [neutron][lbaas] adding lbaas core

I want to be friends with Phil :(. Congrats! Cheers, --Jorge On 4/21/15, 11:57 AM, "Brandon Logan" wrote: >Welcome Phil! > >From: Doug Wiegley >Sent: Tuesday, April 21, 2015 11:54 AM >To: OpenStack Development Mailing List (not for usage questions) >S

Re: [openstack-dev] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!

Hi Ramy, Will there be any discussions of this issue on the Vancouver Summit? Lenny Verkhovsky SW Engineer, Mellanox Technologies From: Nikolay Fedotov (nfedotov) [mailto:nfedo...@cisco.com] Sent: Tuesday, April 21, 2015 8:10 PM To: OpenStack Development Mailing List (not for usage questions) Su

Re: [openstack-dev] [keystone] keystonemiddleware stable/juno broken

On Tue, Apr 21, 2015 at 12:10 PM, gordon chung wrote: > __ > > Date: Tue, 21 Apr 2015 11:12:12 -0500 > > From: b...@acm.org > > To: openstack-dev@lists.openstack.org > > Subject: Re: [openstack-dev] [keystone] keystonemiddleware stable/juno > broken > > > > > > > > On

[openstack-dev] [oslo]

All, I created a patch that would introduce a new behavior in how oslo.config matches StrOpt choice values. https://review.openstack.org/#/c/167025/ I’m emailing the mailing list to get a consensus on whether the approach is the correct one. Historically oslo.config matches given StrOpt value

Re: [openstack-dev] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFSSA iSCSI Driver

On 04/21/2015 01:01 PM, Mike Perez wrote: On 09:57 Apr 21, Mike Perez wrote: On 15:47 Apr 20, Diem Tran wrote: Hi Mike, Oracle ZFSSA iSCSI CI is now reporting test results. It is configured to run against the ZFSSA iSCSI driver. You can see the results here: https://review.openstack.org/#/q/r

Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side

On 04/20/2015 06:30 PM, Claudiu Belu wrote: > Hello, > > So, AFAIK, there is currently a problem with this. If you make a request for, > let's say v2.2 microversion, you will want to execute: > > nova --os-compute-api-version 2.2 keypair-list > > But, from my experience, that does not work as e

Re: [openstack-dev] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFSSA iSCSI Driver

On 13:38 Apr 21, Diem Tran wrote: > > On 04/21/2015 01:01 PM, Mike Perez wrote: > >On 09:57 Apr 21, Mike Perez wrote: > >>On 15:47 Apr 20, Diem Tran wrote: > >>>Hi Mike, > >>> > >>>Oracle ZFSSA iSCSI CI is now reporting test results. It is configured > >>>to run against the ZFSSA iSCSI driver. You

Re: [openstack-dev] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!

On Tue, Apr 21, 2015 at 12:14 PM, Lenny Verkhovsky wrote: > Hi Ramy, > > Will there be any discussions of this issue on the Vancouver Summit? > See previous email in this thread, I have proposed a cross-project session to discuss third party CI topics. > > > *Lenny Verkhovsky* > > SW Engineer

[openstack-dev] [release] oslo.concurrency release 0.4.0 (liberty)

We are gleeful to announce the release of: debtcollector 0.4.0: A collection of Python deprecation patterns and strategies that help you collect your technical debt in a non- destructive manner. For more details, please see the git log history below and: http://launchpad.net/debtcollector/+

[openstack-dev] [release] oslo.config release 0.4.0 (liberty)

We are delighted to announce the release of: debtcollector 0.4.0: A collection of Python deprecation patterns and strategies that help you collect your technical debt in a non- destructive manner. For more details, please see the git log history below and: http://launchpad.net/debtcollector

[openstack-dev] [release] debtcollector release 0.4.0 (liberty)

We are stoked to announce the release of: debtcollector 0.4.0: A collection of Python deprecation patterns and strategies that help you collect your technical debt in a non- destructive manner. For more details, please see the git log history below and: http://launchpad.net/debtcollector/+m

[openstack-dev] [release] debtcollector release 0.4.0 (liberty)

We are psyched to announce the release of: debtcollector 0.4.0: A collection of Python deprecation patterns and strategies that help you collect your technical debt in a non- destructive manner. For more details, please see the git log history below and: http://launchpad.net/debtcollector/+

[openstack-dev] [release] oslo.concurrency release 1.9.0 (liberty)

We are delighted to announce the release of: oslo.concurrency 1.9.0: Oslo Concurrency library For more details, please see the git log history below and: http://launchpad.net/oslo.concurrency/+milestone/1.9.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.concu

[openstack-dev] [release] oslo.config release 1.11.0 (liberty)

We are glad to announce the release of: oslo.config 1.11.0: Oslo Configuration API For more details, please see the git log history below and: http://launchpad.net/oslo.config/+milestone/1.11.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.config Changes in o

[openstack-dev] [release] oslo.context release 0.3.0 (liberty)

We are satisfied to announce the release of: oslo.context 0.3.0: Oslo Context library For more details, please see the git log history below and: http://launchpad.net/oslo.context/+milestone/0.3.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.context Changes

[openstack-dev] [release] oslo.i18n release 0.1.0 (liberty)

We are content to announce the release of: oslo.i18n HEAD: oslo.i18n library For more details, please see the git log history below and: http://launchpad.net/oslo/+milestone/HEAD Please report issues through launchpad: http://bugs.launchpad.net/oslo Changes in oslo.i18n 0.1.0..HEAD -

[openstack-dev] [release] oslo.log release 1.1.0 (liberty)

We are thrilled to announce the release of: oslo.log 1.1.0: oslo.log library For more details, please see the git log history below and: http://launchpad.net/oslo.log/+milestone/1.1.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.log Changes in oslo.log 1.0.0

[openstack-dev] [release] oslo.middleware release 0.2.0 (liberty)

We are glad to announce the release of: oslo.middleware 0.2.0: Oslo Middleware library For more details, please see the git log history below and: http://launchpad.net/oslo/+milestone/0.2.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo Changes in oslo.middlew

[openstack-dev] [release] oslo.db release 1.2.0 (liberty)

We are tickled pink to announce the release of: oslo.db 1.2.0: oslo.db library For more details, please see the git log history below and: http://launchpad.net/oslo/+milestone/1.2.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo Changes in oslo.db 1.1.0..1.2.0

[openstack-dev] [release] oslotest release 1.3.0 (liberty)

We are excited to announce the release of: oslotest 1.3.0: OpenStack test framework For more details, please see the git log history below and: http://launchpad.net/oslotest/+milestone/1.3.0 Please report issues through launchpad: http://bugs.launchpad.net/oslotest Changes in oslotes

[openstack-dev] [release] oslo.rootwrap release 1.4.0 (liberty)

__ 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] [release] oslo.serialization release 1.1.0 (liberty)

We are amped to announce the release of: oslo.serialization 1.1.0: oslo.serialization library For more details, please see the git log history below and: http://launchpad.net/oslo/+milestone/1.1.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo Changes in oslo.

[openstack-dev] [release] oslo.vmware release 0.8.0 (liberty)

__ 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] [release] oslo.policy release 0.2.0 (liberty)

We are eager to announce the release of: oslo.middleware 0.2.0: Oslo Middleware library For more details, please see the git log history below and: http://launchpad.net/oslo/+milestone/0.2.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo Changes in oslo.middle

[openstack-dev] [release] python-tooz release 0.8.0 (liberty)

__ 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] [release] python-stevedore release 0.8.0 (liberty)

__ 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] [release] oslo.utils release 1.1.1 (liberty)

We are stoked to announce the release of: oslo.utils 1.1.1: Oslo Utility library For more details, please see the git log history below and: http://launchpad.net/oslo/+milestone/1.1.1 Please report issues through launchpad: http://bugs.launchpad.net/oslo Changes in oslo.utils 1.1.0..

[openstack-dev] [release] oslo.messaging release 1.9.0 (liberty)

We are glad to announce the release of: oslo.messaging 1.9.0: Oslo Messaging API For more details, please see the git log history below and: http://launchpad.net/oslo.messaging/+milestone/1.9.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.messaging Changes i

[openstack-dev] [release] python-cliff release 0.8.0 (liberty)

__ 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] [release] django_openstack_auth release 1.3.0 (liberty)

We are delighted to announce the release of: django_openstack_auth 1.3.0: Django authentication backend for use with OpenStack Identity For more details, please see the git log history below and: https://launchpad.net/django-openstack-auth/+milestone/1.3.0 Please report issues through laun

[openstack-dev] [release] # release 1.3.0 (liberty)

We are stoked to announce the release of: django_openstack_auth 1.3.0: Django authentication backend for use with OpenStack Identity For more details, please see the git log history below and: https://launchpad.net/django-openstack-auth/+milestone/1.3.0 Please report issues through launchp

[openstack-dev] [release] oslo.versionedobjects release 1.1.1 (liberty)

We are glad to announce the release of: oslo.utils 1.1.1: Oslo Utility library For more details, please see the git log history below and: http://launchpad.net/oslo/+milestone/1.1.1 Please report issues through launchpad: http://bugs.launchpad.net/oslo Changes in oslo.utils 1.1.0..1.

[openstack-dev] [release] lp release 1.3.0 (liberty)

We are glad to announce the release of: django_openstack_auth 1.3.0: Django authentication backend for use with OpenStack Identity For more details, please see the git log history below and: https://launchpad.net/django-openstack-auth/+milestone/1.3.0 Please report issues through launchpad

[openstack-dev] [release] (no release 1.3.0 (liberty)

We are stoked to announce the release of: django_openstack_auth 1.3.0: Django authentication backend for use with OpenStack Identity For more details, please see the git log history below and: https://launchpad.net/django-openstack-auth/+milestone/1.3.0 Please report issues through launchp

[openstack-dev] [release] taskflow release 0.6.0 (liberty)

We are satisfied to announce the release of: taskflow 0.6.0: Taskflow structured state management library. For more details, please see the git log history below and: http://launchpad.net/taskflow/+milestone/0.6.0 Please report issues through launchpad: http://bugs.launchpad.net/taskf

[openstack-dev] [release] pycadf release 0.6.0 (liberty)

__ 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] [release] project) release 1.3.0 (liberty)

We are glad to announce the release of: django_openstack_auth 1.3.0: Django authentication backend for use with OpenStack Identity For more details, please see the git log history below and: https://launchpad.net/django-openstack-auth/+milestone/1.3.0 Please report issues through launchpad

[openstack-dev] [release] python-barbicanclient release 3.0.1 (liberty)

__ 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] Liberty Design Summit - Proposed room / time layout

On 04/17/2015 05:00 AM, Thierry Carrez wrote: Hi PTLs, Following the slot allocation last week, here is the proposed room layout: https://docs.google.com/spreadsheets/d/1VsFdRYGbX5eCde81XDV7TrPBfEC7cgtOFikruYmqbPY/edit?usp=sharing It takes into account the following changes: - Barbican donates

[openstack-dev] [release] keystonemiddleware release 1.6.0 (liberty)

__ 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] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!

On 04/20/2015 04:39 PM, Sukhdev Kapur wrote: > Hi Ramy, > > While I agree, in principal, with this line of thinking and goal, my > concern will be how much extra work is it going to create for existing CI > owners? > Our Ci system has been stable for a long time, and we put in a good amount > of e

[openstack-dev] [release] bad release note emails

Some of the repos I was trying to generate release notes from, especially the python-fooclient repos, don't have the data in the README.rst files needed for the script to work. As a result, some of the emails are blank. I'm working on fixing that, sorry for the noise. Doug _

Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side

On 04/21/2015 11:35 AM, Hayes, Graham wrote: From: Jay Pipes [jaypi...@gmail.com] The existing --os-compute-api-version CLI option should be made to take: * 2 * \d+.\d+ * "latest" And nothing else. Yes - please don't add a flag to the cli (or the python bindings for that matter) I

Re: [openstack-dev] [neutron][lbaas] adding lbaas core

Congratulations Phil! > On Apr 21, 2015, at 11:54 AM, Doug Wiegley > wrote: > > It’s been a week, welcome Phil. > > Thanks, > doug > > >> On Apr 13, 2015, at 2:39 PM, Doug Wiegley >> wrote: >> >> Hi all, >> >> I'd like to nominate Philip Toohill as a neutron-lbaas core. Good guy, did a

Re: [openstack-dev] Fwd: Integration Gerrit with Launchpad

Heya, On 20 April 2015 at 00:26, Kaneko Takehiro wrote: > Hi, > > I'm managing a stackforge project and want to integrate Gerrit with > Launchpad. > > Links; > Git: https://git.openstack.org/cgit/stackforge/rack/ > Launchpad: https://launchpad.net/python-rack > > Project name 'rack' is duplic

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

This touches on many of the aspects of the Ops tagging to be discussed in Vancouver. What are the criteria for - An operator to consider a PoC for a new function ? We look for RDO packaging, Puppet configuration and ops/end user documentation. - An operator offering function to their end users in

[openstack-dev] [Nova] Reviewers please watch the check-tempest-dsvm-cells job now

It's been a long road but due to the hard work of bauzas and melwitt the cells Tempest check job should now be green for changes that don't break cells. The job has been red for a long time so it's likely that people don't think about it much. I would ask that until we can get the confidence

[openstack-dev] [release] oslo.config release 1.11.0 (liberty)

We are psyched to announce the release of: oslo.config 1.11.0: Oslo Configuration API For more details, please see the git log history below and: http://launchpad.net/oslo.config/+milestone/1.11.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.config Changes i

[openstack-dev] [release] oslo.concurrency release 1.9.0 (liberty)

We are tickled pink to announce the release of: oslo.concurrency 1.9.0: Oslo Concurrency library For more details, please see the git log history below and: http://launchpad.net/oslo.concurrency/+milestone/1.9.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.co

[openstack-dev] [release] oslo.i18n release 0.1.0 (liberty)

We are thrilled to announce the release of: oslo.i18n HEAD: oslo.i18n library For more details, please see the git log history below and: http://launchpad.net/oslo/+milestone/HEAD Please report issues through launchpad: http://bugs.launchpad.net/oslo Changes in oslo.i18n 0.1.0..HEAD

[openstack-dev] [release] debtcollector release 0.4.0 (liberty)

We are satisfied to announce the release of: debtcollector 0.4.0: A collection of Python deprecation patterns and strategies that help you collect your technical debt in a non- destructive manner. For more details, please see the git log history below and: http://launchpad.net/debtcollector

  1   2   >