Re: [openstack-dev] [tempest] Is there a sandbox project how to use tempest test plugin interface?

Hi Matthew, Thanks for the help, this helped a lot a start the work. regards Lajos On 09/10/2015 04:13 PM, Matthew Treinish wrote: On Thu, Sep 10, 2015 at 02:56:31PM +0200, Lajos Katona wrote: Hi, I just noticed that from tag 6, the test plugin interface considered ready, and I am eager to s

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 Topo

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

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 implementation

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

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 ver

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: > > As I outlined (bri

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

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

Srikumar-- I'm not aware of any particular write-up. The best advice I have is to start with the logging noop driver and refer to the reference haproxy namespace driver to see what these are doing to implement the functionality of LBaaS v2. Sorry! I wish I had better news for you. Stephen On Fr

[openstack-dev] [infra] PTL candidacy

It's time to toss my hat into the ring for Infrastructure PTL, if you'll have me. I wasn't around at the beginning like my illustrious predecessors, but I've been a core reviewer and root sysadmin for OpenStack's community-maintained project infrastructure these past three years. In that time it's

Re: [openstack-dev] [all][Elections] Nominations for OpenStack PTLs (Program Technical Leads) are now open

On Fri, Sep 11, 2015 at 10:24:17AM +1000, Tony Breeds wrote: > Nominations for OpenStack PTLs (Program Technical Leads) are now open and will > remain open until September 17, 05:59 UTC. > > All candidacies must be submitted as a text file to the openstack/election > repository as explained on the

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

Best of luck in your new adventures, and thanks for all your hard work! On Thu, Sep 10, 2015 at 5:28 PM, Dolph Mathews wrote: > Thank you for all your work, Morgan! Good luck with the opportunity to > write some code again :) > > On Thu, Sep 10, 2015 at 4:40 PM, Morgan Fainberg < > morgan.fainb.

[openstack-dev] [all][Elections] Nominations for OpenStack PTLs (Program Technical Leads) are now open

Nominations for OpenStack PTLs (Program Technical Leads) are now open and will remain open until September 17, 05:59 UTC. All candidacies must be submitted as a text file to the openstack/election repository as explained on the wiki[0]. In order to be an eligible candidate (and be allowed to vote

[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

[openstack-dev] [oslo][release] stable/juno branch creation

On Wed, Aug 26, 2015 at 03:11:56PM -0400, Doug Hellmann wrote: > Tony, > > Thanks for digging into this! > > I should be able to help, but right now we're ramping up for the L3 > feature freeze and there are a lot of release-related activities going > on. Can this wait a few weeks for things to s

Re: [openstack-dev] [oslo][release] stable/juno branch creation

+1 from me! Thanks, Dims On Thu, Sep 10, 2015 at 7:50 PM, Tony Breeds wrote: > On Wed, Aug 26, 2015 at 03:11:56PM -0400, Doug Hellmann wrote: > > Tony, > > > > Thanks for digging into this! > > > > I should be able to help, but right now we're ramping up for the L3 > > feature freeze and there

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

On Fri, Sep 11, 2015 at 6:56 AM, 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 break from t

[openstack-dev] [ceilometerclient] Updating global-requirements caps.

Hi all, In trying to fix a few stable/juno issues we need to release a new version of ceilometerclient for stable/juno. This email is to try and raise awareness so that if the proposal is bonkers [1] we can come up with something better. This isn't currently possible due to the current caps i

[openstack-dev] [neutron][nova] - removing "INVALID drop" iptables rule

Hi, I have a patch out in which I want to make sure any allow rules are processed before the rule that drops packets conntrack deems as INVALID.[1] This rule interferes with setups where conntrack might not see the first part of a TCP handshake because of encapsulation in a load balancer direct-se

Re: [openstack-dev] [Horizon]Let's take care of our integration tests

I completely agree about monitoring for integration test failures and blocking until the failure is corrected. The hope is to make sure we've stabilized the integration testing framework a bit before reenabling to vote. Thanks Timur, I know this has been a considerable undertaking. David On Thu

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

On 10/09/15 19:39, Gal Sagie wrote: > Hi James, > > I think that https://review.openstack.org/#/c/216021/ might be what you are > looking for. > Please review and see that it fits your requierment. > Hopefully this gets approved for next release and i can start working on > it, if you would like t

[openstack-dev] [magnum] Vote for our weekly meeting schedule

Hi team, Currently, magnum weekly team meeting is scheduled at Tuesday UTC1600 and UTC2200. As our team growing, contributors from different timezones joined and actively participated. I worried that our current meeting schedule (which was decided a long time ago) might not be update-to-date to

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

Thanks James for the great work done on the team! I am sure we are going to hear a lot more from you in the community ;-) Edgar On 9/10/15, 1:27 PM, "James E. Blair" wrote: >Hi, > >I've been the Infrastructure PTL for some time now and I've been >fortunate to serve during a time when we ha

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

Thank you for all your work, Morgan! Good luck with the opportunity to write some code again :) On Thu, Sep 10, 2015 at 4: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

[openstack-dev] [Horizon]Let's take care of our integration tests

It looks like we've reached the point where our Horizon integration tests are functional again. Thanks for your work on this Timur! (Offer for beer/hug at the next summit still stands) I'd like to have these tests voting again ASAP, but I understand that might be a bit risky at this point. We h

Re: [openstack-dev] [heat] Backup resources and properties in the delete-path

On 11/09/15 05:02, Zane Bitter wrote: On 10/09/15 12:53, Steven Hardy wrote: Hi all, So, I've been battling with $subject for the last few days ref [1][2]. The problem I have is that out TestResource references several properties in the delete (check_delete_complete) path[4], which it turns o

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

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 running for PTL of Keystone this next cycle (Mitaka). The role of PTL is a difficult but extremely rewarding job. It has been amazing to see

[openstack-dev] [sahara] mitaka summit session ideas

hey all, i started an etherpad for us to collect ideas about our session for the mitaka summit. https://etherpad.openstack.org/p/mitaka-sahara-session-plans please drop any thoughts or suggestions about the summit there. thanks, mike _

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

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 actual

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] [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)" > >Sent: Wednesday, September 9, 2015 5:33:01 PM >Subje

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 brea

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

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 Stanle

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 p

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 ha

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 > >mike > >On 09/04

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

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 shouldn't need such > back compa

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 >> Date: Tue Aug 18 07:55:18 2015 + >> >>Restrict PyEC

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

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 > > v1.0.9 rev of PyECLib replaces Jerasure with a n

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

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

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 space

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 (liberasurecode_rs_vand) as the default

[openstack-dev] Fwd: [kolla] Planned maintenance for Delorean instance - September 14-15

FYI -- Forwarded message -- From: Javier Pena Date: Thu, Sep 10, 2015 at 11:50 AM Subject: [Rdo-list] [delorean] Planned maintenance for Delorean instance - September 14-15 To: rdo-list Dear all, Due to a planned maintenance of the infrastructure supporting the Delorean instanc

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

On 9/10/2015 1:31 PM, Gohad, Tushar wrote: Hi Sean, To start with, "pip install PyECLib==1.0.9" works fine on a clean trusty instance. Looking at the gate log - http://logs.openstack.org/92/115092/11/check/gate-grenade-dsvm/ecfb1f5/logs/grenade.sh.txt.gz#_2015-09-10_13_54_32_069: -[snip]

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

Hi Sean, To start with, "pip install PyECLib==1.0.9" works fine on a clean trusty instance. Looking at the gate log - http://logs.openstack.org/92/115092/11/check/gate-grenade-dsvm/ecfb1f5/logs/grenade.sh.txt.gz#_2015-09-10_13_54_32_069: -[snip]- 2015-09-10 13:55:52.335 | Collecting PyECLib

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 it

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 be

[openstack-dev] [ceilometer][aodh][gnocchi] Tokyo design session planning

hi, as mentioned during today's meeting, since we have our slots for design summit, we'll start accepting proposals for the telemetry-related topics for the Tokyo summit. similar to previous design summits, anyone is welcome to propose topics related to ceilometer, aodh, gnocchi, or any othe

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

Just out of curiosity, not 100% related to this thread, but other applications also bundle configuration files (for example heat templates @ https://github.com/openstack/magnum/tree/master/magnum/templates) Should there be some guidelines on how these config files are packaged and distributed

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 preci

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

Sean Dague wrote: > On 09/10/2015 08:23 AM, Thierry Carrez wrote: >> Now another problem you're describing is that there is no single place >> where those filters end up, depending on the way the projects (or libs) >> are packaged and installed. And it's up to the distros to "fix" the >> filters_pa

[openstack-dev] [ALL] Instance Users

Many OpenStack projects have a failry common problem. The lack of well defined way for OpenStack Instances to talk to the OpenStack its running under. Each OpenStack project has been working around it themselves in one form or another, including Heat, Sahara, Trove, Magnum, and others. Zaqar an

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/10/2015 11:57 AM, Matthew Thode wrote: > I think that'd work, it'd also allow discussion on if something should > be in each section as well. I'll start assembling a spec so we can throw some darts at it. - -- Major Hayden -BEGIN PGP SIGN

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

Hi, I'm working [1] on a new Puppet modules for AODH [2]. The good news is that we don't need AODH to have alarming working in Liberty, so people using puppet to deploy Ceilometer will be able to use Alarming with future stable/liberty. I'll of course use puppet-openstack-cookiecutter to create

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Dmitry, Thanks a lot. That is exactly what I mean. fuel-createmirror can be used by a user during building ISO, after deployment, never and whenever he/she wants. Standard approach for all repos. That is it. We just don't need to put DEB MOS repo on ISO by default, because it makes little sense if

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

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 be anywhere. We could just punt in that part and s

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Vladimir, * We can not put upstream Ubuntu on ISO by default and publish it. We just can not and thus won't do that. * If a user wants to have all inclusive ISO, he/she will do it on his/her own, on his/her own machine, probably using publicly available Fuel tools, but not using Fuel CI/CD. I am

Re: [openstack-dev] [heat] Backup resources and properties in the delete-path

On 10/09/15 12:53, Steven Hardy wrote: Hi all, So, I've been battling with $subject for the last few days ref [1][2]. The problem I have is that out TestResource references several properties in the delete (check_delete_complete) path[4], which it turns out doesn't work very well if those prope

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

On 09/10/2015 11:33 AM, Major Hayden wrote: > 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 it would be best to make a "punch list" of CI

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Guys, looks like you’ve started to talk about different things. As I see, original proposal was: stop treat MOS DEB repo as a special case and use the same flow for all repos. Your use case does not contradict it. Moreover, it requires standard flow for all repos. ‘Put everything on the ISO’ u

[openstack-dev] [heat] Backup resources and properties in the delete-path

Hi all, So, I've been battling with $subject for the last few days ref [1][2]. The problem I have is that out TestResource references several properties in the delete (check_delete_complete) path[4], which it turns out doesn't work very well if those properties refer to parameters via get_param,

Re: [openstack-dev] [Neutron][ML2] ML2 late/early-cycle sprint announcement

Hi Gal, I was hoping you will join us in yesterday's ML2 meeting to discuss further. Anyhow, we would love your participation in this activity. Please check the ether pad and see if you could join us in this sprint? If yes, please sign up so that host can make appropriate arrangements. Regardless

[openstack-dev] [Glance] FFE request for parallel scrubbing

Hi, We had a request for this small spec [1] to be in Liberty. It addresses the concerns around parallel scrubbing performance improvements. The reason for asking for creating a spec was that it can rather affect performance negatively in some cases and a config is to help fine tune that. This wil

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

On Thu, Sep 10, 2015 at 10:06:31AM -0400, James Slagle wrote: > TripleO has added a few new repositories, one of which is > python-tripleoclient[1], the former python-rdomanager-oscplugin. > > With the additional repositories, there is an additional review burden > on our core reviewers. There is

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

-BEGIN PGP SIGNED MESSAGE- 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 it would be best to make a "punch list" of CIS bench

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

On 09/10/2015 09:54 AM, Major Hayden wrote: > Hey there, > > I've been looking for some ways to harden the systems that are deployed by > os-ansible-deployment (soon to be openstack-ansible?) and I've been using the > Center for Internet Security (CIS)[1] benchmarks as a potential pathway for >

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

On 10/09/15 15:06, James Slagle wrote: TripleO has added a few new repositories, one of which is python-tripleoclient[1], the former python-rdomanager-oscplugin. With the additional repositories, there is an additional review burden on our core reviewers. There is also the fact that folks who

Re: [openstack-dev] [ironic] [tripleo] [kolla] Possible to support multiple compute drivers?

On Wed, Sep 9, 2015 at 10:25 PM, Steve Gordon wrote: > - Original Message - > > From: "Jeff Peeler" > > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > > > > I'd greatly prefer using availability zones/host aggregates as I'm try

Re: [openstack-dev] SOS

Shameless plug: http://apps.openstack.org :) Thanks, Kevin From: Gongys [gong_ys2...@aliyun.com] Sent: Wednesday, September 09, 2015 8:51 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] SOS It should be easy, you g

[openstack-dev] [Congress] Ending feature freeze

Hi all, We're now finished with feature freeze. We have our first release candidate and the stable/liberty branch. So master is once again open for new features. Couple of things to note: 1. Documentation. We should also look through the docs and update them. Documentation is really important

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

On 09/10/2015 09:06 AM, James Slagle wrote: > TripleO has added a few new repositories, one of which is > python-tripleoclient[1], the former python-rdomanager-oscplugin. > > With the additional repositories, there is an additional review burden > on our core reviewers. There is also the fact that

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Folks I guess I need to get you on-site to deploy something at our user's datacenter. I do want to be able to download an ISO which contains all packages. This may not be the primary artifact of our software suite, but we need to have this opportunity to build full ISO with ALL components. Please,

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

On 9/10/2015 9:44 AM, Sean Dague wrote: The pyeclib 1.0.9 release has broken the gate because Swift is in the default grenade upgrade jobs, and Swift stable/kilo allows 1.0.9 (which doesn't compile correctly with a pip install). We're working to pin requirements in kilo/juno right now, but any

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

Hey there, I've been looking for some ways to harden the systems that are deployed by os-ansible-deployment (soon to be openstack-ansible?) and I've been using the Center for Internet Security (CIS)[1] benchmarks as a potential pathway for that. There are benchmarks available for various opera

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

The pyeclib 1.0.9 release has broken the gate because Swift is in the default grenade upgrade jobs, and Swift stable/kilo allows 1.0.9 (which doesn't compile correctly with a pip install). We're working to pin requirements in kilo/juno right now, but anything that has a grenade job is going to fai

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Vladimir, * We don't have full ISO anyway * We don't require to create mirror. When you launch your browser, do you mean to have mirror of the Internet locally? Probably, no. The same is here. Internet connection is the common requirement nowadays, but if you don't have one, you definitely need to

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Vladimir, I give my +1. We must have different repos for MOS and master node. As a sample I am giving a case when we need to implement CentOS 7 support but master node may remain on Centos 6. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Thu, Sep 10, 2015 at 3:06 PM, Vladi

Re: [openstack-dev] [Ansible][Infra] Moving ansible roles into big tent?

On Thu, Sep 10, 2015 at 09:31:47AM +0200, Yolanda Robla Mota wrote: > Hi > I will be interested as well. Having these playbooks in ansible can also be > useful > in order to integrate with infra-ansible project. > I really see that collection as a valid alternative for puppet modules, with > the ad

Re: [openstack-dev] [tempest] Is there a sandbox project how to use tempest test plugin interface?

On Thu, Sep 10, 2015 at 02:56:31PM +0200, Lajos Katona wrote: > Hi, > > I just noticed that from tag 6, the test plugin interface considered ready, > and I am eager to start to use it. > I have some questions: > > If I understand well in the future the plugin interface will be moved to > tempest-

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

On 09/10/2015 10:06 AM, James Slagle wrote: TripleO has added a few new repositories, one of which is python-tripleoclient[1], the former python-rdomanager-oscplugin. With the additional repositories, there is an additional review burden on our core reviewers. There is also the fact that folks w

[openstack-dev] [TripleO] Current meeting timeslot

Hi All, The current meeting slot for TripleO is every second Tuesday @ 1900 UTC, since that time slot was chosen a lot of people have joined the team and others have moved on, I like to revisit the timeslot to see if we can accommodate more people at the meeting (myself included). Sticking w

Re: [openstack-dev] [Fuel] Let's change the way we distribute Fuel (was: [Fuel] Remove MOS DEB repo from master node)

On Thu, Sep 10, 2015 at 4:43 PM Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > > Vladimir's proposal was to use smth similar to MiniCD > > Just to clarify. My proposal is to remove DEB MOS repo from the master > node by default and thus from the ISO. That is it. > My proposal does not as

[openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

TripleO has added a few new repositories, one of which is python-tripleoclient[1], the former python-rdomanager-oscplugin. With the additional repositories, there is an additional review burden on our core reviewers. There is also the fact that folks who have been working on the client code for a

Re: [openstack-dev] [Fuel] Let's change the way we distribute Fuel (was: [Fuel] Remove MOS DEB repo from master node)

> Vladimir's proposal was to use smth similar to MiniCD Just to clarify. My proposal is to remove DEB MOS repo from the master node by default and thus from the ISO. That is it. My proposal does not assume having internet connection during installing the master node. Fuel RPM packages together wit

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

On 09/10/2015 08:23 AM, Thierry Carrez wrote: > 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 be anywhere. We could just punt in that part and say "punt! every >> install

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Igor Having poor access to the internet is a regular use case which we must support. This is not a crazy requirement. Not having full ISO makes cloud setup harder to complete. Even more, not having hard requirement to create a mirror will detract newcomers. I can say that if I were a user and saw

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Guys, I really appreciate your opinions on whether Fuel should be all inclusive or not. But the original topic of this thread is different. I personally think that in 2015 it is not a big deal to make the master node able to access any online host (even taking into account paranoid security polici

[openstack-dev] [tempest] Is there a sandbox project how to use tempest test plugin interface?

Hi, I just noticed that from tag 6, the test plugin interface considered ready, and I am eager to start to use it. I have some questions: If I understand well in the future the plugin interface will be moved to tempest-lib, but now I have to import module(s) from tempest to start to use the

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Vladimir, Different users have different requirements. If start covering all of them, the project will become complex, buggy and unsupportable. It's a common practice to choose just one path and follow it. Obviously, some "recipes" how to achieve something could be provided, but I believe we shou

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

Hi Ramy & Evgeny, Yes, it does work. Thanks a lot. Once I thought there is no need to add the CI group for the sandbox project. Xiexs From: Asselin, Ramy [mailto:ramy.asse...@hp.com] Sent: Thursday, September 10, 2015 7:00 PM To: OpenStack Development Mailing List (not for usage questions) Sub

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

Igor This is not the case to tell users if they are stupid are not. We are working for our users, not vice versa. On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky wrote: > Mike, > > > still not exactly true for some large enterprises. Due to all the > security, etc., > > there are sometimes VPNs

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

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 be anywhere. We could just punt in that part and say "punt! every > installer and configuration management install needs to sol

[openstack-dev] Fwd: Re: [neutron][L3][dvr][fwaas] FWaaS

Hi , neutron-openvswitch-agent is crashing with below error 2015-09-10 04:39:36.675 DEBUG neutron.agent.linux.utils [req-a6c70c4e-aa40-44e4-bd09-493e82bfe43c None None] Command: ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', '--columns=name,other_config,tag', 'list', 'Port'

  1   2   >