Re: [openstack-dev] [nova][glance] Deprecation of nova.image.download.modules extension point

2018-05-31 Thread Chris Friesen
On 05/31/2018 04:14 PM, Moore, Curt wrote: The challenge is that transferring the Glance image transfer is _glacially slow_ when using the Glance HTTP API (~30 min for a 50GB Windows image (It’s Windows, it’s huge with all of the necessary tools installed)). If libvirt can instead perform an

Re: [openstack-dev] [tripleo] Containerized Undercloud by default

2018-05-31 Thread Emilien Macchi
I forgot to mention Steve's effort to update the containers when deploying the undercloud, this is a critical piece if we want to continue to test changes in projects like tripleo-common that are embedded in Mistral containers for example. The patch that will enable it is

[openstack-dev] [tripleo] Containerized Undercloud by default

2018-05-31 Thread Emilien Macchi
Hi, During Rocky cycle we would like to switch tripleoclient to deploy containeirzed undercloud by default but before to get there, we want to switch all CI jobs to it, like it was done when enabling config-download by default. Right now we have 3 jobs which test the containerized undercloud: -

Re: [openstack-dev] [kolla][vote] Nominating Steve Noyes for kolla-cli core reviewer

2018-05-31 Thread Surya Singh
+1 Thanks for work, got the good feedback and interest of kolla-cli in *kolla-rocky-ops-and-user-feedback* session in Vancouver. On Thu, May 31, 2018 at 10:32 PM, Borne Mace wrote: > Greetings all, > > I would like to propose the addition of Steve Noyes to the kolla-cli core > reviewer team.

Re: [openstack-dev] [kolla][vote] Nominating Steve Noyes for kolla-cli core reviewer

2018-05-31 Thread Jeffrey Zhang
+1 On Fri, Jun 1, 2018 at 1:41 AM Mark Giles wrote: > > +1 > > On May 31, 2018 at 1:06:43 PM, Borne Mace (borne.m...@oracle.com) wrote: > > Greetings all, > > I would like to propose the addition of Steve Noyes to the kolla-cli > core reviewer team. Consider this nomination as my personal +1. > >

Re: [openstack-dev] [Cyborg] [Nova] Cyborg traits

2018-05-31 Thread Alex Xu
I can help on it. 2018-05-31 21:49 GMT+08:00 Eric Fried : > Yup. I'm sure reviewers will bikeshed the names, but the review is the > appropriate place for that to happen. > > A couple of test changes will also be required. You can have a look at > [1] as an example to follow. > > -efried > >

[openstack-dev] [nova][glance] Deprecation of nova.image.download.modules extension point

2018-05-31 Thread Moore, Curt
Hello. We recently upgraded from Liberty to Pike and looking ahead to the code in Queens, noticed the image download deprecation notice with instructions to post here if this interface was in use. As such, I'd like to explain our use case and see if there is a better way of accomplishing

[openstack-dev] [keystone] failing documentation jobs

2018-05-31 Thread Lance Bragstad
Hi all, If you've been trying to write documentation patches, you may have noticed them tripping over unrelated errors when building the docs. We have a bug opened detailing why this happened [0] and a fix working its way through the gate [1]. The docs job should be back up and running soon. [0]

Re: [openstack-dev] Winterscale: a proposal regarding the project infrastructure

2018-05-31 Thread James E. Blair
Joshua Hesketh writes: > So the "winterscale infrastructure council"'s purview is quite limited in > scope to just govern the services provided? > > If so, would you foresee a need to maintain some kind of "Infrastructure > council" as it exists at the moment to be the technical design body?

[openstack-dev] Forum Recap - Stein Release Goals

2018-05-31 Thread Sean McGinnis
Here's my attempt to recap the goal selection discussion we had last week at the Forum. Feel free to correct any misstatements and continue the discussion. For reference, here's the etherpad from the discussion: https://etherpad.openstack.org/p/YVR-S-release-goals Overall Goal Discussion

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

2018-05-31 Thread Jeremy Stanley
On 2018-05-31 16:49:13 -0400 (-0400), John Dennis wrote: > On 05/30/2018 08:23 PM, Jeremy Stanley wrote: > > I think this is orthogonal to the thread. The idea is that we should > > avoid nettling contributors over minor imperfections in their > > submissions (grammatical, spelling or

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

2018-05-31 Thread John Dennis
On 05/30/2018 08:23 PM, Jeremy Stanley wrote: I think this is orthogonal to the thread. The idea is that we should avoid nettling contributors over minor imperfections in their submissions (grammatical, spelling or typographical errors in code comments and documentation, mild inefficiencies in

Re: [openstack-dev] [nova] proposal to postpone nova-network core functionality removal to Stein

2018-05-31 Thread Matt Riedemann
+openstack-operators On 5/31/2018 3:04 PM, Matt Riedemann wrote: On 5/31/2018 1:35 PM, melanie witt wrote: This cycle at the PTG, we had decided to start making some progress toward removing nova-network [1] (thanks to those who have helped!) and so far, we've landed some patches to extract

Re: [openstack-dev] [nova] proposal to postpone nova-network core functionality removal to Stein

2018-05-31 Thread Matt Riedemann
On 5/31/2018 1:35 PM, melanie witt wrote: This cycle at the PTG, we had decided to start making some progress toward removing nova-network [1] (thanks to those who have helped!) and so far, we've landed some patches to extract common network utilities from nova-network core functionality

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Sylvain Bauza
On Thu, May 31, 2018 at 8:26 PM, Eric Fried wrote: > > 1. Make everything perform the pivot on compute node start (which can be > >re-used by a CLI tool for the offline case) > > 2. Make everything default to non-nested inventory at first, and provide > >a way to migrate a compute node

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Sylvain Bauza
On Thu, May 31, 2018 at 7:44 PM, Chris Dent wrote: > On Thu, 31 May 2018, Dan Smith wrote: > > I kinda think we need to either: >> >> 1. Make everything perform the pivot on compute node start (which can be >> re-used by a CLI tool for the offline case) >> > > This sounds effectively like:

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Jay Pipes
On 05/31/2018 01:09 PM, Dan Smith wrote: My feeling is that we should not attempt to "migrate" any allocations or inventories between root or child providers within a compute node, period. While I agree this is the simplest approach, it does put a lot of responsibility on the operators to do

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Sylvain Bauza
On Thu, May 31, 2018 at 7:09 PM, Dan Smith wrote: > > My feeling is that we should not attempt to "migrate" any allocations > > or inventories between root or child providers within a compute node, > > period. > > While I agree this is the simplest approach, it does put a lot of > responsibility

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Sylvain Bauza
On Thu, May 31, 2018 at 5:00 PM, Jay Pipes wrote: > On 05/31/2018 05:10 AM, Sylvain Bauza wrote: > >> After considering the whole approach, discussing with a couple of folks >> over IRC, here is what I feel the best approach for a seamless upgrade : >> - VGPU inventory will be kept on root RP

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Sylvain Bauza
On Thu, May 31, 2018 at 4:34 PM, Jay Pipes wrote: > On 05/29/2018 09:12 AM, Sylvain Bauza wrote: > >> We could keep the old inventory in the root RP for the previous vGPU type >> already supported in Queens and just add other inventories for other vGPU >> types now supported. That looks possibly

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Eric Fried
Chris- >> virt driver isn't supposed to talk to placement directly, or know >> anything about allocations? > > For sake of discussion, how much (if any) easier would it be if we > got rid of this restriction? At this point, having implemented the update_[from_]provider_tree flow as we have, it

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Sylvain Bauza
On Thu, May 31, 2018 at 3:54 PM, Eric Fried wrote: > This seems reasonable, but... > > On 05/31/2018 04:34 AM, Balázs Gibizer wrote: > > > > > > On Thu, May 31, 2018 at 11:10 AM, Sylvain Bauza > wrote: > >>> > >> > >> After considering the whole approach, discussing with a couple of > >> folks

[openstack-dev] [api] notes from api-sig forum meeting on graphql experiment

2018-05-31 Thread Michael McCune
hi everybody, i have added my notes to the etherpad[1] from summit. briefly, we had a great meeting about creating a graphql experiment in openstack and i tried to capture some of the questions and comments that flew back and forth. there seems to be a good consensus that a proof of concept

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Chris Dent
On Thu, 31 May 2018, Eric Fried wrote: But how would this be accomplished, in light of the current "separation of responsibilities" drawn at the virt driver interface, whereby the virt driver isn't supposed to talk to placement directly, or know anything about allocations? Here's a first pass:

[openstack-dev] [nova] proposal to postpone nova-network core functionality removal to Stein

2018-05-31 Thread melanie witt
Hello Operators and Devs, This cycle at the PTG, we had decided to start making some progress toward removing nova-network [1] (thanks to those who have helped!) and so far, we've landed some patches to extract common network utilities from nova-network core functionality into separate

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

2018-05-31 Thread Julia Kreger
Back to the topic of nitpicking! I virtually sat down with Doug today and we hammered out the positive aspects that we feel like are the things that we as a community want to see as part of reviews coming out of this effort. The principles change[1] in governance has been updated as a result. I

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Eric Fried
Rats, typo correction below. On 05/31/2018 01:26 PM, Eric Fried wrote: >> 1. Make everything perform the pivot on compute node start (which can be >>re-used by a CLI tool for the offline case) >> 2. Make everything default to non-nested inventory at first, and provide >>a way to migrate a

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Eric Fried
> 1. Make everything perform the pivot on compute node start (which can be >re-used by a CLI tool for the offline case) > 2. Make everything default to non-nested inventory at first, and provide >a way to migrate a compute node and its instances one at a time (in >place) to roll

Re: [openstack-dev] [tc] Organizational diversity tag

2018-05-31 Thread Chris Dent
On Tue, 29 May 2018, Samuel Cassiba wrote: The moniker of 'low-activity' does give the very real, negative perception that things are just barely hanging on. It conveys the subconscious, officiated statement (!!!whether or not this was intended!!!) that nobody in their right mind should

[openstack-dev] OpenLab Cross-community Impact

2018-05-31 Thread Melvin Hillsman
Hi everyone, I know we have sent out quite a bit of information over the past few days with the OpenStack Summit and other updates recently. Additionally there are plenty of meetings we all attend. I just want to take time to point to something very significant in my opinion and again give big

Re: [openstack-dev] Ceph multiattach support

2018-05-31 Thread Tom Barron
On 31/05/18 10:00 +0800, fengyd wrote: Hi, I'm using Ceph for cinder backend. Do you have any plan to support multiattach for Ceph backend? Thanks Yafeng Yafeng, Would you describe your use case for cinder multi-attach with ceph backend? I'd like to understand better whether manila

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Chris Dent
On Thu, 31 May 2018, Dan Smith wrote: I kinda think we need to either: 1. Make everything perform the pivot on compute node start (which can be re-used by a CLI tool for the offline case) This sounds effectively like: validate my inventory and allocations at compute node start, correcting

Re: [openstack-dev] [kolla][vote] Nominating Steve Noyes for kolla-cli core reviewer

2018-05-31 Thread Mark Giles
+1 On May 31, 2018 at 1:06:43 PM, Borne Mace (borne.m...@oracle.com) wrote: Greetings all, I would like to propose the addition of Steve Noyes to the kolla-cli core reviewer team. Consider this nomination as my personal +1. Steve has a long history with the kolla-cli and should be considered

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Dan Smith
> My feeling is that we should not attempt to "migrate" any allocations > or inventories between root or child providers within a compute node, > period. While I agree this is the simplest approach, it does put a lot of responsibility on the operators to do work to sidestep this issue, which

[openstack-dev] [kolla][vote] Nominating Steve Noyes for kolla-cli core reviewer

2018-05-31 Thread Borne Mace
Greetings all, I would like to propose the addition of Steve Noyes to the kolla-cli core reviewer team. Consider this nomination as my personal +1. Steve has a long history with the kolla-cli and should be considered its co-creator as probably half or more of the existing code was due to

[openstack-dev] [tc][all] CD tangent - was: A culture change (nitpicking)

2018-05-31 Thread Sean McGinnis
On 05/31/2018 03:50 AM, Thierry Carrez wrote: Right... There might be a reasonable middle ground between "every commit on master must be backward-compatible" and "rip out all testing" that allows us to routinely revert broken feature commits (as long as they don't cross a release boundary).

Re: [openstack-dev] Help required to install devstack with GBP

2018-05-31 Thread Sumit Naiksatam
Hi, Sure we can help you. Could you please take a look at the neutron logs and let me know what exception you are seeing? Also, please let me know which branch you are trying to install. Thanks, ~Sumit. On Thu, May 31, 2018 at 1:52 AM, ., Alex Dominic Savio < alex.will...@microfocus.com> wrote:

Re: [openstack-dev] [tripleo][puppet] Hello all, puppet modules

2018-05-31 Thread Tim Bell
CERN use these puppet modules too and contributes any missing functionality we need upstream. Tim From: Alex Schultz Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Thursday, 31 May 2018 at 16:24 To: "OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Jay Pipes
On 05/31/2018 05:10 AM, Sylvain Bauza wrote: After considering the whole approach, discussing with a couple of folks over IRC, here is what I feel the best approach for a seamless upgrade :  - VGPU inventory will be kept on root RP (for the first type) in Queens so that a compute service

[openstack-dev] [release] Release countdown for week R-12, June 4-8

2018-05-31 Thread Sean McGinnis
Welcome back to our weekly countdown email. Development Focus - The Rocky-2 milestone deadline is June 7th. Teams should be focused on implementing priority features. General Information --- Membership freeze coincides with milestone 2 [0]. This means projects

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Jay Pipes
On 05/30/2018 07:06 AM, Balázs Gibizer wrote: The nova-manage is another possible way similar to my idea #c) but there I imagined the logic in placement-manage instead of nova-manage. Please note there is no placement-manage CLI tool. Best, -jay

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Jay Pipes
On 05/29/2018 09:12 AM, Sylvain Bauza wrote: We could keep the old inventory in the root RP for the previous vGPU type already supported in Queens and just add other inventories for other vGPU types now supported. That looks possibly the simpliest option as the virt driver knows that. What

Re: [openstack-dev] Questions about token scopes

2018-05-31 Thread Lance Bragstad
On 05/31/2018 12:09 AM, Ghanshyam Mann wrote: > On Wed, May 30, 2018 at 11:53 PM, Lance Bragstad wrote: >> >> On 05/30/2018 08:47 AM, Matt Riedemann wrote: >>> I know the keystone team has been doing a lot of work on scoped tokens >>> and Lance has been trying to roll that out to other projects

Re: [openstack-dev] [tripleo][puppet] Hello all, puppet modules

2018-05-31 Thread Alex Schultz
On Wed, May 30, 2018 at 3:18 PM, Remo Mattei wrote: > Hello all, > I have talked to several people about this and I would love to get this > finalized once and for all. I have checked the OpenStack puppet modules > which are mostly developed by the Red Hat team, as of right now, TripleO is >

Re: [openstack-dev] Questions about token scopes

2018-05-31 Thread Lance Bragstad
On 05/30/2018 03:37 PM, Matt Riedemann wrote: > On 5/30/2018 9:53 AM, Lance Bragstad wrote: >> While scope isn't explicitly denoted by an >> attribute, it can be derived from the attributes of the token response. >> > > Yeah, this was confusing to me, which is why I reported it as a bug in > the

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Naichuan Sun
I can do it on xenserver side, although keep old inv in compute node rp looks weird to me(it just work for one case: upgrade)... -Original Message- From: Eric Fried [mailto:openst...@fried.cc] Sent: Thursday, May 31, 2018 9:54 PM To: OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Eric Fried
This seems reasonable, but... On 05/31/2018 04:34 AM, Balázs Gibizer wrote: > > > On Thu, May 31, 2018 at 11:10 AM, Sylvain Bauza wrote: >>> >> >> After considering the whole approach, discussing with a couple of >> folks over IRC, here is what I feel the best approach for a seamless >>

Re: [openstack-dev] [Cyborg] [Nova] Cyborg traits

2018-05-31 Thread Eric Fried
Yup. I'm sure reviewers will bikeshed the names, but the review is the appropriate place for that to happen. A couple of test changes will also be required. You can have a look at [1] as an example to follow. -efried [1] https://review.openstack.org/#/c/511180/ On 05/31/2018 01:02 AM,

Re: [openstack-dev] [tc][forum] TC Retrospective for Queens/Rocky

2018-05-31 Thread Doug Hellmann
Excerpts from Thierry Carrez's message of 2018-05-31 10:31:12 +0200: > Doug Hellmann wrote: > > [...] > > I'm missing details and/or whole topics. Please review the list and > > make any updates you think are necessary. > > One thing that was raised at the Board+TC+UC meeting is the idea of >

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

2018-05-31 Thread Jeremy Stanley
On 2018-05-31 10:33:51 +0200 (+0200), Thierry Carrez wrote: > Ade Lee wrote: > > [...] > > So it seems that the two blockers above have been resolved. So is it > > time to ad a castellan compatible secret store to the base services? > > It's definitely time to start a discussion about it, at

[openstack-dev] [sahara] Canceling today's meeting

2018-05-31 Thread Telles Nobrega
Hi saharans and interested folks, we won't be having meeting today since at least half of our team is on PTO today. We will be back next Thursday. See you all. -- TELLES NOBREGA SOFTWARE ENGINEER Red Hat Brasil Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi,

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Balázs Gibizer
On Thu, May 31, 2018 at 11:10 AM, Sylvain Bauza wrote: After considering the whole approach, discussing with a couple of folks over IRC, here is what I feel the best approach for a seamless upgrade : - VGPU inventory will be kept on root RP (for the first type) in Queens so that a

Re: [openstack-dev] [oslo] Summit onboarding and project update slides

2018-05-31 Thread ChangBo Guo
Thanks Ben 2018-05-31 6:48 GMT+08:00 Ben Nemec : > As promised in the sessions, here are the slides that were presented: > > https://www.slideshare.net/BenNemec1/oslo-vancouver-onboarding > > https://www.slideshare.net/BenNemec1/oslo-vancouver-project-update > > The font in the onboarding one

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-31 Thread Sylvain Bauza
On Wed, May 30, 2018 at 1:06 PM, Balázs Gibizer wrote: > > > On Tue, May 29, 2018 at 3:12 PM, Sylvain Bauza wrote: > >> >> >> On Tue, May 29, 2018 at 2:21 PM, Balázs Gibizer < >> balazs.gibi...@ericsson.com> wrote: >> >>> >>> >>> On Tue, May 29, 2018 at 1:47 PM, Sylvain Bauza >>> wrote: >>>

[openstack-dev] Help required to install devstack with GBP

2018-05-31 Thread ., Alex Dominic Savio
Hi Experts, I have been trying to install devstack with gbp as per the instruction given in the GitHub https://github.com/openstack/group-based-policy This I am running on Ubuntu 16.x as well as 14.x but both the attempts were not successful. It fails stating "neutron is not started" Can you

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

2018-05-31 Thread Thierry Carrez
Davanum Srinivas wrote: "master should be always deployable and fully backward compatible and so we cant let anything in anytime that could possibly regress anyone" Should we change that attitude too? Anyone agree? disagree? Thanks, Dims I'll definitely jump at this one. I've always thought

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

2018-05-31 Thread Thierry Carrez
Ade Lee wrote: [...] So it seems that the two blockers above have been resolved. So is it time to ad a castellan compatible secret store to the base services? It's definitely time to start a discussion about it, at least :) Would you be interested in starting a ML thread about it ? If not,

Re: [openstack-dev] [tc][forum] TC Retrospective for Queens/Rocky

2018-05-31 Thread Thierry Carrez
Doug Hellmann wrote: [...] I'm missing details and/or whole topics. Please review the list and make any updates you think are necessary. One thing that was raised at the Board+TC+UC meeting is the idea of creating a group to help with wording and communication of "help most needed" list

Re: [openstack-dev] Questions about token scopes

2018-05-31 Thread Ghanshyam Mann
On Thu, May 31, 2018 at 2:09 PM, Ghanshyam Mann wrote: > On Wed, May 30, 2018 at 11:53 PM, Lance Bragstad wrote: >> >> >> On 05/30/2018 08:47 AM, Matt Riedemann wrote: >>> I know the keystone team has been doing a lot of work on scoped tokens >>> and Lance has been trying to roll that out to

Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

2018-05-31 Thread Flint WALRUS
Hi Gilles, Ed, I’m really glad and thrilled to read such good news! At this point it’s cool to see that many initiatives have the same convergent needs regarding GraphQL as it will give us a good traction from the beginning if our PoC manage to sufficiently convince our peers. Let me know as

Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

2018-05-31 Thread Gilles Dubreuil
On 31/05/18 13:08, Ed Leafe wrote: On May 6, 2018, at 8:01 AM, Gilles Dubreuil wrote: Regarding the choice of Neutron as PoC, I'm sorry for not providing much details when I said "because of its specific data model", effectively the original mention was "its API exposes things at an

Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

2018-05-31 Thread Gilles Dubreuil
Hi Flint, I wish it was "my" summit ;) In the latter case I'd make the sessions an hour and not 20 or 40 minutes, well at least for the Forum part. And I will also make only one summit a year instead of two (which is also a feed back I got from the Market place). I've passed that during the

Re: [openstack-dev] [tap-as-a-service] core reviewer update

2018-05-31 Thread Soichi Shigeta
+1 Soichi On 2018/05/31 14:36, Takashi Yamamoto wrote: hi, i plan to add Kazuhiro Suzuki to tap-as-a-service-core group. [1] he is one of active members of the project. he is also the original author of tap-as-a-service-dashboard. i'll make the change after a week unless i hear any

Re: [openstack-dev] [stable][kolla] tagging newton EOL

2018-05-31 Thread Jeffrey Zhang
have no idea about this too. and it looks as expected. Thanks tony On Thu, May 31, 2018 at 8:17 AM Tony Breeds wrote: > > On Sat, Apr 14, 2018 at 11:02:54AM +0800, Jeffrey Zhang wrote: > > hi stable team, > > > > Kolla project is ready for Newton EOL. Since kolla-ansible is split from > > kolla

Re: [openstack-dev] [Cyborg] [Nova] Cyborg traits

2018-05-31 Thread Nadathur, Sundar
On 5/30/2018 1:18 PM, Eric Fried wrote: This all sounds fully reasonable to me. One thing, though... * There is a resource class per device category e.g. CUSTOM_ACCELERATOR_GPU, CUSTOM_ACCELERATOR_FPGA. Let's propose standard resource classes for these ASAP.