| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-10 | |||
| 13:38:39 | bauzas | mriedem: I'm on PTO today and tomorrow, but see if I can help | |
| 13:43:21 | jroll | jaypipes: bauzas: yeah, I know it's on alex_xu's list to do quotas on resource classes, not sure if he has anything proposed upstream yet | |
| 13:43:45 | stephenfin | mriedem: Sure | |
| 13:43:56 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add NUMANetworkInfo object https://review.openstack.org/564439 | |
| 13:43:57 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Add '[neutron] physnets' and related options https://review.openstack.org/564440 | |
| 13:43:58 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Start populating NUMACell.network_info field https://review.openstack.org/564441 | |
| 13:43:59 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add NetworkRequest.physnet, tunnelled https://review.openstack.org/564442 | |
| 13:44:00 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Unchain _get_phynet_info from _get_port_vnic_info https://review.openstack.org/564443 | |
| 13:44:01 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Add 'populate_networks' to network API https://review.openstack.org/564444 | |
| 13:44:02 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Add '_get_network_tunnel_status' https://review.openstack.org/564445 | |
| 13:44:03 | openstackgerrit | Stephen Finucane proposed openstack/nova master: db: Add network_requests to instance_extra https://review.openstack.org/564446 | |
| 13:44:04 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add Instance.network_requests https://review.openstack.org/564447 | |
| 13:44:05 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hardware: Start accounting for network requests https://review.openstack.org/564448 | |
| 13:44:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: rt: Start utilizing Instance.network_requests https://review.openstack.org/564449 | |
| 13:44:07 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add RequestSpec.requested_networks https://review.openstack.org/564450 | |
| 13:44:08 | openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Remove unnecessary default parameter https://review.openstack.org/564451 | |
| 13:44:09 | openstackgerrit | Stephen Finucane proposed openstack/nova master: scheduler: Start utilizing network_requests https://review.openstack.org/564452 | |
| 13:44:12 | jaypipes | jroll: last I heard, he was focusing on quota-by-aggregate and ran into a number of issues... | |
| 13:44:29 | jroll | jaypipes: yar, he's working through it | |
| 13:44:31 | jaypipes | jroll: sorry, had to wait until stephenfin's patch-cloud passed. | |
| 13:44:35 | jroll | heh | |
| 13:44:47 | stephenfin | ☁ ☁ ☁ | |
| 13:44:56 | jaypipes | which reminds me I need to complete reviews on those. :) | |
| 13:45:36 | stephenfin | jaypipes: Would be appreciated. Fixed the Tempest issue (thanks gibi/mriedem) and addressed what comments were there so far | |
| 13:45:41 | jaypipes | gibi: I've read your ML post about the instance migration UUID thing three times and looked at the map_instances() function. and I still don't get it :( | |
| 13:46:43 | stephenfin | jaypipes: we're using a munged UUID as a marker so we catch batch up the migrations | |
| 13:47:03 | stephenfin | cos it's munged, it's not a valid UUID and oslo.whatever complains | |
| 13:47:35 | jaypipes | stephenfin: right, but I don't understand why we're doing the replace('-','') thing at all | |
| 13:47:36 | stephenfin | edleafe tried to fix it before but dansmith found the solution distressing | |
| 13:47:51 | stephenfin | because there's a UNIQUE constraint on that column | |
| 13:48:07 | stephenfin | if we didn't do that, it would clash with the instance (or whatever that UUID is taken from) | |
| 13:48:08 | jaypipes | stephenfin: ok, but why are we changing it? | |
| 13:48:32 | jaypipes | stephenfin: ah... so all migrations have the same uuid? | |
| 13:49:22 | stephenfin | jaypipes: My memory on this is hazy but I don't think that's it | |
| 13:49:36 | stephenfin | The revert of the edleafe's solution is here 9038738d0134c0a1d59757ed3205d84f76416869 | |
| 13:49:43 | stephenfin | (commit ID) | |
| 13:49:52 | tssurya | jaypipes: we use this as a marker for nova-manage map_instances | |
| 13:51:01 | jaypipes | stephenfin: k, thx for the commit ID. I'll look it up and see if I can understand the problem better. | |
| 13:51:03 | stephenfin | Oh, yeah, now I remember | |
| 13:51:33 | stephenfin | So we store a special string for InstanceMappingList.project_id | |
| 13:51:59 | stephenfin | and then for the UUID value, we store the list of the last InstanceMappingList that we processed | |
| 13:52:32 | stephenfin | but munged, so it won't conflict with that InstanceMappingList's UUID | |
| 13:52:36 | dansmith | I haven't read the thread, | |
| 13:52:53 | dansmith | but we can't change this unless you provide a migration path for people that might be in the middle of the process when they apply the patch | |
| 13:53:39 | dansmith | and if this is just because of the damn o.vo UUIDField warning (which I didn't want in the first place) I think it's not worth a change | |
| 13:55:05 | mrf | Hi, | |
| 13:55:27 | mrf | After a Resize i got Instance at Error with the next drop in nova-compute: InstanceNotFound: Instance 299fd82f-f081-4c81-8226-70d208f10a8f could not be found. any ideas? | |
| 14:05:10 | openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Explain how the marker works for instance-cell mapping https://review.openstack.org/567597 | |
| 14:05:12 | stephenfin | gibi, dansmith: ^ | |
| 14:08:28 | mriedem | bauzas: fyi in case you haven't seen this yet https://openstack-in-production.blogspot.com/2018/05/introducing-gpus-to-cern-cloud.html | |
| 14:08:58 | bauzas | mriedem: just discussed on twitter with tim | |
| 14:09:20 | bauzas | but thanks | |
| 14:13:10 | openstackgerrit | Eric Berglund proposed openstack/nova stable/queens: Stringify instance UUID https://review.openstack.org/567599 | |
| 14:13:35 | tetsuro | jaypipes, efried: Could you have a look at https://review.openstack.org/#/c/567113/5, if you have time? | |
| 14:42:12 | mriedem | dansmith: question in https://review.openstack.org/#/c/509003/ about how the cell_mappings kwarg gets through to the DB API query method, i.e. why you need to do this https://review.openstack.org/#/c/509003/12/nova/tests/unit/api/openstack/fakes.py | |
| 14:42:18 | mriedem | otherwise the rest are nits which can be deal with in a follow up | |
| 14:42:22 | mriedem | *dealt | |
| 14:43:09 | dansmith | ack, will look in a bit | |
| 14:46:00 | sean-k-mooney | i have an interesting (annoying) issue with my teams openstack devcluster ... what does the value of the deleted column in the nova.instnaces table mean? | |
| 14:46:22 | dansmith | sean-k-mooney: deleted=id means the instance is deleted | |
| 14:46:28 | dansmith | deleted=0 means it's not | |
| 14:47:12 | sean-k-mooney | dansmith: thanks. i have an instance that shows up in opentack server list but cant be found when i do a openstack server delete or nova force-delete | |
| 14:47:36 | sean-k-mooney | dansmith: that was exactly what i was looking for ill see if that "deletes it" | |
| 14:47:41 | dansmith | maybe it's missing a mapping? | |
| 14:48:30 | sean-k-mooney | dansmith: or when my database crashed because the binary logs filled up the disk it currupted the entries... | |
| 14:48:36 | dansmith | or that :) | |
| 14:49:24 | sean-k-mooney | dansmith: it was mapped in the nova_api db. i tried deleteing it from there to see if it would be enough but it looks like i have to remove it from the cell0 db too or at least mark it as deleted | |
| 14:49:53 | dansmith | yeah, list will still find it without a mapping unless it's actually deleted | |
| 14:50:35 | sean-k-mooney | dansmith: its currently messsing with my nodepool deployment because it keeps trying to delete it and cant hence my db hacking | |
| 14:50:50 | dansmith | ack | |
| 14:51:02 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Migrate tempest-dsvm-multinode-live-migration job in-tree https://review.openstack.org/567612 | |
| 14:55:31 | jroll | mriedem: fyi, https://review.openstack.org/567577 | |
| 14:55:57 | jroll | thanks for pointing me at that bug, is not good | |
| 14:56:44 | openstackgerrit | Eric Berglund proposed openstack/nova stable/queens: Stringify instance UUID https://review.openstack.org/567599 | |
| 14:57:11 | mriedem | jroll: ok, are there also going to need to be nova changes? | |
| 14:57:57 | jroll | mriedem: not in our driver, I'm not sure what you all do / need to do to shut down the connection on instance destroy | |
| 14:59:25 | mriedem | jroll: that reply is confusing | |
| 14:59:43 | jroll | lemme try again | |
| 14:59:47 | tssurya | mriedem: thanks for triaging https://bugs.launchpad.net/nova/+bug/1768876 , shall I go ahead with the migration tool then for populating the ones that are missing? | |
| 14:59:48 | mriedem | if there is nothing to do in the ironic driver, then i don't think there is anything to change in nova | |
| 14:59:59 | mriedem | tssurya: i was just going to ask you about that, | |
| 15:00:00 | openstack | Launchpad bug 1768876 in OpenStack Compute (nova) queens "metadata-api fails to get availability zone for instances created before pike" [High,Triaged] | |
| 15:00:13 | mriedem | tssurya: it will require some thought, because i'm not sure what got put into instance.availability_zone before that change in pike, | |
| 15:00:32 | mriedem | i.e. is it None if the user doesn't specify an AZ when creating the instance? or does it default to 'nova'? | |
| 15:00:36 | tssurya | wasn't it None ? | |
| 15:00:54 | jroll | mriedem: the driver gives back some console URL, right? and nova's proxy thing connects to it? does that connection need to be closed or do we just let it die? if it needs to be closed, does nova do that already? (I guess this is outside the scope of the bug, but could be an improvement) | |
| 15:00:55 | mriedem | i'm not sure, but it will matter if we add an online data migration routine since we'll need to know which instances need to be migrated | |
| 15:01:18 | tssurya | mriedem: yea, I will try to dig more into the tree then | |
| 15:01:29 | mriedem | jroll: not sure, probably a good question for melwitt | |
| 15:02:02 | jroll | mriedem: ok, I'm sure it isn't urgent anyway. can mark that closes-bug instead if you like, but gonna wait for some reviews/CI results first | |
| 15:03:30 | mriedem | i'll mark invalid for nova, | |
| 15:03:35 | mriedem | and just point to the SB entry | |
| 15:04:22 | jroll | wfm | |
| 15:04:59 | mriedem | unrelated, but looks like issues in storyboard aren't found via google search? | |
| 15:05:13 | jroll | no clue | |
| 15:05:15 | jroll | that would be sad | |
| 15:05:21 | mriedem | like, trump level sad? | |
| 15:05:37 | mriedem | hash tag sad?! | |
| 15:06:09 | jroll | SAD! | |
| 15:09:27 | artom | MALA! | |