Re: [openstack-dev] Acknowledging Jim Blair's work on the TC

Absolutely, +1! Thanks very much for all you do Jim. On Sat, Apr 2, 2016 at 6:06 AM, Anita Kuno wrote: > Jim is an incumbent on the TC this election and he didn't run. I'm > posting this to express my thanks to Jim for his work and dedication on > the TC. > > Jim, I think

Re: [openstack-dev] [monasca][release] missing build artifacts

Hi Doug, You had mentioned issues with three repos: 1. monasca-ceilometer 2. monasca-log-api 3. monasca-thresh All the repos that have Python code I believe are in reasonable shape with respect to the Python deliverables except for the following two repos: 1. monasca-ceilometer 2.

[openstack-dev] [nova] We have our first implemented blueprint in Newton

Congratulations to Nikola for being the first to get a blueprint implemented in Newton [1][2]. I would give a shiny trophy if I had one. Just 34 more of the already approved blueprints to go. :) Seriously though, this is nice to see so quickly, and I'm seeing good progress on some of the

Re: [openstack-dev] [nova] Which SSL ca_file does a person use, really?

> > However, I'd be willing to bet there's some cloud out there where at > least one of these services is owned by a separate team than Nova, who > uses a different CA than the rest of things. > It's not really a constraint as a cafile can contain one or more CA(s). Typical examples : *

[openstack-dev] [Neutron] Team meeting this Monday at 2100 UTC

Hi neutrinos, A kind reminder for next week's meeting. More on the agenda [1]. Cheers, Armando [1] https://wiki.openstack.org/wiki/Network/Meetings __ OpenStack Development Mailing List (not for usage questions)

[openstack-dev] [security][tc] Tidy up language in section 5 of the vulnerability:managed tag

Please see my review here as requested in this thread [1]: https://review.openstack.org/300698 The purpose of this review is two fold: 1. Permit sponsoring companies of single vendor projects or projects with low company affiliation diversity to allow their own security experts to sign

Re: [openstack-dev] [Neutron] Adding amuller to the neutron-drivers team

Congratulations Assaf! From: "Armando M." > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Thursday, March 31, 2016 at 5:48 PM To: "OpenStack

Re: [openstack-dev] [Tricircle] Naming convention

One of examples is: """ tricircle/db/api.py """ authorize_quota_class_context(context, class_name): # This could become: auth_quota_class_ctx(ctx, class_name): # If we put some comment for this, this also could become: """ Function: Ensure a request has right permission to given the

Re: [Openstack-operators] [neutron][ml2] Gutting ML2 from Neutron - possible?

On 04/01/2016 03:18 PM, Adam Lawson wrote: > Hi Dan - thanks I think that answers the core plugin question. What is > Contrail doing with the Neutron service plugin? Are there two plugins? > > //adam > > */ > Adam Lawson/* > > AQORN, Inc. > 427 North Tatnall Street > Ste. 58461 > Wilmington,

Re: [openstack-dev] [congress][release] missing build artifacts

Hi Doug, Thanks for letting us know. Here's what we're intending... - We'd like to release the server code for Mitaka. - We release the client to Pypi, so that's already taken care of. - We haven't moved our docs off of readthedocs yet, so we're taking care of that as well. I gave a +1 to your

Re: [openstack-dev] [tempest] Implementing tempest test for Keystone federation functional tests

On Thu, Mar 31, 2016 at 1:11 PM, Matthew Treinish wrote: > On Thu, Mar 31, 2016 at 11:38:55AM -0400, Minying Lu wrote: > > Hi all, > > > > I'm working on resource federation at the Massachusetts Open Cloud. We > want > > to implement functional test on the k2k federation,

Re: [openstack-dev] [bifrost][ironic][release] missing build artifacts

On Fri, Apr 1, 2016 at 4:48 PM, Doug Hellmann wrote: > Excerpts from Doug Hellmann's message of 2016-04-01 16:25:07 -0400: > > Ironic/Bifrost team, > > > > > It would be good to understand what your intent is for builds. Can > > you follow up here on this thread with

[openstack-dev] [Tricircle] Naming convention

Hi Team, Probably it's worth thinking of naming convention for classes, methods or whatever we define in source codes. Some names are lengthy and there might be no consistency. At the moment it's fine. But once this project gets growing, situation would become chaotic and could cause bugs. What

Re: [Openstack-operators] [neutron][ml2] Gutting ML2 from Neutron - possible?

Hi Dan - thanks I think that answers the core plugin question. What is Contrail doing with the Neutron service plugin? Are there two plugins? //adam *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101

Re: [openstack-dev] [magnum] Split k8s-client in separate python package

Dims, Thanks for splitting the k8sclient code out. Below is my answer to your question. - Should this be a new openstack/ repo? Yes, I think so. We need it in openstack namespace in order to leverage the openstack infra for testing and packaging. - Would the Magnum team own the repo and use

Re: [openstack-dev] Meeting time preferences for OSC team

Possible options: A) 1. even week: *E.1* 2. odd week: *O.3* B) 1. even week: *E.4* 2. odd week: *O.3* >Dear All, >This is regarding deciding meeting time for OSC team to facilitate >appropriate time for APAC guys. >We are planning to have meeting on alternate weeks for this purpose. >Some

Re: [openstack-dev] Floating IPs and Public IPs are not equivalent

The main barrier to this is that we need to stop using the 'external_network_bridge = br-ex' option for the L3 agent and define a bridge mapping on the L2 agent. Otherwise the external network is treated as a special case and the VMs won't actually be able to get wired into the external network.

Re: [openstack-dev] Floating IPs and Public IPs are not equivalent

Or if you don't like floating IPs, it means you can have floating IPs available to only one tenant you dislike. :) On Fri, Apr 1, 2016 at 11:39 AM, Monty Taylor wrote: > On 04/01/2016 12:00 PM, Fox, Kevin M wrote: > >> And with external rbac in mitaka, you can finally have

Re: [openstack-dev] [Neutron] Adding amuller to the neutron-drivers team

Welcome! \o/ On Fri, Apr 1, 2016 at 12:04 PM, Carl Baldwin wrote: > Welcome, Assaf! > > On Thu, Mar 31, 2016 at 6:48 PM, Armando M. wrote: > > Hi folks, > > > > Assaf's tenacity is a great asset for the Neutron team at large. I > believe > > that the

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

Excerpts from Matt Kassawara's message of 2016-04-01 12:38:02 -0600: > Hi, > > I didn't see this e-mail until now because I'm busy trying to update and > test the installation guide in time for the Mitaka release. As a primary > contributor to the installation guide for about six releases

Re: [openstack-dev] [neutron]: Neutron naming legal issues

This kind of thing happens all the time, and usually its not reasonable to enforce across different types of things. Especially since neutrons a type of space/science thing and so is nova, from which it spawned. I think its highly unlikely that someone will confuse the software and the

Re: [Openstack-operators] [neutron][ml2] Gutting ML2 from Neutron - possible?

On 04/01/2016 02:07 PM, Dan Sneddon wrote: > On 04/01/2016 01:07 PM, Adam Lawson wrote: >> The Contrail team that said they are using their network product with >> OpenStack without requiring a mechanism driver with the ML2 plugin. >> More specifically, they said they don't use or need ML2. I

Re: [Openstack-operators] [neutron][ml2] Gutting ML2 from Neutron - possible?

On 04/01/2016 01:07 PM, Adam Lawson wrote: > The Contrail team that said they are using their network product with > OpenStack without requiring a mechanism driver with the ML2 plugin. > More specifically, they said they don't use or need ML2. I didn't have > a chance to ask them to clarify so I'm

Re: [openstack-dev] [neutron]: Neutron naming legal issues

I vote for “Big Giant Pencil”. We can call it BGP for short. doug > On Apr 1, 2016, at 2:15 PM, Sean M. Collins wrote: > > I for one, have grown fond of "Mutnauq" while doing the DevStack neutron > re-write ;) > > > -- > Sean M. Collins > >

Re: [openstack-dev] [Ceilosca][Neutron][Monasca]

Hi Rubab, I'm not that knowledge on networking/neutron, and still in learn mode, but it sounds like it would be useful. This is an area that I am starting to get more involved with. There is a potential design summit session that Armando and I are looking into hosting on monitoring Neutron.

Re: [openstack-dev] [congress][release] missing build artifacts

Excerpts from Doug Hellmann's message of 2016-04-01 16:21:07 -0400: > Congress team, > > We noticed in our audit of the links on > http://releases.openstack.org/mitaka/index.html that the links to > the build artifacts for congress point to missing files. The > repository doesn't seem to have any

Re: [openstack-dev] [bifrost][ironic][release] missing build artifacts

Excerpts from Doug Hellmann's message of 2016-04-01 16:25:07 -0400: > Ironic/Bifrost team, > > We noticed in our audit of the links on > http://releases.openstack.org/mitaka/index.html that the links to > the build artifacts for bifrost point to missing files. The repository > doesn't seem to

Re: [openstack-dev] [sahara][release] missing build artifacts

Excerpts from Doug Hellmann's message of 2016-04-01 16:27:42 -0400: > Sahara team, > > We noticed in our audit of the links on > http://releases.openstack.org/mitaka/index.html that the links to > the build artifacts for sahara-extras point to missing files. The > repository doesn't seem to have

Re: [openstack-dev] [monasca][release] missing build artifacts

Excerpts from Hochmuth, Roland M's message of 2016-04-01 20:06:28 +: > Hi Doug, Sorry, this is our first release and we want to do the right thing. > > monasca-ceilometer is the code that plugs into the Ceilometer publisher and > Ceilometer storage driver to allow Ceilometer to send metrics

[openstack-dev] [sahara][release] missing build artifacts

Sahara team, We noticed in our audit of the links on http://releases.openstack.org/mitaka/index.html that the links to the build artifacts for sahara-extras point to missing files. The repository doesn't seem to have any real build jobs configured in

[openstack-dev] [bifrost][ironic][release] missing build artifacts

Ironic/Bifrost team, We noticed in our audit of the links on http://releases.openstack.org/mitaka/index.html that the links to the build artifacts for bifrost point to missing files. The repository doesn't seem to have any real build jobs configured in

[openstack-dev] [congress][release] missing build artifacts

Congress team, We noticed in our audit of the links on http://releases.openstack.org/mitaka/index.html that the links to the build artifacts for congress point to missing files. The repository doesn't seem to have any real build jobs configured in openstack-infra/project-config/zuul/layout.yaml,

Re: [openstack-dev] [neutron]: Neutron naming legal issues

I for one, have grown fond of "Mutnauq" while doing the DevStack neutron re-write ;) -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

[openstack-dev] Meeting time preferences for OSC team

Dear All, This is regarding deciding meeting time for OSC team to facilitate appropriate time for APAC guys. We are planning to have meeting on alternate weeks for this purpose. Some of the suggestions are: *E.1* Every two weeks (on even weeks) on Thursday at 1300 UTC in #openstack-meeting (IRC

Re: [openstack-dev] [monasca][release] missing build artifacts

Hi Doug, Sorry, this is our first release and we want to do the right thing. monasca-ceilometer is the code that plugs into the Ceilometer publisher and Ceilometer storage driver to allow Ceilometer to send metrics to the Monasca API and use Monasca as a storage backend. We don't create a pypi

Re: [openstack-dev] [release][requirements] global requirements master branch is unfrozen

I've cleaned up my votes as well. Thanks, Dims On Fri, Apr 1, 2016 at 2:20 PM, Doug Hellmann wrote: > Folks, > > The global requirements repo (openstack/requirements) is now open for > Newton-related changes. I've removed the -2 votes from all of the > patches I froze,

Re: [openstack-dev] [kolla][tc] [security] threat analysis, tags, and the road ahead

Graham, Responses inline. On 4/1/16, 8:50 AM, "Hayes, Graham" wrote: >>> On 3/31/16, 12:15 PM, "michael mccune" wrote: >>> > >>> one of the big questions seems to be who should be doing these analysis, especially given that the ossp

Re: [openstack-dev] [nova] the bugs team needs (more) members

Markus, If you van connect me with someone who can tell me what needs the most attention and how to get started, I'd be happy to help. //adam *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1

Re: [openstack-dev] [OpenStack-DefCore] [defcore][glance] Glare not defcore ready

Rochelle, thanks for replying. Glad to hear all the voices. Response inline. On 4/1/16 3:24 PM, Rochelle Grober wrote: > Hi folks. > > I'm chiming in here from a systems engineering perspective. I recently > discovered that OpenStack-client is trying to build cross-project consistency > into

[openstack-dev] [nova][scheduler] Next Meeting: Monday, April 4 @ 1400UTC

The next meeting for the Nova Scheduler sub-team is scheduled for Monday, April 4 at 1400 UTC. http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160404T14 The agenda is at https://wiki.openstack.org/wiki/Meetings/NovaScheduler - feel free to add items that need to be discussed to

[openstack-dev] [magnum] Split k8s-client in separate python package

Team, I've been meaning to do this for a while. Short version, see repo: https://github.com/dims/python-k8sclient/ Long version: - Started from the magnum repo. - pulled out just ./magnum/common/pythonk8sclient - preserved entire history in case we had to go back - reorganized directory

Re: [openstack-dev] [OpenStack-DefCore] [defcore][glance] Glare not defcore ready

Hi folks. I'm chiming in here from a systems engineering perspective. I recently discovered that OpenStack-client is trying to build cross-project consistency into its design. As such, it is opinionated, but this is good. The glance team might consider also consulting the OSC team to ensure

Re: [Openstack] OpenStack Liberty and Ryu

Hey there, Silvia, Have you had success configuring it? I'm trying to add Ryu in OpenStack Liberty, but not the Devstack. Mine is the packages installation. Thank you. Em seg, 25 de jan de 2016 às 14:16, Silvia Fichera escreveu: > Hi all, > I would like to try to use

[openstack-dev] [monasca][release] missing build artifacts

Monasca team, We noticed in our audit of the links on http://releases.openstack.org/mitaka/index.html that the links to the build artifacts for monasca-ceilometer, monasca-log-api, and monasca-thresh point to missing files. These repositories either don't seem to have any real build jobs

Re: [openstack-dev] [neutron]: Neutron naming legal issues

Wait... is this April's Fool? (hard to believe project name change resulting from name clashing with a Marvel comic character) On Fri, Apr 1, 2016 at 11:57 AM, Carl Baldwin wrote: > On Fri, Apr 1, 2016 at 2:24 AM, Ihar Hrachyshka > wrote: > > We could

[openstack-dev] [murano][release] missing build artifacts

Murano team, We noticed in our audit of the links on http://releases.openstack.org/mitaka/index.html that the links to the build artifacts for murano-apps point to missing files. The murano-apps repository doesn't seem to have any real build jobs configured in

[openstack-dev] Acknowledging Jim Blair's work on the TC

Jim is an incumbent on the TC this election and he didn't run. I'm posting this to express my thanks to Jim for his work and dedication on the TC. Jim, I think your commitment to open source, spanning many years before OpenStack, and your dedication to governance process, are qualities I admire

Re: [openstack-dev] [Neutron] Adding amuller to the neutron-drivers team

Welcome, Assaf! On Thu, Mar 31, 2016 at 6:48 PM, Armando M. wrote: > Hi folks, > > Assaf's tenacity is a great asset for the Neutron team at large. I believe > that the drivers team would benefit from that tenacity, and therefore I > would like to announce him to be a new

Re: [openstack-dev] Floating IPs and Public IPs are not equivalent

Sean, I can tell you how the configuration should work. Sean Collins and I have collaborated quite a bit on how to fix the DevStack networking problems... mostly by replacing the legacy neutron bits with something a bit more flexible and less crufty. On Fri, Apr 1, 2016 at 12:39 PM, Monty Taylor

Re: [openstack-dev] [neutron]: Neutron naming legal issues

On Fri, Apr 1, 2016 at 2:24 AM, Ihar Hrachyshka wrote: > We could play words, like Quantron or Neutrum. Actually, it makes perfect > sense to me, since the change to rename all project name references will be > half the size of the proposed solution, and may even save us some

[openstack-dev] [Fuel] Newton Design Summit sessions planning

Dear colleagues, Looks like we have final version sessions layout [1] for Austin design summit. We have 3 fishbows, 11 workrooms, full day meetup. Here you can find some useful information about design summit [2]. All session leads must read this page, be prepared for their sessions (agenda,

Re: [Openstack] [Fuel] How to configure Xen + Libvirt using Fuel 8.0

Hi Martin, I've never seen or heard of this before; do you have any more details or a bug on launchpad I can read? XenServer is used under openstack for hundreds of thousands of VM instances, so some configurations are definitely stable and don't suffer from the issue you saw. Were you - by

Re: [openstack-dev] Floating IPs and Public IPs are not equivalent

On 04/01/2016 12:00 PM, Fox, Kevin M wrote: And with external rbac in mitaka, you can finally have private floating ip's. :) Wha. I mean. My face. It just fell off. *From:* Monty Taylor *Sent:* Thursday, March 31, 2016

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

Hi, I didn't see this e-mail until now because I'm busy trying to update and test the installation guide in time for the Mitaka release. As a primary contributor to the installation guide for about six releases including restructuring it a couple of times, I think I can explain why we do what we

[openstack-dev] [release][requirements] global requirements master branch is unfrozen

Folks, The global requirements repo (openstack/requirements) is now open for Newton-related changes. I've removed the -2 votes from all of the patches I froze, but there may be some from other reviewers. Please contact them directly if your patch still has a procedural block, but keep in mind

Re: [openstack-dev] [docs] [api] Oh Swagger, where art thou?

On Fri, Apr 01, 2016 at 10:13:49AM -0500, Anne Gentle wrote: > On Thu, Mar 31, 2016 at 11:22 AM, Jim Rollenhagen > wrote: > > > On Thu, Mar 31, 2016 at 09:50:48AM -0400, Sean Dague wrote: > > > On 03/31/2016 09:43 AM, Jim Rollenhagen wrote: > > > > On Thu, Mar 31, 2016

[openstack-dev] Searching with the Summit Schdule App

My preference when consuming the schedule for the Design Summit is to see an entire project track in one view. I was unable to figure out how to accomplish this by clicking things on https://www.openstack.org/summit/austin-2016/summit-schedule/#day=2016-04-27_types=2 (the link ttx had provided for

Re: [openstack-dev] [nova] Which SSL ca_file does a person use, really?

On Fri, Apr 01, 2016 at 11:07:40AM -0500, Matt Riedemann wrote: > We have a lot of CA file options in nova: > > 1. DEFAULT.ca_file - this is used in nova.crypto > 2. ssl.ca_file - this is used when constructing glanceclient > 3. DEFAULT.ssl_ca_file - this is used in nova.wsgi > 4. vmware.ca_file

Re: [openstack-dev] [defcore][glance] Glare not defcore ready

Excellent! Thank you, Christopher, for supplementing by sharing the logs and the perspective. On 4/1/16 1:10 PM, Christopher Aedo wrote: > On Fri, Apr 1, 2016 at 8:02 AM, Flavio Percoco wrote: >> Greetings, >> >> I missed yday's Glance meeting but I went ahead and read the

Re: [openstack-dev] [defcore][glance] Glare not defcore ready

Thank you for your emails Flavio and Mike. It's really good to get a clarity out there. Hence, yes, the intent of the DefCore meeting was to get more "clarity" on the entire situation and making sure that the project proceeds with compliant standards. However, meetings can be informal and if

Re: [openstack-dev] [all] Newton Summit: cross-project session for deployment tools projects

An obvious +1 from me as well On Fri, Apr 1, 2016 at 10:25 AM Paul Belanger wrote: > On Thu, Mar 31, 2016 at 05:40:53PM -0400, Emilien Macchi wrote: > > Hi, > > > > OpenStack big tent has different projects for deployments: Puppet, > > Chef, Ansible, Kolla, TripleO, (...)

Re: [openstack-dev] [defcore][glance] Glare not defcore ready

On 01/04/16 20:03 +0300, Mikhail Fedosin wrote: Hi Flavio! Thank you for the clarification. I do realize that I missed both meetings and that logs from one of them are not complete. I apologize if I've misinterpreted the intentions here. I do think engaiging with DefCore as

Re: [openstack-dev] [defcore][glance] Glare not defcore ready

On 01/04/16 10:10 -0700, Christopher Aedo wrote: On Fri, Apr 1, 2016 at 8:02 AM, Flavio Percoco wrote: Greetings, I missed yday's Glance meeting but I went ahead and read the logs. While I was at it, I read a sentence from Erno (under the Glare updates topic) that caught my

Re: [openstack-dev] [all] Newton Summit: cross-project session for deployment tools projects

On Thu, Mar 31, 2016 at 05:40:53PM -0400, Emilien Macchi wrote: > Hi, > > OpenStack big tent has different projects for deployments: Puppet, > Chef, Ansible, Kolla, TripleO, (...) but we still have some topics in > common. > I propose we use the Cross-project day to meet and talk about our >

Re: [openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

Hi Alex +1 to your proposal - this is long-awaited change. On Fri, Apr 1, 2016 at 6:01 PM, Aleksandr Didenko wrote: > One more thing about spec to fixture mapping [0]. What if instead of: > > # RUN: (hiera1) (facts1) > > we'll use > > # RUN: (roles_array1) (facts1) > > ?

Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

Params have the added advantage that horizon could be potentially tweaked to do form validation in the ui based in it. Thanks, Kevin From: Steven Hardy Sent: Friday, April 01, 2016 9:31:45 AM To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [defcore][glance] Glare not defcore ready

On Fri, Apr 1, 2016 at 8:02 AM, Flavio Percoco wrote: > Greetings, > > I missed yday's Glance meeting but I went ahead and read the logs. While I > was > at it, I read a sentence from Erno (under the Glare updates topic) that > caught > my eye: > > 14:06:27 About that.

Re: [openstack-dev] [defcore][glance] Glare not defcore ready

Hi Flavio! Thank you for the clarification. I do realize that I missed both meetings and that logs from one of them are > not > complete. I apologize if I've misinterpreted the intentions here. I do > think > engaiging with DefCore as early in the process as possible is good but I'd > also > like

Re: [Openstack] [Fuel] How to configure Xen + Libvirt using Fuel 8.0

XenServer is fully open source - XCP is no longer. You can download XenServer for free from www.XenServer.org without any contact with Citrix. For libvirt+Xen AFAIK that plugin doesn't exist and you would need to manually configure each compute node after installation. The XenServer plugin

Re: [openstack-dev] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

On 04/01/2016 09:39 AM, Sean Dague wrote: On 04/01/2016 10:35 AM, Monty Taylor wrote: On 04/01/2016 09:16 AM, Sean Dague wrote: On 04/01/2016 10:08 AM, Monty Taylor wrote: On 04/01/2016 08:45 AM, Sean Dague wrote: The glance v2 work is currently blocked as there is no active spec, would be

Re: [openstack-dev] Floating IPs and Public IPs are not equivalent

And with external rbac in mitaka, you can finally have private floating ip's. :) Thanks, Kevin From: Monty Taylor Sent: Thursday, March 31, 2016 10:23:22 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] Floating IPs and

Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

Why is imperative programming always brought up when discussing conditionals in the templates? We are not wanting anything imperative. The heat engine still picks the final ordering of things. We just want to give it all the valid options, and then enough knowledge to eliminate unacceptlable

[Openstack-operators] OpenStack Developer Mailing List Digest March 26 – April 1

HTML version: http://www.openstack.org/blog/2016/04/openstack-developer-mailing-list-digest-20160401/ SuccessBot Says === * Tonyb: Dims fixed the Routes 2.3 API break :) * pabelanger: migration from devstack-trusty to ubuntu-trusty complete! * Tell us yours via IRC with a message

[openstack-dev] OpenStack Developer Mailing List Digest March 26 – April 1

HTML version: http://www.openstack.org/blog/2016/04/openstack-developer-mailing-list-digest-20160401/ SuccessBot Says === * Tonyb: Dims fixed the Routes 2.3 API break :) * pabelanger: migration from devstack-trusty to ubuntu-trusty complete! * Tell us yours via IRC with a message

Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

On Fri, Apr 01, 2016 at 04:15:30PM +0200, Thomas Herve wrote: > On Fri, Apr 1, 2016 at 3:21 AM, Zane Bitter wrote: > > On 31/03/16 18:10, Zane Bitter wrote: > >> > >> > >> I'm in favour of some sort of variable-based implementation for a few > >> reasons. One is that (5) seems

Re: [openstack-dev] [nova] Which SSL ca_file does a person use, really?

On 4/1/2016 11:07 AM, Matt Riedemann wrote: We have a lot of CA file options in nova: 1. DEFAULT.ca_file - this is used in nova.crypto 2. ssl.ca_file - this is used when constructing glanceclient 3. DEFAULT.ssl_ca_file - this is used in nova.wsgi 4. vmware.ca_file - for connecting to vcenter

[openstack-dev] [nova] Which SSL ca_file does a person use, really?

We have a lot of CA file options in nova: 1. DEFAULT.ca_file - this is used in nova.crypto 2. ssl.ca_file - this is used when constructing glanceclient 3. DEFAULT.ssl_ca_file - this is used in nova.wsgi 4. vmware.ca_file - for connecting to vcenter 5. neutron.cafile - for constructing

[openstack-dev] Announcement of new bandit-security-check gate

Dear colleagues, we want to announce new gate bandit-security-check. The gate will be applied to such projects: openstack/fuel-web openstack/fuel-agent openstack/fuel-mirror openstack/fuel-ostf openstack/shotgun It will work in non voting mode. The bandit documentation can be found here

Re: [openstack-dev] [Glance] Newton virtual pre-summit sync

Tuesday, April 12 1400-1800 UTC works for me, I will attend. On 3/31/16, 5:34 PM, "Nikhil Komawar" wrote: >Hi all, > >I'm excited to see you all Glancers at the Austin summit and discuss >more on our project. > >Nevertheless, I feel that our summit conversations will have

Re: [openstack-dev] [neutron]: Neutron naming legal issues

BTW. This is my proposal design for this summit t-shirts: Yes, I run overcomplicated virtual networking in my Cloud nova-network quantum neutron nova-network ... neutron quantum of course, after a few changes! From: "Armando M." > Reply-To:

Re: [openstack-dev] [nova][neutron] What to do about booting into port_security_enabled=False networks?

On 3/31/2016 8:42 AM, Sahid Orentino Ferdjaoui wrote: On Wed, Mar 30, 2016 at 09:46:45PM -0500, Matt Riedemann wrote: On 3/30/2016 5:55 PM, Armando M. wrote: On 29 March 2016 at 18:55, Matt Riedemann > wrote: On

Re: [openstack-dev] [neutron]: Neutron naming legal issues

Let’s keep the name and wait for the movie where we all become the bad guys! Edgar On 3/31/16, 10:46 PM, "Jimmy Akin" wrote: > >Dear Neutrinos, > >We've been following the project for quite some time. >To our satisfaction the project seems to have done well; the base

Re: [openstack-dev] [kolla][tc] [security] threat analysis, tags, and the road ahead

>> On 3/31/16, 12:15 PM, "michael mccune" wrote: >> >>> >>> >>> one of the big questions seems to be who should be doing these analysis, >>> especially given that the ossp has not formally codified the practice >>> yet, and the complexity involved. although currently the >>>

Re: [openstack-dev] [neutron]: Neutron naming legal issues

Jim,  Did you verify with Marvel if it's possible to keep the name and use his hero. In that way we could be the first OpenStack project to have one. Victor Morales On Fri, 2016-04-01 at 08:46 +0300, Jimmy Akin wrote: > Dear Neutrinos, > > We've been following the project for quite some time.

Re: [openstack-dev] [All][Neutron] Improving development and review velocity - Is it time for a drastic change?

Le 01/04/2016 03:12, Assaf Muller a écrit : 2) Now, transform yourself six to twelve months in the future. We now face a new problem. (...) I hereby propose that we remove the tests. (...) Needless to say, my proposal keeps pep8 in place. We all know how important a consistent style is. The

Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

On 01/04/16 10:15, Thomas Herve wrote: On Fri, Apr 1, 2016 at 3:21 AM, Zane Bitter wrote: On 31/03/16 18:10, Zane Bitter wrote: I'm in favour of some sort of variable-based implementation for a few reasons. One is that (5) seems to come up fairly regularly in a complex

Re: [openstack-dev] [Glance] Newton virtual pre-summit sync

Matt, thanks for sending the update! My comments inline. On 4/1/16 10:54 AM, Matt Riedemann wrote: > > > On 4/1/2016 7:56 AM, Flavio Percoco wrote: >> On 31/03/16 17:34 -0400, Nikhil Komawar wrote: >>> Hi all, >>> >>> I'm excited to see you all Glancers at the Austin summit and discuss >>> more

Re: [openstack-dev] [docs] [api] Oh Swagger, where art thou?

On Thu, Mar 31, 2016 at 11:22 AM, Jim Rollenhagen wrote: > On Thu, Mar 31, 2016 at 09:50:48AM -0400, Sean Dague wrote: > > On 03/31/2016 09:43 AM, Jim Rollenhagen wrote: > > > On Thu, Mar 31, 2016 at 08:43:29AM -0400, Sean Dague wrote: > > >> Some more details on

[openstack-dev] [defcore][glance] Glare not defcore ready

Greetings, I missed yday's Glance meeting but I went ahead and read the logs. While I was at it, I read a sentence from Erno (under the Glare updates topic) that caught my eye: 14:06:27 About that. I got couple of pings last night asking wtf is going on. Could we please stop

Re: [openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

One more thing about spec to fixture mapping [0]. What if instead of: # RUN: (hiera1) (facts1) we'll use # RUN: (roles_array1) (facts1) ? We don't need to duplicate complicated task graph calculations to understand which task to execute, because we don't care about tasks ordering and

Re: [openstack-dev] [Glance] Newton virtual pre-summit sync

On 4/1/2016 7:56 AM, Flavio Percoco wrote: On 31/03/16 17:34 -0400, Nikhil Komawar wrote: Hi all, I'm excited to see you all Glancers at the Austin summit and discuss more on our project. Nevertheless, I feel that our summit conversations will have a lot more value if we establish some

Re: [openstack-dev] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

On 04/01/2016 10:35 AM, Monty Taylor wrote: > On 04/01/2016 09:16 AM, Sean Dague wrote: >> On 04/01/2016 10:08 AM, Monty Taylor wrote: >>> On 04/01/2016 08:45 AM, Sean Dague wrote: The glance v2 work is currently blocked as there is no active spec, would be great if someone from the

Re: [openstack-dev] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

On 04/01/2016 09:16 AM, Sean Dague wrote: On 04/01/2016 10:08 AM, Monty Taylor wrote: On 04/01/2016 08:45 AM, Sean Dague wrote: The glance v2 work is currently blocked as there is no active spec, would be great if someone from the glance team could get that rolling again. I started digging

[openstack-dev] [neutron][stable] RDO needs stable/mitaka branches for subprojects WAS: Re: [Rdo-list] RDO Mitaka RC1 current status - testers requested

Haïkel wrote: 2016-04-01 16:17 GMT+02:00 Ihar Hrachyshka : Haïkel wrote: Do we want to raise those issues to networking vendors? Do we have a list of what’s required from them for RDO? Ihar Yes, we need to

Re: [openstack-dev] [kolla][tc] [security] threat analysis, tags, and the road ahead

Thanks Steve, Mike, We’ve had a lot more traction with this latest incarnation of TA. I’m very much looking forward to working through the process with the wider community. -Rob On 31/03/2016 20:44, "Steven Dake (stdake)" wrote: >Including tc and kolla > >Michael, >

Re: [openstack-dev] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

On 04/01/2016 10:08 AM, Monty Taylor wrote: > On 04/01/2016 08:45 AM, Sean Dague wrote: >> The glance v2 work is currently blocked as there is no active spec, >> would be great if someone from the glance team could get that rolling >> again. >> >> I started digging back through the patches in

Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

On Fri, Apr 1, 2016 at 3:21 AM, Zane Bitter wrote: > On 31/03/16 18:10, Zane Bitter wrote: >> >> >> I'm in favour of some sort of variable-based implementation for a few >> reasons. One is that (5) seems to come up fairly regularly in a complex >> deployment like TripleO.

Re: [openstack-dev] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

On 04/01/2016 08:45 AM, Sean Dague wrote: The glance v2 work is currently blocked as there is no active spec, would be great if someone from the glance team could get that rolling again. I started digging back through the patches in detail to figure out if there are some infrastructure bits we

[openstack-dev] [Fuel][library] Update of astute.yaml fixtures and noop tests

Hi. As you may know, we're still using some very old astute.yaml fixtures (v6.1) in our 'master' (v9.0) noop rspec tests [0]. Besides that, we have problems with fixture-to-rspec mapping [1]. So we've started to work on those problems [2]. So please be aware of upcoming changes in noop rspec

[openstack-dev] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

The glance v2 work is currently blocked as there is no active spec, would be great if someone from the glance team could get that rolling again. I started digging back through the patches in detail to figure out if there are some infrastructure bits we could get in early regardless. #1 - new

  1   2   >