| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-10 | |||
| 13:12:45 | lyarwood | frickler: FYI https://review.opendev.org/701957 | |
| 13:15:18 | frickler | lyarwood: thx, added to my list, will review once the test results are in | |
| 13:17:25 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: DNM Test devstack-gate n-net fix https://review.opendev.org/701958 | |
| 14:03:20 | aarents | Hi, kashyap: lyarwood I need your feedback from that: https://review.opendev.org/#/c/696084/ if you may have a look | |
| 14:03:30 | kashyap | aarents: Hi | |
| 14:05:01 | kashyap | aarents: Have queued it; once I flush my curent cache, will look. | |
| 14:05:51 | lyarwood | aarents: ack also looking | |
| 14:06:11 | lyarwood | hmm is gerrit dead for anyone else? | |
| 14:06:23 | lyarwood | nvm it's back | |
| 14:06:43 | aarents | kashyap: lyarwood great, thks | |
| 14:55:01 | efried | alex_xu: gimme a second and I'll try to summarize the discussion... | |
| 14:55:11 | efried | sean-k-mooney: I don't know where/how Sundar has been testing, let me ask him. | |
| 14:59:45 | efried | Sundar: sean-k-mooney was asking what OS you're using to test cyborg stuff... | |
| 15:00:10 | efried | Sundar: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-01-10.log.html#t2020-01-10T12:16:01 | |
| 15:00:46 | Sundar | efried: sean-k-mooney: It is mostly Centos 7.6. | |
| 15:08:36 | sean-k-mooney | Sundar: so the issue i have with centos 7.6 was gettign a working version of python 3.6 | |
| 15:09:04 | sean-k-mooney | you cant deploy nova under python 2 anymore and i was getting issue with python 3.6 from eple | |
| 15:09:44 | Sundar | sean-k-mooney: I have installed Python 3.6 with Centos 7.6, and I am testing exclusively with Py3. | |
| 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 | |