| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-16 | |||
| 17:34:53 | mriedem | melwitt: mitaka is closed i think - the branch is there but i don't know if any ci works on it | |
| 17:35:19 | melwitt | okay | |
| 17:35:24 | mriedem | clarkb: is mitaka CI all dead now? | |
| 17:35:30 | clarkb | uh | |
| 17:35:35 | clarkb | no idea | |
| 17:35:39 | mriedem | ok | |
| 17:36:02 | superdan | didn't tony already announce mitaka as eol? | |
| 17:36:13 | mriedem | announcing and making it happen are different things | |
| 17:36:23 | eandersson | no mitaka eol tag yet at least | |
| 17:36:35 | superdan | I figured I'd have to backport it downstream only for mitaka, fwiw | |
| 17:37:18 | superdan | eandersson: do you want to propose backports of that to ocata and newton at least? | |
| 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 | |