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

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 removing the "healing" aspect of the resource

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

at 1:01 PM Jay Pipes <mailto:jaypi...@gmail.com>> wrote: > > 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_provi

[openstack-dev] [nova][placement] No n-sch meeting next week

...due to summit. -efried __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac

Re: [openstack-dev] Development workflow for bunch of patches

I've always used rebase rather than cherry-pick in this situation. Bonus is that sometimes (if no conflicts) I can do the rebase in gerrit with two clicks rather than locally with a bunch of typing. @kevinbenton, is there a benefit to using cherry-pick rather than rebase? Thanks, Eric

Re: [openstack-dev] [Taskflow] Current state or the project ?

it. We've found it to be a boon, especially for automated cleanup (via revert() chains) when something goes wrong. Doing this kind of workflow management is inherently complicated, but we find TaskFlow makes it about as straightforward as we could reasonably expect it to be. Good luck. Er

Re: [openstack-dev] [nova][oslo.utils] Bug-1680130 Check validation of UUID length

+1. Provide a sanitize_uuid() or similar, which may be as simple as: def sanitize_uuid(val): try: return uuid.UUID(val) except ValueError: raise SomePossiblyNewException(...) UUID consumers are encouraged, but not required, to use it - so we retain backward compatibility

Re: [openstack-dev] [nova][oslo.utils] Bug-1680130 Check validation of UUID length

That's not the only way you can break this, though. For example, '12-3-45-6-78-12-3456-781-234-56-781-234-56-79' still passes the modified is_uuid_like(), but still manifests the bug. Trying to get is_uuid_like() to cover all possible formatting snafus while still allowing the same formats as bef

[openstack-dev] [nova][glance] Who needs multiple api_servers?

lance.py#L27-L37 [3] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-04-27.log.html#t2017-04-27T20:38:29 Thanks, Eric Fried (efried) . __ OpenStack Development Mailing List (not for usage questions) Unsubs

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

ose the redundancy we get now by providing a list. >> Or we would have to shunt all the calls through the user-facing endpoint, >> which would generate a lot of extra traffic (in places where we don’t want >> it) for image transfers. >> >> Thanks, >> Mike >>

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

se one of the > Glance servers in the list is down, without putting them behind a load > balancer. We also don’t run https for these “internal” Glance calls, to save > the overhead when transferring images. > >> > >> End-user calls to Glance DO go through a real

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

I love this. Will it be done by July 20th [1] so I can use it in Pike for [2]? [1] https://wiki.openstack.org/wiki/Nova/Pike_Release_Schedule [2] https://review.openstack.org/#/c/458257/4/nova/utils.py@1508 On 04/28/2017 05:26 PM, Monty Taylor wrote: > Hey everybody! > > Yay! (I'm sure you're a

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

ethod could be moved to a more common lib (ksaor os-client-config perhaps) in the future to facilitate this. Eric (efried) On 05/01/2017 09:17 AM, Matthew Treinish wrote: > On Mon, May 01, 2017 at 05:00:17AM -0700, Flavio Percoco wrote: >> On 28/04/17 11:19 -0500, Eric Fried wrot

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

Sam- Under the current design, you can provide a specific endpoint (singular) via the `endpoint_override` conf option. Based on feedback on this thread, we will also be keeping support for `[glance]api_servers` for consumers who actually need to be able to specify multiple endpoints. See

Re: [openstack-dev] [neutron] neutron-lib impact: neutron.plugins.common.constants are now in neutron-lib

Boden- Can you please point to the change(s) that move the constants? Or provide some other way to figure out which are affected? Thanks, Eric (efried) On 05/03/2017 09:30 AM, Boden Russell wrote: > If your project uses neutron.plugins.com

Re: [openstack-dev] [nova] [cinder] Follow up on Nova/Cinder summit sessions from an ops perspective

> If there are alternative ideas on how to design or model this, I'm all > ears. How about aggregates? https://www.youtube.com/watch?v=fu6jdGGdYU4&feature=youtu.be&t=1784 On 05/15/2017 05:04 PM, Matt Riedemann wrote: > On 5/15/2017 2:28 PM, Edmund Rhudy (BLOOMBERG/ 120 PARK) wrote: >> Hi all, >>

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

> The idea is that a regular user calling into a service should not > be able to set the request id, but outgoing calls from that service > to other services as part of the same request would. Yeah, so can anyone explain to me why this is a real problem? If a regular user wanted to be a d*ck and

[openstack-dev] [all] Log coloring under systemd

Folks- As of [1], devstack will include color escapes in the default log formats under systemd. Production deployments can emulate as they see fit. Note that journalctl will strip those color escapes by default, which is why we thought we lost log coloring with systemd. Turns ou

Re: [openstack-dev] [glance] please approve test patch to fix glanceclient

Thanks Nikhil. This one is also needed to make py35 pass: https://review.openstack.org/#/c/396816/ E On 05/24/2017 10:55 AM, Nikhil Komawar wrote: > thanks for bringing it up. this is done. > > On Wed, May 24, 2017 at 10:54 AM, Sean Dague > wrote: > > python-glance

Re: [openstack-dev] [ironic] using keystone right - catalog, endpoints, tokens and noauth

Pavlo- There's a blueprint [1] whereby we're trying to address a bunch of these same concerns in nova. You can see the first part in action here [2]. However, it has become clear that nova is just one of the many services that would benefit from get_service_url(). With the full support

[openstack-dev] [nova][out-of-tree drivers] InstanceInfo/get_info getting a haircut

If you don't maintain an out-of-tree nova compute driver, you can probably hit Delete now. A proposed change [1] gets rid of some unused fields from nova.virt.hardware.InstanceInfo, which is the thing returned by ComputeDriver.get_info(). I say "unused" in the context of the nova project. If you

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

Nice Stephen! For those who aren't aware, the rendered version (pretty, so pretty) can be accessed via the gate-nova-docs-ubuntu-xenial jenkins job: http://docs-draft.openstack.org/10/475810/1/check/gate-nova-docs-ubuntu-xenial/25e5173//doc/build/html/scheduling.html?highlight=scheduling On 06/2

Re: [openstack-dev] [nova] PCI handling (including SR-IOV), Traits, Resource Providers and Placement API - how to proceed?

Hi Maciej, thanks for bringing this up. On 06/26/2017 04:59 AM, Maciej Kucia wrote: > Hi, > > I have recently spent some time digging in Nova PCI devices handling code. > I would like to propose some improvements: > https://review.openstack.org/#/c/474218/ (Extended PCI alias) > https://review.op

Re: [openstack-dev] [heat][ironic][telemetry][dragonflow][freezer][kuryr][manila][mistral][monasca][neutron][ansible][congress][rally][senlin][storlets][zun][docs] repos without signs of migration sta

> can't speak regarding ceilometer-powervm since it's vendor specific. I can confirm that ceilometer-powervm (and nova-powervm and networking-powervm) shouldn't be tracked with this effort, since they publish to readthedocs and not docs.openstack.org. Something something Big Tent something Govern

Re: [openstack-dev] [keystone] keystoneauth1 3.0.0 broken keystonemiddleware

dims- SHA was good; just hadn't merged yet. It has now. All greens. Assuming lbragstad/morgan/mordred are on board, let's do it. Thanks, efried On 07/22/2017 10:06 AM, Davanum Srinivas wrote: > Lance, > > Ack. SHA needs to be fixed (https://review.opens

[openstack-dev] [nova][placement] self links include /placement?

I finally got around to fiddling with the placement API today, and noticed something... disturbing. To me, anyway. When I GET a URI, such as '/resource_classes', the response includes e.g. {u'links': [{u'href': u'/placement/resource_classes/MEMORY_MB', u'rel': u'self'}], u'name': u'MEM

Re: [openstack-dev] [nova][placement] self links include /placement?

umer using a HATEOAS-compliant request client might be able to use the links, which is why we bother to include them at all. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-08-14.log.html#t2017-08-14T13:04:59 On 08/12/2017 04:03 AM, Chris Dent wrote: > On Fri,

Re: [openstack-dev] [ptg] PTG general info & upcoming registration price hike

Thierry- > If you're still wondering what will happen at this PTG (or you went to > the first one Atlanta and wonder what changed since), I wrote a blogpost > you might be interested to read at: https://ttx.re/queens-ptg.html Thanks for this, super helpful! efried __

Re: [openstack-dev] [infra][docs] Why Manila api-ref doc isn't published?

Agree with everything fungi has said here. Per https://git.openstack.org/cgit/openstack/service-types-authority/tree/README.rst#n97 we want the official service type to be singular rather than plural. And per the doc migration movement, we want the API references to live at standard URLs based on

Re: [openstack-dev] [infra][docs] Why Manila api-ref doc isn't published?

Sigh. [3] https://review.openstack.org/#/c/495326/1/www/.htaccess@52 On 09/05/2017 07:30 AM, Eric Fried wrote: > Agree with everything fungi has said here. > > Per > https://git.openstack.org/cgit/openstack/service-types-authority/tree/README.rst#n97 > we want the official ser

Re: [openstack-dev] removing screen from devstack - RSN

Thanks, Eric Fried (efried) On 09/07/2017 12:34 PM, John Griffith wrote: > > > On Thu, Sep 7, 2017 at 11:29 AM, John Griffith <mailto:john.griffi...@gmail.com>> wrote: > > Please don't, some of us have no issues with screen and use it > extensive

Re: [openstack-dev] removing screen from devstack - RSN

t; > On 09/07/2017 01:52 PM, Eric Fried wrote: > > John- > > You're not the only one for whom the transition to > systemd has been > painful. > > However... > > It *is* possible

Re: [openstack-dev] [nova] [neutron] Adding neutron VIF NUMA locality support

Stephen- FYI, we're teeing up (anti-)affinity and neutron-nova interaction topics for the "generic device management" discussions at the PTG. Please jump on the etherpad [1] and expand/expound in the relevant spots, which, as of this writing, you can find by searching for "aggregate", "vf

Re: [openstack-dev] removing screen from devstack - RSN

Oh, are we talking about the logs produced by CI jobs? I thought we were talking about on your local devstack itself. Because there, I don't think you shouldn't be seeing log files like this anymore. Logging is done via systemd and can be viewed via journalctl [1]. The exceptions are things that

Re: [openstack-dev] removing screen from devstack - RSN

Eric (efried) On 09/11/2017 10:56 AM, Miguel Angel Ajo Pelayo wrote: > I wonder if it makes sense to provide a helper script to do what it's > explained on the document. > > So we could ~/devstack/tools/run_locally.sh n-sch. > > If yes, I'll send the patch. > > On

Re: [openstack-dev] [ptg][nova][neutron] modelling network capabilities and capacity in placement and nova neutron port binding negociation.

Yup, I definitely want to be involved in this too. Please keep me posted. efried On 09/11/2017 11:12 AM, Jay Pipes wrote: > I'm interested in this. I get in to Denver this evening so if we can do > this session tomorrow or later, that would be super. > > Best, > -jay > > On 09/

Re: [openstack-dev] [ptg][nova][neutron] modelling network capabilities and capacity in placement and nova neutron port binding negociation.

h out the schedule/scope/topics. o Let me know if this time/location doesn't work for you. o It would be nice to have a rep from Neutron handy :) [1] https://etherpad.openstack.org/p/placement-nova-neutron-queens-ptg Thanks, Eric Fried (efried) On 09/11/201

Re: [openstack-dev] [ptg][nova][neutron] modelling network capabilities and capacity in placement and nova neutron port binding negociation.

s, so we may be able to bleed over if necessary.) See y'all there. Thanks, Eric Fried (efried) [1] https://etherpad.openstack.org/p/placement-nova-neutron-queens-ptg On 09/12/2017 09:30 AM, Chris Dent wrote: > On Mon, 11 Sep 2017,

Re: [openstack-dev] [zun][unit test] Any python utils can collect pci info?

You may get a little help from the methods in nova.pci.utils. If you're calling out to lspci or accessing sysfs, be aware of this series [1] and do it via the new privsep mechanisms. [1] https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:hurrah-for-privsep On

Re: [openstack-dev] [docs][ptls][install] Install guide vs. tutorial

it back to the mailing list > to highlight your concerns and continue this discussion :) > > Thanks for your reply, > > Alex > > On 9/19/17, 2:43 PM, "Eric Fried" wrote: > > Alex- > > Regardless of what the dictionary might say, people asso

Re: [openstack-dev] [ironic] ironic and traits

* Adding references to the specs: ironic side [1]; nova side [2] (which just merged). * Since Jay is on vacation, I'll tentatively note his vote by proxy [3] that ironic should be the source of truth - i.e. option (a). I think the upshot is that it's easier for Ironic to track and resolve conflic

[openstack-dev] [nova][out-of-tree drivers] Breaking change to ComputeDriver.spawn and friends

Out-of-tree virt driver maintainers, please keep an eye on [1], which will force you to update the signature of your spawn and rebuild overrides. See the commit message for the whys and wherefores, and let me know if you have any questions. [1] https://review.openstack.org/511879 Thanks, Eric

Re: [openstack-dev] [nova][out-of-tree drivers] Breaking change to ComputeDriver.spawn and friends

river to use it, correct? > > Best Regards! > > Kevin (Chen) Ji 纪 晨 > > Engineer, zVM Development, CSTL > Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com > Phone: +86-10-82451493 > Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian > Distri

Re: [openstack-dev] [Openstack-operators] PCI pass through settings on a flavor without aliases on the API nodes

trait:CUSTOM_PCI_PRODUCTID_154D=required In the meantime, it's especially useful to get this kind of feedback from ops so we can ensure we're meeting the right requirements as we design things. Please reach out if you want to discuss further. Thanks, Eric Fried (efried) On 10/18/2017 09:56 AM, V

Re: [openstack-dev] [ironic] ironic and traits

I agree with Sean. In general terms: * A resource provider should be marked with a trait if that feature * Can be turned on or off (whether it's currently on or not); or * Is always on and can't ever be turned off. * A consumer wanting that feature present (doesn't matter whether it's on or o

Re: [openstack-dev] [ironic] ironic and traits

#t2017-10-23T13:12:13 On 10/23/2017 08:15 AM, Sylvain Bauza wrote: > > > On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried <mailto:openst...@fried.cc>> wrote: > > I agree with Sean.  In general terms: > > * A resource provider should be marked with a trai

Re: [openstack-dev] [ironic] ironic and traits

, but if there are 10 > values, or it is just an integer value. > > That sounds like we put information isn't about the scheduling to the > placement, and those information adds extra burden to the placement. > > 2017-10-23 22:09 GMT+08:00 Eric Fried <mailto:openst...@

Re: [openstack-dev] [ironic] [nova] traits discussion call - moved to Tue!!

Here's the executive summary of the meeting: Topic: How does Nova communicate to the Ironic virt driver that the user wants a particular RAID setup or boot mode or whatever? o Level set: Traits are an indication of capability, not state. To be clear: if a RP (e.g. ironic node) has traits indicat

[openstack-dev] [nova] [placement] resource providers update 41

Standing in for cdent while he's across the planet. If this update doesn't live up to the quality you've come to expect, blame it on that guy being an overachiever. # Most Important GET /allocation_candidates is big and complicated, but is going to get exponentially more so as we start handling

[openstack-dev] [nova][placement] resource providers update 41.5

Not too much happened due to the summit, so this will be a short one. => The majority of last week's update [1] still applies, including the call for reviews under "# Most Important". [1] http://lists.openstack.org/pipermail/openstack-dev/2017-November/124233.html => cdent's spec for symmetric G

[openstack-dev] [nova][placement] resource providers update 41.75

Folks are still trickling back from the summit, so things haven't ground fully back into action yet. But some progress has been made: GET /allocation_candidates == The refactor series starting at [1] has started to merge. The series has included a number of useful tests,

[openstack-dev] [nova][placement] Review push this week

Nova devs (especially cores): In this week's scheduler meeting [1] we fondly recalled our vigorous agreement at the PTG to merge the big stuff early in the cycle. We lamented the extent to which Sydney + Thanksgiving drained our review resources for much of November, and shed a tear in ant

Re: [openstack-dev] [nova] Working toward Queens feature freeze and RC1

Matt, et al- > * Nested resource providers: I'm going to need someone closer to this > work like Jay or Eric to provide an update on where things are at in the > series of changes and what absolutely needs to get done. I have > personally found it hard to track what the main focus items are for th

Re: [openstack-dev] [nova] Working toward Queens feature freeze and RC1

Folks- >> - NRP affordance in GET /allocation_candidates >>    . PATCHES: - >>    . STATUS: Not proposed >>    . PRIORITY: Critical >>    . OWNER: jaypipes >>    . DESCRIPTION: In the current master branch, the placement API will >> report allocation candidates from [(a single non-sharing provider

Re: [openstack-dev] [ResMgmt SIG]Proposal to form Resource Management SIG

> I think having a bi-weekly cross-project (or even cross-ecosystem if > we're talking about OpenStack+k8s) status email reporting any big events > in the resource tracking world would be useful. As far as regular > meetings for a resource management SIG, I'm +0 on that. I prefer to have > targeted

Re: [openstack-dev] [nova] [placement] resource providers update 18-03

> Earlier in the week I did some exercising by humans and was confused > by the state of traits handling on /allocation_candidates (it could be > the current state is the expected state but the code didn't make that > clear) so I made a bug on it make sure that confusion didn't get forgotten: > >

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

For my part, I tried it [1] and it doesn't seem to have worked. (The functional test failure is what the dep is supposed to have fixed.) Did I do something wrong? [1] https://review.openstack.org/#/c/533821/12 On 01/25/2018 09:33 PM, Mathieu Gagné wrote: > On Thu, Jan 25, 2018 at 7:08 PM, James

[openstack-dev] [nova][placement] Re: VMWare's resource pool / cluster and nested resource providers

.  However, if > no trait is specified then we can end up in the situation that you > describe (allocating different resources from different resource > pools) and this is not what we want.  If we go with the model that you > propose, is there a way to make the scheduler allocate on

Re: [openstack-dev] [nova][placement] Re: VMWare's resource pool / cluster and nested resource providers

n (A). (E) Take (D) a step further by adding each 'host' as a child of its respective resource pool. No "creative finagling", but same "moving allocations" issue as (B). I'm sure I've missed/misrepresented things. Please correct and refine as necessary. Th

Re: [openstack-dev] [nova] Should we get auth from context for Neutron endpoint?

Zheng 先生- I *think* you're right that 'network' should be included in [2]. I can't think of any reason it shouldn't be. Does that fix the problem by itself? I believe the Neutron API code is already getting its auth from context... sometimes [5]. If you want to make sure it's a

Re: [openstack-dev] [nova][cyborg]Dublin PTG Cyborg Nova Interaction Discussion

I'm interested. No date/time preference so far as long as it sticks to Monday/Tuesday. efried On 02/12/2018 09:13 AM, Zhipeng Huang wrote: > Hi Nova team, > > Cyborg will have ptg sessions on Mon and Tue from 2:00pm to 6:00pm, and > we would love to invite any of you guys who is interested in n

[openstack-dev] [nova][placement] update_provider_tree design updates

One of the takeaways from the Queens retrospective [1] was that we should be summarizing discussions that happen in person/hangout/IRC/etc. to the appropriate mailing list for the benefit of those who weren't present (or paying attention :P ). This is such a summary. As originally conceived, Comp

Re: [openstack-dev] [nova][placement] update_provider_tree design updates

Excellent and astute questions, both of which came up in the discussion, but I neglected to mention. (I had to miss *something*, right?) See inline. On 03/15/2018 02:29 PM, Chris Dent wrote: > On Thu, 15 Mar 2018, Eric Fried wrote: > >> One of the takeaways from the Queens retr

Re: [openstack-dev] [nova] Rocky spec review day

+1 for the-earlier-the-better, for the additional reason that, if we don't finish, we can do another one in time for spec freeze. And I, for one, wouldn't be offended if we could "officially start development" (i.e. focus on patches, start runways, etc.) before the mystical but arbitrary spec free

Re: [openstack-dev] [nova] Review runways this cycle

> I think the only concern around moving spec freeze out would be that I > thought the original purpose of the spec freeze was to set expectations > early about what was approved and not approved instead of having folks > potentially in the situation where it's technically "maybe" for a large > ch

Re: [openstack-dev] [nova] Review runways this cycle

WFM. November Oscar Victor Alpha you are cleared for takeoff. On 03/22/2018 03:18 PM, Matt Riedemann wrote: > On 3/22/2018 2:59 PM, melanie witt wrote: >> Maybe a good compromise would be to start runways now and move spec >> freeze out to r-2 (Jun 7). That way we have less pressure on spec >> re

Re: [openstack-dev] [nova] [cyborg] Race condition in the Cyborg/Nova flow

Sundar- First thought is to simplify by NOT keeping inventory information in the cyborg db at all. The provider record in the placement service already knows the device (the provider ID, which you can look up in the cyborg db) the host (the root_provider_uuid of the provider representing

[openstack-dev] [nova][placement] Upgrade placement first!

Since forever [0], nova has gently recommended [1] that the placement service be upgraded first. However, we've not made any serious effort to test scenarios where this isn't done. For example, we don't have grenade tests running placement at earlier levels. After a(nother) discussion [2] which

Re: [openstack-dev] [nova] [cyborg] Race condition in the Cyborg/Nova flow

ogram it to result in more or fewer > functions. That said, we could hopefully keep this analogy in mind for > future discussions. > > We probably will not support multi-function accelerators in Rocky. This > discussion is for the longer term. > > Regards, > Sundar > >

Re: [openstack-dev] [nova] [cyborg] Race condition in the Cyborg/Nova flow

that it has races? > > Regards, > Sundar > > On 3/28/2018 11:48 AM, Eric Fried wrote: >> Sundar- >> >> We're running across this issue in several places right now.   One >> thing that's definitely not going to get traction is >> auto

Re: [openstack-dev] [nova] [cyborg] Race condition in the Cyborg/Nova flow

2, We should use trait to distinguish the function type. > > Then we didn't keep any inventory info in the cyborg again, and we > needn't any filter in cyborg also, > and there is no race condition anymore. > > 2018-03-29 2:48 GMT+08:00 Eric Fried <mailto:openst...@fr

Re: [openstack-dev] [nova] [cyborg] Race condition in the Cyborg/Nova flow

> That means that for the (re)-programming scenarios you need to > dynamically adjust the inventory of a particular FPGA resource provider. Oh, see, this is something I had *thought* was a non-starter. This makes the "single program" case way easier to deal with, and allows it to be handled on th

[openstack-dev] [placement] Anchor/Relay Providers

Folks who care about placement (but especially Jay and Tetsuro)- I was reviewing [1] and was at first very unsatisfied that we were not returning the anchor providers in the results. But as I started digging into what it would take to fix it, I realized it's going to be nontrivial. I wanted to d

Re: [openstack-dev] [placement] Anchor/Relay Providers

rovider.py@2658 > [6] https://review.openstack.org/#/c/533437/6/nova/api/openstack/placement/objects/resource_provider.py@3303 > [7] https://review.openstack.org/#/c/558014/ [8] https://review.openstack.org/#/c/558045/ [9] https://review.openstack.org/#/c/558044/ On 03/30/2018 07:34 PM, Eric

Re: [openstack-dev] [nova][oslo] what to do with problematic mocking in nova unit tests

Hi Doug, I made this [2] for you. I tested it locally with oslo.config master, and whereas I started off with a slightly different set of errors than you show at [1], they were in the same suites. Since I didn't want to tox the world locally, I went ahead and added a Depends-On from [3]. Let's s

Re: [openstack-dev] [barbican][nova-powervm][pyghmi][solum][trove] Switching to cryptography from pycrypto

Mr. Fire- > nova-powervm: no open reviews > - in test-requirements, but not actually used? > - made https://review.openstack.org/558091 for it Thanks for that. It passed all our tests; we should merge it early next week. -efried _

Re: [openstack-dev] [nova] Proposing Eric Fried for nova-core

PM, melanie witt wrote: > On Mon, 26 Mar 2018 19:00:06 -0700, Melanie Witt wrote: >> Howdy everyone, >> >> I'd like to propose that we add Eric Fried to the nova-core team. >> >> Eric has been instrumental to the placement effort with his work on >> nes

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

>> it's really on nested allocation candidates. > > Yup. And that series is deadlocked on a disagreement about whether > granular request groups should be "separate by default" (meaning: if you > request multiple groups of resources, the expectation is that they will > be served by distinct resour

Re: [openstack-dev] [nova] Changes toComputeVirtAPI.wait_for_instance_event

Jichen was able to use this information immediately, to great benefit [1]. (If those paying attention could have a quick look at that to make sure he used it right, it would be appreciated; I'm not an expert here.) [1] https://review.openstack.org/#/c/527658/31..32/nova/virt/zvm/guest.py@192 On

Re: [openstack-dev] [Nova][Deployers] Optional, platform specific, dependancies in requirements.txt

+1 This sounds reasonable to me. I'm glad the issue was raised, but IMO it shouldn't derail progress on an approved blueprint with ready code. Jichen, would you please go ahead and file that blueprint template (no need to write a spec yet) and link it in a review comment on the bottom zvm patch

Re: [openstack-dev] [Nova][Deployers] Optional, platform specific, dependancies in requirements.txt

ortutils.import_module('ironicclient') > > > Is avoiding three lines of code really worth making future cleanup > harder? Is a three line change really blocking "an approved blueprint > with ready code"? > > Michael > > > > On Thu, Apr 12,

Re: [openstack-dev] [placement] Anchor/Relay Providers

ng to respond. Comments inline. > > On 03/30/2018 08:34 PM, Eric Fried wrote: >> Folks who care about placement (but especially Jay and Tetsuro)- >> >> I was reviewing [1] and was at first very unsatisfied that we were not >> returning the anchor providers in the results

Re: [openstack-dev] [placement] Anchor/Relay Providers

> I still don't see a use in returning the root providers in the > allocation requests -- since there is nothing consuming resources from > those providers. > > And we already return the root_provider_uuid for all providers involved > in allocation requests within the provider_summaries section. >

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

On 04/18/2018 09:06 AM, Jay Pipes wrote: > Stackers, > > Eric Fried and I are currently at an impasse regarding a decision that > will have far-reaching (and end-user facing) impacts to the placement > API and how nova interacts with the placement service from the nova > schedu

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

I can't tell if you're being facetious, but this seems sane, albeit complex. It's also extensible as we come up with new and wacky affinity semantics we want to support. I can't say I'm sold on requiring `proximity` qparams that cover every granular group - that seems like a pretty onerous burden

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

Chris- Going to accumulate a couple of your emails and answer them. I could have answered them separately (anti-affinity). But in this case I felt it appropriate to provide responses in a single note (best fit). > I'm a bit conflicted.  On the one hand... > On the other hand, Right; w

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

> Cool. So let's not use a GET for this and instead change it to a POST > with a request body that can more cleanly describe what the user is > requesting, which is something we talked about a long time ago. I kinda doubt we could agree on a format for this in the Rocky timeframe. But for the sak

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

Sorry, addressing gaffe, bringing this back on-list... On 04/18/2018 04:36 PM, Ed Leafe wrote: > On Apr 18, 2018, at 4:11 PM, Eric Fried wrote: >>> That makes a lot of sense. Since we are already suffixing the query param >>> “resources” to indicate granular, why not add

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

> I have a feeling we're just going to go back and forth on this, as we > have for weeks now, and not reach any conclusion that is satisfactory to > everyone. And we'll delay, yet again, getting functionality into this > release that serves 90% of use cases because we are obsessing over the > 0.01%

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

gibi- > Can the proximity param specify relationship between the un-numbered and > the numbered groups as well or only between numbered groups? > Besides that I'm +1 about proxyimity={isolate|any} Remembering that the resources in the un-numbered group can be spread around the tree and sharing pr

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

Chris- Thanks for this perspective. I totally agree. > * the common behavior should require the least syntax. To that point, I had been assuming "any fit" was going to be more common than "explicit anti-affinity". But I think this is where we are having trouble agreeing. So since, as you poin

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

Sylvain- > What's the default behaviour if we aren't providing the proximity qparam > ? Isolate or any ? What we've been talking about, per mriedem's suggestion, is that the qparam is required when you specify any numbered request groups. There is no default. If you don't provide the qparam, 40

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

%2013:48:39.213790#a1c [2] https://review.openstack.org/#/c/562687/ On 04/19/2018 07:38 AM, Balázs Gibizer wrote: > > > On Thu, Apr 19, 2018 at 2:27 PM, Eric Fried wrote: >> gibi- >> >>>  Can the proximity param specify relationship between the un-numbered >>&g

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

Semantically, GET /allocation_candidates where we don't actually want to allocate anything (i.e. we don't want to use the returned candidates) is goofy, and talking about what the result would look like when there's no `resources` is going to spider into some weird questions. Like what does the re

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

L(_("The following traits were in the image but not in the instance's RPs: %s") % ', '.join(missing_traits)) [1] https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L986 On 04/23/2018 03:47 PM, Matt Riedemann wrote: > On 4/23/2018 3:26 PM

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

> for the GET > /resource_providers?in_tree=&required=, nested > resource providers and allocation pose a problem see #3 above. This *would* work as a quick up-front check as Jay described (if you get no results from this, you know that at least one of your image traits doesn't exist anywhere in t

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

> The problem isn't just checking the traits in the nested resource > provider. We also need to ensure the trait in the exactly same child > resource provider. No, we can't get "granular" with image traits. We accepted this as a limitation for the spawn aspect of this spec [1], for all the same r

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

Alex- On 04/24/2018 09:21 AM, Alex Xu wrote: > > > 2018-04-24 20:53 GMT+08:00 Eric Fried <mailto:openst...@fried.cc>>: > > > The problem isn't just checking the traits in the nested resource > > provider. We also need to ensure the trait in t

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

>> verify with placement >> whether the image traits requested are 1) supported by the compute >> host the instance is residing on and 2) coincide with the >> already-existing allocations. Note that #2 is a subset of #1. The only potential advantage of including #1 is efficiency: We can do #1 in

Re: [openstack-dev] [nova] Extra feature of vCPU allocation on demands

I will be interested to watch this develop. In PowerVM we already have shared vs. dedicated processors [1] along with concepts like capped vs. uncapped, min/max proc units, weights, etc. But obviously it's all heavily customized to be PowerVM-specific. If these concepts made their way into mains

Re: [openstack-dev] [Cyborg] [Nova] Cyborg traits

This all sounds fully reasonable to me. One thing, though... >> * There is a resource class per device category e.g. >> CUSTOM_ACCELERATOR_GPU, CUSTOM_ACCELERATOR_FPGA. Let's propose standard resource classes for these ASAP. https://github.com/openstack/nova/blob/d741f624c81baf89f

  1   2   >