Re: [openstack-dev] [ceilometer][tempest] disabling 'full' tempest tests for ceilometer changes in CI

+1, That make sense. Also as Ceilometer and Aodh will be running tests from plugin, I have initiated patch to remove those from Tempest. - https://review.openstack.org/#/c/304992/ Regards Ghanshyam Mann +818011120698 On Tue, Apr 12, 2016 at 9:47 PM, Chris Dent wrote: > On Tue, 12 Apr 2016, gor

Re: [openstack-dev] [Nova] RFC Host Maintenance

> -Original Message- > From: EXT Jim Rollenhagen [mailto:j...@jimrollenhagen.com] > Sent: Tuesday, April 12, 2016 4:46 PM > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [Nova] RFC Host Maintenance > > On Thu, Apr 07, 2016 at 06:36:20AM

[openstack-dev] [python-keystoneclient] Return request-id to caller

Hi All, I have submitted patches [1] for returning request-id to the caller on which Brant has raised his concerns [2]; Brant’s concern: We've tried a couple of times to have the client return metadata for the lists returned and we wound up reverting the change both times because it broke some

[openstack-dev] [neutron][taas] Problem receiving mirrored ingress traffic and a solution suggestion

Anil and all Hi, Continuing the discussion from the IRC about the problem with the mirrored traffic incoming to a VM not being mirrored. Indeed, it does look like the bug mentioned on https://bugs.launchpad.net/tap-as-a-service/+bug/1544176. I am using Liberty, ovs 2.0.2, Devstack, Single node. A

[openstack-dev] [vitrage] vitrage weekly meeting today

Hi, Due to daylight saving time issues - Vitrage meeting today will be at 9:00 UTC, which might be an hour later than usual. Ifat. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-de

Re: [openstack-dev] [ironic][nova][horizon] Serial console support for ironic instances

Hi, I also want to discuss about it at summit session. 2016-04-13 0:41 GMT+09:00 Ruby Loo : > Yes, I think it would be good to have a summit session on that. However, > before the session, it would really be helpful if the folks with proposals > got together and/or reviewed each other's proposal

Re: [openstack-dev] [TripleO][CI] Ability to reproduce failures

On Tue, Apr 12, 2016 at 11:08:28PM +0200, Gabriele Cerami wrote: > On Fri, 2016-04-08 at 16:18 +0100, Steven Hardy wrote: > > > Note we're not using devtest at all anymore, the developer script > > many > > folks use is tripleo.sh: > > So, I followed the flow of the gate jobs starting from jenkin

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

Fox, Kevin M wrote: I think my head just exploded. :) That idea's similar to neutron sfc stuff, where you just say what needs to connect to what, and it figures out the plumbing. Ideally, it would map somehow to heat & docker COE & neutron sfc to produce a final set of deployment scripts and

[openstack-dev] [magnum] Microversions usage

?I recently discovered that Magnum supports microversions [1] - but it doesn't seem to be incrementing the API in accordance with new functionality releases. Is this due to the v1 API not being locked yet? What is the status of freezing the API, so that we can move to a microversions-based relea

Re: [openstack-dev] [vitrage] vitrage weekly meeting today

Meeting minutes, for those of you who missed it: http://eavesdrop.openstack.org/meetings/vitrage/2016/vitrage.2016-04-13-09.00.html Meeting log: http://eavesdrop.openstack.org/meetings/vitrage/2016/vitrage.2016-04-13-09.00.log.html I'll send an update next week regarding the meeting time. Ifat.

Re: [openstack-dev] [kolla][vote] Nit-picking documentation changes

On Tue, Apr 12, 2016 at 10:05 PM, Steve Gordon wrote: > - Original Message - > > From: "Jeff Peeler" > > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > > > > On Mon, Apr 11, 2016 at 3:37 AM, Steven Dake (stdake) > > wrote: > >

Re: [openstack-dev] [ironic][nova][horizon] Serial console support for ironic instances

Hi >From: Yuiko Takada [mailto:yuikotakada0...@gmail.com] > >I've summarized all of related proposals. > Thanks for your summary, Yuiko Takada. It is great. I want to give you some more comments as below. >(4)Add Ironic-ipmiproxy server >https://review.openstack.org/#/c/296869/ > >* Pros: >-

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

On 04/13/2016 11:16 AM, Thierry Carrez wrote: > Fox, Kevin M wrote: >> I think my head just exploded. :) >> >> That idea's similar to neutron sfc stuff, where you just say what >> needs to connect to what, and it figures out the plumbing. >> >> Ideally, it would map somehow to heat & docker COE & n

Re: [openstack-dev] [Neutron] Newton blueprints call for action

Hello everyone! Count me in for the VLAN aware VMS. I already have a [seemingly working] proof-of-concept for the OVS driver case and expect to submit it for the review in a few days. > On 13 Apr 2016, at 12:51, Oleg Bondarev wrote: > > > -- Forwarded message -- > From: Sukh

Re: [openstack-dev] [magnum] Microversions usage

Hi Jamie On 2016年04月13日 17:26, Jamie Hannaford wrote: ​I recently discovered that Magnum supports microversions [1] - but it doesn't seem to be incrementing the API in accordance with new functionality releases. Is this due to the v1 API not being locked yet? What is the status of freezing t

[openstack-dev] [neutron][taas] service show omits the network id

Hi, Although the network id is essential argument when creating the service, it is not shown when doing show for the service. Either using cli or rest-api. *{ "tap_services": [{ "tenant_id": "619ce6d9192c494fbf3dd7947ef78f9f", "port_id": "2250affe-6a38-4678-b4ab-969c36cc

Re: [openstack-dev] [Neutron] Newton Design summit schedule - Draft

Hi guys, Note that the wiki page's timestamps<->session title was a bit outdated so I've corrected where I've seen the discrepancies. Specifically the "future of Neutron architecture" and "future of Neutron client" were swapped. John. On Tue, Apr 12, 2016 at 9:47 PM, Armando M. wrote: > > > On

[openstack-dev] [release][oslo] oslo.privsep 1.5.0 release (newton)

We are tickled pink to announce the release of: oslo.privsep 1.5.0: OpenStack library for privilege separation This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.privsep With package available at: https://pypi.pyth

[openstack-dev] [release][ironic] ironic-lib 1.3.0 release (newton)

We are content to announce the release of: ironic-lib 1.3.0: Ironic common library This release is part of the newton release series. With package available at: https://pypi.python.org/pypi/ironic-lib For more details, please see below. Changes in ironic-lib 1.1.0..1.3.0 -

[openstack-dev] [release][neutron] python-neutronclient 4.2.0 release (newton)

We are pumped to announce the release of: python-neutronclient 4.2.0: CLI and Client Library for OpenStack Networking This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/python-neutronclient With package available at: ht

Re: [openstack-dev] [vitrage] Cinder Datasource

Can you give a bit more of context? Where is the design you mentioned? By datasource you mean the Cinder service? There is already some work[1] to allow Cider to attach volumes in baremetal servers. [1] https://blueprints.launchpad.net/cinder/+spec/use-cinder-without-nova On Tue, Apr 12, 2016 at

Re: [openstack-dev] [python-keystoneclient] Return request-id to caller

On Wed, Apr 13, 2016 at 3:26 AM koshiya maho wrote: > > My request to all keystone cores to give their suggestions about the same. > > I'll test this a little and see if I can see how it breaks. Overall I'm not really a fan of this design. It's just a hack to add attributes where they don't belo

Re: [openstack-dev] [TripleO][CI] Ability to reproduce failures

On 13 April 2016 at 09:58, Steven Hardy wrote: > On Tue, Apr 12, 2016 at 11:08:28PM +0200, Gabriele Cerami wrote: >> On Fri, 2016-04-08 at 16:18 +0100, Steven Hardy wrote: >> >> > Note we're not using devtest at all anymore, the developer script >> > many >> > folks use is tripleo.sh: >> >> So, I

[openstack-dev] [release][sahara] sahara-tests 0.1.0 release (newton)

We are gleeful to announce the release of: sahara-tests 0.1.0: Sahara tests This is the first release of sahara-tests. This release is part of the newton release series. For more details, please see below. 0.1.0 ^ New Features * Sahara API tests have been imported from Tempe

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

Barbican is the abstraction layer. Its plugable like nova, neutron, cinder, etc. Thanks, Kevin From: rezroo Sent: Tuesday, April 12, 2016 11:00:30 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/cre

Re: [openstack-dev] [Nova][Neutron] [Live Migration] Prevent invalid live migration instead of failing and setting instance to error state after porbinding failed

After a great chat with Kevin we agreed to follow up the multiple binding approach until the summit and see if this is the right direction. [1] [1] http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/% 23openstack-neutron.2016-04-13.log.html#t2016-04-13T09:43:46 -- - Andreas (IRC:

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

It partially depends on if your following lightweight container methodology. Can nova api support unix sockets or bind mounts between containers in the same pod? Would it be reasonable to add that functionality? Its pretty different to novas usual use cases. Thanks, Kevin

Re: [openstack-dev] [ironic][nova][horizon] Serial console support for ironic instances

I favor the solutions that also enable logs. Thanks, Kevin From: Yuiko Takada Sent: Wednesday, April 13, 2016 1:47:15 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [ironic][nova][horizon] Serial console support fo

Re: [openstack-dev] [release][sahara] sahara-tests 0.1.0 release (newton)

On Wednesday 13 of April 2016 09:42:25 dava...@gmail.com wrote: > We are gleeful to announce the release of: > > sahara-tests 0.1.0: Sahara tests > > This is the first release of sahara-tests. This release is part of the > newton release series. > > For more details, please see below. Small cor

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

Hi Kevin, I understand that this is how it is now. My question is how bad would it be to wrap the Barbican client library calls in another class and claim, for all practical purposes, that Magnum has no direct dependency on Barbican? What is the negative of doing that? Anyone who wants to us

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

On Wed, Apr 13, 2016 at 10:26 AM, rezroo wrote: > Hi Kevin, > > I understand that this is how it is now. My question is how bad would it be > to wrap the Barbican client library calls in another class and claim, for > all practical purposes, that Magnum has no direct dependency on Barbican? > What

Re: [openstack-dev] [TripleO] Can we create some subteams?

On Mon, Apr 11, 2016 at 5:54 AM, John Trowbridge wrote: > Hola OOOers, > > It came up in the meeting last week that we could benefit from a CI > subteam with its own meeting, since CI is taking up a lot of the main > meeting time. > > I like this idea, and think we should do something similar for

Re: [openstack-dev] [release][sahara] sahara-tests 0.1.0 release (newton)

Luigi, @vgridnev, http://git.openstack.org/cgit/openstack/releases/tree/deliverables/newton/sahara-tests.yaml needs to move into _independent/deliverables/newton/sahara-tests.yaml for next time. Thanks, Dims On Wed, Apr 13, 2016 at 10:10 AM, Luigi Toscano wrote: > On Wednesday 13 of April 2016

[openstack-dev] [fuel][swift] Privileges for new user

Hi! As you may know, there's an issue with access to swift for newly created users. Here's a bug [0]. As mentioned in a comment [1] it can be fixed by two different ways: 1. Add role SwiftOperator to all newly created users. 2. Add role __member__ to swift operator_roles parameter. So, I'd like

[openstack-dev] [all] create periodic-ci-reports mailing-list

Hi, Current OpenStack Infra Periodic jobs do not send e-mails (only periodic-stable do), so I propose to create periodic-ci-reports mailing list [1] and to use it when our periodic jobs fail [2]. If accepted, people who care about periodic jobs would like to subscribe to this new ML so they can re

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

Thierry Carrez wrote: Fox, Kevin M wrote: I think my head just exploded. :) That idea's similar to neutron sfc stuff, where you just say what needs to connect to what, and it figures out the plumbing. Ideally, it would map somehow to heat & docker COE & neutron sfc to produce a final set of de

[openstack-dev] [nova] Nova API doc import, and next steps

I think we've gotten the automatic converters for the wadl files to about as good as we're going to get. The results right now are here - https://review.openstack.org/#/c/302500/ There remain many issues in the content (there are many issues in the source content, and a few crept in during imperfe

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

I think there are two questions here: 1. Should Magnum decouple from Barbican? 2. Which options Magnum should use to achieve #1 (leverage Keystone credential store, or other alternatives [1])? For question #1, Magnum team has thoughtfully discussed it. I think we all agreed that Mag

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

  -Original Message- From: Clayton O'Neill Reply: OpenStack Development Mailing List (not for usage questions) Date: April 13, 2016 at 09:39:38 To: OpenStack Development Mailing List (not for usage questions) Subject:  Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/cr

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

I think we need to ask who we are lowering the barrier of entry for. Are we going down this path because we want developers to have less things to do to stand up a development environment? Or do we want to make it easy for people to realistically test? If you're going to realistically vet magnum, w

[openstack-dev] [Nova] RPC Communication Errors Might Lead to a Bad State

Hi all, There are some cases that a communication failure between the different nova services, might cause a bad state in the system. For example, when "shelving" a VM, nova-api puts the VM's task_state as "shelving", sends an RPC to nova-compute, which shelves the VM, and resets it's task_state

Re: [openstack-dev] [Neutron] Newton blueprints call for action

On 13 April 2016 at 03:18, Ilya Chukhnakov wrote: > Hello everyone! > > Count me in for the VLAN aware VMS. I already have a [seemingly working] > proof-of-concept for the OVS driver case and expect to submit it for the > review in a few days. > > Please provide feedback on [1], as that should be

Re: [openstack-dev] [Nova] RPC Communication Errors Might Lead to a Bad State

> * nova-api should receive an acknowledgement from nova-compute. It is > unclear to me why today it uses a non-reply mechanism - probably to > free the worker as fast as it can. Yes, wherever possible, we want the API to return immediately and let the action complete later. Making a who

Re: [openstack-dev] [TripleO] Can we create some subteams?

On 04/13/2016 08:39 AM, Ryan Brady wrote: > On Mon, Apr 11, 2016 at 5:54 AM, John Trowbridge wrote: > > > Hola OOOers, > > > > It came up in the meeting last week that we could benefit from a CI > > subteam with its own meeting, since CI is taking up a lot of the main > > meeting time. > > > > I l

[openstack-dev] [nova][neutron] os-vif status report

I won't be present at the forthcoming Austin summit, so to prepare other people in case there are f2f discussions, this is a rough status report on the os-vif progress os-vif core --- NB by os-vif core, I mean the python packages in the os_vif/ namespace. The object model for describing

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

  -Original Message- From: Lance Bragstad Reply: OpenStack Development Mailing List (not for usage questions) Date: April 13, 2016 at 10:24:18 To: OpenStack Development Mailing List (not for usage questions) Subject:  Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/cre

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

On 04/12/2016 03:43 PM, Hongbin Lu wrote: Hi all, In short, some Magnum team members proposed to store TLS certificates in Keystone credential store. As Magnum PTL, I want to get agreements (or non-disagreement) from OpenStack community in general, Keystone community in particular, before ap

Re: [openstack-dev] [all] create periodic-ci-reports mailing-list

On Wed, Apr 13, 2016 at 10:59:10AM -0400, Emilien Macchi wrote: > Hi, > > Current OpenStack Infra Periodic jobs do not send e-mails (only > periodic-stable do), so I propose to create periodic-ci-reports > mailing list [1] and to use it when our periodic jobs fail [2]. > If accepted, people who ca

Re: [openstack-dev] [all] create periodic-ci-reports mailing-list

Matthew Treinish wrote: On Wed, Apr 13, 2016 at 10:59:10AM -0400, Emilien Macchi wrote: Hi, Current OpenStack Infra Periodic jobs do not send e-mails (only periodic-stable do), so I propose to create periodic-ci-reports mailing list [1] and to use it when our periodic jobs fail [2]. If accept

[openstack-dev] BoF OVN call for ideas/discussion points

Hi, There is a Birds of a Feather session on OVN at Austin. If you've got experience or questions or issues with OVN, you can register them here: https://etherpad.openstack.org/p/AUS-BoF-OVN and participate in the session: Wednesday, April 27, 1:50pm-2:30pm https://www.openstack.org/summit/aust

[openstack-dev] Nova quota statistics counting issue

Hi Team, I worked on nova quota statistics issue ( https://bugs.launchpad.net/nova/+bug/1284424) happenning when nova-* processes are restarted during removing instances and was able to reproduce it. For repro I used devstack and started nova-api and nova-compute in separate screen windows. For ki

Re: [openstack-dev] [packstack] Update packstack core list

- Original Message - > > Hello, > > I would like to step up as PTL if everybody is ok with it. > Go for it Iván! Javier > Cheers, > Ivan > > - Original Message - > > From: "Martin Magr" > > To: "OpenStack Development Mailing List (not for usage questions)" > > > > Cc: "Ja

Re: [openstack-dev] [TripleO] Can we create some subteams?

On 04/11/2016 05:54 AM, John Trowbridge wrote: > Hola OOOers, > > It came up in the meeting last week that we could benefit from a CI > subteam with its own meeting, since CI is taking up a lot of the main > meeting time. > > I like this idea, and think we should do something similar for the ot

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

For evaluation, you should be able to throw it on a single machine with the file backend and skip barbican. Why do you need to do a partially hardened config? (magnum ha but insecure) Thanks Kevin From: Clayton O'Neill [clay...@oneill.net] Sent: Wednesday

Re: [openstack-dev] [all] create periodic-ci-reports mailing-list

On Wed, Apr 13, 2016 at 06:22:50PM +0200, Ihar Hrachyshka wrote: > Matthew Treinish wrote: > > > On Wed, Apr 13, 2016 at 10:59:10AM -0400, Emilien Macchi wrote: > > > Hi, > > > > > > Current OpenStack Infra Periodic jobs do not send e-mails (only > > > periodic-stable do), so I propose to create

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Reza, The Barbican team has already abstracted python-barbicanclient into a general purpose key-storage library called Castellan [1] There are a few OpenStack projects that have planned to integrate or are currently integrating with Castellan to

[openstack-dev] [tc] Leadership training dates - please confirm attendance

Hi everyone! Quick summary of where we're at with leadership training: dates are confirmed as available with ZingTrain, and we're finalizing trainers with them right now. *June 28/29th in Ann Arbor, Michigan.* https://etherpad.openstack.org/p/Leadershiptraining Has updated info, a sample itinera

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

Andreas, Lana, Mike, Matt, and others who've been active on this thread, I've been following this conversation about installation documentation and core vs. non-core projects from afar and was under the impression that the changes being proposed would take effect for Newton and moving forward.

Re: [openstack-dev] [all] create periodic-ci-reports mailing-list

On 2016-04-13 12:58:47 -0400 (-0400), Matthew Treinish wrote: > So, sure I understand the attraction of an active notification. [...] > Instead, of pretending the ML work for doing this I think it'll be > better if we concentrate on making the dashboard for this better. Mentioned in IRC as well, b

Re: [openstack-dev] [all] create periodic-ci-reports mailing-list

On Wed, Apr 13, 2016 at 05:22:28PM +, Jeremy Stanley wrote: > On 2016-04-13 12:58:47 -0400 (-0400), Matthew Treinish wrote: > > So, sure I understand the attraction of an active notification. > [...] > > Instead, of pretending the ML work for doing this I think it'll be > > better if we concent

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

On 04/13/2016 07:17 PM, Amrith Kumar wrote: > Andreas, Lana, Mike, Matt, and others who've been active on this thread, > > I've been following this conversation about installation documentation and > core vs. non-core projects from afar and was under the impression that the > changes being propo

[openstack-dev] [nova] Proposing Andrey Kurilin for python-novaclient core

I'd like to propose that we make Andrey Kurilin core on python-novaclient. He's been doing a lot of the maintenance the last several months and a lot of times is the first to jump on any major issue, does a lot of the microversion work, and is also working on cleaning up docs and helping me wit

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

On Wed, Apr 13, 2016 at 05:17:18PM +, Amrith Kumar wrote: :Today I was informed that after a lot of effort and testing, the installation guide for Trove/Mitaka which is ready and up for review[1] has been placed on hold pending the outcome of your discussions in Austin. I've not been follow

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

On Wed, Apr 13, 2016 at 01:52:38PM -0400, Jonathan D. Proulx wrote: :I've not been following this thread at all so appologies if I'm :confused. reading follow up emails relating to timing of various submissions, I back away slowly clearly not having all the context on this one. -Jon _

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

Andreas, Thanks for your email. I am aware of the reviews you describe below but I was still under the impression that the status from the email on openstack-docs (Mitaka Install Guide testing) [1] and [2] were still valid. The understanding I had from those email threads is that the door hadn'

Re: [openstack-dev] [nova] Proposing Andrey Kurilin for python-novaclient core

Big +1. On 04/13/2016 01:53 PM, Matt Riedemann wrote: I'd like to propose that we make Andrey Kurilin core on python-novaclient. He's been doing a lot of the maintenance the last several months and a lot of times is the first to jump on any major issue, does a lot of the microversion work, and

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

Excerpts from Douglas Mendizábal's message of 2016-04-13 10:01:21 -0700: > Hash: SHA512 > > Hi Reza, > > The Barbican team has already abstracted python-barbicanclient into a > general purpose key-storage library called Castellan [1] > > There are a few OpenStack projects that have planned to in

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

Excerpts from Clayton O'Neill's message of 2016-04-13 07:37:16 -0700: > On Wed, Apr 13, 2016 at 10:26 AM, rezroo wrote: > > Hi Kevin, > > > > I understand that this is how it is now. My question is how bad would it be > > to wrap the Barbican client library calls in another class and claim, for >

[openstack-dev] [Openstack] [Ceilometer][Architecture] Transformers in Kilo vs Liberty(and Mitaka)

hi Nadya, copy/pasting full original message with comments inline to clarify some comments. i think a lot of the confusion is because we use pipeline.yaml across both polling and notification agents when really it only applies to latter. just an fyi, we've had an open work item to create a po

Re: [openstack-dev] [packstack] Update packstack core list

>> I would like to step up as PTL if everybody is ok with it. > > Go for it Iván! +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Hongbin, I have to admit that it's a bit disappointing that the Magnum team chose to decouple from Barbican, although I do understand that our team needs to do a better job of documenting detailed how-tos for deploying Barbican. I'm not sure tha

[openstack-dev] [trove] Trove weekly meeting notes

The minutes of the Trove weekly meeting are at http://eavesdrop.openstack.org/meetings/trove/2016/trove.2016-04-13-18.00.html AGREED: We decided that changes from the proposal bot (requirements, translations) can be approved on master by a single +2. The python34 gate jobs can be changed from

Re: [openstack-dev] [all] create periodic-ci-reports mailing-list

On Wed, Apr 13, 2016 at 12:13 PM, Matthew Treinish wrote: > On Wed, Apr 13, 2016 at 10:59:10AM -0400, Emilien Macchi wrote: >> Hi, >> >> Current OpenStack Infra Periodic jobs do not send e-mails (only >> periodic-stable do), so I propose to create periodic-ci-reports >> mailing list [1] and to use

Re: [openstack-dev] [nova] Proposing Andrey Kurilin for python-novaclient core

+1 Thanks for implementing microversion support, Andrey. 2016-04-13 10:53 GMT-07:00 Matt Riedemann : > I'd like to propose that we make Andrey Kurilin core on python-novaclient. > > He's been doing a lot of the maintenance the last several months and a lot > of times is the first to jump on any m

Re: [openstack-dev] [oslo] Removing Nova specifics from oslo.log

Excerpts from Julien Danjou's message of 2016-04-11 15:38:44 +0200: > Hi, > > There's a lot of assumption in oslo.log about Nova, such as talking > about "instance" and "context" in a lot of the code by default. There's > even a dependency on oslo.context. >.< > > That's being an issue for projec

Re: [openstack-dev] [oslo] Removing Nova specifics from oslo.log

Excerpts from Sean Dague's message of 2016-04-11 10:16:23 -0400: > On 04/11/2016 10:08 AM, Ed Leafe wrote: > > On 04/11/2016 08:38 AM, Julien Danjou wrote: > > > >> There's a lot of assumption in oslo.log about Nova, such as talking > >> about "instance" and "context" in a lot of the code by defau

Re: [openstack-dev] [nova] Proposing Andrey Kurilin for python-novaclient core

+1 On Wed, Apr 13, 2016, at 01:53 PM, Matt Riedemann wrote: > I'd like to propose that we make Andrey Kurilin core on > python-novaclient. > > He's been doing a lot of the maintenance the last several months and a > lot of times is the first to jump on any major issue, does a lot of the > microv

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

At Mirantis we are playing with different technologies to explore possible ways of using containers. Recently we did some POC kind of work for integration existing OpenStack components with containers technologies. Here is a link for a demo. In this POC Nova API can s

[openstack-dev] [QA] Meeting Thursday April 14th at 17:00 UTC

Hi, Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, April 14th at 17:00 UTC in the #openstack-meeting channel. The agenda for the meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_April_14th_2016_.281700_UTC.29 Anyone is

Re: [openstack-dev] [nova] Proposing Andrey Kurilin for python-novaclient core

On Wed, 13 Apr 2016 12:53:12 -0500, Matt Riedemann wrote: I'd like to propose that we make Andrey Kurilin core on python-novaclient. He's been doing a lot of the maintenance the last several months and a lot of times is the first to jump on any major issue, does a lot of the microversion work, a

[openstack-dev] [Tacker] Invalid command sfc-create

Hi all, I am trying to follow this walkthrough here: https://github.com/trozet/sfc-random/blob/master/tacker_sfc_walkthrough.txt But when I get to this point: tacker sfc-create --name mychain --chain testVNF1, I get the error: Invalid command u'sfc-create --name' 'tacker help' doesn't even li

Re: [openstack-dev] [oslo] Removing Nova specifics from oslo.log

On Wed, Apr 13 2016, Doug Hellmann wrote: >> I'm not sure why oslo.context is an issue though. That's mostly about >> putting in the common information about the identity of the requester >> into the stream. > > The context is also the place, frequently, where we know the id of the > resource on w

Re: [openstack-dev] [Tacker] Invalid command sfc-create

Hi Victor, You can use the local.conf thats in the sfc-random repo. The sfc functionality is not in upstream Tacker yet. It is here: https://github.com/trozet/sfc-random/blob/master/local.conf#L2 Tim Rozet Red Hat SDN Team - Original Message - From: "Victor Mehmeri" To: openstack-dev

Re: [openstack-dev] [Tacker] Invalid command sfc-create

Thanks, Tim! Victor -Original Message- From: Tim Rozet [mailto:tro...@redhat.com] Sent: 13. april 2016 16:01 To: OpenStack Development Mailing List (not for usage questions); Victor Mehmeri Subject: Re: [openstack-dev] [Tacker] Invalid command sfc-create Hi Victor, You can use the local

[openstack-dev] [glance] [all] Tagging sessions for other tracks

Hello everyone, The summit schedule for Glance is up [1]. I hope no-to-minimal changes at this point (besides descriptions) so, was trying to gauge some interest from other teams regarding tagging a subset of these sessions with the respective tracks. I've tagged one FB session for app-catalog+mur

Re: [openstack-dev] [nova] Proposing Andrey Kurilin for python-novaclient core

Le 13/04/2016 19:53, Matt Riedemann a écrit : I'd like to propose that we make Andrey Kurilin core on python-novaclient. He's been doing a lot of the maintenance the last several months and a lot of times is the first to jump on any major issue, does a lot of the microversion work, and is al

Re: [openstack-dev] [Cinder] Newton Midcycle Planning

On Tue, Apr 12, 2016 at 09:05:18AM -0500, Sean McGinnis wrote: All folks interested in attending the Cinder Newton Midcycle - please fill out this survey so we can collect data to help finalize a date and location: https://www.surveymonkey.com/r/L2CY3RL Thanks! Sean > Hey Cinder team (and thos

Re: [openstack-dev] [all] create periodic-ci-reports mailing-list

On Wed, Apr 13, 2016 at 2:37 PM, Emilien Macchi wrote: > On Wed, Apr 13, 2016 at 12:13 PM, Matthew Treinish > wrote: > > On Wed, Apr 13, 2016 at 10:59:10AM -0400, Emilien Macchi wrote: > >> Hi, > >> > >> Current OpenStack Infra Periodic jobs do not send e-mails (only > >> periodic-stable do), so

[openstack-dev] Community App Catalog IRC meeting Thursday April 14th

Join us Thursday for our weekly meeting, scheduled for April 14th at 17:00UTC in #openstack-meeting-3 The agenda can be found here, and please add to if you want to get something on the agenda: https://wiki.openstack.org/wiki/Meetings/app-catalog One topic that might be of interest if you are not

Re: [openstack-dev] [neutron][taas] service show omits the network id

Hi Simhon, We are in the process of removing the network-id argument from the tap-service-create API. There is a patch that has been submitted with this change and it is currently under review. We expect it to be merged very soon. Thanks, Anil From: Simhon Doctori שמחון דוקטורי [mailto:simh...

Re: [openstack-dev] [all] create periodic-ci-reports mailing-list

On 04/14/2016 03:22 AM, Jeremy Stanley wrote: Mentioned in IRC as well, but would an RSS/ATOM feed be a good compromise between active notification and focus on the dashboard as an entry point to researching job failures? For myself, simply ordering by date on the log page as per [1] would make

Re: [openstack-dev] [release][monasca][cloudkitty][neutron][stacktach] removing python 2.6 classifiers from package metadata

Excerpts from Doug Hellmann's message of 2016-02-10 09:59:54 -0500: > We stopped running tests under python 2.6 a while back, and I submitted > a bunch of patches to projects that still had the python package > classifier indicating support for python 2.6. Most of those merged, but > quite a few ar

Re: [openstack-dev] [all] create periodic-ci-reports mailing-list

On Wed, Apr 13, 2016 at 05:12:08PM -0500, Dolph Mathews wrote: > On Wed, Apr 13, 2016 at 2:37 PM, Emilien Macchi wrote: > > > On Wed, Apr 13, 2016 at 12:13 PM, Matthew Treinish > > wrote: > > > On Wed, Apr 13, 2016 at 10:59:10AM -0400, Emilien Macchi wrote: > > >> Hi, > > >> > > >> Current OpenS

Re: [openstack-dev] [nova] Newton midcycle planning

On Apr 12, 2016, at 6:07 PM, Bhandaru, Malini K wrote: > Intel would be pleased to host the Nova midcycle meetup either at San > Antonio, Texas or Hillsboro, Oregon during R-15 (June 20-24) or R-11 (July > 18-22) as preferred by the Nova community. In July? Oregon > San Antonio -- Ed Leafe

Re: [openstack-dev] [nova] Newton midcycle planning

> In July? Oregon > San Antonio In any month of any year, Oregon > San Antonio :P +1 for Hillsboro again from me, but I'm just a tad biased :) --Dan __ OpenStack Development Mailing List (not for usage questions) Unsubscrib

[openstack-dev] meeting topics for 4/14/2016 networking-sfc project IRC meeting

Hi everyone, Here are some topics I have in mind for tomorrow's meeting discussion. Feel free to add more. Meeting Info: Every Thursday 1700 UTC on #openstack-meeting-4 1. Meeting time change from Thursday 1700 UTC to Wednesday 1700 UTC? 2. Launch pad bug scrub 3. Launch pad Bluep

Re: [openstack-dev] [Tricircle] Error runnig py27

Hi, Khayam, @mock.patch('self.app.post_json') No “self.” needed. Best Regards Chaoyi Huang ( Joe Huang ) From: Khayam Gondal [mailto:khayam.gon...@gmail.com] Sent: Wednesday, April 13, 2016 2:50 PM To: OpenStack Development Mailing List (not for usage questions) Cc: joehuang; Zhiyuan Cai Subjec

[openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

Hi everyone, Per Armando's request, Louis and I are looking into the following features for Newton cycle. * Neutron Common FC used for SFC, QoS, Tap as a service etc., * OVS Agent extension Some of you might know that we already developed a FC in networking-sfc project and QoS al

[openstack-dev] [release][keystone] keystoneauth1 2.6.0 release (newton)

We are psyched to announce the release of: keystoneauth1 2.6.0: Authentication Library for OpenStack Identity This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/keystoneauth With package available at: https://pypi.pytho

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

Well, it is a myth that Docker is not linux container specific. It is born with cgroup/namespace, but the image is an app-centric way to package, nothing particular to linux container. For openstack, given the virtualization root, it is an easy win in places where requires strong isolation, multi-t

  1   2   >