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 Fried

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

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. Eric Fried (

[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':

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

-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, 11 Aug 2017, Eric Fr

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

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

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

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 load balancer and then > are distributed out to the Glance servers on the backend. From the > end-u

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

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

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

://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) Unsubscribe: openstack-dev-requ

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

nted. We would lose 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, &

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

[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

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

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=youtu.be=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, >> >> I'd

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) >

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

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

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

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 wrote: &g

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.

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: > >

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

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

o 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" <openst...@fried.cc> wrote: > > Alex- > > Regardless of what the dictionary might

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

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

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

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

(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 Fri, Sep 8, 201

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

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

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

@dague.net>> wrote: > > 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*

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

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/2017 01:05 PM

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

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, Eric Fried wrote: > >> Fo

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

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 offici

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

t 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 > District, Beijing 100193, PRC > > Inact

[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] [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, Van Leeuwen

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

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

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

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

; 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 <openst...@fried.cc > <mailto:openst...@

[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

[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] 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

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

[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

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

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

oint saying that virtio-blk is not longer >> limited by the number of PCI slot available. That in recent kernel and >> QEMU version [0]. >> >> I could join what you are suggesting at the bottom and fix the limit >> to 256 disks. > > Right, that's for KVM-base

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

There is now a blueprint [1] and draft spec [2]. Reviews welcomed. [1] https://blueprints.launchpad.net/nova/+spec/reshape-provider-tree [2] https://review.openstack.org/#/c/572583/ On 06/04/2018 06:00 PM, Eric Fried wrote: > There has been much discussion. We've gotten to a po

Re: [openstack-dev] [cinder] [placement] cinder + placement forum session etherpad

We just merged an initial pass at direct access to the placement service [1]. See the test_direct suite for simple usage examples. Note that this was written primarily to satisfy the FFU use case in blueprint reshape-provider-tree [2] and therefore likely won't have everything cinder needs. So

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

Thank you as always for doing this, Chris. > Some of the older items in this list are not getting much attention. > That's a shame. The list is ordered (oldest first) the way it is on > purpose. > > * >   Purge comp_node and res_prvdr records during

Re: [openstack-dev] [requirements][nova] weird error on 'Validating lower constraints of test-requirements.txt'

Doug- > The lower constraints tests only look at files in the same repo. > The minimum versions of dependencies set in requirements.txt, > test-requirements.txt, etc. need to match the values in > lower-constraints.txt. > > In this case, the more detailed error message is a few lines above the >

[openstack-dev] [nova][oot drivers] Putting a contract out on ComputeDriver.get_traits()

All (but especially out-of-tree compute driver maintainers)- ComputeDriver.get_traits() was introduced mere months ago [1] for initial implementation by Ironic [2] mainly because the whole update_provider_tree framework [3] wasn't fully baked yet. Now that update_provider_tree is a

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.

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

> 1. Make everything perform the pivot on compute node start (which can be >re-used by a CLI tool for the offline case) > 2. Make everything default to non-nested inventory at first, and provide >a way to migrate a compute node and its instances one at a time (in >place) to roll

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

Chris- >> virt driver isn't supposed to talk to placement directly, or know >> anything about allocations? > > For sake of discussion, how much (if any) easier would it be if we > got rid of this restriction? At this point, having implemented the update_[from_]provider_tree flow as we have, it

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

Rats, typo correction below. On 05/31/2018 01:26 PM, Eric Fried wrote: >> 1. Make everything perform the pivot on compute node start (which can be >>re-used by a CLI tool for the offline case) >> 2. Make everything default to non-nested inventory at first, and provide >

Re: [openstack-dev] [Cyborg] [Nova] Backup plan without nested RPs

Sundar- We've been discussing the upgrade path on another thread [1] and are working toward a solution [2][3] that would not require downtime or special scripts (other than whatever's normally required for an upgrade). We still hope to have all of that ready for Rocky, but if

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

wrote: > On 05/31/2018 02:26 PM, Eric Fried wrote: >>> 1. Make everything perform the pivot on compute node start (which can be >>>     re-used by a CLI tool for the offline case) >>> 2. Make everything default to non-nested inventory at first, and provide >>>    

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

Sylvain- On 05/31/2018 02:41 PM, Sylvain Bauza wrote: > > > On Thu, May 31, 2018 at 8:26 PM, Eric Fried <mailto:openst...@fried.cc>> wrote: > > > 1. Make everything perform the pivot on compute node start (which can be > >    re-used by a CLI tool for

Re: [openstack-dev] [Cyborg] [Nova] Backup plan without nested RPs

To summarize: cyborg could model things nested-wise, but there would be no way to schedule them yet. Couple of clarifications inline. On 06/05/2018 08:29 AM, Jay Pipes wrote: > On 06/05/2018 08:50 AM, Stephen Finucane wrote: >> I thought nested resource providers were already supported by >>

Re: [openstack-dev] [Cyborg] [Nova] Backup plan without nested RPs

Alex- Allocations for an instance are pulled down by the compute manager and passed into the virt driver's spawn method since [1]. An allocation comprises a consumer, provider, resource class, and amount. Once we can schedule to trees, the allocations pulled down by the compute manager

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

, Nadathur, Sundar wrote: > On 5/30/2018 1:18 PM, Eric Fried wrote: >> 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. >

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

This seems reasonable, but... On 05/31/2018 04:34 AM, Balázs Gibizer wrote: > > > On Thu, May 31, 2018 at 11:10 AM, Sylvain Bauza wrote: >>> >> >> After considering the whole approach, discussing with a couple of >> folks over IRC, here is what I feel the best approach for a seamless >>

Re: [openstack-dev] [keystone] Keystone Team Update - Week of 18 June 2018

Also: keystoneauth1 3.9.0 was released. Its new feature is the ability to set raise_exc on the Adapter object so you don't have to do it per request. Here's a patch that makes use of the feature: https://review.openstack.org/#/c/577437/ -efried On 06/22/2018 06:53 AM, Colleen Murphy wrote: > #

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] 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

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

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 >

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,

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

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. Thanks, Eric On 01/27/2018 12:23 PM, Eric Fried wrote: > Rado-

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

cribe (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 only from one > specific RP if no custom trait is specified in the request? > > Thanks, &g

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

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

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

I should have made it clear that this is a tiny incremental improvement, to a code path that almost nobody is even going to see until Stein. In no way was it intended to close this topic. Thanks, efried On 08/02/2018 12:40 PM, Eric Fried wrote: > Jay et al- > >> And what I

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

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

> And we could do the same kind of approach with the non-granular request > groups by reducing the single large SQL statement that is used for all > resources and all traits (and all agg associations) into separate SELECT > statements. > > It could be slightly less performance-optimized but more

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

> I'm of two minds here. > > On the one hand, you have the case where the end user has accidentally > requested some combination of things that isn't normally available, and > they need to be able to ask the provider what they did wrong.  I agree > that this case is not really an exception, those

Re: [openstack-dev] [Nova] [Cyborg] Updates to os-acc proposal

Sundar- > * Cyborg drivers deal with device-specific aspects, including > discovery/enumeration of devices and handling the Device Half of the > attach (preparing devices/accelerators for attach to an instance, > post-attach cleanup (if any) after successful attach, releasing >

Re: [openstack-dev] [Nova] [Cyborg] Updates to os-acc proposal

Sundar- > On an unrelated note, thanks for the > pointer to the GPU spec > (https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst). > I will review that. Thanks. Please note that this is for nova-powervm, PowerVM's *out-of-tree* compute driver. We hope to bring

Re: [openstack-dev] [cinder] Reminder about the weekly Cinder meeting ...

Are you talking about the nastygram from "Sigyn" saying: "Your actions in # tripped automated anti-spam measures (nicks/hilight spam), but were ignored based on your time in channel; stop now, or automated action will still be taken. If you have any questions, please don't hesitate to contact a

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

Folks- The patch mentioned below [1] has undergone several rounds of review and collaborative revision, and we'd really like to get your feedback on it. From the commit message: Here are some examples of the debug output: - A request for three resources with no aggregate or trait

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

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 (specifically the resource tracker via the report client) is supposed to be mucking with instance allocations, right? And given the global lock

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

> 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 their preference on > what the

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

This is great information, thanks Hongbin. If I'm understanding correctly, it sounds like Zun ultimately wants to be a peer of nova in terms of placement consumption. Using the resource information reported by nova, neutron, etc., you wish to be able to discover viable targets for a container

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

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. Given the global lock >> in the report client, this should have been tough to do. If it does >>

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

> The reshaper code > is still going through code review, then next we have the integration to > do. To clarify: we're doing the integration in concert with the API side. Right now the API side patches [1][2] are in series underneath the nova side [3]. In a placement-in-its-own-repo world, the

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

Do you mean an actual fixture, that would be used like: class MyTestCase(testtools.TestCase): def setUp(self): self.uuids = self.useFixture(oslofx.UUIDSentinelFixture()).uuids def test_foo(self): do_a_thing_with(self.uuids.foo) ? That's... okay I guess, but the

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

The compromise, using the patch as currently written [1], would entail adding one line at the top of each test file: uuids = uuidsentinel.UUIDSentinels() ...as seen (more or less) at [2]. The subtle difference being that this `uuids` wouldn't share a namespace across the whole process, only

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

So... Restore the PS of the oslo_utils version that exposed the global [1]? Or use the forced-singleton pattern from nova [2] to put it in its own importable module, e.g. oslo_utils.uuidutils.uuidsentinel? (FTR, "import only modules" is a thing for me too, but I've noticed it doesn't seem to be

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

Naichuan- Are you running with [1]? If you are, the placement logs (at debug level) should be giving you some useful info. If you're not... perhaps you could pull that in :) Note that it refactors the _get_provider_ids_matching method completely, so it's possible your problem will

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

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 usage: [2]. We would like other projects (notably the

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

o at least initially we should leave that out. On 08/22/2018 07: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 >&

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

Thanks Matt, you summed it up nicely. Just one thing to point out... > Option 1 would clearly be a drain on at least 2 nova cores to go through > the changes. I think Eric is on board for reviewing options 1 or 2 in > either case, but he prefers option 2. Since I'm throwing a wrench in the >

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

Thanks Doug. I restored [4] and moved the code to the fixture module. Enjoy. -efried On 08/27/2018 10:59 AM, Doug Hellmann wrote: > Excerpts from Eric Fried's message of 2018-08-22 09:13:25 -0500: >> For some time, nova has been using uuidsentinel [1] which conveniently >> allows you to get a

[openstack-dev] [nova][placement] Freezing placement for extraction

Greetings. The captains of placement extraction have declared readiness to begin the process of seeding the new repository (once [1] has finished merging). As such, we are freezing development in the affected portions of the openstack/nova repository until this process is completed. We're relying

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

> 030 is okay as long as nothing goes wrong. If something does it > raises exceptions which would currently fail as the exceptions are > not there. See below for more about exceptions. Maybe I'm misunderstanding what these migration thingies are supposed to be doing, but 030 [1] seems like it's

  1   2   >