[openstack-dev] [Ironic] There is a function to display the VGA emulation screen of BMC in the baremetal node on the Horizon?

Hello, We are investigating how to display on the Horizon a VGA emulation screen of BMC in the bare metal node that has been deployed by Ironic. If it was already implemented, I thought that the connection information of a VNC or SPICE server (converted if necessary) for a VGA emulation screen of

Re: [openstack-dev] [keystone] PTL non-candidacy

Thank you Morgan for your outstanding leadership, tremendous effort, and your dedication to OpenStack and Keystone in particular. It has been an absolute pleasure getting to work with you these past few years. And I am looking forward to working with you in your new role!!! --Brad Brad

Re: [openstack-dev] [keystone] PTL non-candidacy

Thanks for doing a great job, Morgan! Good luck on your next adventure. On Thu, Sep 10, 2015 at 7:22 PM, Adam Young wrote: > Confirming that Morgan is eligible for non-candidacy. > > You've done a great job. Thanks. > > > > On 09/10/2015 05:40 PM, Morgan Fainberg wrote: >

Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified into gerrit server

Done. Thank you for adding your CI system to the wiki. Ramy -Original Message- From: Watanabe, Isao [mailto:watanabe_i...@jp.fujitsu.com] Sent: Thursday, September 10, 2015 8:00 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [CI] [zuul]

Re: [openstack-dev] [keystone] PTL non-candidacy

Morgan, thanks for your great leadership, all the best in your new journey. Best Regards, Dave Chen From: Lance Bragstad [mailto:lbrags...@gmail.com] Sent: Friday, September 11, 2015 8:56 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev]

Re: [openstack-dev] [keystone] PTL non-candidacy

Confirming that Morgan is eligible for non-candidacy. You've done a great job. Thanks. On 09/10/2015 05:40 PM, Morgan Fainberg wrote: As I outlined (briefly) in my recent announcement of changes ( https://www.morganfainberg.com/blog/2015/09/09/openstack-career-act-3-scene-1/ ) I will not be

Re: [openstack-dev] custom lbaas driver

Just to add a little flavor and a slightly different twist from what Stephen wrote: - The logging noop driver is indeed a good first place to start. - The haproxy reference driver is the *only* driver that utilizes the lbaas-agent, and it’s being deprecated soon, so… Most vendor

Re: [openstack-dev] [CI] [zuul] Can not vote +/-1 verified into gerrit server

Hello, Ramy Could you please add the following CI to the third-party ci group, too. Fujitsu ETERNUS CI We are preparing this CI test system, and going to use this CI system to test Cinder. The wiki of this CI: Thank you

Re: [openstack-dev] [Neutron] Targeting "Logging API for SG and FW rules" feature to L-3 milestone

Good day Germy, >I have reviewed the specification linked above. Thank you for introducing >such an interesting and important feature. But as I commented inline, I >think it still need some further work to do. Such as how to get those logs >stored? To admin and tenant, I think it's different.

Re: [openstack-dev] [gate] broken by pyeclib 1.0.9 release

Note that master is pinned: commit aca1a74909d7a2841cd9805b7f57c867a1f74b73 Author: Tushar Gohad Date: Tue Aug 18 07:55:18 2015 + Restrict PyECLib version to 1.0.7 v1.0.9 rev of PyECLib replaces Jerasure with a native EC implementation

Re: [openstack-dev] [Glance] python-glanceclient 1.0.x back compat for v2 proposal.

On 11 September 2015 at 07:48, Nikhil Komawar wrote: > Hi all, > ... > 3. python-glanceclient upgrades need to be done in staged manner and by > cross-checking the rel-notes or preferably commit messages if your > deployment is fragile to upgrades. A CI/CD pipeline

Re: [openstack-dev] [gate] broken by pyeclib 1.0.9 release

+Kevin > On 10 Sep 2015, at 12:49, Robert Collins wrote: > >> On 11 September 2015 at 07:23, Robert Collins >> wrote: >> Note that master is pinned: >> >> commit aca1a74909d7a2841cd9805b7f57c867a1f74b73 >> Author: Tushar Gohad

Re: [openstack-dev] [puppet] [ceilometer] Puppetize OpenStack Aodh

On Thu, Sep 10 2015, Emilien Macchi wrote: > I'll of course use puppet-openstack-cookiecutter to create our new > module, I'll ask to Ceilometer team to have a look once we have the > basic structure in place, I have now no idea how to deploy it :-) > I guess looking at how devstack deploys it

Re: [openstack-dev] [gate] broken by pyeclib 1.0.9 release

On 11 September 2015 at 07:23, Robert Collins wrote: > Note that master is pinned: > > commit aca1a74909d7a2841cd9805b7f57c867a1f74b73 > Author: Tushar Gohad > Date: Tue Aug 18 07:55:18 2015 + > > Restrict PyECLib version to 1.0.7 > >

Re: [openstack-dev] [glance] [nova] Verification of glance images before boot

Malini, Thank you for bringing up the ³killed² state as it relates to quota. We opted to move the image to a killed state since that is what occurs when an upload fails, and the signature verification failure would occur during an upload. But we should keep in mind the potential to take up

Re: [openstack-dev] [glance] [nova] Verification of glance images before boot

The solution to this problem is to improve the scrubber to clean up the garbage data left behind in the backend store during such failed uploads. Currently, scrubber cleans up images in pending_delete and extending that to images in killed status would avoid such a situation. On 9/10/15 3:28 PM,

Re: [openstack-dev] [nova] [all] Updated String Freeze Guidelines

John Garbutt wrote: > [...] > After yesterday's cross project meeting, and hanging out in > #openstack-i18n I have come up with these updates to the String Freeze > Guidelines: > https://wiki.openstack.org/wiki/StringFreeze > > Basically, we have a Soft String Freeze from Feature Freeze until

[openstack-dev] [Glance] python-glanceclient 1.0.x back compat for v2 proposal.

Hi all, We have a review [1] that suggests adding backward compatibility to the existing CLI, that is currently defaulting to v2, to be able to support some v1 like parameters. We considered this option by consulting in Cross Project Meeting, operators list, multiple developer meetings and irc

[openstack-dev] [infra] PTL non-candidacy

Hi, I've been the Infrastructure PTL for some time now and I've been fortunate to serve during a time when we have not only grown the OpenStack project to a scale that we only hoped we would attain, but also we have grown the Infrastructure project itself into truly uncharted territory. Serving

Re: [openstack-dev] [infra] PTL non-candidacy

On 2015-09-10 13:27:53 -0700 (-0700), James E. Blair wrote: [...] > I do not plan to run for PTL in the next cycle. [...] Thanks for the awesome job you did as PTL these last cycles. I hope you enjoy a much-deserved break from the post, and I'm looking forward to the new Zuul! ;) -- Jeremy

Re: [openstack-dev] [sahara] FFE request for heat wait condition support

Seems reasonable; +1. -Ethan >- Original Message - >From: "michael mccune" >To: openstack-dev@lists.openstack.org >Sent: Friday, September 4, 2015 12:16:24 PM >Subject: Re: [openstack-dev] [sahara] FFE request for heat wait condition >support > >makes sense to me, +1 >

Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC

Excerpts from Sean Dague's message of 2015-09-10 14:11:20 -0400: > On 09/10/2015 01:05 PM, Doug Hellmann wrote: > > Excerpts from Thierry Carrez's message of 2015-09-10 14:23:34 +0200: > >> Sean Dague wrote: > >>> Right now, they are all a bunch of files, they can be anywhere. And then > >>> you

Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC

Excerpts from Thierry Carrez's message of 2015-09-10 19:35:21 +0200: > Doug Hellmann wrote: > > Excerpts from Thierry Carrez's message of 2015-09-10 14:23:34 +0200: > >> My quick 2cents on this. Rootwrap was designed as a generic solution to > >> wrap privileged calls. That's why filter files are

Re: [openstack-dev] [sahara] FFE request for scheduler and suspend EDP job for sahara

Sadly, in reviewing the client code, Vitaly is right; the current client will not support this feature, which would make it direct REST call only. Given that, I am uncertain it is worth the risk. I'd really love to have seen this go in; it's a great feature and a lot of work has gone into it,

Re: [openstack-dev] [infra] PTL non-candidacy

On Thu, Sep 10, 2015 at 08:56:58PM +, Jeremy Stanley wrote: > On 2015-09-10 13:27:53 -0700 (-0700), James E. Blair wrote: > [...] > > I do not plan to run for PTL in the next cycle. > [...] > > Thanks for the awesome job you did as PTL these last cycles. I hope > you enjoy a much-deserved

Re: [openstack-dev] [sahara] FFE request for nfs-as-a-data-source

This seems like a sanely scoped exception, and wholly agreed about spinning off the UI into a separate bp. +1. -Ethan >- Original Message - >From: "michael mccune" >To: "OpenStack Development Mailing List (not for usage questions)" >

Re: [openstack-dev] [Glance] python-glanceclient 1.0.x back compat for v2 proposal.

The client does support v1 just not by default on the CLI. Users will need to specify --os-image-api-version as 1 to be able to use v1. The change in 1.x.x series is that the default has moved from v1 to v2 and the patch proposes mocking v2 CLI into v1 like CLI calls and that can be cumbersome. I

Re: [openstack-dev] [openstack-ansible] Security hardening

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/10/2015 01:21 PM, Clint Byrum wrote: > Just a thought from somebody outside of this. If OSAD can provide the > automation, turned off by default as a convenience, and run a bank of > tests with all of these turned on to make sure they do

[openstack-dev] [nova][neutron][SR-IOV] Hardware changes and shifting PCI addresses

Hi, I was recently informed of a situation that came up when an engineer added an SR-IOV nic to a compute node that was hosting some guests that had VFs attached. Unfortunately, adding the card shuffled the PCI addresses causing some degree of havoc. Basically, the PCI addresses associated with

Re: [openstack-dev] [neutron] RFE process question

On 10 September 2015 at 11:04, James Dempsey wrote: > Greetings Devs, > > I'm very excited about the new RFE process and thought I'd test it by > requesting a feature that is very often requested by my users[1]. > > There are some great docs out there about how to submit

Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC

Doug Hellmann wrote: > Excerpts from Thierry Carrez's message of 2015-09-10 14:23:34 +0200: >> My quick 2cents on this. Rootwrap was designed as a generic solution to >> wrap privileged calls. That's why filter files are part of its >> "configuration". The problem is, OpenStack needs a pretty

Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC

On 09/10/2015 01:05 PM, Doug Hellmann wrote: > Excerpts from Thierry Carrez's message of 2015-09-10 14:23:34 +0200: >> Sean Dague wrote: >>> Right now, they are all a bunch of files, they can be anywhere. And then >>> you have other files that have to reference these files by path, which >>> can

Re: [openstack-dev] [openstack-ansible] Security hardening

Excerpts from Major Hayden's message of 2015-09-10 09:33:27 -0700: > Hash: SHA256 > > On 09/10/2015 11:22 AM, Matthew Thode wrote: > > Sane defaults can't be used? The two bugs you listed look fine to me as > > default things to do. > > Thanks, Matthew. I tend to agree. > > I'm wondering if

<    1   2