| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-10 | |||
| 08:46:05 | shilpasd | Hi, thanks for review for DB patch for ignore root_gb | |
| 08:46:18 | shilpasd | brinzhang_: thanks for review for DB patch for ignore root_gb | |
| 08:46:33 | shilpasd | regarding comment related to release note, IMO since its code level changes, we shouldn't have | |
| 08:47:01 | brinzhang_ | shipasd: Yeah, I am ok. | |
| 08:47:27 | shilpasd | brinzhang_: thanks | |
| 08:48:05 | brinzhang_ | shilpasd: np :) | |
| 08:50:03 | brinzhang_ | alex_xu: I am reviewing this bug https://bugs.launchpad.net/nova/+bug/1663456, I think Vishakha Agarwal fix is available, can you restore https://review.opendev.org/#/c/580271/ | |
| 08:50:03 | openstack | Launchpad bug 1663456 in OpenStack Compute (nova) "Field 'updated_at' always 'None' when show aggregate" [Low,Confirmed] | |
| 08:51:12 | brinzhang_ | alex_xu: it's abandoned by matt because of the merge conflict, I will resolve the merge conflict, and let the bug continue | |
| 09:51:07 | gibi | dansmith: thanks for starting the discussion on the conflicting ovo usage. I appreciate your effort. I was alway too lazy to start up such a discussion. I will comment your patches soon | |
| 10:03:44 | ralonsoh | gibi, sorry, I updated the commit message at the same you +1 the patch https://review.opendev.org/#/c/701797/ | |
| 11:28:44 | gibi | ralonsoh: no worries | |
| 11:28:50 | gibi | ralonsoh: thanks for fixing the gatae | |
| 11:28:52 | gibi | gate | |
| 11:41:59 | openstackgerrit | Luyao Zhong proposed openstack/nova-specs master: support live migration with virtual persistent memory https://review.opendev.org/695863 | |
| 12:04:12 | brinzhang | gibi: sean-k-mooney: could you please review these specs? https://review.opendev.org/#/c/699669/ and https://review.opendev.org/#/c/682302/ | |
| 12:05:00 | brinzhang | gibi, sean-k-moonkey: thanks~ | |
| 12:16:01 | sean-k-mooney | efried: do you know if sundar has been testing his cyborg patches on centos 7 still. i have tried 3 different way to get python 3.6 running properly on centos and they all end up failing to stack with python errors so im swaping to ubunut just want to check if you know if he has tested ubuntu 18.04 | |
| 12:19:23 | sean-k-mooney | i assume the tempest job proably used ubunut so it should work but just said i would ask | |
| 12:25:51 | gibi | brinzhang: added to my review queue | |
| 12:26:21 | brinzhang | gibi: thanks :) | |
| 12:31:31 | gibi | dansmith, efried: I commented both ovo improvement patch. I totally +2 on the EphemeralObject one, and I'm OK with the default_fn too but I don't see where I will use that in Nova | |
| 12:33:10 | brinzhang | gibi: Today I was reviewed this bug https://bugs.launchpad.net/nova/+bug/1663456,and reviewed it's fixed patch, I think it's available, and it was abandoned by matt, could you please restore this patch? | |
| 12:33:10 | openstack | Launchpad bug 1663456 in OpenStack Compute (nova) "Field 'updated_at' always 'None' when show aggregate" [Low,Confirmed] - Assigned to Brin Zhang (zhangbailin) | |
| 12:33:58 | brinzhang | gibi: I will resolve that merge conflict, and continue work for it. | |
| 12:47:49 | gibi | brinzhang: restored the review https://review.opendev.org/#/c/580271/ | |
| 12:48:52 | lyarwood | did someone track down a change in devstack-gate that's causing n-net to be dropped from stable/queens cells-v1 runs? | |
| 13:01:23 | frickler | lyarwood: that should be fixed by https://review.opendev.org/701404 | |
| 13:01:38 | frickler | oh, n-net | |
| 13:02:09 | frickler | that isn't fixed afaict, need to do something similar to the above probably if that's really still needed | |
| 13:02:17 | frickler | the fix was for n-cauth | |
| 13:02:39 | lyarwood | yeah I think I'm confusing it with thast | |
| 13:03:31 | lyarwood | https://a2c2b9c0506b0b396571-e07636147bed59ede28bbdb888fbf884.ssl.cf1.rackcdn.com/700359/1/gate/nova-cells-v1/11412d4/logs/local.conf.txt.gz - n-net is missing from local.conf here on the nova-cells-v1 jobs that results in n-cpu trying to use neutron even when it isn't deployed. Trying to work out why now as this wasn't the case on the 23rd. | |
| 13:04:04 | frickler | lyarwood: this patch dropped it https://review.opendev.org/#/c/700217/ | |
| 13:04:35 | frickler | so it's all mriedem's fault ;) | |
| 13:05:13 | lyarwood | \o/ | |
| 13:05:19 | lyarwood | I'll add it back in for queens now | |
| 13:05:25 | lyarwood | thanks :) | |
| 13:06:23 | sean-k-mooney | lyarwood: queens is em now right | |
| 13:06:46 | sean-k-mooney | we will eventually drop it and the cells v1 job im assuming but i guess not for a while | |
| 13:07:19 | lyarwood | sean-k-mooney: yup, it was passing prior to this change and as it's just infra I'll fix it | |
| 13:08:12 | sean-k-mooney | ya im just not sure how many people are still running cellsv1 and queens | |
| 13:08:48 | sean-k-mooney | im sure there is some unfortunete that is but if it was an invovled fix rather then just enableing nova networks again i would question the merit more | |
| 13:09:16 | lyarwood | yup indeed | |
| 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 | alex_xu: We didn't really come to a firm agreement on the approach for placement-ese vs. flavor-ese with mixed CPUs. | |
| 15:39:35 | efried | dansmith and I have a slight disagreement about the long-term vision. | |
| 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 | 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 | 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 | 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 | And will that work sanely even when hw:numa_nodes is >1? | |
| 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 | |