[openstack-dev] [nova] Can we deprecate the server backup API please?

The server backup API was added 8 years ago. It has Nova basically implementing a poor-man's cron for some unknown reason (probably because the original RAX Cloud Servers API had some similar or identical functionality, who knows...). Can we deprecate this functionality please? It's confusing

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

On 11/02/2018 03:22 PM, Eric Fried wrote: All- Based on a (long) discussion yesterday [1] I have put up a patch [2] whereby you can set [compute]resource_provider_association_refresh to zero and the resource tracker will never* refresh the report client's provider cache. Philosophically, we're

Re: [openstack-dev] [all] We're combining the lists!

I'm not willing to subscribe with a password over a non-TLS connection... -jay On 10/29/2018 12:53 PM, Jeremy Stanley wrote: REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this is being sent) will be replaced by a new

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On 10/25/2018 02:44 PM, melanie witt wrote: On Thu, 25 Oct 2018 14:00:08 -0400, Jay Pipes wrote: On 10/25/2018 01:38 PM, Chris Friesen wrote: On 10/24/2018 9:10 AM, Jay Pipes wrote: Nova's API has the ability to create "quota classes", which are basically limits for a set of reso

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On 10/25/2018 01:38 PM, Chris Friesen wrote: On 10/24/2018 9:10 AM, Jay Pipes wrote: Nova's API has the ability to create "quota classes", which are basically limits for a set of resource types. There is something called the "default quota class" which corre

Re: [openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

On 10/24/2018 02:57 PM, Matt Riedemann wrote: On 10/24/2018 10:10 AM, Jay Pipes wrote: I'd like to propose deprecating this API and getting rid of this functionality since it conflicts with the new Keystone /limits endpoint, is highly coupled with RAX's turnstile middleware and I can't seem

[openstack-dev] [nova][limits] Does ANYONE at all use the quota class functionality in Nova?

Nova's API has the ability to create "quota classes", which are basically limits for a set of resource types. There is something called the "default quota class" which corresponds to the limits in the CONF.quota section. Quota classes are basically templates of limits to be applied if the

Re: [openstack-dev] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge"

On 10/18/2018 10:23 AM, Dmitry Tantsur wrote: Hi all, Sorry for chiming in really late in this topic, but I think $subj is worth discussing until we settle harder on the potentially confusing terminology. I think the difference between "Edge" and "Far Edge" is too vague to use these terms

Re: [openstack-dev] [nova] shall we do a spec review day next tuesday oct 23?

Works for me too, thanks Melanie. On Mon, Oct 15, 2018, 10:07 AM melanie witt wrote: > Hey all, > > Milestone s-1 is coming up next week on Thursday Oct 25 [1] and I was > thinking it would be a good idea to have a spec review day next week on > Tuesday Oct 23 to spend some focus on spec

Re: [openstack-dev] [kolla][tc] add service discovery, proxysql, vault, fabio and FQDN endpoints

On 10/11/2018 01:08 PM, Zane Bitter wrote: On 10/10/18 1:35 PM, Jay Pipes wrote: +tc topic On 10/10/2018 11:49 AM, Fox, Kevin M wrote: Sorry. Couldn't quite think of the name. I was meaning, openstack project tags. I think having a tag that indicates the project is no longer using SELECT

Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

On 10/10/2018 01:41 PM, Greg Hill wrote: I've been out of the openstack loop for a few years, so I hope this reaches the right folks. Josh Harlow (original author of taskflow and related libraries) and I have been discussing the option of moving taskflow out of the openstack umbrella

Re: [openstack-dev] [kolla][tc] add service discovery, proxysql, vault, fabio and FQDN endpoints

, Kevin. ++ -jay From: Jay Pipes [jaypi...@gmail.com] Sent: Tuesday, October 09, 2018 12:22 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints On 10/09/2018 03:10 PM

Re: [openstack-dev] [python3] Enabling py37 unit tests

On 10/10/2018 09:42 AM, Corey Bryant wrote: On Wed, Oct 10, 2018 at 9:26 AM Andreas Jaeger > wrote: On 10/10/2018 14.45, Corey Bryant wrote: > [...] > == Enabling py37 unit tests == > > Ubuntu Bionic (18.04 LTS) has the 3.7.0 interpreter and I have

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

On 10/10/2018 06:32 AM, Balázs Gibizer wrote: Hi, Thanks for all the feedback. I feel the following consensus is forming: 1) remove the force flag in a new microversion. I've proposed a spec about that API change [1] +1 2) in the old microversions change the blind allocation copy to gather

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

On 10/09/2018 05:01 PM, Eric Fried wrote: On 10/09/2018 02:20 PM, Jay Pipes wrote: On 10/09/2018 11:04 AM, Balázs Gibizer wrote: If you do the force flag removal in a nw microversion that also means (at least to me) that you should not change the behavior of the force flag in the old

Re: [openstack-dev] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints

On 10/09/2018 03:10 PM, Fox, Kevin M wrote: Oh, this does raise an interesting question... Should such information be reported by the projects up to users through labels? Something like, "percona_multimaster=safe" Its really difficult for folks to know which projects can and can not be used

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

On 10/09/2018 11:04 AM, Balázs Gibizer wrote: If you do the force flag removal in a nw microversion that also means (at least to me) that you should not change the behavior of the force flag in the old microversions. Agreed. Keep the old, buggy and unsafe behaviour for the old microversion

Re: [openstack-dev] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints

On 10/09/2018 06:34 AM, Florian Engelmann wrote: Am 10/9/18 um 11:41 AM schrieb Jay Pipes: On 10/09/2018 04:34 AM, Christian Berendt wrote: On 8. Oct 2018, at 19:48, Jay Pipes wrote: Why not send all read and all write traffic to a single haproxy endpoint and just have haproxy spread all

Re: [openstack-dev] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints

On 10/09/2018 04:34 AM, Christian Berendt wrote: On 8. Oct 2018, at 19:48, Jay Pipes wrote: Why not send all read and all write traffic to a single haproxy endpoint and just have haproxy spread all traffic across each Galera node? Galera, after all, is multi-master synchronous replication

Re: [openstack-dev] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints

On 10/08/2018 06:14 AM, Florian Engelmann wrote: 3. HAProxy is not capable to handle "read/write" split with Galera. I would like to introduce ProxySQL to be able to scale Galera. Why not send all read and all write traffic to a single haproxy endpoint and just have haproxy spread all traffic

Re: [openstack-dev] [nova] [ironic] agreement on how to specify options that impact scheduling and configuration

Added [ironic] topic. On 10/04/2018 06:06 PM, Chris Friesen wrote: While discussing the "Add HPET timer support for x86 guests" blueprint[1] one of the items that came up was how to represent what are essentially flags that impact both scheduling and configuration.  Eric Fried posted a spec

Re: [openstack-dev] [ironic] Tenks

On 10/02/2018 08:58 AM, Mark Goddard wrote: Hi, In the most recent Ironic meeting we discussed [1] tenks, and the possibility of adding the project under Ironic governance. We agreed to move the discussion to the mailing list. I'll introduce the project here and give everyone a chance to ask

Re: [openstack-dev] [Openstack-operators] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter

On 10/01/2018 06:04 PM, Julia Kreger wrote: On Mon, Oct 1, 2018 at 2:41 PM Eric Fried wrote: > So say the user requests a node that supports UEFI because their image > needs UEFI. Which workflow would you want here? > > 1) The operator (or ironic?) has already

Re: [openstack-dev] [placement] The "intended purpose" of traits

On 10/01/2018 01:20 PM, Eric Fried wrote: I agree that we should not overload placement as a mechanism to pass configuration information ("set up RAID5 on my storage, please") to the driver. So let's put that aside. (Looking forward to that spec.) ack. I still want to use something like "Is

Re: [openstack-dev] [Openstack-operators] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter

On 10/01/2018 09:01 AM, Jim Rollenhagen wrote: On Mon, Oct 1, 2018 at 8:03 AM Jay Pipes <mailto:jaypi...@gmail.com>> wrote: On 10/01/2018 04:36 AM, John Garbutt wrote: > On Fri, 28 Sep 2018 at 00:46, Jay Pipes mailto:jaypi...@gmail.com> > <mailto:jaypi...@gm

Re: [openstack-dev] [Openstack-operators] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter

On 10/01/2018 04:36 AM, John Garbutt wrote: On Fri, 28 Sep 2018 at 00:46, Jay Pipes <mailto:jaypi...@gmail.com>> wrote: On 09/27/2018 06:23 PM, Matt Riedemann wrote: > On 9/27/2018 3:02 PM, Jay Pipes wrote: >> A great example of this would be the propose

Re: [openstack-dev] [placement] The "intended purpose" of traits

On 09/28/2018 04:36 PM, Eric Fried wrote: So here it is. Two of the top influencers in placement, one saying we shouldn't overload traits, the other saying we shouldn't add a primitive that would obviate the need for that. Historically, this kind of disagreement seems to result in an impasse:

Re: [openstack-dev] [placement] The "intended purpose" of traits

On 09/28/2018 04:42 PM, Eric Fried wrote: On 09/28/2018 09:41 AM, Balázs Gibizer wrote: On Fri, Sep 28, 2018 at 3:25 PM, Eric Fried wrote: It's time somebody said this. Every time we turn a corner or look under a rug, we find another use case for provider traits in placement. But every time

Re: [openstack-dev] [placement] The "intended purpose" of traits

On 09/28/2018 09:25 AM, Eric Fried wrote: It's time somebody said this. Every time we turn a corner or look under a rug, we find another use case for provider traits in placement. But every time we have to have the argument about whether that use case satisfies the original "intended purpose"

Re: [openstack-dev] [Openstack-operators] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter

On 09/27/2018 06:23 PM, Matt Riedemann wrote: On 9/27/2018 3:02 PM, Jay Pipes wrote: A great example of this would be the proposed "deploy template" from [2]. This is nothing more than abusing the placement traits API in order to allow passthrough of instance configuration data from

Re: [openstack-dev] [nova] Stein PTG summary

On 09/27/2018 11:15 AM, Eric Fried wrote: On 09/27/2018 07:37 AM, Matt Riedemann wrote: On 9/27/2018 5:23 AM, Sylvain Bauza wrote: On Thu, Sep 27, 2018 at 2:46 AM Matt Riedemann mailto:mriede...@gmail.com>> wrote:     On 9/26/2018 5:30 PM, Sylvain Bauza wrote: > So, during this day,

Re: [openstack-dev] [cinder][glance][ironic][keystone][neutron][nova][edge] PTG summary on edge discussions

On 09/26/2018 05:10 AM, Colleen Murphy wrote: Thanks for the summary, Ildiko. I have some questions inline. On Tue, Sep 25, 2018, at 11:23 AM, Ildiko Vancsa wrote: We agreed to prefer federation for Keystone and came up with two work items to cover missing functionality: * Keystone to

Re: [openstack-dev] [penstack-dev]Discussion about the future of OpenStack in China

Fred, I had a hard time understanding the articles. I'm not sure if you used Google Translate to do the translation from Chinese to English, but I personally found both of them difficult to follow. There were a couple points that I did manage to decipher, though. One thing that both

Re: [openstack-dev] [ironic][edge] Notes from the PTG

On 09/19/2018 11:03 AM, Jim Rollenhagen wrote: On Wed, Sep 19, 2018 at 8:49 AM, Jim Rollenhagen > wrote: Tuesday: edge Since cdent asked in IRC, when we talk about edge and far edge, we defined these roughly like this:

Re: [openstack-dev] Nominating Tetsuro Nakamura for placement-core

On 09/19/2018 11:25 AM, Chris Dent wrote: I'd like to nominate Tetsuro Nakamura for membership in the placement-core team. Throughout placement's development Tetsuro has provided quality reviews; done the hard work of creating rigorous functional tests, making them fail, and fixing them; and

Re: [openstack-dev] [tc] notes from stein ptg meetings of the technical committee

On 09/17/2018 04:50 PM, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-09-17 16:12:30 -0400: On 17/09/18 3:06 PM, Jay Pipes wrote: On 09/17/2018 01:31 PM, Doug Hellmann wrote: New Project Application Process === We wrapped up Sunday

Re: [openstack-dev] [nova] When can/should we change additionalProperties=False in GET /servers(/detail)?

On 09/17/2018 03:28 PM, Matt Riedemann wrote: This is a question from a change [1] which adds a new changes-before filter to the servers, os-instance-actions and os-migrations APIs. For context, the os-instance-actions API stopped accepting undefined query parameters in 2.58 when we added

Re: [openstack-dev] [tc] notes from stein ptg meetings of the technical committee

On 09/17/2018 01:31 PM, Doug Hellmann wrote: New Project Application Process === We wrapped up Sunday with a discussion of of our process for reviewing new project applications. Zane and Chris in particular felt the process for Adjutant was too painful for the

Re: [openstack-dev] [nova] how nova should behave when placement returns consumer generation conflict

Thanks Giblet, Will review this afternoon. Best, -jay On 09/17/2018 09:10 AM, Balázs Gibizer wrote: Hi, Reworked and rebased the series based on this thread. The series starts here https://review.openstack.org/#/c/591597 Cheers, gibi

Re: [openstack-dev] About microversion setting to enable nested resource provider

somewhere I could set microversion(some configure file?), Or just modify the source code to set it? > > BR. > Naichuan Sun > > -Original Message- > From: Jay Pipes [mailto:jaypi...@gmail.com &

Re: [openstack-dev] About microversion setting to enable nested resource provider

On 09/13/2018 06:39 AM, Naichuan Sun wrote: Hi, guys, Looks n-rp is disabled by default because microversion matches 1.29 : https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/handlers/allocation_candidate.py#L252 Anyone know how to set the microversion to enable n-rp

Re: [openstack-dev] [ptg][cinder][placement] etherpad for this afternoon's meeting

Hi Jay, where is this discussion taking place? On Tue, Sep 11, 2018, 11:10 AM Jay S Bryant wrote: > All, > > I have created an etherpad to take notes during our meeting this > afternoon: > https://etherpad.openstack.org/p/cinder-placement-denver-ptg-2018 > > If you have information you want to

Re: [openstack-dev] [nova][placement][upgrade][qa] Some upgrade-specific news on extraction

On 09/07/2018 11:17 AM, Dan Smith wrote: The other obvious thing is the database. The placement repo code as-is today still has the check for whether or not it should use the placement database but falls back to using the nova_api database [5]. So technically you could point the extracted

Re: [openstack-dev] better name for placement

On 09/05/2018 11:48 AM, Jeremy Stanley wrote: On 2018-09-05 17:01:49 +0200 (+0200), Thomas Goirand wrote: [...] In a distro, no 2 package can hold the same file. That's forbidden. This has nothing to do if someone has to "import placemement" or not. Just saying this, but *not* that we should

Re: [openstack-dev] better name for placement

On 09/04/2018 01:17 PM, Balázs Gibizer wrote: On Tue, Sep 4, 2018 at 7:01 PM, Jay Pipes wrote: On 09/04/2018 12:59 PM, Balázs Gibizer wrote: On Tue, Sep 4, 2018 at 6:25 PM, Jay Pipes wrote: On 09/04/2018 12:17 PM, Doug Hellmann wrote: Excerpts from Jay Pipes's message of 2018-09-04 12:08

Re: [openstack-dev] better name for placement

On 09/04/2018 12:59 PM, Balázs Gibizer wrote: On Tue, Sep 4, 2018 at 6:25 PM, Jay Pipes wrote: On 09/04/2018 12:17 PM, Doug Hellmann wrote: Excerpts from Jay Pipes's message of 2018-09-04 12:08:41 -0400: On 09/04/2018 11:44 AM, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2018

Re: [openstack-dev] better name for placement

On 09/04/2018 12:17 PM, Doug Hellmann wrote: Excerpts from Jay Pipes's message of 2018-09-04 12:08:41 -0400: On 09/04/2018 11:44 AM, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2018-09-04 15:32:12 +0100: On Tue, 4 Sep 2018, Jay Pipes wrote: Is there a reason we couldn't have

Re: [openstack-dev] better name for placement

On 09/04/2018 11:44 AM, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2018-09-04 15:32:12 +0100: On Tue, 4 Sep 2018, Jay Pipes wrote: Is there a reason we couldn't have openstack-placement be the package name? I would hope we'd be able to do that, and probably should do

Re: [openstack-dev] better name for placement

On 09/04/2018 09:37 AM, Jeremy Stanley wrote: On 2018-09-04 09:32:20 +0100 (+0100), Chris Dent wrote: [...] it allowed for the possibility that there could be another project which provided the same service-type. That hasn't really come to pass [...] It still might make sense to attempt to

Re: [openstack-dev] Nominating Chris Dent for placement-core

On 08/31/2018 11:45 AM, Eric Fried wrote: The openstack/placement project [1] and its core team [2] have been established in gerrit. I hereby nominate Chris Dent for membership in the placement-core team. He has been instrumental in the design, implementation, and stewardship of the placement

Re: [openstack-dev] [chef] fog-openstack 0.2.0 breakage

Thanks for notifying about this, Samuel. Our most modern deployment is actually currently blocked on this and I'm glad to see a resolution. Best, -jay On 08/31/2018 11:59 AM, Samuel Cassiba wrote: Ohai! fog-openstack 0.2.0 was recently released, which had less than optimal effects on Chef

Re: [openstack-dev] [neutron][nova] Small bandwidth demo on the PTG

On 08/30/2018 04:55 AM, Balázs Gibizer wrote: Hi, Based on the Nova PTG planning etherpad [1] there is a need to talk about the current state of the bandwidth work [2][3]. Bence (rubasov) has already planned to show a small demo to Neutron folks about the current state of the implementation.

Re: [openstack-dev] [nova] [placement] XenServer CI failed frequently because of placement update

I think the immediate solution would be to just set cpu_allocation_ratio to 16.0 in the nova.CONF that your CI system is using. Best, -jay On 08/29/2018 05:26 AM, Naichuan Sun wrote: Hi, Eric and Jay, The VCPU/Disk/RAM allocation ratio are set to 0.0 by default, and resource tracker would

Re: [openstack-dev] [api] Open API 3.0 for OpenStack API

On 08/29/2018 02:36 AM, Edison Xiang wrote: Based on Open API 3.0, it can bring lots of benefits for OpenStack Community and does not impact the current features the Community has. 3rd party developers can also do some self-defined development. Hi Edison, Would you mind expanding on what

Re: [openstack-dev] [nova] [placement] XenServer CI failed frequently because of placement update

ck.org/#/c/590041/ On 08/28/2018 07:54 AM, Jay Pipes wrote: On 08/28/2018 04:17 AM, Naichuan Sun wrote: Hi, experts, XenServer CI failed frequently with an error "No valid host was found. " for more than a week. I think it is cause by placement update. Hi Naichuan, Can you give u

Re: [openstack-dev] [nova] [placement] XenServer CI failed frequently because of placement update

On 08/28/2018 04:17 AM, Naichuan Sun wrote: Hi, experts, XenServer CI failed frequently with an error "No valid host was found. " for more than a week. I think it is cause by placement update. Hi Naichuan, Can you give us a link to the logs a patchset's Citrix XenServer CI that has failed?

Re: [openstack-dev] [nova] [placement] extraction (technical) update

On 08/27/2018 11:31 AM, Matt Riedemann wrote: On 8/24/2018 7:36 AM, Chris Dent wrote: Over the past few days a few of us have been experimenting with extracting placement to its own repo, as has been discussed at length on this list, and in some etherpads:

Re: [openstack-dev] [nova] how nova should behave when placement returns consumer generation conflict

On 08/22/2018 08:55 AM, Balázs Gibizer wrote: On Fri, Aug 17, 2018 at 5:40 PM, Eric Fried wrote: gibi-  - On migration, when we transfer the allocations in either direction, a  conflict means someone managed to resize (or otherwise change  allocations?) since the last time we pulled data.

Re: [openstack-dev] [nova] how nova should behave when placement returns consumer generation conflict

Sorry for the delay in responding to this, Gibi and Eric. Comments inline. tl;dr: go with option a) On 08/16/2018 11:34 AM, Eric Fried wrote: Thanks for this, gibi. TL;DR: a). I didn't look, but I'm pretty sure we're not caching allocations in the report client. Today, nobody outside of nova

Re: [openstack-dev] [oslo] UUID sentinel needs a home

On 08/24/2018 07:51 PM, Matt Riedemann wrote: On 8/23/2018 2:05 PM, Chris Dent wrote: On Thu, 23 Aug 2018, Dan Smith wrote: ...and it doesn't work like mock.sentinel does, which is part of the value. I really think we should put this wherever it needs to be so that it can continue to be as

Re: [openstack-dev] [oslo] UUID sentinel needs a home

On 08/23/2018 01:25 PM, Doug Hellmann wrote: Excerpts from Eric Fried's message of 2018-08-23 09:51:21 -0500: Do you mean an actual fixture, that would be used like: class MyTestCase(testtools.TestCase): def setUp(self): self.uuids =

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

Dan, thanks for the details and answers. Appreciated. Best, -jay On 08/23/2018 10:50 AM, Dan Prince wrote: On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes wrote: On 08/15/2018 04:01 PM, Emilien Macchi wrote: On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi mailto:emil...@redhat.com>>

Re: [openstack-dev] [oslo] UUID sentinel needs a home

On 08/23/2018 08:06 AM, Doug Hellmann wrote: Excerpts from Davanum Srinivas (dims)'s message of 2018-08-23 06:46:38 -0400: Where exactly Eric? I can't seem to find the import: http://codesearch.openstack.org/?q=(from%7Cimport).*oslotest=nope==oslo.utils -- dims oslo.utils depends on

Re: [openstack-dev] [oslo] UUID sentinel needs a home

On Wed, Aug 22, 2018, 10:13 AM Eric Fried wrote: > For some time, nova has been using uuidsentinel [1] which conveniently > allows you to get a random UUID in a single LOC with a readable name > that's the same every time you reference it within that process (but not > across processes). Example

Re: [openstack-dev] [all] [nova] [neutron] live migration with multiple port bindings.

On Tue, Aug 21, 2018, 8:29 AM Matt Riedemann wrote: > On 8/21/2018 7:28 AM, Matt Riedemann wrote: > > On 8/20/2018 3:18 PM, Sean Mooney wrote: > >> in both the ovs-dpdk tests, when the migration failed and the vm > >> contiuned to run on the source node however > >> it had no network

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On 08/18/2018 08:25 AM, Chris Dent wrote: So my hope is that (in no particular order) Jay Pipes, Eric Fried, Takashi Natsume, Tetsuro Nakamura, Matt Riedemann, Andrey Volkov, Alex Xu, Balazs Gibizer, Ed Leafe, and any other contributor to placement whom I'm forgetting [1] would express

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

On 08/15/2018 04:01 PM, Emilien Macchi wrote: On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi > wrote: More seriously here: there is an ongoing effort to converge the tools around containerization within Red Hat, and we, TripleO are interested to continue

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

On 08/15/2018 05:32 AM, Cédric Jeanneret wrote: Dear Community, As you may know, a move toward Podman as replacement of Docker is starting. This was news to me. Is this just a triple-o thing? -jay __ OpenStack

Re: [openstack-dev] [oslo][tooz][etcd] need help debugging tooz test failure

On 08/13/2018 03:52 PM, Doug Hellmann wrote: Excerpts from Jay Pipes's message of 2018-08-13 13:21:56 -0400: On 08/12/2018 04:11 PM, Doug Hellmann wrote: The tooz tests on master and stable/rocky are failing with an error: UnicodeDecodeError: 'utf8' codec can't decode byte 0xc4 in

Re: [openstack-dev] [oslo][tooz][etcd] need help debugging tooz test failure

On 08/12/2018 04:11 PM, Doug Hellmann wrote: The tooz tests on master and stable/rocky are failing with an error: UnicodeDecodeError: 'utf8' codec can't decode byte 0xc4 in position 0: invalid continuation byte This is unrelated to the change, which is simply importing test job

Re: [openstack-dev] [nova] Do we still want to lowercase metadata keys?

On 08/13/2018 11:56 AM, Chris Friesen wrote: On 08/13/2018 08:26 AM, Jay Pipes wrote: On 08/13/2018 10:10 AM, Matthew Booth wrote: I suspect I've misunderstood, but I was arguing this is an anti-goal. There's no reason to do this if the db is working correctly, and it would violate

Re: [openstack-dev] [nova] Do we still want to lowercase metadata keys?

On 08/13/2018 10:10 AM, Matthew Booth wrote: On Mon, 13 Aug 2018 at 14:05, Jay Pipes wrote: On 08/13/2018 06:06 AM, Matthew Booth wrote: Thanks mriedem for answering my previous question, and also pointing out the related previous spec around just forcing all metadata to be lowercase: (Spec

Re: [openstack-dev] [nova] Do we still want to lowercase metadata keys?

On 08/13/2018 06:06 AM, Matthew Booth wrote: Thanks mriedem for answering my previous question, and also pointing out the related previous spec around just forcing all metadata to be lowercase: (Spec: approved in Newton) https://review.openstack.org/#/c/311529/ (Online migration: not merged,

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

On Wed, Aug 1, 2018 at 11:15 AM, Ben Nemec wrote: > Hi, > > I'm having an issue with no valid host errors when starting instances and > I'm struggling to figure out why. I thought the problem was disk space, > but I changed the disk_allocation_ratio and I'm still getting no valid > host. The

[openstack-dev] [nova][placement] Excessive WARNING level log messages in placement-api

For evidence, see: http://logs.openstack.org/41/590041/1/check/tempest-full-py3/db08dec/controller/logs/screen-placement-api.txt.gz?level=WARNING thousands of these are filling the logs with WARNING-level log messages, making it difficult to find anything: Aug 08 22:17:30.837557

Re: [openstack-dev] Stepping down as coordinator for the Outreachy internships

On 08/08/2018 09:32 AM, Doug Hellmann wrote: Excerpts from Victoria Martínez de la Cruz's message of 2018-08-07 20:47:28 -0300: Hi all, I'm reaching you out to let you know that I'll be stepping down as coordinator for OpenStack next round. I had been contributing to this effort for several

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

On 08/04/2018 07:35 PM, Michael Glasgow wrote: On 8/2/2018 7:27 PM, Jay Pipes wrote: It's not an exception. It's normal course of events. NoValidHosts means there were no compute nodes that met the requested resource amounts. To clarify, I didn't mean a python exception. Neither did I. I

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

On 08/02/2018 06:18 PM, Michael Glasgow wrote: On 08/02/18 15:04, Chris Friesen wrote: On 08/02/2018 01:04 PM, melanie witt wrote: The problem is an infamous one, which is, your users are trying to boot instances and they get "No Valid Host" and an instance in ERROR state. They contact

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

On 08/02/2018 01:40 PM, Eric Fried wrote: Jay et al- And what I'm referring to is doing a single query per "related resource/trait placement request group" -- which is pretty much what we're heading towards anyway. If we had a request for: GET /allocation_candidates?  resources0=VCPU:1&  

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

On 08/02/2018 01:12 AM, Alex Xu wrote: 2018-08-02 4:09 GMT+08:00 Jay Pipes <mailto:jaypi...@gmail.com>>: On 08/01/2018 02:02 PM, Chris Friesen wrote: On 08/01/2018 11:32 AM, melanie witt wrote: I think it's definitely a signific

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

On 08/01/2018 02:02 PM, Chris Friesen wrote: On 08/01/2018 11:32 AM, melanie witt wrote: I think it's definitely a significant issue that troubleshooting "No allocation candidates returned" from placement is so difficult. However, it's not straightforward to log detail in placement when the

Re: [openstack-dev] [nova] [placement] compute nodes use of placement

ack. will review shortly. thanks, Chris. On 07/30/2018 02:20 PM, Chris Dent wrote: On Mon, 30 Jul 2018, Jay Pipes wrote: On 07/26/2018 12:15 PM, Chris Dent wrote: The `in_tree` calls happen from the report client method `_get_providers_in_tree` which is called by `_ensure_resource_provider

Re: [openstack-dev] [nova] [placement] compute nodes use of placement

On 07/26/2018 12:15 PM, Chris Dent wrote: The `in_tree` calls happen from the report client method `_get_providers_in_tree` which is called by `_ensure_resource_provider` which can be called from multiple places, but in this case is being called both times from

Re: [openstack-dev] [nova] keypair quota usage info for user

On 07/27/2018 03:21 PM, Matt Riedemann wrote: On 7/27/2018 2:14 PM, Matt Riedemann wrote:  From checking the history and review discussion on [3], it seems that it was like that from staring. key_pair quota is being counted when actually creating the keypair but it is not shown in API

Re: [openstack-dev] OpenStack lagging behind 2 major python versions: we need a Python 3.7 gate

On 07/18/2018 12:42 AM, Ian Wienand wrote: The ideal is that a (say) Neutron dev gets a clear traceback from a standard Python error in their change and happily fixes it. The reality is probably more like this developer gets a tempest failure due to nova failing to boot a cirros image, stemming

Re: [openstack-dev] [neutron] How to look up a project name from Neutron server code?

On 07/17/2018 03:36 AM, Neil Jerram wrote: Can someone help me with how to look up a project name (aka tenant name) for a known project/tenant ID, from code (specifically a mechanism driver) running in the Neutron server? I believe that means I need to make a GET REST call as here:

Re: [openstack-dev] [cinder] about block device driver

On 07/16/2018 10:15 AM, arkady.kanev...@dell.com wrote: Is this for ephemeral storage handling? For both ephemeral as well as root disk. In other words, just act like Cinder isn't there and attach a big local root disk to the instance. Best, -jay -Original Message- From: Jay

[openstack-dev] [placement] Low hanging fruit bug for interested newcomers

Hi all, Here's a testing and documentation bug that would be great for newcomers to the placement project: https://bugs.launchpad.net/nova/+bug/1781439 Come find us on #openstack-placement on Freenode IRC to chat about it if you're interested! Best, -jay

Re: [openstack-dev] [cinder] about block device driver

On 07/16/2018 09:32 AM, Sean McGinnis wrote: The other option would be to not use Cinder volumes so you just use local storage on your compute nodes. ^^ yes, this. -jay __ OpenStack Development Mailing List (not for

[openstack-dev] [nova][placement] placement update 18-28

This is placement update 18-28, a weekly update of ongoing development related to the [OpenStack](https://www.openstack.org/) [placement service](https://developer.openstack.org/api-ref/placement/). This week I'm trying to fill Chris' esteemable shoes while he's away. # Most Important ##

Re: [openstack-dev] [nova] What do we lose if the reshaper stuff doesn't land in Rocky?

DB work is now pushed for the single transaction reshape() function: https://review.openstack.org/#/c/582383 Note that in working on that, I uncovered a bug in AllocationList.delete_all() which needed to first be fixed: https://bugs.launchpad.net/nova/+bug/1781430 A fix has been pushed

Re: [openstack-dev] [nova] What do we lose if the reshaper stuff doesn't land in Rocky?

Let's just get the darn thing done in Rocky. I will have the DB work up for review today. -jay On 07/12/2018 10:45 AM, Matt Riedemann wrote: Continuing the discussion from the nova meeting today [1], I'm trying to figure out what the risk / benefit / contingency is if we don't get the

Re: [openstack-dev] [nova] [placement] placement update 18-27

On 07/06/2018 10:09 AM, Chris Dent wrote: # Questions * Will consumer id, project and user id always be a UUID? We've   established for certain that user id will not, but things are   less clear for the other two. This issue is compounded by the   fact that these two strings are different

Re: [openstack-dev] [nova] [placement] placement update 18-27

On 07/09/2018 02:52 PM, Chris Dent wrote: On Fri, 6 Jul 2018, Chris Dent wrote: This is placement update 18-27, a weekly update of ongoing development related to the [OpenStack](https://www.openstack.org/) [placement service](https://developer.openstack.org/api-ref/placement/). This is a

Re: [openstack-dev] [tc] [all] TC Report 18-26

On 07/06/2018 12:58 PM, Zane Bitter wrote: On 02/07/18 19:13, Jay Pipes wrote: Nova's primary competition is: * Stand-alone Ironic * oVirt and stand-alone virsh callers * Parts of VMWare vCenter [3] * MaaS in some respects Do you see KubeVirt or Kata or Virtlet or RancherVM ending up

Re: [openstack-dev] [tc] [all] TC Report 18-26

o I don't really see the correlation here. That said, I'm 100% against a monolithic application approach, as I've mentioned before. Best, -jay Thanks, Kevin From: Jay Pipes [jaypi...@gmail.com] Sent: Monday, July 02, 2018 4:13 PM To: openstack-dev@

Re: [openstack-dev] [barbican][cinder][glance][nova] Goodbye from JHUAPL

Thanks so much for your contributions to our ecosystem, Brianna! I'm sad to see you go! :( Best, -jay On 07/03/2018 03:13 PM, Poulos, Brianna L. wrote: All, After over five years of contributing security features to OpenStack, the JHUAPL team is wrapping up our involvement with OpenStack.

Re: [openstack-dev] [tc] [all] TC Report 18-26

On 07/02/2018 03:31 PM, Zane Bitter wrote: On 28/06/18 15:09, Fox, Kevin M wrote:   * made the barrier to testing/development as low as 'curl http://..minikube; minikube start' (this spurs adoption and contribution) That's not so different from devstack though.   * not having large

Re: [openstack-dev] [sqlalchemy][db][oslo.db][mistral] Is there a recommended MySQL driver for OpenStack projects?

On 07/03/2018 08:47 AM, Doug Hellmann wrote: If you have a scaling issue that may be solved by eventlet, that's one thing, but please don't adopt eventlet just because a lot of other projects have. We've tried several times to minimize our reliance on eventlet because new releases tend to

Re: [openstack-dev] [tc] [all] TC Report 18-26

On 06/27/2018 07:23 PM, Zane Bitter wrote: On 27/06/18 07:55, Jay Pipes wrote: Above, I was saying that the scope of the *OpenStack* community is already too broad (IMHO). An example of projects that have made the *OpenStack* community too broad are purpose-built telco applications like

  1   2   3   4   5   6   7   8   9   10   >