Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

Juno Whatever gets it done faster- let me get the three repos aligned. I need to get the ovs/ovn work done so networking-ovn can call it, and the networking-sfc can call networking-ovn. Hopefully I will have it done tomorrow or over the weekend - let's touch base Monday or Sunday night.

[openstack-dev] What's Up, Doc? 3 June 2016

Hi everyone, I'm very pleased to be able to announce the results of our Install Guide naming poll this week. We ended up with 31 responses, and a very clear winner in "OpenStack Installation Tutorial". Thank you to everyone who voted! Also, just a note that I'm still very much in need of

[openstack-dev] [Infra][tricircle] patch not able to be merged

Hello, There is one quite strange issue in Tricircle stable/mitaka branch (https://github.com/openstack/tricircle/tree/stable/mitaka) . Even the patch ( https://review.openstack.org/#/c/324209/ ) were given Code-Review +2 and Workflow +1, the gating job not started, and the patch was not

Re: [openstack-dev] [horizon] new stable-maint cores for Horizon

On Thu, Jun 02, 2016 at 08:27:29AM +0200, Matthias Runge wrote: > Horizoners, > > please join me to welcome > > * Richard Jones > * Rob Cresswell > * Thai Tran > > as new Horizon stable core reviewers. > > Thank you guys for stepping up and thank you tonyb for pulling stats and > pushing this.

[openstack-dev] openstack Unauthorized HTTP 401 'Could not find user' when sahara call heat

Hi, Friends, I used Openstack-Juno heat, keystone and Mitaka sahara in CentOS7. Sahara is installed in docker container using host network. When sahara wants to call heat to create a hadoop cluster, the below error is happened. Could you help to check this issue? I guess, the heat

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

Hi John, I agree with submitting WIP patches to community, because you already did many works on networking-sfc and networking-ovn, it is better that you submit the initial patches about networking-sfc and networking-ovn, then me and Srilatha take over the patches. Do you have time to do it?

[openstack-dev] [kolla] Google Hangouts discussion for dueling specifications for Dockerfile customization

Hey folks, IRC and mailing list were going far too slow for us to make progress on the competing specifications for handling Dockerfile customization. Instead we held a hangout, which I don't like because it isn't recorded, but it is high bandwidth and permitted us to work through the problem

[openstack-dev] [nova][SR-IOV/PCI] SR-IOV/PCI CI for mutli node

Hi, As part of the Performance VMs CI and technical debt session we had in Ausin summit, we decide to focus on fixing pci resize and migration bugs. Currently the pci resize patch [1] and migration patch [2] are up for review. The resize patch is tested with Intel PCI CI

[openstack-dev] [tc][security] Item #5 of the VMT

Hi folks, I think we are nearly done with Item #5 [1] of the VMT. One question remains. We need to know which repo the analysis documentation will land in . There is security-doc we could use for this purpose, but we could also create a new repository called "security-analysis" (or open to

Re: [openstack-dev] [keystone] Changing the project name uniqueness constraint

On 06/02/2016 07:22 PM, Henry Nash wrote: Hi As you know, I have been working on specs that change the way we handle the uniqueness of project names in Newton. The goal of this is to better support project hierarchies, which as they stand today are restrictive in that all project names

Re: [openstack-dev] [magnum] Discuss the idea of manually managing the bay nodes

As an operator that has clouds that are partitioned into different host aggregates with different flavors targeting them, I totally believe we will have users that want to have a single k8s cluster span multiple different flavor types. I'm sure once I deploy magnum, I will want it too. You

Re: [openstack-dev] [magnum] Discuss the idea of manually managing the bay nodes

Hongbin, Have you considered a workflow engine? FWIW I agree with Adrian about the difficulties of heterogenous systems. Much better to operate, and in reality the world has moved entirely to x86_64 + Linux. I could see a future in which ARM breaks into the server space, but that is multiple

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

On Thu, Jun 02, 2016 at 08:41:40AM -0700, John Dickinson wrote: > open swift/swiftclient patches to stable/kilo have been abandoned Thanks John Tony. signature.asc Description: PGP signature __ OpenStack Development

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

On Thu, Jun 02, 2016 at 07:10:23PM -0400, Emilien Macchi wrote: > I think that all openstack/puppet-* projects that have stable/kilo can > be kilo-EOLed. > Let me know if it's ok and I'll abandon all open reviews. Totally fine with me. I've added them. Feel free to abanond the reviews. Any

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

On Thu, Jun 02, 2016 at 12:38:15PM +0200, Ihar Hrachyshka wrote: > I think all networking-* repos should EOL too, since they are plugins to > neutron which is already EOL. I struggle to find a way that could maintain > their gate without neutron. Thanks I've added them. Yours Tony.

Re: [openstack-dev] [magnum] Discuss the idea of manually managing the bay nodes

I am really struggling to accept the idea of heterogeneous clusters. My experience causes me to question whether a heterogeneus cluster makes sense for Magnum. I will try to explain why I have this hesitation: 1) If you have a heterogeneous cluster, it suggests that you are using external

[openstack-dev] [keystone] Changing the project name uniqueness constraint

Hi As you know, I have been working on specs that change the way we handle the uniqueness of project names in Newton. The goal of this is to better support project hierarchies, which as they stand today are restrictive in that all project names within a domain must be unique, irrespective of

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

On Thu, Jun 2, 2016 at 6:31 AM, Tony Breeds wrote: > Hi all, > In early May we tagged/EOL'd several (13) projects. We'd like to do a > final round for a more complete set. We looked for projects meet one or more > of the following criteria: > - The project is

[openstack-dev] [octavia] enabling new topologies

Stephen, Michael, thank you for having a look. I'll respond to every issue you mentioned when I get to work on Sunday. Until then, in case you don't mind inspecting a small diff, just to clarify my point, please have a look at a rather straightforward change, which 1. exemplifies pretty much

Re: [openstack-dev] [magnum][lbaas] Operator-facing installation guide

Brandon, Magnum uses neutron’s LBaaS service to allow for multi-master bays. We can balance connections between multiple kubernetes masters, for example. It’s not needed for single master bays, which are much more common. We have a blueprint that is in design stage for de-coupling magnum from

Re: [openstack-dev] [Kolla] About kolla-ansible reconfigure

Hu, Reconfigure was not designed to handle changes to globals.yml. I think its a good goal that it should be able to do so, but it does not today. Reconfigure was designed to handle changes to /etc/kolla/config/* (where custom config for services live). Reconfigure in its current incarnation

Re: [openstack-dev] [Ironic] Changes to Ramdisk and iPXE defaults in Devstack and many gate jobs

These changes have all merged and taken effect. Ironic and IPA gate jobs are now operating as mentioned below, with one change; during review it was decided to lower the amount of ram per node to 384mb instead of 512mb of RAM. This will ensure that we don't add additional bloat to TinyIPA

[openstack-dev] [Ironic] Completed: Move to TinyIPA Ramdisk and iPXE defaults in gate jobs

These changes have all merged and taken effect. Ironic and IPA gate jobs are now operating as mentioned below, with one change; during review it was decided to lower the amount of ram per node to 384mb instead of 512mb of RAM. This will ensure that we don't add additional bloat to TinyIPA

Re: [openstack-dev] [magnum][lbaas] Operator-facing installation guide

Call me ignorance, but I'm surprised at neutron-lbaas being a dependency of magnum. Why is this? Sorry if it has been asked before and I've just missed that answer? Thanks, Brandon On Wed, 2016-06-01 at 14:39 +, Hongbin Lu wrote: > Hi lbaas team, > > > > I wonder if there is an

[openstack-dev] [Manila] v1 API and nova-net support removal in newton

We have made the decision to remove the v1 API from Manila in Newton (it was deprecated in Mitaka). Only v2.0+ will be supported. For those that don't know, v2.0 is exactly the same as v1 but it has microversion support. You need a client library from Liberty or Mitaka to get microversion

[openstack-dev] [Manila] Newton deadlines (reminder)

At the start of the Newton release we agreed to keep the same deadlines we had for Mitaka. I thought everyone knew what those were but there is some confusion so I'll remind everyone. As always, we will enforce a Feature Freeze on the N-3 milestone date: September 1st [1]. Only bugfixes and

Re: [openstack-dev] [ironic] versioning of IPA, it is time or is it?

2 июня 2016 г. 10:19 PM пользователь "Loo, Ruby" написал: > > Hi, > > I recently reviewed a patch [1] that is trying to address an issue with ironic (master) talking to a ramdisk that has a mitaka IPA lurking around. > > It made me think that IPA may no longer be a teenager

[openstack-dev] [Manila] Midcycle meetup

As of now we're planning to hold our midcycle meetup in virtually on June 28, 29, and possibly June 30 (depending on agenda). If any core reviewers or significant contributors can't attend those days please let me know. Also if anyone wants to travel to RTP to join those of us based here I

Re: [openstack-dev] [neutron][upgrades] Bi-weekly upgrades work status. 6/2/2016

Thanks Artur for this summarize. > On Jun 2, 2016, at 3:29 PM, Korzeniewski, Artur > wrote: > > Hi Neutrinos, > I would like to start the first bi-weekly upgrades work report. > > TLDR: > In order to inform community what is going on in upgrades field, we would

[openstack-dev] [neutron][upgrades] Bi-weekly upgrades work status. 6/2/2016

Hi Neutrinos, I would like to start the first bi-weekly upgrades work report. TLDR: In order to inform community what is going on in upgrades field, we would like to start bi-weekly reporting. We would like to show progress in database resource transition to Oslo VersionedObjects. Also list

[openstack-dev] [ironic] versioning of IPA, it is time or is it?

Hi, I recently reviewed a patch [1] that is trying to address an issue with ironic (master) talking to a ramdisk that has a mitaka IPA lurking around. It made me think that IPA may no longer be a teenager (yay, boo). IPA now has a stable branch. I think it is time it grows up and acts

Re: [openstack-dev] [octavia] enabling new topologies

Hi Sergey, Welcome to working on Octavia! I'm not sure I fully understand your proposals, but I can give my thoughts/opinion on the challenge for Active/Active. In general I agree with Stephen. The intention of using TaskFlow is to facilitate code reuse across similar but different code flows.

Re: [openstack-dev] [octavia] is l7 rule using routed L3 connectivity

I agree that if this occurred it is a bug. Please open a bug for us in launchpad and include your controller worker logs and amphora-agent log from the impacted amphora. Thanks, Michael On Wed, Jun 1, 2016 at 9:55 AM, Stephen Balukoff wrote: > Hello Yong Sheng Gong! > >

Re: [openstack-dev] [magnum] Discuss the idea of manually managing the bay nodes

Has an email been posted to the [heat] community for their input? Maybe I missed it. Thanks, -Keith On 6/2/16, 9:42 AM, "Hongbin Lu" wrote: >Madhuri, > >It looks both of us agree the idea of having heterogeneous set of nodes. >For the implementation, I am open to

Re: [openstack-dev] [freezer] Addition to the core team

+1 Sent from my Samsung device Original message From: "Ramirez Garcia, Guillermo" Date: 02/06/2016 17:40 (GMT+01:00) To: "Mathieu, Pierre-Arthur" , openstack-dev@lists.openstack.org Cc:

Re: [openstack-dev] [qa] [Tempest] Abondoned old code reviews

Thanks for feedback here. There are not any objections, so I will drop old code reviews on Tempest queue. Thanks Ken Ohmichi --- 2016-05-31 23:55 GMT-07:00 Masayuki Igawa : > On Wed, Jun 1, 2016 at 3:05 AM, Andrea Frittoli > wrote: >> On

Re: [openstack-dev] [congress] Spec for congress.conf

Bryan, I spent some time looking into the proper way to document configuration options in OpenStack. There's a configuration reference that's part of the openstack-manuals project. It'll take some time to figure out the best way of contributing to that. But for now I added a section to our

Re: [openstack-dev] [nova] API changes on limit / marker / sort in Newton

On 06/02/2016 12:53 PM, Everett Toews wrote: > >> On Jun 1, 2016, at 2:01 PM, Matt Riedemann >> wrote: >> >> Agree with Sean, I'd prefer separate microversions since it makes getting >> these in easier since they are easier to review (and remember we make >>

Re: [openstack-dev] [nova] [scheduler] New filter: AggregateInstanceAffinityFilter

> -Original Message- > From: Alonso Hernandez, Rodolfo > [mailto:rodolfo.alonso.hernan...@intel.com] > Sent: Thursday, June 2, 2016 6:00 PM > To: OpenStack Development Mailing List (not for usage questions) > > Subject: [openstack-dev] [nova]

Re: [openstack-dev] [keystone][security] Service User Permissions

> On Jun 2, 2016, at 10:58 AM, Adam Young wrote: > > Any senseible RBAC setup would support this, but we are not using a sensible > one, we are using a hand rolled one. Replacing everything with Fortress > implies a complete rewrite of what we do now. Nuke it from orbit

[openstack-dev] [nova] [scheduler] New filter: AggregateInstanceAffinityFilter

Hello: For the last two cycles we have tried to introduce a new filter to be able to interact better with the aggregates, using the metadata to accept or reject an instance depending on the flavor: https://review.openstack.org/#/c/189279/ This filter was reverted and we agreed to

Re: [openstack-dev] [nova] API changes on limit / marker / sort in Newton

> On Jun 1, 2016, at 2:01 PM, Matt Riedemann wrote: > > Agree with Sean, I'd prefer separate microversions since it makes getting > these in easier since they are easier to review (and remember we make changes > to python-novaclient for each of these also). > >

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

John McDowall wrote on 06/02/2016 11:03:28 AM: > From: John McDowall > To: Ryan Moats/Omaha/IBM@IBMUS > Cc: Ben Pfaff , "disc...@openvswitch.org" > , Justin Pettit , >

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

Greetings OpenStack community, This week there are no new merged guidelines nor guidelines proposed for freeze but there is a new guideline discussing ways to ensure that URIs are semantically consistent: https://review.openstack.org/#/c/322194/ # Recently merged guidelines These guidelines

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

Juno, Sure make sense. I will have ovs/ovn in rough shape by end of week (hopefully) that will allow you to call the interfaces from networking-ovn. Ryan has asked that we submit WIP patches etc so hopefully that will kickstart the review process. Also, hopefully some of the networking-sfc

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

Ryan, Sure - may need some help and it will probably be next week before I get to it. Regards John From: Ryan Moats > Date: Wednesday, June 1, 2016 at 1:25 PM To: John McDowall >

Re: [openstack-dev] [keystone][security] Service User Permissions

On 06/02/2016 11:36 AM, Shawn McKinney wrote: On Jun 2, 2016, at 10:03 AM, Adam Young wrote: To do all of this right, however, requires a degree of introspection that we do not have in OpenStack. Trove needs to ask Nova "I want to do X, what role do I need?" and there is

Re: [openstack-dev] [Monasca][Gnocchi] influxDB clustering and HA will be "commercial option".

Has anyone talked with the gnocchi folks? It seems like a good time to. :) Thanks, Kevin From: Jay Pipes [jaypi...@gmail.com] Sent: Thursday, June 02, 2016 4:55 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Monasca] influxDB

Re: [openstack-dev] [freezer] Addition to the core team

+1 -Original Message- From: Mathieu, Pierre-Arthur Sent: Thursday 2 June 2016 16:29 To: openstack-dev@lists.openstack.org Cc: freezer-eskimos Subject: [openstack-dev][freezer] Addition to the core team Hello, I would like to propose that we make

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

open swift/swiftclient patches to stable/kilo have been abandoned --John On 2 Jun 2016, at 4:45, Jesse Pretorius wrote: > Hi Tony, > > OpenStack-Ansible is just waiting for the requirements repository and the > swift repository kilo-eol tags. Once they're done we'd like to bump the > SHA's

[openstack-dev] [networking-sfc] how to install networking-sfc on compute node

Hi, >From this link https://github.com/openstack/networking-sfc/tree/master/devstack, it is about installing networking-sfc together with neutron-server, I want to install networking-sfc on compute node, can anyone tell me how to set the local.conf? Regards, Juno Zhu IBM China Development

Re: [openstack-dev] Collecting our wiki use cases

On 06/02/2016 10:59 AM, Thierry Carrez wrote: > Thanks to everyone who helped collecting wiki use cases on that etherpad. > > I tried to categorize the various use cases and I think they fit in 4 > categories: > > 1/ Things that are already in the process of being moved to reference > websites

Re: [openstack-dev] [freezer] Addition to the core team

Small correction for the final line of the last email. I am proposing Deklan and not Saad as core. - Pierre From: Mathieu, Pierre-Arthur Sent: Thursday, June 2, 2016 4:29:29 PM To: openstack-dev@lists.openstack.org Cc: freezer-eskimos Subject:

Re: [openstack-dev] [keystone][security] Service User Permissions

> On Jun 2, 2016, at 10:03 AM, Adam Young wrote: > > To do all of this right, however, requires a degree of introspection that we > do not have in OpenStack. Trove needs to ask Nova "I want to do X, what role > do I need?" and there is no where in the system today that

Re: [openstack-dev] [Nova] State machines in Nova

On 01/06/16 13:50, Andrew Laski wrote: This is a great point. I think most people have an implicit assumption that the state machine will be exposed to end users via the API. I would like to avoid that for exactly the reason you've mentioned. Of course we'll want to expose something to users but

[openstack-dev] [freezer] Addition to the core team

Hello, I would like to propose that we make Deklan Dieterly (ddieterly) core on freezer. He has been a highly valuable developper for the past few month, mainly working on integration testing for Freezer components. He has also been helping a lot with features and Ux testing. His work can be

Re: [openstack-dev] [neutron][dvr] Wasting so many external network IPs in DVR mode?

On Thu, Jun 2, 2016 at 12:04 AM, zhi wrote: > The reason putting the routers namespaces behind the fip namespace is > saving mac address tables in switches. In Centralized Virtual Router, there > are many "qg" interfaces in the external bridge. Every "qg" interface

Re: [openstack-dev] [magnum] Discuss the idea of manually managing the bay nodes

Hongbin, for the implementation of heterogeneous, I think we should avoid to talking with nova or other service directly, which will bring lots of coding. maybe the best way is to refactor our heat template, and let a bay support several heat template when we scale-out new node or delete

Re: [openstack-dev] [keystone][security] Service User Permissions

On 06/02/2016 01:23 AM, Jamie Lennox wrote: Hi All, I'd like to bring to the attention of the wider security groups and OpenStack users the Service Users Permissions [1] spec currently proposed against keystonemiddleware. To summarize quickly OpenStack has long had the problem of token

Re: [openstack-dev] Collecting our wiki use cases

Thanks to everyone who helped collecting wiki use cases on that etherpad. I tried to categorize the various use cases and I think they fit in 4 categories: 1/ Things that are already in the process of being moved to reference websites or documentation That would be the main "portal" page

[openstack-dev] [Fuel] [Fuel-Astute] Core reviewers changes

Hi all, Evgeny Li, one of two core reviewers of fuel-astute project [1], could not participate on this project anymore because of his high load on another project. I want to express my sincere gratitude for his help and great advices and wish good luck in his new project. For safe and better

[openstack-dev] [new][openstack] os-client-config 1.18.0 release (newton)

We are psyched to announce the release of: os-client-config 1.18.0: OpenStack Client Configuation Library This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/os-client-config With package available at:

Re: [openstack-dev] [magnum] Discuss the idea of manually managing the bay nodes

Madhuri, It looks both of us agree the idea of having heterogeneous set of nodes. For the implementation, I am open to alternative (I supported the work-around idea because I cannot think of a feasible implementation by purely using Heat, unless Heat support "for" logic which is very unlikely

Re: [openstack-dev] [TripleO][diskimage-builder] Proposing Stephane Miller to dib-core

Excerpts from Gregory Haynes's message of 2016-06-01 12:50:19 -0500: > Hello everyone, > > I'd like to propose adding Stephane Miller (cinerama) to the > diskimage-builder core team. She has been a huge help with our reviews > for some time now and I think she would make a great addition to our >

[openstack-dev] [neutron][stable] stable/liberty in phase II

Hi neutron-stable-maint members, yesterday we released neutron 7.1.0 tarballs. Those tarballs are the last ones that allowed patches that did not fulfil requirements of Phase II: "Phase II (6-12 months): Only critical bugfixes and security patches are acceptable” [1] For Neutron’s sake, at

[openstack-dev] [release] [infra] Conflict between publishing jobs

Hi, While importing Panko¹ into OpenStack, Andreas informed me that the jobs "openstack-server-release-jobs" and "publish-to-pypi" were incompatible and that the release team would know that. We actually want to publish Panko as an OpenStack server and also to PyPI. We already have both these

[openstack-dev] [manila]: questions on update-access() changes

Hi, There are a few changes that seem to be lined up for Newton to make manila's share access control, update_access(), workflow better [1] -- reduce races in DB updates, avoid non-atomic state transitions, and possibly enable the workflow fit in a HA active-active manila configuration (if not

Re: [openstack-dev] [kolla] prototype of a DSL for generating Dockerfiles

Looking at some of the capabilities jinja2 has, it's hard to justify changing the method already in place. I think jinja2 can provide a clear and operational way for operators to customize the dockerfiles as needed. Kolla just hasn't applied them yet. I'm extremely hesitant to agree on changing

Re: [openstack-dev] [Nova] State machines in Nova

> -Original Message- > From: Monty Taylor [mailto:mord...@inaugust.com] > Sent: 01 June 2016 13:54 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Nova] State machines in Nova > > On 06/01/2016 03:50 PM, Andrew Laski wrote: > > > > > > On Wed, Jun 1, 2016, at

Re: [openstack-dev] [tc] [heat] [murano] [app-catalog] OpenStack Apps Community, several suggestions how to improve collaboration

On 2016-06-02 11:08:14 +0300 (+0300), Sergey Kraynev wrote: [...] > I am happy to hear, that you don't mind about it. We suppose, that > the number of such repositories should not be more then 10. > Probably the number will be about 5-10 repos. I suppose, that it's > extremely big number. [...]

[openstack-dev] [cue] Removing the Cue project team from OpenStack official projects

Hi there, Due to obvious inactivity I proposed the removal of the Cue project team from the "Big Tent" list of official OpenStack projects under Technical Committee governance: https://review.openstack.org/324412 Please comment on that review if you think it's the wrong call. -- Thierry

Re: [openstack-dev] Gerrit downtime on Friday 2016-06-03 at 20:00 UTC

On Mon, May 23, 2016 at 10:58 AM, Elizabeth K. Joseph wrote: > Hi everyone, > > On Friday, June 3, from approximately 20:00 through 24:00 UTC Gerrit > will be unavailable while we rename some projects. > > Currently, we plan on renaming the following projects: > >

Re: [openstack-dev] [Monasca] influxDB clustering and HA will be "commercial option".

On 06/02/2016 04:02 AM, Monty Taylor wrote: On 06/02/2016 10:06 AM, Hochmuth, Roland M wrote: Hi Jaesuk, The change in InfluxDB licensing was announced in the blog at, https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/. Up until that announcement,

Re: [openstack-dev] [Monasca] influxDB clustering and HA will be "commercial option".

On 06/02/2016 04:02 AM, Monty Taylor wrote: On 06/02/2016 10:06 AM, Hochmuth, Roland M wrote: Hi Jaesuk, The change in InfluxDB licensing was announced in the blog at, https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/. Up until that announcement,

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

Hi Tony, OpenStack-Ansible is just waiting for the requirements repository and the swift repository kilo-eol tags. Once they're done we'd like to bump the SHA's for our 'kilo' to the EOL tags of those two repositories, tag a release, then do our own kilo-eol tag. Thanks, Jesse IRC: odyssey4me

Re: [openstack-dev] [Nova] State machines in Nova

On 01/06/16 16:45, Joshua Harlow wrote: Do u have any more details (perhaps an 'real-life' example that you can walk us through) of this and how it played out. It'd be interesting to hear (I believe it has happened a few times but I've never heard how it was resolved or the details of it). The

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

I think all networking-* repos should EOL too, since they are plugins to neutron which is already EOL. I struggle to find a way that could maintain their gate without neutron. > On 02 Jun 2016, at 12:31, Tony Breeds wrote: > > Hi all, >In early May we tagged/EOL'd

[openstack-dev] [stable][all] Tagging kilo-eol for "the world"

Hi all, In early May we tagged/EOL'd several (13) projects. We'd like to do a final round for a more complete set. We looked for projects meet one or more of the following criteria: - The project is openstack-dev/devstack, openstack-dev/grenade or openstack/requirements - The project has

Re: [openstack-dev] [keystone][security] Service User Permissions

Hi Jamie In my opinion no security token should have the potential to last forever. This is a bad idea and can lead to all sorts of security vulnerabilities, some of which you highlight below. I thus take issue with your statement 'Ideally in a big system like this we only want to validate a

[openstack-dev] [vitrage] multi-tenancy in Vitrage

Hi, During the discussion about accepting vitrage into the big tent[1], there was a concern raised by a few people regarding whether Vitrage is suitable for a public cloud. They were bothered that allowing each user to see the entire cloud topology is not suitable in such environments. It is

Re: [openstack-dev] [higgins] Should we rename "Higgins"?

Yanyan Hu wrote: Aha, it's pretty interesting, I vote for Zun as well :) I don't get to vote, but since I was the one to suggest Higgins in the first place, I must admit that Zun sounds like a good alternative. -- Thierry Carrez (ttx)

Re: [openstack-dev] [Neutron][Release] Changing release model for *-aas services

Mark Voelker wrote: On Jun 1, 2016, at 12:27 PM, Armando M. wrote: [...] To the best of my knowledge none of the *-aas projects are part of defcore, and since [1] has no presence of vpn, fw, lb, nor planned, I thought I was on the safe side. Thanks for checking. You are

Re: [openstack-dev] [tc] [heat] [murano] [app-catalog] OpenStack Apps Community, several suggestions how to improve collaboration

Hi Jeremy, Please see my answers below: On 31 May 2016 at 19:38, Jeremy Stanley wrote: > On 2016-05-31 19:20:22 +0300 (+0300), Sergey Kraynev wrote: > [...] > > * *Second part related with changes with future repositories and* > > important for Openstack Infra team *

Re: [openstack-dev] [Monasca] influxDB clustering and HA will be "commercial option".

On 06/02/2016 10:06 AM, Hochmuth, Roland M wrote: > Hi Jaesuk, The change in InfluxDB licensing was announced in the blog at, > https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/. > Up until that announcement, InfluxDB was planning on supporting all

Re: [openstack-dev] [Monasca] influxDB clustering and HA will be "commercial option".

Hi László, as another alternative you could achieve something similar in Monasca, without using the InfluxDB Relay project, by configuring multiple Monasca Persisters each in a different consumer group, and with it's own independent InfluxDB server instance. Not sure which is the better

Re: [openstack-dev] [higgins] Should we rename "Higgins"?

Aha, it's pretty interesting, I vote for Zun as well :) 2016-06-02 12:56 GMT+08:00 Fei Long Wang : > +1 for Zun, I love it and it's definitely a good container :) > > > On 02/06/16 15:46, Monty Taylor wrote: > > On 06/02/2016 06:29 AM, 秀才 wrote: > >> i suggest a name Zun

Re: [openstack-dev] [Monasca] influxDB clustering and HA will be "commercial option".

My understanding of Prometheus is that it doesn't support HA, fault-tolerant clustering either. The recommendation from the Prometheus developers for HA and fault-tolerance/reliability is to run multiple Prometheus servers with one server scraping metrics from another server. To do something

[openstack-dev] [new][keystone] keystoneauth1 2.8.0 release (newton)

We are delighted to announce the release of: keystoneauth1 2.8.0: Authentication Library for OpenStack Identity This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/keystoneauth With package available at:

Re: [openstack-dev] [Monasca] influxDB clustering and HA will be "commercial option".

Hi Jaesuk, The change in InfluxDB licensing was announced in the blog at, https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/. Up until that announcement, InfluxDB was planning on supporting all their clustering and HA capabilities in the open-source

Re: [openstack-dev] [Monasca] influxDB clustering and HA will be "commercial option".

The blog post also states that: "For our users looking for free open source options, we’ll be releasing the open source InfluxDB Relay project along with a landing page how to achieve high availability using pure open source and subscription options with the 0.12.0 releases and beyond. From

Re: [openstack-dev] [TripleO] [diskimage-builder] Howto refactor?

Hi! > ++, but one clarification: We do have a spec process which is to use the > tripleo-specs repo. Since this is obviously not super clear and there is > a SnR issue for folks who are only dib core maybe we should move specs > in to the dib repo? Good to know! I'd really love to use the dib

[openstack-dev] [horizon] new stable-maint cores for Horizon

Horizoners, please join me to welcome * Richard Jones * Rob Cresswell * Thai Tran as new Horizon stable core reviewers. Thank you guys for stepping up and thank you tonyb for pulling stats and pushing this. Best, Matthias -- Matthias Runge Red Hat GmbH,

Re: [openstack-dev] [neutron][dvr] Wasting so many external network IPs in DVR mode?

Hi, Carl Thanks for your reply! ;-) I have some ideas about your explanation. Please review it. :-) The reason putting the routers namespaces behind the fip namespace is saving mac address tables in switches. In Centralized Virtual Router, there are many "qg" interfaces in the