| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-19 | |||
| 09:31:56 | bauzas | but yeah, mypy is like a cold sea, you just step into it by the toe first | |
| 09:32:15 | bauzas | or you'll get cold | |
| 09:35:31 | bauzas | but at least I can reproduce it locally \o/ | |
| 09:41:18 | swp20 | stephenfin: morning | |
| 09:42:30 | swp20 | for the noVNC patch, can we add TLS in the follow change? as the bp's goal is add the password to get vnc url. | |
| 09:51:48 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Add net & utils methods for routed nets & segments https://review.opendev.org/c/openstack/nova/+/773976 | |
| 09:51:49 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Add a routed networks scheduler pre-filter https://review.opendev.org/c/openstack/nova/+/749068 | |
| 09:52:04 | bauzas | stephenfin: gibi: eventually gave up on fixing neutron issues | |
| 09:52:07 | bauzas | (for mypy) | |
| 09:56:46 | openstackgerrit | Wenping Song proposed openstack/nova master: Nova supports password encrypted VNC https://review.opendev.org/c/openstack/nova/+/622336 | |
| 10:00:17 | openstackgerrit | Lucian Petrut proposed openstack/nova master: hyper-v rbd volume support https://review.opendev.org/c/openstack/nova/+/763550 | |
| 10:06:02 | brinzhang | stephenfin, swp20: yes, this spec we just want to add the vnc authenticate | |
| 10:06:02 | brinzhang | by password, if we want to add the x509vnc support, we can do that later, rather than in this spec | |
| 10:08:00 | brinzhang | stephenfin, swp20: as your point in https://review.opendev.org/c/openstack/nova/+/622336/30/nova/console/rfb/auths.py#30 | |
| 10:14:51 | stephenfin | brinzhang: swp20: I need to think about it more and read melwitt's replies. I don't understand why someone would opt for basic VNC auth when X509+VNC is an option. Using just basic VNC auth makes this feature effectively useless for deployments with encryption, which is virtually all TripleO deployments at least | |
| 10:15:16 | stephenfin | brinzhang: Surely you folks aren't going to recommend people use VNC and drop encryption? | |
| 10:22:51 | lyarwood | stephenfin / gibi ; https://review.opendev.org/c/openstack/nova/+/774897/ - Would you mind looking at this again today and highlighting which approach you think I should take here (o.vo vs sqla)? I'm not sure how I can test this on an actual env at scale before we merge tbh. | |
| 10:28:01 | lyarwood | urgh lc-- pip-- how does it pass locally and then fail in the gate | |
| 10:29:05 | stephenfin | sure | |
| 10:32:51 | brinzhang | stephenfin: I know you want to encrypt identities and files, but this is not my original intention of designing this feature. For the users I have seen, vnc password authentication is sufficient. | |
| 10:33:25 | brinzhang | stephenfin: but as you said, using x509+vnc is an optional, we can try | |
| 10:37:05 | brinzhang | s/optional/option/ | |
| 11:01:14 | gibi | bauzas: have you tried the routed net patches in a devstack? I think it is cannot be activated as the extension name is wrong in the code https://review.opendev.org/c/openstack/nova/+/773976/9/nova/network/constants.py#32 | |
| 11:02:01 | gibi | bauzas: I can give a try to adding mypy needs to neutron.py | |
| 11:59:01 | openstackgerrit | Merged openstack/nova stable/train: tools: Allow check-cherry-picks.sh to be disabled by an env var https://review.opendev.org/c/openstack/nova/+/766025 | |
| 12:39:47 | openstackgerrit | Lee Yarwood proposed openstack/nova master: block_device: Use initialize APIs to refresh when reported as idempotent https://review.opendev.org/c/openstack/nova/+/720769 | |
| 13:14:30 | bauzas | gibi: unfortunately no, I don't have an env with multiple nodes at hand | |
| 13:14:33 | bauzas | ... | |
| 13:42:03 | openstackgerrit | Lucian Petrut proposed openstack/nova master: hyper-v rbd volume support https://review.opendev.org/c/openstack/nova/+/763550 | |
| 13:57:00 | lyarwood | dansmith / gmann / gibi ; https://review.opendev.org/c/openstack/tempest/+/771499 - This came up during the meeting yesterday, IMHO we should go ahead with this now if multinode provides the same coverage | |
| 14:09:36 | stephenfin | bauzas: It should be pretty easy to set one up with DevStack and VMs, if you have something with 32 GB of RAM | |
| 14:10:39 | stephenfin | If not, sean-k-mooney might be able to lend you a hand? | |
| 14:16:20 | gibi | bauzas: ack, I will try to validate as much of the assumption the functional test cases makes as possible in a devstack | |
| 14:16:30 | gibi | right now I saw the problem with the extension name | |
| 14:17:05 | gibi | and strugling with neutron to produce the assumed placement config (PRs, inventories, aggregates) and nova config (aggregates) for the networks | |
| 14:19:03 | gibi | lyarwood: I'm OK to drop the base grenade | |
| 14:20:44 | sean-k-mooney | i see my name | |
| 14:20:46 | sean-k-mooney | reading | |
| 14:21:34 | sean-k-mooney | bauzas: i have got 3-4 nodes on my p50 laptop before but if you need nodes i think i still have space on my home cloud | |
| 14:21:47 | sean-k-mooney | bauzas: i can give you a log in and you can install away | |
| 14:22:10 | bauzas | stephenfin: gibi: sean-k-mooney: my laptop (a t470s) only has 16GB of RAM | |
| 14:22:17 | dansmith | lyarwood: cool with me! | |
| 14:22:22 | sean-k-mooney | bauzas: i have found the min ram size for contolers is about 6G and comptue is about 2-4 | |
| 14:22:30 | bauzas | I also have two mini optiplexs but they also have 16GB | |
| 14:23:03 | bauzas | and I'm waiting for my new laptop since beginning of december, but the provider is running out of stock till' March :) | |
| 14:23:15 | bauzas | things are going crazy those days with CPUs and GPUs | |
| 14:23:25 | bauzas | same with bikes fwiw | |
| 14:24:34 | gibi__ | hm, my raspberry hosting my irc client just died | |
| 14:25:29 | sean-k-mooney | bauzas: looking at my cloud i currently have about 35GB free if you need to spin up a couple of 8G vms | |
| 14:26:07 | bauzas | sean-k-mooney: well, spinning up a devstack env with multiple nodes would take me a couple of days | |
| 14:26:26 | bauzas | if someone can verify the segments extension for me, this should be enough IMHO | |
| 14:26:44 | gibi__ | bauzas: I'm on that | |
| 14:26:51 | bauzas | gibi__: <3 | |
| 14:27:18 | bauzas | I'm enough confident in my functional testing | |
| 14:27:48 | bauzas | but yeah, this (the segments extension name) wasn't verified | |
| 14:27:56 | gibi__ | bauzas: yes, I also think that the funct test are plenty, I just need to verify the assumptions the func test makes about neutron | |
| 14:28:01 | sean-k-mooney | bauzas: ok i can get you a 2 node deployment in my cloud in a hour or so. | |
| 14:28:03 | gibi__ | like the name of the extension | |
| 14:28:21 | sean-k-mooney | bauzas: oh you just want that | |
| 14:28:30 | sean-k-mooney | i cans show you were its defiend | |
| 14:28:55 | sean-k-mooney | https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/segment.py#L32 | |
| 14:29:28 | bauzas | https://docs.openstack.org/neutron/latest/contributor/internals/segments.html | |
| 14:29:37 | bauzas | it says SEGMENT with capitals | |
| 14:30:14 | bauzas | sean-k-mooney: sure, but 'segment' looks to work too https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/segment.py#L29 | |
| 14:30:20 | bauzas | that's what I provided | |
| 14:30:27 | sean-k-mooney | yes segment is the alis | |
| 14:30:32 | sean-k-mooney | just ignore case | |
| 14:30:43 | bauzas | and https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/segment.py#L36 tells me 'segment' too | |
| 14:30:45 | bauzas | gibi__: ^ | |
| 14:31:01 | sean-k-mooney | thats the resouce name | |
| 14:31:09 | sean-k-mooney | for the api endpoint | |
| 14:31:33 | sean-k-mooney | bauzas: the only one im sure its not is all uppercase | |
| 14:31:47 | bauzas | huh | |
| 14:32:32 | sean-k-mooney | http://paste.openstack.org/show/802824/ | |
| 14:32:38 | sean-k-mooney | i dont have the segments extion enabled | |
| 14:32:39 | gibi__ | this is the output of the extension list http://paste.openstack.org/show/802810/ | |
| 14:32:58 | sean-k-mooney | but the Name will be Segment and the alias will be segment | |
| 14:33:00 | gibi__ | the nova code checks the keys in the segments dict | |
| 14:33:05 | sean-k-mooney | the alias are always lowercase | |
| 14:33:10 | gibi__ | so yes, it is Segment what we need | |
| 14:33:11 | sean-k-mooney | oh mybe not | |
| 14:34:26 | bauzas | ... | |
| 14:34:38 | bauzas | we're discussing about keys using CamelCase ? | |
| 14:34:45 | bauzas | co'on Neutron ! | |
| 14:34:55 | sean-k-mooney | bauzas: the name is not used in code | |
| 14:35:06 | bauzas | okay, so 'segment' then ? | |
| 14:35:10 | sean-k-mooney | the alisa is whats used internally | |
| 14:35:21 | bauzas | why is this so complicated to know which extension name to use ? | |
| 14:35:38 | sean-k-mooney | the name is the huma readable name more or less you would use the alis in the config files for example | |
| 14:35:51 | sean-k-mooney | where are you using it | |
| 14:35:56 | bauzas | gibi__: tbh, I copied the semantics from multi_provider_network extension | |
| 14:36:11 | sean-k-mooney | there are two filed you can check for either | |
| 14:36:15 | bauzas | this was a single name and with all non-capitals | |
| 14:36:36 | bauzas | sean-k-mooney: context https://review.opendev.org/c/openstack/nova/+/773976/9/nova/network/constants.py#32 | |
| 14:36:45 | sean-k-mooney | thanks jsut went lookign for that | |
| 14:37:13 | sean-k-mooney | bauzas: stephenfin has a patch to normallyise you use of names to the alias | |
| 14:37:57 | gibi__ | I've tried, in devstack. I enabled the segment service_plugin in neutron and the pre-filter did not triggered as it looked for the name 'segments' but the extensions dict in nova contains 'Segments' | |
| 14:38:04 | gibi__ | bah | |
| 14:38:07 | gibi__ | segment and Segment | |
| 14:38:08 | gibi__ | singular | |