| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-16 | |||
| 17:37:31 | mriedem | i was working on the ocata one | |
| 17:37:36 | superdan | eandersson: I'm happy to, but if you do, I can vote on them :P | |
| 17:42:35 | sdague | unless mitaka gets another release though it doesn't help much to stick it in git | |
| 17:43:44 | superdan | well, it helps people that pull from the git trees, but yeah | |
| 17:43:46 | mriedem | fwiw we did a novaclient mitaka release a week or two ago | |
| 17:46:20 | sdague | I'm not opposed to doing another mitaka release honestly, that fix seems like it would be worth it | |
| 17:47:21 | sdague | mriedem: ok, well I just closed out the kilo/liberty bug cruff, and moved all the Fix Committed => Fix Released in mitaka | |
| 17:50:21 | mriedem | ocata backport is posted for your viewing pleasure | |
| 17:50:30 | mriedem | https://review.openstack.org/475044 | |
| 18:08:31 | Redcavalier | Hi, I believe I've found a bug in nova and I haven't seen any similar bug report. However, before I report it, I'd just like to validate it with someone if possible. | |
| 18:10:13 | Redcavalier | Essentially, when using the virtio-scsi driver for block devices, I get an error when I try to add additional block devices through cinder. The error is as follow : libvirtError: internal error: unable to execute QEMU command '__com.redhat_drive_add': Duplicate ID 'drive-scsi0-0-0-0' for drive | |
| 18:11:43 | Redcavalier | It seems that Nova is not providing a good address to libvirt when adding an additional block device to an existing VM using the virtio-scsi driver. Or so that's what I understand from this. | |
| 18:12:25 | Redcavalier | This is in the latest RDO newton release, btw. | |
| 18:14:17 | smcginnis | Redcavalier: Are you using config drive? | |
| 18:14:28 | Redcavalier | smcginnis, nope | |
| 18:15:33 | Redcavalier | neutron metadata because I live dangerously (and it's been working better than my expectations until now, tbh) | |
| 18:27:45 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: produce set of alternative allocations https://review.openstack.org/473377 | |
| 18:28:26 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: produce set of allocation candidates https://review.openstack.org/473377 | |
| 18:33:31 | leakypipes | figleaf: hey, I renamed the ProviderAlternatives to AllocationCandidates above | |
| 18:33:36 | leakypipes | figleaf: naming is hard... | |
| 18:37:25 | mriedem | leakypipes: comments posted https://review.openstack.org/#/c/473377/3 | |
| 18:40:16 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: [WIP] Implement virt driver set_host_enabled https://review.openstack.org/472794 | |
| 18:42:18 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: [WIP] Deactivate powervm compute until ready https://review.openstack.org/471773 | |
| 18:42:18 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: [WIP] Implement virt driver set_host_enabled https://review.openstack.org/472794 | |
| 18:43:11 | figleaf | leakypipes: will review shortly | |
| 18:43:50 | figleaf | leakypipes: I would still like to get a clearer picture in my mind as to where this is heading. Hard to evaluate things otherwise | |
| 18:44:24 | figleaf | leakypipes: I realize that you're coding to the strawman spec, but that strawman spec was just one small piece of the plan | |
| 18:45:25 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: [WIP] Deactivate powervm compute until ready https://review.openstack.org/471773 | |
| 18:45:40 | leakypipes | figleaf: ack | |
| 18:45:51 | leakypipes | figleaf: working on the followup patches which add that to the picture now. | |
| 18:46:48 | figleaf | leakypipes: kewl | |
| 18:50:32 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: [WIP] Deactivate powervm compute until ready https://review.openstack.org/471773 | |
| 18:57:24 | leakypipes | figleaf: link for your extra specs patch pls? | |
| 19:03:21 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: [WIP] Implement virt driver set_host_enabled https://review.openstack.org/472794 | |
| 19:05:54 | mriedem | eandersson: superdan: newton backport https://review.openstack.org/475057 | |
| 19:10:18 | eandersson | Looks good - that patch is identical to the patch we have been running since last year | |
| 19:24:21 | figleaf | leakypipes: https://review.openstack.org/#/c/473627/ | |
| 19:25:25 | figleaf | leakypipes: your input on handling the exception for an invalid extra_spec value would be appreciated on that | |
| 19:27:38 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Microversion 2.48: Standardization of VM diagnostics https://review.openstack.org/473228 | |
| 19:27:58 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Microversion 2.49 - Enable cold migration with target host https://review.openstack.org/406707 | |
| 19:28:16 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Microversion 2.49 - List/Show all server migration types https://review.openstack.org/430839 | |
| 19:29:23 | NostawRm | heh, I never know if what I'm asking is appropriate for this channel. Wouldn't it be useful to have the option to recreate config_drive on boot/reboot? I'm doubting it would be simple enought to do it only if data has changed, but as it stand right now, the only way to get up-to-date data in the drive is to manually remove the existing drive, or am I missing something? | |
| 19:29:41 | mriedem | NostawRm: yes that's a thing people have talked about for awhile | |
| 19:30:02 | NostawRm | okay, cool, I couldn't find anything about it and I wasn't sure if I was missing something on it | |
| 19:30:22 | mriedem | i believe harlowja was also talking about this in an operators ML thread at one point | |
| 19:30:30 | harlowja | wut | |
| 19:30:36 | NostawRm | it wouldn't be the first time that I thought something would be useful and there's good reason not to do it lol | |
| 19:30:47 | mriedem | harlowja: refresh config drive on reboot | |
| 19:30:51 | harlowja | ah | |
| 19:31:03 | mriedem | this thread http://lists.openstack.org/pipermail/openstack-operators/2017-May/013548.html | |
| 19:31:07 | harlowja | ya, so its i mean theoritically possible | |
| 19:31:19 | harlowja | i just know that cloud-init won't refresh/reread that data | |
| 19:31:29 | harlowja | (so normal images using cloud-init won't understand such a refresh) | |
| 19:31:42 | harlowja | it only will re-read things if the instance-id changes | |
| 19:31:51 | harlowja | or u delete the cloud-init data cache lol | |
| 19:32:04 | NostawRm | oh, it won't? I didn't know that about cloud-init | |
| 19:32:10 | harlowja | ya | |
| 19:32:29 | NostawRm | bah, caches, the bane of my day | |
| 19:32:49 | harlowja | example, https://gist.github.com/harlowja/e66514030588d7fcebcaa152ce7ec0be | |
| 19:32:55 | harlowja | its cache | |
| 19:34:06 | harlowja | u can wipe `/var/lib/cloud/instances/` and that will cause it to refresh, but its not designed to understand such refresh (unless instance-id gets transformed) | |
| 19:34:45 | NostawRm | yeah, and that's no good, which means that even going the route of using DHCP again for the metadata service isn't going to help | |
| 19:34:55 | harlowja | yup | |
| 19:35:19 | harlowja | the link mriedem showed was about how there are already mutable things in the metadata service (that my guess most people don't know about lol) | |
| 19:36:00 | harlowja | and those mutable things aren't propagated to the config-drive | |
| 19:36:14 | harlowja | so there is a bug/feature-discrepancy/hidden-feature? already | |
| 19:36:35 | NostawRm | I think that puts me building a per-boot script that pulls what I want :/ | |
| 19:36:47 | harlowja | ya, just be careful imho | |
| 19:36:52 | harlowja | we have a cron job that does something like that | |
| 19:37:02 | harlowja | and it can create a bunch more traffic than u would normally get :-P | |
| 19:37:12 | harlowja | (on the metadata service) | |
| 19:37:26 | harlowja | so use it with caution | |
| 19:37:42 | cfriesen | dansmith: mriedem: anyone else: why did we keep db.pcidevice_online_data_migration and db.aggregate_uuids_online_data_migration in Newton online data migrations when they were already in Mitaka? | |
| 19:37:42 | harlowja | espcially if u put it in all vms... | |
| 19:38:14 | NostawRm | I'd hope it wouldn't be too bad with it being per boot and not a timed job, but I'm probably underestimating | |
| 19:38:40 | harlowja | NostawRm just do some calculations | |
| 19:38:45 | harlowja | just incase :-P | |
| 19:39:11 | mriedem | figleaf: i took the liberty https://review.openstack.org/#/c/473627 | |
| 19:40:06 | mriedem | cfriesen: because you can install the new code in a venv or container and run the migrations before upgrading from mitaka to newton | |
| 19:40:07 | NostawRm | I genuinely appreciate the input harlowja, I kept wanting to keep everything contained to the config_drive and cloud-init because it felt 'proper' but it is what it is | |
| 19:40:41 | mriedem | cfriesen: also, it's not science, sometimes we just don't cleanup for a release or two | |
| 19:40:41 | mriedem | since it's not urgent | |
| 19:40:50 | harlowja | NostawRm ya | |
| 19:40:52 | mriedem | cfriesen: e.g. https://review.openstack.org/#/c/460377/ | |
| 19:41:10 | cfriesen | NostawRm: config drive is tricky, it's not persisted in the DB anywhere. | |
| 19:41:13 | figleaf | mriedem: ok, I can log it. If operators shoot themselves in the foot that way... | |
| 19:42:03 | NostawRm | cfriesen, yeah, I've noticed, I've been digging which is why I felt okay poking about it in the dev channel :P | |
| 19:42:19 | NostawRm | meta data in general seems finicky, or atleast in my use case | |
| 19:42:23 | cfriesen | NostawRm: I have used the mutable metadata service stuff though | |
| 19:44:02 | NostawRm | like I'm going to be giving multiple IPs to the interfaces of instances, ant the metadata service just picks the first IP but that may not be the 'main ip' that was set aside for licensing purposes :/ | |
| 19:44:45 | harlowja | cfriesen NostawRm ya, i think smoser (another cloud-init guy, the main guy really) doesn't want config-drive at all, lol | |
| 19:44:51 | cfriesen | mriedem: doing an upgrade from Mitaka to Newton, one of the "type-PF" entries in table pci_devices ended up with a non-null entry under the "parent_addr" column, which is I think unexpected. Not sure yet if it's upstream code or ours, but its odd. | |
| 19:45:33 | mriedem | cfriesen: i believe that's already fixed | |
| 19:45:52 | NostawRm | harlowja, :/ that's odd, I like the config-drive better, partially because I wasn't going to use DHCP | |
| 19:45:59 | mriedem | cfriesen: https://github.com/openstack/nova/commit/ad12fa65f5cc06bdee52be49b7370d703855d618 | |
| 19:46:06 | cfriesen | harlowja: I proposed dropping it and allowing specifying personality files on an evacuate the way we do now for rebuild. (since config drive gets lost on evacuate currently) | |
| 19:46:31 | cfriesen | NostawRm: by the way, config drive gets lost on evacuate. :) | |
| 19:46:34 | harlowja | cfriesen right | |
| 19:46:34 | mriedem | cfriesen: you should be getting the latest stable branch releases before doing your upgrade | |
| 19:46:49 | NostawRm | cfriesen, don't think they do when using rbd, but I'd have to double check | |