Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-07
15:45:29 openstackgerrit Curt Moore proposed openstack/nova-specs master: Add spec for downloading images via RBD https://review.openstack.org/572805
15:45:44 mriedem bauzas: you'd likely have to persist the requested networks in the request spec
15:45:50 mriedem like everything else that comes in on the POST /servers request
15:46:05 mriedem except bdms and config drive and the other 50 things you can request when creating a server...
15:46:25 mriedem but that stuff gets stored on the instance, where as requested_networks don't
15:47:10 mriedem i'll also say, for the record, that i don't think given the timing that pre-emptible instances / rebuild from cell0 are priorities for rocky
15:47:20 mriedem it's way too big at this point
15:47:21 mriedem imo
15:47:56 mriedem dansmith: you were right, that pike backport failed http://logs.openstack.org/48/573248/2/check/nova-tox-functional/fd4d7a5/testr_results.html.gz
15:48:04 dansmith mriedem: yeah I'm running tests now to fi
15:48:06 dansmith *fix
15:48:08 mriedem ack
15:48:15 johnthetubaguy mriedem: yeah, that's fair, I mean its been in review for months, but we only just getting close on the details now
15:48:46 bauzas mriedem: don't get me wrong, I agree with persisting requested_networks in the ReqSpec
15:48:57 melwitt mriedem: +1 on pre-emptible instances, I was wondering similar yesterday when I was looking over the spec to add the PENDING state
15:49:01 bauzas mriedem: that's exactly the reason why we have this object
15:49:29 melwitt if it's too early to be starting on those? I dunno
15:49:37 bauzas mriedem: but my concern is not about persisting the field for the new instances that are created once we start persisting this info
15:49:47 melwitt mriedem: unrelated but just updated the hash for the ocata release https://review.openstack.org/571522
15:50:10 bauzas mriedem: my wonders come from the situation where we also need to discover the networks for the instances that are *already* created and having a request_spec record
15:50:38 mriedem bauzas: so something already in cell0 that doesn't have requested networks in cell0
15:50:41 mriedem in that case, you can't rebuild it
15:50:45 bauzas that's why I'm wondering how we can get this info, and populate the req_spec record accordingly thru a data migration or something like that
15:50:46 johnthetubaguy bauzas: I think we just fail the API call for old instances
15:50:48 mriedem 409
15:50:52 johnthetubaguy yeah, +1
15:50:59 johnthetubaguy just added that comment on the spec
15:51:08 bauzas mriedem: johnthetubaguy: I don't disagree, I just mean we need to say this in the specd
15:51:14 johnthetubaguy yup
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

Earlier   Later