Earlier  
Posted Nick Remark
#openstack-nova - 2018-06-07
15:59:08 gibi johnthetubaguy: in my bandwidth case it could be tempting to store the oringally bandwidth request in the RequestSpec to use it later, but then I will have to ensure it is up to date. So I decided not to persist it to force myself to refresh it every time I need it
15:59:24 bauzas gibi: because if other callers want to check it, then they should make sure that whatever the instance now has as networks, that field is just the *original ask*
15:59:53 mriedem melwitt: sorry, in -tc meeting,
15:59:57 mriedem will look in a bit
16:00:12 bauzas gibi: since I incepted this RequestSpec object, I refrained myself to make it look like "here is what the instance is", but rather "here is what the user asked"
16:00:40 johnthetubaguy bauzas: I certainly assumed it was that, the initial state
16:00:43 bauzas if you wanna lookup any field that's related to a current status (like the instance), req_spec is not the good place to look at
16:01:11 bauzas johnthetubaguy: well, I hitted bumps on the road a number of times
16:01:27 bauzas johnthetubaguy: like the forced_hosts thing
16:01:42 bauzas but I think we're now in a pretty good shape
16:02:26 gibi bauzas: but RequestSpec is used and updated later in the lifecycle of the instance e.g. https://github.com/openstack/nova/blob/master/nova/conductor/tasks/migrate.py#L184
16:02:46 bauzas gibi: that's what I called 'bumps on the road'
16:03:34 openstackgerrit John Garbutt proposed openstack/nova-specs master: Enable rebuild for instances in cell0 https://review.openstack.org/554218
16:03:34 bauzas either way, I think johnthetubaguy only needs the 'requested networks', because he only cares of cell0
16:03:34 gibi bauzas: I call it precedent
16:04:23 bauzas let's just assume that this field will only contain the 'requested_networks', and if someone wants to use this field for anything other than rebuild from cell0, then we could rathole on it later
16:04:57 johnthetubaguy bauzas: I just added this note: https://review.openstack.org/#/c/554218/4/specs/rocky/approved/enable-rebuild-for-instances-in-cell0.rst@112
16:04:59 bauzas gibi: people could even create a new field called 'actual_networks' in opposition to 'requested_networks' :)
16:04:59 gibi bauzas: OK, I rest my case. We can add big fat comment on the field and handle the issue latear
16:05:13 gibi bauzas: :)
16:05:38 bauzas gibi: but again, take the 'requested_destination' field
16:05:54 johnthetubaguy gibi: I am +1 a big fat comment to warn about it, can't think of a better way to help that right now
16:06:08 bauzas or the 'availability_zone' field rather
16:06:28 bauzas req_spec.availability_zone doesn't get you the *actual* AZ
16:06:40 bauzas it gets you the AZ the user asked
16:06:53 johnthetubaguy that matches to port_ids pefectly actually
16:07:07 johnthetubaguy you request "give me a network" you get port uuid 9028734087238947
16:07:26 gibi OK, I think I see the difference
16:09:13 gibi so my endeavour to add the bandwidth resource request from the port to the RequestSpec is yet another bump on the road, as the user asked for a port in the boot request and not for bandwidth
16:10:20 gibi but eventually he will get bandwidth
16:11:17 gibi maybe the bandwidth request (and actually all implicit resource request) should live in a totally separate object outside of the RequestSpec
16:16:22 mriedem melwitt: given https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata i think we're ok, nothing else is ready
16:17:17 melwitt mriedem: ack, just making double sure there was nothing yet-to-be-proposed bugs coming down the pipe. since this release has been up longer than intended
16:17:19 melwitt thanks
16:17:31 mriedem melwitt: i think your hash in the release patch is wrong though
16:17:38 johnthetubaguy gibi: bandwidth we get from the port details?
16:17:57 mriedem johnthetubaguy: https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/bandwidth-resource-provider.html
16:17:59 gibi johnthetubaguy: yes, there will be a new resource_request field in the port
16:18:00 mriedem enjoy!
16:18:29 gibi johnthetubaguy: https://review.openstack.org/#/c/567268/13/nova/tests/fixtures.py@1153 this is how it will look like
16:18:33 johnthetubaguy gibi: yeah, its so why we want to create the ports before calling placement, sigh.
16:18:52 melwitt mriedem: really? did you think I should use the merge hash?
16:19:25 gibi johnthetubaguy: yes, the is another reason to eventually move the port creation to the conductor
16:19:41 mriedem melwitt: i have always used the head commit on the branch
16:19:42 gibi johnthetubaguy: s/the/this/
16:19:43 mriedem merge or not
16:19:58 mriedem which is always what we'd use for tagging
16:20:24 melwitt mriedem: okay, I keep getting confused about that. I'll change it
16:20:41 openstackgerrit Balazs Gibizer proposed openstack/nova master: Send resource allocations in the port binding https://review.openstack.org/569459
16:26:45 openstackgerrit Merged openstack/nova master: Fix the file name of development-environment.rst https://review.openstack.org/573096
16:33:50 openstackgerrit Jay Pipes proposed openstack/nova master: placement: always create consumer records https://review.openstack.org/567678
16:33:51 openstackgerrit Jay Pipes proposed openstack/nova master: add consumers generation field https://review.openstack.org/557958
16:33:52 openstackgerrit Jay Pipes proposed openstack/nova master: placement: Allocation.consumer field https://review.openstack.org/565405
16:33:53 openstackgerrit Jay Pipes proposed openstack/nova master: rework allocation handler _allocations_dict() https://review.openstack.org/565407
16:33:54 openstackgerrit Jay Pipes proposed openstack/nova master: Add a microversion for consumer generation support https://review.openstack.org/565604
16:35:21 mriedem so, does anyone know if lyarwood has been hit by a mini bus because today is spec freeze day and i've got a +2 on https://review.openstack.org/#/c/552078/ and a -1 from lee but i don't think i need to make any changes
16:35:33 dansmith mriedem: he's sick
16:35:38 openstackgerrit Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317
16:35:56 mriedem ok
16:36:20 mriedem so, any other core care to take a look at that? we agreed on it in dublin and it came up again in vancouver
16:37:28 dansmith I mean, yeah we could approve with expected addendum if needed, or just trivially excuse it for a few days for clairifcation
16:37:32 dansmith whichever
16:38:27 mriedem tbc, i suspect there are some bugs in how cinder manages read only volumes/attachments,
16:38:36 mriedem but those are dependencies, not really blockers on the general idea
16:40:46 openstackgerrit Merged openstack/nova-specs master: Add additional information for z/VM spec. https://review.openstack.org/562154
16:40:47 openstackgerrit Merged openstack/nova-specs master: Amend allow abort live migrations in queued status spec https://review.openstack.org/560872
16:45:00 dansmith mriedem: aight, well, I don't really have any complaints about it, having skimmed
16:45:20 dansmith mriedem: I guess you just prefer to have it merged and resolve any issues lee may have later yeah?
16:45:25 dansmith I guess I don't really care either way
16:46:06 openstackgerrit Doug Hellmann proposed openstack/python-novaclient master: fix tox python3 overrides https://review.openstack.org/573347
16:57:07 mriedem dansmith: yeah
16:57:21 mriedem but i looked into lee's comments and don't consider them blocking, unless i'm missing something
16:57:31 dansmith yeah
17:03:15 mriedem low hanging fruit opportunity https://bugs.launchpad.net/nova/+bug/1775665
17:03:16 openstack Launchpad bug 1775665 in OpenStack Compute (nova) "api-ref: rebuild server does not mention pre-conditions" [Low,Confirmed]
17:16:15 openstackgerrit Merged openstack/nova-specs master: Spec for volume multiattach enhancements https://review.openstack.org/552078
17:37:23 mriedem melwitt: i'm going to go through some very obvious things targeted against rocky and defer them out https://blueprints.launchpad.net/nova/rocky
17:37:29 mriedem stuff that doesn't have an owner, etc
17:38:01 melwitt mriedem: okay, sounds good. thanks for doing that
17:47:00 karimull Looking for a review on https://review.openstack.org/#/c/565620/ from a core member
17:48:29 mriedem jroll: ^?
17:50:10 jroll mriedem: looks fine
17:50:29 jroll pretty straightforward :)
17:57:33 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Add spec for downloading images via RBD https://review.openstack.org/572805
17:58:50 mriedem dansmith: +2 on this pretty simple spec about using rbd for getting images from local storage even when you're not running the rbd image backend https://review.openstack.org/#/c/572805/
17:59:06 mriedem related to that thread in the ML about the image handler download extension point deprecation
17:59:23 mriedem i have a feeling CERN has also said they wanted something like this for windows images
18:05:19 dansmith hmm
18:05:23 dansmith I didn't realize we still had that
18:05:25 dansmith it's hidden in __init__
18:05:58 melwitt mriedem: thanks for following that btw, I had meant to ask mnaser to chime in about it too because I thought maybe it was something he also needs
18:08:14 mriedem i felt compelled since i deprecated it and sent out the call for input in the ML
18:08:22 mriedem and actually caught a bite
18:08:22 melwitt :)
18:10:44 dansmith we don't have to undeprecate the modules thing for this,
18:11:05 dansmith we can just convert it to a be_smart=True sort of flag I think
18:11:50 dansmith approving this makes me worried that someone that understands the image cache is going to show up and cry foul,
18:12:09 dansmith and it's not very helpful to look at a havana implementation
18:13:04 dansmith I also feel like there are things in that spec you would call out as needing more detail if it wasn't spec deadline day and you weren't flustered by getting a bite on the mailing list
18:14:27 dansmith obviously the idea seems sane

Earlier   Later