[openstack-dev] [heat] RFC: Nested resources missing orchestration UUID at stack lifecycle plugin-time

I'd like to open the proverbial floor for feedback regarding a problem I'm trying to tackle. It concerns Heat's assignment of stack resource UUIDs prior to a stack's instantiation. (Note that this is not the same as physical UUIDs assigned by Nova, Cinder, et. al; one ID is

Re: [openstack-dev] [kolla] Requirement for bug when reno is present

> On 30 Aug 2016, at 12:42, Paul Bourke wrote: > > Do people feel we still want to require a bug-id in the commit message for > features, when reno notes are present? My understanding is that till now > we've required people to add bugs for non trivial features in order

Re: [openstack-dev] [heat][yaql] Deep merge map of lists?

On Tue, Aug 30, 2016 at 6:02 PM, Steven Hardy wrote: > On Tue, Aug 30, 2016 at 04:10:47PM +0200, Jiří Stránský wrote: >> >> On 30.8.2016 10:17, Steven Hardy wrote: >> >> >> >> > Yeah, that gets us closer, but we do need to handle more than one value >> > (list entry) per key,

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

>> I don't think it's all that ambitious to think we can just use >> tried and tested schema evolution techniques that work for everyone >> else. > > People have been asking me for over a year how to do this, and I have > no easy answer, I'm glad that you do. I would like to see some > examples

Re: [openstack-dev] [tripleo] Feature freeze exception for OVN

On Tue, Aug 30, 2016 at 07:53:07PM +0530, Babu Shanmugam wrote: > Hi, > > The THT patch for OVN [1] has no more dependencies with the recent merging > of [2]. The changes in heat templates does not have any impact on the > existing templates as major of the changes are in new templates and will

[openstack-dev] The State of the NFS Driver ...

All, I wanted to follow up on the e-mail thread [1] on Cloning support in the NFS driver. The purpose of this e-mail is to provide the plan for the NFS driver going forward as I see it. First, I am aware that the driver has gone quite some time without care and feeding. For a number of

Re: [openstack-dev] [ironic] should we provide 'ironic node-list --chassis' and 'ironic port-list --node' commands?

The ironic node-list --chassis seems to be easier to understand for me. I've commented on one of the patches that maybe we should deprecate the chassis-node-list if we add this, but then, the deprecation is slow, we have some functional tests already... Having two commands kind of reflects the

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

- Mail original - > De: "Andrew Laski" > À: openstack-dev@lists.openstack.org > Envoyé: Mardi 30 Août 2016 15:03:35 > Objet: Re: [openstack-dev] [all][massively > distributed][architecture]Coordination between actions/WGs > > > > On Tue, Aug 30, 2016, at 05:36 AM,

[openstack-dev] [tripleo] Feature freeze exception for OVN

Hi, The THT patch for OVN [1] has no more dependencies with the recent merging of [2]. The changes in heat templates does not have any impact on the existing templates as major of the changes are in new templates and will be used only when OVN is enabled. It would be nice to have OVN

Re: [openstack-dev] [heat][yaql] Deep merge map of lists?

On Tue, Aug 30, 2016 at 04:10:47PM +0200, Jiří Stránský wrote: > > On 30.8.2016 10:17, Steven Hardy wrote: > > > > > Yeah, that gets us closer, but we do need to handle more than one value > > (list entry) per key, e.g: > > > > data: > >l: > > -

Re: [openstack-dev] [tempest][cinder] Clone feature toggle not in clone tests

Ben, Thank you very much for the history on the driver here. This was all news to me. It helps me to understand why cloning was listed as supported but was no longer implemented. Also explains why the simpler 'cp' based solution hasn't been implemented. I was wondering why that hadn't

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

Excerpts from Mike Bayer's message of 2016-08-26 11:50:24 -0400: > > On 08/25/2016 01:13 PM, Steve Martinelli wrote: > > The keystone team is pursuing a trigger-based approach to support > > rolling, zero-downtime upgrades. The proposed operator experience is > > documented here: > > > >

Re: [openstack-dev] [heat][yaql] Deep merge map of lists?

On 30.8.2016 10:17, Steven Hardy wrote: Yeah, that gets us closer, but we do need to handle more than one value (list entry) per key, e.g: data: l: - "gnocchi_metricd_node_names": ["a0", "a1", "a2"] "tripleo_packages_node_names": ["a0", "a1",

Re: [openstack-dev] [heat][yaql] Deep merge map of lists?

expression: $.data.l.reduce($1.mergeWith($2)) Or maybe it's better with seed value for reduce, just in case: $.data.l.reduce($1.mergeWith($2), {}) Jirka __ OpenStack Development Mailing List (not for usage

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

No topic this week, meeting cancelled! See you next week :) On Mon, Aug 29, 2016 at 1:45 PM, Emilien Macchi <emil...@redhat.com> wrote: > Hi, > > If you have any topic to add for this week, please use the etherpad: > https://etherpad.openstack.org/p/puppet-openstack-weekl

[openstack-dev] [kuryr] Python 3 usage and kuryr-kubernetes

Hi fellow kuryrs! This email is gonna be a bit long, so I'll put it in parts. Kubernetes integration components == As you know, we are now in the process of upstreaming the Kuryr Kubernetes PoC that the Kuryr team at Midokura did. This PoC upstreaming effort has two main

[openstack-dev] [new][openstackclient] os-client-config 1.21.0 release (newton)

We are high-spirited to announce the release of: os-client-config 1.21.0: OpenStack Client Configuation Library This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/os-client-config With package available at:

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

Hi Yujun, From: Yujun Zhang Date: Monday, 29 August 2016 at 11:59 entities: - type: switch name: switch-1 id: switch-1 # should be same as name state: available relationships: - type: nova.host name: host-1 id: host-1 # should be same as name is_source:

Re: [openstack-dev] [neutron][networking-sfc] Unable to create openstack SFC

Hi, Have you received my previous email ? Regards, On 15 August 2016 at 13:39, Alioune wrote: > Hi all, > I'm trying to launch Openstack SFC as explained in[1] by creating 2 SFs, 1 > Web Server (DST) and the DHCP namespace as the SRC. > I've installed OVS (Open vSwitch)

Re: [openstack-dev] [heat][yaql] Deep merge map of lists?

On 30.8.2016 18:16, Zane Bitter wrote: On 30/08/16 12:02, Steven Hardy wrote: debug_tripleo2: value: yaql: expression: $.data.l.reduce($1.mergeWith($2)) data: l: - "gnocchi_metricd_node_names": ["overcloud-controller-0",

Re: [openstack-dev] [Horizon][FFE]Support a param to specify subnet or fixed IP when creating port

I’m happy to allow this personally, but wanted to get others input and give people the chance to object. My reasoning for allowing this: - It’s high level, doesn’t affect any base horizon lib features. - It is mature code, has multiple patch sets and a +2 I’ll give it a few days to allow others

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

>> Even in the case of projects using versioned objects, it still >> means a SQL layer has to include functionality for both versions of >> a particular schema change which itself is awkward. That's not true. Nova doesn't have multiple models to straddle a particular change. We just... > It's

Re: [openstack-dev] [nova] Next steps for resource providers work

On 8/29/2016 2:40 PM, Matt Riedemann wrote: I've been out for a week and not very involved in the resource providers work, but after talking about the various changes up in the air at the moment a bunch of us thought it would be helpful to lay out next steps for the work we want to get done this

[openstack-dev] [tripleo] FFE request for Ceph RGW integration

Together with Keith we're working on some patches to integrate (via puppet-ceph) the deployment of Ceph RGW in TripleO as a composable service which can optionally replace SwiftProxy Changes are tracked via blueprint at: https://blueprints.launchpad.net/tripleo/+spec/ceph-rgw-integration

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

On Tue, Aug 30, 2016, at 09:55 AM, lebre.adr...@free.fr wrote: > > > - Mail original - > > De: "Andrew Laski" > > À: openstack-dev@lists.openstack.org > > Envoyé: Mardi 30 Août 2016 15:03:35 > > Objet: Re: [openstack-dev] [all][massively > >

[openstack-dev] [manila] [security] [tc] Add the vulnerability:managed tag to Manila

Ben has proposed[1] adding manila, manila-ui and python-manilaclient to the list of deliverables whose vulnerability reports and advisories are overseen by the OpenStack Vulnerability Management Team. This proposal is an assertion that the requirements[2] for the vulnerability:managed governance

Re: [openstack-dev] [heat][yaql] Deep merge map of lists?

On 30.8.2016 18:02, Steven Hardy wrote: On Tue, Aug 30, 2016 at 04:10:47PM +0200, Jiří Stránský wrote: On 30.8.2016 10:17, Steven Hardy wrote: Yeah, that gets us closer, but we do need to handle more than one value (list entry) per key, e.g: data: l: -

Re: [openstack-dev] [heat][yaql] Deep merge map of lists?

On 30/08/16 12:02, Steven Hardy wrote: debug_tripleo2: value: yaql: expression: $.data.l.reduce($1.mergeWith($2)) data: l: - "gnocchi_metricd_node_names": ["overcloud-controller-0", "overcloud-controller-1",

[openstack-dev] [api] [devstack] [ocata] Consistent Endpoint Discovery

Hey everyone - I have a little bit of a UX request for our API developers. For the last week or so, I've been working on building version negotiation logic for an OpenStack SDK. The process is pretty simple: 1- Read clouds.yaml for the keystone URL. 2- Query keystone for the service catalog. 3-

[openstack-dev] [new][nova] os_vif 1.2.0 release (newton)

We are delighted to announce the release of: os_vif 1.2.0: A library for plugging and unplugging virtual interfaces in OpenStack. This release is part of the newton release series. With package available at: https://pypi.python.org/pypi/os_vif For more details, please see below. Changes

Re: [openstack-dev] [neutron][networking-sfc] Unable to create openstack SFC

Hi Alioune, It is weird that when you create a port chain, you get a “chain delete failed” error message. We never had this problem. Chain deletion is only involved when you do “delete chain” or “update chain”. Not sure which networking code file combination you are using or whether it is

[openstack-dev] [ironic] API v.next meeting cancelled

Sorry for the late notice, but we decided we'd rather keep working on Newton things this week instead of having this meeting, so it's cancelled for today. // jim __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [glance] Barcelona summit space requirements and session planning etherpad

This was sent earlier in the day. Please note the final request for schedule sent: FB: 2, WR: 2, CM: 1 Also, a request was made to have all Glance sessions on same day for the convenience of the audience willing to show up (be in the same place/floor/etc.) and request for the contributors'

[openstack-dev] [oslo] Barcelona summit space and sessions!

Hi all oslo (and others), Just to make sure that everyone is aware, we have a summit soon in barcelona (ha); hopefully that's not news to many, the bigger news though is that we (the oslo folks) need to decide on how many fishbowls and working rooms we would like to get. I've brought this

Re: [openstack-dev] [kolla] Requirement for bug when reno is present

The bug id and blueprint id are for automatic tracking via Launchpad. If they are omitted, managing the release becomes especially difficult. Unfortunately launchpad doesn't know about reno because then I'd agree, that would be an optimal way too go. Regards -steve On 8/30/16, 3:42 AM,

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 08/30/2016 09:57 AM, Clint Byrum wrote: As someone else brought up, this is an unnecessarily bleak view of how database migrations work. We aren't talking about database migrations. We are talking about *online* database migrations, where we would like both the *old* and *new*

Re: [openstack-dev] [oslo] Barcelona summit space and sessions!

Sounds good Josh On Tue, Aug 30, 2016 at 1:53 PM, Joshua Harlow wrote: > Hi all oslo (and others), > > Just to make sure that everyone is aware, we have a summit soon in barcelona > (ha); hopefully that's not news to many, the bigger news though is that we > (the oslo

Re: [openstack-dev] [tripleo] FFE request for Ceph RGW integration

Here's my 2 cents: The patch in puppet-ceph has been here for long time now and it still doesn't work (recent update of today, puppet-ceph is not idempotent when deploying RGW service. It must be fixed in order to get successful deployment). Puppet CI is still not gating on Ceph RGW (scenario004

Re: [openstack-dev] [tripleo] Barcelona Design Summit space needs

On Thu, Aug 25, 2016 at 07:18:26PM -0400, James Slagle wrote: > On Thu, Aug 25, 2016 at 9:10 AM, Steven Hardy wrote: > > On Tue, Aug 23, 2016 at 09:04:15AM -0400, Emilien Macchi wrote: > >> As a reminder, here's what we had for Austin: > >> Fishbowl slots (Wed-Thu): 2 > >>

Re: [openstack-dev] [heat][yaql] Deep merge map of lists?

FYI: we’re in the process of doing almost that =)  Here is a link for yaql doc commits  https://review.openstack.org/#/q/status:open+project:openstack/yaql+branch:master+topic:yaqldocs We plan to have it finished and published in time for N release and Barcelona =) --  Kirill Zaitsev Murano

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 08/30/2016 04:43 PM, Clint Byrum wrote: Correct, it is harder for development. Since the database server has all of the potential for the worst problems, being a stateful service, then I believe moving complexity _out_ of it, is generally an operational win, at the expense of some

[openstack-dev] [kolla] Deadline Aug 31 for Newton Milestone #3

Hey folks, The deadline for milestone #3 is August 31st (this is when we are tagging milestone #3). We then have until September 15th to stabilize the release and tag rc1. The release team branches occata at rc1, so if a feature doesn’t make rc1, its not making newton. After rc1, any

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

Excerpts from Mike Bayer's message of 2016-08-30 14:56:15 -0400: > > On 08/30/2016 09:57 AM, Clint Byrum wrote: > >> > > > > As someone else brought up, this is an unnecessarily bleak view of how > > database > > migrations work. > > We aren't talking about database migrations. We are talking

Re: [openstack-dev] [tripleo] launchpad bugs

As a gentle and peaceful reminder, please make auto triage when filing a bug and keep track on it. - Set priority level, set it to triaged if you set a milestone. - Assign the bug to yourself if you work on it. - Set it to Fix released when your patch is merged and automation didn't update

Re: [openstack-dev] [heat][yaql] Deep merge map of lists?

On 30/08/16 12:18, Jiří Stránský wrote: Hmm yea that's strange, because YAQL has a test case for reduce() with 5 items: https://github.com/openstack/yaql/blob/f71a0305089997cbfa5ff00f660920711b04f39e/yaql/tests/test_queries.py#L337-L339 If YAQL people are reading this, I suggest you should

Re: [openstack-dev] [nova][keystone] auth for new metadata plugins

Sorry for being slow on this one, I've been pulled into some internal things at work. So... Talking to Matt Riedemann just now, it seems like we should continue to pass through the user authentication details when we have them to the plugin. The problem is what to do in the case where we do not

Re: [openstack-dev] [nova][keystone] auth for new metadata plugins

On 8/30/2016 4:36 PM, Michael Still wrote: Sorry for being slow on this one, I've been pulled into some internal things at work. So... Talking to Matt Riedemann just now, it seems like we should continue to pass through the user authentication details when we have them to the plugin. The

Re: [openstack-dev] [heat][yaql] Deep merge map of lists?

There is a bug in how yaql interprets its 3rd argument (aggregator). It was supposed to be a function to aggregate values within each group but instead was applied to the outcome of groupBy. I submitted a fix for this: https://review.openstack.org/363191. Though I'm not sure we can release new

[openstack-dev] [new][winstackers] os-win 1.2.0 release (newton)

We are tickled pink to announce the release of: os-win 1.2.0: Windows / Hyper-V library for OpenStack projects. This release is part of the newton stable release series. With source available at: http://git.openstack.org/cgit/openstack/os-win With package available at:

Re: [openstack-dev] [tripleo] FFE request for Ceph RGW integration

On Tue, Aug 30, 2016 at 03:25:30PM -0400, Emilien Macchi wrote: > Here's my 2 cents: > > The patch in puppet-ceph has been here for long time now and it still > doesn't work (recent update of today, puppet-ceph is not idempotent > when deploying RGW service. It must be fixed in order to get >

Re: [openstack-dev] [nova] no nova bugs team meeting today

Yeah, no meeting again, same reason :/ -- Regards, Markus Zoeller (markus_z) On 23.08.2016 14:21, Markus Zoeller wrote: > I get dragged into some internal stuff recently and didn't have time to > prepare anything or host the meeting. > > One noteworthy thing though, please tag any bug report,

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

What is the problem you are running into with mock_sync? Elisha From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] Sent: Tuesday, August 30, 2016 5:09 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [vitrage] relationship_type in

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

Excerpts from Mike Bayer's message of 2016-08-30 18:15:14 -0400: > > On 08/30/2016 04:43 PM, Clint Byrum wrote: > >> > > > > Correct, it is harder for development. Since the database server has all > > of the potential for the worst problems, being a stateful service, then > > I believe moving

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

Since the encrypted credential work is currently based on triggers, I spent most of today documenting a walk-though migration from Mitaka to Newton [0]. Regardless of the outcome discussed here - figured it would be worth sharing since it's relevant to the thread. Most of the gist contains stuff

Re: [openstack-dev] The State of the NFS Driver ...

On 8/30/2016 10:50 AM, Jay S. Bryant wrote: All, I wanted to follow up on the e-mail thread [1] on Cloning support in the NFS driver. The purpose of this e-mail is to provide the plan for the NFS driver going forward as I see it. First, I am aware that the driver has gone quite some time

[openstack-dev] [requirements] upcoming freeze (was Re: [release] Release countdown for week R-5, 29 Aug - 2 Sept)

Hi all, I'd just like to add a point to Doug's email. Along with this being the Final release for client libraries freeze its also the requirements freeze. That means that on Thursday Sept 1st (UTC) we'll add a procedural -2 to all open changes in the master branch of openstack/requirements.

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 08/30/2016 08:04 PM, Clint Byrum wrote: My direct experience with this was MySQL 5.0 and 5.1. They worked as documented, and no I don't think they've changed much since then. When they were actually installed into the schema and up to date with the code that expected them, and the

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

Cells is a good enhancement for Nova scalability, but there are some issues in deployment Cells for massively distributed edge clouds: 1) using RPC for inter-data center communication will bring the difficulty in inter-dc troubleshooting and maintenance, and some critical issue in operation.

[openstack-dev] [glance] store and client stable branches for newton

Hi, The stable/newton has been cut and respective commits have merged for both store and client [1]. Please feel free to merge any commits on master that were pending however, note that we won't be releasing any libraries out until R-0 when the freeze on libraries stops. Let me know if there are

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

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

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

joehuang wrote: Cells is a good enhancement for Nova scalability, but there are some issues in deployment Cells for massively distributed edge clouds: 1) using RPC for inter-data center communication will bring the difficulty in inter-dc troubleshooting and maintenance, and some critical

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

Dear all Sorry my lack of reactivity, I 've been out for the few last days. According to the different replies, I think we should enlarge the discussion and not stay on the vCPE use-case, which is clearly specific and represents only one use-case among the ones we would like to study. For

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

On Tue, Aug 30, 2016, at 05:36 AM, lebre.adr...@free.fr wrote: > Dear all > > Sorry my lack of reactivity, I 've been out for the few last days. > > According to the different replies, I think we should enlarge the > discussion and not stay on the vCPE use-case, which is clearly specific >

Re: [openstack-dev] [TripleO] FFE request for Ironic composable services

On Tue, Aug 30, 2016 at 10:20:00AM +0200, Dmitry Tantsur wrote: > Hi all! > > Bare metal provisioning is a hot topic right now. These services are also > required for Dan's heat-driven undercloud work. The majority of changes has > landed already, but there a few changes waiting on puppet-ironic

[openstack-dev] [kuryr] openstack/kuryr-libnetwork dropping 'common' subpackage

Hi fellow kuryrs! There is a proposal for dropping the 'common' openstack/kuryr-libnetwork package and move its pieces in the parent kuryr_libnetwork package [1]. The idea behind 'common' was that it would serve the current purpose developed by the openstack/kuryr repository, i.e., to serve as a

Re: [openstack-dev] [TripleO] FFE request for Manila CephFS Native backend integration

On Tue, Aug 30, 2016 at 9:42 AM, Erno Kuvaja wrote: > On Tue, Aug 30, 2016 at 9:09 AM, Steven Hardy wrote: >> On Tue, Aug 30, 2016 at 06:32:16AM +0100, Erno Kuvaja wrote: >>> On Fri, Aug 19, 2016 at 9:53 AM, Erno Kuvaja wrote: >>> > Hi

[openstack-dev] [new][ironic] virtualbmc 0.1.0 release

We are happy to announce the release of: virtualbmc 0.1.0: Create virtual BMCs for controlling virtual instances via IPMI This is the first release of virtualbmc. For more details, please see below. Changes in virtualbmc d10b57d95acd35e47f51aba1fe9a98ccf0de08d3..0.1.0

[openstack-dev] [OSSN 0070] Bandit versions lower than 1.1.0 do not escape HTML in issue reports

Bandit versions lower than 1.1.0 do not escape HTML in issue reports --- ### Summary ### Bandit versions lower than 1.1.0 have a bug in the HTML report formatter that does not escape HTML in issue context snippets. This could lead to an XSS if HTML reports are hosted as part of a CI pipeline.

Re: [openstack-dev] [kolla] Requirement for bug when reno is present

On 30 August 2016 at 11:42, Paul Bourke wrote: > Kolla, > > Do people feel we still want to require a bug-id in the commit message for > features, when reno notes are present? My understanding is that till now > we've required people to add bugs for non trivial features

Re: [openstack-dev] [nova] Next steps for resource providers work

On Mon, 29 Aug 2016, Matt Riedemann wrote: 2. Chris is going to cleanup the devstack change that adds the placement service: https://review.openstack.org/#/c/342362/ The main issue is there isn't a separate placement database, at least not by default, so Chris has to take that into account.

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

lebre.adr...@free.fr wrote: > [...] > According to the different replies, I think we should enlarge the discussion > and not stay on the vCPE use-case, which is clearly specific and represents > only one use-case among the ones we would like to study. For instance we are > in touch with NRENs

Re: [openstack-dev] [heat][yaql] Deep merge map of lists?

On Mon, Aug 29, 2016 at 04:03:27PM +0200, Thomas Herve wrote: > On Mon, Aug 29, 2016 at 3:16 PM, Steven Hardy wrote: > > On Mon, Aug 29, 2016 at 07:07:09AM +0200, Thomas Herve wrote: > >> dict($.groupBy($.keys().toList()[0], $.values().toList()[0][0])) > >> > >> ought to work,

Re: [openstack-dev] [release][barbican][cinder][cloudkitty][ironic][magnum][monasca][searchlight][senlin][solum][swift][tripleo][watcher][winstackers] tags needed to be considered part of Newton

On Mon, Aug 29, 2016 at 10:37 PM, Sean McGinnis wrote: > python-cinderclient this week. It just doesn't have enough activity to > have needed a release any earlier > +1 to Sean on it. All features were merged last few weeks and it sounds good to get it released both with

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

Yes. Please add it to the file /workspace/dev/vitrage/vitrage/tests/resources/mock_configurations/driver/driver_switch_snapshot_dynamic.json under the "relationships" section, just like in your commit. If you need help understanding how to work with the mock_sync, let me know. Elisha From:

[openstack-dev] [nova][kolla] Live migration, VNC / SPICE address?

Hi, In Kolla, we are having an issue with Nova's VNC / SPICE address and live migration. Currently, we are declaring the IP address for vncserver_listen on each node (via ansible). However, when a live migration is performed, it fails due to this address not being available. The hack is to

Re: [openstack-dev] [tripleo] Requesting FFE for improved Swift deployments

On Mon, Aug 29, 2016 at 09:32:09PM +0200, Christian Schwede wrote: > Hello, > > kindly asking for a FFE for a required setting to improve Swift-based > TripleO deployments: > > https://review.openstack.org/#/c/358643/ This looks like it's associated with a bug, and if it's a bugfix then no FFE

[openstack-dev] [kolla] Requirement for bug when reno is present

Kolla, Do people feel we still want to require a bug-id in the commit message for features, when reno notes are present? My understanding is that till now we've required people to add bugs for non trivial features in order to track them as part of releases. Does/should reno supersede this?

[openstack-dev] [TripleO] FFE request for Ironic composable services

Hi all! Bare metal provisioning is a hot topic right now. These services are also required for Dan's heat-driven undercloud work. The majority of changes has landed already, but there a few changes waiting on puppet-ironic changes. The feature is low-impact as it's disabled by default and

Re: [openstack-dev] [nova] Creating VM error: Insufficient compute resources

On Thu, 2016-08-25 at 14:11 +0400, Fawaz Mohammed wrote: > Have you enabled huge page on the host level? > Do you have enough vn.nr_hugepages? > As per your requirements, you need a host with 512 hugepage (1G/2M). > Check your host's /etc/sysctl.conf file and see vm.nr_hugepages > value. As a

Re: [openstack-dev] [TripleO] FFE request for Manila CephFS Native backend integration

On Tue, Aug 30, 2016 at 9:09 AM, Steven Hardy wrote: > On Tue, Aug 30, 2016 at 06:32:16AM +0100, Erno Kuvaja wrote: >> On Fri, Aug 19, 2016 at 9:53 AM, Erno Kuvaja wrote: >> > Hi all, >> > >> > I'm still working on getting all pieces together for the Manila

Re: [openstack-dev] [Nova] Support specified volume_type when boot instance, do we like it?

Dear all, Thanks all for the reply, I have read the etherpad note and there seems no working BP/SPEC now. So I have updated one BP/SPEC from my colleague put up for Mitaka with microversion implementation for Ocata release: BP:

Re: [openstack-dev] [vitrage] relationship_type in static_datasources

I added a new key 'is_source' to static physical configuration [1] and the test currently fails. Not sure we need to update mock_sync or not. [1] https://review.openstack.org/#/c/362525/1/vitrage/tests/resources/static_datasources/switch_to_host_datasource.yaml On Tue, Aug 30, 2016 at 2:53 PM

Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

Colleagues, An interesting discussion, the only question appears to be whether vCPE is a suitable use case as the others do appear to be cloud use cases. Lots of people assume CPE == small residential devices however CPE covers a broad spectrum of appliances. Some of our customers' premises are

[openstack-dev] [vitrage] inspecting external openstack environment

My purpose is to inspect an **existing** openstack environment with vitrage. Do I have to install vitrage on the target environment or it can be done by proper configuration? -- Yujun __ OpenStack Development Mailing List

Re: [openstack-dev] [TripleO] FFE request for Manila CephFS Native backend integration

On Tue, Aug 30, 2016 at 06:32:16AM +0100, Erno Kuvaja wrote: > On Fri, Aug 19, 2016 at 9:53 AM, Erno Kuvaja wrote: > > Hi all, > > > > I'm still working on getting all pieces together for the Manila CephFS > > driver integration and realizing that we have about a week of busy

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 25/08/16 13:13 -0400, Steve Martinelli wrote: The keystone team is pursuing a trigger-based approach to support rolling, zero-downtime upgrades. The proposed operator experience is documented here: http://docs.openstack.org/developer/keystone/upgrading.html This differs from Nova and

Re: [openstack-dev] [nova][kolla] Live migration, VNC / SPICE address?

Dave, Thanks for pointing this out, looks like it is a regression in nova introduced during Newton cycle. At some point we moved checks of graphic and serial consoles to the live migration pre-checks on source node, but we never moved piece of code that populates this data while executing