Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-07
15:51:19 bauzas mriedem: johnthetubaguy: ie. either we find it, or we fail
15:51:19 mriedem easy workaround - delete the ERROR server and re-create it
15:51:52 johnthetubaguy mriedem: +1
15:52:23 johnthetubaguy given gibi's concerns, I wonder about calling it initial_requested_networks?
15:52:34 johnthetubaguy i.e. its not updated when you add ports later
15:52:40 bauzas johnthetubaguy: no
15:52:48 gibi johnthetubaguy: or update it whenever it changes :)
15:52:55 bauzas johnthetubaguy: requested_networks looks to me the exact naming
15:53:01 bauzas you *requested* a network
15:53:16 gibi bauzas: interface_attach is used to request additional networks
15:53:21 bauzas that doesn't imply you'll get *this* network
15:53:40 johnthetubaguy do we update the security_groups list that is in request_spec today?
15:53:41 bauzas gibi: sure, but then when rebuilding, we only need to know about what the user asked
15:53:55 bauzas johnthetubaguy: nope, AFAIK
15:53:55 mriedem johnthetubaguy: yes
15:53:58 bauzas shit
15:54:01 bauzas we do ?
15:54:16 gibi bauzas: boot, interface_attach, rebuild => you need to know both the originally requested and the later attached network
15:54:19 bauzas we update the instance group info
15:54:23 mriedem https://github.com/openstack/nova/blob/master/nova/compute/api.py#L876
15:54:54 bauzas mriedem: sure, we persist those, but do we update them ?
15:55:07 bauzas well... nevermind, silly question
15:55:18 johnthetubaguy gibi: bauzas: my distraction is we don't need this for regular rebuild (as we need the port_ids, not the network_ids) but we do need it for rebuild from cell0, but agreed we don't what it to be "special"
15:55:40 bauzas I guess johnthetubaguy's point (and gibi's) is to know whether we should persist *both* what the user asked and what the instance got eventually
15:56:03 bauzas gibi: but if the instance got to cell0, it didn't got other networks, right?
15:56:11 gibi johnthetubaguy: I agree, if the persisted field will be used for cell0 only then we have to make it explicity that it is for that case only
15:56:13 johnthetubaguy right, I know we have secuirty_groups from the initial request, but if you change security groups do we update that later on
15:57:21 gibi bauzas: right. How do you make sure that the new RequestSpec field only used for the cell0 case as in any other case that info is potentially stale
15:57:59 johnthetubaguy gibi: my argument is its not useful in any other case, but I suspect I would get proved wrong by something
15:58:36 melwitt mriedem: do we have anything else queued up for ocata that I should wait on for release?
15:58:44 bauzas gibi: if we consider requested_networks as just a picture of what the user asked, I don't see the problem
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 gibi bauzas: I call it precedent
16:03:34 bauzas either way, I think johnthetubaguy only needs the 'requested networks', because he only cares of cell0
16:03:34 openstackgerrit John Garbutt proposed openstack/nova-specs master: Enable rebuild for instances in cell0 https://review.openstack.org/554218
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 gibi bauzas: OK, I rest my case. We can add big fat comment on the field and handle the issue latear
16:04:59 bauzas gibi: people could even create a new field called 'actual_networks' in opposition to 'requested_networks' :)
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

Earlier   Later