[openstack-dev] [kuryr][fuxi][dragonflow][devstack] Installing etcd in devstack plugin

Folks, Please look over this review for adding etcd as a base service: https://review.openstack.org/#/c/445432/ Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for

Re: [openstack-dev] [vitrage] [nova] [HA] [masakari] VM Heartbeat / Healthcheck Monitoring

Hi Vikash, Great... I will add you as reviewer to this spec. Thank you.. --- Regards, Sampath On Fri, May 19, 2017 at 1:06 PM, Vikash Kumar wrote: > Hi Greg, > > Please include my email in this spec also. We are also dealing with HA > of Virtual Instances

Re: [openstack-dev] [tc][all] Do we need a #openstack-tc IRC channel

In keeping with the brevity of the email below, YES Enough others have opined on the why, I have nothing new to add and I am happy to just say +1 ... -amrith > -Original Message- > From: Davanum Srinivas [mailto:dava...@gmail.com] > Sent: Tuesday, May 16, 2017 9:39 AM > To: OpenStack

Re: [openstack-dev] [trove] Trove meeting time update

Thanks for doing this Trevor, I am hoping that this patch merges soon so we can do the new meeting time on Wednesday. -- Amrith Kumar amrith.ku...@gmail.com > -Original Message- > From: MCCASLAND, TREVOR [mailto:tm2...@att.com] > Sent: Friday, May 19, 2017 2:49 PM > To: OpenStack

Re: [openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

So making a subnet ID mandatory for a port creation and a RouterInterface ID mandatory for a Floating IP creation are both possible in Heat without Neutron changes. Presumably you haven't done that because it's backwards-incompatible, but you would need to implement the change anyway if the

[openstack-dev] [nova] Bug heads up: Significant increase in DB connections with cells since Newton

Hey Folks, I wanted to give everyone a heads up that we have found and fixed a bug [1] on master where the number of database connections had increased so much that we were starting to hit a "OperationalError (pymysql.err.OperationalError) (1040, u'Too many connections')" in the gate on some

[openstack-dev] [neutron] - Summit "The Future of VPN as a Service (VPNaaS)" summary and next steps

Hi, Here are the key points from "The Future of VPN as a Service" session: https://etherpad.openstack.org/p/boston-vpnaas We had a good showing of operators that have VPNaaS deployed who are relatively happy with it and definitely want to see it continue being developed. We have a list of 9

[openstack-dev] [neutron] - Summit "Distributed SNAT with DVR" summary and next steps

Hi, https://etherpad.openstack.org/p/boston-dvr The summary from this session is somewhat short. It looks like for this cycle we don't have the bandwidth to either implement or review the data model, API, and agent changes required to implement this feature in the in-tree DVR implementation. If

[openstack-dev] [neutron] - Summit "Neutron Pain points session" summary and next steps

Hi, Here are the key points from the "Neutron Pain Points" session: https://etherpad.openstack.org/p/neutron-boston-painpoints FWaaS v1 to v2 - We should try to support running both v1 and v2 concurrently so operators aren't forced to immediately kill all existing v1 users just to start to

Re: [openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

On 19/05/17 17:03, Kevin Benton wrote: I split this conversation off of the "Is the pendulum swinging on PaaS layers?" thread [1] to discuss some improvements we can make to Neutron to make orchestration easier. There are some pain points that heat has when working with the Neutron API. I would

Re: [openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

On 19 May 2017 at 14:54, Clark Boylan wrote: > On Fri, May 19, 2017, at 02:03 PM, Kevin Benton wrote: > > I split this conversation off of the "Is the pendulum swinging on PaaS > > layers?" thread [1] to discuss some improvements we can make to Neutron > > to > > make

[openstack-dev] Summary of BOS Summit session: User API Improvements

Hey folks, I’ve summarized the User API Improvement forum session. I seem to recall that Clark Boyland and I were “volunteered” to project manage the effort to get these tracked and scheduled (which I would assume also means eiterh spec’ed, bp’ed or bugged), but I’m real fuzzy on that.

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

On 5/19/2017 3:35 PM, Monty Taylor wrote: Heck - while I'm on floating ips ... if you have some pre-existing floating ips and you want to boot servers on them and you want to do that in parallel, you can't. You can boot a server with a floating ip that did not pre-exist if you get the port id

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

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

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

On 5/19/2017 9:36 AM, Zane Bitter wrote: The problem is that orchestration done inside APIs is very easy to do badly in ways that cause lots of downstream pain for users and external orchestrators. For example, Nova already does some orchestration: it creates a Neutron port for a server if

Re: [openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

On Fri, May 19, 2017, at 02:03 PM, Kevin Benton wrote: > I split this conversation off of the "Is the pendulum swinging on PaaS > layers?" thread [1] to discuss some improvements we can make to Neutron > to > make orchestration easier. > > There are some pain points that heat has when working

[openstack-dev] [glance] Stepping Down

Glancers, Due to a significant change to my job description, I wouldn't be able to contribute to Glance in the capacity of a core reviewer going forward. Hence, I'd like to step down from my role immediately. For the same reason, I'd like to step down from Glance coresec and release liaison roles

Re: [openstack-dev] [Keystone] Cockroachdb for Keystone Multi-master

On 05/18/2017 06:13 PM, Adrian Turjak wrote: So, specifically in the realm of Keystone, since we are using sqlalchemy we already have Postgresql support, and since Cockroachdb does talk Postgres it shouldn't be too hard to back Keystone with it. At that stage you have a Keystone DB that could

Re: [openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

We could potentially alter Neutron to inspect each of the fixed IPs to see if it's eligible to be associated to that floating IP to find the one that works. Unfortunately that still won't solve multiple eligible fixed IPs. So is the right thing to do to just always force the user to specify

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

On 5/19/2017 3:03 PM, Monty Taylor wrote: On 05/19/2017 01:04 PM, Sean Dague wrote: On 05/19/2017 01:38 PM, Dean Troyer wrote: On Fri, May 19, 2017 at 11:53 AM, Chris Friesen wrote: ..., but it seems to me that the logical extension of that is to expose simple

Re: [openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

On 05/19/2017 04:03 PM, Kevin Benton wrote: I split this conversation off of the "Is the pendulum swinging on PaaS layers?" thread [1] to discuss some improvements we can make to Neutron to make orchestration easier. There are some pain points that heat has when working with the Neutron API. I

Re: [openstack-dev] [oslo] can we make everyone drop eventlet? (was: Can we stop global requirements update?)

FTFY On 05/19/2017 03:58 PM, Joshua Harlow wrote: Mehdi Abaakouk wrote: Not really, I just put some comments on reviews and discus this on IRC. Since nobody except Telemetry have expressed/try to get rid of eventlet. Octavia is using cotyledon and they have gotten rid of eventlet. Didn't

Re: [openstack-dev] [oslo] Can we stop global requirements update?

On 05/19/2017 04:23 AM, Mehdi Abaakouk wrote: And some applications rely on implicit internal contract/behavior/assumption. IMO that's a bug for them.I'm inspired to see that Keystone, Nova etc. are able to move between and eventlet backend and a mod_wsgi backend.IMO eventlet is

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

On 5/19/2017 1:04 PM, Sean Dague wrote: Anyway, this gets pretty meta pretty fast. I agree with Zane saying "I want my server to build", or "I'd like Nova to build a volume for me" are very odd things to call PaaS. I think of PaaS as "here is a ruby on rails app, provision me a db for it, and

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

Started a new Neutron-specific thread so we can get some stuff turned into improvements in Neutron from this: http://lists.openstack.org/pipermail/openstack-dev/2017-May/117112.html On Fri, May 19, 2017 at 1:05 PM, Zane Bitter wrote: > On 19/05/17 15:06, Kevin Benton wrote:

[openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

I split this conversation off of the "Is the pendulum swinging on PaaS layers?" thread [1] to discuss some improvements we can make to Neutron to make orchestration easier. There are some pain points that heat has when working with the Neutron API. I would like to get them converted into requests

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

On 5/19/2017 12:38 PM, Dean Troyer wrote: First and foremost, we need to have the primitive operations that get composed into the higher-level ones available. Just picking "POST /server" as an example, we do not have that today. Chris mentions above the low-level version should take IDs for

Re: [openstack-dev] [all] Onboarding rooms postmortem, what did you do, what worked, lessons learned

Project: Keystone Attendees: 12 - 15 We conflicted with one of the Baremetal/VM sessions I attempted to document most of the session in my recap [0]. We started out by doing a round-the-room of introductions so that folks could put IRC nicks to faces (we also didn't have a packed room so this

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

On 05/19/2017 03:05 PM, Zane Bitter wrote: On 19/05/17 15:06, Kevin Benton wrote: Don't even get me started on Neutron.[2] It seems to me the conclusion to that thread was that the majority of your issues stemmed from the fact that we had poor documentation at the time. A major component of

Re: [openstack-dev] [Keystone] Cockroachdb for Keystone Multi-master

On Thu, May 18, 2017 at 6:43 PM, Curtis wrote: > On Thu, May 18, 2017 at 4:13 PM, Adrian Turjak > wrote: > > Hello fellow OpenStackers, > > > > For the last while I've been looking at options for multi-region > > multi-master Keystone, as well as

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

On 05/19/2017 01:53 PM, Sean Dague wrote: On 05/19/2017 02:34 PM, Dean Troyer wrote: On Fri, May 19, 2017 at 1:04 PM, Sean Dague wrote: These should be used as ways to experiment with the kinds of interfaces we want cheaply, then take them back into services (which is a more

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

On 19/05/17 15:06, Kevin Benton wrote: Don't even get me started on Neutron.[2] It seems to me the conclusion to that thread was that the majority of your issues stemmed from the fact that we had poor documentation at the time. A major component of the complaints resulted from you

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

On 05/19/2017 01:04 PM, Sean Dague wrote: On 05/19/2017 01:38 PM, Dean Troyer wrote: On Fri, May 19, 2017 at 11:53 AM, Chris Friesen wrote: ..., but it seems to me that the logical extension of that is to expose simple orthogonal APIs where the nova boot request

Re: [openstack-dev] [oslo] Can we stop global requirements update?

Mehdi Abaakouk wrote: Not really, I just put some comments on reviews and discus this on IRC. Since nobody except Telemetry have expressed/try to get rid of eventlet. Octavia is using cotyledon and they have gotten rid of eventlet. Didn't seem like it was that hard either to do it (of course

Re: [openstack-dev] [glance][openstack-ansible] Moving on

This is most unfortunate. :( I do wish you the absolute best with whatever lies ahead. I have found your skills, patience and willingness to debate and learn most inspirational. From: Steve Lewis Reply-To: "OpenStack Development Mailing List (not for usage questions)"

[openstack-dev] [trove] Trove reboot meeting

As a result of a large number of new contributors looking for direction from our project, we would like to host a focused meeting on the project's scope. Please let us know your availability for this one time meeting by using this doodle poll[1] We have brainstormed a few ideas for discussion

Re: [openstack-dev] [nova][neutron] massive overhead processing "network-changed" events during live migration

On 5/19/2017 1:40 PM, Chris Friesen wrote: Recently we noticed failures in Newton when we attempted to live-migrate an instance with 16 vifs. We tracked it down to an RPC timeout in nova which timed out waiting for the 'refresh_cache-%s' lock in get_instance_nw_info(). This led to a few

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

>Don't even get me started on Neutron.[2] It seems to me the conclusion to that thread was that the majority of your issues stemmed from the fact that we had poor documentation at the time. A major component of the complaints resulted from you misunderstanding the difference between

Re: [openstack-dev] [nova] Boston Forum session recap - searchlight integration

On 05/19/2017 02:46 AM, joehuang wrote: Support sort and pagination together will be the biggest challenge: it's up to how many cells will be involved in the query, 3,5 may be OK, you can search each cells, and cached data. But how about 20, 50 or more, and how many data will be cached?

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

On 05/19/2017 02:34 PM, Dean Troyer wrote: > On Fri, May 19, 2017 at 1:04 PM, Sean Dague wrote: >> These should be used as ways to experiment with the kinds of interfaces >> we want cheaply, then take them back into services (which is a more >> expensive process involving

[openstack-dev] [trove] Trove meeting time update

I have submitted a patch for updating the regular trove meeting time to 1500 UTC. This was decided during the trove project update meeting last week[1] If you weren't able to make it and want to voice your opinion or If you feel like a better time is more suitable, feel free to make a

[openstack-dev] [nova][neutron] massive overhead processing "network-changed" events during live migration

Recently we noticed failures in Newton when we attempted to live-migrate an instance with 16 vifs. We tracked it down to an RPC timeout in nova which timed out waiting for the 'refresh_cache-%s' lock in get_instance_nw_info(). This led to a few other discoveries. First, we have no fair

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

On Fri, May 19, 2017 at 1:04 PM, Sean Dague wrote: > These should be used as ways to experiment with the kinds of interfaces > we want cheaply, then take them back into services (which is a more > expensive process involving compatibility stories, deeper documentation, >

Re: [openstack-dev] [nova] Boston Forum session recap - searchlight integration

On Thu, May 18, 2017 at 4:21 PM, Matt Riedemann wrote: > Since sorting instances across cells is the main issue, it was also > suggested that we allow a config option to disable sorting in the API. It > was stated this would be without a microversion, and filtering/paging

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

Excerpts from Clark Boylan's message of 2017-05-19 10:03:23 -0700: > On Fri, May 19, 2017, at 05:59 AM, Duncan Thomas wrote: > > On 19 May 2017 at 12:24, Sean Dague wrote: > > > > > I do get the concerns of extra logic in Nova, but the decision to break > > > up the working

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

On 05/19/2017 01:38 PM, Dean Troyer wrote: > On Fri, May 19, 2017 at 11:53 AM, Chris Friesen > wrote: >> ..., but it seems to me that the logical >> extension of that is to expose simple orthogonal APIs where the nova boot >> request should only take neutron port ids

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

On Fri, May 19, 2017 at 11:53 AM, Chris Friesen wrote: > ..., but it seems to me that the logical > extension of that is to expose simple orthogonal APIs where the nova boot > request should only take neutron port ids and cinder volume ids. The actual > setup of

Re: [openstack-dev] [gnocchi] Migration to GitHub

On Thu, May 18 2017, Julien Danjou wrote: > I've started to migrate Gnocchi itself to GitHub. The Launchpad bugs > have been re-created at https://github.com/gnocchixyz/gnocchi/issues and > I'll move the repository as soon as all opened reviews are merged. Everything has been merged today so the

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

On Fri, May 19, 2017, at 05:59 AM, Duncan Thomas wrote: > On 19 May 2017 at 12:24, Sean Dague wrote: > > > I do get the concerns of extra logic in Nova, but the decision to break > > up the working compute with network and storage problem space across 3 > > services and APIs

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

On 05/19/2017 07:18 AM, Sean Dague wrote: There was a conversation in the Cell v2 discussion around searchlight that puts me more firmly in the anti enamel camp. Because of some complexities around server list, Nova was planning on using Searchlight to provide an efficient backend. Q: Who in

Re: [openstack-dev] [oslo] Can we stop global requirements update?

Excerpts from Mehdi Abaakouk's message of 2017-05-19 10:23:09 +0200: > On Thu, May 18, 2017 at 03:16:20PM -0400, Mike Bayer wrote: > > > > > >On 05/18/2017 02:37 PM, Julien Danjou wrote: > >>On Thu, May 18 2017, Mike Bayer wrote: > >> > >>>I'm not understanding this? do you mean this? > >> > >>In

Re: [openstack-dev] [all] Onboarding rooms postmortem, what did you do, what worked, lessons learned

Kolla: Attendees - full room (20-30?) Notes - Conflict with kolla-k8s demo probably didn't help While we didn't have etherpad, slides, recording (and video dongle that could fit my laptop), we had great session with analog tools (whiteboard and my voice chords). We walked through architecture of

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

Hi, The next two notification subteam meetings are canceled so the next meeting will be held on 6th of June. https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170606T17 Cheers, gibi __ OpenStack

Re: [openstack-dev] [tripleo] CI Squad Meeting Summary (week 20)

On Fri, May 19, 2017 at 5:23 AM, Attila Darazs wrote: > If the topics below interest you and you want to contribute to the > discussion, feel free to join the next meeting: > > Time: Thursdays, 14:30-15:30 UTC > Place: https://bluejeans.com/4113567798/ > > Full minutes:

[openstack-dev] [nova] Boston Forum session recap - cellsv2

The etherpad for this session is here [1]. The goal of the session was to get some questions answered that the developers had for operators around the topic of cellsv2. The bulk of the time was spent discussing ways to limit instance scheduling retries in a cellsv2 world where placement

Re: [openstack-dev] [all] Onboarding rooms postmortem, what did you do, what worked, lessons learned

On Fri, May 19 2017, Sean Dague wrote: > If you ran a room, please post the project, what you did in the room, > what you think worked, what you would have done differently. If you > attended a room you didn't run, please provide feedback about which one > it was, and what you thought worked /

Re: [openstack-dev] [horizon][api][docs] Feedback requested on proposed formatting change to API docs

On Fri, May 19, 2017 at 8:00 AM, Sean Dague wrote: > On 05/19/2017 08:36 AM, Monty Taylor wrote: > > On 05/17/2017 10:14 AM, Joe Topjian wrote: > >> > >> > >> On Tue, May 16, 2017 at 4:13 PM, Monty Taylor >> > wrote: > >> > >>

[openstack-dev] [Heat] revised structure of the heat-templates repository. Suggestions

Hi, As we know the heat-templates repository has become out of date in some respects and also has been difficult to be maintained from a community perspective. For me the repository is quiet confusing with different styles that are used to show certain aspects and other styles for older

[openstack-dev] [L2-Gateway] Tempest plugin structure

Hello guys, I'm trying to include Neutron L2GW tempest tests into puppet-openstack CI pipeline and I'm having some troubles. I noticed that the structure of the code: https://github.com/openstack/networking-l2gw/tree/master/networking_l2gw/tests It's not as a standard tempest plugin. I was

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

On 18/05/17 20:19, Matt Riedemann wrote: I just wanted to blurt this out since it hit me a few times at the summit, and see if I'm misreading the rooms. For the last few years, Nova has pushed back on adding orchestration to the compute API, and even define a policy for it since it comes up so

Re: [openstack-dev] [all] Onboarding rooms postmortem, what did you do, what worked, lessons learned

Thank you so much for getting this started Sean! I have gotten a lot of feedback that people liked the on-boarding rooms, but I would be interested to know more about what people did so we can coordinate better next time. This round I left a lot of the decisions up to the different teams since

[openstack-dev] [deployment][tripleo][puppet] using puppet to push configuration into etcd

While some efforts are made to support k/v to store OpenStack configurations [1] [2] [3], I spent some time this week to investigate how Puppet modules could still be used to manage data binding, but push the config into etcd instead of the files. A containerized TripleO environment only use

Re: [openstack-dev] [ptg] How to slice the week to minimize conflicts

Emilien Macchi wrote: > On Thu, May 18, 2017 at 5:27 AM, Thierry Carrez wrote: >> After giving it some thought, my current thinking is that we should >> still split the week in two, but should move away from an arbitrary >> horizontal/vertical split. My strawman proposal

Re: [openstack-dev] [nova] Boston Forum session recap - claims in the scheduler (or conductor)

Le 19/05/2017 15:14, Chris Dent a écrit : > On Thu, 18 May 2017, Matt Riedemann wrote: > >> We didn't really get into this during the forum session, but there are >> different opinions within the nova dev team on how to do claims in the >> controller services (conductor vs scheduler). Sylvain

Re: [openstack-dev] [glance][openstack-ansible] Moving on

On Thu, May 18, 2017 at 11:55 PM, Steve Lewis wrote: > It is clear to me now that I won't be able to work on OpenStack as a part of > my next day job, wherever that ends up being. As such, I’ll no longer be > able to invest the time and energy required to maintain my

Re: [openstack-dev] [horizon][api][docs] Feedback requested on proposed formatting change to API docs

On 05/19/2017 08:36 AM, Monty Taylor wrote: > On 05/17/2017 10:14 AM, Joe Topjian wrote: >> >> >> On Tue, May 16, 2017 at 4:13 PM, Monty Taylor > > wrote: >> >> Hey all! >> >> I read the API docs A LOT. (thank you to all of you who have

Re: [openstack-dev] [Keystone] Cockroachdb for Keystone Multi-master

On Fri, 19 May 2017, Adrian Turjak wrote: On 19 May 2017 11:43 am, Curtis wrote: I had thought that the OpenStack community was deprecating Postgres support though, so that could make things a bit harder here (I might be wrong about this). I really

Re: [openstack-dev] [all] Onboarding rooms postmortem, what did you do, what worked, lessons learned

On 05/19/2017 09:22 AM, Sean Dague wrote: > If you ran a room, please post the project, what you did in the room, > what you think worked, what you would have done differently. If you > attended a room you didn't run, please provide feedback about which one > it was, and what you thought worked /

Re: [openstack-dev] [nova] Boston Forum session recap - searchlight integration

On 5/19/2017 1:46 AM, joehuang wrote: Support sort and pagination together will be the biggest challenge: it's up to how many cells will be involved in the query, 3,5 may be OK, you can search each cells, and cached data. But how about 20, 50 or more, and how many data will be cached? More

[openstack-dev] [all] Onboarding rooms postmortem, what did you do, what worked, lessons learned

This is a thread for anyone that participated in the onboarding rooms, on either the presenter or audience side. Because we all went into this creating things from whole cloth, I'm sure there are lots of lessons learned. If you ran a room, please post the project, what you did in the room, what

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

On 05/19/2017 09:04 AM, Chris Dent wrote: > On Fri, 19 May 2017, Duncan Thomas wrote: > >> On 19 May 2017 at 12:24, Sean Dague wrote: >> >>> I do get the concerns of extra logic in Nova, but the decision to break >>> up the working compute with network and storage problem space

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

Here's your placement and resource providers update 23. There wasn't one last week because of summit. As usual, please let me know if there is anything incorrect or missing. # From Summit Placement was all over the place at summit, coming up as a relevant piece of the puzzle in many sessions.

Re: [openstack-dev] [nova] Boston Forum session recap - claims in the scheduler (or conductor)

On Thu, 18 May 2017, Matt Riedemann wrote: We didn't really get into this during the forum session, but there are different opinions within the nova dev team on how to do claims in the controller services (conductor vs scheduler). Sylvain Bauza has a series which uses the conductor service,

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

On Fri, 19 May 2017, Duncan Thomas wrote: On 19 May 2017 at 12:24, Sean Dague wrote: I do get the concerns of extra logic in Nova, but the decision to break up the working compute with network and storage problem space across 3 services and APIs doesn't mean we shouldn't

Re: [openstack-dev] [telemetry] Room during the next PTG

On 18/05/17 05:56 PM, Julien Danjou wrote: > Hi team, > > It's time for us to request a room (or share one) for the next PTG in > September if we want to meet. Last time we did not. Do we want one this > time? > if there are cross project discussions we can line up beforehand, it might be

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

On 19 May 2017 at 12:24, Sean Dague wrote: > I do get the concerns of extra logic in Nova, but the decision to break > up the working compute with network and storage problem space across 3 > services and APIs doesn't mean we shouldn't still make it easy to > express some pretty

Re: [openstack-dev] [horizon][api][docs] Feedback requested on proposed formatting change to API docs

On 05/17/2017 10:14 AM, Joe Topjian wrote: On Tue, May 16, 2017 at 4:13 PM, Monty Taylor > wrote: Hey all! I read the API docs A LOT. (thank you to all of you who have worked on writing them) As I do, a gotcha I hit up

Re: [openstack-dev] [glance][openstack-ansible] Moving on

Thank you, Steve for your help. Hope to see you back. . All the best ☺ Abhishek From: Steve Lewis [mailto:steve...@gmail.com] Sent: Friday, May 19, 2017 9:26 AM To: OpenStack Subject: [openstack-dev] [glance][openstack-ansible] Moving on It is clear to me now that I won't be able to work on

Re: [openstack-dev] [tripleo] CI Squad Meeting Summary (week 20)

On Fri, May 19, 2017 at 5:23 AM, Attila Darazs wrote: > If the topics below interest you and you want to contribute to the > discussion, feel free to join the next meeting: > > Time: Thursdays, 14:30-15:30 UTC > Place: https://bluejeans.com/4113567798/ > > Full minutes:

Re: [openstack-dev] [ptg] How to slice the week to minimize conflicts

On Thu, May 18, 2017 at 5:27 AM, Thierry Carrez wrote: > Hi everyone, > > For the PTG events we have a number of rooms available for 5 days, of > which we need to make the best usage. We also want to keep it simple and > productive, so we want to minimize room changes

Re: [openstack-dev] [glance][openstack-ansible] Moving on

On 05/18/2017 10:55 PM, Steve Lewis wrote: > It is clear to me now that I won't be able to work on OpenStack as a part of > my next day job, wherever that ends up being. As such, I’ll no longer be able > to invest the time and energy required to maintain my involvement in the > community. It's

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

On 05/18/2017 08:19 PM, Matt Riedemann wrote: > I just wanted to blurt this out since it hit me a few times at the > summit, and see if I'm misreading the rooms. > > For the last few years, Nova has pushed back on adding orchestration to > the compute API, and even define a policy for it since it

[openstack-dev] [forum] Writing applications for the VM and Baremetal Platform

A quick summary of what happened in the writing applications for the VM and Baremetal forum session. The etherpad is available here: https://etherpad.openstack.org/p/BOS-forum-using-vm-and-baremetal We had a good number of API users and API developers talking together about the issues facing API

[openstack-dev] [openstack-doc] [dev] What's up doc? Summit recap edition

Hi everyone, The OpenStack manuals project had a really productive week at the OpenStack summit in Boston. You can find a list of all the etherpads and attendees here: https://etherpad.openstack.org/p/docs-summit As we all know, we are rapidly losing key contributors and core reviewers. We

Re: [openstack-dev] [oslo][devstack][tooz][all] etcd 3.x as a base service

On 05/18/2017 07:31 PM, Davanum Srinivas wrote: > Team, > > Please take a look at this devstack review that adds a new etcd3 service: > https://review.openstack.org/#/c/445432/ > > Waiting on infra team to help with creating a directory on > tarballs.openstack.org with etcd release binaries as

Re: [openstack-dev] [nova] Boston Forum session recap - claims in the scheduler (or conductor)

Le 19/05/2017 12:19, John Garbutt a écrit : > On 19 May 2017 at 10:03, Sylvain Bauza wrote: >> >> >> Le 19/05/2017 10:02, Sylvain Bauza a écrit : >>> >>> >>> Le 19/05/2017 02:55, Matt Riedemann a écrit : The etherpad for this session is here [1]. The goal for this

[openstack-dev] [forum] [vm] Action required to help improve Ops <-> Dev feedback loops

Hi, On the ops list I have started a thread about the forum session sumary and the actions needed to keep things going. Please do join in over there: http://lists.openstack.org/pipermail/openstack-operators/2017-May/013448.html Many thanks, johnthetubaguy

Re: [openstack-dev] [nova] Boston Forum session recap - claims in the scheduler (or conductor)

On 19 May 2017 at 10:03, Sylvain Bauza wrote: > > > Le 19/05/2017 10:02, Sylvain Bauza a écrit : >> >> >> Le 19/05/2017 02:55, Matt Riedemann a écrit : >>> The etherpad for this session is here [1]. The goal for this session was >>> to inform operators and get feedback on the

[openstack-dev] [Openstack-dev][Tacker] How to update vnf with user_data

Hi, Someone can help me to update vnf with user_data by using noop or openwrt mgmt_driver. Below is my tosca-config-user-data.yaml vdus: VDU1: config: user_data: | #!/bin/sh echo "my hostname is `hostname`" > /tmp/hostname df -h > /tmp/diskinfo

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

Hi! This new regular email will give you an update on the status of a number of TC-proposed governance changes, in an attempt to rely less on a weekly meeting to convey that information. In this first version, this email will highlight a number of topics requiring more immediate attention. If

[openstack-dev] [tripleo] CI Squad Meeting Summary (week 20)

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

Re: [openstack-dev] [nova] Boston Forum session recap - claims in the scheduler (or conductor)

Le 19/05/2017 10:02, Sylvain Bauza a écrit : > > > Le 19/05/2017 02:55, Matt Riedemann a écrit : >> The etherpad for this session is here [1]. The goal for this session was >> to inform operators and get feedback on the plan for what we're doing >> with moving claims from the computes to the

Re: [openstack-dev] [oslo] Can we stop global requirements update?

On Fri, May 19 2017, Mehdi Abaakouk wrote: > Not really, I just put some comments on reviews and discus this on IRC. > Since nobody except Telemetry have expressed/try to get rid of eventlet. TBH Keystone get rid of it too. But they only provide WSGI servers. They don't build any daemon so they

[openstack-dev] [release] Release countdown for week R-14 and R-13, May 22 - June 2

Welcome to our regular release countdown email! Development Focus - At this stage, a few weeks before the Pike-2 milestone, work on major feature work should be well under way. Team members who had the chance to attend the Forum in Boston should collect their thoughts and bring

Re: [openstack-dev] [gnocchi] Running Gnocchi API in specific interface

Understood. I have submitted a patch to pbr for review here: https://review.openstack.org/#/c/466225/ -- View this message in context: http://openstack.10931.n7.nabble.com/gnocchi-Running-Gnocchi-API-in-specific-interface-tp135004p135095.html Sent from the Developer mailing list archive at

Re: [openstack-dev] [oslo] Can we stop global requirements update?

On Thu, May 18, 2017 at 03:16:20PM -0400, Mike Bayer wrote: On 05/18/2017 02:37 PM, Julien Danjou wrote: On Thu, May 18 2017, Mike Bayer wrote: I'm not understanding this? do you mean this? In the long run, yes. Unfortunately, we're not happy with the way Oslo libraries are managed and

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

Matt Riedemann wrote: > [...] > Am I missing the point, or is the pendulum really swinging away from > PaaS layer services which abstract the dirty details of the lower-level > IaaS APIs? Or was this always something people wanted and I've just > never made the connection until now? I feel like

Re: [openstack-dev] [nova] Boston Forum session recap - claims in the scheduler (or conductor)

Le 19/05/2017 02:55, Matt Riedemann a écrit : > The etherpad for this session is here [1]. The goal for this session was > to inform operators and get feedback on the plan for what we're doing > with moving claims from the computes to the control layer (scheduler or > conductor). > > We mostly

Re: [openstack-dev] [Heat] Heat template example repository

On 18.05.17 15:02, Mehdi Abaakouk wrote: On Thu, May 18, 2017 at 11:26:41AM +0200, Lance Haig wrote: This is not only an Aodh/Ceilometer alarm issue. I can confirm that whatever the resource prefix, this works well. But an alarm description also contains a query an external API to retrieve

Re: [openstack-dev] [nova] Boston Forum session recap - searchlight integration

Support sort and pagination together will be the biggest challenge: it's up to how many cells will be involved in the query, 3,5 may be OK, you can search each cells, and cached data. But how about 20, 50 or more, and how many data will be cached? More over, during the query there are

  1   2   >