[openstack-dev] [TripleO] PLUMgrid Neutron Integration for stable/mitaka

Hi TripleO Folks, As Mitaka branch was cut few days ago, I would like a request for backport for PLUMgrid Neutron integration patch [1]. The patch has been in progress for a while and adds support for enabling PLUMgrid neutron plugin [3] *optionally*. It has a low impact or risk since it can only

Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

The main issue is one of upgradability, not stability. We all know tripleo is stable. Tripleo cant do upgrades today. We're looking for ways to get there. So "upgrading" to ansible isnt nessisary for sure since folks deploying tripleo today must assume they cant upgrade anyway. Honestly I have

Re: [openstack-dev] [magnum] Are Floating IPs really needed for all nodes?

-1 who is going to run/support this proxy? also keep in mind that Kubernetes Service/NodePort (http://kubernetes.io/docs/user-guide/services/#type-nodeport)functionality is not going to work without public ip and this is very handy feature.   --- Egor From: 王华

Re: [openstack-dev] [magnum] Are Floating IPs really needed for all nodes?

Oh, that reminds me, MesosMonitor requires to use master node’s floating ip address directly to get state information. BR, Eli(Li Yong)Qiao From: 王华 [mailto:wanghua.hum...@gmail.com] Sent: Thursday, March 31, 2016 11:41 AM To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [magnum] Are Floating IPs really needed for all nodes?

Hi yuanying, I agree to reduce the usage of floating IP. But as far as I know, if we need to pull docker images from docker hub in nodes floating ips are needed. To reduce the usage of floating ip, we can use proxy. Only some nodes have floating ips, and other nodes can access docker hub by

Re: [openstack-dev] [telemetry] Rescheduling IRC meetings

Another personal suggestion: maybe we can have a weekly routine mail thread to present the things need to be discussed or need to be notified. The mail will also list the topics posted in meeting agenda and ask to Telemetry folks if a online IRC meeting is necessary, if there are a very few

Re: [openstack-dev] [magnum] Are Floating IPs really needed for all nodes?

Hi Yuanying, +1 I think we can add option on whether to using floating ip address since IP address are kinds of resource which not wise to waste. On 2016年03月31日 10:40, 大塚元央 wrote: Hi team, Previously, we had a reason why all nodes should have floating ips [1]. But now we have a LoadBalancer

Re: [openstack-dev] [Senlin] Asking about launching an instance in Senlin cluster

Hi, Please refer to Senlin user documentation [1] to start your journey (aka adventure). Also, you can stop by the #senlin channel on freenode IRC for any questions, suggestions. BTW, This mailinglist is intended for developers not for usage questions. You really want to check if someone on the

Re: [openstack-dev] [nova] [infra] The same SRIOV / NFV CI failures missed a regression, why?

On 26 March 2016 at 09:08, Jeremy Stanley wrote: > On 2016-03-25 15:20:00 -0400 (-0400), Jay Pipes wrote: > [...] >> 3) The upstream Infrastructure team works with the hired system >> administrators to create a single CI system that can spawn >> functional test jobs on the lab

[openstack-dev] [TC] TC Non-candidancy

Hi everyone - I'm not submitting my hat for the ring this cycle - I think its important we both share the work, and bring more folk up into the position of having-been-on-the-TC. I promise to still hold strong opinions weakly, and to discuss those in TC meetings :). -Rob -- Robert Collins

[openstack-dev] [Nova] How about use IP instead of hostname when live Migrate.

Hi, Nova, Currently, we use destination host name as the target node uri by default (if the newly added config option live_migration_inbound_addr has not been set). This will need transformations from hostname to IP to perform the operation such as copy disks, and it will depend on DNS services,

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

On 3/30/2016 5:55 PM, Armando M. wrote: On 29 March 2016 at 18:55, Matt Riedemann > wrote: On 3/29/2016 4:44 PM, Armando M. wrote: On 29 March 2016 at 08:08, Matt Riedemann

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

On 3/30/2016 5:50 PM, Armando M. wrote: On 30 March 2016 at 13:40, Sean Dague > wrote: On 03/29/2016 09:55 PM, Matt Riedemann wrote: > > Yup, HenryG walked me through the cases on IRC today. > > The more I think about option

[openstack-dev] [magnum] Are Floating IPs really needed for all nodes?

Hi team, Previously, we had a reason why all nodes should have floating ips [1]. But now we have a LoadBalancer features for masters [2] and minions [3]. And also minions do not necessarily need to have floating ips [4]. I think it’s the time to remove floating ips from all nodes. I know we are

Re: [openstack-dev] [nova][cinder] Fix nova swap volume (updating an attached volume) function

On 3/30/2016 9:14 PM, GHANSHYAM MANN wrote: On Thu, Mar 31, 2016 at 10:39 AM, Matt Riedemann wrote: On 3/30/2016 8:20 PM, Matt Riedemann wrote: On 3/30/2016 7:56 PM, Matt Riedemann wrote: On 3/30/2016 7:38 PM, Matt Riedemann wrote: On 2/25/2016 5:31

Re: [openstack-dev] [nova][cinder] Fix nova swap volume (updating an attached volume) function

On Thu, Mar 31, 2016 at 10:39 AM, Matt Riedemann wrote: > > > On 3/30/2016 8:20 PM, Matt Riedemann wrote: >> >> >> >> On 3/30/2016 7:56 PM, Matt Riedemann wrote: >>> >>> >>> >>> On 3/30/2016 7:38 PM, Matt Riedemann wrote: On 2/25/2016 5:31 AM,

Re: [openstack-dev] [nova] Is the Intel SRIOV CI running and if so, what does it test?

Hi, mriedem Shaohe is on vacation. And Intel SRIOV CI comment to Neutron. running the macvtap vnic SRIOV testing and plus required neutron smoking test. [4] https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-SRIOV-CI Regards Yongli He 在 2016年03月30日 23:21, Matt Riedemann 写道:

Re: [openstack-dev] [nova][cinder] Fix nova swap volume (updating an attached volume) function

On 3/30/2016 8:20 PM, Matt Riedemann wrote: On 3/30/2016 7:56 PM, Matt Riedemann wrote: On 3/30/2016 7:38 PM, Matt Riedemann wrote: On 2/25/2016 5:31 AM, Takashi Natsume wrote: Hi Nova and Cinder developers. As I reported in a bug report [1], nova swap volume (updating an attached

Re: [openstack-dev] [Neutron] BGP support

On 30 March 2016 at 17:07, Abhishek Raut wrote: > I think what Gary is talking about is BGP and the Border Gateway API > spec[1] in L2 GW repo. > [1] https://review.openstack.org/#/c/270786/ > Spec [1] has nothing to do with BGP (the routing protocol) last time I checked (note

Re: [openstack-dev] [nova][cinder] Fix nova swap volume (updating an attached volume) function

On 3/30/2016 7:56 PM, Matt Riedemann wrote: On 3/30/2016 7:38 PM, Matt Riedemann wrote: On 2/25/2016 5:31 AM, Takashi Natsume wrote: Hi Nova and Cinder developers. As I reported in a bug report [1], nova swap volume (updating an attached volume) fuction does not work in the case of non

Re: [openstack-dev] [nova][cinder] Fix nova swap volume (updating an attached volume) function

On 3/30/2016 7:38 PM, Matt Riedemann wrote: On 2/25/2016 5:31 AM, Takashi Natsume wrote: Hi Nova and Cinder developers. As I reported in a bug report [1], nova swap volume (updating an attached volume) fuction does not work in the case of non admin users by default. (Volumes are stuck.)

Re: [openstack-dev] [magnum] Discuss the blueprint"support-private-registry"

Sound good if bp /allow-user-softwareconfig/ can support configure CA, if it can be land, then I am going to drop this bp /support-private-registry (which is insceure) /but for now, I need to use patches for

Re: [openstack-dev] [nova][cinder] Fix nova swap volume (updating an attached volume) function

On 2/25/2016 5:31 AM, Takashi Natsume wrote: Hi Nova and Cinder developers. As I reported in a bug report [1], nova swap volume (updating an attached volume) fuction does not work in the case of non admin users by default. (Volumes are stuck.) Before I was working for fixing another swap

Re: [openstack-dev] [Neutron] BGP support

I think what Gary is talking about is BGP and the Border Gateway API spec[1] in L2 GW repo. [1] https://review.openstack.org/#/c/270786/ -Abhishek Raut From: "Tidwell, Ryan" > Reply-To: "OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [Neutron] BGP support

Gary, I’m not sure I understand the relationship you’re drawing between BGP and L2 GW, could you elaborate? The BGP code that landed in Mitaka is mostly geared toward the use case where you want to directly route your tenant networks without any NAT (ie no floating IP’s, no SNAT). Neutron

[openstack-dev] meeting topics for 3/31/2016 networking-sfc project IRC meeting

Hi everyone, First thanks to Louis Fourie and Paul Carver for chairing the project IRC meetings while I was on business trip. Here are some topics I have in mind for tomorrow's meeting discussion. Feel free to add more. 1. ODL SFC Driver to networking-sfc 2. Networking-sfc driver

[openstack-dev] [election] [tc] TC candidacy

Please accept my candidacy for election to the technical committee. Election season is both a time of intense activity as well as (hopefully) a time to self-evaluate and commit or recommit to a personal vision of OpenStack. OpenStack is exactly as we define it and I hope many folks are taking a

[openstack-dev] [election][tc] TC Candidacy for Carol Barrett

Hi - I am announcing my candidacy for the OpenStack Technical Committee for the upcoming term. Currently, I am a Data Center Software Planner at Intel. I have been an active member in the community since 2013, working with Community teams to understand market needs and bring that information

[openstack-dev] [elections][tc] TC Candidacy

Hi All, I would like to throw my hat in the ring to be part of the OpenStack Technical Committee. I'm working at Ericsson, where I'm coordinating the OpenStack related activities across the company. I started to contribute to OpenStack more than two years ago by adding rich query functionality

Re: [openstack-dev] [lbaas] [octavia] Proposing Bharath Munirajulu as Octavia Core

+1 On Wed, 2016-03-30 at 13:56 -0700, Michael Johnson wrote: > I would like to nominate Bharath Munirajulu (bharathm) as a OpenStack > Octavia core reviewer. > His contributions [1] are in line with other cores and he has been an > active member of our community. I have been impressed with the >

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

On 29 March 2016 at 18:55, Matt Riedemann wrote: > > > On 3/29/2016 4:44 PM, Armando M. wrote: > >> >> >> On 29 March 2016 at 08:08, Matt Riedemann > > wrote: >> >> Nova has had some long-standing

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

On 30 March 2016 at 13:40, Sean Dague wrote: > On 03/29/2016 09:55 PM, Matt Riedemann wrote: > > > > > Yup, HenryG walked me through the cases on IRC today. > > > > The more I think about option (b) above, the less I like that idea given > > how much work goes into the

[openstack-dev] [app-catalog] App Catalog IRC meeting cancelled this week

Due to a very light agenda (and everyone being pretty busy at the moment) we're going to skip the meeting this week. Our next meeting is scheduled for April 7th, the agenda can be found here: https://wiki.openstack.org/wiki/Meetings/app-catalog -Christopher

Re: [openstack-dev] [lbaas] [octavia] Proposing Bharath Munirajulu as Octavia Core

+1 Great work Bharath!! On 3/30/16, 1:56 PM, "Michael Johnson" wrote: >I would like to nominate Bharath Munirajulu (bharathm) as a OpenStack >Octavia core reviewer. >His contributions [1] are in line with other cores and he has been an >active member of our community. I

Re: [openstack-dev] [lbaas] [octavia] Proposing Bharath Munirajulu as Octavia Core

not core reviewer, but wanna give my +1 On Thu, Mar 31, 2016 at 9:56 AM, Michael Johnson wrote: > I would like to nominate Bharath Munirajulu (bharathm) as a OpenStack > Octavia core reviewer. > His contributions [1] are in line with other cores and he has been an > active

Re: [openstack-dev] [nova] API priorities in Newton

On 3/30/2016 2:26 PM, Sean Dague wrote: During the Nova API meeting we had some conversations about priorities, but this feels like the thing where a mailing list conversation is more inclusive to get agreement on things. I think we need to remain focused on what API related work will have the

Re: [openstack-dev] [nova] API priorities in Newton

On Wed, Mar 30, 2016, at 04:47 PM, Adam Young wrote: > On 03/30/2016 04:16 PM, Andrew Laski wrote: > > > > On Wed, Mar 30, 2016, at 03:54 PM, Matt Riedemann wrote: > >> > >> On 3/30/2016 2:42 PM, Andrew Laski wrote: > >>> > >>> On Wed, Mar 30, 2016, at 03:26 PM, Sean Dague wrote: > During

Re: [openstack-dev] [tripleo] Policy Managment and distribution.

On Tue, Mar 29, 2016 at 07:37:02PM -0400, Emilien Macchi wrote: > On Tue, Mar 29, 2016 at 6:18 PM, Adam Young wrote: > > Keystone has a policy API, but no one uses it. It allows us to associate a > > policy file with an endpoint. Upload a json blob, it gets a uuid. Associate

Re: [openstack-dev] [all] Austin Design Summit track layout

On 03/30/2016 05:24 AM, Thierry Carrez wrote: > See new version attached. This will be pushed to the official schedule > tomorrow, so please reply here today if you see any major issue with it. > > Changes: > - swapped the release and stable slots to accommodate mriedem > - moved Astara fishbowl

[openstack-dev] [lbaas] [octavia] Proposing Bharath Munirajulu as Octavia Core

I would like to nominate Bharath Munirajulu (bharathm) as a OpenStack Octavia core reviewer. His contributions [1] are in line with other cores and he has been an active member of our community. I have been impressed with the insight and quality of his reviews. Current Octavia cores, please vote

Re: [openstack-dev] [searchlight] Add Nova Keypair Plugin

Hi Hiroyuki, It would be worth being certain about what access we have to keypairs before committing to a plugin; if we cannot retrieve the initial list or receive notifications on new keypairs, we likely can't index them at all. If we have partial access we may be able to make a decision on

Re: [openstack-dev] [all] Austin Design Summit track layout

Hi Thierry, After discussing with the Kuryr PTL (Gal), we agreed to have a shared fishbowl session between Magnum and Kuryr. I would like to schedule it at Thursday 11:50 - 12:30 for now (by using the original Magnum fishbowl slot). We might adjust the time later if needed. Thanks. Best

Re: [openstack-dev] [nova] API priorities in Newton

On 03/30/2016 04:16 PM, Andrew Laski wrote: On Wed, Mar 30, 2016, at 03:54 PM, Matt Riedemann wrote: On 3/30/2016 2:42 PM, Andrew Laski wrote: On Wed, Mar 30, 2016, at 03:26 PM, Sean Dague wrote: During the Nova API meeting we had some conversations about priorities, but this feels like

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

On 03/29/2016 09:55 PM, Matt Riedemann wrote: > > Yup, HenryG walked me through the cases on IRC today. > > The more I think about option (b) above, the less I like that idea given > how much work goes into the allocate_for_instance code in nova where > it's already building the list of

Re: [openstack-dev] [all] Service Catalog TNG work in Mitaka ... next steps

On 03/29/2016 06:49 PM, Matt Riedemann wrote: On 3/29/2016 2:30 PM, Sean Dague wrote: At the Mitaka Summit we had a double session on the Service Catalog, where we stood, and where we could move forward. Even though the service catalog isn't used nearly as much as we'd like, it's used in just

Re: [openstack-dev] [nova] API priorities in Newton

On 03/30/2016 04:17 PM, Jay Pipes wrote: > On 03/30/2016 12:54 PM, Matt Riedemann wrote: - POC of Gabbi for additional API validation >> >> I'm assuming cdent would be driving this, and he's also working on the >> resource providers stuff for the scheduler, but might be a decent side >>

[openstack-dev] Are injected files in compute going to be deprecated?

In nova/compute/manager.py I see: def inject_file(self, context, path, file_contents, instance): """Write a file to the specified path in an instance on this host.""" # NOTE(russellb) Remove this method, as well as the underlying virt # driver methods, when the

Re: [openstack-dev] [nova] API priorities in Newton

On Wed, Mar 30, 2016, at 03:54 PM, Matt Riedemann wrote: > > > On 3/30/2016 2:42 PM, Andrew Laski wrote: > > > > > > On Wed, Mar 30, 2016, at 03:26 PM, Sean Dague wrote: > >> During the Nova API meeting we had some conversations about priorities, > >> but this feels like the thing where a

Re: [openstack-dev] [nova] API priorities in Newton

On 03/30/2016 12:54 PM, Matt Riedemann wrote: - POC of Gabbi for additional API validation I'm assuming cdent would be driving this, and he's also working on the resource providers stuff for the scheduler, but might be a decent side project for him to stay sane. Actually, Sergey Nikitin can

Re: [openstack-dev] [nova] API priorities in Newton

On 3/30/2016 2:42 PM, Andrew Laski wrote: On Wed, Mar 30, 2016, at 03:26 PM, Sean Dague wrote: During the Nova API meeting we had some conversations about priorities, but this feels like the thing where a mailing list conversation is more inclusive to get agreement on things. I think we

Re: [openstack-dev] [nova] API priorities in Newton

On Wed, Mar 30, 2016 at 03:26:13PM -0400, Sean Dague wrote: > During the Nova API meeting we had some conversations about priorities, > but this feels like the thing where a mailing list conversation is more > inclusive to get agreement on things. I think we need to remain focused > on what API

Re: [openstack-dev] [nova] API priorities in Newton

On Wed, Mar 30, 2016, at 03:26 PM, Sean Dague wrote: > During the Nova API meeting we had some conversations about priorities, > but this feels like the thing where a mailing list conversation is more > inclusive to get agreement on things. I think we need to remain focused > on what API related

[openstack-dev] [nova] API priorities in Newton

During the Nova API meeting we had some conversations about priorities, but this feels like the thing where a mailing list conversation is more inclusive to get agreement on things. I think we need to remain focused on what API related work will have the highest impact on our users. (some brain

[openstack-dev] minutes of the Trove meeting 2016-03-30

Meeting minutes can be found at http://eavesdrop.openstack.org/meetings/trove/2016/trove.2016-03-30-18.01.txt Thanks to all who attended. -amrith __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty within the Liberty branch

So I made this: https://review.openstack.org/#/c/299563/ I'm not super fond of reverting commits from the middle of release, because this will make a lot of mess. I'd rather re-implement keystone bootstrap logic and make it conditional as it is not that complicated. On 30 March 2016 at 12:37,

Re: [openstack-dev] [TripleO] tripleo-quickstart import

On Tue, Mar 29, 2016 at 08:30:22PM -0400, John Trowbridge wrote: > Hola, > > With the approval of the tripleo-quickstart spec[1], it is time to > actually start doing the work. The first work item is moving it to the > openstack git. The spec talks about moving it as is, and this would > still be

Re: [openstack-dev] [kloudbuster] authorization failed problem

Hi Yichen, Thanks a lot . I will try with v6 and reach out to you for further help. Regards, Akshay On Wed, Mar 30, 2016 at 11:35 PM, Yichen Wang (yicwang) wrote: > Hi, Akshay, > > > > From the log you attached, the good news is you got KloudBuster installed > and running

Re: [openstack-dev] [i18n][horizon][sahara][trove][magnum][murano] dashboard plugin release schedule

Just an update on this thread that the trove-dashboard RC2 was released https://review.openstack.org/#/c/298365/ Thanks, Craig Vyvial On Wed, Mar 23, 2016 at 11:36 PM Craig Vyvial wrote: > The trove-dashboard has its own stable/mitaka branch [1] as well. We have > an RC1

Re: [openstack-dev] [kloudbuster] authorization failed problem

Hi, Akshay, From the log you attached, the good news is you got KloudBuster installed and running fine! The problem is the image you are using (v5) is outdated for the latest KloudBuster main code. ☺ Normally for every version of KloudBuster, it needs certain version of image to support the

Re: [openstack-dev] [Neutron]Relationship between physical networks and segment

Bob, Thanks for your detailed response. In it you "strongly recommend that any functionality trying to make decisions based on connectivity do so by calling into the registered mechanism drivers, so they can decide whether whatever they manage has connectivity". After eading this I went through

Re: [openstack-dev] [Fuel] [RDO] Volunteers needed

Hi, Vladimir, this is a great feature, which can make Fuel truly universal. But i think it is hard to fully commit to the whole thing at once, especially for new contributors. Let's start with splitting it into some observable chunks of work, in a form of wiki page, blueprint or spec. This way

Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty within the Liberty branch

Agreed this needs to happen +1, - Original Message - From: "Jeff Peeler" To: "OpenStack Development Mailing List (not for usage questions)" Sent: Wednesday, March 30, 2016 1:22:31 PM Subject: Re: [openstack-dev] [kolla][vote] Just

Re: [openstack-dev] Fw:Extending API via Plugins

Hi wangzhh, I think this look reasonable, but I would prefer to have a proper spec for this feature. I generally like to have extendable API in Murano. On Thu, Mar 24, 2016 at 8:49 PM, 王正浩 wrote: > I'm sorry that I forgot to tell you murano-paste.ini should be modified to

Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty within the Liberty branch

On 03/30/2016 09:51 AM, Steven Dake (stdake) wrote: Michal, We can't commit to that. We discussed it at midcycle and unable to commit to it then. We are essentially abandoning the 1.0.0 release and replacing it with 1.1.0 because of the documentation outlined here:

Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty within the Liberty branch

On Wed, Mar 30, 2016 at 3:52 AM, Steven Dake (stdake) wrote: > > > From: Jeffrey Zhang > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Wednesday, March 30, 2016 at 12:29 AM > To:

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On Wed, Mar 30, 2016 at 9:03 AM, Pavel Bondar wrote: > Kevin Benton commented on review page for current migration to pluggable > approach [1]: > > IMO this cannot be optional. It's going to be a nightmare to try to support > two IPAM systems that people may have switched

Re: [openstack-dev] [all] Austin Design Summit track layout

Matt Riedemann wrote: 1:30pm on Thursday (first slot after lunch is unconference for nova) would work for me. OK, I'll make that swap too (unless Josh hits me with a trout over the night) -- Thierry Carrez (ttx) __

Re: [openstack-dev] [Rally] single router per tenant in network context

Hi Aleksandr, Thanks Aleksandr. According to your references,I made the necessary changes to the code for single router , but now facing problems in the resource cleanup. While I correct the code, Can you suggest how to generate traffic between the VMs ? Is there any tool that is generally used

Re: [openstack-dev] [all] Austin Design Summit track layout

John Dickinson wrote: Yes, I checked on that. Based on where in the schedule that is, and based on the way we're planning on doing the working sessions, it will be just fine for me to not be in that particular session. It's much better for the community that we have the contiguous block that

Re: [openstack-dev] [all] Austin Design Summit track layout

On 3/30/2016 10:42 AM, Ihar Hrachyshka wrote: Thierry Carrez wrote: Ihar Hrachyshka wrote: I'd then have the same problem than Matt here as I'm the Release CPL for Nova. That said, given I think I'm the only person probably having the issue, I can say fair enough and

Re: [openstack-dev] [all] Austin Design Summit track layout

Yes, I checked on that. Based on where in the schedule that is, and based on the way we're planning on doing the working sessions, it will be just fine for me to not be in that particular session. It's much better for the community that we have the contiguous block that I personally be present

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On 30/03/16 16:08, Pavel Bondar wrote: > We are now in early Newton, so it is good time to discuss plan for > pluggable ipam for this release cycle. > > Kevin Benton commented on review page for current migration to pluggable > approach [1]: >> >> IMO this cannot be optional. It's going to be a

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

On 29/03/16 21:55, Carl Baldwin wrote: > > I thought of another type of grouping which could benefit pluggable > IPAM today. It occurred to me as I was refreshing my memory on how > pluggable IPAM works when there are multiple subnets on a network. > Currently, Neutron's backend pulls the subnets

Re: [openstack-dev] [magnum][magnum-ui] Have magnum jobs respect upper-constraints.txt

Thanks Hongbin, I've updated the bug summary to be more generic. -amrith > -Original Message- > From: Hongbin Lu [mailto:hongbin...@huawei.com] > Sent: Wednesday, March 30, 2016 11:32 AM > To: OpenStack Development Mailing List (not for usage questions) >

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

On 29/03/16 19:16, Carl Baldwin wrote: > I've been playing with this a bit on this patch set [1]. I haven't > gotten very far yet but it has me thinking. > > Calico has a similar use case in mind as I do. Essentially, we both > want to group subnets to allow for aggregation of routes. (a) In >

Re: [openstack-dev] [magnum][magnum-ui] Have magnum jobs respect upper-constraints.txt

On 03/30/2016 05:31 PM, Hongbin Lu wrote: > Hi team, > > After a quick check, it seems python-magnumclient and magnum-ui don't use > upper constraints. Magnum (the main repo) uses upper constraints in > integration tests (gate-functional-*), but doesn't use it in others (e.g. > py27, py34,

Re: [openstack-dev] [all] Austin Design Summit track layout

Thierry Carrez wrote: Ihar Hrachyshka wrote: I'd then have the same problem than Matt here as I'm the Release CPL for Nova. That said, given I think I'm the only person probably having the issue, I can say fair enough and try to clone myself before the Summit :-)

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

On 11/03/16 23:20, Carl Baldwin wrote: > Hi, Hi Carl, and sorry for the lateness of this reply. > I have started to get into coding [1] for the Neutron routed networks > specification [2]. > > This spec proposes a new association between network segments and > subnets. This affects how IPAM

Re: [openstack-dev] [Fuel] Extra red tape for filing bugs

We also often use bugtracker as a TODO tracker. This template does not work for TODOs at all. I understand that it’s not technically mandatory to follow it, but if that Fuel Bug Checker is going to spam on every single TODO, our inboxes will overflow. > 30 бер. 2016 р. о 17:37 Roman

[openstack-dev] [Fuel] Extra red tape for filing bugs

Guys, I’m not trying to be a foreteller but with a bug template this huge and complicated people will either not follow it or track bugs somewhere else. Perhaps we should make it simpler? Detailed bug description: Steps to reproduce: Expected results: Actual result: Reproducibility:

[openstack-dev] [magnum][magnum-ui] Have magnum jobs respect upper-constraints.txt

Hi team, After a quick check, it seems python-magnumclient and magnum-ui don't use upper constraints. Magnum (the main repo) uses upper constraints in integration tests (gate-functional-*), but doesn't use it in others (e.g. py27, py34, pep8, docs, coverage). The missing of upper constraints

Re: [openstack-dev] [all] Austin Design Summit track layout

Ihar Hrachyshka wrote: I'd then have the same problem than Matt here as I'm the Release CPL for Nova. That said, given I think I'm the only person probably having the issue, I can say fair enough and try to clone myself before the Summit :-) Actually, now that I am a release CPL for Neutron,

[openstack-dev] [nova] Is the Intel SRIOV CI running and if so, what does it test?

Intel has a few third party CIs in the third party systems wiki [1]. I was talking with Moshe Levi today about expanding coverage for mellanox CI in nova, today they run an SRIOV CI for vnic type 'direct'. I'd like them to also start running their 'macvtap' CI on the same nova changes (that

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On 12.02.2016 15:01, Ihar Hrachyshka wrote: > Salvatore Orlando wrote: > >> On 11 February 2016 at 20:17, John Belamaric >> wrote: >> >>> On Feb 11, 2016, at 12:04 PM, Armando M. wrote: >>> >>> >>> >>> On 11 February 2016 at

Re: [openstack-dev] [Neutron]Relationship between physical networks and segment

On 29/03/16 20:42, Miguel Lavalle wrote: > Hi, Hi Miguel, > I am writing a patchset to build a mapping between hosts and network > segments. The goal of this mapping is to be able to say whether a host > has access to a given network segment. I am building this mapping > assuming that if a host

Re: [openstack-dev] [magnum] Generate atomic images using diskimage-builder

Another use case I can think of is to cache the required docker images in the Glance image. This is an important use case because we have containerized most of the COE components (e.g. kube-scheduler, swarm-manager, etc.). As a result, each bay needs to pull docker images over the Internet on

Re: [openstack-dev] [magnum][kuryr] Shared session in design summit

All these slots are fine with me, added Kuryr team as CC to make sure most can attend any of these times. On Wed, Mar 30, 2016 at 5:12 PM, Hongbin Lu wrote: > Gal, > > > > Thursday 4:10 – 4:50 conflicts with a Magnum workroom session, but we can > choose from: > > ·

Re: [openstack-dev] [all] Austin Design Summit track layout

Sylvain Bauza wrote: Le 29/03/2016 09:48, Thierry Carrez a écrit : Matt Riedemann wrote: I see one problem. The single stable team fishbowl session is scheduled for the last slot on Thursday (5pm). The conflict I have with that is the nova team does it's

Re: [openstack-dev] [kloudbuster] authorization failed problem

Hi Alec, Thanks for clarifying. I didnot have the cinder service previously. It was not a complete setup. Now, I did the setup of cinder service. Output of keystone service list. [image: Inline image 1] I installed the setup of openstack using the installation guide for ubuntu and for kloudbuster,

Re: [openstack-dev] [release][all] What is upper-constraints.txt?

> -Original Message- > From: Andreas Jaeger [mailto:a...@suse.com] > Sent: Wednesday, March 30, 2016 9:03 AM > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [release][all] What is upper-constraints.txt?

Re: [openstack-dev] [release][all] What is upper-constraints.txt?

> -Original Message- > From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com] > Sent: Wednesday, March 30, 2016 9:01 AM > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [release][all] What is

Re: [openstack-dev] [magnum] Discuss the blueprint"support-private-registry"

I agree to that support-private-registry should be secure. As insecure seems not much useful for production use. Also I understood the point setup related CA could be diffcult than normal HTTP, but we want to know if https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig Could

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

Hi, Do we have any requirements for the new tool? Do we know what we don’t like about current implementation, what should be avoided, etc.? Before that we can only speculate. From my ops experience, shotgun like tools will not work conveniently on medium to big environments. Even on medium env

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

Osquery [1] could also be considered as providing a lot of useful informations in a convenient way. [1] https://osquery.io/ On Wed, Mar 30, 2016 at 3:20 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > ​Igor, > > I can not agree more. Wherever possible we should > use existent

[openstack-dev] Mitaka RC packages for openSUSE and SLES available

Hi, In the last few weeks we've been working hard on stabilizing the Mitaka packages, and the packages currently available in Cloud:OpenStack:Mitaka [0] pass early testing. Feel free to try them out by adding the repository: http://download.opensuse.org/repositories/Cloud:/OpenStack:/Mitaka/$DI

Re: [openstack-dev] [magnum][kuryr] Shared session in design summit

Gal, Thursday 4:10 – 4:50 conflicts with a Magnum workroom session, but we can choose from: · 11:00 – 11:40 · 11:50 – 12:30 · 3:10 – 3:50 Please let us know if some of the slots don’t work well with your schedule. Best regards, Hongbin From: Gal Sagie

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

On Wed, Mar 30, 2016, at 03:37 AM, Thomas Goirand wrote: > On 03/29/2016 08:33 PM, Doug Hellmann wrote: > > If the core doc team isn't able to help you maintain it, maybe it's a > > candidate for a separate guide, just like we're discussing for projects > > that aren't part of the DefCore set

Re: [openstack-dev] [telemetry] Rescheduling IRC meetings

On 30/03/2016 8:06 AM, Julien Danjou wrote: > On Wed, Mar 30 2016, Chris Dent wrote: > >> Another option on the meetings would be to do what the cross project >> meetings do: Only have the meeting if there are agenda items. > > That's a good idea, I'd be totally cool with that too. We could send

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

​Igor, I can not agree more. Wherever possible we should use existent mature solutions. Ansible is really convenient and well known solution, let's try to use it. Yet another thing should be taken into account. One of Shotgun features is diagnostic report that could then be attached to bugs to

Re: [openstack-dev] [magnum] Discuss the blueprint "support-private-registry"

Hi. On Wed, Mar 30, 2016 at 3:59 AM, Eli Qiao wrote: > > Hi Hongbin > > Thanks for starting this thread, > > > > I initial propose this bp because I am in China which is behind China great > wall and can not have access of gcr.io directly, after checking our > cloud-init

  1   2   >