| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-07 | |||
| 08:35:53 | bauzas | tomorrow | |
| 08:36:13 | hrw | bauzas: as I do not have multinode setup which is required for some tests | |
| 08:36:26 | bauzas | I'm just surprised to see operators beginning to deploy on ARM64 machines while Nova doesn't officially support it | |
| 08:36:42 | bauzas | hrw: there is a question mark lebelling possible | |
| 08:36:46 | bauzas | labelling | |
| 08:36:57 | bauzas | like say "?" if you don't know the answer yet | |
| 08:36:59 | hrw | bauzas: we concentrated more on getting whole stack running more than on small issues here and there | |
| 08:37:10 | bauzas | that's understandable | |
| 08:37:36 | hrw | bauzas: Kolla work took most of my previous year and it paid off nicely. | |
| 08:37:42 | bauzas | hrw: I have a couple of Pi3 at home, do you think I could test myself ? ;) | |
| 08:38:09 | hrw | I just run a job on Jenkins and in 2.5h I have ~250 images built and pushed to hub.docker so we can use those | |
| 08:38:54 | hrw | bauzas: haha | |
| 08:39:25 | hrw | I hope that once we move jenkins builder to better network I will fit build phase in 1.5h | |
| 08:41:23 | rabel | could we merge https://review.openstack.org/#/c/535871/ ? it's a backport of a small docu fix to stable/pike | |
| 08:41:40 | hrw | bauzas: ok, so where in code data for support matrix is? | |
| 08:41:59 | bauzas | rabel: looking | |
| 08:44:15 | rabel | bauzas: thanks! | |
| 08:44:31 | bauzas | hrw: sec, finding it | |
| 08:44:38 | hrw | bauzas: hm. looks like I can dig through tempest test results to get feature completion status | |
| 08:45:39 | bauzas | hrw: https://github.com/openstack/nova/blob/master/doc/source/user/feature-classification.rst | |
| 08:45:43 | hrw | thx | |
| 08:45:50 | bauzas | hrw: for the feature classification page, ideally | |
| 08:45:58 | bauzas | hrw: for the support matrix page, no | |
| 08:46:14 | bauzas | take the VGPU effort I made this cycle | |
| 08:46:26 | bauzas | we don't have Tempest tests that verify thzt | |
| 08:46:43 | bauzas | sometimes docs is better than no docs | |
| 08:46:52 | hrw | sure | |
| 08:47:02 | hrw | we do not have gpus | |
| 08:47:09 | bauzas | and https://github.com/openstack/nova/blob/master/doc/source/user/support-matrix.rst | |
| 08:47:32 | bauzas | you can see those are actually ini files we source in the sphinx doc | |
| 08:47:50 | bauzas | https://github.com/openstack/nova/blob/master/doc/source/user/support-matrix.ini being the reference page to update | |
| 08:53:48 | openstackgerrit | Thomas Goirand proposed openstack/python-novaclient master: Fix crashing console-log https://review.openstack.org/541610 | |
| 08:57:56 | openstackgerrit | Claudiu Belu proposed openstack/nova master: hyperv: Cleans up live migration Planned VM https://review.openstack.org/478943 | |
| 08:58:51 | hrw | hm. https://refstack.openstack.org/#/results/29ec537b-1463-4fee-b860-1329455ea5df shows what pass/fail but hides parts which can be useful to fill matrix ;D | |
| 08:59:13 | openstackgerrit | sahid proposed openstack/nova master: libvirt: disconnect volume from host during detach https://review.openstack.org/515008 | |
| 09:03:53 | claudiub|2 | artom: hi. around? | |
| 09:15:48 | hrw | bauzas: https://paste.fedoraproject.org/paste/vUX3Ar7XAQ3J1k~Au4kzfw - something like that but with less '=unknown' values, right? | |
| 09:24:39 | lyarwood | bauzas, melwitt ; https://review.openstack.org/#/c/540679/ is another follow up to matt's https://review.openstack.org/#/c/539739/ bugfix for LM with encrypted volumes if you have time today. | |
| 09:26:12 | claudiub|2 | artom: just so you know: https://review.openstack.org/#/c/541633/ | |
| 09:28:51 | bauzas | hrw: what you're pasting is for the feature classification, good with me | |
| 09:29:09 | bauzas | hrw: there is another https://github.com/openstack/nova/blob/master/doc/source/user/support-matrix.ini to update | |
| 09:29:09 | hrw | bauzas: thx. now I know what to do | |
| 09:29:16 | hrw | sure | |
| 09:29:25 | bauzas | hrw: you can test your docs change by running tox -edocs | |
| 09:29:41 | bauzas | and then the directory build/html/ | |
| 09:30:43 | bauzas | lyarwood: okay, will look | |
| 09:31:47 | hrw | ok. refstack output is useless for that | |
| 09:32:09 | hrw | will have to check how to run tempest | |
| 09:32:09 | lyarwood | bauzas: thanks | |
| 09:47:11 | hrw | ok, got tempest running | |
| 09:50:12 | hrw | meh. whoever wrote support matrix docs was neither fan of people nor tempest | |
| 09:50:51 | hrw | tempest output gives test names. refstack gives test names from tempest. | |
| 09:51:09 | hrw | support matrix requires you to dig through tempest code to map UUID to test names | |
| 09:52:22 | hrw | why.... | |
| 09:54:59 | hrw | now to check 'operation.server-shelve' I need to dig out 1164e700-0af0-4a4c-8792-35909a88743c and c1b6318c-b9da-490b-9c67-9339b627271f uuids from tempest code to know what to look for in tempest.log | |
| 09:55:10 | hrw | what kind of #$%@$%@ wrote it that way? | |
| 09:55:48 | hrw | was it so hard to either inject UUIDs into tempest.log or use test names? | |
| 09:56:16 | openstackgerrit | sahid proposed openstack/nova stable/pike: live-mig: keep disk device address same https://review.openstack.org/541642 | |
| 10:09:11 | ameeda | Morning :) | |
| 10:09:29 | ameeda | I need +2w here https://review.openstack.org/#/c/528385/ | |
| 10:17:08 | hrw | bauzas: sorry but with this level of tools I really wonder how status matrix moves forward | |
| 10:18:45 | bauzas | hrw: sorry in a meeting | |
| 10:21:35 | hrw | np | |
| 10:21:58 | openstackgerrit | Merged openstack/nova stable/pike: Fix format in live-migration-usage.rst https://review.openstack.org/535871 | |
| 10:23:56 | openstackgerrit | jichenjc proposed openstack/nova master: Only log during pop retry phase https://review.openstack.org/541655 | |
| 10:36:43 | openstackgerrit | Leopard Ma proposed openstack/nova master: fix paused instance not support shelve https://review.openstack.org/541660 | |
| 10:50:45 | cgoncalves | sean-k-mooney: ping | |
| 10:52:01 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Make bdms querying in multi-cell use scatter-gather and ignore down cell https://review.openstack.org/541246 | |
| 10:56:33 | stephenfin | sean-k-mooney, cfriesen, efried: Just read through all that log from last night. We really need to get this information into a doc or spec somewhere | |
| 10:58:27 | stephenfin | efried: Also, as cfriesen points out, guests with multiple virtual NUMA nodes are a thing and a necessary thing at that (it's the only way you can attach multiple PCI devices to an instance, if those PCI devices aren't affined to the same socket) | |
| 11:00:32 | cgoncalves | ralonsoh: hi. do you plan to resume https://review.openstack.org/#/c/485228 ? | |
| 11:02:43 | cgoncalves | ralonsoh: also on that patch, isn't the bridge name missing in VIFOpenVSwitchPatchPort? | |
| 11:07:58 | jianghuaw | bauzas, hi. | |
| 11:16:34 | hrw | bauzas: are there plans to update support-matrix.ini cli calls to use openstackclient instead of bunch of clients per service? | |
| 11:20:58 | openstackgerrit | melissaml proposed openstack/nova master: fix link https://review.openstack.org/541675 | |
| 12:04:11 | sean-k-mooney | cgoncalves: pong o/ | |
| 12:04:59 | sean-k-mooney | stephenfin: yes it might make sense to pull together an etherpad. just got ptg approval | |
| 12:07:05 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Move resource provider objects into placement hierarchy https://review.openstack.org/540049 | |
| 12:07:06 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Isolate placement database config https://review.openstack.org/541435 | |
| 12:07:06 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 12:12:23 | cgoncalves | sean-k-mooney: I'd like to check if my understanding from your review of https://review.openstack.org/#/c/533713 is correct. instead of extending VIFBridge and VIFOpenVSwitch you're saying adding a new VIFTap. if that is the case, the should_provide_port would not be needed at all as the TAP device (VIFTap) would be created | |
| 12:13:37 | cgoncalves | sean-k-mooney: request of attachment of the TAP device (or VIFVeth, VIFGre, etc) would be by setting vif.network.bridge, right? | |
| 12:14:23 | sean-k-mooney | cgoncalves: oh hi sorry i have been meaning to get back to that review. am no i have some draft commets that ill publish later but in essence the os-vif vif objects are ment to carry only the infomation reqiured by a vif that is independet of the network backend that vif is uesed with | |
| 12:14:58 | sean-k-mooney | cgoncalves: so instead of putting the should_provide_port in the VIF it should in in the port profile as the port porfiled is backend specific | |
| 12:16:44 | sean-k-mooney | my comments regrading VIFTap vs VIFBridge and VIFOpenVSwitch is in regrades to what if anything the tap is connected to | |
| 12:17:32 | sean-k-mooney | VIFOpenVSwitch means it should be direcly attached to ovs VIFBridge means its attached to a linux bridge and VIFTap means its not attached to any bridge | |
| 12:19:09 | cgoncalves | sean-k-mooney: hmm what if a tap attached to an ovs/lb is required? | |
| 12:19:09 | sean-k-mooney | cgoncalves: i just published the comments i had pending but not sure if i finished them but does that make sense? | |
| 12:19:51 | cgoncalves | sean-k-mooney: actually for the use case I have at hands a veth would make more sense | |
| 12:19:54 | cgoncalves | sean-k-mooney: thanks! | |
| 12:19:54 | sean-k-mooney | cgoncalves: well it can only be attached to one or the other at any one time | |
| 12:20:22 | sean-k-mooney | cgoncalves: what is the usecase? | |
| 12:20:43 | cgoncalves | sean-k-mooney: one cannot attach a tap to an ovs and then the app connects to the tap device?? | |
| 12:21:15 | sean-k-mooney | cgoncalves: you should be able to do that | |
| 12:21:51 | sean-k-mooney | when you say application are you talking about a application on the host or a vm | |
| 12:22:02 | ameeda | bauzas: can you please give this review https://review.openstack.org/#/c/528385/ +2w | |
| 12:22:15 | cgoncalves | sean-k-mooney: application on the host | |
| 12:22:35 | sean-k-mooney | cgoncalves: in that case you want to use an ovs internal port. | |
| 12:22:45 | cgoncalves | sean-k-mooney: the use case is the octavia health manager that listens for heart beats sent from service vms connected to a neutron network | |
| 12:23:10 | cgoncalves | sean-k-mooney: correct, hence the should_provide_port in VIFOpenVSwitch that would create such ovs internal port | |