[openstack-dev] [new][oslo] oslo.messaging 5.12.0 release (ocata)

We are exuberant to announce the release of: oslo.messaging 5.12.0: Oslo Messaging API This release is part of the ocata release series. The source is available from: http://git.openstack.org/cgit/openstack/oslo.messaging Download the package from:

[openstack-dev] [new][oslo] oslo.rootwrap 5.1.1 release (newton)

We are glad to announce the release of: oslo.rootwrap 5.1.1: Oslo Rootwrap This release is part of the newton stable release series. The source is available from: http://git.openstack.org/cgit/openstack/oslo.rootwrap Download the package from:

[openstack-dev] [new][oslo] oslo.utils 3.18.0 release (ocata)

We are psyched to announce the release of: oslo.utils 3.18.0: Oslo Utility library This release is part of the ocata release series. The source is available from: http://git.openstack.org/cgit/openstack/oslo.utils Download the package from: https://pypi.python.org/pypi/oslo.utils

Re: [openstack-dev] [Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

> On 4 Nov. 2016, at 1:33 pm, Emilien Macchi wrote: > > On Thu, Nov 3, 2016 at 9:10 PM, Sam Morrison > wrote: >> Wow I didn’t realise puppet3 was being deprecated, is anyone actually using >> puppet4? >> >> I would hope

[openstack-dev] [cinder] generic volume groups and consistency groups

Hi everyone, Generic volume groups support was added in Cinder in Newton. We are planning to migrate consistency groups to generic volume groups. I have submitted a dev doc patch to explain how to add consistency groups support in generic volume groups in a driver. Let me know if you have

[openstack-dev] [neutron] Barcelona summit neutron-lib session recap

Ocata neutron-lib session recap --- tl;dr: - Speed up moving common code into neutron-lib - Sub-project maintainers must keep up and should contribute The session consisted of announcing the goals around speeding up the neutron-lib work so that consuming projects

Re: [openstack-dev] [Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

On Thu, Nov 3, 2016 at 9:10 PM, Sam Morrison wrote: > Wow I didn’t realise puppet3 was being deprecated, is anyone actually using > puppet4? > > I would hope that the openstack puppet modules would support puppet3 for a > while still, at lest until the next ubuntu LTS is out

Re: [openstack-dev] [neutron][networking-vpp] - Status of startup issues

Hi John, I think the fix that will most likely go in is https://review.openstack.org/#/c/391523/. Removing local cache should fairly cleanly make the physnets check work. Currently our CI gate is broken on a package versioning problem, once the CI fix goes in (

[openstack-dev] [tricircle]Barcelona design summit sessions recap

Hello, During the two sessions in Barcelona and the weekly meeting this week, the summary is located in https://etherpad.openstack.org/p/ocata-tricircle-work-session Contents also attached here: Milestones: Ocata-2: Dec.15 Ocata-3: Jan.26 Release: Feb.22 Topics: Title: shared

[openstack-dev] [jjb] Multibranch pipeline/workflow better support?

Hi folks using jenkins-job-builder, I was just looking around for better additions to the jenkins-job-builder for multibranch workflows (see https://jenkins.io/blog/2015/12/03/pipeline-as-code-with-multibranch-workflows-in-jenkins/) and stumbled into the following:

[openstack-dev] [Docs] Changes to docs speciality teams, meetings, and reporting

Hi everyone, There was a long-running and wide-ranging conversation during Summit about community engagement in the docs team, most formally at the 'Social Things' session[1], and culminating in the 'Ocata Planning' session[2] on the last day. I suggest you read those etherpads if you weren't

Re: [openstack-dev] [Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

Wow I didn’t realise puppet3 was being deprecated, is anyone actually using puppet4? I would hope that the openstack puppet modules would support puppet3 for a while still, at lest until the next ubuntu LTS is out else we would get to the stage where the openstack release supports Xenial but

Re: [openstack-dev] [nova] Nova-MultiJob CI (non-voting) request to comment

On 11/3/2016 3:45 AM, Lenny Verkhovsky wrote: Hi, We would like Mellanox[1] MultiNode CI job to start commenting as ‘non voting’ job on partial nova[2] and tempest[3] code. This Job runs few migration tests[4] and an example of its run can be seen here[5]. [1]

Re: [openstack-dev] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

On 04/11/16 01:16, Julien Danjou wrote: > On Thu, Nov 03 2016, Adrian Turjak wrote: > >> I'd need to double check exactly what query it is, but it effectively >> amounts to: >> "List all instance metric samples where project_id is and timestamp >> is in time range -" >> >> The time range is an

Re: [openstack-dev] [monasca] License for monasca-statsd

On 2016-11-03 18:17:42 -0400 (-0400), Chuck Short wrote: > I have checked the version on pypi and tarballs.openstack.org and all the > versions from monasca-statsd from 1.0.0 onwards provide the incorrect > LICENSE file. Right, I'm saying I hope the files which have Apache license headers in them

Re: [openstack-dev] [monasca] License for monasca-statsd

On Thu, Nov 3, 2016 at 3:55 PM, Jeremy Stanley wrote: > On 2016-11-03 15:03:44 -0400 (-0400), Chuck Short wrote: > > I was looking at packaging monasca-statsd since it is a dependency for > > designate, however when I look at the license for it,it says Apache-2. > > However

Re: [openstack-dev] [all][dev][python] constructing a deterministic representation of a python data structure

Excerpts from Amrith Kumar's message of 2016-11-03 20:50:01 +: > Josh, > > I have the key management part figured out and in actuality I will be > signing the messages. > > But step 1 is getting a deterministic representation and step 2 is hashing. > Step 3 would be signing. > > So, steps

Re: [openstack-dev] [mistral] Ocata summit summary

Thanks for sharing this, Renat! Cheers, Lingxian Kong (Larry) On Thu, Nov 3, 2016 at 8:41 PM, Renat Akhmerov wrote: > Hi, > > I’d like to share the summary of activities happened in Barcelona around > Mistral. > > = Presentations = > > 1.

[openstack-dev] [Neutron] summit sessions - feedback

Hi Neutrinos, You will be noticing a few emails getting into your inbox with subject summit recap or similar. Watch out for those if you're interested in making sense of the discussions as captured on etherpads [1]. Many thanks to the session chairs for the effort! Cheers and happy hacking!

Re: [openstack-dev] [networking-ovn] restart failure to bring up ovn services

> > The OVN packages install systemd units, so you can also start it that way > and set it up to re-start after a reboot. > > $ sudo systemctl enable ovn-northd > $ sudo systemctl start ovn-northd > > I did install python_networking_ovn & openvswitch-switch. I could not find any other ovn packages

Re: [openstack-dev] [all][dev][python] constructing a deterministic representation of a python data structure

Amrith, Please see the older work from 2013: https://blueprints.launchpad.net/oslo.messaging/+spec/trusted-messaging https://etherpad.openstack.org/p/HavanaOsloMessaging https://blog-nkinder.rhcloud.com/?p=62 https://adam.younglogic.com/2014/04/pki-for-oslo-messaging/ -- Dims On Thu, Nov 3,

Re: [openstack-dev] [all][dev][python] constructing a deterministic representation of a python data structure

From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com] Sent: Thursday, November 3, 2016 4:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all][dev][python] constructing a deterministic

Re: [openstack-dev] [glance] draft logo of glance mascot

Thanks for the feedback, Brian! That is always HUGELY helpful. I’ll convey that to the design team and I’m hoping you also took a moment to include your feedback on the tinyurl.com/OSmascot page (because it makes it a lot easier for us to see all feedback side-by-side). Either way, I’m very

Re: [openstack-dev] [ovn] [[l3-agent] connectivity to external network

On Thu, Nov 3, 2016 at 3:31 PM, Murali R wrote: > The scope of question is using neutron L3 services with OVN. The problem > is when a router created, there is no implicit internal interface created > between the router instance and the external bridge. > ​To be honest,

Re: [openstack-dev] [all][dev][python] constructing a deterministic representation of a python data structure

Josh, I have the key management part figured out and in actuality I will be signing the messages. But step 1 is getting a deterministic representation and step 2 is hashing. Step 3 would be signing. So, steps 2 and 3 are all set; just need step 1 :) And I'm marveling at the link that Morgan

Re: [openstack-dev] [FaaS] Function as a service in OpenStack

Would Kubernetes be a good fit? It might be possible to hook up a Zaqar queue to submit k8s Jobs? Thanks, Kevin From: Lingxian Kong [anlin.k...@gmail.com] Sent: Wednesday, November 02, 2016 6:20 PM To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all][dev][python] constructing a deterministic representation of a python data structure

On Thu, Nov 3, 2016 at 1:04 PM, Amrith Kumar wrote: > Gordon, > > You can see a very quick-and-dirty prototype of the kind of thing I'm > looking to do in Trove at > https://gist.github.com/amrith/6a89ff478f81c2910e84325923eddebe > > Uncommenting line 51 would simulate a bad

Re: [openstack-dev] [all][dev][python] constructing a deterministic representation of a python data structure

I wouldn't recommend this (the basic hash) if you actually want to do any kind of validation that the contents weren't altered. Is that the purpose? Or are you trying to ensure bits aren't flipped? If u want some level of validation that the message wasn't tampered with u probably at least

Re: [openstack-dev] [neutron][networking-vpp] - Status of startup issues

thx De : "John Joyce (joycej)" Répondre à : "OpenStack Development Mailing List (not for usage questions)" Date : jeudi 3 novembre 2016 à 15:23 À : "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [all][dev][python] constructing a deterministic representation of a python data structure

Gordon, You can see a very quick-and-dirty prototype of the kind of thing I'm looking to do in Trove at https://gist.github.com/amrith/6a89ff478f81c2910e84325923eddebe Uncommenting line 51 would simulate a bad hash. I'd be happy to propose something similar in oslo.messaging if you think that

Re: [openstack-dev] [monasca] License for monasca-statsd

On 2016-11-03 15:03:44 -0400 (-0400), Chuck Short wrote: > I was looking at packaging monasca-statsd since it is a dependency for > designate, however when I look at the license for it,it says Apache-2. > However the LICENSE file included in the source is that the software is > provided as

Re: [openstack-dev] [all][dev][python] constructing a deterministic representation of a python data structure

Dims, I don't think ovo addresses this issue. It isn't one of versioning that I'm attempting to address but rather as Gordon points out, of signing and verifying authenticity. Please see also my longer response to him on this. -amrith -Original Message- From: Davanum Srinivas

Re: [openstack-dev] [oslo][oslo-messaging] [all][dev][python] constructing a deterministic representation of a python data structure

Yes, what I'm trying to do is related to this spec. https://review.openstack.org/#/c/391637/ The basic idea is this, I'd like to make sure that a message sent over oslo.messaging is actually from the person that we expect that it is from. So, to that end, I'd like to sign the message on the way

[openstack-dev] [ovn] [[l3-agent] connectivity to external network

The scope of question is using neutron L3 services with OVN. The problem is when a router created, there is no implicit internal interface created between the router instance and the external bridge. The neutron config says "external_network_bridge" and "gateway_external_network_id" must be set

[openstack-dev] [cinder][stable] Deprecation notice: Driver for NetApp Data ONTAP operating in 7-mode

Developers and Operators, The NetApp unified driver in Cinder currently provides integration for two major generations of the ONTAP operating system: the current “clustered” ONTAP and the legacy 7-mode. NetApp’s “full support” for 7-mode ended in August of 2015 and the current “limited

Re: [openstack-dev] [all][dev][python] constructing a deterministic representation of a python data structure

On 03/11/16 02:24 PM, Amrith Kumar wrote: > > So, just before calling call() or cast(), I could compute the hash and > stuff it into the dictionary that is being sent over, and I can do the > same on the receiving side. But since I cannot guarantee that the > representation on the receiving

Re: [openstack-dev] [oslo] New and next-gen libraries (a BCN followup)

Jay Faulkner wrote: On Nov 3, 2016, at 11:27 AM, Joshua Harlow wrote: Just as a followup from the summit, One of the sessions (the new lib one) had a few proposals: https://etherpad.openstack.org/p/ocata-oslo-bring-ideas And I wanted to try to get clear owners for

[openstack-dev] [monasca] License for monasca-statsd

Hi, I was looking at packaging monasca-statsd since it is a dependency for designate, however when I look at the license for it,it says Apache-2. However the LICENSE file included in the source is that the software is provided as is...etc etc. Could we get some clarification please? Thanks

Re: [openstack-dev] [all][dev][python] constructing a deterministic representation of a python data structure

Does oslo.versionedobjects solve some of your needs? http://www.slideshare.net/davanum/ovo-deep-dive https://gorka.eguileor.com/learning-something-new-about-oslo-versioned-objects/ http://www.danplanet.com/blog/2015/10/06/upgrades-in-nova-objects/ -- Dims On Thu, Nov 3, 2016 at 2:24 PM, Amrith

Re: [openstack-dev] [manila] spec review focus

The following specs were designated as review focus specs for Ocata: https://etherpad.openstack.org/p/manila-ocata-spec-review-focus -Ben On 11/03/2016 12:27 PM, Ben Swartzlander wrote: As agreed to in the manila spec process spec, the whole core team is expected to review certain specs and

[openstack-dev] [neutron] neutron-server retrospective/next steps summit session recap

Hi all, this is a recap for the neutron-server session that was on Fri. === tl;dr for Ocata, we proceed with adopting OVO (reviewers needed!), push-notifications (now unblocked, Kevin already spins up patches), and no-downtime-upgrades (contract alembic migrations will be forbidden for

Re: [openstack-dev] [oslo] New and next-gen libraries (a BCN followup)

> On Nov 3, 2016, at 11:27 AM, Joshua Harlow wrote: > > Just as a followup from the summit, > > One of the sessions (the new lib one) had a few proposals: > > https://etherpad.openstack.org/p/ocata-oslo-bring-ideas > > And I wanted to try to get clear owners for each

Re: [openstack-dev] [all][i18n] how to indicate non-translatable identifiers in translatable strings?

Excerpts from Ian Y. Choi's message of 2016-11-04 00:58:30 +0900: > Hello, > > I am from I18n team. Please see inline for my comments. > > Doug Hellmann wrote on 11/3/2016 2:19 AM: > > Excerpts from Brian Rosmaita's message of 2016-11-02 16:34:45 +: > >> This issue came up during a code

Re: [openstack-dev] [Neutron][neutron-lbaas][octavia] Not be able to ping loadbalancer ip

Going through the log , I saw the following error on o-hm 2016-11-03 03:31:06.441 19560 ERROR octavia.controller.worker.controller_worker request_ids=request_ids) 2016-11-03 03:31:06.441 19560 ERROR octavia.controller.worker.controller_worker BadRequest: Unrecognized attribute(s) 'dns_name'

[openstack-dev] [oslo] New and next-gen libraries (a BCN followup)

Just as a followup from the summit, One of the sessions (the new lib one) had a few proposals: https://etherpad.openstack.org/p/ocata-oslo-bring-ideas And I wanted to try to get clear owners for each part (there was some followup work for each); so just wanted to start this email to get the

[openstack-dev] [all][dev][python] constructing a deterministic representation of a python data structure

TL;DR I want to take a python data structure (see later for details) and represent it in a format that will be stable across python versions, and platforms so that I can construct a stable hash. I'm looking for pointers to some best practices on how to do this. The longer version

[openstack-dev] [release] Release countdown for week R-15, 7 - 11 Nov

Welcome back from summit! As we did last cycle, the release team will be sending reminder emails as we count down toward the Ocata release. If all goes as planned, these emails will be sent just before the week mentioned in the subject (on my Thursday, but some of you live in the future).

[openstack-dev] [zaqar] Summary of Barcelona Design Summit

Greetings, Firstly, thank you for everyone joined Zaqar sessions at Barcelona summit. We definitely made some great progress for those working sessions. Here are the high level summary and those are basically our Ocata priorities. I may miss something so please feel free to comment/reply

[openstack-dev] [nova][ironic] Announcing Valence, support for integrating Rack Scale Devices

Hello Everyone! We are very pleased to announce Valence. Please visit our wiki at https://wiki.openstack.org/wiki/Valence Regards, Malini __ OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [manila] Access key via the UI?

On 11/03/2016 10:33 AM, Ravi, Goutham wrote: > Ah. I’d let Tom or Ramana weigh in on that. IIRC, the access key is > plaintext, so, I thought it can be displayed; that’s what the CLI is doing. > > Reading the spec though, this was an intended part of the feature: >

Re: [openstack-dev] Splitting notifications from rpc (and questions + work around this)

Cheran, Nova and Neutron already supported this split when we started this exercise. So yes, they are already shipped :) https://review.openstack.org/#/c/266960/ https://review.openstack.org/#/c/268335/ -- Dims On Thu, Nov 3, 2016 at 1:43 PM, Elancheran Subramanian

Re: [openstack-dev] Splitting notifications from rpc (and questions + work around this)

Hi Dims, Thanks for sharing… Just wanted to check whether there is any development for Nova and Neutron going on, which we can leverage? Thanks, Cheran On 11/3/16, 12:51 AM, "Davanum Srinivas" wrote: >Josh, > >Kirill Bespalov put together this doc of which components

Re: [openstack-dev] [neutron] proposal to resolve a rootwrap problem for XenServer

>> Side note: we should first have Xen third-party CI testing running > > It already is running > Oh right. It does not validate the new change though. Would be nice to see > the new ‘daemon’-ic mode behaves in real world. 100% agreed. I'll work with Jianghua to make sure we get automated

[openstack-dev] [all][api] POST /api-wg/news

Greetings OpenStack community, This week's meeting of the working group talked about the discussion at the API-WG "birds of a feather" at last week's summit in Barcelona. Thanks to everyone who showed up for that. I hope it was interesting and useful. Also thanks very much to all the people

Re: [openstack-dev] [glance] draft logo of glance mascot

Hello Heidi Joy, First, let me say on behalf of the Glance community that we appreciate the hard work you and your team have done in creating all the team mascot/logos. We discussed the draft logo at the weekly Glance meeting today [0], and the general sense of the Glance community is that we'd

[openstack-dev] [manila] spec review focus

As agreed to in the manila spec process spec, the whole core team is expected to review certain specs and vote before they merge. The following specs were designed as review focus specs for Ocata: https://etherpad.openstack.org/p/manila-ocata-spec-review-focus -Ben Swartzlander

[openstack-dev] [all] important changes to pep8 python jobs

Greetings, We (openstack-infra) are proposing a change to the current pep8[1] job for python jobs, and would like to bring your attention to it. We'll be removing the extra-index-url field from pip.conf which forces the job to manually build any missing wheels as dependencies. The reason for

Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

a blog post on the OpenStack sore might be good. superuser? there are folks reading this who can help Sent from HUAWEI AnyOffice From:Lance Bragstad To:OpenStack Development Mailing List (not for usage questions),openstack-operat...@lists.openstack.org, Date:2016-11-03 08:11:20 Subject:Re:

[openstack-dev] [puppet][fuel][packstack][tripleo] puppet 3 end of life

Hey everyone, Puppet 3 is reaching it's end of life at the end of this year[0]. Because of this we are planning on dropping official puppet 3 support as part of the Ocata cycle. While we currently are not planning on doing any large scale conversion of code over to puppet 4 only syntax, we may

Re: [openstack-dev] [all][i18n] how to indicate non-translatable identifiers in translatable strings?

Hello, I am from I18n team. Please see inline for my comments. Doug Hellmann wrote on 11/3/2016 2:19 AM: Excerpts from Brian Rosmaita's message of 2016-11-02 16:34:45 +: This issue came up during a code review; I've asked around a bit but haven't been able to find an answer. Some of the

Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

I totally agree with communicating this the best we can. I'm adding the operator list to this thread to increase visibility. If there are any other methods folks think of for getting the word out, outside of what we've already done (release notes, email threads, etc.), please let me know. I'd be

Re: [openstack-dev] [manila] propose adding gouthamr to manila core

+2 On Thu, Nov 3, 2016 at 4:36 PM, yang, xing wrote: > +1. > > Thanks, > Xing > > > > > From: Tom Barron [whui...@gmail.com] > Sent: Wednesday, November 2, 2016 8:09 AM > To: openstack-dev@lists.openstack.org > Subject:

Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

Hey Steve, On Thu, Nov 3, 2016 at 8:29 AM, Steve Martinelli wrote: > Thanks Alex and Emilien for the quick answer. This was brought up at the > summit by Adam, but I don't think we have to prevent keystone from changing > the default. TripleO and Puppet can still specify

Re: [openstack-dev] [neutron] proposal to resolve a rootwrap problem for XenServer

Bob Ball wrote: Hi Ihar, I am puzzled. Is Neutron the only component that need to call to dom0? No it's not. Nova has similar code to call plugins in dom0[1], and Ceilometer will also need to make the calls for some metrics not exposed through the formal API. We

Re: [openstack-dev] [manila] propose adding gouthamr to manila core

+1. Thanks, Xing From: Tom Barron [whui...@gmail.com] Sent: Wednesday, November 2, 2016 8:09 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [manila] propose adding gouthamr to manila core I hereby propose that we add Goutham Pacha

[openstack-dev] [manila] Barcelona Design Summit summary

Thanks to gouthamr for doing these writeups and for recording! We had a great turn out at the manila Fishbowl and working sessions. Important notes and Action Items are below: === Fishbowl 1: Race Conditions === Thursday 27th Oct / 11:00 - 11:40

Re: [openstack-dev] [manila] Access key via the UI?

Ah. I’d let Tom or Ramana weigh in on that. IIRC, the access key is plaintext, so, I thought it can be displayed; that’s what the CLI is doing. Reading the spec though, this was an intended part of the feature: http://specs.openstack.org/openstack/manila-specs/specs/newton/auth-access-keys.html

Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

Thanks Alex and Emilien for the quick answer. This was brought up at the summit by Adam, but I don't think we have to prevent keystone from changing the default. TripleO and Puppet can still specify UUID as their desired token format; it is not deprecated or slated for removal. Agreed? On Thu,

Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

Hey Steve, On Thu, Nov 3, 2016 at 8:11 AM, Steve Martinelli wrote: > As a heads up to some of keystone's consuming projects, we will be changing > the default token format from UUID to Fernet. Many patches have merged to > make this possible [1]. The last 2 that you

[openstack-dev] [neutron][networking-vpp] - Status of startup issues

Is anyone able to provide a summary of which patches fix the startup scenarios. Any startup issues are of interest but the one we specifically have bugs around is the phsynets not being discovered by the server properly. I see: https://bugs.launchpad.net/networking-vpp/+bug/1631063 which says a

Re: [openstack-dev] [neutron] proposal to resolve a rootwrap problem for XenServer

Hi Ihar, > I am puzzled. Is Neutron the only component that need to call to dom0? No it's not. Nova has similar code to call plugins in dom0[1], and Ceilometer will also need to make the calls for some metrics not exposed through the formal API. We don't want code duplication, and are

Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

On Thu, Nov 3, 2016 at 10:11 AM, Steve Martinelli wrote: > As a heads up to some of keystone's consuming projects, we will be changing > the default token format from UUID to Fernet. Many patches have merged to > make this possible [1]. The last 2 that you probably want to

Re: [openstack-dev] [manila] Access key via the UI?

Hi Goutham, It’s already being returned in the manila access-list API as of 2.21, if you’re using the latest python-manilaclient, you should have it there. However, it’s missing in the UI: Yes, I was comparing what I can do on the CLI and what was offered with the UI.

[openstack-dev] [trove] migration of trove-integration; ci changes

Unless you are actively working on Trove, this is something you wouldn't care about so here's the TL;DR The changes to the Trove CI (including trove, trove-integration, and python-troveclient) related to the project to get rid of trove-integration are now complete. Thanks to everyone in infra

[openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

As a heads up to some of keystone's consuming projects, we will be changing the default token format from UUID to Fernet. Many patches have merged to make this possible [1]. The last 2 that you probably want to look at are [2] and [3]. The first flips a switch in devstack to make fernet the

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

> On 3 Nov 2016, at 14:33, Mauricio Lima wrote: > > I Agree. +1 +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [neutron] proposal to resolve a rootwrap problem for XenServer

Thierry Carrez wrote: Bob Ball wrote: Oslo.privsep seem try to launch a daemon process and set caps for this daemon; but for XenAPI, there is no need to spawn the daemon. I guess I'm lacking some context... If you don't need special rights, why use a rootwrap-like

Re: [openstack-dev] [manila] Access key via the UI?

Hey Arne, It’s already being returned in the manila access-list API as of 2.21, if you’re using the latest python-manilaclient, you should have it there. However, it’s missing in the UI:

Re: [openstack-dev] [networking-ovn] restart failure to bring up ovn services

On Wed, Nov 2, 2016 at 6:48 PM, Murali R wrote: > Following the docs online (Newton), the installation was successful. > However when the VM that has the controller (and ovn-nb) restarted, it > fails to bring up ovs & ovn. This is ubuntu deployment using >

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

I Agree. +1 2016-11-03 10:21 GMT-03:00 Paul Bourke : > Kolleagues, > > How do people feel above removing the requirement of having TrivialFix in > commit messages where a bug/bp is not required? > > I'm seeing a lot of valid and important commits being held up because of

[openstack-dev] [kolla] Propose removal of TrivialFix requirement

Kolleagues, How do people feel above removing the requirement of having TrivialFix in commit messages where a bug/bp is not required? I'm seeing a lot of valid and important commits being held up because of this, in my opinion, unnecessary requirement. It also causes friction for new

[openstack-dev] [ironic][tempest][openwhisk] Notes from the Barcelona summit

Capsule rec.juggling-style review - **High:** Impossible to pick out one moment in particular, but in general it was getting to chat informally over dinner/drinks/climbing with other Stackers. Thanks everyone for making me feel welcome! **Low:** Spending four

[openstack-dev] [Keystone] Token Verify Role Check

There has been a lot of talk about Policy this past summit and release. Based on feedback, we've come up with the following spec to address it. https://review.openstack.org/#/c/391624/ The idea is that we are going to split the role check off from the existing policy checks. The role check

Re: [openstack-dev] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

On 02/11/16 08:10 PM, Adrian Turjak wrote: > > On 03/11/16 03:01, gordon chung wrote: >> gnocchi captures the state of a resource and it's history. this is >> accessible by looking at resource history. i'm not entirely sure if that >> handles your case, may you could provide the queries you use

Re: [openstack-dev] [neutron] proposal to resolve a rootwrap problem for XenServer

Bob Ball wrote: >>> Oslo.privsep seem try to launch a daemon process and set caps for this >> daemon; but for XenAPI, there is no need to spawn the daemon. >> >> I guess I'm lacking some context... If you don't need special rights, why >> use a >> rootwrap-like thing at all ? Why go through a

Re: [openstack-dev] [tripleo] possible backports for stable/newton

Hi Michele, vous autres, On Thu, Nov 3, 2016 at 4:50 AM, Michele Baldessari wrote: > Hi Brent ;) > > On Thu, Nov 03, 2016 at 01:20:12AM -0230, Brent Eagles wrote: > > puppet-tripleo > > > > https://review.openstack.org/#/c/389583/ Set redis file descriptor limit > > when run

[openstack-dev] [vitrage] FW: Your draft logo & sneak peek

Hi, Please find below the draft for the Vitrage Giraffe. If you would like to provide feedback on the design, you can use: http://tinyurl.com/OSmascot Note that the original idea was to have a colourful Giraffe, with a skin that looks like a Vitrage. Here's a 50-second "sneak peek" at how they

Re: [openstack-dev] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

On Thu, Nov 03 2016, Maxime Belanger wrote: Hi Maxime, > We had this project of our own for a couple years and it was not meant to > replace Ceilometer at all. For our billing use case, yes it did replace > Ceilometer because scaling issues. We just wanted to propose it to the > community as a

Re: [openstack-dev] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

On Thu, Nov 03 2016, Adrian Turjak wrote: > I'd need to double check exactly what query it is, but it effectively > amounts to: > "List all instance metric samples where project_id is and timestamp > is in time range -" > > The time range is an hour + leadin from last hour to catch the last >

Re: [openstack-dev] [all][release] Release announcements

2016-11-03 1:28 GMT+08:00 Davanum Srinivas : > On Wed, Nov 2, 2016 at 1:21 PM, Doug Hellmann > wrote: > > Excerpts from Thierry Carrez's message of 2016-11-02 17:33:51 +0100: > >> Hi everyone, > >> > >> In Barcelona the release team has been discussing

Re: [openstack-dev] [TripleO] [UI] Adding a new job to the gate

On Thu, Nov 3, 2016 at 6:24 AM, Julie Pichon wrote: > Hi, > > At the end of Newton we had a few issues where the packaged UI in DLRN > didn't work at all. To try and avoid similar problems happening again, > I've been working on a simple sanity check to be run on CI at [1].

Re: [openstack-dev] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

Hi Emilien, We had this project of our own for a couple years and it was not meant to replace Ceilometer at all. For our billing use case, yes it did replace Ceilometer because scaling issues. We just wanted to propose it to the community as a matter of sharing knowledge. This system just

[openstack-dev] [manila] Access key via the UI?

Hi, As cephx has been added as an access type in the dashboard and an access key can now be part of the API's response to access list requests, is it planned to have the access key to be returned when adding a cephx access rule via the UI (for instance similar to what ‘Create Key Pair’ in the

Re: [openstack-dev] [manila] propose adding gouthamr to manila core

Wow!! Great idea. From: Thomas Bechtold Sent: Thursday, November 3, 2016 11:16:41 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [manila] propose adding gouthamr to manila core ** This mail has been sent from an

[openstack-dev] [nova] next notification subteam meeting

Hi, The next notification subteam meeting will be held on 2016.11.08 17:00 UTC [1] on #openstack-meeting-4. Also I proposed [2] to change the meeting frequency from biweekly to weekly until the feature freeze of Ocata. Cheers, Gibi [1]

Re: [openstack-dev] [nova] [searchlight] Discrepancies between nova server notifications and API response

> -Original Message- > From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] > Sent: October 31, 2016 14:01 > > On 10/28/2016 4:32 PM, McLellan, Steven wrote: > > Hi, > > > > I was unfortunately unable to make the summit but I'm told there were > > some good discussions around possible

[openstack-dev] [TripleO] [UI] Adding a new job to the gate

Hi, At the end of Newton we had a few issues where the packaged UI in DLRN didn't work at all. To try and avoid similar problems happening again, I've been working on a simple sanity check to be run on CI at [1]. All the necessary patches are up, this is just a heads-up for folks working in the

[openstack-dev] [nova][ironic] Instance can "migrate" to another node?

Hi al, Now, nova’s ironic driver can allow multiple compute services. I am not sure that, when a compute node is down. The instances running in it, whether can “migrate” to another compute node(use ironic driver)? Thanks C1dx

Re: [openstack-dev] [kuryr][magnum] Notes from Summit fishbowl session

On Thu, Nov 3, 2016 at 4:29 AM, Vikas Choudhary wrote: > > > On Thu, Nov 3, 2016 at 12:33 AM, Antoni Segura Puimedon > wrote: >> >> Hi magna and kuryrs! >> >> Thank you all for joining last week meetings. I am now writing a few >> emails to have

[openstack-dev] Nova-MultiJob CI (non-voting) request to comment

Hi, We would like Mellanox[1] MultiNode CI job to start commenting as 'non voting' job on partial nova[2] and tempest[3] code. This Job runs few migration tests[4] and an example of its run can be seen here[5]. [1] https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_CI [2] nova/pci [3]

  1   2   >