Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-04
13:35:57 alex_xu sfinucan: done
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.

Earlier   Later