| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-16 | |||
| 17:30:27 | melwitt | eandersson: it is, but I think that's the only way to make it look reasonable and not hide bug that shows the fix etc | |
| 17:30:45 | melwitt | I think someone told me the ones that get marked as dupes don't show up in searches etc | |
| 17:30:57 | mriedem | we can also dupe dan's against the original and change the status to fix released | |
| 17:31:00 | mriedem | on the originla | |
| 17:31:02 | mriedem | *original | |
| 17:31:27 | melwitt | okay, I can do that | |
| 17:31:53 | eandersson | Just don't mark it as fixed for Mitaka | |
| 17:32:21 | melwitt | yeah, will have to put that as won't fix I think | |
| 17:34:03 | melwitt | mriedem: are we gonna backport to mitaka? we still have a stable/mitaka branch | |
| 17:34:35 | eandersson | This is the kind of horrible issue that you will run in production, but won't notice until you reach capacity. So we should make it obvious that it's an issue for anyone running overcommit in Mitaka. | |
| 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 | |