| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-04 | |||
| 13:36:06 | sfinucan | bauzas: :) I have also done that more than once | |
| 13:36:14 | sfinucan | alex_xu, bauzas: Thanks folks :) | |
| 13:38:34 | openstackgerrit | Merged openstack/nova master: Fix 'project-id' 'user-id' as required in server group https://review.openstack.org/480162 | |
| 13:40:16 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-manage: Deprecate '--version' parameters https://review.openstack.org/453808 | |
| 13:40:16 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-manage: Rename 'api_db', 'cellsv2' commands https://review.openstack.org/453809 | |
| 13:44:56 | openstackgerrit | Alex Xu proposed openstack/nova master: placement: ensure MISC_SHARES_VIA_AGGREGATE trait created in the test https://review.openstack.org/480198 | |
| 13:45:44 | alex_xu | bauzas: sfinucan ^ still can see the 'MISC_SHARES_VIA_AGGREGATE' not found in the functional tests. I can't find the root cause, that patch is a choice which fallback to ensure the trait created first. | |
| 13:46:45 | bauzas | alex_xu: okay will look | |
| 13:46:59 | bauzas | alex_xu: I'm confused, we already have this trait ? | |
| 13:47:26 | alex_xu | bauzas: yea, it is in the os-traits lib, and it should be synced into the placement db | |
| 13:47:47 | bauzas | alex_xu: but computes wouldn't provide this trait now, right? | |
| 13:48:11 | sfinucan | alex_xu: This is the thing causing all the functional test failures, right? | |
| 13:48:12 | bauzas | I agree with that trait being in the *api* db given we now sync | |
| 13:48:33 | bauzas | but I don't remember when we merged to see computes pushing this trait | |
| 13:48:53 | bauzas | that said, I was (and I'm a bit still) out of my keyboard during last weeks | |
| 13:49:06 | alex_xu | sfinucan: yea, 29 hits http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22%2Fusr%2Flocal%2Fbin%2Fdevstack-version:%20line%203:%20unexpected%20EOF%20while%20looking%20for%20matching%20%60''%5C%22%20AND%20tags:%5C%22console%5C%22&from=7d | |
| 13:49:24 | alex_xu | bauzas: the compute didn't push this trait | |
| 13:49:51 | alex_xu | bauzas: https://review.openstack.org/#/c/480198/1/nova/tests/functional/api/openstack/placement/fixtures.py@285 | |
| 13:50:06 | alex_xu | the fixture set that trait on the RP | |
| 13:50:51 | bauzas | alex_xu: sec | |
| 13:50:53 | alex_xu | bauzas: introduced by https://review.openstack.org/475448 | |
| 13:52:09 | bauzas | wait, I'm confused | |
| 13:52:22 | bauzas | what we provide as a functional test doesn't mean that Nova uses that | |
| 13:52:57 | jangutter | sean-k-mooney: acknowledged. Support should land at a similar time as Open vSwitch 2.8 stabilizes. | |
| 13:53:08 | bauzas | alex_xu: just to be clear, there are 2 things here | |
| 13:53:15 | bauzas | alex_xu: #1 is the list of traits | |
| 13:53:23 | bauzas | that's synced by os-traits, agreed | |
| 13:53:26 | bauzas | but | |
| 13:53:30 | bauzas | there is a #2 point | |
| 13:53:45 | bauzas | alex_xu: the traits mapping with ResourceProviders | |
| 13:54:01 | bauzas | alex_xu: and that, I don't think we merged it, correct? | |
| 13:54:25 | bauzas | ie. the fact that RP <uuid1> is mapped with trait <uuid2> | |
| 13:55:02 | sean-k-mooney | jangutter: will the netronome solution work without modification to ovs. my understnading was that ye did not support the TC flower protocol | |
| 13:55:08 | alex_xu | bauzas: for testing the shared resource provider, jay's patch fake a mapping https://review.openstack.org/#/c/475448/24/nova/tests/functional/api/openstack/placement/fixtures.py@283 | |
| 13:55:33 | bauzas | alex_xu: sure, but that's just for the functional test, right?N | |
| 13:55:42 | alex_xu | bauzas: yea, just for functional test | |
| 13:55:58 | bauzas | tbc, just for a *fixture*, even not a test | |
| 13:56:07 | bauzas | meaning that we don't even assert something | |
| 13:56:30 | jangutter | sean-k-mooney: I believe TC-Flower support has just been submitted upstream. | |
| 13:56:59 | alex_xu | bauzas: emm... didn't get what means 'assert something' | |
| 13:57:16 | sean-k-mooney | jangutter: for the netronome smart driver in the kernel? | |
| 13:58:17 | jangutter | sean-k-mooney: correct, so if you use openvswitch.ko, kernel 4.13 and Open vSwitch 2.8, the card should just work... | |
| 13:58:42 | bauzas | alex_xu: the fact that jay pushed some fixture that is not exactly be in Nova | |
| 13:58:49 | bauzas | it's confusing | |
| 13:59:04 | bauzas | because for the moment, we don't really use that in our codetree | |
| 13:59:24 | sean-k-mooney | jangutter: ok then if we want to supprot that config in pike we need to merge the updates to os vif before the non client libariries frezze which is jul 17-21 | |
| 13:59:59 | alex_xu | bauzas: yea, but I think the 'MISC_SHARES_VIA_AGGREGATE' is something used by operator | |
| 14:00:06 | jangutter | sean-k-mooney: our PCI layout is a bit different from mellanox, and the sysfs interface isn't standardized, so that's why I'm trying to make sure we cooperate nicely. | |
| 14:00:38 | alex_xu | bauzas: do you mean 'MISC_SHARES_VIA_AGGREGATE' is not used in the our codetree? | |
| 14:00:43 | bauzas | alex_xu: even wit that, it's unclear | |
| 14:00:47 | bauzas | alex_xu: yeah | |
| 14:01:10 | sean-k-mooney | jangutter: yes from what i can tell this will be different for intel also be we wont have the required code in the kernel/ovs etc in time for pike. | |
| 14:01:11 | bauzas | alex_xu: Jay wrote some nice TDD, but it's not something we support it yet, right? | |
| 14:01:40 | bauzas | oh wait, I think about another point | |
| 14:02:02 | bauzas | if that's in os-traits and os-traits is synced, why should we need to create a new trait ? | |
| 14:02:17 | bauzas | the fixture probably forgets to sync the library, that's it | |
| 14:02:28 | jangutter | sean-k-mooney: I should have clarity very soon about what we regard as stable. There's been some heated discussion on what the correct way is to resolve the VF's to the reprs. | |
| 14:02:28 | alex_xu | bauzas: yes, we needn't create a new trait | |
| 14:02:45 | sean-k-mooney | jangutter: i had execpect to need to extend this in alter this in queens to supprot our nics. | |
| 14:03:23 | alex_xu | bauzas: but there is something strange in the gate http://logs.openstack.org/69/474869/5/check/gate-nova-tox-functional-ubuntu-xenial/308184e/testr_results.html.gz | |
| 14:03:37 | bauzas | alex_xu: so, 3.0.1 provides the trait https://github.com/openstack/os-traits/blob/0.3.1/os_traits/misc/__init__.py | |
| 14:03:39 | jangutter | sean-k-mooney: yep, it's always been in the back of my mind. I had thought of a support service that would persist VF settings across reboots. | |
| 14:04:09 | bauzas | and nova uses it https://github.com/openstack/nova/blob/master/requirements.txt#L56 | |
| 14:04:09 | alex_xu | bauzas: edleafe have a fix https://review.openstack.org/478564, but looks like still have problem in the gate | |
| 14:04:11 | jangutter | sean-k-mooney: maybe NetworkManager is the correct way to do it :-p | |
| 14:04:36 | sean-k-mooney | jangutter: except redhat dont use it... | |
| 14:05:09 | jangutter | sean-k-mooney: wha? RH wrote it! | |
| 14:05:53 | sean-k-mooney | jangutter: when you said networkmanager you were refering to /etc/network/interfeces and /etc/network/interfeces.d | |
| 14:06:10 | sean-k-mooney | jangutter: and the deamon that reads those files? | |
| 14:06:21 | bauzas | alex_xu: I can try to debut | |
| 14:06:23 | bauzas | debug | |
| 14:06:41 | bauzas | alex_xu: that's a transient bug, right? | |
| 14:07:15 | bauzas | ie. the gate is not blocked every time, but just having hits ? | |
| 14:07:29 | jangutter | sean-k-mooney: Yeah, the sysv initscripts and the thing that spawned from systemd. The problem with keeping state is proliferating yet another thing with another interface. | |
| 14:08:04 | sean-k-mooney | jangutter: but in either case no i think the configuration should be handled by os vif. eventurly this will get ported to the ovs windows datapath too so i would like to minimis external dependecies on linus | |
| 14:08:08 | sean-k-mooney | *linux | |
| 14:09:26 | alex_xu | bauzas: yes, looks like not very time | |
| 14:09:33 | jangutter | sean-k-mooney: aaah, yep. That's a very valid point. But my fever dream is that linux_net would call to nmcli or something if it exists, and that would persist VF settings, meaning that everything could come up asynchronously. | |
| 14:09:51 | sean-k-mooney | jangutter: for the intel intersect im actullly hoping to extend ovs to advertises the representor mapping in a table in the ovsdb that would be populated when you add the pf to the bridge | |
| 14:10:16 | jangutter | sean-k-mooney: yeah, that would be very useful. | |
| 14:10:19 | bauzas | alex_xu: I'm trying to reproduce the bug locally | |
| 14:10:37 | alex_xu | bauzas: if you lucky, you can see that locally :) | |
| 14:10:47 | bauzas | my guts is that this fixture doesn't correctly sync the lib | |
| 14:10:55 | sean-k-mooney | jangutter: i then want to have neutron read that table and populate a resouce provider for that in the placement api and have nova assign one of the representors as part of vm placement | |
| 14:10:55 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Correct the description of 'disable-log-reason' api-ref https://review.openstack.org/480209 | |
| 14:11:13 | bauzas | and that, if you run other test before that functional test, you could be lucky because then you have that lib sync'd | |
| 14:11:33 | jangutter | sean-k-mooney: yep, that makes sense. Then ovs persists the VF settings. | |
| 14:11:35 | bauzas | alex_xu: so, that's probably just us being explicit in the fixture to load the lib | |
| 14:12:34 | jangutter | sean-k-mooney: on a completely tangential topic, is this the place to ask some really, really newbie questions regarding third-party os-vif plugins? | |
| 14:13:13 | sean-k-mooney | jangutter: sure as long as we are not boaring the rest of the nova guys too much | |
| 14:14:03 | sean-k-mooney | jangutter: what did you want to ask? | |
| 14:14:59 | jangutter | sean-k-mooney: so our legacy solution (non TC) will need a third-party OS-VIF and neutron plugin. Are there any docs to follow for publication and submission? | |
| 14:16:48 | sean-k-mooney | jangutter: well the simplest way to get started is ask infra to create a new repo, then clone clone the ovs plugin subtree and use that as the base for your plugin | |
| 14:17:44 | stephenfin | and it has. Wonderful. | |
| 14:18:13 | sean-k-mooney | stephenfin: is if permenet or a backup nick? | |
| 14:18:33 | stephenfin | sean-k-mooney: Probably permanent. I've been meaning to do it for ages | |
| 14:18:36 | jangutter | sean-k-mooney: so I've built some stuff in devstack using a local repo, that wouldn't impede our publishing? | |
| 14:19:02 | stephenfin | sean-k-mooney: Got an RedHat email alias set up, so I can move things to stephenfin@redhat.com too | |
| 14:19:49 | sean-k-mooney | jangutter: no it should not when you ask infra to create the repo you can use what you already have as a seed for the repo. alternitivly you just need to host is somewhare publicly yourself. | |
| 14:20:36 | sean-k-mooney | jangutter: the process to add a plugin is simply pip install it | |