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

Hi Keystone devs, Blueprint [1] related to request-ids is approved for Mitaka and its implementation [2] is up for review for quite a long time. I would like to apply for a goal for this blueprint so that it can be included in Newton. [1]

Re: [openstack-dev] [Nova] FPGA as a resource

On Tue, 5 Apr 2016 13:58:44 +0100 "Daniel P. Berrange" wrote: > Along similar lines we have proposals to add vGPU support to Nova, > where the vGPUs may or may not be exposed using SR-IOV. We also want > to be able to on the fly decide whether any physical GPU is assigned >

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

On Wed, Apr 6, 2016 at 1:44 PM, Qiming Teng wrote: > Not an expert of Nova but I am really shocked by such a change. Because > I'm not a Nova expert, I don't have a say on the *huge* efforts in > maintaining some builtin/default flavors. As a user I don't care where >

Re: [openstack-dev] [TripleO] FreeIPA integration

On Wed, Apr 6, 2016 at 4:06 AM, Dan Prince wrote: > On Sat, 2016-04-02 at 17:28 -0400, Adam Young wrote: > > I finally have enough understanding of what is going on with Tripleo > > to > > reasonably discuss how to implement solutions for some of the main > > security needs

Re: [openstack-dev] [Nova] FPGA as a resource

Hi, On Tue, Apr 5, 2016 at 8:58 PM, Daniel P. Berrange wrote: >> As you can see, it seems not complicated at this point, however it >> become more complex due to following things we also have to take into >> consideration: I agree with this. Many kinds of resources could be

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

Not an expert of Nova but I am really shocked by such a change. Because I'm not a Nova expert, I don't have a say on the *huge* efforts in maintaining some builtin/default flavors. As a user I don't care where the data have been stored, but I do care that they are gone. They are gone because they

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

+1000. Totally in favor of this, if anything it seems overdue, I'm a bit surprised that they aren't already deprecated. Two alternatives exist for the CLI (osc and glanceclient), and two alternatives exist for python API bindings (SDK and glanceclient). This should follow the same case with the

Re: [openstack-dev] [Nova] FPGA as a resource

Emm... finally this is brought up. We from IBM have already done some work on FPGA/GPU resource management [1]. Let me bring the SMEs into this discussion and see if we together can work out a concrete roadmap to land this upstream. Fei and Yonghua, this is indeed very interesting a topic for us.

Re: [openstack-dev] [neutron] OVSDB native interface as default in gate jobs

At Tue, 5 Apr 2016 12:57:33 -0400, Assaf Muller wrote: > > On Tue, Apr 5, 2016 at 12:35 PM, Sean M. Collins wrote: > > Russell Bryant wrote: > >> because they are related to two different command line utilities > >> (ovs-vsctl vs ovs-ofctl) that speak two different protocols

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

On 04/05/2016 05:07 PM, Michael Still wrote: As a recent newcomer to using our client libraries, my only real objection to this plan is that our client libraries as a mess [1][2]. The interfaces we expect users to use are quite different for basic things like initial auth between the various

Re: [openstack-dev] [Horizon][Searchlight] Plans for Horizon cross-region view

Sorry the for delayed response on this message. Finishing out Mitaka has been quite time consuming! Cross region searching is a high priority item for Searchlight in Newton. Steve has begun work on the spec [1] with initial prototyping. We also are considering this as a likely candidate for

Re: [openstack-dev] [ironic] [inspector] Proposing Anton Arefiev (aarefiev) for ironic-inspector-core

+1 from me, and congrats! On Wed, Apr 6, 2016 at 12:45 AM, Jim Rollenhagen wrote: > +1 from me :) > > // jim > > > On Apr 5, 2016, at 03:24, Dmitry Tantsur wrote: > > > > Hi! > > > > I'd like to propose Anton to the ironic-inspector core reviewers

Re: [openstack-dev] [TripleO] FreeIPA integration

On 04/05/2016 09:06 PM, Dan Prince wrote: On Sat, 2016-04-02 at 17:28 -0400, Adam Young wrote: I finally have enough understanding of what is going on with Tripleo to reasonably discuss how to implement solutions for some of the main security needs of a deployment. FreeIPA is an identity

Re: [openstack-dev] [TripleO] FreeIPA integration

On 04/05/2016 08:02 AM, Hayes, Graham wrote: On 02/04/2016 22:33, Adam Young wrote: I finally have enough understanding of what is going on with Tripleo to reasonably discuss how to implement solutions for some of the main security needs of a deployment. FreeIPA is an identity management

Re: [openstack-dev] [TripleO] FreeIPA integration

On 04/05/2016 11:42 AM, Fox, Kevin M wrote: Yeah, and they just deprecated vendor data plugins too, which eliminates my other workaround. :/ We need to really discuss this problem at the summit and get a viable path forward. Its just getting worse. :/ Thanks, Kevin

Re: [openstack-dev] [TripleO] FreeIPA integration

On 04/05/2016 09:01 AM, Steven Hardy wrote: On Tue, Apr 05, 2016 at 02:07:06PM +0300, Juan Antonio Osorio wrote: On Tue, Apr 5, 2016 at 11:36 AM, Steven Hardy wrote: On Sat, Apr 02, 2016 at 05:28:57PM -0400, Adam Young wrote: > I finally have enough

Re: [openstack-dev] [oslo] oslo.context and name fields

from_environ was mine, it's reasonably new and at the time i was blocked upon getting a release before pushing it out to services. Since then i've been distracted with other things. The intent at the time was exactly this to standardize the values on the context object, though in my case i was

Re: [openstack-dev] [TripleO] FreeIPA integration

On 04/05/2016 07:06 PM, Dan Prince wrote: On Sat, 2016-04-02 at 17:28 -0400, Adam Young wrote: I finally have enough understanding of what is going on with Tripleo to reasonably discuss how to implement solutions for some of the main security needs of a deployment. FreeIPA is an identity

Re: [openstack-dev] [TripleO] FreeIPA integration

On Sat, 2016-04-02 at 17:28 -0400, Adam Young wrote: > I finally have enough understanding of what is going on with Tripleo > to  > reasonably discuss how to implement solutions for some of the main  > security needs of a deployment. > > > FreeIPA is an identity management solution that can

Re: [openstack-dev] [nova] Minimal secure identification of a new VM

Adam Young wrote: We have a use case where we want to register a newly spawned Virtual machine with an identity provider. Heat also has a need to provide some form of Identity for a new VM. Looking at the set of utilities right now, there does not seem to be a secure way to do this. Injecting

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

Armando M. wrote: > I would like to understand if these need new owners (both assignees and > approvers). Code submitted [5,6] has not been touched in a while, and > whilst I appreciate people have been busy focussing on Mitaka (myself > included), the Newton master branch has been open for a

[openstack-dev] [openstack][release][keystone] Mitaka RC3 available

Hello everyone, Due to a release-critical issue spotted in Keystone during RC2 testing, a new release candidate was created for Mitaka. You can find the RC3 source code tarball at: https://tarballs.openstack.org/keystone/keystone-9.0.0.0rc3.tar.gz Unless new release-critical issues are found

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

On Tue, Apr 5, 2016 at 4:35 PM, Ian Cordasco wrote: > The goal is to centralize the server expertise and have that be combined > with the folks who know how to better design a library for a good developer > experience (kind of like with osc). That said, I think the SDK

[openstack-dev] [magnum] Collaborating topics for Magnum design summit

Hi team, As mentioned in the team meeting, Magnum team is using an etherpad [1] to collaborate topics for design summit. If you interest to join us in the Newton design summit, I would request your inputs in the etherpad. In particular, you can do the followings: * Propose new topics that you

Re: [openstack-dev] [tempest] Implementing tempest test for Keystone federation functional tests

On Tue, Apr 5, 2016 at 11:53 AM, Minying Lu wrote: > Thank you for your awesome feedbacks! > > >> Another option is to add those tests to keystone itself (if you are not >>> including tests that triggers other components APIs). See >>>

[openstack-dev] [nova] Minimal secure identification of a new VM

We have a use case where we want to register a newly spawned Virtual machine with an identity provider. Heat also has a need to provide some form of Identity for a new VM. Looking at the set of utilities right now, there does not seem to be a secure way to do this. Injecting files does not

Re: [openstack-dev] [monasca][release] missing build artifacts

Thanks for the pointer Clark. We will look into using that, although we were running out of time on the Mitaka release to get something like that implemented. Craig Bryant is in the process of manually updating the versions in the pom files to match the Mitaka tags. A couple of reviews are

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

I think in the interest of supporting the OSC effort, I am with deprecating the CLI stuff (possibly glanceclient too -- BUT in a different thread). I believe removing the bindings/modules that support possibly OSC and other libs might be lot trickier. (nova proxy stuff for glance may be an

Re: [openstack-dev] [oslo] oslo.context and name fields

I have created a version that use constructor arguments. [5] I will review in more detail across projects the use of keystone middleware to see if we can utilize a constructor environment attribute to simply constructor usage. [5] https://review.openstack.org/301918 Ronald Bradford Web Site:

Re: [openstack-dev] [all][trove] Trove bug scrub

++! 2016-04-05 17:54 GMT-03:00 Amrith Kumar : > > > *From:* Victoria Martínez de la Cruz [mailto: > victo...@vmartinezdelacruz.com] > *Sent:* Tuesday, April 05, 2016 4:35 PM > *To:* OpenStack Development Mailing List (not for usage questions) < >

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

  -Original Message- From: Michael Still Reply: Michael Still Date: April 5, 2016 at 16:30:36 To: Ian Cordasco CC: OpenStack Development Mailing List (not for usage questions) Subject: 

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

On Wed, Apr 6, 2016 at 7:28 AM, Ian Cordasco wrote: > > > -Original Message- > From: Michael Still > Reply: OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > Date: April 5, 2016 at 16:11:05 >

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

  -Original Message- From: Michael Still Reply: OpenStack Development Mailing List (not for usage questions) Date: April 5, 2016 at 16:11:05 To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

As a recent newcomer to using our client libraries, my only real objection to this plan is that our client libraries as a mess [1][2]. The interfaces we expect users to use are quite different for basic things like initial auth between the various clients, and by introducing another library we

Re: [openstack-dev] [all][trove] Trove bug scrub

From: Victoria Martínez de la Cruz [mailto:victo...@vmartinezdelacruz.com] Sent: Tuesday, April 05, 2016 4:35 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all][trove] Trove bug scrub Thanks Amrith. I'll

Re: [openstack-dev] [all][trove] Trove bug scrub

Thanks Amrith. I'll follow your lead and do some triaging as well. We should organize bug triage days to make this process easier next time. 2016-04-05 14:44 GMT-03:00 Flavio Percoco : > On 05/04/16 15:15 +, Amrith Kumar wrote: > >> If you are subscribed to bug

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

On Apr 5, 2016 2:49 PM, "Matt Riedemann" wrote: > > As we discuss the glance v2 spec for nova, questions are coming up around what to do about the nova images API which is a proxy for glance v1. > > I don't want to add glance v2 support to the nova API since that's

Re: [openstack-dev] [oslo] oslo.context and name fields

Cool. Great. In looking at this code a bit more I think we're missing out on some commonality by the fact that this nice bit of common parsing - https://github.com/openstack/oslo.context/blob/c63a359094907bc50cc5e1be716508ddee825dfa/oslo_context/context.py#L138-L161 is actually hidden behind a

[openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

As we discuss the glance v2 spec for nova, questions are coming up around what to do about the nova images API which is a proxy for glance v1. I don't want to add glance v2 support to the nova API since that's just more proxy gorp. I don't think we can just make the nova images API fail if

Re: [openstack-dev] [oslo] oslo.context and name fields

Sean, I cannot speak to historically why there were not there, but I am working through the app-agnostic-logging-parameters blueprint [1] right now and it's very related to this. As part of this work I would be reviewing attributes that are more commonly used in subclassed context objects for

Re: [openstack-dev] [magnum] Are Floating IPs really needed for all nodes?

Hi Monty, Thanks for your guidance. I have appended your inputs to the blueprint [1]. [1] https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips Best regards, Honbgin -Original Message- From: Monty Taylor [mailto:mord...@inaugust.com] Sent: March-31-16 1:18 PM To:

Re: [openstack-dev] [osc] Meeting time preferences for OSC team

On Tue, Apr 5, 2016 at 10:44 AM, Richard Theis wrote: > Here are my preferences: > > 1. even week: E.1 or E.4 > 2. odd week: O.3 > I really don't want to go against the API-WG but want to keep it on Thursday if possible: E.4 O.3 Thanks for doing this Sheel dt -- Dean

Re: [openstack-dev] [monasca][release] missing build artifacts

On Tue, Apr 5, 2016, at 11:56 AM, Hochmuth, Roland M wrote: > Thanks Doug, Thierry and Davanum. Sorry about the all the extra work that > I've caused. > > It sounds like all Python projects/deliverables are in reasonable shape, > but if not, please let me know. > > Not sure what we should do

Re: [openstack-dev] [magnum] Are Floating IPs really needed for all nodes?

Egor, I agree with you. I think Magnum should support another option to connect a bay to an existing neutron private network instead of creating one. If you like, we can discuss it separately in our next team meeting or in the design summit. Best regards, Hongbin From: Guz Egor

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

I think the only thing standing in our way is this bug [1]. Ryan Tidwell and I are working on this. Carl [1] https://bugs.launchpad.net/neutron/+bug/1543094 On Mon, Apr 4, 2016 at 3:48 PM, John Belamaric wrote: > I was on vacation last week so I am just seeing this

Re: [openstack-dev] [magnum] Are Floating IPs really needed for all nodes?

Hi all, Thanks for your inputs. We discussed this proposal in our team meeting [1], and we all agreed to support an option to remove the need of floating IPs. A blueprint was created for implementing this feature: https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips . Please

Re: [openstack-dev] [monasca][release] missing build artifacts

Thanks Doug, Thierry and Davanum. Sorry about the all the extra work that I've caused. It sounds like all Python projects/deliverables are in reasonable shape, but if not, please let me know. Not sure what we should do about the jars at this point. We had started to discuss a plan to

[openstack-dev] [nova] Launchpad bug spring cleaning day Monday 4/18

We're going to have a day of just cleaning out the launchpad bugs for Nova on Monday 4/18. This isn't a bug squashing day where people are proposing patches and the core team is reviewing them. This is purely about cleaning the garbage out of launchpad. Markus Zoeller has a nice dashboard

Re: [openstack-dev] [oslo] oslo.context and name fields

Excerpts from Sean Dague's message of 2016-04-05 14:31:46 -0400: > I was trying to clean up the divergent logging definitions in devstack > as part of scrubbing out 'tenant' references - > https://review.openstack.org/#/c/301801/ and in doing so stumbled over > the fact that the extremely useful

Re: [openstack-dev] [sahara][release] missing build artifacts

On 04/05/2016 03:56 AM, Thierry Carrez wrote: We seem to have a sahara-extra build alright: http://tarballs.openstack.org/sahara-extra/ Please ignore the noise :) ah, excellent! thanks for the clarification Thierry regards, mike

[openstack-dev] [oslo] oslo.context and name fields

I was trying to clean up the divergent logging definitions in devstack as part of scrubbing out 'tenant' references - https://review.openstack.org/#/c/301801/ and in doing so stumbled over the fact that the extremely useful project_name and user_name fields are not in base oslo.context.

Re: [openstack-dev] [all][trove] Trove bug scrub

On 05/04/16 15:15 +, Amrith Kumar wrote: If you are subscribed to bug notifications from Trove, you’d have received a lot of email from me over the past couple of days as I’ve gone through the LP bug list for the project and attempted to do some spring cleaning. Here’s (roughly) what I’ve

Re: [openstack-dev] [neutron] OVSDB native interface as default in gate jobs

On Tue, Apr 5, 2016 at 12:57 PM, Assaf Muller wrote: > On Tue, Apr 5, 2016 at 12:35 PM, Sean M. Collins > wrote: > > Russell Bryant wrote: > >> because they are related to two different command line utilities > >> (ovs-vsctl vs ovs-ofctl) that speak two

Re: [openstack-dev] [neutron] OVSDB native interface as default in gate jobs

On Tue, Apr 5, 2016 at 12:35 PM, Sean M. Collins wrote: > Russell Bryant wrote: >> because they are related to two different command line utilities >> (ovs-vsctl vs ovs-ofctl) that speak two different protocols (OVSDB vs >> OpenFlow) that talk to two different daemons on the

Re: [openstack-dev] [kloudbuster] authorization failed problem

Akshay, Note that version 6 is now released so please use the official image from the OpenStack App Catalog and update your code to latest. The doc has also been updated, you might want to have a look at the new arch section and gallery - those should help you with the questions you had below

Re: [openstack-dev] [bifrost][ironic][release] missing build artifacts

> On Apr 2, 2016, at 05:46, Doug Hellmann wrote: > > Excerpts from Julia Kreger's message of 2016-04-01 18:21:24 -0400: >>> On Fri, Apr 1, 2016 at 4:48 PM, Doug Hellmann wrote: >>> >>> Excerpts from Doug Hellmann's message of 2016-04-01 16:25:07

Re: [openstack-dev] [ironic] [inspector] Proposing Anton Arefiev (aarefiev) for ironic-inspector-core

+1 from me :) // jim > On Apr 5, 2016, at 03:24, Dmitry Tantsur wrote: > > Hi! > > I'd like to propose Anton to the ironic-inspector core reviewers team. His > stats are pretty nice [1], he's making meaningful reviews and he's pushing > important things (discovery, now

Re: [openstack-dev] [neutron] OVSDB native interface as default in gate jobs

Russell Bryant wrote: > because they are related to two different command line utilities > (ovs-vsctl vs ovs-ofctl) that speak two different protocols (OVSDB vs > OpenFlow) that talk to two different daemons on the system (ovsdb-server vs > ovs-vswitchd) ? True, they influence two different

Re: [openstack-dev] [TripleO] FreeIPA integration

I was planning to bring it up informally for TripleO. But it would be cool to have a slot to talk about this. BR On 5 Apr 2016 18:51, "Fox, Kevin M" wrote: > Yeah, and they just deprecated vendor data plugins too, which eliminates > my other workaround. :/ > > We need to

[openstack-dev] [TripleO] Austin summit sessions

All, As discussed briefly today in our weekly meeting, I've started this etherpad: https://etherpad.openstack.org/p/newton-tripleo-sessions We have two fishbowl sessions and 3 working sessions, plus a half-day contributor meetup. Please can everyone dump ideas of what topics you'd like to

Re: [openstack-dev] [nova] post-copy live migration

On 05/04/16 16:33, Daniel P. Berrange wrote: On Tue, Apr 05, 2016 at 05:17:41PM +0200, Luis Tomas wrote: Hi, We are working on the possibility of including post-copy live migration into Nova (https://review.openstack.org/#/c/301509/) At libvirt level, post-copy live migration works as follow:

Re: [openstack-dev] [osc] Meeting time preferences for OSC team

I am OK with any of the proposed times. stevemar From: Richard Theis To: Date: 2016/04/05 11:46 AM Subject:[openstack-dev] [osc] Meeting time preferences for OSC team Here are my preferences: 1. even week: E.1 or E.4

Re: [openstack-dev] [neutron][api] advanced search criteria

On Mon, Apr 4, 2016 at 7:36 PM, Armando M. wrote: > > > On 4 April 2016 at 17:08, Jay Pipes wrote: >> >> On 04/04/2016 06:57 PM, Ihar Hrachyshka wrote: >>> >>> - why do we even need to control those features with configuration >>> options? can we deprecate

Re: [openstack-dev] [TripleO] FreeIPA integration

Yeah, and they just deprecated vendor data plugins too, which eliminates my other workaround. :/ We need to really discuss this problem at the summit and get a viable path forward. Its just getting worse. :/ Thanks, Kevin From: Juan Antonio Osorio

[openstack-dev] [osc] Meeting time preferences for OSC team

Here are my preferences: 1. even week: E.1 or E.4 2. odd week: O.3 Thanks, Richard > Dear All, > > This is regarding deciding meeting time for OSC team to facilitate > appropriate time for APAC guys. > We are planning to have meeting on alternate weeks for this purpose. > > Some of the

Re: [openstack-dev] [nova] post-copy live migration

On Tue, Apr 05, 2016 at 05:17:41PM +0200, Luis Tomas wrote: > Hi, > > We are working on the possibility of including post-copy live migration into > Nova (https://review.openstack.org/#/c/301509/) > > At libvirt level, post-copy live migration works as follow: > - Start live migration with a

[openstack-dev] [nova] post-copy live migration

Hi, We are working on the possibility of including post-copy live migration into Nova (https://review.openstack.org/#/c/301509/) At libvirt level, post-copy live migration works as follow: - Start live migration with a post-copy enabler flag (VIR_MIGRATE_POSTCOPY). Note this does not

[openstack-dev] [all][trove] Trove bug scrub

If you are subscribed to bug notifications from Trove, you'd have received a lot of email from me over the past couple of days as I've gone through the LP bug list for the project and attempted to do some spring cleaning. Here's (roughly) what I've tried to do: -many bugs that have been

Re: [openstack-dev] [puppet] weekly meeting #77

rrow at 3pm UTC on > #openstack-meeting4. > > https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack > > As usual, free free to bring topics in this etherpad: > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160405 > > We'll also have open discussion for bugs &a

Re: [openstack-dev] [Fuel] branching Mitaka April 6, 2016

Hi Sergey, According to Matthew Mosesohn the plan is to delay branching of detach-* plugins. The only plugin scheduled for branching tomorrow seems to be a fuel-plugin-murano. -- Igor Belikov Fuel CI Engineer ibeli...@mirantis.com > On 04 Apr 2016, at 15:11, Sergii Golovatiuk

Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

On 01/04/16 12:31, Steven Hardy wrote: On Fri, Apr 01, 2016 at 04:15:30PM +0200, Thomas Herve wrote: On Fri, Apr 1, 2016 at 3:21 AM, Zane Bitter wrote: On 31/03/16 18:10, Zane Bitter wrote: I'm in favour of some sort of variable-based implementation for a few reasons.

Re: [openstack-dev] [congress][release] missing build artifacts

Looks like the congress job is working now. We have a tarball for our latest RC: http://tarballs.openstack.org/congress/congress-3.0.0.0rc3.tar.gz Thierry added the links back for the tarball. https://github.com/openstack/releases/commit/beee35379b3b52ed7d444d93d7afd8b6603f69b6 So it looks

Re: [openstack-dev] [tempest] Implementing tempest test for Keystone federation functional tests

Thank you for your awesome feedbacks! > Another option is to add those tests to keystone itself (if you are not >> including tests that triggers other components APIs). See >> https://blueprints.launchpad.net/keystone/+spec/keystone-tempest-plugin-tests >> >> > > knikolla and I are looking into

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

On Tuesday, April 5, 2016, Duncan Thomas wrote: > What about commands the become ambiguous in the future? I doubt there are > many operations or objects that are unique to Cinder - backup, snapshot, > transfer, group, type - these are all very much generic, and even if

Re: [openstack-dev] [TripleO] FreeIPA integration

Having an extra node for FreeIPA spawn up by heat works for me. And it's not a hard-requirement that we have to wire this into the TripleO CI. But the most sustainable approach to having TLS everywhere (at least for the admin and internal endpoints of Openstack, the message broker server nodes and

Re: [openstack-dev] [tempest] Implementing tempest test for Keystone federation functional tests

Thank you all for your awesome feedbacks! On Sun, Apr 3, 2016 at 9:07 PM, Jamie Lennox wrote: > > > On 2 April 2016 at 09:21, Rodrigo Duarte wrote: > >> >> >> On Thu, Mar 31, 2016 at 1:11 PM, Matthew Treinish >> wrote: >>

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

Duncan, Agreed, but the OSC team is concerned about unnecessarily adding API names into commands as much as the Cinder team wishes to make it clearer which commands belong to our component. This is where we need to keep this discussion open with the OSC team to find a good common ground. I am

Re: [openstack-dev] [Designate] Tempest Tests - in-repo or separate

On Tue, Apr 05, 2016 at 01:37:21PM +0100, Kiall Mac Innes wrote: > Agreed on a separate repo. > > I'm honestly a little unsure how in-service-repo would ever work long > term, given that tempest's requirements will match master, and may > not be compatible with N releases ago's $service

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

All, Just to document the discussion we had during the OSC IRC meeting last week: I believe the consensus we reached was that it wasn't appropriate to pretend "volume" before all Cinder commands but that it would be appropriate to move in that direction to for any commands that may be ambiguous

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

What about commands the become ambiguous in the future? I doubt there are many operations or objects that are unique to Cinder - backup, snapshot, transfer, group, type - these are all very much generic, and even if they aren't ambiguous now, they might well become so in future... On 5 April 2016

Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

On 05/04/16 06:43, Steven Hardy wrote: On Fri, Apr 01, 2016 at 04:39:02PM +, Fox, Kevin M wrote: Why is imperative programming always brought up when discussing conditionals in the templates? We are not wanting anything imperative. The heat engine still picks the final ordering

Re: [openstack-dev] [telemetry] Rescheduling IRC meetings

+1 to demand meetings and asynchronous way On Thu, Mar 31, 2016 at 9:33 PM, Ildikó Váncsa wrote: > Hi Gordon, > > > > > ie. the new PTL should checkpoint with subteam leads regularly to review > spec status or identify missing resources on high-priority > > items? >

Re: [openstack-dev] [cross-project] [all] Quotas and the need for reservation

>It is believed that reservation help to to reserve a set of resources >beforehand and hence eventually preventing any other upcoming request >(serial or parallel) to exceed quota if because of original request the >project might have reached the quota limits. > >Questions :- >1. Does reservation

Re: [openstack-dev] [neutron][api] advanced search criteria

Hirofumi Ichihara wrote: Hi Ihar, On 2016/04/05 7:57, Ihar Hrachyshka wrote: Hi all, in neutron, we have a bunch of configuration options to control advanced filtering features for API, f.e. allow_sorting, allow_pagination, allow_bulk, etc. Those options

Re: [openstack-dev] [telemetry] Newton design summit planning

seems fine to me. we still don't have a story around events. we just sort of store and dump it right now. i guess this could probably fit into ceilometer split session... or maybe everyone is cool with just pushing things to elasticsearch and letting users play with that + kibana. On

Re: [openstack-dev] [Nova] FPGA as a resource

On Tue, Apr 05, 2016 at 02:27:30PM +0200, Roman Dobosz wrote: > Hey all, > > On yesterday's scheduler meeting I was raised the idea of bringing up > the FPGA to the OpenStack as the resource, which than might be exposed > to the VMs. > > The use cases for motivations, why one want do this, are

Re: [openstack-dev] [TripleO] FreeIPA integration

On Tue, Apr 05, 2016 at 02:07:06PM +0300, Juan Antonio Osorio wrote: >On Tue, Apr 5, 2016 at 11:36 AM, Steven Hardy wrote: > > On Sat, Apr 02, 2016 at 05:28:57PM -0400, Adam Young wrote: > > I finally have enough understanding of what is going on with Tripleo >

[openstack-dev] [release][stable][ironic] bifrost 1.0.1 release (mitaka)

We are satisfied to announce the release of: bifrost 1.0.1: Deployment of physical machines using OpenStack Ironic and Ansible This release is part of the mitaka stable release series. For more details, please see below. Changes in bifrost 1.0.0..1.0.1 --- 83f2232

Re: [openstack-dev] [ironic] [inspector] Proposing Anton Arefiev (aarefiev) for ironic-inspector-core

Not sure if I'm eligible to vote, but his reviews are insightful, so +1 from me. Congrats! :) On Tue, Apr 5, 2016 at 3:22 PM, Imre Farkas wrote: > +1 from me. Thanks for your work Anton and congrats! ;-) > > Imre > > > > On 04/05/2016 12:24 PM, Dmitry Tantsur wrote: > >> Hi!

Re: [openstack-dev] [telemetry] Newton design summit planning

> -Original Message- > From: Chris Dent [mailto:cdent...@anticdent.org] > Sent: April 05, 2016 12:13 > > On Tue, 5 Apr 2016, Julien Danjou wrote: > > > Any items/ideas we could discussion in this remaining sessions? > > Any project we could/should invite to discuss with us? > > Nova has

Re: [openstack-dev] [Designate] Tempest Tests - in-repo or separate

Agreed on a separate repo. I'm honestly a little unsure how in-service-repo would ever work long term, given that tempest's requirements will match master, and may not be compatible with N releases ago's $service requirements.. Thoughts on how that might work, or is it just that no service has

[openstack-dev] [Nova] FPGA as a resource

Hey all, On yesterday's scheduler meeting I was raised the idea of bringing up the FPGA to the OpenStack as the resource, which than might be exposed to the VMs. The use cases for motivations, why one want do this, are pretty broad - having such chip ready on the computes might be beneficial

Re: [openstack-dev] [ironic] [inspector] Proposing Anton Arefiev (aarefiev) for ironic-inspector-core

+1 from me. Thanks for your work Anton and congrats! ;-) Imre On 04/05/2016 12:24 PM, Dmitry Tantsur wrote: Hi! I'd like to propose Anton to the ironic-inspector core reviewers team. His stats are pretty nice [1], he's making meaningful reviews and he's pushing important things (discovery,

Re: [openstack-dev] [TripleO] FreeIPA integration

On Tue, Apr 5, 2016 at 2:45 PM, Fox, Kevin M wrote: > This sounds suspiciously like, "how do you get a secret to the instance to > get a secret from the secret store" issue :) > Yeah, sounds pretty familiar. We were using the nova hooks mechanism for this means, but it

[openstack-dev] [Smaug]- IRC Meeting today (04/05) - 1400 UTC SM

Hi All, We will hold our bi-weekly IRC meeting today (Tuesday, 04/05) at 1400 UTC in #openstack-meeting Please review the proposed meeting agenda here: https://wiki.openstack.org/wiki/Meetings/smaug Please feel free to add to the agenda any subject you would like to discuss. Thanks, Saggi

Re: [openstack-dev] [TripleO] FreeIPA integration

On 02/04/2016 22:33, Adam Young wrote: > I finally have enough understanding of what is going on with Tripleo to > reasonably discuss how to implement solutions for some of the main > security needs of a deployment. > > > FreeIPA is an identity management solution that can provide support for: > >

[openstack-dev] [Heat] Design summit planning

Hi all, We've been allocated 12 sessions for Austin. I started an etherpad where you can put topics that you'd like to talk about: https://etherpad.openstack.org/p/newton-heat-sessions. Please fill it up, we'll discuss what we have at the meeting tomorrow. Maybe we'll wait until next week to

Re: [openstack-dev] [neutron] -2'ing all patches on every gate breakage

On 04/04/2016 23:20, Carl Baldwin wrote: > On Mon, Apr 4, 2016 at 3:22 PM, Doug Wiegley > wrote: >> I don’t know, -1 really means, “there is something wrong, the submitter >> should fix it and clear the slate.” Whereas -2 has two meanings. The first >> is

Re: [openstack-dev] [TripleO] FreeIPA integration

This sounds suspiciously like, "how do you get a secret to the instance to get a secret from the secret store" issue :) Nova instance user spec again? Thanks, Kevin From: Juan Antonio Osorio Sent: Tuesday, April 05, 2016 4:07:06 AM To: OpenStack Development

[openstack-dev] [nova] Nova API sub-team meeting

Hi, We have weekly Nova API meeting tomorrow. The meeting is being held Wednesday UTC1300 and irc channel is #openstack-meeting-4. The proposed agenda and meeting details are here: https://wiki.openstack.org/wiki/Meetings/NovaAPI Please feel free to add items to the agenda. Thanks

  1   2   >