Re: [openstack-dev] [Congress] Guide for all reactive policy options? (execute[...])

Hi Bryan, You can see neutron driver's action with 'openstack congress datasource actions show' command. It shows all execution method supported by neutronclient. btw, the prefix of reaction policy rule is datasource *name*. If you initialize openstack like devstack, the datasource name

Re: [openstack-dev] [Congress] Issues with Tox testing

Hi Bryan, Yes, tempest can be run outside devstack deployments. Please check the README in https://github.com/openstack/tempest on configuring tempest. As in liberty, you need to copy the tests to tempest, I guess installing tempest on diff server also should work as long as congress service is

[openstack-dev] [Congress] Guide for all reactive policy options? (execute[...])

Hi Congress team, I'm trying to develop tests for the reactive policy features of Congress. I have one such test working, shown at https://git.opnfv.org/cgit/copper/tree/tests/adhoc/dmz01.sh, which applies the following rule for pausing a server when there has been an error in server

Re: [openstack-dev] Does Neutron itself add VM ports to ovs?

Hello, I don't know this ODL and how it works but for ovs-agent nova-compute is part which adds port to ovs bridge (see for example nova/virt/libvirt/vif.py) -- Pozdrawiam / Best regards Sławek Kapłoński sla...@kaplonski.pl Dnia wtorek, 12 kwietnia 2016 12:31:01 CEST 张晨 pisze: > Hello

Re: [openstack-dev] [Congress] Issues with Tox testing

Hi Anusha, That helps. Just one more question: in Liberty (which I'm currently based upon) have the tempest tests been run outside of devstack deployments, i.e. in an actual OpenStack deployment? The guide you reference mentions devstack but it's not clear that the same process applies outside

[openstack-dev] [Neutron] Newton Design summit schedule - Draft

Hi folks, A provisional schedule for the Neutron project is available [1]. I am still working with the session chairs and going through/ironing out some details as well as gathering input from [2]. I hope I can get something more final by the end of this week. In the meantime, please free to ask

[openstack-dev] Does Neutron itself add VM ports to ovs?

Hello everyone, I have a question about Neutron. I learn that the ovs-agent receives the update-port rpc notification,and updates ovsdb data for VM port. But what is the situation when i use SDN controllers instead of OVS mechanism driver? I found no where in ODL to add the VM port to ovs.

Re: [openstack-dev] [neutron][taas] start time of weekly TaaS IRC meeting

it's my understanding too. i submitted the change: https://review.openstack.org/#/c/304383/ please +1 if you are ok. On Tue, Apr 12, 2016 at 9:06 AM, Soichi Shigeta wrote: > > Hi Anil, Vinay, and folks, > > I'd like to confirm the start time of weekly TaaS IRC

Re: [openstack-dev] [Horizon][stable] proposing Rob Cresswell for Horizon stable core

On Thu, Apr 07, 2016 at 12:01:31PM +0200, Matthias Runge wrote: > Hello, > > I'm proposing Rob Cresswell to become stable core for Horizon. I > thought, in the past all PTL were in stable team, but this doesn't seem > to be true any more. This *may* have been true when the project specific team

Re: [openstack-dev] [devstack][neutron] Eliminating the DevStack layer

On 2016/04/12 8:02, Kevin Benton wrote: Oh right, I'm definitely for eliminating these values from Devstack and just telling people to use post-config. I was just hesitant about advocating for their removal from neutron. Yeah, my point is eliminating useless options from Devstack since we can

[openstack-dev] [stackalytics] Proposal for some code/feature changes

Hello, I was hoping to make some changes to the stackalytics dashboard specifically of this type [1] following my requested suggestions here [2]; possibly add a few extra columns for +0s and just Bot +1s. I think having this info gives much clearer picture of the kind of reviews someone is/wants

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

I'll actually be out in Hillsboro on Thursday night so I can ask folks when I'm out there... Best, -jay On 04/11/2016 07:19 PM, Augustina Ragwitz wrote: On Mon, Apr 11, 2016 at 3:54 PM, Michael Still > wrote: Intel at Hillsboro had expressed

Re: [openstack-dev] [infra] [releases] Behavior change in the bot for jenkins merge?

On Mon, Apr 11, 2016, at 06:18 PM, Nikhil Komawar wrote: > Hi, > > I noticed on a recent merge to glance [1] that the bot updated the bug > [2] with comment from "in progress" to "fix released" vs. earlier > behavior "fix committed". Is that behavior on purpose or issue with the > bot? > > [1]

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

On Mon, Apr 11, 2016 at 03:49:16PM -0500, Matt Riedemann wrote: > A few people have been asking about planning for the nova midcycle for > newton. Looking at the schedule [1] I'm thinking weeks R-15 or R-11 work the > best. R-14 is close to the US July 4th holiday, R-13 is during the week of > the

Re: [openstack-dev] [glance][reno] Broken releasenotes in glance_store

To close this: This has been fixed as a part of the earlier opened bug https://bugs.launchpad.net/glance-store/+bug/1568767 and other is duplicated. Thanks! On 4/11/16 6:12 PM, Nikhil Komawar wrote: > NVM, I verified it locally and created a report. >

Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay

Run both Chronos and Marathon on Mesos and Run Chronos on top of Marathon seems two different cases. I think if #1 Add Chronos to the mesos bay , #2 is possible to archive that. Only if we find frameworks(heat templates) not able to handle that, we could use option #1. But still flexible is

[openstack-dev] [infra] [releases] Behavior change in the bot for jenkins merge?

Hi, I noticed on a recent merge to glance [1] that the bot updated the bug [2] with comment from "in progress" to "fix released" vs. earlier behavior "fix committed". Is that behavior on purpose or issue with the bot? [1] https://review.openstack.org/#/c/304184/ [2]

[openstack-dev] [neutron][taas] start time of weekly TaaS IRC meeting

Hi Anil, Vinay, and folks, I'd like to confirm the start time of weekly TaaS IRC meeting will be changed from 06:30 UTC to 05:30 UTC (adjustment for summer/daylight time) from next IRC on 13th Apr. Is this right? Regards, Soichi

Re: [openstack-dev] [TripleO] Can we create some subteams?

On 12/04/16 11:48, Jeremy Stanley wrote: On 2016-04-12 11:43:06 +1200 (+1200), Steve Baker wrote: Can I suggest a sub-team for os-collect-config/os-refresh-config/os-apply-config? I ask since these tools also make up the default heat agent, and there is nothing in them which is TripleO

[openstack-dev] Meeting SKIPPED, Tue April 12th, 21:00 UTC

Hi all! We will be skipping the cross-project meeting since there are no agenda items to discuss, but someone can add one [1] to call a meeting next time. Thanks! [1] - https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda -- Mike Perez

Re: [openstack-dev] [TripleO] Can we create some subteams?

On 2016-04-12 11:43:06 +1200 (+1200), Steve Baker wrote: > Can I suggest a sub-team for > os-collect-config/os-refresh-config/os-apply-config? I ask since > these tools also make up the default heat agent, and there is > nothing in them which is TripleO specific. Could make sense similarly for

Re: [openstack-dev] [TripleO] Can we create some subteams?

On 11/04/16 22:19, Steven Hardy wrote: On Mon, Apr 11, 2016 at 05:54:11AM -0400, John Trowbridge wrote: Hola OOOers, It came up in the meeting last week that we could benefit from a CI subteam with its own meeting, since CI is taking up a lot of the main meeting time. I like this idea, and

[openstack-dev] [Infra] Meeting Tuesday April 12th at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday April 12th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting Anyone is welcome to to add agenda

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

On Mon, Apr 11, 2016 at 3:54 PM, Michael Still wrote: > > Intel at Hillsboro had expressed an interest in hosting the N mid-cycle > last release, so they might still be an option? I don't recall any other > possible hosts in the queue, but its possible I've missed someone. > >

Re: [openstack-dev] [devstack][neutron] Eliminating the DevStack layer

Oh right, I'm definitely for eliminating these values from Devstack and just telling people to use post-config. I was just hesitant about advocating for their removal from neutron. On Mon, Apr 11, 2016 at 3:55 PM, Brandon Logan wrote: > On Mon, 2016-04-11 at 15:30

Re: [openstack-dev] [devstack][neutron] Eliminating the DevStack layer

On Mon, 2016-04-11 at 15:30 -0700, Kevin Benton wrote: > >[1]: > >https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L178 > >[2]: > >https://github.com/openstack/nova/blob/master/nova/conf/virt.py#L164-L166 > > > This is a Nova option to decide how long to wait for

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

On Tue, Apr 12, 2016 at 6:49 AM, Matt Riedemann wrote: > A few people have been asking about planning for the nova midcycle for > newton. Looking at the schedule [1] I'm thinking weeks R-15 or R-11 work > the best. R-14 is close to the US July 4th holiday, R-13 is

Re: [openstack-dev] [devstack][neutron] Eliminating the DevStack layer

>[1]: https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L178 >[2]: https://github.com/openstack/nova/blob/master/nova/conf/virt.py#L164-L166 This is a Nova option to decide how long to wait for Neutron to callback before considering a port failed to be wired. The time this

Re: [openstack-dev] Gerrit server replacement scheduled for April 11th

Our maintenance has concluded, and services are back in operation as of 21:00 UTC. Please note that (as previously announced) this maintenance included a move to new IP addresses for review.openstack.org: IPv4 -> 104.130.246.91 IPv6 -> 2001:4800:7819:103:be76:4eff:fe05:8525 These have

Re: [openstack-dev] [glance][reno] Broken releasenotes in glance_store

NVM, I verified it locally and created a report. https://bugs.launchpad.net/glance-store/+bug/1569062 Thanks for bringing this up. On 4/11/16 4:07 PM, Nikhil Komawar wrote: > I just referred to it using my email inbox, gerrit seems to be down for > me to be fully confirmed on this fixing things.

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: April-11-16 2:52 PM To: OpenStack Development Mailing List (not for usage questions); Adrian Otto Cc: foundat...@lists.openstack.org Subject: Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal?

Re: [openstack-dev] [magnum][requirements][release] The introduction of package py2-ipaddress

Thierry, Hongbin, Looked at current docker-py and came up with this: https://github.com/docker/docker-py/pull/1033/ Thanks, Dims On Mon, Apr 11, 2016 at 3:43 PM, Hongbin Lu wrote: > Hi Thierry, > > Thanks for your advice. I submitted a patch [1] to downgrade docker-py to

[openstack-dev] [puppet][ceph] Puppet-ceph is now a formal member of puppet-openstack

It's been a while since we started the puppet-ceph module on stackforge as a friend of OpenStack. Since then Ceph's usage in OpenStack has increased greatly and we have both the puppet-openstack deployment scenarios as well as check-trippleo running against the module. We've been receiving

Re: [openstack-dev] [Horizon][stable] proposing Rob Cresswell for Horizon stable core

+1 On Thu, Apr 7, 2016 at 8:05 PM, Zhenguo Niu wrote: > definitely +1 > > On Fri, Apr 8, 2016 at 12:42 AM, Brad Pokorny > wrote: >> >> +1. I think Rob will provide good input for stable. >> >> Thanks, >> Brad >> >> From: Timur Sufiev

Re: [openstack-dev] [heat] upgrade options for custom heat resource plug-ins

There is a mechanism to mark them as support status "hidden" so that they don't show up in resource-type-show and aren't allowed in new templates, but older templates should still work. Eventually they may go away altogether but that should be far in the future. For your custom resources, you

Re: [openstack-dev] [Rally] Term "workload" has two clashing meanings

"dataplane" looks good to me On Mon, Apr 11, 2016 at 10:56 PM, Boris Pavlovic wrote: > Alex, > > I would suggest to call it "dataplane" because it obvious points to > dataplane testing > > Best regards, > Boris Pavlovic > > On Mon, Apr 11, 2016 at 11:10 AM, Roman Vasilets

Re: [openstack-dev] [heat] upgrade options for custom heat resource plug-ins

Randall, Thanks for your reply. I was wondering especially about those "deprecated" properties.. What happens after several releases? Do you just remove them at that point? If the expected maximum lifespan of a stack is shorter than the span for which those "deprecated" properties are maintained,

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

On 04/11/2016 04:49 PM, Matt Riedemann wrote: > A few people have been asking about planning for the nova midcycle for > newton. Looking at the schedule [1] I'm thinking weeks R-15 or R-11 work > the best. R-14 is close to the US July 4th holiday, R-13 is during the > week of the US July 4th

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

On 04/11/2016 04:49 PM, Matt Riedemann wrote: > A few people have been asking about planning for the nova midcycle for > newton. Looking at the schedule [1] I'm thinking weeks R-15 or R-11 work > the best. R-14 is close to the US July 4th holiday, R-13 is during the > week of the US July 4th

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

That’s not what I was talking about here. I’m addressing the interest in a common compute API for the various types of compute (VM, BM, Container). Having a “containers” API for multiple COE’s is a different subject. Adrian On Apr 11, 2016, at 11:10 AM, Hongbin Lu

[openstack-dev] [nova] Newton midcycle planning

A few people have been asking about planning for the nova midcycle for newton. Looking at the schedule [1] I'm thinking weeks R-15 or R-11 work the best. R-14 is close to the US July 4th holiday, R-13 is during the week of the US July 4th holiday, and R-12 is the week of the n-2 milestone.

Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay

+1 for "#1: Mesos and Marathon". Most deployments that I am aware of has this setup. Also we can provide several line instructions how to run Chronos on top of Marathon. honestly I don't see how #2 will work, because Marathon installation is different from Aurora installation.  --- Egor

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

On 04/11/2016 02:51 PM, Fox, Kevin M wrote: > Yeah, I think there are two places where it may make sense. > > 1. Ironic's nova plugin is a lowst common denominator for treating a > physical host like a vm. Ironic's api is much more rich, but sometimes > all you need is the lowest common

Re: [openstack-dev] [glance][reno] Broken releasenotes in glance_store

I just referred to it using my email inbox, gerrit seems to be down for me to be fully confirmed on this fixing things. On 4/11/16 4:06 PM, Nikhil Komawar wrote: > Thanks for your proposal Andreas. I guess [1] fixes things and good to > have here for awareness? > > [1]

Re: [openstack-dev] [glance][reno] Broken releasenotes in glance_store

Thanks for your proposal Andreas. I guess [1] fixes things and good to have here for awareness? [1] https://review.openstack.org/303962 On 4/11/16 2:56 AM, Andreas Jaeger wrote: > I've noticed that the translation bot fails extracting strings from the > release notes: >

[openstack-dev] [Glance] Announcing Newton mid-cycle meetup

Hello everyone, We are pleased to announce that the Glance mid-cycle meetup for Newton will be held Wednesday-Friday, June 15-17 2016 in Cambridge, MA, USA at the VMwareoffice. We are sending this notice in advance to help you plan your travel early. Whether you work in/with Glance community on a

Re: [openstack-dev] [Rally] Term "workload" has two clashing meanings

Alex, I would suggest to call it "dataplane" because it obvious points to dataplane testing Best regards, Boris Pavlovic On Mon, Apr 11, 2016 at 11:10 AM, Roman Vasilets wrote: > Hi all, personally I want to suggest* crossload. *Concept is similar to > cross

Re: [openstack-dev] [keystone][performance][profiling] Profiling Mitaka Keystone: some results and asking for a help

On Mon, Apr 11, 2016 at 8:11 AM, Dina Belova wrote: > Hey, openstackers! > > Recently I was trying to profile Keystone (OpenStack Liberty vs Mitaka) > using this set of changes > > (that's

Re: [openstack-dev] [devstack][neutron] Eliminating the DevStack layer

I agree. Throughout I was reviewing Devstack over 3 cycles, I thought the same thing. Devstack often accepted patches just adding option although we're not sure who really needs the options. There are many useless stuff in the options. For example, default value of devstack option is the same

Re: [openstack-dev] [magnum][requirements][release] The introduction of package py2-ipaddress

Hi Thierry, Thanks for your advice. I submitted a patch [1] to downgrade docker-py to 1.7.2. In long term, we will negotiate with upstream maintainers to resolve the module conflicting issue. [1] https://review.openstack.org/#/c/304296/ Best regards, Hongbin > -Original Message- >

Re: [openstack-dev] [Cinder] About snapshot Rollback?

Ok, you're right about device naming by UUID. So we have two advantages compared to the existing system: - Keeping the same volume id (and therefore disk UUID) makes reverting a VM much easier since device names inside the instance stay the same - Can significantly reduce the amount of copying

Re: [openstack-dev] [heat] upgrade options for custom heat resource plug-ins

Not really. Ideally, you need to write your resource such that these changes are backwards compatible. We do this for the resources we ship with Heat (add new properties while supporting deprecated properties for several releases). On Apr 11, 2016, at 1:06 PM, "Praveen Yalagandula"

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

Yeah, I think there are two places where it may make sense. 1. Ironic's nova plugin is a lowst common denominator for treating a physical host like a vm. Ironic's api is much more rich, but sometimes all you need is the lowest common denominator and don't want to rewrite a bunch of code. In

Re: [openstack-dev] [Neutron][Infra] Post processing of gate hooks on job timeouts

On Mon, Apr 11, 2016 at 1:56 PM, Clark Boylan wrote: > On Mon, Apr 11, 2016, at 10:52 AM, Jakub Libosvar wrote: >> On 04/11/2016 06:41 PM, Clark Boylan wrote: >> > On Mon, Apr 11, 2016, at 03:07 AM, Jakub Libosvar wrote: >> >> Hi, >> >> >> >> recently we hit an issue in

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

As we’ve deployed more OpenStack components in production, one of the points we have really appreciated is the common areas - Single pane of glass for Horizon - Single accounting infrastructure - Single resource management, quota and admin roles - Single storage pools with Cinder - (not quite

Re: [openstack-dev] [kolla][vote] Nit-picking documentation changes

My proposal was for docs-only patches not code contributions with docs. Obviously we want a high bar for code contributions. This is part of the reason we have the DocImpact flag (for folks that don't feel comfortable writing documentation because perhaps of ESL, or other reasons). We already

Re: [openstack-dev] [Rally] Term "workload" has two clashing meanings

Hi all, personally I want to suggest* crossload. *Concept is similar to cross training(training in two or more sports in order to improve fitness and performance, especially in a main sport.) in sport. By that template - crossload is load in two or more areas in order to improve durability and

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

Sorry, I disagree. Magnum team doesn’t have consensus to reject the idea of unifying APIs from different container technology. In contrast, the idea of unified Container APIs has been constantly proposed by different people in the past. I will try to allocate a session in design summit to

Re: [openstack-dev] [TripleO] Can we create some subteams?

On 04/11/2016 12:12 PM, Steven Hardy wrote: > On Mon, Apr 11, 2016 at 10:33:53AM -0500, Ben Nemec wrote: >> On 04/11/2016 04:54 AM, John Trowbridge wrote: >>> Hola OOOers, >>> >>> It came up in the meeting last week that we could benefit from a CI >>> subteam with its own meeting, since CI is

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

Adrian, thx for your detailed mail. Yes, I was hopeful of a silver bullet and as we’ve discussed before (I think it was Vancouver), there’s likely no silver bullet in this area. After that conversation, and some further experimentation, I found that even if Trove had access to a single Compute

[openstack-dev] [heat] upgrade options for custom heat resource plug-ins

Hi, We are developing a custom heat resource plug-in and wondering about how to handle plug-in upgrades. As our product's object model changes with new releases, we will need to release updated resource plug-in code too. However, the "properties" stored in the heat DB for the existing resources,

Re: [openstack-dev] [Cinder] About snapshot Rollback?

You are right, the instance should be shutdown or the device be unmounted, before 'revert' or removing the old device. That should be enough to avoid corruption. I think the device naming is not a problem if you use the same volume (at least the disk UUID will be the same). On Mon, Apr 11, 2016

Re: [openstack-dev] [Openstack-security] [Security]abandoned OSSNs?

Thanks Michael, I'm following the thread and I've asked Thierry for this tag to be subscribable here if we're not using openstack-security anymore so that I can receive the follow-ups. On Mon, Apr 11, 2016 at 8:28 AM, Michael Xin wrote: > Matt: > Thanks for asking

Re: [openstack-dev] [Neutron][Infra] Post processing of gate hooks on job timeouts

On 04/11/2016 06:41 PM, Clark Boylan wrote: > On Mon, Apr 11, 2016, at 03:07 AM, Jakub Libosvar wrote: >> Hi, >> >> recently we hit an issue in Neutron with tests getting stuck [1]. As a >> side effect we discovered logs are not collected properly which makes it >> hard to find the root cause. The

Re: [openstack-dev] [Neutron][Infra] Post processing of gate hooks on job timeouts

On Mon, Apr 11, 2016, at 10:52 AM, Jakub Libosvar wrote: > On 04/11/2016 06:41 PM, Clark Boylan wrote: > > On Mon, Apr 11, 2016, at 03:07 AM, Jakub Libosvar wrote: > >> Hi, > >> > >> recently we hit an issue in Neutron with tests getting stuck [1]. As a > >> side effect we discovered logs are not

Re: [openstack-dev] [TripleO] Can we create some subteams?

On 04/11/2016 05:33 PM, Ben Nemec wrote: On 04/11/2016 04:54 AM, John Trowbridge wrote: Hola OOOers, It came up in the meeting last week that we could benefit from a CI subteam with its own meeting, since CI is taking up a lot of the main meeting time. I like this idea, and think we should do

Re: [openstack-dev] [cinder][nova] Cinder-Nova API meeting

Hi All, It's a friendly reminder we're having the next Cinder-Nova API interactions meeting this Wednesday __13th April 2100UTC__, on the #openstack-meeting-cp channel. You can follow up the recent activities here: https://etherpad.openstack.org/p/cinder-nova-api-changes Our current focus is

Re: [openstack-dev] [Cinder] About snapshot Rollback?

You can't just change the contents of a volume under the instance though - at the very least you need to do an unmount in the instance, and a detach is preferable, otherwise you've got data corruption issues. At that point, the device naming problems are identical. On 11 April 2016 at 20:22,

Re: [openstack-dev] [Cinder] About snapshot Rollback?

The actual user workflow is: 1 - User creates a volume(s) 2 - User attach volume to instance 3 - User creates a snapshot 4 - Something happens causing the need of a revert 5 - User creates a volume(s) from the snapshot(s) 6 - User detach old volumes 7 - User attach new volumes (and pray so

Re: [openstack-dev] [TripleO] Can we create some subteams?

On Mon, Apr 11, 2016 at 10:33:53AM -0500, Ben Nemec wrote: > On 04/11/2016 04:54 AM, John Trowbridge wrote: > > Hola OOOers, > > > > It came up in the meeting last week that we could benefit from a CI > > subteam with its own meeting, since CI is taking up a lot of the main > > meeting time. > >

[openstack-dev] [nova] Encrypted Ephemeral Storage

I've been looking into using encrypted ephemeral storage with LVM. With the [ephemeral_storage_encryption] and [keymgr] sections to nova.conf, I get an LVM volume with "-dmcrypt" is appended to the volume name, but otherwise see no difference; I can still grep for text inside the volume. Upon

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

Amrith, I respect your point of view, and agree that the idea of a common compute API is attractive… until you think a bit deeper about what that would mean. We seriously considered a “global” compute API at the time we were first contemplating Magnum. However, what we came to learn through

Re: [openstack-dev] [Neutron][Infra] Post processing of gate hooks on job timeouts

On Mon, Apr 11, 2016, at 03:07 AM, Jakub Libosvar wrote: > Hi, > > recently we hit an issue in Neutron with tests getting stuck [1]. As a > side effect we discovered logs are not collected properly which makes it > hard to find the root cause. The reason of missing logs is that we send > SIGKILL

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

On Mon, Apr 11, 2016 at 11:30 AM, Monty Taylor wrote: > On 04/11/2016 09:43 AM, Allison Randal wrote: > >> On Wed, Apr 6, 2016 at 1:11 PM, Davanum Srinivas >>> wrote: >>> Reading unofficial notes [1], i found one topic very interesting: One

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

The more I've used Containers in production the more I've come to the conclusion they are much different beasts then Nova Instances. Nova's abstraction lets Physical hardware and VM's share one common API, and it makes a lot of sense to unify them. Oh. To be explicit, I'm talking about docker

Re: [openstack-dev] [Openstack-security] [Security]abandoned OSSNs?

Hi, I believe 50 and 51 were both assigned to me. They were closely linked, but seperate issues. I wrote 50 up here: https://review.openstack.org/#/c/200303/2 After discussion in a security meeting, my memory is that it was agreed that they probably weren't required. I'd have to pull out the

Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion

On 04/11/2016 11:11 AM, michael mccune wrote: > please forgive my lack of direct knowledge about the neutron process and > how this fits in. i'm just commenting from the perspective of someone > looking at this from the api-wg. > > On 04/11/2016 09:52 AM, Duncan Thomas wrote: >> So by adding the

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

Monty, Dims, I read the notes and was similarly intrigued about the idea. In particular, from the perspective of projects like Trove, having a common Compute API is very valuable. It would allow the projects to have a single view of provisioning compute, as we can today with Nova and get the

Re: [openstack-dev] [Openstack-security] [Security]abandoned OSSNs?

On 04/11/2016 08:04 AM, Clark, Robert Graham wrote: > Thanks Matt, Michael, > > > > To start with, lets look quickly at the more recent OSSNs that are > marked as work in progress, namely 63,64,65 and 66 – these should all be > published within a week or so. > > > > Looking further back

[openstack-dev] [Rally] Term "workload" has two clashing meanings

Hi all, this is about terminology, we have term "workload" in Rally that appears in two clashing meanings: 1. module rally.plugins.workload which collects plugins for cross-VM testing 2. workload replaces term "scenario"

Re: [openstack-dev] [Neutron][Infra] Post processing of gate hooks on job timeouts

On Mon, Apr 11, 2016 at 9:39 AM, Morales, Victor wrote: > > > > > > On 4/11/16, 5:07 AM, "Jakub Libosvar" wrote: > >>Hi, >> >>recently we hit an issue in Neutron with tests getting stuck [1]. As a >>side effect we discovered logs are not collected

Re: [openstack-dev] [TripleO] Can we create some subteams?

On 04/11/2016 04:54 AM, John Trowbridge wrote: > Hola OOOers, > > It came up in the meeting last week that we could benefit from a CI > subteam with its own meeting, since CI is taking up a lot of the main > meeting time. > > I like this idea, and think we should do something similar for the

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

On 04/11/2016 09:43 AM, Allison Randal wrote: On Wed, Apr 6, 2016 at 1:11 PM, Davanum Srinivas wrote: Reading unofficial notes [1], i found one topic very interesting: One Platform – How do we truly support containers and bare metal under a common API with VMs? (Ironic,

Re: [openstack-dev] [devstack][neutron] Eliminating the DevStack layer

Good news... the number of neutron options with a sane default value has increased significantly in the last couple of releases. If you're looking at the installation guide, it explicitly configures more options to override bad values set by distribution packages. For deployment tools, explicitly

[openstack-dev] [vitrage] Austin preparation

Hi all, Here are the tasks that we should finish for the Austin summit, with the current owners: - List of default Templates + testing - danoffek - Description support in Templates - ifat_afek / (or lhartal?) - Installation - First Steps Guide - elisha_r - Aodh – Installation requirements

Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion

please forgive my lack of direct knowledge about the neutron process and how this fits in. i'm just commenting from the perspective of someone looking at this from the api-wg. On 04/11/2016 09:52 AM, Duncan Thomas wrote: So by adding the handling of a header to change the behaviour of the

Re: [openstack-dev] [Openstack-security] [Security]abandoned OSSNs?

Thanks Matt, Michael, To start with, lets look quickly at the more recent OSSNs that are marked as work in progress, namely 63,64,65 and 66 – these should all be published within a week or so. Looking further back we have the more difficult OSSNs 50 and 51, I’m not 100% sure what the blockers

Re: [openstack-dev] [User-committee] [all] [app-catalog] Newton summit schedule

On Sat, Apr 9, 2016 at 8:41 AM, Yih Leong, Sun. wrote: > I think it needs to relate to 'workload'. > The Enterprise WG is working on a series of workload reference architecture. > These architecture documents will include sample Heat template for each type > of workload. We

Re: [openstack-dev] [TripleO] Can we create some subteams?

On 04/11/2016 06:19 AM, Steven Hardy wrote: > On Mon, Apr 11, 2016 at 05:54:11AM -0400, John Trowbridge wrote: >> Hola OOOers, >> >> It came up in the meeting last week that we could benefit from a CI >> subteam with its own meeting, since CI is taking up a lot of the main >> meeting time. >> >>

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

> On Wed, Apr 6, 2016 at 1:11 PM, Davanum Srinivas wrote: >> Reading unofficial notes [1], i found one topic very interesting: >> One Platform – How do we truly support containers and bare metal under >> a common API with VMs? (Ironic, Nova, adjacent communities e.g. >>

Re: [openstack-dev] [ironic] [api] Fixing bugs in old microversions

On 04/11/2016 10:11 AM, Sean Dague wrote: On 04/11/2016 09:54 AM, Jay Pipes wrote: On 04/11/2016 09:48 AM, Dmitry Tantsur wrote: On 04/11/2016 02:00 PM, Jay Pipes wrote: On 04/11/2016 04:48 AM, Vladyslav Drok wrote: Hi all! There is a bug in

Re: [openstack-dev] [devstack][neutron] Eliminating the DevStack layer

Armando M. wrote: > My understanding of the plan to overhaul the neutron (bloated) layer > present in DevStack being tackled in [1] has always been that this was > about trimming the layer rather than eliminating it altogether. Is this > email a reflection of a desire to change direction? If so,

Re: [openstack-dev] [TripleO] Can we create some subteams?

+1 from me too, we have it in Puppet OpenStack group, and it works just fine. On Mon, Apr 11, 2016 at 10:27 AM, Jason Rist wrote: > On 04/11/2016 04:19 AM, Steven Hardy wrote: >> On Mon, Apr 11, 2016 at 05:54:11AM -0400, John Trowbridge wrote: >> > Hola OOOers, >> > >> > It

Re: [openstack-dev] [Openstack-security] [Security]abandoned OSSNs?

Matt: Thanks for asking this. I forwarded this email to the new email list so that folks with better knowledge can answer this. Thanks and have a great day. Yours, Michael - Michael Xin | Manager, Security

Re: [openstack-dev] [TripleO] Can we create some subteams?

On 04/11/2016 04:19 AM, Steven Hardy wrote: > On Mon, Apr 11, 2016 at 05:54:11AM -0400, John Trowbridge wrote: > > Hola OOOers, > > > > It came up in the meeting last week that we could benefit from a CI > > subteam with its own meeting, since CI is taking up a lot of the main > > meeting time. >

Re: [openstack-dev] [neutron] [nova] scheduling bandwidth resources / NIC_BW_KB resource class

On Mon, Apr 11, 2016 at 1:46 PM, Jay Pipes wrote: > Hi Miguel Angel, comments/answers inline :) > > On 04/08/2016 09:17 AM, Miguel Angel Ajo Pelayo wrote: >> >> Hi!, >> >> In the context of [1] (generic resource pools / scheduling in nova) >> and [2] (minimum bandwidth

[openstack-dev] [puppet] weekly meeting #78

Hi, We'll have our weekly meeting tomorrow 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-20160412 We'll also have open discussion

Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion

On 04/08/2016 03:23 AM, Xie, Xianshan wrote: > According to the discussion, a new header would be a good idea to resolve > this issue [4], we think. > For instance: > curl -X DELETE "http://xxx:9696/v2.0/networks/xxx; -H > "Neutron-Common-Error-Format: True" > > But we haven't decided which

[openstack-dev] [keystone][performance][profiling] Profiling Mitaka Keystone: some results and asking for a help

Hey, openstackers! Recently I was trying to profile Keystone (OpenStack Liberty vs Mitaka) using this set of changes (that's currently on review - some final steps are required there to finish the work) and

Re: [openstack-dev] [oslo] Removing Nova specifics from oslo.log

On 04/11/2016 10:08 AM, Ed Leafe wrote: > On 04/11/2016 08:38 AM, Julien Danjou wrote: > >> There's a lot of assumption in oslo.log about Nova, such as talking >> about "instance" and "context" in a lot of the code by default. There's >> even a dependency on oslo.context. >.< >> >> That's being

  1   2   >