| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-03 | |||
| 08:57:42 | openstackgerrit | Matthew Thode proposed openstack/nova stable/rocky: Don't use '_TransactionContextManager._async' https://review.openstack.org/597421 | |
| 09:11:58 | openstackgerrit | Chen proposed openstack/nova master: Fix SOFT_DELETE vm_state string https://review.openstack.org/598482 | |
| 09:23:57 | prometheanfire | this isn't helping, for some reason re-running the service isn't using the file I just changed, wtf | |
| 09:24:36 | prometheanfire | https://gist.githubusercontent.com/prometheanfire/76b31b592b1780a72b32c289ab1bfb06/raw/b58c80c3d22860397781c53915d7350d6dbe0bab/gistfile1.txt | |
| 09:25:00 | prometheanfire | but async_ isn't defined at all on that line anymore, I editited it to be async | |
| 09:25:17 | prometheanfire | anyone have any idea where that's cached? | |
| 09:28:01 | prometheanfire | I've removed any pycache files I could find | |
| 09:30:38 | openstackgerrit | Merged openstack/nova master: libvirt: guest: introduce blockStats instead of domain.blockStats https://review.openstack.org/526833 | |
| 09:55:11 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Making instance listing skipping down cells configurable https://review.openstack.org/592428 | |
| 10:00:15 | openstackgerrit | Sujeet Banerjee proposed openstack/nova master: WIP: Added a periodic task for network management. https://review.openstack.org/599338 | |
| 10:15:14 | prometheanfire | well, it looks like https://review.openstack.org/597421 may not be the right fix | |
| 11:23:28 | gibi | o/ | |
| 11:27:09 | sean-k-mooney | gibi: o/ | |
| 11:30:10 | openstackgerrit | Merged openstack/nova master: hardware: fix memory check usage for small/large pages https://review.openstack.org/532168 | |
| 12:20:40 | amarao | How to access object attributes in policy json? I'd like to forbid some operations based on flavor. Is someone tried that before? | |
| 12:26:29 | sean-k-mooney | amarao: as in based on the flavor of an instance you want to change what api actions are allowable and or by whom? | |
| 12:27:07 | sean-k-mooney | amarao: that sound like a nightmare from an interoperablity stand point so i doubt that has been tried/tested before | |
| 12:30:13 | amarao | Yep, I want to use flavor of the instance (or another instance attribute). | |
| 12:30:42 | amarao | Basically, I want to lock instance. I can use nova lock for this, but user still have access to console, and I want to remove it. | |
| 12:34:57 | moshele | sean-k-mooney: hi | |
| 12:35:47 | moshele | sean-k-mooney: in intel driver if spoofchk is enabled does it allow to set the mac address of the vf to 00:00:00:00:00:00 | |
| 12:58:51 | sean-k-mooney | moshele: i am not sure. if it did i would expect that to mean if the dest/source mac is not 00:00:00:00:00:00 specically drop the packet e.g. only broadcast traffic would be allowed | |
| 13:02:03 | sean-k-mooney | moshele: also at least in niantic (x520/x510) cards i know the mac filter is before the vlan filter so if you had 2 vf with that adress that would cause issues | |
| 13:03:27 | sean-k-mooney | amarao: locking in nova is intended to prevent api acess to an instance not to prevent users form using it | |
| 13:04:27 | sean-k-mooney | amarao: so a user can still poweroff a locked instance by sshing in and executing power off if they choose too. | |
| 13:05:23 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Making instance/migration listing skipping down cells configurable https://review.openstack.org/592428 | |
| 13:05:41 | sean-k-mooney | amarao: is there a partical usecase you have in mind. perhaps a dedicated feature would be better then a flavor hack. | |
| 13:06:04 | amarao | sean-k-mooney, in our scenario we want to run it with our own key (user have no private key from it). 'Hidden' key plus 'lock' almost lock instance from user. What is left is console: Ctrl-Alt-Del, Sysrq-b, and (most importantly) grub access at boot time. | |
| 13:06:18 | amarao | I'd like to take away console from user as well (for specific instances only). | |
| 13:10:26 | moshele | sean-k-mooney: the reason I am asking is that mellanox driver block this and it can cause issues. So the mac address 00:00:00:00:00:00 is just to allow libvirt to clean vf when the VM with VF is deleted see https://www.redhat.com/archives/libvir-list/2017-March/msg00455.html | |
| 13:11:24 | moshele | sean-k-mooney: but now if spoofchk enabled first nova(libvirt delete the vm) restoring the mac to 00:00:00:00:00:00 and then the sriov agent will disable the spofchk | |
| 13:12:01 | moshele | sean-k-mooney: so the vf mac will not set to 00:00:00:00:00:00 and we can't reuse the mac on the same compute | |
| 13:12:44 | moshele | sean-k-mooney: I wonder how intel driver behavior to undestand were to fix it, in the driver or in openstack ... | |
| 13:14:26 | sean-k-mooney | moshele: i really need to get a redhat account at somepoint.. i cant read that linke but anyway. i dont think setting 00:00:00:00:00:00 is a good idea on intel cards either | |
| 13:14:52 | sean-k-mooney | moshele: i belive that the intel driver generates unique macs automaticaly for the pfs | |
| 13:14:57 | sean-k-mooney | * vfs | |
| 13:16:17 | sean-k-mooney | personally the fact that libvirt is seting 00:00:00:00:00:00 on deleteing the vm sound like a libvirt bug to me | |
| 13:16:40 | sean-k-mooney | or a nova bug if we are doing that in the libvirt vir driver | |
| 13:18:30 | moshele | sean-k-mooney: basically it set the restore the previously used mac so if you auto generate it. it will restore the auto generate one. in mellanox case the vf is start with 00:00:00:00:00:00 so we allowed to restore to 00:00:00:00:00:00 | |
| 13:18:37 | sean-k-mooney | amarao: well would a flavor extra-spec for disableing the console on an instace work? | |
| 13:19:53 | amarao | sean-k-mooney are there such property for extra-spec? | |
| 13:19:55 | sean-k-mooney | moshele: right in anycase when the vf is detached from a instance its linkstate should be down so no trafic will travers it so does it matter if spoof checking is disabled | |
| 13:20:37 | sean-k-mooney | amarao: ill check you can chages several aspecs of the vm like this via extra-sepcs and or image metadata. | |
| 13:22:46 | amarao | If I could disable console via flavor specs, it would be cool. | |
| 13:23:03 | sean-k-mooney | amarao: you can change the type of gpu in the guest and ram https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt-image.json#L45-L62 | |
| 13:23:14 | moshele | sean-k-mooney: right, but I think the default links state is auto, (at least for Mellanox) | |
| 13:23:15 | sean-k-mooney | you can also set the serial port count https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt.json#L18-L23 | |
| 13:23:34 | sean-k-mooney | amarao: we could add a display count extra spec | |
| 13:24:04 | sean-k-mooney | amarao: or extend hw_video_model to allow none to signel no display | |
| 13:24:52 | amarao | Nodisplay wouldn't work with many OSes. | |
| 13:25:06 | amarao | But disable_vnc (or disable_access) will be cool. | |
| 13:25:40 | sean-k-mooney | amarao: hum the perhaps we should leave the display and allow disabling of the vnc/spice console that is attached to it instead? | |
| 13:27:11 | sean-k-mooney | amarao: atleast in terms of libvirt/kvm the vnc/spice console is a sperate device form the gpu/display so we could disable it speraate ly or leave it here but limit its acess to local scope so you cannot connect to it via the novnc_proxy | |
| 13:28:05 | amarao | For the best user expirience it's better to return error on get-vnc-console, saying 'VNC console is disabled for this instance'. | |
| 13:28:45 | amarao | ... And admins will love that they still can connect to VNC through local IP on libvirt host. | |
| 13:29:20 | amarao | Should I report wishbug into launchpad? | |
| 13:29:25 | sean-k-mooney | amarao: we could proably do that based on the extraspec via an api check. amarao this would be a good topic for a blueprint care to write one | |
| 13:29:45 | sean-k-mooney | amarao: yes. a bug or sepcless blueprint. | |
| 13:30:19 | amarao | I'll start from a bug. I never created a blueprint, so I'll write down a bug and then will try with blueprint. | |
| 13:31:53 | sean-k-mooney | amarao: ok sound good. feel free to add me to the bug if you like. am will you be attending the PTG next week. if not i can highlight this as an RFE | |
| 13:34:31 | amarao | Should I put it into 'hw' namespace? | |
| 13:35:07 | sean-k-mooney | am you dont have to detail the impmentation in the bug but yes i would think so | |
| 13:35:15 | amarao | I thought about something like 'hw:disable_consoles: vnc,spice,serial' | |
| 13:36:41 | amarao | Oh, it's simpler than I thought. https://blueprints.launchpad.net/nova/+spec/flavor-based-access-to-console | |
| 13:37:45 | sean-k-mooney | amarao: perhapes invert that to hw:consoles=<one of vnc|spice|serial|None> | |
| 13:38:13 | amarao | .. and if this field is absent, everything is permitted. ack. | |
| 13:38:14 | sean-k-mooney | amarao: yes blueprints are baseicelay jsut what is the problem you would like to fix | |
| 13:38:36 | sean-k-mooney | amarao: yep if the field is not there just do waht we do today | |
| 13:39:25 | sean-k-mooney | amarao: i dont think we actully allow more then one console currently hence the one of but that is something we could figure out as we start looking at the implementaion | |
| 13:39:47 | sean-k-mooney | e.g. i dont think you can have an instance with both spice and vnc enabled | |
| 13:41:17 | amarao | ack, updated. | |
| 13:41:29 | amarao | It's more about serial/vnc thing, actually. | |
| 13:42:31 | sean-k-mooney | ya serial likely can be mix with vnc as they attach do different virualised hardware | |
| 13:42:44 | sean-k-mooney | rdp/vnc/spice all share teh virutal gpu | |
| 13:43:39 | amarao | Anyway, we are still on mitaka (sad, but true), so I'll continue to search some kind of dirty hack for that. Thank you for help. | |
| 13:43:46 | sean-k-mooney | the other think about inverting it is we could model what consoles are available on each host as traits in the placement api and use this extraspec if present to land on a host that is able to support that console | |
| 13:44:30 | stephenfin | Afternoon, gibi. Think this is something you'd be happy reviewing? https://review.openstack.org/#/c/595592/ | |
| 13:45:13 | sean-k-mooney | amarao: no worries, you may be able to use policies but that is not a area im familar with unfrotuetly. | |
| 13:46:23 | amarao | ... policy.json is like a path in a swamp. Everyone knew it exist, but rarely someone passes through. :) | |
| 13:49:30 | gibi | stephenfin: sure, looking | |
| 13:58:50 | gibi | stephenfin: https://review.openstack.org/#/c/595592/ looks good overall. I'm wondering how we can tests this other than in the unit test that is in the patch | |
| 13:59:53 | stephenfin | gibi: I'm not sure how we could do it in the gate due to the hardware dependencies. I do have an SR-IOV machine locally that I could validate the fix with, if you'd like | |
| 14:00:40 | stephenfin | gibi: Downstream we will likely look at automating this as part of the whitebox-tempest-plugin Tempest plugin, but how we actually run those tests is still very much in the air | |
| 14:02:52 | bauzas | given we're on a US holiday today, I guess we won't have any scheduler meeting? | |
| 14:02:53 | gibi | stephenfin: if it does not take more than 2 hours of your time to locally test it then could you please run that test? It would give sizeable confidence boost to me towards this patch | |
| 14:03:17 | stephenfin | gibi: No problem, should only take me 20 minutes | |
| 14:03:25 | gibi | bauzas: cdent asked it in openstack-placement where I said it is OK to me to skip | |
| 14:03:33 | bauzas | k | |
| 14:03:33 | gibi | stephenfin: thanks a lot | |
| 14:07:57 | moshele | stephenfin: Mellanox CI was update to test this | |
| 14:16:16 | sean-k-mooney | stephenfin: gibi moshele if you are refering to https://review.openstack.org/#/c/595592/3 i think that is a pretty safe change | |
| 14:18:41 | gibi | sean-k-mooney: yes, we are talking about that. If stephenfin's timeline is correct he will have test results in 5 minutes anyhow :) | |
| 14:20:14 | sean-k-mooney | stephenfin: if not i can prep an sriov env if needed but ill have to do an os reinstall on the node so it will be more like 2-3 hours before ill be able to check this directly. | |
| 14:20:36 | sean-k-mooney | * or rather if you have issues | |
| 14:23:09 | stephenfin | sean-k-mooney: Think I'm all good. Will known in 60 seconds :P | |
| 14:23:46 | sean-k-mooney | stephenfin: i take it you worked out your sriov issues then? | |
| 14:24:32 | stephenfin | gibi: Without the fix http://paste.openstack.org/show/729332/ | |
| 14:24:52 | stephenfin | sean-k-mooney: Sure did. It was a really stupid typo | |
| 14:25:08 | stephenfin | sean-k-mooney: and those warnings didn't seem to affect anything. | |
| 14:25:09 | sean-k-mooney | ha they are always the best typos | |