| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-30 | |||
| 22:17:49 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (15) https://review.opendev.org/576031 | |
| 22:18:06 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (16) https://review.opendev.org/576299 | |
| 22:22:47 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (17) https://review.opendev.org/576344 | |
| 22:22:59 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (18) https://review.opendev.org/576673 | |
| 22:23:23 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (19) https://review.opendev.org/576676 | |
| 22:24:06 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (20) https://review.opendev.org/576689 | |
| 22:24:37 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (21) https://review.opendev.org/576709 | |
| 22:24:54 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (22) https://review.opendev.org/576712 | |
| 22:25:16 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in virt/test_block_device.py https://review.opendev.org/566153 | |
| #openstack-nova - 2019-07-01 | |||
| 00:00:11 | adriant | is there any documentation on what the difference (from a Nova perspective) of a volume snapshot vs an instance snapshot? I'm trying to figure out what workflow behind instance action 'createImage' | |
| 00:00:52 | adriant | From what I can tell, if the instance is backed by a persistent volume, it creates a volume snapshot for me | |
| 00:01:51 | adriant | if the instance is backed by an ephemeral volume it triggers the creation of an image (instance snapshot is what the horizon gui calls it). | |
| 00:02:18 | adriant | I've also been told that ' | |
| 00:03:15 | adriant | that an 'instance snapshot' also somehow can take into account multiple volumes attached to an instance and include all of that into a single snapshot, but that functionality isn't documented anywhere, or is it specific to certain volume drivers? | |
| 06:12:09 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Add neutron-tempest-iptables_hybrid job to experimental queue https://review.opendev.org/667154 | |
| 06:12:10 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Revert resize: wait for events according to hybrid plug https://review.opendev.org/667177 | |
| 06:46:42 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Revert resize: wait for events according to hybrid plug https://review.opendev.org/667177 | |
| 08:18:22 | gibi | stephenfin: hi! could you please look back to https://review.opendev.org/#/c/641679/ ? you were +2 before | |
| 09:06:02 | kashyap | gibi: Hi, can you ACK|NACK this stable/rocky backport, please? -- https://review.opendev.org/#/c/667436/ (libvirt: Rework 'EBUSY' (SIGKILL) error handling code path) | |
| 09:06:22 | kashyap | It already has a +2. (And FWIW, its stable/queens counterpart is merged.) | |
| 09:08:11 | gibi | kashyap: I have no +2 power on stable, but the backport looks OK to me | |
| 09:08:38 | kashyap | gibi: Hmm, very bizarre; johnthetubaguy ^ Want to put the stable/rocky one, too? | |
| 09:08:54 | gibi | kashyap: and I think you ment stable/stain counterpart :) | |
| 09:09:08 | kashyap | gibi: Err, indeed :-) | |
| 09:09:21 | johnthetubaguy | I can take a peak | |
| 09:09:41 | gibi | kashyap: this is the stable core group https://review.opendev.org/#/admin/groups/540,members | |
| 09:09:49 | kashyap | Yeah, saw that | |
| 09:09:57 | kashyap | johnthetubaguy: Thanks; you ACKed one of the backports | |
| 09:10:21 | kashyap | johnthetubaguy: Also, I'm almost done through reworking the OVMF spec, hope to push out a new version EOD or tomm. Want to get it past the "finish line" | |
| 09:10:33 | kashyap | (Addressing your feedback, i.e.) | |
| 09:11:50 | johnthetubaguy | kashyap: ah, cool, it is spec review day tomorrow, although I am on a train to bristol and all day meeting tomorrow, so going through stuff today | |
| 09:12:11 | kashyap | johnthetubaguy: Oh, okay; is tomm the last deadline or what for specs? | |
| 09:12:36 | kashyap | Regardless, /me will work through it. Was busy with some downstream stuff | |
| 09:12:39 | johnthetubaguy | more just a big push, that you might want to get cought up in, if you can | |
| 09:13:43 | johnthetubaguy | kashyap: no worries, we all know that feeling of being pulled in 12 directions | |
| 09:14:20 | johnthetubaguy | actually little francis literately pulls at my leg now when he decides I am not listening | |
| 09:14:55 | kashyap | Hehe | |
| 09:18:52 | openstackgerrit | pengyuesheng proposed openstack/python-novaclient master: Add Python 3 Train unit tests https://review.opendev.org/668395 | |
| 09:20:41 | openstackgerrit | pengyuesheng proposed openstack/python-novaclient master: Blacklist sphinx 2.1.0 (autodoc bug) https://review.opendev.org/668398 | |
| 10:09:11 | ysandeep | #openstack-nova, Is there OpenStack cli alternative for this command "nova boot --flavor m1.medium --block-device source=image,id=<image-id>,dest=volume,size=10,shutdown=preserve,bootindex=0 --nic net-id=<net-id> --key-name mykey test_instance" | |
| 10:37:55 | openstackgerrit | Merged openstack/nova master: Add integration testing for heal_allocations https://review.opendev.org/667994 | |
| 10:46:17 | tssurya | bauzas: stable stein easy review if you have time - https://review.opendev.org/#/c/667948/ | |
| 10:46:35 | tssurya | and the corresponding rocky one: https://review.opendev.org/#/c/667955/1 | |
| 11:06:01 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Revert resize: wait for events according to hybrid plug https://review.opendev.org/667177 | |
| 12:53:34 | openstackgerrit | Brin Zhang proposed openstack/nova master: Specify availability_zone to unshelve https://review.opendev.org/663851 | |
| 13:21:04 | openstackgerrit | ya.wang proposed openstack/nova-specs master: Re-propose the spec to allow specifying a list of CPU models https://review.opendev.org/642030 | |
| 13:22:49 | openstackgerrit | ya.wang proposed openstack/nova-specs master: Re-propose the spec to allow specifying a list of CPU models https://review.opendev.org/642030 | |
| 13:24:21 | openstackgerrit | Brin Zhang proposed openstack/nova master: Specify availability_zone to unshelve https://review.opendev.org/663851 | |
| 13:45:58 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Handle HostMappingNotFound when deleting a compute service https://review.opendev.org/666872 | |
| 13:45:59 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Delete resource providers for all nodes when deleting compute service https://review.opendev.org/666874 | |
| 13:47:56 | lyarwood | mriedem: https://review.opendev.org/#/c/668123/ - would you mind hitting that today if you have time? | |
| 13:48:54 | openstackgerrit | Merged openstack/nova stable/stein: Grab fresh power state info from the driver https://review.opendev.org/667948 | |
| 14:06:25 | bauzas | tssurya: ack | |
| 14:16:43 | mriedem | lyarwood: yeah i have a tab open for it already; i was wondering if it should wait until after the next queens release because i just did a rocky release and queens was next | |
| 14:17:05 | mriedem | i.e. might be good to only release things in queens that have already been released in rocky already | |
| 14:19:02 | lyarwood | mriedem: ah yeah that's fair | |
| 14:22:43 | kashyap | I'm feeling stupid, can anyone tell why is this stable/rocky backport Zuul -2? -- https://review.opendev.org/#/c/667436/ | |
| 14:23:26 | kashyap | (It's cherry-picked from master; and it's merged.) | |
| 14:29:52 | mriedem | tempest-slow FAILURE in 2h 06m 01s | |
| 14:32:52 | openstackgerrit | Martin Midolesov proposed openstack/nova master: Implementing graceful shutdown. https://review.opendev.org/666245 | |
| 14:49:01 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations https://review.opendev.org/637955 | |
| 14:49:01 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: WIP: Add rollback to heal port allocation https://review.opendev.org/668184 | |
| 15:02:47 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Disable limit if affinity(anti)/same(different)host is requested https://review.opendev.org/659246 | |
| 15:08:17 | kashyap | mriedem: Thanks! I'm blinder than a mole. | |
| 15:08:49 | kashyap | Guess it's one of those fully useful timeouts. | |
| 15:27:30 | mriedem | lyarwood: can you take a look at these queens backports? https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:stable/queens+topic:bug/1830747 | |
| 15:32:38 | openstackgerrit | Merged openstack/python-novaclient master: Blacklist sphinx 2.1.0 (autodoc bug) https://review.opendev.org/668398 | |
| 15:35:31 | mriedem | need another non-lee stable core for this queens backport https://review.opendev.org/#/c/662471/ | |
| 15:50:52 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: WIP: Add rollback to heal port allocation https://review.opendev.org/668184 | |
| 15:51:45 | gibi | mriedem: what do you prefer? Should I squash the rollback code ^^ into the heal port allocation patch or keep it separate | |
| 15:54:51 | mriedem | gibi: we can drop the code in the original change that generates the list of manual commands to run if we have the rollback stuff right? | |
| 15:55:19 | gibi | mriedem: no, we have to tell the admin what to do when whe rollback fails | |
| 15:55:20 | mriedem | i'd prefer that we rollback and drop the manual list of commands that get generated if possible | |
| 15:55:55 | gibi | mriedem: I mean I can drop it from the original patch and re-introduce it in the rollback patch | |
| 15:56:01 | gibi | if you prefer | |
| 15:58:37 | mriedem | to be clear, the only manual set of commands you plan on dumping are for the port update rollbacks, right? not the thing for the allocations. | |
| 15:59:56 | mriedem | because now we'll be doing: 1. port updates - if good, put allocations, else rollback port updates, 2. if put allocations is good, we're done for that instance, else rollback port updates | |
| 15:59:56 | gibi | commands are only for cleaning the allocation key from the binding:profile | |
| 16:00:42 | efried | I was thinking, does it cost us anything to *gather* those CLIs? Would be useful to print them if you selected --don't-heal-port-allocations-I'll-do-it-myself | |
| 16:00:44 | mriedem | right so we don't need https://review.opendev.org/#/c/637955/29/nova/cmd/manage.py@1876 and _port_update_to_openstack_cli if we move the port updates to before the PUT allocatoins call | |
| 16:01:19 | mriedem | efried: you mean --skip-port-allocations ? | |
| 16:01:23 | mriedem | we don't even hit this code if you specify that | |
| 16:01:24 | efried | yeah | |
| 16:01:27 | efried | i know | |
| 16:01:29 | efried | swhat I'm saying | |
| 16:01:30 | mriedem | and i really don't want to chase CLIs | |
| 16:01:52 | gibi | mriedem: we need a very similar piece of code in the rollback code https://review.opendev.org/#/c/668184/3/nova/cmd/manage.py@1947 | |
| 16:02:54 | gibi | mriedem: so I can drop https://review.opendev.org/#/c/637955/29/nova/cmd/manage.py@1876 from that patch, but then I will re-introduce a similar CLI generating code in the rollback patch https://review.opendev.org/#/c/66818 | |
| 16:03:14 | gibi | mriedem: or shall I only tell the admin to clean the allocation key but not generate the CLI for it? | |
| 16:04:50 | gibi | efried: if we go and try to heal the port allocations then generating CLIs is cheap. But if we are asked not to heal port allocations with --skip-port-allocations then we don't even call neutron to see if there is anything to heal. So in that case it is expensive to generate CLIs | |
| 16:05:11 | mriedem | i just don't really like generating CLIs from a CLI | |
| 16:05:40 | mriedem | i think i'd prefer to describe something in https://docs.openstack.org/nova/latest/admin/support-compute.html and just link to that | |
| 16:06:40 | mriedem | i think i'd also prefer to squash the changes | |
| 16:06:45 | gibi | mriedem: I can dump the port id's that needs to be updated and link to https://docs.openstack.org/nova/latest/admin/support-compute.html where I write a CLI template. But I don't see why I the admin needs to go through these hops to run a CLI at then end | |
| 16:07:35 | mriedem | it seems easier and more future proof to document the situation and recovery solution in the docs than in code is all | |
| 16:07:48 | mriedem | if this needs to change, it would be easier to do it in the docs i think | |
| 16:08:04 | gibi | mriedem: OK, I will go with your suggestion and write the CLI in the doc. (and squash the changes) | |
| 16:08:07 | gibi | mriedem: thanks | |
| 16:10:11 | mriedem | stephenfin: a couple of comments in this queens backport https://review.opendev.org/#/c/629597/ | |
| 16:15:40 | efried | gibi: You going to fold in https://review.opendev.org/#/c/668062/ as well? | |