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

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] Struggling to get the s3 api interface to work with swift.

Hi Shyam, You should specify the path starts from bucket. It will be like http://20.20.20.229:8080/testBucket assuming you didn't configure virtual-hosted style. Even if your *Swift* endpoint is http://20.20.20.229:8080/v1/AUTH_dc86f7d8787b46158268bd77098b6578, swift3 doesn't require the

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

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

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

+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

+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

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

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

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-operators] attaching network cards to VMs taking a very long time

On 5/30/2018 9:30 AM, Matt Riedemann wrote: I can start pushing some docs patches and report back here for review help. Here are the docs patches in both nova and neutron: https://review.openstack.org/#/q/topic:bug/1774217+(status:open+OR+status:merged) -- Thanks, Matt

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

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

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)

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)

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-operators] [openstack-dev] [nova] proposal to postpone nova-network core functionality removal to Stein

+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

+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

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

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

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

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

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

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

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

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

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

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

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-operators] [nova] proposal to postpone nova-network core functionality removal to Stein

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

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

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)

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

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

> 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

[OpenStack-Infra] Updating gerrit jenkins-job-builder-release group members

Hi Can someone help updating the jenkins-job-builder-release group on gerrit to add two persons to it? Apparently there is no way to raise a CR to update group membership, or if it is I am unaware about it. https://review.openstack.org/#/admin/groups/321,members

Re: [OpenStack-Infra] How to take over a project? (tap-as-a-service)

Hi, Sure. I’ll give it a try and get back to you guys. Regards, Anil Sent from my iPhone > On May 31, 2018, at 1:07 AM, Thierry Carrez wrote: > > Delivered-To: arao...@gmail.com > Received: by 2002:a19:e21a:0:0:0:0:0 with SMTP id z26-v6csp5901938lfg; Thu, 31 > May 2018 01:07:30 -0700 (PDT) >

Re: [OpenStack-Infra] Updating gerrit jenkins-job-builder-release group members

On 23 May 2018 at 03:17, Sorin Ionuț Sbârnea wrote: > Hi > > Can someone help updating the *jenkins-job-builder-release* group on > gerrit to add two persons to it? Apparently there is no way to raise a CR > to update group membership, or if it is I am unaware about it. >

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

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-operators] OpenLab Cross-community Impact

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

[openstack-dev] OpenLab Cross-community Impact

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

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

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

+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

> 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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [Openstack] Struggling to get the s3 api interface to work with swift.

Hi Yuxin, Thank you for sharing your configs. So I've managed to get past the Signature not matching error. Now the error is different. InvalidbucketName: eightkpc@objectstore1:~/s3curl$ ./s3curl.pl --debug --id=testerks --createBucket --

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

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

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

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

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

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)

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

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

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-Infra] How to take over a project? (tap-as-a-service)

Takashi Yamamoto wrote: i want to take over tap-as-a-service project. originally the project had two leaders. but one of them (vinay) has not been responding these days. another (anil) recently told us he might not work on it anymore. this email has cc: to them. i think gerrit is ok as i'm

Re: [openstack-dev] Questions about token scopes

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

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

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

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

+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-operators] Problems with AggregateMultiTenancyIsolation while migrating an instance

Thanks a lot !! On Wed, May 30, 2018 at 8:06 PM, Matt Riedemann wrote: > On 5/30/2018 9:41 AM, Matt Riedemann wrote: > >> Thanks for your patience in debugging this Massimo! I'll get a bug >> reported and patch posted to fix it. >> > > I'm tracking the problem with this bug: > >

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

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

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.