Re: [openstack-dev] openstack-dev] [trove] Considering the transfter of the project leadership

2018-07-27 Thread Dariusz Krol
Hi Sean,   This is good point. It would be great to have some help especially to start. We have some experience with contributing to openstack and we are working with gerrit on daily basis so there is no problem with technical aspects. However, it takes some time for changes to be reviewed

Re: [openstack-dev] [edge][glance]: Image handling in edge environment

2018-07-27 Thread Csatari, Gergely (Nokia - HU/Budapest)
Hi, The meeting will take place on 2018.08.01 18-19h CET. Here I attach the invitation. Br, Gerg0 From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Friday, July 20, 2018 1:32 PM To: 'edge-computing' ; 'OpenStack Development Mailing List (not for usage questions)' Cc: 'jokke' Subject: RE:

[openstack-dev] [tripleo] Rocky Ceph update/upgrade regression risk (semi-FFE)

2018-07-27 Thread Jiří Stránský
Hi folks, i want to raise attention on remaining patches that are needed to prevent losing Ceph updates/upgrades in Rocky [1], basically making the Ceph upgrade mechanism compatible with config-download. I'd call this a semi-FFE, as a few of the patches have characteristics of feature work,

[openstack-dev] [magnum] PTL Candidacy for Stein

2018-07-27 Thread Spyros Trigazis
Hello OpenStack community! I would like to nominate myself as PTL for the Magnum project for the Stein cycle. In the last cycle magnum became more stable and is reaching the point of becoming a feature complete solution for providing managed container clusters for private or public OpenStack

Re: [openstack-dev] [glance] FFE for multi-backend

2018-07-27 Thread Erno Kuvaja
On Thu, Jul 26, 2018 at 3:35 PM, Abhishek Kekane wrote: > I'm asking for a Feature Freeze Exception for Multiple backend support > (multi-store) > feature [0]. The only remaining work is a versioning patch to flag this > feature as > experimental and should be completed early next week. > > [0]

Re: [openstack-dev] [glance] FFE for multihash

2018-07-27 Thread Erno Kuvaja
On Thu, Jul 26, 2018 at 3:28 PM, Brian Rosmaita wrote: > I'm asking for a Feature Freeze Exception for the glance-side work for > the Secure Hash Algorithm Support (multihash) feature [0]. The work > is underway and should be completed early next week. > > cheers, > brian > > [0] >

Re: [openstack-dev] [tripleo] Rocky Ceph update/upgrade regression risk (semi-FFE)

2018-07-27 Thread Emilien Macchi
On Fri, Jul 27, 2018 at 3:58 AM Jiří Stránský wrote: > I'd call this a semi-FFE, as a few of the patches have characteristics of > feature work, > but at the same time i don't believe we can afford having Ceph > unupgradable in Rocky, so it has characteristics of a regression bug > too. I

Re: [openstack-dev] [tripleo] [tripleo-validations] using using top-level fact vars will deprecated in future Ansible versions

2018-07-27 Thread Sam Doran
> so if, for convenience, we do this: > vars: > a_mounts: "{{ hostvars[inventory_hostname].ansible_facts.mounts }}" > > That's completely acceptable and correct, and won't create any security > issue, right? Yes, that will work, but you don't need to use the hostvars dict. You can simply use

Re: [openstack-dev] [cinder] about block device driver

2018-07-27 Thread Matt Riedemann
On 7/16/2018 4:20 AM, Gorka Eguileor wrote: If I remember correctly the driver was deprecated because it had no maintainer or CI. In Cinder we require our drivers to have both, otherwise we can't guarantee that they actually work or that anyone will fix it if it gets broken. Would this really

Re: [openstack-dev] [tripleo] Rocky Ceph update/upgrade regression risk (semi-FFE)

2018-07-27 Thread Alex Schultz
On Fri, Jul 27, 2018 at 5:48 AM, Emilien Macchi wrote: > > > On Fri, Jul 27, 2018 at 3:58 AM Jiří Stránský wrote: >> >> I'd call this a semi-FFE, as a few of the patches have characteristics of >> feature work, >> but at the same time i don't believe we can afford having Ceph >> unupgradable in

[openstack-dev] [nova] [placement] placement update 18-30

2018-07-27 Thread Chris Dent
HTML: https://anticdent.org/placement-update-18-30.html This is placement update 18-30, a weekly update of ongoing development related to the [OpenStack](https://www.openstack.org/) [placement service](https://developer.openstack.org/api-ref/placement/). # Most Important This week is

Re: [openstack-dev] [tripleo] network isolation can't find files referred to on director

2018-07-27 Thread James Slagle
On Thu, Jul 26, 2018 at 4:58 AM, Samuel Monderer wrote: > Hi James, > > I understand the network-environment.yaml will also be generated. > What do you mean by rendered path? Will it be > "usr/share/openstack-tripleo-heat-templates/network/ports/"? Yes, the rendered path is the path that the

[openstack-dev] [keystone] Keystone Team Update - Week of 23 July 2018

2018-07-27 Thread Lance Bragstad
# Keystone Team Update - Week of 23 July 2018 ## News This week wrapped up rocky-3, but the majority of the things working through review are refactors that aren't necessarily susceptible to the deadline. ## Recently Merged Changes Search query: https://bit.ly/2IACk3F We merged 32 changes

[openstack-dev] [charms] PTL non-candidacy for Stein cycle

2018-07-27 Thread James Page
Hi All I won't be standing for PTL of OpenStack Charms for this upcoming cycle. Its been my pleasure to have been PTL since the project was accepted into OpenStack, but its time to let someone else take the helm. I'm not going anywhere but expect to have a bit of a different focus for this

[openstack-dev] [chef] PTL candidacy for Stein

2018-07-27 Thread Samuel Cassiba
Howdy! I am submitting my name to continue as PTL for Chef OpenStack. If you don't know me, I am scas on Freenode. I work for Workday, where I am an active operator and upstream developer. I have contributed to OpenStack since 2014, and joined the Chef core team in early 2015. Since then, I have

Re: [openstack-dev] [nova] [placement] placement update 18-30

2018-07-27 Thread Matt Riedemann
On 7/27/2018 8:07 AM, Chris Dent wrote: # Questions I wrote up some analysis of the way the [resource tracker talks to placement](https://anticdent.org/novas-use-of-placement.html). It identifies some redundancies. Actually it reinforces that some redundancies we've known about are still there.

Re: [openstack-dev] [nova] keypair quota usage info for user

2018-07-27 Thread Matt Riedemann
On 7/25/2018 4:44 AM, Ghanshyam Mann wrote: From checking the history and review discussion on [3], it seems that it was like that from staring. key_pair quota is being counted when actually creating the keypair but it is not shown in API 'in_use' field. Just so I'm clear which API we're

Re: [openstack-dev] [charms] PTL non-candidacy for Stein cycle

2018-07-27 Thread Jean-Philippe Evrard
On July 27, 2018 4:09:04 PM UTC, James Page wrote: >Hi All > >I won't be standing for PTL of OpenStack Charms for this upcoming >cycle. > >Its been my pleasure to have been PTL since the project was accepted >into >OpenStack, but its time to let someone else take the helm. I'm not >going

Re: [openstack-dev] [magnum] PTL Candidacy for Stein

2018-07-27 Thread T. Nichole Williams
+1, you’ve got my vote :D T. Nichole Williams tribe...@tribecc.us > On Jul 27, 2018, at 6:35 AM, Spyros Trigazis wrote: > > Hello OpenStack community! > > I would like to nominate myself as PTL for the Magnum project for the > Stein cycle. > > In the last cycle magnum became more stable

Re: [openstack-dev] [nova] keypair quota usage info for user

2018-07-27 Thread Matt Riedemann
On 7/25/2018 12:43 PM, Chris Friesen wrote: Keypairs are weird in that they're owned by users, not projects.  This is arguably wrong, since it can cause problems if a user boots an instance with their keypair and then gets removed from a project. Nova microversion 2.54 added support for

Re: [openstack-dev] [nova] keypair quota usage info for user

2018-07-27 Thread Jay Pipes
On 07/27/2018 03:21 PM, Matt Riedemann wrote: On 7/27/2018 2:14 PM, Matt Riedemann wrote:  From checking the history and review discussion on [3], it seems that it was like that from staring. key_pair quota is being counted when actually creating the keypair but it is not shown in API

Re: [openstack-dev] [nova] keypair quota usage info for user

2018-07-27 Thread Matt Riedemann
On 7/27/2018 2:14 PM, Matt Riedemann wrote:  From checking the history and review discussion on [3], it seems that it was like that from staring. key_pair quota is being counted when actually creating the keypair but it is not shown in API 'in_use' field. Just so I'm clear which API we're

Re: [openstack-dev] [nova] keypair quota usage info for user

2018-07-27 Thread Jeremy Stanley
On 2018-07-27 14:20:01 -0500 (-0500), Matt Riedemann wrote: [...] > Note the entries in there about how several deployments don't rely > on nova's keypair interface because of its clunky nature, and > other ideas about getting nova out of the keypair business > altogether and instead let barbican