| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-27 | |||
| 20:37:16 | melwitt | mriedem: that was based on how long it took last time. but agreed with how empty the etherpad is, maybe should plan for more like 30min - 1 hour | |
| 20:37:29 | melwitt | last time, I think we scheduled 30 min and it took 2 hours, or something like that | |
| 20:38:55 | sean-k-mooney | melwitt: it might be good to add some time to discuss what were our priorities for Rocky and assess how much we got done | |
| 20:39:00 | mriedem | in dublin? | |
| 20:39:06 | mriedem | i thought it took less than an hour in dublin | |
| 20:39:16 | mriedem | we didn't have priorities in rocky | |
| 20:39:44 | melwitt | sean-k-mooney: yeah, I slotted time for priorities discussion at the end on friday this time. I had forgotten last time | |
| 20:40:18 | sean-k-mooney | mriedem: oh i assumed https://specs.openstack.org/openstack/nova-specs/priorities/rocky-priorities.html had a list i should have read it i guess | |
| 20:41:18 | openstackgerrit | Merged openstack/nova master: privsep: Handle ENOENT when checking for direct IO support https://review.openstack.org/596815 | |
| 21:03:20 | melwitt | mriedem: yeah, it took about 2 hours in dublin, that's my memory. the etherpad was pretty big https://etherpad.openstack.org/p/nova-queens-retrospective | |
| 21:04:55 | dansmith | melwitt: wasn't most of that filled in ahead of time? | |
| 21:05:09 | melwitt | most of it yeah | |
| 21:05:24 | dansmith | I'm definitely in favor of time-boxing the retro | |
| 21:05:32 | dansmith | it needs to happen, but it can run away if allowed | |
| 21:06:11 | mriedem | if it helps, placement extraction landmine is technically a stein thing, not a rocky thing :) | |
| 21:06:28 | mriedem | so we could all be hit by buses before having to retrospect on that | |
| 21:06:43 | mriedem | alive! era soccer crash etc | |
| 21:07:20 | sean-k-mooney | mriedem: just like the deltion of nova-networks and cellsv1 retro... | |
| 21:07:29 | mriedem | ? | |
| 21:08:35 | sean-k-mooney | mriedem: extraction of placement feels like deltetion of nova networks in that we have talked about several time in the past. | |
| 21:08:44 | dansmith | um, no | |
| 21:08:52 | dansmith | nobody cares enough to delete nova-network right now :) | |
| 21:09:02 | dansmith | kinda the opposite problem | |
| 21:09:15 | mriedem | i cared enough to neuter several APIs :) | |
| 21:10:02 | sean-k-mooney | dansmith: ya but we really cant undpercate it twice because we never got around to deleting it | |
| 21:10:23 | mriedem | sean-k-mooney: you might just be thinking of all the "are we ready to make neutron the default and deprecate nova-net" discussions | |
| 21:10:28 | dansmith | I'm confused | |
| 21:10:42 | sean-k-mooney | mriedem: perhaps. | |
| 21:11:42 | melwitt | okay, let's plan for a time box of 1 hour then, based on the emptiness of the etherpad and trying to account for things that people bring up on-the-fly. maybe it will be shorter than that, and if so, we'll just start on the next thing | |
| 21:13:23 | sean-k-mooney | melwitt: are you aware of any cross project session with nova on the monday or tuesday? do we have a cyborg session this time? | |
| 21:14:11 | sean-k-mooney | is the operator meetup is collated with PTG this time too? | |
| 21:15:52 | melwitt | sean-k-mooney: no, not that I know of. there are things related to nova in general but no special cross project time has been scheduled | |
| 21:16:24 | mriedem | ops meetup is colocated this time yes | |
| 21:16:29 | mriedem | just in time for the last ptg! | |
| 21:17:16 | sean-k-mooney | mriedem: has that actully been decided? i kindo of stopped caring | |
| 21:17:35 | mriedem | yes, ptg is colocated with the summit starting in denver summit | |
| 21:17:47 | sean-k-mooney | no not that. the future of the ptg | |
| 21:17:52 | mriedem | DOA | |
| 21:17:59 | sean-k-mooney | oh sorry miss read | |
| 21:18:20 | sean-k-mooney | mriedem: so back to the design summit | |
| 21:18:30 | mriedem | yeah i guess | |
| 21:18:47 | sean-k-mooney | and operators meetup will also be colocated with denver summit? | |
| 21:18:55 | mriedem | probably not | |
| 21:18:55 | melwitt | except now it goes also on saturday | |
| 21:19:07 | mriedem | operators will likely go back to self-organizing meetups like they used to | |
| 21:19:15 | mriedem | after we bait and switched them | |
| 21:19:16 | mriedem | suckers! | |
| 21:19:49 | sean-k-mooney | this is why my eye glaze over when i see emails on this topic | |
| 21:22:26 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add contributor guide for upgrade status checks https://review.openstack.org/596902 | |
| 21:37:25 | melwitt | mgagne_: don't forget to re-propose this spec for stein since we didn't get it merged in time for rocky https://review.openstack.org/580742 | |
| 21:39:03 | openstackgerrit | sean mooney proposed openstack/nova master: add regression test for bug 1759420 https://review.openstack.org/587615 | |
| 21:39:03 | openstack | bug 1759420 in OpenStack Compute (nova) "nova does not correctly support HW_DISK_BUS=sata or usb for kvm/qemu" [Medium,In progress] https://launchpad.net/bugs/1759420 - Assigned to sean mooney (sean-k-mooney) | |
| 21:39:04 | openstackgerrit | sean mooney proposed openstack/nova master: libvirt: fix disk_bus handling for root disk https://review.openstack.org/584999 | |
| 21:44:30 | openstackgerrit | Patricia Domingues proposed openstack/nova master: load up the volume drivers by checking architecture https://review.openstack.org/541393 | |
| 21:46:33 | openstackgerrit | Patricia Domingues proposed openstack/nova master: load up the volume drivers by checking architecture https://review.openstack.org/541393 | |
| #openstack-nova - 2018-08-28 | |||
| 01:32:04 | openstackgerrit | JiaJunsu proposed openstack/nova master: Remove args(os=False) in monkey_patch https://review.openstack.org/568999 | |
| 01:51:04 | openstackgerrit | Yikun Jiang (Kero) proposed openstack/nova master: Make monkey patch work in uWSGI mode https://review.openstack.org/592285 | |
| 01:56:55 | prometheanfire | I should be able to `curl http://169.254.169.254/latest/meta-data/instance-id` even on config-drive instances right? | |
| 02:38:10 | donghm | Hi folks, how can I check this number https://github.com/openstack/nova/blob/master/nova/cmd/status.py#L290 via db query or api? | |
| 02:38:19 | donghm | I'm using nova in master | |
| 02:38:35 | donghm | when I run command: nova-status upgrade check | |
| 02:38:59 | donghm | it return There are no compute resource providers in the Placement service but there are 1 compute nodes in the deployment. | |
| 03:58:21 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Transform libvirt.error notification https://review.openstack.org/484851 | |
| 03:58:39 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Adds view builders for keypairs controller https://review.openstack.org/347289 | |
| 03:58:51 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (3) https://review.openstack.org/574104 | |
| 04:41:12 | crazik | hello | |
| 04:41:30 | crazik | Is it safe to cleanup cell mapping table? | |
| 04:42:05 | crazik | I have almost 10k entries there, looks like it was never purged when instances were deleted... | |
| 04:43:15 | crazik | (I want to delete entries where instance_id is no longer in nova instances table | |
| 04:55:17 | openstackgerrit | Merged openstack/nova master: Make instance_list perform per-cell batching https://review.openstack.org/593131 | |
| 07:26:45 | hongda | dansmith : Excuse me. I am working on this patch: "https://review.openstack.org/#/c/579093/" Do you have any questions about this patch now ? | |
| 07:37:03 | moshele | sahid: hi | |
| 07:37:48 | moshele | sahid: I didn't understand you commnet, do you agree with my change? what are the alternative here? | |
| 07:38:12 | sahid | hello moshele, | |
| 07:38:44 | moshele | sahid: I am talking about this commit https://review.openstack.org/#/c/595592/ | |
| 07:39:07 | sahid | i'm not really agree, so i wanted to know your thinking | |
| 07:39:17 | sahid | because i think if we keep your change like that we will have the same issue at some point for an other vif | |
| 07:40:01 | sahid | OR at least what about to add a comment to indicate the limitation of your fix? | |
| 07:41:26 | moshele | sahid: ok, but I am not sure how to do it otherwise because the network_model.VIF_MODEL_VIRTIO is set anyway by this code https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L137-L142 | |
| 07:41:47 | moshele | sahid: and I didn't find any other way to solve this | |
| 07:42:41 | moshele | sahid: I can add that in the future not virtio nics should be skipped as well | |
| 07:43:04 | moshele | sahid: I mean adding a comment ^ | |
| 07:44:49 | sahid | yes... nut i have a last question | |
| 07:44:51 | sahid | but | |
| 07:45:47 | sahid | it seems for me model wil always be VIF_MDEL_VIRTIO that because CONF.libvirt.use_virtio_for_bridges is defaulted to True | |
| 07:46:08 | sahid | so your comment is not really clear, i mean i don't undertand why my initial suggestion is not working | |
| 07:47:03 | moshele | because if the default is CONF.libvirt.use_virtio_for_bridges is True and you will use direct port it will failed | |
| 07:47:09 | sahid | oh i see :) that is the problem actually :) even for VIF DIRECT model is equal to VIRTIO | |
| 07:47:54 | moshele | shaid: and because I don't understandthis option "CONF.libvirt.use_virtio_for_bridges" I didn't want to change the logic there | |
| 07:48:12 | moshele | sahid: ^ | |
| 07:48:18 | sahid | yes i can understand you want to limit the change | |
| 07:48:26 | sahid | i m goint to comment on the review | |
| 07:48:40 | sahid | and see if everyone are agree | |
| 07:48:56 | moshele | sahid: we update the macvtap ci to run with the rx/tx quues option | |
| 07:49:51 | moshele | sahid: and the macvtap ci is passing but it only configure the rx_queue_size | |
| 07:50:16 | moshele | sahid: http://13.74.249.42/92/595592/2/check-nova/Nova-MACVTAP-ML2-Sriov/ea9063b/logs/n-cpu.service.log.gz look for rx_queue_size and not the tx_queue_size | |
| 07:50:54 | moshele | sahid: it seem that the tx_queue_size is configured with vshostuser is that correct behaviour? | |
| 07:52:28 | sahid | yes | |
| 07:52:54 | sahid | for vhostuser you should also be able to configure RX | |
| 07:53:03 | moshele | sahid: ok cool | |