Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-18
20:25:10 spotz cfriesen: And no errors in stable/ocata. Let me peek at Pike and master
20:25:13 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: Handle spawning error on unshelving https://review.openstack.org/548622
20:25:46 melwitt thanks cfriesen. found one here https://github.com/openstack/python-novaclient/blob/stable/pike/novaclient/v2/shell.py#L88
20:26:07 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: Clean up volumes on boot failure https://review.openstack.org/545086
20:26:42 melwitt spotz: ^
20:27:02 spotz melwitt: I can patch if you like
20:27:05 melwitt spotz: so, you used stable/ocata novaclient and saw that message? seems like the message only started in pike
20:27:30 spotz melwitt: Yeah just realized this is a Pike packstack, not the Ocata devstack I thought I was on:)
20:27:40 spotz I have too many servers running:(
20:29:01 melwitt spotz: heh, okay. glad it's just the typo then. yeah, if you want to propose a patch to stable/pike, we can review it
20:29:45 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Add root provider uuid to group by clause https://review.openstack.org/562379
20:30:16 spotz melwitt: Only other odd behavior is I had to set the api-version to less then 2.44 but that's part of the warning and I seem to be running 2.53
20:32:31 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: Clean up volumes on boot failure https://review.openstack.org/545086
20:32:32 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: Detach volumes when VM creation fails https://review.openstack.org/545087
20:32:42 melwitt spotz: the novaclient CLI will default to the latest available nova server API microversion (through version discovery) that it supports. on the nova server, the add/remove fixed/floating IP were removed in microversion 2.44, that's why you have to tell novaclient to request an earlier microversion of the API in order to do it
20:32:51 melwitt https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id39
20:33:17 spotz melwitt: So expected behavior:)
20:33:29 melwitt so if you're working with pike, the max microversion in pike is 2.53, so that's what novaclient will default to
20:34:09 melwitt yes, because of the CLI defaulting to latest available and supportable
20:35:21 cfriesen melwitt: I wonder if there should be a checker for implicitly continued strings that don't have a space either at the end of one line or the beginning of the next.
20:35:21 melwitt spotz: the recommended way to associate IPs these days is to use openstackclient as it will make the appropriate calls to neutron (because the association actually happens in neutron)
20:35:30 spotz melwitt: Good to know, I'm trying to be more thorough about using the openstack CLI and the various project CLIs
20:35:58 spotz melwitt: And looks like Neutron is looking for a total depcreation of their client in the near future
20:36:08 melwitt cfriesen: there could be. but I don't wanna figure out how to write it
20:36:22 cfriesen melwitt: have you noticed that openstackclient won't let you live-migrate unless you specify a destination host?
20:37:17 melwitt spotz: yeah, that's the direction, for openstackclient to be the way to do everything. unfortunately for certain nova operations, the openstackclient doesn't support things properly or requires extra steps whereas the novaclient does one step. we need to fix that stuff :(
20:37:34 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Add root and parenet provider uuid to group by clause https://review.openstack.org/562379
20:38:10 melwitt cfriesen: I haven't. but I do know that the one-step boot-from-volume in openstackclient was removed relatively recently. and we need to get that fixed too
20:38:24 spotz melwitt: There's a lot of disparity in the commands as far as functionality. We'll get there eventually, I just try to teach folks as many ways as possible
20:40:44 mriedem dansmith: melwitt: is there a cells meeting happening today?
20:41:05 melwitt mriedem: nay, we didn't have anything for today. do you have anything for today?
20:41:39 mriedem two things kind of
20:41:50 mriedem 1. wanted to know if dansmith is ok with the plan laid out in https://review.openstack.org/#/c/560674/2/nova/api/openstack/compute/services.py@222
20:41:51 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Add root and parenet provider uuid to group by clause https://review.openstack.org/562379
20:42:01 mriedem wrt the get_uuids_by_host performance thing
20:42:17 melwitt spotz: yeah. one thing to know about openstackclient and nova is that the openstackclient does *not* discover the latest version, so if you want to do anything newer in the nova API, you have to pass along the desired microversion on the command line. that trips people up a lot
20:42:33 mriedem 2. was wondering if tssurya was investigating the functional test failures in https://review.openstack.org/#/c/554920/ because they look unrelated but i don't know why they'd fail here
20:43:45 mriedem nvm i think i just figured out #2
20:44:11 melwitt sweet
20:44:23 mriedem have to step away for a few days to realize your mistakes
20:45:00 cdent mriedem: while you're back: are you aware of the life or death of the experimental job that once tested nova with postgres? Is that still around somewhere?
20:45:13 mriedem cdent: neutron has one in their experimental queue
20:45:18 mriedem we don't, but we easily could
20:45:48 cdent something in a recent placement change tweaked things: https://review.openstack.org/#/c/562379/
20:46:07 mriedem ok, give me a sec and i can wip something up
20:46:42 cdent cool, thanks, i'll be back in a few, I need to do dishes etc
20:48:59 melwitt mriedem: earlier today, bmace reported that novaclient 9.1.1 (queens) does not work with multi-attach, making it not possible to use multi-attach with the client in queens. I assumed this is because the max supported microversion in the client is < the multi-attach microversion
20:49:33 mriedem it's in 10.x
20:49:55 mriedem https://github.com/openstack/releases/blob/master/deliverables/queens/python-novaclient.yaml#L16
20:49:59 melwitt yeah, but we couldn't use 10.x for queens because it didn't work with osc, right?
20:50:14 mriedem 10.x isn't in upper-constraints for stable/queens correct
20:50:18 mriedem b/c of osc and horizon
20:50:20 melwitt right
20:50:26 mriedem because i waited until too late to release it
20:52:00 openstackgerrit Matt Riedemann proposed openstack/nova master: Add neutron-tempest-postgres-full to experimental queue https://review.openstack.org/562383
20:52:00 mriedem cdent: ^
20:52:51 melwitt is there anything we can do to fix it? they ran into a problem trying to use heat with the queens requirements and couldn't do multiattach http://eavesdrop.openstack.org/irclogs/%23openstack-nova/latest.log.html#t2018-04-18T17:50:32
20:53:28 cdent mriedem: so the job names are global to a zuul instance and you can choose to incorporate whichever ones you like?
20:54:00 mriedem cdent: yeah. e.g. nova-multiattach is defined in the nova repo, but also used in cinder and tempest repos
20:54:10 cdent rad
20:54:42 mriedem melwitt: well, if the horizon and osc fixes could be backported and released on stable/queens, you could maybe make the argument that upper-constraints on stable/queens could be bumped to include novaclient 10.x
20:55:09 mriedem otherwise, heat on stable/queens would likely have to monekypatch novaclient's upper version limit when making that specific call
20:55:25 cdent I will poke at this more closely in my morning
20:55:52 mriedem the horizon fixes might have made it by queens GA, would have to look
20:56:46 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Add root and parenet provider uuid to group by clause https://review.openstack.org/562379
20:56:51 openstackgerrit Ed Leafe proposed openstack/nova master: Add columns for generation to consumers https://review.openstack.org/557958
20:56:52 openstackgerrit Ed Leafe proposed openstack/nova master: Add the Consumer object https://review.openstack.org/561406
20:56:53 openstackgerrit Ed Leafe proposed openstack/nova master: Add Consumer objects to Allocations https://review.openstack.org/561407
20:56:54 openstackgerrit Ed Leafe proposed openstack/nova master: Add generation checking logic to Consumer https://review.openstack.org/561408
20:56:55 openstackgerrit Ed Leafe proposed openstack/nova master: Add a microversion for consumer generation https://review.openstack.org/562000
20:57:24 melwitt mriedem: I see, okay. I'll go look at that, thanks for the pointer
21:00:28 mriedem melwitt: https://review.openstack.org/#/c/538070/
21:00:42 mriedem so horizon is ok in queens per https://review.openstack.org/#/c/538472/
21:01:08 mriedem osc was fixed in https://review.openstack.org/#/c/550105/
21:01:36 mriedem i don't know how feasible backporting that is
21:01:47 melwitt alright, so osc needs a backport and if that could go smoothly, we could try to bump upper-constraints
21:01:58 melwitt yeah, it looks big
21:02:11 mriedem yeah, if there are no API behavior changes in the osc patch then it could maybe be backported
21:02:22 dansmith mriedem: I'm not sure I get the plan from reading those comments
21:02:27 mriedem i think it was just supposed to be a ton of internal plumbing
21:02:34 mriedem dansmith: it was in an earlier patch set
21:03:00 mriedem https://review.openstack.org/#/c/560674/1/nova/api/openstack/compute/services.py@221
21:03:41 mriedem heat could also use KSA and just not rely on novaclient for that one call altogether...
21:03:47 mriedem which might be in their best interest long term
21:05:07 melwitt how does KSA avoid novaclient?
21:05:35 openstackgerrit Arvind Nadendla proposed openstack/nova-specs master: Handle rebuild of instance with new image https://review.openstack.org/560718
21:07:36 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Add root and parent provider uuid to group by clause https://review.openstack.org/562379
21:08:47 mriedem ksa is just the auth wrapper around the request
21:09:02 mriedem we use ksa exclusively for talking to the placement api for example
21:09:07 mriedem since there is no python-placementclient
21:10:41 melwitt oh, I see. I need to look more at that in placement. I haven't known how that works
21:11:14 mriedem it's in nova.scheduler.client.report.SchedulerReportClient
21:11:26 arvindn05 mriedem: wanted to discuss rebuilding of instance since a lot of comments in the code seem to be added by you on the conductor->scheduler flow
21:11:30 melwitt thanks
21:12:24 arvindn05 mriedem: https://review.openstack.org/#/c/560718/ is updated with the approach so wanted to check i am on right path
21:13:16 openstackgerrit melanie witt proposed openstack/nova stable/pike: only increment disk address unit for scsi devices https://review.openstack.org/561611
21:16:08 arvindn05 basically if image properties have changed we will trigger a scheduler -> placement -> filter flow for all cases where image properties havent changed we will use the existing scheduler -> filter flow(skipping placement)
21:16:19 openstackgerrit melanie witt proposed openstack/nova stable/ocata: only increment disk address unit for scsi devices https://review.openstack.org/561613
21:19:45 cfriesen could one of the cores take a look at https://review.openstack.org/#/c/560690/ ? It's already been approved by lyarwood and melwitt
21:20:33 mriedem arvindn05: ok, i can't really get into that today, but can try to look it over tomorrow

Earlier   Later