Re: [openstack-dev] [nova] Feature Freeze Exception request for x509 keypairs

yea, this patch is on good shape. 2015-02-13 9:05 GMT+08:00 Ken'ichi Ohmichi : > 2015-02-12 21:20 GMT+09:00 Claudiu Belu : > > > > Hello. > > > > I would like to ask for a FFE for the x509 keypairs blueprint: > > https://blueprints.launchpad.net/nova/+spec/keypair-x509-certificates > > > > This b

[openstack-dev] [Neutron] Ryu CI scheduled outage

Ryu/ofagent CI will be offline during this weekend. sorry for inconvenience. YAMAMOTO Takashi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu

Re: [openstack-dev] [neutron][security][rootwrap] Proposal to replace rootwrap/sudo with privsep helper process (for neutron, but others too)

ᐧ > > from neutron.agent.privileged.commands import ip_lib as priv_ip > def foo(): > # Need to create a new veth interface pair - that usually requires > root/NET_ADMIN > priv_ip.CreateLink('veth', 'veth0', peer='veth1') > > Because we now have elevated privileges directly

Re: [openstack-dev] [neutron][security][rootwrap] Proposal to replace rootwrap/sudo with privsep helper process (for neutron, but others too)

On Fri Feb 13 2015 at 4:05:33 PM Robert Collins wrote: > > On 13 Feb 2015 17:42, "Angus Lees" wrote: > > > > So inspired by the "Rootwrap on root-intensive nodes" thread, I went and > wrote a proof-of-concept privsep daemon for neutron: > https://review.openstack.org/#/c/155631 > > There's nothi

Re: [openstack-dev] [neutron][security][rootwrap] Proposal to replace rootwrap/sudo with privsep helper process (for neutron, but others too)

On 13 Feb 2015 17:42, "Angus Lees" wrote: > > So inspired by the "Rootwrap on root-intensive nodes" thread, I went and wrote a proof-of-concept privsep daemon for neutron: https://review.openstack.org/#/c/155631 > There's nothing neutron-specific in the core mechanism and it could easily be moved

[openstack-dev] [cinder] Etherpad for volume replication created ...

All, Several members of the Cinder team and I were discussing the current state of volume replication while trying to figure out the best way to resolve bug 1383524 [1]. The outcome of the discussion was a decision to hold off on integrating volume replication support for additional drivers.

Re: [openstack-dev] [neutron][security][rootwrap] Proposal to replace rootwrap/sudo with privsep helper process (for neutron, but others too)

So inspired by the "Rootwrap on root-intensive nodes" thread, I went and wrote a proof-of-concept privsep daemon for neutron: https://review.openstack.org/#/c/155631 There's nothing neutron-specific in the core mechanism and it could easily be moved out into a common (oslo) library and reused acros

Re: [openstack-dev] [nova] Question about force_host skip filters

Append blueprint link: https://blueprints.launchpad.net/nova/+spec/verifiable-force-hosts 2015-02-13 10:48 GMT+08:00 Rui Chen : > I agree with you @Chris > '--force' flag is a good idea, it keep backward compatibility and > flexibility. > We can select whether the filters was applied for force_ho

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

On 5 February 2015 at 13:20, Rochelle Grober wrote: > Duncan Thomas [mailto:duncan.tho...@gmail.com] on Wednesday, February 04, > 2015 8:34 AM wrote: > > > > The downside of numbers rather than camel-case text is that they are less > likely to stick in the memory of regular users. Not a huge think

Re: [openstack-dev] [congress][Policy][Copper]Collaboration between OpenStack Congress and OPNFV Copper

THX Tim! I think It'd be great if we could have some online discussion ahead of F2F LFC summit.We could have the crash course early next week (Monday or Tuesday), and then Bryan could discuss with Sean in detail when they met, with specific questions. Would this be ok for everyone ? On Fri, Feb

Re: [openstack-dev] [nova] Question about force_host skip filters

I agree with you @Chris '--force' flag is a good idea, it keep backward compatibility and flexibility. We can select whether the filters was applied for force_hosts. I will register blueprint to trace the feature. The 'force_hosts' feature is so age-old that I don't know how many users had used it

Re: [openstack-dev] [api] Optional Properties in an Entity

Hi Brian, thanks for the response. Some comments inline :) On 02/11/2015 09:57 AM, Brian Rosmaita wrote: On 2/9/15, 8:44 PM, "Joe Gordon" mailto:joe.gord...@gmail.com>> wrote: On Mon, Feb 9, 2015 at 1:22 PM, Jay Pipes mailto:jaypi...@gmail.com>> wrote: On 01/20/2015 10:54 AM, Bria

Re: [openstack-dev] [neutron] monkey patching strategy

Why did the services fail with the stdlib patched? Are they incompatible with eventlet? On Thu, Feb 12, 2015 at 11:25 AM, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > there were some moves recently to make monkey patching strategy sane > in neutron. >

Re: [openstack-dev] [nova] Feature Freeze Exception request for x509 keypairs

2015-02-12 21:20 GMT+09:00 Claudiu Belu : > > Hello. > > I would like to ask for a FFE for the x509 keypairs blueprint: > https://blueprints.launchpad.net/nova/+spec/keypair-x509-certificates > > This blueprint is split up into 3 commits: > > [1] Database migration: previously merged, but had to be

Re: [openstack-dev] [nova] Feature Freeze Exception request for x509 keypairs

I'm happy to sponsor this. I've reviewed all the patches as well and as Claudiu mentions we have this lined up as being the first api change to use microversions Regards, Chris On Thu, Feb 12, 2015 at 10:50 PM, Claudiu Belu wrote: > > Hello. > > I would like to ask for a FFE for the x509 keyp

Re: [openstack-dev] [nova] release request for python-novaclient

This was discussed in the nova meeting this morning. In that meeting we declared ourselves unwedged and ready to do a release, and I said I'd do that today. On reflection, I want to recant just a little -- I think its a bad idea for me to do a release on a Friday. So, I'll do this early next week

Re: [openstack-dev] [congress][Policy][Copper]Collaboration between OpenStack Congress and OPNFV Copper

Bryan and Zhipeng, Sean Roberts (CCed) is planning to be in Santa Rosa. Sean’s definitely there on Wed. Less clear about Thu/Fri. I don’t know if I’ll make the trip yet, but I’m guessing Wed early afternoon if I can. Tim On Feb 11, 2015, at 9:04 PM, SULLIVAN, BRYAN L mailto:bs3...@att.com

Re: [openstack-dev] [sahara] Shell Action, Re: Running HBase Jobs (was: About Sahara Oozie plan)

Hmm, my attachments were removed :) Well, the interesting parts were the doit.sh and workflow.xml: $ more doit.sh #!/bin/bash /usr/lib/jvm/java-7-oracle-cloudera/bin/java -cp HBaseTest.jar:`hbase classpath` HBaseTest $ more workflow.xml ${jobTracker}

[openstack-dev] [sahara] Shell Action, Re: Running HBase Jobs (was: About Sahara Oozie plan)

Hi folks, Here is another way to do this. Lu had mentioned Oozie shell actions previously. Sahara doesn't support them, but I played with it from the Oozie command line to verify that it solves our hbase problem, too. We can potentially create a blueprint to build a simple Shell action around a

Re: [openstack-dev] What should openstack-specs review approval rules be ?

On Wed, Jan 28, 2015, at 08:25 AM, Thierry Carrez wrote: > Hi everyone, > > When we first introduced the cross-project specs (specs for things that > may potentially affect all OpenStack projects, or where more convergence > is desirable), we defaulted to rather simple rules for approval: > > -

Re: [openstack-dev] [all][PTLs] Stop releasing libraries/clients without capping stable global requirements

On Thu, Feb 12, 2015, at 03:47 PM, Dean Troyer wrote: > On Thu, Feb 12, 2015 at 2:22 PM, Doug Hellmann > wrote: > > > It's Thursday, so we're outside of the Oslo team's release window, so we > > > > I didn't know this was a thing. Thank You! Now let's point some other > upstream maintainers i

Re: [openstack-dev] [TripleO] update on Puppet integration in Kilo

On Wed, Feb 11, 2015 at 12:06 PM, Dan Prince wrote: > I wanted to take a few minutes to go over the progress we've made with > TripleO Puppet in Kilo so far. > > For those unfamilar with the efforts our initial goal was to be able to > use Puppet as the configuration tool for a TripleO deployment

Re: [openstack-dev] [ceilometer] nova api.fault notification isn't collected by ceilometer

Yep, that's what i'm looking for, thanks, another notification from nova that is missed in ceilometer is info from nova api: https://github.com/openstack/nova/blob/master/nova/notifications.py#L64 this notify_decorator will decorate every nova/ec2 rest api and send out a notification for each ap

Re: [openstack-dev] [API] Do we need to specify "follow the HTTP RFCs"?

On 2/12/15, 12:01, "Chris Dent" wrote: > >I meant to get to this in today's meeting[1] but we ran out of time >and based on the rest of the conversation it was likely to lead to a >spiral of different interpretations, so I thought I'd put it up here. > >$SUBJECT says it all: When writing guidelin

Re: [openstack-dev] [all][PTLs] Stop releasing libraries/clients without capping stable global requirements

On Thu, Feb 12, 2015 at 2:22 PM, Doug Hellmann wrote: > It's Thursday, so we're outside of the Oslo team's release window, so we > I didn't know this was a thing. Thank You! Now let's point some other upstream maintainers in this direction... ;) dt /me crawls back into venv-land -- Dean Tro

Re: [openstack-dev] [all][PTLs] Stop releasing libraries/clients without capping stable global requirements

On Thu, Feb 12, 2015, at 02:17 PM, Joe Gordon wrote: > On Wed, Feb 11, 2015 at 7:53 AM, Doug Hellmann > wrote: > > > > > > > On Tue, Feb 10, 2015, at 07:12 PM, Joe Gordon wrote: > > > Hi, > > > > > > As you know a few of us have been spending way too much time digging > > > stable/juno out of t

Re: [openstack-dev] [Fuel] Cache for packages on master node

On Thu, Feb 12, 2015 at 3:59 AM, Tomasz Napierala wrote: > > > On 10 Feb 2015, at 23:02, Andrew Woodward wrote: > > > > previously we used squid in 3.0 and before. The main problem is that the > deployment would proceeded even if not all the packages where cached or > even available on the remot

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

On Thu, 12 Feb 2015, Flavio Percoco wrote: On 11/02/15 11:24 +, Chris Dent wrote: I think it is time we recognize and act on the fact that the corporate landlords that pay many of us to farm on this land need to provide more resources. This will help to ensure the health of semi-artifical op

Re: [openstack-dev] [Congress][Delegation] Google doc for working notes

Hi Tim, Thanks for your response. Excited too to extend the collaboration and ensure there is no need to duplicate effort in the open source community. My responses inline. 1) Choice of LP solver. I see solver-scheduler uses Pulp, which was on the Congress short list as well. So we’re high

[openstack-dev] [neutron] monkey patching strategy

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, there were some moves recently to make monkey patching strategy sane in neutron. This was triggered by some bugs found when interacting with external oslo libraries [1], and a cross project spec to make eventlet usage sane throughout the proj

Re: [openstack-dev] What should openstack-specs review approval rules be ?

Thierry Carrez writes: > So what is it we actually want for that repository ? In a world where > Gerrit can do anything, what would you like to have ? > > Personally, I want our technical community in general, and our PTLs/CPLs > in particular, to be able to record their opinion on the proposed >

Re: [openstack-dev] [API] Do we need to specify "follow the HTTP RFCs"?

On 02/12/2015 01:08 PM, Jay Pipes wrote: > On 02/12/2015 01:01 PM, Chris Dent wrote: >> I meant to get to this in today's meeting[1] but we ran out of time >> and based on the rest of the conversation it was likely to lead to a >> spiral of different interpretations, so I thought I'd put it up here

Re: [openstack-dev] [all][PTLs] Stop releasing libraries/clients without capping stable global requirements

On Wed, Feb 11, 2015 at 7:53 AM, Doug Hellmann wrote: > > > On Tue, Feb 10, 2015, at 07:12 PM, Joe Gordon wrote: > > Hi, > > > > As you know a few of us have been spending way too much time digging > > stable/juno out of the ditch its currently in. And just when we thought > > we > > were in the

Re: [openstack-dev] [keystone] [nova]

On 02/12/2015 10:40 AM, Alexander Makarov wrote: A trust token cannot be used to get another token: https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156 You have to make your Nova client use the very same trust scoped token obtained from authentication using

Re: [openstack-dev] [Neutron] Update on "DB" IPAM driver

From: Salvatore Orlando mailto:sorla...@nicira.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Thursday, February 12, 2015 at 8:36 AM To: OpenStack Development Mailing List mailto:openstack-dev@lists.openstack.org>>

[openstack-dev] [oslo.messaging] notification listener; same target with multiple executors

Is it possible to have multiple oslo messaging notification listeners using different executors on the same target? For example, I was to create multiple notification listeners [1] each using a different executor for the same set of targets (e.g. glance/notifications). When I try this [2], only

Re: [openstack-dev] [nova] issues with fakelibvirt in tests

On Thu, Feb 12, 2015 at 01:17:55PM -0500, Sean Dague wrote: > On 02/12/2015 01:09 PM, Daniel P. Berrange wrote: > > On Thu, Feb 12, 2015 at 12:32:10PM -0500, Sean Dague wrote: > >> Looking recently at the following failure - > >> http://logs.openstack.org/04/154804/1/gate/gate-nova-python27/1fe94bf

[openstack-dev] [nova] FFE Request: Proxy neutron configuration to guest instance

Hi Nova cores, We’d like to request an FFE for this added nova feature. It gives a real interface - a JSON file - to network data inside the instance. This is a patch Rackspace carries downstream, and we’ve had lots of interested users, including the OpenStack Infra team and upstream cloud-init

Re: [openstack-dev] [nova] issues with fakelibvirt in tests

On 02/12/2015 01:09 PM, Daniel P. Berrange wrote: > On Thu, Feb 12, 2015 at 12:32:10PM -0500, Sean Dague wrote: >> Looking recently at the following failure - >> http://logs.openstack.org/04/154804/1/gate/gate-nova-python27/1fe94bf/console.html#_2015-02-12_15_02_19_593 >> >> It appears that the fak

Re: [openstack-dev] [nova] issues with fakelibvirt in tests

On Thu, Feb 12, 2015 at 11:49:12AM -0600, Matt Riedemann wrote: > > > On 2/12/2015 11:32 AM, Sean Dague wrote: > >Looking recently at the following failure - > >http://logs.openstack.org/04/154804/1/gate/gate-nova-python27/1fe94bf/console.html#_2015-02-12_15_02_19_593 > > > >It appears that the f

Re: [openstack-dev] [nova] issues with fakelibvirt in tests

On Thu, Feb 12, 2015 at 12:32:10PM -0500, Sean Dague wrote: > Looking recently at the following failure - > http://logs.openstack.org/04/154804/1/gate/gate-nova-python27/1fe94bf/console.html#_2015-02-12_15_02_19_593 > > It appears that the fakelibvirt fixture is potentially causing races in > test

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

On 2015-02-12 18:34:56 +0100 (+0100), Flavio Percoco wrote: [...] > we *don't* have a public voip channel [...] Well, technically we do if you want one. https://wiki.openstack.org/wiki/Infrastructure/Conferencing But of course the logistics around all the project connecting in and talking at onc

Re: [openstack-dev] [API] Do we need to specify "follow the HTTP RFCs"?

On 02/12/2015 01:01 PM, Chris Dent wrote: I meant to get to this in today's meeting[1] but we ran out of time and based on the rest of the conversation it was likely to lead to a spiral of different interpretations, so I thought I'd put it up here. $SUBJECT says it all: When writing guidelines t

Re: [openstack-dev] [Congress][Delegation] Google doc for working notes

Hi Debo and Yathiraj, I took a third look at the solver-scheduler docs and code with your comments in mind. A few things jumped out. 1) Choice of LP solver. I see solver-scheduler uses Pulp, which was on the Congress short list as well. So we’re highly aligned on the choice of underlying so

Re: [openstack-dev] [Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested

Hi, My experience with Ceilometer is that MongoDB is/was a major bottleneck. You need sharding + servers with lot of RAM. You need to set TTL on your samples, and only save in DB the metrics that really mater to you. MongoDB v3 should also help. Regarding RabbitMQ pressure, I think this blueprint

[openstack-dev] [API] Do we need to specify "follow the HTTP RFCs"?

I meant to get to this in today's meeting[1] but we ran out of time and based on the rest of the conversation it was likely to lead to a spiral of different interpretations, so I thought I'd put it up here. $SUBJECT says it all: When writing guidelines to what extent do we think we should be rec

Re: [openstack-dev] [defcore] Proposal for new openstack/defcore repository

On 02/12/2015 12:47 PM, Chris Hoge wrote: > In the most recent Defcore committee meeting we discussed the need > for a repository to host artifacts related to the Defcore process[1]. > These artifacts will include documentation of the Defcore process, > lists of advisory and required capabilities f

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

On 12/02/15 12:04 +, Chris Dent wrote: On Thu, 12 Feb 2015, Flavio Percoco wrote: The important bit, thoguh, is that email is meant for asynchronous communication and IRC isn't. If things that require the intervention of other folks from the community are being discussed and those folks are

Re: [openstack-dev] [nova] issues with fakelibvirt in tests

On 2/12/2015 11:32 AM, Sean Dague wrote: Looking recently at the following failure - http://logs.openstack.org/04/154804/1/gate/gate-nova-python27/1fe94bf/console.html#_2015-02-12_15_02_19_593 It appears that the fakelibvirt fixture is potentially causing races in tests because after the first

[openstack-dev] [defcore] Proposal for new openstack/defcore repository

In the most recent Defcore committee meeting we discussed the need for a repository to host artifacts related to the Defcore process[1]. These artifacts will include documentation of the Defcore process, lists of advisory and required capabilities for releases, and useful tools and instructions

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

On 11/02/15 11:24 +, Chris Dent wrote: On Wed, 11 Feb 2015, Flavio Percoco wrote: During the last two cycles, I've had the feeling that some of the things I love the most about this community are degrading and moving to a state that I personally disagree with. With the hope of seeing these

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

On 12/02/15 16:01 +, Amrith Kumar wrote: Flavio, Thanks for your email. I've read your response as well as those from all the others who responded and one thing is very unclear to me in the position being advanced. You write, and other respondents appear to share the following sentiment:

Re: [openstack-dev] [glance] File-backed glance scrubber queue

Yeah, that commit definitely disables the file-backed queue -- it certainly *looks* like we want to be rid of it, but all of the code is left in place and even updated to support the new format. So my confusion remains. Hopefully Zhi Yan can clarify. Link added. Thanks. On Thu, Feb 12, 2015 at 12

[openstack-dev] [nova] issues with fakelibvirt in tests

Looking recently at the following failure - http://logs.openstack.org/04/154804/1/gate/gate-nova-python27/1fe94bf/console.html#_2015-02-12_15_02_19_593 It appears that the fakelibvirt fixture is potentially causing races in tests because after the first test in a worker starts a libvirt connection

Re: [openstack-dev] [Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested

Hi Mash, we dropped Ceilometer as the core tool to gather metrics for our rating and billing system. I must admit it has improved, but I think it's broken by design: a metering and monitoring system is not the same thing. We have built a component that directly listens from rabbit notification to

Re: [openstack-dev] [Murano] [API WG] Environment status

On 02/12/2015 10:52 AM, Georgy Okrokvertskhov wrote: > I think this is a good case for API WG as statuses of entities should be > consistent among OpenStack APIs. As I recall, we are mixing two > different statuses for environments. The first dimension for environment > status is its content status

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

On 2015-02-12 17:20:37 +0100 (+0100), Alan Pevec wrote: > Discussing CVEs in private came up few times but I'm not sure IRC > is secure enough for that. IMHO discussion about embargoed issues > must be kept in private Launchpad bugs but I'd like to hear from > VMT team. I do from time to time /msg

Re: [openstack-dev] [Designate] Core reviewer update

Thanks all, I’m honored :) —Tim On Feb 12, 2015, at 10:31 AM, Kiall Mac Innes mailto:ki...@macinnes.ie>> wrote: Changes have been applied, welcome Tim :) On 12/02/15 16:18, Rich Megginson wrote: On 02/12/2015 08:51 AM, Hayes, Graham wrote: On 12/02/15 15:50, Kiall Mac Innes wrote: +1 - Tim has

[openstack-dev] SDN Security in OpenStack

Hi all, I am a software developer working at HP, I do not work with OpenStack @HP though, only worked with it privately. I am finishing up a Masters and for my dissertation research I am focusing on SDN Security. I wanted to align my research to current SDN uses in the industry and was interest

Re: [openstack-dev] [Designate] Core reviewer update

Changes have been applied, welcome Tim :) On 12/02/15 16:18, Rich Megginson wrote: > On 02/12/2015 08:51 AM, Hayes, Graham wrote: >> On 12/02/15 15:50, Kiall Mac Innes wrote: >>> +1 - Tim has been giving good reviews over the last few months and will >>> make a good addition.. >>> >>> Thanks, >>>

[openstack-dev] [Fuel][Plugins] Versioning, branching, tagging

Hello! I would like to discuss which policy we want to recommend for the versioning, branching and tagging for FUEL plugins and how it should correlate with FUEL/MOS versions/releases. According Fuel Plug-in Guide

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

>> I think there's a place for >> private conversation (eg. discussing a security issue that corresponds >> to a CVE... > CVE's are a special exception and I'd even argue on the need of > private conversations there. Discussing CVEs in private came up few times but I'm not sure IRC is secure enou

Re: [openstack-dev] [Designate] Core reviewer update

On 02/12/2015 08:51 AM, Hayes, Graham wrote: On 12/02/15 15:50, Kiall Mac Innes wrote: +1 - Tim has been giving good reviews over the last few months and will make a good addition.. Thanks, Kiall On 12/02/15 15:40, Vinod Mangalpally wrote: Hello Designate folks, Betsy Luzader (betsy) resigne

[openstack-dev] [vmware-api] Weekly meeting

Hi, Over the last few IRC meetings we have discussed the following: 1. Providing a platform for people other than those working on the Nova driver to take part. There are efforts with the Glance, Cinder, Ceilometer and Neutron projects. Hopefully people working on those can also take part and

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

Flavio, Thanks for your email. I've read your response as well as those from all the others who responded and one thing is very unclear to me in the position being advanced. You write, and other respondents appear to share the following sentiment: | I personally don't care if you have private

Re: [openstack-dev] [Murano] [API WG] Environment status

I think this is a good case for API WG as statuses of entities should be consistent among OpenStack APIs. As I recall, we are mixing two different statuses for environments. The first dimension for environment status is its content status: NEW, CONFIGURING, READY The second dimension is deployment

Re: [openstack-dev] [Designate] Core reviewer update

On 12/02/15 15:50, Kiall Mac Innes wrote: > +1 - Tim has been giving good reviews over the last few months and will > make a good addition.. > > Thanks, > Kiall > > On 12/02/15 15:40, Vinod Mangalpally wrote: >> Hello Designate folks, >> >> Betsy Luzader (betsy) resigned from her core reviewer po

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

On 2015-02-12 10:35:18 + (+), Kuvaja, Erno wrote: [...] > I'd like to point out that that this discussion has been pushing > all inclusive open approach. Not ATC, not specially approved > individuals, but everyone. Mailing list can easily facilitate > participation of everyone who wishes to

Re: [openstack-dev] [Designate] Core reviewer update

+1 - Tim has been giving good reviews over the last few months and will make a good addition.. Thanks, Kiall On 12/02/15 15:40, Vinod Mangalpally wrote: > Hello Designate folks, > > Betsy Luzader (betsy) resigned from her core reviewer position on > Designate. In order to keep the momentum of re

Re: [openstack-dev] [glance] Metadef-tags create api change request.

On 2/12/15, 9:57 AM, "Ian Cordasco" wrote: >On 2/11/15, 11:10, "Okuma, Wayne" wrote: > >>Hello, >> >>I would like to change the metadef-tags create API which was checked into >>Kilo (cycle 1). >>The python-glanceclient that would support metadef-tags has not been >>released yet and I would like

Re: [openstack-dev] [keystone] [nova]

A trust token cannot be used to get another token: https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156 You have to make your Nova client use the very same trust scoped token obtained from authentication using trust without trying to authenticate with it one mor

[openstack-dev] [Designate] Core reviewer update

Hello Designate folks, Betsy Luzader (betsy) resigned from her core reviewer position on Designate. In order to keep the momentum of reviews in Designate going, I'd like to propose adding Tim Simmons (timsim) to designate-core. For context on Designate reviews and who has been active, please se

[openstack-dev] [Murano] Environment status

Initiall my interest to that problem was caused by the bug [1] due to whose once environment was deployed with failure it stays forever with that status even if it have been deployed sucessfully later. For now status determination happens in three stages: - If at least one of all sessions of env,

Re: [openstack-dev] [Heat][API] Filtering by metadata values

On 02/10/2015 10:03 PM, Angus Salkeld wrote: > On Wed, Feb 11, 2015 at 8:20 AM, Miguel Grinberg > mailto:miguel.grinb...@gmail.com>> wrote: > > Hi, > > We had a discussion yesterday on the Heat channel regarding patterns > for searching or filtering entities by its metadata values. Th

Re: [openstack-dev] [all] Ask for help with devstack error

Hi, Take a look at this commit, it broke a number of Trove tests last night: https://review.openstack.org/#/c/154391 Not sure if it’s related, but it seems similar (try manually backing out the change for cinder and see if it fixes your problem). Good luck! Peter From: liuxinguo [mailto:liuxi

Re: [openstack-dev] The API WG mission statement

On 02/10/2015 08:01 AM, Everett Toews wrote: > On Feb 9, 2015, at 9:28 PM, Jay Pipes > wrote: > >> On 02/02/2015 02:51 PM, Stefano Maffulli wrote: >>> On Fri, 2015-01-30 at 23:05 +, Everett Toews wrote: To converge the OpenStack APIs to a consistent and pragmat

Re: [openstack-dev] [nova] Question about force_host skip filters

On 02/12/2015 10:10 AM, Chris Friesen wrote: On 02/12/2015 03:44 AM, Sylvain Bauza wrote: Any action done by the operator is always more important than what the Scheduler could decide. So, in an emergency situation, the operator wants to force a migration to an host, we need to accept it and do

Re: [openstack-dev] [nova] Question about force_host skip filters

On 02/12/2015 03:44 AM, Sylvain Bauza wrote: Any action done by the operator is always more important than what the Scheduler could decide. So, in an emergency situation, the operator wants to force a migration to an host, we need to accept it and do it, even if it doesn't match what the Schedul

Re: [openstack-dev] [glance] Metadef-tags create api change request.

On 2/11/15, 11:10, "Okuma, Wayne" wrote: >Hello, > >I would like to change the metadef-tags create API which was checked into >Kilo (cycle 1). >The python-glanceclient that would support metadef-tags has not been >released yet and I would like to make this change before doing so. >The details ar

Re: [openstack-dev] [api] Missing the next API WG meeting

I’ll be around so I’ll do this if no one else will be around to do it. On 2/11/15, 16:39, "Everett Toews" wrote: >I’ll be missing the next API WG meeting [1] as I’m in some all day >training. Someone else will have to #startmeeting api wg > >Cheers, >Everett > >[1] https://wiki.openstack.org/wik

Re: [openstack-dev] [sahara] team meeting Feb 12 1400 UTC

Log: http://eavesdrop.openstack.org/meetings/sahara/2015/sahara.2015-02-12-14.00.txt Minutes: http://eavesdrop.openstack.org/meetings/sahara/2015/sahara.2015-02-12-14.00.html On Thu, Feb 12, 2015 at 1:26 AM, Andrew Lazarev wrote: > Hi guys, > > We'll be having the Sahara team meeting tomorrow at

[openstack-dev] [devstack] Devstack and Grenade futures

In the spirit of summarizing conversations that have been had, I'd like to point people that are interested at the Devstack FUTURE.rst document - https://github.com/openstack-dev/devstack/blob/master/FUTURE.rst This is an attempt by the Devstack team recently to write down a "where are we going" d

[openstack-dev] [Designate] Documentation Sprint tomorrow @ 16.00 UTC

Hey Designate is having a 2 hour docs sprint this Friday @ 16.00 UTC List of topics is here - https://etherpad.openstack.org/p/designate-documentation-sprint If you are interested in helping out, please add your name to an unclaimed topic :) We will be co-ordinating via IRC in #openstack-dns T

[openstack-dev] [sahara] Running HBase Jobs (was: About Sahara Oozie plan)

Hi Lu, folks, I've been investigating how to run Java actions in Sahara EDP that depend on HBase libraries (see snippet from the original question by Lu below). In a nutshell, we need to use Oozie sharelibs for this. I am working on a spec now, thinking about the best way to support this in Sah

[openstack-dev] [Neutron] Update on "DB" IPAM driver

Hi, I have updated the patch; albeit not complete yet it's kind of closer to be an allocator decent enough to replace the built-in logic. I will be unable to attend today's L3/IPAM meeting due to a conflict, so here are some highlights from me on which your feedback is more than welcome: - I agr

Re: [openstack-dev] [nova] Feature Freeze Exception for "Add config drive support for PCS containers"

On Wed, Feb 11, 2015 at 03:28:49PM +0300, aburluka wrote: > Hello, > > I'd like to request a feature freeze exception for the change [1] > This change implements configuration drive support in Parallels containers. > It does not change existing Nova behaviour. > It's a last patch in parallels seri

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

On Thu, 2015-02-12 at 10:37 +0100, Thierry Carrez wrote: > Right. You can't prevent occasional private discussions and pings, and > you shouldn't. It's when you encourage and officialize them (by for > example creating a channel for them) that things start to go bad. Yes, that's very bad. Private

Re: [openstack-dev] [devstack] [third-party] how to use a devstack external plugin in gate testing

Sean Dague writes: > I'm going to be -1ing most new or substantially redone drivers at this > point. External plugins are a better model for those. +1 Chnmouel __ OpenStack Development Mailing List (not for usage questions

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

On Thu, 2015-02-12 at 10:35 +, Kuvaja, Erno wrote: > I'm not attacking against having summits, I think the face to face > time is incredibly valuable for all kind of things. My point was to > bring up general flaw of the flow between all inclusive decision > making vs. decided in summit session

Re: [openstack-dev] [devstack] [third-party] how to use a devstack external plugin in gate testing

On 02/12/2015 07:49 AM, Gary Kotton wrote: > > > On 2/12/15, 1:33 PM, "Chmouel Boudjnah" wrote: > >> Jaume Devesa writes: >> >>> Following the conversation... >>> >>> We have seen that glusterfs[1] and ec2api[2] use different approach >>> when it comes to repository managing: whereas glusterfs

Re: [openstack-dev] [devstack] [third-party] how to use a devstack external plugin in gate testing

On 2/12/15, 1:33 PM, "Chmouel Boudjnah" wrote: >Jaume Devesa writes: > >> Following the conversation... >> >> We have seen that glusterfs[1] and ec2api[2] use different approach >> when it comes to repository managing: whereas glusterfs is a single >> 'devstack' directory repository, ec2api is

Re: [openstack-dev] [nova] Question about force_host skip filters

I understand the fact that an opertaor can and should be able to place the VM where she/he wants. The VM should just adhere to the scheduling constraints :) (which are defined in the filters) :) From: Rui Chen mailto:chenrui.m...@gmail.com>> Reply-To: OpenStack List mailto:openstack-dev@lists.o

Re: [openstack-dev] Feature Freeze Exception for hyper-v unit tests refactoring

On 02/12/2015 07:28 AM, Daniel P. Berrange wrote: > On Thu, Feb 12, 2015 at 12:18:49PM +, Claudiu Belu wrote: >> Hello. >> >> I would like to request a FFE for the Hyper-V unit tests refactoring >> blueprint: >> https://blueprints.launchpad.net/nova/+spec/hyper-v-test-refactoring >> >> The po

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

On Thu, 12 Feb 2015, Flavio Percoco wrote: The important bit, thoguh, is that email is meant for asynchronous communication and IRC isn't. If things that require the intervention of other folks from the community are being discussed and those folks are not on IRC, it'd be wrong to consider the t

Re: [openstack-dev] Feature Freeze Exception for hyper-v unit tests refactoring

On Thu, Feb 12, 2015 at 12:18:49PM +, Claudiu Belu wrote: > Hello. > > I would like to request a FFE for the Hyper-V unit tests refactoring > blueprint: > https://blueprints.launchpad.net/nova/+spec/hyper-v-test-refactoring > > The point of the blueprint was to get rid of the ancient test_h

[openstack-dev] [stable] expanding sahara maint team

Hi stable maint folks, I'd like to propose to add the following folks to the sahara stable maint team: * Trevor McKay (tmckay) * Ethan Gafford (egafford) * Andrew Lazarev (alazarev) * Sergey Reshetnyak (sreshetniak) Thanks. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack D

[openstack-dev] [nova] Feature Freeze Exception for hyper-v unit tests refactoring

Hello. I would like to request a FFE for the Hyper-V unit tests refactoring blueprint: https://blueprints.launchpad.net/nova/+spec/hyper-v-test-refactoring The point of the blueprint was to get rid of the ancient test_hypervapi.py tests, that use mox, as they prove more and more difficult to m

[openstack-dev] [nova] Feature Freeze Exception request for x509 keypairs

Hello. I would like to ask for a FFE for the x509 keypairs blueprint: https://blueprints.launchpad.net/nova/+spec/keypair-x509-certificates This blueprint is split up into 3 commits: [1] Database migration: previously merged, but had to be reverted because of a small issue. Everything is fixe

Re: [openstack-dev] A question about strange behavior of oslo.config in eclipse

Hi Doug, Thank you very much for your reply. I don't have any codes, so no any special codes as well. Only thing I did is that: 1, use devstack to install a fresh openstack env, all are ok. 2, import neutron-vpnaas directory (no any my own codes) into eclipse as pydev project, for exam

[openstack-dev] Feature Freeze Exception for hyper-v unit tests refactoring

Hello. I would like to request a FFE for the Hyper-V unit tests refactoring blueprint: https://blueprints.launchpad.net/nova/+spec/hyper-v-test-refactoring The point of the blueprint was to get rid of the ancient test_hypervapi.py tests, that use mox, as they prove more and more difficult to ma

  1   2   >