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

We had issues with physical security and unfiltered internet access last time we were in Hillsboro. Do we know if those issues are now resolved? Michael On 13 Apr 2016 9:08 AM, "Bhandaru, Malini K" wrote: Hi Everyone! Intel would be pleased to host the Nova

Re: [openstack-dev] [release][oslo] pbr 1.9.0 release

I think we need the following fixes first? https://review.openstack.org/#/c/305080/ If so let's work on merging that (if not let me know), I also see the following: https://review.openstack.org/#/c/305604/ Does that include a fix for your issue? -Josh Takashi Yamamoto wrote: hi, this

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

> In any month of any year, Oregon > San Antonio :P +1 for Hillsboro > again from me, but I'm just a tad biased :) > I have to agree with Dan here, but then again, I am also a bit biased. -- Augustina Ragwitz Sr Systems Software Engineer, HPE Cloud Hewlett Packard Enterprise --- irc:

Re: [openstack-dev] [release][oslo] pbr 1.9.0 release

hi, this version broke networking-midonet gate jobs. bug 1569680 bug 1570145 is there any chance to make another release with fixes? On Tue, Apr 12, 2016 at 10:46 PM, wrote: > We are satisfied to announce the release of: > > pbr 1.9.0: Python Build Reasonableness > >

[openstack-dev] [zaqar] Newton Design Summit Session Schedule

Hi team, The schedule of Zaqar design summit sessions is up now [1]. Some of the session descriptions might need a little bit polish, like adding etherpad links, but this is the schedule at least. And I know the schedule may conflict with yours for the summit tour, so please feel free let me know

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

Hi, Just coming from my curiosity (inline). On Thu, Apr 14, 2016 at 12:34 AM, Dan Smith wrote: >> * 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

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

Hi Cathy, A project called "neutron-classifier [1]" is also there addressing the same use case. Let's sync up and avoid work duplicity. [1] https://github.com/openstack/neutron-classifier Thanks Vikram On Apr 14, 2016 6:40 AM, "Cathy Zhang" wrote: Hi everyone, Per

Re: [openstack-dev] [keystone] Newton midycle planning

Would like to try and make it, no promises, so don't decide based on me, but, I'm with Adam: R-14 June 27-01 or R-11 July 18-22 work On Wed, Apr 13, 2016 at 8:19 PM, Adam Young wrote: > On 04/13/2016 10:07 PM, Morgan Fainberg wrote: > > It is that time again, the time to

Re: [openstack-dev] [keystone] Newton midycle planning

Thanks for volunteering to organize, I genuinely appreciate it. I'm OK with any of those weeks, the earlier the better IMO. Thanks, Steve Martinelli OpenStack Keystone Project Team Lead From: Morgan Fainberg To: "OpenStack Development Mailing List (not for

Re: [openstack-dev] [keystone] Newton midycle planning

On 04/13/2016 10:07 PM, Morgan Fainberg wrote: It is that time again, the time to plan the Keystone midcycle! Looking at the schedule [1] for Newton, the weeks that make the most sense look to be (not in preferential order): R-14 June 27-01 Might be interesting having one this early in the

[openstack-dev] [keystone] Newton midycle planning

It is that time again, the time to plan the Keystone midcycle! Looking at the schedule [1] for Newton, the weeks that make the most sense look to be (not in preferential order): R-14 June 27-01 R-12 July 11-15 R-11 July 18-22 As usual this will be a 3 day event (probably Wed, Thurs, Fri), and

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,

[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:

[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

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

[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

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)

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?

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

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

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

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 שמחון דוקטורי

[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

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

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

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

[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

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

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"

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

[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

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,

[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] [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

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 >

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

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

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

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 >>

[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] [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

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] [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

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

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

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] [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

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?

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

[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

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

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

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,

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.

[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

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),

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:

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

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

[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

[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

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

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

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

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)

[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

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 > >

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

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

[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] [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,

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

[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

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

[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

[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

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

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

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

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

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

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] [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] [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

[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

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

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

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

[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:

[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][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:

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.

[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":

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

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

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 &

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] [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

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.

[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

  1   2   >