Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-10
15:09:45 sean-k-mooney i have stacked on ubuntu now but without the nova changes ill restack with that after the meeting im on finishes up
15:10:14 sean-k-mooney Sundar: ok i was getting some trace back although it was runrelated to cyborg
15:10:52 Sundar I understand it is not a first class citizen yet. There are a few wrinkles.
15:10:55 sean-k-mooney i tried installing python3.6 3 different way so maybe one of the first two caussed issue when i installed it from epel
15:11:29 sean-k-mooney Sundar: well centos 7 is not going to be offically supported for ussuri
15:11:48 sean-k-mooney peopel are workign to move devstack to centos 8
15:12:15 sean-k-mooney i used to be able to use py36 on centos fine but it broke for me back in august
15:13:01 Sundar sean-k-mooney: Totally understand. Many Centos packages still assume Python 2, such as yum etc. Had some issues with pip2 etc. My main constraint is, I often work with FPGAs and that stack is validated with Centos 7.6 and old Ubuntu.
15:13:48 Sundar Meanwhile, many 'real world' deployments of the stack are with Centos, so I kinda prioritize that
15:15:03 Sundar sean-k-mooney: "centos 7 is not going to be offically supported for ussuri" -- for devstack? Or more generally?
15:15:24 sean-k-mooney in general
15:15:43 sean-k-mooney https://github.com/openstack/governance/blob/master/reference/runtimes/ussuri.rst
15:17:01 sean-k-mooney Sundar: the RDO comuntiy are moveig to centos 8 at the moment and redhat move our product to rhel 8 for stien
15:17:37 sean-k-mooney the install poject like kolla and osa i belive are swapping in train or ussuri
15:22:01 Sundar We can test with the fake driver and Centos 8. That _should_ work now, but I haven't checked it yet.
15:39:35 efried And will that work sanely even when hw:numa_nodes is >1?
15:39:35 efried So in conclusion: if we say the mixed-CPU blueprint should *only* use placement-ese syntax, is it possible for the virt driver to do a reasonable thing wrt selecting which physical CPUs to pin and which to float; and which guest CPU IDs they should land on?
15:39:35 efried Since we already have the precedent of using placement-ese for PCPUs from stephenfin's work in Train, I can get behind Dan's approach, but will reserve an "I told you so" for when we have to start mixing resources:$RC and hw:* e.g. for numa modeling.
15:39:35 efried But dansmith contends that the placement syntax is simple, strict, and consistent; and we want the main use cases to use *just* that syntax and make reasonable guesses/defaults for the complicated stuff.
15:39:35 efried I don't like the idea of using placement-ese at all, because it's not going to be powerful enough to do everything we need, and if we're going to have to home-grow a syntax anyway, IMO it's less confusing to use that same home-grown syntax consistently vs. mixing syntaxes.
15:39:35 efried dansmith and I have a slight disagreement about the long-term vision.
15:39:35 efried alex_xu: We didn't really come to a firm agreement on the approach for placement-ese vs. flavor-ese with mixed CPUs.
15:56:41 openstackgerrit Mykola Yakovliev proposed openstack/nova master: Fix boot_roles in InstanceSystemMetadata https://review.opendev.org/698040
16:07:09 sean-k-mooney efried: if we want as sane algorting i would propose spread floating cpus round robing aross numa nodes first then make all the rest pinned
16:07:28 sean-k-mooney so for a singel numa vm that will result in all the floating cores first and the pinned cores last
16:08:00 sean-k-mooney for multin numa node guest then per numa node the first x cores will be floating and the rest will be pinned
16:08:22 sean-k-mooney and in any case we will report th pinned vs mixed in the metadta api and or toplogy api
16:08:41 sean-k-mooney efried: alex_xu ^
16:09:01 sean-k-mooney /algorting/algorithim
16:10:11 sean-k-mooney so you would do hw:numa_nodes=2 resouces=PCPU:6,VCPU:2
16:10:34 sean-k-mooney and that would give you a 2 numa node vm with the first core in each numa node floatign and the rest pinned
16:11:58 sean-k-mooney the linux kernel has a preference for using the first core per numa node and socket to handel some housekeeping task hence the resoning behind that approch
16:14:40 sean-k-mooney by the way if we do that or something similar the detail of that should be considered private and subject to change and the tenant should always consume the info form the metadta api
16:15:35 efried yeah, that seems reasonable to me, but I want the spec owners to confirm it's workable for them.
16:18:22 dansmith efried: I don't want to be the sole recipient of the told-you-so
16:18:43 dansmith if I'm the only one that prefers that method, then of course it doesn't make sense to go down a path everyone else doesn't want
16:19:04 efried I think it's just you & me in the cage dansmith.
16:19:06 dansmith it makes me sad, but I'm sad about a lot of things
16:19:40 efried As usual, you're probably right and I'm probably wrong anyway.
16:21:41 dansmith no, I'm sure you're right
16:29:43 openstackgerrit Iury Gregory Melo Ferreira proposed openstack/nova master: Add ironic hypervisor doc https://review.opendev.org/701998
16:51:42 sean-k-mooney well im not a fan of the group sysntax in the flavor or a direct mapping form flavor resource requets to placement query
16:52:00 sean-k-mooney so i do like the hw:* extra spec for that reason
16:52:31 sean-k-mooney but if you just use the unnumbered groups in the flavor and hw:* for tweeking then i could buy that
16:52:42 sean-k-mooney i think think there is a midel ground
16:56:13 dansmith efried: https://pastebin.com/zbHra4rr
16:57:09 dansmith service is the outlier there. we break the rules specifically because version should *always* be overridden always
16:57:27 dansmith so I'll have to figure out some way to copiously document why that is the case, if not already
17:12:03 efried dansmith: Am I looking at the result of the test that we talked about yesterday?
17:12:36 efried So after asserting that we should never ever overwrite the table cell, we found an example where we have to overwrite the table cell?
17:12:38 dansmith yeah, just fyi, that's the list of objects that do naughty things
17:13:42 dansmith service version is kinda special in that regard.. we want to overwrite it always and forever, kinda like how updated_at is always set outside of your control
17:14:31 efried yeah, updated_at was the example that came to mind yesterday, but I figured that was handled specially somehow.
17:14:45 dansmith it is handled below the object layer
17:15:10 dansmith since service version is *implemented* at the object layer it can't be done in the db layer
17:15:19 efried makes sense.
17:17:13 dansmith efried: hah, past me was on it: https://github.com/openstack/nova/blob/b0cae0750c3d9f9ebac33ee38cc1762fdd7fc138/nova/objects/service.py#L231-L235
17:17:28 sean-k-mooney why am di not surprised that the numa and pci objects are on that list
17:17:40 dansmith sean-k-mooney: yeah they're *awful* unfortunately
17:17:55 dansmith sean-k-mooney: would really appreciate you reviewing this patch to see if I'm breaking anything by making the changes I'm making
17:17:58 dansmith when I post it that is
17:18:25 sean-k-mooney i was just going to ask which patch but sure add me to it and ill take a look
17:26:33 dansmith efried: Sundar: FYI, since I haven't seen much activity lately: I'm off in the wilderness week after next, completely unreachable most of the time
18:01:35 dansmith sean-k-mooney: hrm
18:02:36 dansmith looks like an os-vif object is leaking into nova's namespace
18:04:25 dansmith not sure how that's happening
18:05:58 dansmith ooh
18:06:23 dansmith I wonder if it's because you have a "Network" object and we do too, and get_nova_objects() is only checking the first in the list
18:09:38 sean-k-mooney maybe
18:10:23 dansmith but the repository is mixing the two, which seems, like bad.. but gawd I don't even want to think about that right now
18:20:33 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Remove VIR_DOMAIN_BLOCK_REBASE_RELATIVE check https://review.opendev.org/702021
18:22:03 sean-k-mooney dansmith: sorry was on a call
18:22:25 sean-k-mooney am can you point me in the right direction and i can try an figure out how this is happenign.
18:23:09 dansmith I was thinking it was something in os-vif but now I don't think it is
18:23:16 dansmith so it'd be something for me to resolve if anything
18:23:28 sean-k-mooney dansmith: we should be construciton the os-vif objects from nova ones but neither should contain the other. and the should in theory be in there own namespace but maybe that is not done correctly
18:24:49 dansmith yeah the namespace stuff was added way late when we were spinning things out
18:24:58 dansmith it's working right now, there's just a wrinkle in this test
18:25:16 dansmith so I will work around that and then revisit the bigger picture, but yeah I think os-vif is doing the right thing now that I look
18:26:18 sean-k-mooney this is where we set the os-vif namespace by the way https://github.com/openstack/os-vif/blob/master/os_vif/objects/base.py#L18
18:26:58 dansmith yep, I dug in
18:29:05 dansmith btw, when are we going to switch the functional tox target to be py37 by default? I hate having to type out functional-py37 each time
18:29:28 sean-k-mooney in nova you mean
18:29:42 sean-k-mooney we could do that now i guess
18:29:43 dansmith yes
18:29:46 sean-k-mooney its after m1
18:30:33 sean-k-mooney dansmith: it looks like its already python3
18:30:54 sean-k-mooney so tox -e functional will use your default system python 3
18:30:57 dansmith is it? why do we have functional-py37 then?
18:31:03 sean-k-mooney that is proably 3.6
18:31:28 sean-k-mooney well functional-py37 will be expressly 3.7 regardless of your system default
18:31:41 dansmith last I checked, which has been a while, functional would use whatever env says "python" resolves to, which is 2.7 for me
18:31:49 sean-k-mooney the fucntioal target is inheriting basepython = python3
18:32:04 dansmith ah okay
18:32:18 dansmith hmm, from 2018
18:32:21 sean-k-mooney os ya it will use whatever python3 point too
18:33:04 sean-k-mooney am no form https://github.com/openstack/nova/commit/14872caae1a51c7015dd7c509d0173df2e943ed4
18:33:32 sean-k-mooney it had python 2.7 explcitly before https://github.com/openstack/nova/commit/14872caae1a51c7015dd7c509d0173df2e943ed4#diff-b91f3d5bd63fcd17221b267e851608e8L69
18:33:50 dansmith oh good good, that explains it
18:34:34 sean-k-mooney i still kind of want to add a "unit" env so we can do the same thing with the unit tests

Earlier   Later