| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-27 | |||
| 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 | melwitt | except now it goes also on saturday | |
| 21:18:55 | mriedem | probably not | |
| 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 | 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:03 | openstackgerrit | sean mooney proposed openstack/nova master: add regression test for bug 1759420 https://review.openstack.org/587615 | |
| 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 | |
| 07:54:42 | moshele | sahid: so my fix will make it work on rx_queue_size macvtap | |
| 07:55:28 | moshele | sahid: I will update my commit soon. thank for the help :) | |
| 07:56:16 | sahid | moshele: thanks for your work on it :) | |
| 08:05:05 | openstackgerrit | Tushar Patil proposed openstack/nova-specs master: Bi-directional enforcement of traits https://review.openstack.org/593475 | |
| 08:21:55 | openstackgerrit | Alex Xu proposed openstack/nova-specs master: Resource retrieving: add change-before filter https://review.openstack.org/591976 | |
| 08:56:08 | moshele | sahid: another way is that I will change the code to skip setting the model to virtio in https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L137-L142 for direct passthoght ports and then I can do you check of the virtio model. I think this will be cleaner | |
| 09:21:44 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Use new-style choice values https://review.openstack.org/530924 | |
| 09:24:07 | openstackgerrit | Moshe Levi proposed openstack/nova master: libvirt: skip setting rx/tx queue sizes for not virto interfaces https://review.openstack.org/595592 | |
| 09:55:07 | sahid | moshele: yes sounds, can you comment so other contributors that are involved on the patch can understand why you decided to do that :) | |
| 10:46:12 | Tahvok | Hey guys! I'm trying to understand why nova conductor is receiving a lot of messages.. I mean I get from 30 to 120 messages a second. The environment is not small, we have around 160 compute hosts, but it's not very active. We have a new instance coming up/deleted every hour or so | |
| 10:47:08 | Tahvok | Apart from it, we have our rabbit service working with 100% up to 400% cpu all the time, and along with it, we see the nova-conductor service processes taking 10% cpu each | |
| 10:53:12 | sean-k-mooney | Tahvok: i could be wrong but it think all database acess from the computenodes is relayed via the conductor so the periodic jobs that update the compute node resouces and health will be a portion of those messages | |
| 10:53:50 | Tahvok | sean-k-mooney: thanks.. I | |
| 10:54:12 | Tahvok | I've just tried something else: default_log_levels = oslo,messaging=DEBUG | |
| 10:54:35 | Tahvok | And I see lots of messages like this: 2018-08-28 05:54:26.497 23601 DEBUG oslo.messaging._drivers.impl_rabbit [-] Timed out waiting for RPC response: Timeout while waiting on RPC response - topic: "<unknown>", RPC method: "<unknown>" info: "<unknown>" _raise_timeout /openstack/venvs/nova-15.1.25/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py:1052 | |
| 10:55:16 | Tahvok | What are this unknown calls? Also, rabbit seems to be working fine, as we don't have any timeout issues when creating new instances | |
| 10:55:26 | sean-k-mooney | hum that not very desciptive. we probaly should have better logging | |