Re: [openstack-dev] [Openstack-dev] [Designate]

On Thu, May 25, 2017 at 5:27 PM Carmine Annunziata < carmine.annunziat...@gmail.com> wrote: > Hi everyone, > I integrated Designate in Openstack by devstack, now i'm using the new > default commands like zone create/delete, etc. I got this problem: > > >

[openstack-dev] [publiccloud-wg] Summary meeting 24th May

Hi group, Wednesday we had a meeting with the Public Cloud Working Group, in this email I will give you a quick summary of that meeting, to keep everyone informed and hopefully keep up the interest that we all felt in Boston! =) #start meeting-summary publiccloud-wg 1. Upstream work A lot

Re: [openstack-dev] [glance] priorities for the coming week (05/26-06/01)

One new patch added for the Glanceclient release: https://review.openstack.org/#/c/467592/ On Thu, May 25, 2017 at 12:23 PM, Brian Rosmaita wrote: > As discussed at today's Glance meeting, here are the priorities for this week: > > 0 Glanceclient release > We plan to

[openstack-dev] [telemetry] gnocchi v4 preview

hi, since i've been referencing this to a few people already, i've done some basic benchmarking on the upcoming gnocchi release which should be released in next few weeks. here is a short deck highlighting a few updates: https://www.slideshare.net/GordonChung/gnocchi-v4-preview if you have

[openstack-dev] [nova] placement/resource providers update 24

Once more with a placement and resource providers update. This is number 24. # What Matters Most Claims against the placement API remain the highest priorty. There's plenty of other work in progress too which needs to advance. Lots of links within. # What's Changed This week there were a few

[openstack-dev] [neutron][L3][HA] 2 masters after reboot of node

This is regarding https://bugs.launchpad.net/neutron/+bug/1597461 Earlier to fix this, we added code [1] to spawn keepalived only when HA network port status is active. But, on reboot, node will get HA network port's status as ACTIVE from server(please see comment [2]), though l2 agent might not

Re: [openstack-dev] [fuxi][kuryr] Where to commit codes for Fuxi-golang

On Thu, May 25, 2017 at 10:01 PM, zengchen wrote: > > Hi john: > I have seen your updates on the bp. I agree with your plan on how to > develop the codes. > However, there is one issue I have to remind you that at present, Fuxi > not only can convert > Cinder volume

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

On 05/26/2017 02:53 AM, Chris Friesen wrote: On 05/19/2017 04:06 PM, Dean Troyer wrote: On Fri, May 19, 2017 at 4:01 PM, Matt Riedemann wrote: I'm confused by this. Creating a server takes a volume ID if you're booting from volume, and that's actually preferred (by nova

Re: [openstack-dev] [oslo][oslo.messaging] Call to deprecate the 'pika' driver in the oslo.messaging project

So it's been over a week with no objections. I will start the deprecation process, including an announcement on the operator's email list. Thanks for the feedback. On Mon, May 22, 2017 at 8:06 PM, ChangBo Guo wrote: > +1 , let's focus on key drivers. > > 2017-05-17 2:02

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

On 25/05/17 18:34, Matt Riedemann wrote: On 5/22/2017 11:01 AM, Zane Bitter wrote: If the user does a stack update that changes the network from 'auto' to 'none', or vice-versa. OK I guess we should make this a side discussion at some point, or hit me up in IRC, but if you're requesting

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On 05/26/2017 10:05 AM, Lance Bragstad wrote: > > > On Fri, May 26, 2017 at 5:32 AM, Sean Dague > wrote: > > On 05/26/2017 03:44 AM, John Garbutt wrote: > > +1 on not forcing Operators to transition to something new twice, even > > if we did

[openstack-dev] [nova] Newton 14.0.7 and Ocata 15.0.5 releases

This is a follow up to an email from Melanie Witt [1] calling attention to a high severity performance regression identified in Newton. That change is merged and the fix will be in the Ocata 15.0.5 release [2] and Newton 14.0.7 release [3]. Those releases will also contain a fix for a bug

Re: [openstack-dev] [neutron][L3][HA] 2 masters after reboot of node

On Fri, May 26, 2017 at 6:14 PM, Kevin Benton wrote: > Perhaps when the L3 agent starts up we can have it explicitly set the port > status to DOWN for all of the HA ports on that node. Then we are guaranteed > that when they go to ACTIVE it will be because the L2 agent has

Re: [openstack-dev] [fuxi][kuryr] Where to commit codes for Fuxi-golang

Ya we should combine all the related efforts :) #openstack-cinder would be great place to chat, shall we set a time for the meeting ? On Fri, May 26, 2017 at 11:40 AM, John Griffith wrote: > > > On Thu, May 25, 2017 at 6:25 PM, Zhipeng Huang >

Re: [openstack-dev] [neutron][L3][HA] 2 masters after reboot of node

Just triggering a status change should just be handled as a port update on the agent side which shouldn't interrupt any existing flows. So an l3 agent reboot should be safe in this case. On May 26, 2017 6:06 AM, "Anil Venkata" wrote: > On Fri, May 26, 2017 at 6:14 PM,

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On Fri, May 26, 2017 at 5:32 AM, Sean Dague wrote: > On 05/26/2017 03:44 AM, John Garbutt wrote: > > +1 on not forcing Operators to transition to something new twice, even > > if we did go for option 3. > > > > Do we have an agreed non-distruptive upgrade path mapped out yet?

Re: [openstack-dev] [release][tc][infra][security][stable] Proposal for shipping binaries and containers

I've been out on vacation but as a circle back to normal (working!) life I've found this thread very interesting. I share the concerns raised about the level of resource required to back this. I don't speak for the VMT but I agree with Jeremy that it should be possible to provide VMT support to

Re: [openstack-dev] [neutron][L3][HA] 2 masters after reboot of node

Perhaps when the L3 agent starts up we can have it explicitly set the port status to DOWN for all of the HA ports on that node. Then we are guaranteed that when they go to ACTIVE it will be because the L2 agent has wired the ports. On Fri, May 26, 2017 at 5:27 AM, Anil Venkata

Re: [openstack-dev] [mistral][freezer] adopting oslo.context for logging debugging and tracing

Hi Doug, Thanks for your review. Actually freezer has a separate repo for the api, it can be found here [1]. Freezer is using oslo.context since newton. If you have the time you can take a look at it and let us know if you have any comments. Thanks for your help [1]

Re: [openstack-dev] [all] [nova] [glance] [neutron] [cinder] Global Request ID progress - python-cinderclient the first across the line!

Major Updates: The Cinder team was really responsive with reviews yesterday and getting out a new python-cinderclient, so cinder is now the first project fully plumbed to accept global_request_id. Woot! On the Nova team we managed to resolve some long standing issues with the way that we consume

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On Fri, May 26, 2017 at 9:31 AM, Sean Dague wrote: > On 05/26/2017 10:05 AM, Lance Bragstad wrote: > > > > > > On Fri, May 26, 2017 at 5:32 AM, Sean Dague > > wrote: > > > > On 05/26/2017 03:44 AM, John Garbutt wrote: > > > +1 on

[openstack-dev] [TripleO] quickstart featureset and reviews

Hi, as discussed during the previous meeting, we are adding a lot of new jobs that need new featurset files recently. It's difficult to scan all the review to find an unused featureset file index, so there have been a lot of conflicts. To avoid this I created an etherpad at

Re: [openstack-dev] [upgrades][skip-level][leapfrog] - RFC - Skipping releases when upgrading

On 05/26/2017 10:56 AM, Dan Smith wrote: As most of the upgrade issues center around database migrations, we discussed some of the potential pitfalls at length. One approach was to roll-up all DB migrations into a single repository and run all upgrades for a given project in one step. Another

Re: [openstack-dev] [tc] Status update, May 26

Fun! it was marked as fixed :) https://bugs.launchpad.net/openstack-org/+bug/1691175 On Fri, May 26, 2017 at 10:51 AM, Sean McGinnis wrote: > On 05/26/2017 03:47 AM, Thierry Carrez wrote: >> >> >> ttx to refresh 2017 contributor attrition stats and report back. >> > > We

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On 05/26/2017 10:44 AM, Lance Bragstad wrote: > Interesting - I guess the way I was thinking about it was on a per-token > basis, since today you can't have a single token represent multiple > scopes. Would it be unreasonable to have oslo.context build this > information based on multiple tokens

[openstack-dev] [keystone] deprecating the policy and credential APIs

At the PTG in Atlanta, we talked about deprecating the policy and credential APIs. The policy API doesn't do anything and secrets shouldn't be stored in credential API. Reasoning and outcomes can be found in the etherpad from the session [0]. There was some progress made on the policy API [1], but

Re: [openstack-dev] [nova][cinder][barbican] Why is Cinder creating symmetric keys in Barbican for use with encrypted volumes?

On 25-05-17 11:00:26, Lee Yarwood wrote: > Hello all, > > I'm currently working on enabling QEMU's native LUKS support within Nova > [1]. While testing this work with Barbican I noticed that Cinder is > creating symmetric keys for use with encrypted volumes : > >

Re: [openstack-dev] [nova][cinder][barbican] Why is Cinder creating symmetric keys in Barbican for use with encrypted volumes?

On 25 May 2017 12:33 pm, "Lee Yarwood" wrote: On 25-05-17 11:38:44, Duncan Thomas wrote: > On 25 May 2017 at 11:00, Lee Yarwood wrote: > > This has also reminded me that the plain (dm-crypt) format really needs > > to be deprecated this cycle. I posted

Re: [openstack-dev] [upgrades][skip-level][leapfrog] - RFC - Skipping releases when upgrading

> I haven't looked at what Keystone is doing, but to the degree they are > using triggers, those triggers would only impact new data operations as > they continue to run into the schema that is straddling between two > versions (e.g. old column/table still exists, data should be synced to > new

[openstack-dev] [nova][scheduler] Anyone relying on the host_subset_size config option?

[resending to include the operators list] The host_subset_size configuration option was added to the scheduler to help eliminate race conditions when two requests for a similar VM would be processed close together, since the scheduler’s algorithm would select the same host in both cases,

[openstack-dev] [panko] dropping hbase driver support

hi, as all of you know, we moved all storage out of ceilometer so it is handles only data generation and normalisation. there seems to be very little contribution to panko which handles metadata indexing, event storage so given how little it's being adopted and how little resources are being

[openstack-dev] [tripleo] CI Squad Meeting Summary (week 21) - Devmode OVB, RDO Cloud and config management

If the topics below interest you and you want to contribute to the discussion, feel free to join the next meeting: Time: Thursdays, 14:30-15:30 UTC Place: https://bluejeans.com/4113567798/ Full minutes: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting = Periodic & Promotion OVB jobs

Re: [openstack-dev] [nova][scheduler] Anyone relying on the host_subset_size config option?

On 05/26/2017 01:14 PM, Edward Leafe wrote: The host_subset_size configuration option was added to the scheduler to help eliminate race conditions when two requests for a similar VM would be processed close together, since the scheduler’s algorithm would select the same host in both cases,

Re: [openstack-dev] [upgrades][skip-level][leapfrog] - RFC - Skipping releases when upgrading

> As most of the upgrade issues center around database migrations, we > discussed some of the potential pitfalls at length. One approach was to > roll-up all DB migrations into a single repository and run all upgrades > for a given project in one step. Another was to simply have mutliple > python

Re: [openstack-dev] [tc] Status update, May 26

On 05/26/2017 10:02 AM, Davanum Srinivas wrote: Fun! it was marked as fixed :) https://bugs.launchpad.net/openstack-org/+bug/1691175 Hmm, maybe just not pushed up yet? __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [tc] Status update, May 26

Thanks Jimmy! On 05/26/2017 10:15 AM, Jimmy McArthur wrote: This was completely my fault. I inadvertently updated it on our dev server, but not production :\ https://www.openstack.org/foundation/tech-committee/ Should be good to go now. My apologies for the delay!! Jimmy Sean McGinnis

Re: [openstack-dev] [tc] Status update, May 26

On 05/26/2017 03:47 AM, Thierry Carrez wrote: ttx to refresh 2017 contributor attrition stats and report back. We also need to refresh this page: https://www.openstack.org/foundation/tech-committee/ I think this came up at one other point, but I don't recall if there was a way to propose a

Re: [openstack-dev] [tc] Status update, May 26

This was completely my fault. I inadvertently updated it on our dev server, but not production :\ https://www.openstack.org/foundation/tech-committee/ Should be good to go now. My apologies for the delay!! Jimmy Sean McGinnis May 26, 2017 at 10:08 AM Hmm,

Re: [openstack-dev] [nova][cinder][barbican] Why is Cinder creating symmetric keys in Barbican for use with encrypted volumes?

On 26-05-17 17:25:15, Duncan Thomas wrote: > On 25 May 2017 12:33 pm, "Lee Yarwood" wrote: > > On 25-05-17 11:38:44, Duncan Thomas wrote: > > On 25 May 2017 at 11:00, Lee Yarwood wrote: > > > This has also reminded me that the plain (dm-crypt) format

[openstack-dev] [nova][scheduler] Anyone relying on the host_subset_size config option?

The host_subset_size configuration option was added to the scheduler to help eliminate race conditions when two requests for a similar VM would be processed close together, since the scheduler’s algorithm would select the same host in both cases, leading to a race and a likely failure to build

Re: [openstack-dev] [neutron][L3][HA] 2 masters after reboot of node

Thanks Kevin, Agree with you. I will try to implement this suggestion. On Fri, May 26, 2017 at 7:01 PM, Kevin Benton wrote: > Just triggering a status change should just be handled as a port update on > the agent side which shouldn't interrupt any existing flows. So an l3

Re: [openstack-dev] [requirements][tripleo][heat] Projects holding back requirements updates

On 05/26/2017 04:22 AM, Steven Hardy wrote: On Thu, May 25, 2017 at 03:15:13PM -0500, Ben Nemec wrote: Tagging with tripleo and heat teams for the os-*-config projects. I'm not sure which owns them now, but it sounds like we need a new release. I think they're still owned by the TripleO

Re: [openstack-dev] [nova][scheduler] Anyone relying on the host_subset_size config option?

On 05/26/2017 12:17 PM, Edward Leafe wrote: [resending to include the operators list] The host_subset_size configuration option was added to the scheduler to help eliminate race conditions when two requests for a similar VM would be processed close together, since the scheduler’s algorithm

[openstack-dev] [TripleO] Passing along some field feedback

Hi, As some of you may know, I have a weekly meeting with some of the Red Hat folks who are out in the field using TripleO to deploy OpenStack at customer sites. The past couple of weeks have been particularly interesting, so I thought I'd take a moment to disseminate the comments to the

Re: [openstack-dev] [TripleO] Passing along some field feedback

On Fri, May 26, 2017 at 3:34 PM, Ben Nemec wrote: > Hi, > > As some of you may know, I have a weekly meeting with some of the Red Hat > folks who are out in the field using TripleO to deploy OpenStack at customer > sites. The past couple of weeks have been particularly

Re: [openstack-dev] [keystone] deprecating the policy and credential APIs

So I've actually been using the credentials API for some of my work towards MFA, different types of MFA, and even different stages for MFA. For example (totp in this case), I first have a service create a user's totp secret as type 'totp-draft' so that the totp auth method can't use it, but so

[openstack-dev] no upgrades meeting on May 29th

It's Memorial day in US. Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[openstack-dev] [nova] cells v1 job is at 100% fail on master

Fix is proposed here: https://review.openstack.org/#/c/468585/ This is just FYI so people aren't needlessly rechecking. -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [mistral][freezer] adopting oslo.context for logging debugging and tracing

Excerpts from Saad Zaher's message of 2017-05-26 12:03:24 +0100: > Hi Doug, > > Thanks for your review. Actually freezer has a separate repo for the api, > it can be found here [1]. Freezer is using oslo.context since newton. If > you have the time you can take a look at it and let us know if you

Re: [openstack-dev] [upgrades][skip-level][leapfrog] - RFC - Skipping releases when upgrading

I've mentioned this elsewhere but writing here for posterity... Making N to N+1 upgrades seamless and work well is already challenging today which is one of the reasons why people aren't upgrading in the first place. Making N to N+1 upgrades work as well as possible already puts a great strain on

Re: [openstack-dev] [requirements][tripleo][heat] Projects holding back requirements updates

On Fri, May 26, 2017 at 11:22 AM, Steven Hardy wrote: > On Thu, May 25, 2017 at 03:15:13PM -0500, Ben Nemec wrote: >> Tagging with tripleo and heat teams for the os-*-config projects. I'm not >> sure which owns them now, but it sounds like we need a new release. > > I think

[openstack-dev] [TripleO] overcloud_containers.yaml: container versioning, tags and use cases ?

Hi, Today we discussed a challenge around image tags that mostly boils down to limitations in how overcloud_containers.yaml is constructed and used. TL;DR, we need a smart and easy way to work with the overcloud_containers.yaml file (especially tags). Let's highlight a few use cases that we

Re: [openstack-dev] [nova][scheduler] Anyone relying on the host_subset_size config option?

Beside eliminate race conditions, we use host_subnet_size in the special cases, we have different capacity hardware in a deployment, imagine a simple case, two compute hosts(RAM 48G vs 16G free), only enable the RAM weighter for nova-scheduler, if we launch 10 instances(RAM 1G flavor) one by one,

Re: [openstack-dev] [neutron][L3][HA] 2 masters after reboot of node

I recommend a completely new RPC endpoint to trigger this behavior that the L3 agent calls before sync routers. Don't try to add it to sync routers which is already quite complex. :) On Fri, May 26, 2017 at 7:53 AM, Anil Venkata wrote: > Thanks Kevin, Agree with you. I

Re: [openstack-dev] [mistral][freezer] adopting oslo.context for logging debugging and tracing

Hi Doug, Anyway, thank for the notification. We are really appreciated. Regards, Vitaliy > 26 мая 2017 г., в 20:54, Doug Hellmann написал(а): > > Excerpts from Saad Zaher's message of 2017-05-26 12:03:24 +0100: >> Hi Doug, >> >> Thanks for your review. Actually freezer

[openstack-dev] [swift] new additional team meeting

In Boston, one of the topics is how to better facilitate communication in our global community. Like some other OpenStack projects, we've decided to add an additional meeting that is better scheduled for different time zones. Our current meeting is remaining: 2100UTC on Wednesdays in

Re: [openstack-dev] [swift] new additional team meeting

On Fri, May 26, 2017 at 4:06 PM, John Dickinson wrote: > > The new meeting is at a reasonable time for just about everyone, other > than those who live in New York to San Francisco time zones. define *un*-reasonable ;) Regardless we'll have the logs. > > I'd like to thank

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

+1 on not forcing Operators to transition to something new twice, even if we did go for option 3. Do we have an agreed non-distruptive upgrade path mapped out yet? (For any of the options) We spoke about fallback rules you pass but with a warning to give us a smoother transition. I think that's

Re: [openstack-dev] [doc][ptls][all] Documentation publishing future

On Mon, 22 May 2017 at 10:43, Alexandra Settle wrote: > We could also view option 1 as the longer-term goal, > and option 2 as an incremental step toward it +1 doing option 2 then option 1. It just seems a good way to split up the work. Thanks, johnthetubaguy

[openstack-dev] AttributeError: 'StackManager' object has no attribute 'event'

Hi Team, I am trying below code but the moment I run the code I am getting error. try: evntsdata = hc.stacks.event.list(stack_name=stack_name) #evntsdata = hc.stacks.events.list(stack_name) if evntsdata[-1] == 'UPDATE_IN_PROGRESS': loopcontinue = True while loopcontinue: evntsdata =

Re: [openstack-dev] [neutron]VM packet lost on qbr bridge

Is it being dropped by iptables? Check the following: * Your VM using the correct IPv6 address assigned to it by Neutron * The security group associated with the port allows outbound IPv6 traffic * ensure bridge-nf-call-ip6tables is set to 1 in the kernel of the compute node On Thu, May 25, 2017

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

On 05/19/2017 04:06 PM, Dean Troyer wrote: On Fri, May 19, 2017 at 4:01 PM, Matt Riedemann wrote: I'm confused by this. Creating a server takes a volume ID if you're booting from volume, and that's actually preferred (by nova devs) since then Nova doesn't have to

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

Hi, thanks for bringing this into discussion in the Operators list. Option 1 and 2 and not complementary but complety different. So, considering "Option 2" and the goal to target it for Queens I would prefer not going into a migration path in Pike and then again in Queens. Belmiro On Fri, May

Re: [openstack-dev] [TripleO] Undercloud backup and restore

Hey Yolanda! Thanks for your feedback, that's partially the idea of these 2 features, right now they are targeting the Undercloud (backup and restore), but yes, we should point something similar to the OC. Cheers, Carlos. On Wed, May 24, 2017 at 10:10 AM, Yolanda Robla Mota

Re: [openstack-dev] [TripleO] Undercloud backup and restore

On Wed, May 24, 2017 at 3:17 PM, Jiří Stránský wrote: > On 24.5.2017 15:02, Marios Andreou wrote: > >> On Wed, May 24, 2017 at 10:26 AM, Carlos Camacho Gonzalez < >> ccama...@redhat.com> wrote: >> >> Hey folks, >>> >>> Based on what we discussed yesterday in the TripleO weekly

[openstack-dev] [tc] Status update, May 26

Hi! This new regular email will give you an update on the status of a number of TC-proposed governance changes, in an attempt to rely less on a weekly meeting to convey that information. You can find the full status list of open topics at:

Re: [openstack-dev] [requirements][tripleo][heat] Projects holding back requirements updates

On Thu, May 25, 2017 at 03:15:13PM -0500, Ben Nemec wrote: > Tagging with tripleo and heat teams for the os-*-config projects. I'm not > sure which owns them now, but it sounds like we need a new release. I think they're still owned by the TripleO team, but we missed them in the pike-1 release,

Re: [openstack-dev] [diskimage-builder] Restarting bi-weekly meeting

This time is super complicated to me , as it's night here. Ideally i'd prefer early morning on UTC time, but I understand this may be a problem for people in another timezones. On Fri, May 26, 2017 at 7:42 AM, Ian Wienand wrote: > Hi, > > We've let this meeting [1] lapse,

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On 05/26/2017 03:44 AM, John Garbutt wrote: > +1 on not forcing Operators to transition to something new twice, even > if we did go for option 3. > > Do we have an agreed non-distruptive upgrade path mapped out yet? (For > any of the options) We spoke about fallback rules you pass but with a >