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

We chatted a bit about this on IRC. The issue here is that subnets that belong to router:external networks are not visible unless the network is shared as well. So the only way the users can learn about which subnets to pick are in the list of subnet UUIDs in the json body of the network 'subnets'

Re: [openstack-dev] [tripleo] Validations before upgrades and updates

On Wed, May 24, 2017 at 4:09 AM, Graeme Gillies wrote: > On 08/05/17 21:45, Marios Andreou wrote: > > Hi folks, after some discussion locally with colleagues about improving > > the upgrades experience, one of the items that came up was pre-upgrade > > and update

Re: [openstack-dev] [doc][ptls][all] Documentation publishing future

On 廿十七年五月廿四日 朝 09:38, Rochelle Grober wrote: From: Ildiko > On 2017. May 23., at 15:43, Sean McGinnis wrote: On Mon, May 22, 2017 at 05:50:50PM -0500, Anne Gentle wrote: On Mon, May 22, 2017 at 5:41 PM, Sean McGinnis wrote: [snip] Hey

Re: [openstack-dev] [heat] [devstack] [infra] heat api services with uwsgi

On Tue, May 23, 2017 at 11:57 PM, Zane Bitter wrote: > On 23/05/17 01:23, Rabi Mishra wrote: > >> Hi All, >> >> As per the updated community goal[1] for api deployment with wsgi, >> we've to transition to use uwsgi rather than mod_wsgi at the gate. It >> also seems mod_wsgi

Re: [openstack-dev] [gnocchi] Running tests

Ok so started the tests using: tox -e py27-postgresql-file The suite starts running fine, but then I get a failing test: == Failed 1 tests - output below: == gnocchi.tests.test_indexer.TestIndexerDriver.test_list_resources_without_history

[openstack-dev] [Nova] [Cells] Stupid question: Cells v2 & AZs

Hi Devs and Implementers, A question came up tonight in the Colorado OpenStack meetup regarding cells v2 and availability zones. Can a cell contain multiple AZs? (I assume this is yes.) Can an AZ contain mutliple cells (I assumed this is no, but now in thinking about it, that's probably not

Re: [openstack-dev] [murano] Meeting time

Hi Paul, I'm open to changing the meeting time, although I'd like some input from Murano cores, too. What times work for you and your colleagues? I can create a patch in infra and add you and others to it to allow for people to effectively vote for what times you prefer. Felipe On Tue, May 23,

Re: [openstack-dev] [doc][ptls][all] Documentation publishing future

From: Ildiko > On 2017. May 23., at 15:43, Sean McGinnis > wrote: > > > > On Mon, May 22, 2017 at 05:50:50PM -0500, Anne Gentle wrote: > >> On Mon, May 22, 2017 at 5:41 PM, Sean McGinnis > >> > >> wrote: > >> > >>> > >>> [snip] > >>> > >> > >> Hey

Re: [openstack-dev] [tripleo] Validations before upgrades and updates

On 08/05/17 21:45, Marios Andreou wrote: > Hi folks, after some discussion locally with colleagues about improving > the upgrades experience, one of the items that came up was pre-upgrade > and update validations. I took an AI to look at the current status of > tripleo-validations [0] and posted a

Re: [openstack-dev] on the subject of when we should be deprecating API's in a release cycle

> -Original Message- > From: Matt Riedemann [mailto:mriede...@gmail.com] > Sent: Tuesday, May 23, 2017 8:59 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] on the subject of when we should be deprecating > API's in a release cycle > > On 5/23/2017 7:50 PM,

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: NOT Getting rid of the automated reschedule functionality

On 5/23/2017 7:01 PM, Jay Pipes wrote: On 05/23/2017 07:06 PM, Blair Bethwaite wrote: Thanks Jay, I wonder whether there is an easy-ish way to collect stats about the sorts of errors deployers see in that catchall, so that when this comes back around in a release or two there might be some

Re: [openstack-dev] on the subject of when we should be deprecating API's in a release cycle

On 5/23/2017 7:50 PM, Amrith Kumar wrote: TL;DR When IaaS projects in OpenStack deprecate their API's after milestone 1, it puts PaaS projects in a pickle. I think it would be much better for PaaS projects if the IaaS projects could please do their deprecations well before milestone-1 The

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

On Tue, May 23, 2017 at 3:43 PM, Dean Troyer wrote: > On Tue, May 23, 2017 at 3:42 PM, Sean McGinnis > wrote: > > > >> If it's just too much debt and risk of slippery slope type arguments on > >> the Nova side (and that's fair, after lengthy

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

It’s definitely a nice feature to have for end user, actually we implemented it our own because we need this but nova doesn’t support. Yingjun > On May 24, 2017, at 6:58 AM, Jay Bryant wrote: > > > On 5/23/2017 9:56 AM, Duncan Thomas wrote: >> >> >> On 23 May 2017

[openstack-dev] on the subject of when we should be deprecating API's in a release cycle

TL;DR When IaaS projects in OpenStack deprecate their API's after milestone 1, it puts PaaS projects in a pickle. I think it would be much better for PaaS projects if the IaaS projects could please do their deprecations well before milestone-1 The longer issue: OK, the guy from Trove is

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

On 5/23/2017 4:43 PM, Dean Troyer wrote: In this particular case it may not be necessary, but I think early implementation of composite features in clients is actually the right way to prove the utility of these things going forward. Establish and document the process, implement in a way for

Re: [openstack-dev] [tc] Active or passive role with our database layer

On 05/23/2017 07:07 PM, Boris Pavlovic wrote: And how can someone, that is trying to deploy OpenStack, understand/find the right config for db? Or it's Ops tasks and community doesn't care about them? Neither. It's the ops responsibility to understand database configuration fundamentals

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: NOT Getting rid of the automated reschedule functionality

On 05/23/2017 07:06 PM, Blair Bethwaite wrote: Thanks Jay, I wonder whether there is an easy-ish way to collect stats about the sorts of errors deployers see in that catchall, so that when this comes back around in a release or two there might be some less anecdotal data available...? Don't

Re: [openstack-dev] Save the Date- Queens PTG

On 05/23/2017 06:27 PM, Anita Kuno wrote: On 2017-05-23 07:25 PM, Anita Kuno wrote: On 2017-04-05 06:05 PM, Erin Disney wrote: We are excited to announce the September Project Teams Gathering in Denver, CO at the Denver Renaissance Stapleton Hotel this September 11th-15th. As mentioned at the

Re: [openstack-dev] Save the Date- Queens PTG

On 2017-05-23 07:25 PM, Anita Kuno wrote: On 2017-04-05 06:05 PM, Erin Disney wrote: We are excited to announce the September Project Teams Gathering in Denver, CO at the Denver Renaissance Stapleton Hotel this September 11th-15th. As mentioned at the Atlanta PTG feedback session in

Re: [openstack-dev] Save the Date- Queens PTG

On 2017-04-05 06:05 PM, Erin Disney wrote: We are excited to announce the September Project Teams Gathering in Denver, CO at the Denver Renaissance Stapleton Hotel this September 11th-15th. As mentioned at the Atlanta PTG feedback session in February, we had narrowed down our PTG location

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: NOT Getting rid of the automated reschedule functionality

Thanks Jay, I wonder whether there is an easy-ish way to collect stats about the sorts of errors deployers see in that catchall, so that when this comes back around in a release or two there might be some less anecdotal data available...? Cheers, On 24 May 2017 at 06:43, Jay Pipes

Re: [openstack-dev] [tc] Active or passive role with our database layer

Zane, > This is your periodic reminder that we have ~50 applications sharing the > same database and not only do none of them know how the deployer will > configure the database, most will not even have an idea which set of > assumptions the other ~49 are making about how the deployer will

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

On 5/23/2017 9:56 AM, Duncan Thomas wrote: On 23 May 2017 4:51 am, "Matt Riedemann" > wrote: Is this really something we are going to have to deny at least once per release? My God how is it that this is the #1 thing everyone

Re: [Openstack-operators] Routed provider networks...

On Mon, May 22, 2017 at 1:47 PM, Chris Marino wrote: > Hello operators, I will be talking about the new routed provider network > > features in OpenStack at a Meetup >

Re: [openstack-dev] [tc] [all] TC Report 21

On 2017-05-23 20:44:54 +0100 (+0100), Chris Dent wrote: [...] > ## OpenStack moving too fast and too slow [...] > summit happened, people moved on to other things and there wasn't > much in the way of resolution. Is there anything we could or > should be doing here? [...] The session for this

[Openstack] [MassivelyDistributed] IRC Meeting tomorrow15:00 UTC

Dear all, A gentle reminder for our meeting tomorrow. As usual, the agenda is available at: https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 (line 597) Please feel free to add items. Best, ad_rien_ ___ Mailing list:

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

I had expected more cinder/nova sessions the first days, so I like that proposal. If we are able to minimize project overlap or have alternatives the last 3 days I think we are moving towards a better solution. Jay On Fri, May 19, 2017 at 9:18 AM Thierry Carrez wrote: >

Re: [Openstack] Openstack Routed Provider Networks Question

>Then describing the 'segment ID' as a VLAN ID Segment ID is not a VLAN ID. A segment ID is a UUID for a segment, which can contain a segmentation ID of a VLAN ID or VXLAN VNI or it might even be a flat network. It is unfortunate that we have both segment ID and segmentation ID, which is what

[Openstack-operators] [MassivelyDistributed] IRC Meeting tomorrow15:00 UTC

Dear all, A gentle reminder for our meeting tomorrow. As usual, the agenda is available at: https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 (line 597) Please feel free to add items. Best, ad_rien_ ___ OpenStack-operators

[openstack-dev] [MassivelyDistributed] IRC Meeting tomorrow15:00 UTC

Dear all, A gentle reminder for our meeting tomorrow. As usual, the agenda is available at: https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 (line 597) Please feel free to add items. Best, ad_rien_

Re: [Openstack-operators] Routed provider networks...

Kevin, should have been more clear For the specific operator that is running L3 to host, with only a few /20 blocks...dynamic routing is absolutely necessary. The /16 scenario you describe is totally fine without it. CM On Tue, May 23, 2017 at 2:40 PM, Kevin Benton

Re: [Openstack-operators] Routed provider networks...

>Dynamic routing is absolutely necessary, though. Large blocks of 1918 addresses are scarce, even inside the DC. I just described a 65 thousand VM topology and it used a /16. Dynamic routing is not necessary or even helpful in this scenario if you plan on ever running close to your max server

Re: [openstack-dev] [tc] [all] TC Report 21

On 5/23/2017 2:44 PM, Chris Dent wrote: Doing LTS is probably too big for that, but "stable branch reviews" is not. Oh if we only had more things to review on stable branches. It's also just at a bare minimum having people propose backports. Very few people/organizations actually do that

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

On Tue, May 23, 2017 at 3:42 PM, Sean McGinnis wrote: > >> If it's just too much debt and risk of slippery slope type arguments on >> the Nova side (and that's fair, after lengthy conversations with Nova folks >> I get it), do we consider just orchestrating this from say

Re: [Openstack] How to utilize Neutron independently with veths

Neutron sets up the iptables rules if you have security groups enabled and the agent firewall is set to iptables_hybrid or neutron.agent.linux.iptables_firewall:OVSHybridIptablesFirewallDriver . What are you naming your vNIC? The iptables rules setup by the agent match specifically on 'tap' +

Re: [openstack-dev] [tc] Active or passive role with our database layer

On 21/05/17 15:38, Monty Taylor wrote: One might argue that HA strategies are an operator concern, but in reality the set of workable HA strategies is tightly constrained by how the application works, and the pairing an application expecting one HA strategy with a deployment implementing a

Re: [Openstack-operators] DB deadlocks due to connection string

per IRC deliberation, I'll do a patch in oslo.db: * detect incoming URL that is like "mysql://" with no driver (I can set this up for all DBs, though excluding sqlite:// since that one is used by tests) * log warning referring to the issue, rather than a hard-cut over ("the big issue we'll

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

If it's just too much debt and risk of slippery slope type arguments on the Nova side (and that's fair, after lengthy conversations with Nova folks I get it), do we consider just orchestrating this from say OpenStack Client completely? The last resort (and it's an awful option) is

Re: [Openstack-operators] DB deadlocks due to connection string

On 05/23/2017 04:17 PM, Doug Hellmann wrote: On May 23, 2017, at 4:01 PM, Doug Hellmann > wrote: Excerpts from Sean McGinnis's message of 2017-05-23 11:38:34 -0500: This sounds like something we could fix completely by dropping the

Re: [openstack-dev] [doc][ptls][all] Documentation publishing future

I'm in favor of option #1. I think it encourages our developers to become better writers with guidance from the docs team. While ensuring docs are proposed prior to merging the implementation cross-repository is totally possible, I think #1 makes that flow easier. Thanks for putting together the

Re: [openstack-dev] [release][tc][infra][security][stable] Proposal for shipping binaries and containers

On 23 May 2017 at 08:13, Doug Hellmann wrote: > Excerpts from Davanum Srinivas (dims)'s message of 2017-05-23 10:44:30 -0400: >> Team, >> >> Background: >> For projects based on Go and Containers we need to ship binaries, for > > Can you elaborate on the use of the term

Re: [Openstack-operators] DB deadlocks due to connection string

> On May 23, 2017, at 4:01 PM, Doug Hellmann wrote: > > Excerpts from Sean McGinnis's message of 2017-05-23 11:38:34 -0500: >>> >>> This sounds like something we could fix completely by dropping the >>> use of the offending library. I know there was a lot of work done

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

Thanks for the feedback, Curtis, appreciated! On 05/23/2017 04:09 PM, Curtis wrote: On Tue, May 23, 2017 at 1:20 PM, Edward Leafe wrote: On May 23, 2017, at 1:27 PM, James Penick wrote: Perhaps this is a place where the TC and Foundation should step in

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On Tue, 23 May 2017 20:58:20 +0100 (IST), Chris Dent wrote: If we're talking big crazy changes: Why not take the "small VM driver" (presumably nova-compute) out of Nova? What stays behind is _already_ orchestration but missing some features and having a fair few bugs. I've suggested this a

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On Tue, May 23, 2017 at 1:20 PM, Edward Leafe wrote: > On May 23, 2017, at 1:27 PM, James Penick wrote: > >> Perhaps this is a place where the TC and Foundation should step in and >> foster the existence of a porcelain API. Either by constructing something

Re: [openstack-dev] [tc] Active or passive role with our database layer

On 05/23/2017 03:16 PM, Edward Leafe wrote: On May 23, 2017, at 1:43 PM, Jay Pipes wrote: [1] Witness the join constructs in Golang in Kubernetes as they work around etcd not being a relational data store: Maybe it’s just me, but I found that Go code more

Re: [Openstack-operators] DB deadlocks due to connection string

Excerpts from Sean McGinnis's message of 2017-05-23 11:38:34 -0500: > > > > This sounds like something we could fix completely by dropping the > > use of the offending library. I know there was a lot of work done > > to get pymysql support in place. It seems like we can finish that by > >

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On Tue, 23 May 2017, James Penick wrote: I agree that a single entry point to OpenStack would be fantastic. If it existed, scheduling, quota, etc would have moved out of Nova a long time ago, and Nova at this point would be just a small VM driver. Unfortunately such a thing does not yet exist,

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On Tue, May 23, 2017 at 12:20 PM, Edward Leafe wrote: > > > Oh please, not Nova. The last word that comes to mind when thinking about > Nova code is “porcelain”. > Oh I dunno, porcelain is usually associated with so many every day objects. If we really push, we could see a

[openstack-dev] [tc] [all] TC Report 21

With the advent Thierry's weekly status reports[^1] on the proposals currently under review by the TC and the optionality of the weekly TC meetings, this report becomes less about meeting minutes and more about reporting on the things that crossed my TC radar that seemed important and/or that

Re: [openstack-dev] [tc] revised Postgresql deprecation patch for governance

Thanks. It’s more of a question of not leaving people high and dry when they have made a reasonable choice in the past based on the choices supported at the time. Tim On 23.05.17, 21:14, "Sean Dague" wrote: On 05/23/2017 02:35 PM, Tim Bell wrote: > Is there a proposal

Re: [openstack-dev] [tc][all] Missing answers on Pike release goals

Excerpts from John Dickinson's message of 2017-05-23 09:12:29 -0700: > > I can sympathize with the "do it tomorrow" turns into 6 weeks later... > > Part of the issue for me, personally, is that a governance patch > does *not* feel simple or lightweight. I assume (in part based on > experience)

Re: [openstack-dev] [tc] Active or passive role with our database layer

On 05/23/2017 03:16 PM, Edward Leafe wrote: On May 23, 2017, at 1:43 PM, Jay Pipes wrote: [1] Witness the join constructs in Golang in Kubernetes as they work around etcd not being a relational data store: Maybe it’s just me, but I found that Go code more understandable

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On May 23, 2017, at 1:27 PM, James Penick wrote: > Perhaps this is a place where the TC and Foundation should step in and > foster the existence of a porcelain API. Either by constructing something > new, or by growing Nova into that thing. Oh please, not Nova. The last

Re: [openstack-dev] [tc] Active or passive role with our database layer

On May 23, 2017, at 1:43 PM, Jay Pipes wrote: > [1] Witness the join constructs in Golang in Kubernetes as they work around > etcd not being a relational data store: Maybe it’s just me, but I found that Go code more understandable than some of the SQL we are using in the

Re: [openstack-dev] [tc] revised Postgresql deprecation patch for governance

On 05/23/2017 02:35 PM, Tim Bell wrote: > Is there a proposal where deployments who chose Postgres on good faith can > find migration path to a MySQL based solution? Yes, a migration tool exploration is action #2 in the current proposal. Also, to be clear, we're not at the stage of removing

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

On Tue, May 23, 2017 at 10:13 AM, Matt Riedemann wrote: > On 5/23/2017 9:56 AM, Duncan Thomas wrote: > >> Is it entirely unreasonable to turn the question around and ask why, >> given it is such a commonly requested feature, the Nova team are so >> resistant to it? >> > >

Re: [openstack-dev] [tc] Active or passive role with our database layer

On Tue, 23 May 2017, Jay Pipes wrote: Err, in my experience, having a *completely* dumb persistence layer -- i.e. one that tries to assuage the differences between, say, relational and non-relational stores -- is a recipe for disaster. The developer just ends up writing join constructs in

Re: [openstack-dev] [go][all] Settling on gophercloud as the go based API library for all OpenStack projects

On Tue, May 23, 2017 at 12:48 PM, Davanum Srinivas wrote: > John, > > I had heard this a few time in Boston Summit. So want to put this to bed :) > > -- Dims > > On Tue, May 23, 2017 at 2:43 PM, John Griffith > wrote: > > > > > > On Tue, May 23, 2017

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

On 19/05/17 19:53, Kevin Benton wrote: 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

Re: [openstack-dev] [go][all] Settling on gophercloud as the go based API library for all OpenStack projects

John, I had heard this a few time in Boston Summit. So want to put this to bed :) -- Dims On Tue, May 23, 2017 at 2:43 PM, John Griffith wrote: > > > On Tue, May 23, 2017 at 8:54 AM, Davanum Srinivas wrote: >> >> Folks, >> >> This has come up

Re: [openstack-dev] [tc] Active or passive role with our database layer

On 05/23/2017 07:23 AM, Chris Dent wrote: That "higher dev cost" is one of my objections to the 'active' approach but it is another implication that worries me more. If we limit deployer architecture choices at the persistence layer then it seems very likely that we will be tempted to build more

Re: [openstack-dev] [go][all] Settling on gophercloud as the go based API library for all OpenStack projects

On Tue, May 23, 2017 at 8:54 AM, Davanum Srinivas wrote: > Folks, > > This has come up several times in various conversations. > > Can we please stop activity on > https://git.openstack.org/cgit/openstack/golang-client/ and just > settle down on

[Openstack-operators] [publiccloud-wg] Tomorrows meeting PublicCloudWorkingGroup

Hi everyone, First of all, really fun to see the interest for the group and the forum sessions we moderated in Boston. I hope that we can keep up that spirit and looking forward to a lot of participants in the bi-weekly meetings for this cycle. So, reminder for tomorrows meeting for the

Re: [openstack-dev] [tc] revised Postgresql deprecation patch for governance

Is there a proposal where deployments who chose Postgres on good faith can find migration path to a MySQL based solution? Tim On 23.05.17, 18:35, "Octave J. Orgeron" wrote: As OpenStack has evolved and grown, we are ending up with more and more MySQL-isms

[openstack-dev] [publiccloud-wg] Tomorrows meeting PublicCloudWorkingGroup

Hi everyone, First of all, really fun to see the interest for the group and the forum sessions we moderated in Boston. I hope that we can keep up that spirit and looking forward to a lot of participants in the bi-weekly meetings for this cycle. So, reminder for tomorrows meeting for the

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On Tue, May 23, 2017 at 8:52 AM, Jay Pipes wrote: > > If Heat was more widely deployed, would you feel this way? Would you > reconsider having Heat as one of those "basic compute services" in > OpenStack, then? > > (Caveat: I haven't looked at Heat in at least a year) I

Re: [openstack-dev] [heat] [devstack] [infra] heat api services with uwsgi

On 23/05/17 01:23, Rabi Mishra wrote: Hi All, As per the updated community goal[1] for api deployment with wsgi, we've to transition to use uwsgi rather than mod_wsgi at the gate. It also seems mod_wsgi support would be removed from devstack in Queens. I've been working on a patch[2] for the

Re: [Openstack-operators] Mitaka and gnocchi

On 23/05/17 10:16 AM, mate...@mailbox.org wrote: > / 2017-05-23 13:29:10.961 1931583 ERROR ceilometer.dispatcher.gnocchi > [-] Failed to connect to Gnocchi./ > /2017-05-23 13:29:10.962 1931583 ERROR stevedore.extension [-] Could not > load 'gnocchi': Unexpected exception for >

Re: [Openstack-operators] DB deadlocks due to connection string

One scenario would be to change the default and allow the exceptions to opt out (e.g. mysql-pymysql ( Tim On 23.05.17, 19:08, "Matt Riedemann" wrote: On 5/23/2017 11:38 AM, Sean McGinnis wrote: >> >> This sounds like something we could fix completely by

Re: [openstack-dev] [tc] Active or passive role with our database layer

On 05/23/2017 01:10 PM, Octave J. Orgeron wrote: Comments below.. On 5/21/2017 1:38 PM, Monty Taylor wrote: For example: An HA strategy using slave promotion and a VIP that points at the current write master paired with an application incorrectly configured to do such a thing can lead to

[Openstack-operators] CockroachDB for Core Services

All, Now that cockroachdb has reached v1 and appears to be compatible with sqlalchemy (https://www.cockroachlabs.com/blog/building-application-cockroachdb-sqlalchemy-2/), has anyone tried using it as the backend for any of the service databases? Wondering how far away it is from

Re: [Openstack] Openstack Routed Provider Networks Question

Hello, Vrack based networks are little bit different. We made it by self in OVH. It allows users to create tenant networks and connect them with e.g. dedicated servers. From Openstack user point of view it is similar to vlan network but it’s done littlebit different. Traffic from host in

Re: [Openstack] How to utilize Neutron independently with veths

Afaik, iptables are set by Nova, and the driver is set via firewall_driver option in nova.conf On Tue, May 23, 2017 at 12:15 AM, duhongwei wrote: > > Thanks Kevin! I've made a big step forward! > > Till now, I've successfully connect *vNIC* directly into *br-int *without >

Re: [openstack-dev] [TripleO] A proposal for hackathon to reduce deploy time of TripleO

On Tue, May 23, 2017 at 9:40 AM, Emilien Macchi wrote: > On Tue, May 23, 2017 at 6:47 AM, Sagi Shnaidman wrote: >> Hi, all >> >> I'd like to propose an idea to make one or two days hackathon in TripleO >> project with main goal - to reduce deployment time

Re: [openstack-dev] [openstack-ansible][security] Rename openstack-ansible-security role?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/17/2017 12:25 PM, Major Hayden wrote: > So my questions are: > > 1) Should the openstack-ansible-security role be > renamed to alleviate confusion? > > 2) If it should be renamed, what's your suggestion? Thanks for all of the

[Openstack-operators] Eventbrite - Ops Meet-up Mexico City

Tom, It is time to create the Eventbrite for the Ops Meet-up in Mexico City. I was told you are the man helping us on this area. I have also started the etherpad for the meet-up that we can use as a reference. https://etherpad.openstack.org/p/MEX-ops-meetup Let me know what you need to create

Re: [Openstack-operators] DB deadlocks due to connection string

On 5/23/2017 11:38 AM, Sean McGinnis wrote: This sounds like something we could fix completely by dropping the use of the offending library. I know there was a lot of work done to get pymysql support in place. It seems like we can finish that by removing support for the old library and

Re: [openstack-dev] [tc] Active or passive role with our database layer

Comments below.. On 5/21/2017 1:38 PM, Monty Taylor wrote: Hi all! As the discussion around PostgreSQL has progressed, it has come clear to me that there is a decently deep philosophical question on which we do not currently share either definition or agreement. I believe that the lack of

Re: [openstack-dev] [tc] revised Postgresql deprecation patch for governance

As OpenStack has evolved and grown, we are ending up with more and more MySQL-isms in the code. I'd love to see OpenStack support every database out there, but that is becoming more and more difficult. I've tried to get OpenStack to work with other databases like Oracle DB, MongoDB, TimesTen,

Re: [openstack-dev] [go][all] Settling on gophercloud as the go based API library for all OpenStack projects

+1 as again it can assist us as an entire community (dev/non-dev) to galvanize around one tool On Tue, May 23, 2017 at 3:32 PM, Sean McGinnis wrote: > On Tue, May 23, 2017 at 10:54:13AM -0400, Davanum Srinivas wrote: > > Folks, > > > > This has come up several times in

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

On 5/23/2017 9:56 AM, Duncan Thomas wrote: Is it entirely unreasonable to turn the question around and ask why, given it is such a commonly requested feature, the Nova team are so resistant to it? Because it's technical debt for one thing. Adding more orchestration adds complexity, which

Re: [openstack-dev] [tc][all] Missing answers on Pike release goals

On 23 May 2017, at 8:05, Doug Hellmann wrote: > Excerpts from Sean McGinnis's message of 2017-05-23 08:58:08 -0500: - Is it that the reporting process is too heavy ? (requiring answers from projects that are obviously unaffected) >>> >>> I've thought about this, OSC was

Re: [openstack-dev] [ironic] why is glance image service code so complex?

On 05/23/2017 05:52 PM, Pavlo Shchelokovskyy wrote: Hi all, I've started to dig through the part of Ironic code that deals with glance and I am confused by some things: 1) Glance image service classes have methods to create, update and delete images. What's the use case behind them? Is

[openstack-dev] [murano] Meeting time

Hi Felipe / Murano community, I was wondering how would people feel about revising the time for the Murano weekly meeting? Personally the current time is difficult for me to attend as it falls at the end of a work day, I also have some colleagues that would like to attend but can't at the

Re: [openstack-dev] [release] Issues with reno

Excerpts from Matt Riedemann's message of 2017-05-22 21:48:37 -0500: > I think Doug and I have talked about this before, but it came up again > tonight. > > There seems to be an issue where release notes for the current series > don't show up in the published release notes, but unreleased

Re: [openstack-dev] [TripleO] A proposal for hackathon to reduce deploy time of TripleO

On Tue, May 23, 2017 at 6:47 AM, Sagi Shnaidman wrote: > Hi, all > > I'd like to propose an idea to make one or two days hackathon in TripleO > project with main goal - to reduce deployment time of TripleO. > > - How could it be arranged? > > We can arrange a separate IRC

Re: [Openstack-operators] DB deadlocks due to connection string

Excerpts from Arne Wiebalck's message of 2017-05-23 15:50:43 +: > As discussed on the Cinder channel, I’ve opened > > https://bugs.launchpad.net/oslo.db/+bug/1692956 > > to see if oslo.db would be a good place to produce a warning when it detects > this potential misconfiguration. This

Re: [openstack-dev] [doc][ptls][all] Documentation publishing future

Hi Alex, First of all thank you for writing this up the summary and list options with their expected impacts. > > 1. We could combine all of the documentation builds, so that each project has > a single doc/source directory that includes developer, contributor, and user > documentation. This

Re: [openstack-dev] [release][infra][puppet][stable] Re: [Release-job-failures] Release of openstack/puppet-nova failed

On Mon, May 22, 2017 at 3:43 PM, Doug Hellmann wrote: > Excerpts from Jeremy Stanley's message of 2017-05-22 19:16:34 +: >> On 2017-05-22 12:31:49 -0600 (-0600), Alex Schultz wrote: >> > On Mon, May 22, 2017 at 10:34 AM, Jeremy Stanley wrote: >> > >

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On 05/22/2017 03:36 PM, Sean Dague wrote: On 05/22/2017 02:45 PM, James Penick wrote: I recognize that large Ironic users expressed their concerns about IPMI/BMC communication being unreliable and not wanting to have users manually retry a baremetal instance launch. But, on

Re: [Openstack-operators] DB deadlocks due to connection string

As discussed on the Cinder channel, I’ve opened https://bugs.launchpad.net/oslo.db/+bug/1692956 to see if oslo.db would be a good place to produce a warning when it detects this potential misconfiguration. Cheers, Arne On 23 May 2017, at 17:25, Sean McGinnis

[openstack-dev] [ironic] why is glance image service code so complex?

Hi all, I've started to dig through the part of Ironic code that deals with glance and I am confused by some things: 1) Glance image service classes have methods to create, update and delete images. What's the use case behind them? Is ironic supposed to actively manage images? Besides, these do

Re: [Openstack-operators] UTC 14:00 henceforth for Ops Meet Up planning

Many thanks to David for running this poll. We desperately needed a more popular slot. Minutes for today's meeting : Meeting ended Tue May 23 15:43:14 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 11:43 AM O Minutes:

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On 05/23/2017 09:48 AM, Marc Heckmann wrote: For the anti-affinity use case, it's really useful for smaller or medium size operators who want to provide some form of failure domains to users but do not have the resources to create AZ's at DC or even at rack or row scale. Don't forget that as

Re: [Openstack-operators] UTC 14:00 henceforth for Ops Meet Up planning

Ah, excellent question sean. This is an IRC meeting that occurs weekly currently at 14:00 (starting next week) on Tuesdays in Freenode at #openstack-operators (the current one is just wrapping up) On Tue, May 23, 2017 at 9:34 AM, Sean McGinnis wrote: > On Tue, May 23,

Re: [openstack-dev] Save the Date- Queens PTG

W dniu 06.04.2017 o 00:05, Erin Disney pisze: > We will share registration and sponsorship information soon on this > mailing list. Mark your calendars and we hope to see you in Denver! Any update? I need to collect info about costs for my trip.

Re: [Openstack-operators] UTC 14:00 henceforth for Ops Meet Up planning

On Tue, May 23, 2017 at 09:16:13AM -0600, David Medberry wrote: > I have picked "Tuesday, May 30, 2017 8:00 AM (Time zone: Mountain Time)" as > final option(s) for the Doodle poll "Ops Meetup Preferred Time." Hey David, Sorry, I'm sure this was stated elsewhere, but where is this meeting held?

Re: [openstack-dev] [go][all] Settling on gophercloud as the go based API library for all OpenStack projects

On Tue, May 23, 2017 at 10:54:13AM -0400, Davanum Srinivas wrote: > Folks, > > This has come up several times in various conversations. > > Can we please stop activity on > https://git.openstack.org/cgit/openstack/golang-client/ and just > settle down on

  1   2   >