[openstack-dev] [refstack] Full list of API Tests versus 'OpenStack Powered' Tests

· I have a commercial OpenStack product that I would like to claim compliancy with RefStack · Is it sufficient to claim compliance with only the “OpenStack Powered Platform” TESTS ? oi.e. https://refstack.openstack.org/#/guidelines oi.e. the ~350-ish compute +

Re: [openstack-dev] [kolla][ptg] Team dinner

+1 Thanks for the organisation. > On 26. Feb 2018, at 20:39, Paul Bourke wrote: > > Hey Kolla, > > Hope you're all enjoying Dublin so far :) Some have expressed interest in > getting together for a team meal, how does Thursday sound? Please reply to > this with +1/-1

Re: [openstack-dev] [cinder][nova] Update attachments on replication failover

On Mon, Feb 26, 2018 at 2:47 PM, Matt Riedemann wrote: > On 2/26/2018 9:28 PM, John Griffith wrote: > >> I'm also wondering how much of the extend actions we can leverage here, >> but I haven't looked through all of that yet.​ >> > > The os-server-external-events API in nova

Re: [openstack-dev] [cinder][nova] Update attachments on replication failover

On 2/26/2018 9:28 PM, John Griffith wrote: I'm also wondering how much of the extend actions we can leverage here, but I haven't looked through all of that yet.​ The os-server-external-events API in nova is generic. We'd just add a new microversion to register a new tag for this event. Like

Re: [openstack-dev] [kolla][ptg] Team dinner

+1 On 26 Feb 2018, at 21:38, Mark Goddard > wrote: +1 On 26 Feb 2018 7:58 p.m., "Eduardo Gonzalez" > wrote: +1 On Mon, Feb 26, 2018, 7:40 PM Paul Bourke

Re: [openstack-dev] [kolla][ptg] Team dinner

+1 On 26 Feb 2018 7:58 p.m., "Eduardo Gonzalez" wrote: > +1 > > On Mon, Feb 26, 2018, 7:40 PM Paul Bourke wrote: > >> Hey Kolla, >> >> Hope you're all enjoying Dublin so far :) Some have expressed interest >> in getting together for a team meal, how

Re: [openstack-dev] [cinder][nova] Update attachments on replication failover

On Mon, Feb 26, 2018 at 2:13 PM, Matt Riedemann wrote: > On 2/26/2018 8:09 PM, John Griffith wrote: > >> I'm interested in looking at creating a mechanism to "refresh" all of the >> existing/current attachments as part of the Cinder Failover process. >> > > What would be

Re: [openstack-dev] [cinder][nova] Update attachments on replication failover

On 2/26/2018 8:09 PM, John Griffith wrote: I'm interested in looking at creating a mechanism to "refresh" all of the existing/current attachments as part of the Cinder Failover process. What would be involved on the nova side for the refresh? I'm guessing disconnect/connect the volume via

[openstack-dev] [cinder][nova] Update attachments on replication failover

Hey Everyone, Something I've been looking at with Cinder's replication (sort of the next step in the evolution if you will) is the ability to refresh/renew in-use volumes that were part of a migration event. We do something similar with extend-volume on the Nova side through the use of Instance

Re: [openstack-dev] [kolla][ptg] Team dinner

+1 On Mon, Feb 26, 2018, 7:40 PM Paul Bourke wrote: > Hey Kolla, > > Hope you're all enjoying Dublin so far :) Some have expressed interest > in getting together for a team meal, how does Thursday sound? Please > reply to this with +1/-1 and I can see about booking

[openstack-dev] [kolla][ptg] Team dinner

Hey Kolla, Hope you're all enjoying Dublin so far :) Some have expressed interest in getting together for a team meal, how does Thursday sound? Please reply to this with +1/-1 and I can see about booking something. Cheers, -Paul

Re: [openstack-dev] [ironic] Stepping down from Ironic core

Hey Vasyl, Thanks for all your contributions to Ironic! I hope that you'll still find a bit of time for us :-) --ruby From: Vasyl Saienko Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Friday, February

Re: [openstack-dev] [kolla] Ubuntu jobs failed on pike branch due to package dependency

I'm for option 1 definitely. accidental ceph upgrade during routine minor version upgrade is something we don't want. We will need big warning about this version mismatch in release notes. On 26 February 2018 at 07:01, Eduardo Gonzalez wrote: > I prefer option 1, breaking

Re: [openstack-dev] [magnum][keystone] clusters, trustees and projects

On 02/26/2018 10:17 AM, Ricardo Rocha wrote: > Hi. > > We have an issue on the way Magnum uses keystone trusts. > > Magnum clusters are created in a given project using HEAT, and require > a trust token to communicate back with OpenStack services - there is > also integration with Kubernetes

Re: [openstack-dev] [kolla] Ubuntu jobs failed on pike branch due to package dependency

I prefer option 1, breaking stable policy is not good for users. They will be forced to upgrade a major ceph version during a minor upgrade, which is not good and not excepted to be done ever. Regards 2018-02-26 9:51 GMT+01:00 Shake Chen : > I prefer to the option 2. > >

Re: [openstack-dev] [ptg] Release cycles, stable branch maintenance, LTS vs. downstream consumption models

Thomas Goirand wrote: > On 02/24/2018 03:42 PM, Thierry Carrez wrote: >> On Tuesday afternoon we'll have a discussion on release cycle duration, >> stable branch maintenance, and LTS vs. how OpenStack is consumed downstream. >> >> I set up an etherpad at: >>

Re: [openstack-dev] [sdk] Cleaning up openstacksdk core team

Excerpts from Monty Taylor's message of 2018-02-26 11:41:18 +: > Hey all, > > A bunch of stuff has changed in SDK recently, and a few of the > historical sdk core folks have also not been around. I'd like to propose > removing the following people from the core team: > >Everett Towes >

Re: [openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

One of the concerns here is that the openstack client does not enable one to configure extensions that are not part of the core reference architecture. So any external third part that tries to have any etension added will not be able to leverage the openstack client. This is a major pain point.

[openstack-dev] [Murano]No meeting at Feb 28

Hi Teams, Let's cancel meetings at 28 Feb because of PTG. Cheers, Rong Zhu __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[openstack-dev] [sdk] Cleaning up openstacksdk core team

Hey all, A bunch of stuff has changed in SDK recently, and a few of the historical sdk core folks have also not been around. I'd like to propose removing the following people from the core team: Everett Towes Jesse Noller Richard Theis Terry Howe They're all fantastic humans but

Re: [openstack-dev] [PTG] Project interviews at the PTG

A HUGE thank you to all of the people who have signed up to do interviews at the PTG. Tuesday is now completely full, but I still have space/time on the remaining days. I have set up on the 4th floor. Turn left when you exit the lifts, and I'm set up by the couches in the break area. Please

Re: [openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

On 02/26/2018 10:55 AM, Rabi Mishra wrote: On Mon, Feb 26, 2018 at 3:44 PM, Monty Taylor > wrote: On 02/26/2018 09:57 AM, Akihiro Motoki wrote: Hi neutron and openstacksdk team, This mail proposes to change the first

Re: [openstack-dev] [k8s][ptg] SIG-K8s Scheduling for Dublin PTG

Initial scheduling is live for sig-k8s work at the PTG. Tuesday morning is going to be devoted to external provider migration and documentation. Late morning includes a Kolla sesison. The afternoon is mostly free, with a session set aside for testing. If you have topics you'd like to have sessions

Re: [openstack-dev] [sdk] Nominating Adrian Turjak for core

+1 On Mon, Feb 26, 2018 at 11:46, Sławomir Kapłoński wrote: +1 — Best regards Slawek Kaplonski sla...@kaplonski.pl > Wiadomość napisana przez Monty Taylor w dniu > 26.02.2018, o godz. 11:31: > > Hey everybody, > > I'd like to nominate Adrian Turjak

Re: [openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

On Mon, Feb 26, 2018 at 3:44 PM, Monty Taylor wrote: > On 02/26/2018 09:57 AM, Akihiro Motoki wrote: > >> Hi neutron and openstacksdk team, >> >> This mail proposes to change the first priority of neutron-related >> python binding to OpenStack SDK rather than neutronclient

Re: [openstack-dev] [sdk] Nominating Adrian Turjak for core

+1 — Best regards Slawek Kaplonski sla...@kaplonski.pl > Wiadomość napisana przez Monty Taylor w dniu > 26.02.2018, o godz. 11:31: > > Hey everybody, > > I'd like to nominate Adrian Turjak (adriant) for openstacksdk-core. He's an > Operator/End User and brings

[openstack-dev] [sdk] Nominating Adrian Turjak for core

Hey everybody, I'd like to nominate Adrian Turjak (adriant) for openstacksdk-core. He's an Operator/End User and brings *excellent* deep/strange/edge-condition bugs. He also has a great understanding of the mechanics between Resource/Proxy objects and is super helpful in verifying fixes work

Re: [openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

I also agree that it is good idea and I would be very happy to help with such migration :) — Best regards Slawek Kaplonski sla...@kaplonski.pl > Wiadomość napisana przez Monty Taylor w dniu > 26.02.2018, o godz. 11:14: > > On 02/26/2018 09:57 AM, Akihiro Motoki wrote:

[openstack-dev] [magnum][keystone] clusters, trustees and projects

Hi. We have an issue on the way Magnum uses keystone trusts. Magnum clusters are created in a given project using HEAT, and require a trust token to communicate back with OpenStack services - there is also integration with Kubernetes via a cloud provider. This trust belongs to a given user,

Re: [openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

On 02/26/2018 09:57 AM, Akihiro Motoki wrote: Hi neutron and openstacksdk team, This mail proposes to change the first priority of neutron-related python binding to OpenStack SDK rather than neutronclient python bindings. I think it is time to start this as OpenStack SDK became a official

Re: [openstack-dev] [infra] Please delete branch "notif" of project tatu

On Mon, Feb 26, 2018, at 1:59 AM, Pino de Candia wrote: > Hi OpenStack-Infra Team, > > Please delete branch "notif" of openstack/tatu. > > The project was recently created/imported from my private repo and only the > master branch is needed for the community project. Done. Just for historical

[openstack-dev] [infra] Please delete branch "notif" of project tatu

Hi OpenStack-Infra Team, Please delete branch "notif" of openstack/tatu. The project was recently created/imported from my private repo and only the master branch is needed for the community project. thanks for your help! Pino

[openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

Hi neutron and openstacksdk team, This mail proposes to change the first priority of neutron-related python binding to OpenStack SDK rather than neutronclient python bindings. I think it is time to start this as OpenStack SDK became a official project in Queens. [Current situations and problems]

Re: [openstack-dev] [Openstack-operators] User Committee Election Results - February 2018

Congrats everyone! And thanks to the UC Election Committee for managing :) Cheers, Jimmy Shilla Saebi February 25, 2018 at 11:52 PM Hello Everyone! Please join me in congratulating 3 newly elected members of the User Committee (UC)! The winners for the 3 seats

Re: [openstack-dev] [User-committee] User Committee Election Results - February 2018

Congrats to new committee members. And thanks for great job for previous ones. From: Shilla Saebi [mailto:shilla.sa...@gmail.com] Sent: Sunday, February 25, 2018 5:52 PM To: user-committee ; OpenStack Mailing List ; OpenStack

[openstack-dev] [mistral] What's new in latest CloudFlow?

CloudFlow [1] is an open-source web-based GUI tool that helps visualize and debug Mistral workflows. With the latest release [2] of CloudFlow (v0.5.0) you can: * Visualize the flow of workflow executions * Identify the execution path of a single task in huge workflows * Search Mistral by any

Re: [openstack-dev] [kolla] Ubuntu jobs failed on pike branch due to package dependency

I prefer to the option 2. On Mon, Feb 26, 2018 at 4:39 PM, Jeffrey Zhang wrote: > Recently, the Ubuntu jobs on pike branch are red[0]. With some debugging, > i found it is caused by > package dependency. > > > *Background* > > Since we have no time to upgrade ceph from

[openstack-dev] [kolla] Ubuntu jobs failed on pike branch due to package dependency

Recently, the Ubuntu jobs on pike branch are red[0]. With some debugging, i found it is caused by package dependency. *Background* Since we have no time to upgrade ceph from Jewel to Luminous at the end of pike cycle, we pinned Ceph to Jewel on pike branch. This works on CentOS, because ceph

Re: [openstack-dev] [nova] [placement] resource providers update 18-07

On 02/24/2018 02:17 AM, Matt Riedemann wrote: On 2/16/2018 7:54 AM, Chris Dent wrote: Before I get to the meat of this week's report, I'd like to request some feedback from readers on how to improve the report. Over its lifetime it has grown and it has now reached the point that while it tries