Re: [openstack-dev] [Tacker] Proposing changes in Tacker Core Team

+1 *Trinh Nguyen *| Founder & Chief Architect *E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz * On Wed, Aug 22, 2018 at 2:21 PM 龚永生 wrote: > +1 > > > > > -- > *龚永生* > *九州云信息科技有限公司 99CLOUD Co. Ltd.* > 邮箱（Email）：gong.yongsh...@99cloud.net >

Re: [openstack-dev] [Tacker] Proposing changes in Tacker Core Team

+1 -- Hiroyuki JO Email: jo.hiroy...@lab.ntt.co.jp, TEL(direct) : +81-422-59-7394 NTT Network Service Systems Laboratories From: Dharmendra Kushwaha [mailto:dharmendra.kushw...@india.nec.com] Sent: Wednesday, August 22, 2018 1:21 PM To: openstack-dev Subject: [openstack-dev] [Tacker]

[openstack-dev] [qa][patrole][neutron][policy] Neutron Policy Testing in OpenStack Patrole project

Hi All, This thread is to request the neutron team on review help for neutron policy testing in Patrole project. Folks who are not familiar with Patrole, below is the brief background & description of Patrole: - OpenStack Patrole is official project under QA umbrella

[openstack-dev] [neutron] Old patches cleaning

Hi, In Neutron we have many patches without any activity since long time. To make list of patches a bit smaller I want to run script [1] soon. I will run it only for projects like: * neutron * neutron-lib * neutron-tempest-plugin But if You want to run it for Your stadium project it should be

[openstack-dev] Redis licensing terms changes

Hi, I haven't seen this but I'd like to point that Redis moved to an open core licensing model. https://redislabs.com/community/commons-clause/ In short: * base engine remains under BSD license * modules move to ASL 2.0 + commons clause which is non-free (prohibits sales of derived products)

Re: [openstack-dev] [Tacker] Proposing changes in Tacker Core Team

+1 from me. First of all, I would like to thank Phuoc for his contribution in Tacker. As I know, Phuoc joined in Tacker project for a year, but his contribution in Tacker is highly appreciated. Besides, he also is one of active member in IRC, gerrit and bug report. Hope that he can help Tacker

Re: [openstack-dev] Redis licensing terms changes

Haïkel wrote: I haven't seen this but I'd like to point that Redis moved to an open core licensing model. https://redislabs.com/community/commons-clause/ In short: * base engine remains under BSD license * modules move to ASL 2.0 + commons clause which is non-free (prohibits sales of derived

[openstack-dev] [Searchlight] Action plan for Searchlight in Stein

Dear team, Here is my proposed action plan for Searchlight in Stein. The ultimate goal is to revive Searchlight with a sustainable number of contributors and can release as expected. 1. Migrate Searchlight to Storyboard with the help of Kendall 2. Attract more contributors (as well as cores) 3.

Re: [openstack-dev] [goal][python3] week 2 update

Hi, The other projects please consider merging the OpenStack Release Bot patches related to Rocky branch. So that we can propose the patches related to python3-first goal. On Tue, Aug 21, 2018 at 8:40 PM Telles Nobrega wrote: > Thanks. We merged most of them, there is only one that failed the

Re: [openstack-dev] [TripleO]Addressing Edge/Multi-site/Multi-cloud deployment use cases (new squad)

Hi, This is good news. We could even have an hour session to discuss ideas about TripleO-s place in the edge cloud infrastructure. Would you be open for that? Br, Gerg0 -Original Message- From: James Slagle Sent: Tuesday, August 21, 2018 2:42 PM To: OpenStack Development Mailing

Re: [openstack-dev] [keystone] Keystone Team Update - Week of 6 August 2018

Bah! I saw this while on holiday and didn't get a chance to respond, sorry for being late to the conversation. On 11/08/18 3:46 AM, Colleen Murphy wrote: > ### Self-Service Keystone > > At the weekly meeting Adam suggested we make self-service keystone a focus > point of the PTG[9]. Currently,

Re: [openstack-dev] [Searchlight] Action plan for Searchlight in Stein

It is done! I could only find two lp projects- searchlight and python-searchlight-client. If I missed any let me know and I can run the script on them. Otherwise you can view the results here[1]. Play around with it for a couple days and if it works for you we can migrate you whenever. We usually

[openstack-dev] octavia-dashboard 2.0.0.0rc3 (rocky)

Hello everyone, A new release candidate for octavia-dashboard for the end of the Rocky cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/octavia-dashboard/ Unless release-critical issues are found that warrant a release candidate respin, this

Re: [openstack-dev] [glance][horizon] Issues we found when using Community Images

On 08/22/2018 04:31 PM, Andy Botting wrote: Hi all, We've recently moved to using Glance's community visibility on the Nectar Research Cloud. We had lots of public images (12255), and we found it was becoming slow to list them all and the community image visibility seems to fit our use-case

Re: [openstack-dev] [Searchlight] Action plan for Searchlight in Stein

Hi Kendall, Thanks much for the help. :) Bests, *Trinh Nguyen *| Founder & Chief Architect *E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz * On Thu, Aug 23, 2018 at 7:21 AM Kendall Nelson wrote: > It is done! I could only find two lp

Re: [openstack-dev] [Freezer] Reactivate the team

Hi Kendall, I hope gengchc2 will have a decision on this since he is the new PTL of Freezer for Stein. Bests, *Trinh Nguyen *| Founder & Chief Architect *E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz * On Thu, Aug 23, 2018 at 8:26 AM Kendall

Re: [openstack-dev] [nova][cinder][neutron] Cross-cell cold migration

I think in our case we’d only migrate between cells if we know the network and storage is accessible and would never do it if not. Thinking moving from old to new hardware at a cell level. If storage and network isn’t available ideally it would fail at the api request. There is also ceph

[openstack-dev] [monasca][goal][python3] monasca's zuul migration is only partially complete

Monasca team, It looks like you have self-proposed some, but not all, of the patches to import the zuul settings into monasca repositories. I found these:

Re: [openstack-dev] [oslo] UUID sentinel needs a home

On Wed, Aug 22, 2018, 10:13 AM Eric Fried wrote: > For some time, nova has been using uuidsentinel [1] which conveniently > allows you to get a random UUID in a single LOC with a readable name > that's the same every time you reference it within that process (but not > across processes). Example

[openstack-dev] [nova][cinder][neutron] Cross-cell cold migration

Hi everyone, I have started an etherpad for cells topics at the Stein PTG [1]. The main issue in there right now is dealing with cross-cell cold migration in nova. At a high level, I am going off these requirements: * Cells can shard across flavors (and hardware type) so operators would

Re: [openstack-dev] [barbican][oslo][release][requirements] FFE request for castellan

Thanks guys, Sorry - it was not clear to me if I was supposed to do anything further. It seems like the requirements team has approved the FFE and the release has merged. Is there anything further I need to do? Thanks, Ade On Tue, 2018-08-21 at 14:16 -0500, Matthew Thode wrote: > On 18-08-21

Re: [openstack-dev] [goal][python3] week 2 update

Excerpts from William M Edmonds's message of 2018-08-22 07:42:43 -0400: > > Doug Hellmann wrote on 08/20/2018 11:27:09 AM: > > If your team is ready to have your zuul settings migrated, please > > let us know by following up to this email. We will start with the > > volunteers, and then work our

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

Excerpts from melanie witt's message of 2018-08-21 15:05:00 -0700: > On Tue, 21 Aug 2018 16:41:11 -0400, Doug Hellmann wrote: > > Excerpts from melanie witt's message of 2018-08-21 12:53:43 -0700: > >> On Tue, 21 Aug 2018 06:50:56 -0500, Matt Riedemann wrote: > >>> At this point, I think we're at:

[openstack-dev] [oslo] UUID sentinel needs a home

For some time, nova has been using uuidsentinel [1] which conveniently allows you to get a random UUID in a single LOC with a readable name that's the same every time you reference it within that process (but not across processes). Example usage: [2]. We would like other projects (notably the

Re: [openstack-dev] [kolla][project navigator] kolla missing in project navigator

Thierry, Kolla likely belongs in the packaging recipes in the map. Kolla-Ansible belongs in the lifecycle tools. FWIW, I'm agree with Jean on the location of OpenStack-Ansible in the map. This is a deployment tool, not really a set of recipes. I think the name "openstack-ansible" as a

Re: [openstack-dev] [goal][python3] week 2 update

Doug Hellmann wrote on 08/20/2018 11:27:09 AM: > If your team is ready to have your zuul settings migrated, please > let us know by following up to this email. We will start with the > volunteers, and then work our way through the other teams. I think PowerVMStackers is ready (so nova-powervm,

Re: [openstack-dev] [keystone] Keystone Team Update - Week of 6 August 2018

On 08/22/2018 03:23 AM, Adrian Turjak wrote: > Bah! I saw this while on holiday and didn't get a chance to respond, > sorry for being late to the conversation. > > On 11/08/18 3:46 AM, Colleen Murphy wrote: >> ### Self-Service Keystone >> >> At the weekly meeting Adam suggested we make

Re: [openstack-dev] [TripleO]Addressing Edge/Multi-site/Multi-cloud deployment use cases (new squad)

Hi, thanks for a write up James. I am adding a few notes/ideas inline... On Mon, Aug 20, 2018 at 10:48 PM James Slagle wrote: > As we start looking at how TripleO will address next generation deployment > needs such as Edge, multi-site, and multi-cloud, I'd like to kick off a > discussion

Re: [openstack-dev] [nova][cinder] Disabling nova volume-update (aka swap volume; aka cinder live migration)

> > The solution is conceptually simple. We add a new API microversion in > Cinder that adds and optional parameter called "generic_keep_source" > (defaults to False) to both migrate and retype operations. > > This means that if the driver optimized migration cannot do the > migration and the

[openstack-dev] cinder 13.0.0.0rc2 (rocky)

Hello everyone, A new release candidate for cinder for the end of the Rocky cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/cinder/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally

Re: [openstack-dev] [nova] how nova should behave when placement returns consumer generation conflict

On Fri, Aug 17, 2018 at 5:40 PM, Eric Fried wrote: gibi- - On migration, when we transfer the allocations in either direction, a conflict means someone managed to resize (or otherwise change allocations?) since the last time we pulled data. Given the global lock in the report client,

[openstack-dev] horizon 14.0.0.0rc2 (rocky)

Hello everyone, A new release candidate for horizon for the end of the Rocky cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/horizon/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be

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

Hi John, So sorry to hear this but totally understandable! Thanks for letting us know and for everything you've done! Enjoy life without ironic :) --ruby On Tue, Aug 21, 2018 at 10:39 AM John Villalovos wrote: > Good morning Ironic, > > I have come to realize that I don't have the time needed

Re: [openstack-dev] [nova] how nova should behave when placement returns consumer generation conflict

b) sounds the most sane in both cases. I don't like the idea of "your move operation failed and you have no recourse but to delete your instance". And automatic retry sounds lovely, but potentially hairy to implement (and we would need to account for the retries-failed scenario anyway) so at least

[openstack-dev] heat 11.0.0.0rc2 (rocky)

Hello everyone, A new release candidate for heat for the end of the Rocky cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/heat/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally

[openstack-dev] [neutron][ovs] OVS drop issue

Hi We are seeing a very weird issue with OVS 2.9 which is not seen in OVS 2.6. Basically the end symptom is from the neutron L3 agent router namespace we cant ping the gateway in this case 10.86.67.1 Now on performing tcpdump tests we see the gateway responding to ARP the reply comes into the

Re: [openstack-dev] [kayobe] Kayobe update

On Wed, 22 Aug 2018, 19:08 Erik McCormick, wrote: > > > On Wed, Aug 22, 2018, 1:52 PM Mark Goddard wrote: > >> Hello Kayobians, >> >> I thought it is about time to do another update. >> > > > > >> # PTG >> >> There won't be an official Kayobe session at the PTG in Denver, although >> I and a

[openstack-dev] octavia 3.0.0.0rc3 (rocky)

Hello everyone, A new release candidate for octavia for the end of the Rocky cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/octavia/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be

[openstack-dev] [glance][horizon] Issues we found when using Community Images

Hi all, We've recently moved to using Glance's community visibility on the Nectar Research Cloud. We had lots of public images (12255), and we found it was becoming slow to list them all and the community image visibility seems to fit our use-case nicely. We moved all of our user's images over

Re: [openstack-dev] [Freezer] Reactivate the team

I finished the test migration. You can find the results here[1]. I only found two lp projects- freezer and freezer-web-ui. If I missed any, please let me know and I will run the migration script on them. Play around with it for a few days and let me know if you are interested in moving forward

Re: [openstack-dev] [Searchlight] Action plan for Searchlight in Stein

Trinh Nguyen wrote: Here is my proposed action plan for Searchlight in Stein. The ultimate goal is to revive Searchlight with a sustainable number of contributors and can release as expected. [...] Thanks again for stepping up, and communicating so clearly. -- Thierry Carrez (ttx)

Re: [openstack-dev] [nova][cinder] Disabling nova volume-update (aka swap volume; aka cinder live migration)

On Wed, 22 Aug 2018 at 10:47, Gorka Eguileor wrote: > > On 20/08, Matthew Booth wrote: > > For those who aren't familiar with it, nova's volume-update (also > > called swap volume by nova devs) is the nova part of the > > implementation of cinder's live migration (also called retype). > >

Re: [openstack-dev] [nova][cinder] Disabling nova volume-update (aka swap volume; aka cinder live migration)

On 20/08, Matthew Booth wrote: > For those who aren't familiar with it, nova's volume-update (also > called swap volume by nova devs) is the nova part of the > implementation of cinder's live migration (also called retype). > Volume-update is essentially an internal cinder<->nova api, but as >

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On Sat, Aug 18, 2018 at 2:25 PM, Chris Dent wrote: So my hope is that (in no particular order) Jay Pipes, Eric Fried, Takashi Natsume, Tetsuro Nakamura, Matt Riedemann, Andrey Volkov, Alex Xu, Balazs Gibizer, Ed Leafe, and any other contributor to placement whom I'm forgetting [1] would

Re: [openstack-dev] [Searchlight] Action plan for Searchlight in Stein

Hi, The link for Stein's Etherpad is missing. On Wed, Aug 22, 2018 at 5:58 PM Trinh Nguyen wrote: > Dear team, > > Here is my proposed action plan for Searchlight in Stein. The ultimate > goal is to revive Searchlight with a sustainable number of contributors and > can release as expected. > >

Re: [openstack-dev] Redis licensing terms changes

Hmm... http://antirez.com/news/120 Today a page about the new Creative Common license in the Redis Labs web site was interpreted as if Redis itself switched license. This is not the case, Redis is, and will remain, BSD licensed. However in the fake news era my attempts to provide the correct

[openstack-dev] [tempest][qa][congress] trouble setting tempest feature flag

Hi all, I have added feature flags for the congress tempest plugin [1] and set them in the devstack plugin [2], but the flags seem to be ignored. The tests are skipped [3] according to the default False flag rather than run according to the True flag set in devstack plugin. Any hints on what may

Re: [openstack-dev] [Searchlight] Action plan for Searchlight in Stein

Oops, here you go: https://etherpad.openstack.org/p/searchlight-stein-ptg *Trinh Nguyen *| Founder & Chief Architect *E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz * On Wed, Aug 22, 2018 at 11:46 PM Nguyễn Trí Hải wrote: > Hi, > > The link

Re: [openstack-dev] [neutron] Old patches cleaning

On 8/22/18 2:10 AM, Slawomir Kaplonski wrote:> I will run it only for projects like: > * neutron-lib > > If You have any concerns about running this script, please raise Your hand > now :) Thanks for this. Personally I don't see a need to cleanup old reviews for neutron-lib; it's a pretty

[openstack-dev] [kayobe] Kayobe update

Hello Kayobians, I thought it is about time to do another update. # Releases Work continues on master adding Kayobe features. We're still deploying the Queens release of OpenStack, although the Rocky patch [1] gets refreshed every so often to ensure we're not lagging behind. I've been

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On Wed, 22 Aug 2018 09:49:13 -0400, Doug Hellmann wrote: Excerpts from melanie witt's message of 2018-08-21 15:05:00 -0700: On Tue, 21 Aug 2018 16:41:11 -0400, Doug Hellmann wrote: Excerpts from melanie witt's message of 2018-08-21 12:53:43 -0700: On Tue, 21 Aug 2018 06:50:56 -0500, Matt

Re: [openstack-dev] [kayobe] Kayobe update

On Wed, Aug 22, 2018, 1:52 PM Mark Goddard wrote: > Hello Kayobians, > > I thought it is about time to do another update. > > # PTG > > There won't be an official Kayobe session at the PTG in Denver, although I > and a few others from the team will be present. If anyone would like to > meet

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On 2018-08-22 11:03:43 -0700 (-0700), melanie witt wrote: [...] > I think it's about context. If two separate projects do their own priority > and goal setting, separately, I think they will naturally be more different > than they would be if they were one project. Currently, we agree on goals >

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On 2018-08-22 00:17:41 + (+), Fox, Kevin M wrote: > There have been plenty of cross project goals set forth from the > TC and implemented by the various projects such as wsgi or > python3. Those have been worked on by each of the projects in > priority to some project specific goals by

[openstack-dev] [sahara] Anti-affinity Broke

Hi all, We have an open bug on storyboard regarding anti-affinity on sahara. https://storyboard.openstack.org/#!/story/2002656 This was proposed by Joe Topjian and I have implemented the proposed fix. Unfortunetely we don't have resources to test it properly. Joe, if you can take a look and

Re: [openstack-dev] [oslo] UUID sentinel needs a home

Excerpts from Eric Fried's message of 2018-08-22 09:13:25 -0500: > For some time, nova has been using uuidsentinel [1] which conveniently > allows you to get a random UUID in a single LOC with a readable name > that's the same every time you reference it within that process (but not > across

Re: [openstack-dev] [Searchlight] Action plan for Searchlight in Stein

Hello Trinh, On Wed, Aug 22, 2018 at 1:57 AM Trinh Nguyen wrote: > Dear team, > > Here is my proposed action plan for Searchlight in Stein. The ultimate > goal is to revive Searchlight with a sustainable number of contributors and > can release as expected. > > 1. Migrate Searchlight to