| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-17 | |||
| 12:52:47 | sean-k-mooney | gibi: im kind of felling like we should do what ever we would do if cinder or neutron went away | |
| 12:53:01 | sean-k-mooney | i would assume we would fail to delete but i confess i have never tried it | |
| 12:53:20 | gibi | I can try that | |
| 12:54:27 | sean-k-mooney | cool you should jsut need to delete the entry in the service in keystone to emulate that right | |
| 12:55:19 | gibi | I'm not sure that a) this is a valid scenarios that cyborg service is removed from the deployment b) if yes then which is more important in general keeping cyborg - nova in sync or allowing to delete an instance during a temporary failure of cyborg | |
| 12:56:15 | sean-k-mooney | gibi: i am leaning towords this si operator error for removing a service before its consumer are removed | |
| 12:56:33 | sean-k-mooney | that said i dont think they should have to do db surgury to remove the instance | |
| 13:01:59 | gibi | sean-k-mooney: without neutron endpoint in keystone the instance delete fails with HTTP 500 | |
| 13:02:02 | gibi | http://paste.openstack.org/show/792326/ | |
| 13:02:18 | sean-k-mooney | ack | |
| 13:02:27 | sean-k-mooney | ya that is baskcially what i expected | |
| 13:02:43 | sean-k-mooney | and i would expect the same for cyborg | |
| 13:02:45 | gibi | so this also points towards that the scenario of removing cyborg is invalid | |
| 13:03:08 | sean-k-mooney | yes i was going to comment with a proceedure to do that in the bug | |
| 13:03:15 | sean-k-mooney | but just removing it i think is invalid | |
| 13:03:20 | sean-k-mooney | *patch | |
| 13:05:07 | openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM - Test stable device rescue tests with BFV instances https://review.opendev.org/710050 | |
| 13:06:17 | sean-k-mooney | gibi: left a comment with my toughts | |
| 13:06:21 | gibi | sean-k-mooney: thanks | |
| 13:38:25 | gibi | sean-k-mooney, dansmith thanks for the reviews on the https://review.opendev.org/#/c/720670 I marked the bug invalid | |
| 13:38:50 | dansmith | cool | |
| 13:48:21 | sean-k-mooney | dansmith: gibi cross cell migrate was complete this cycle right it was not supported in train | |
| 13:48:42 | sean-k-mooney | well cross cell resize. same thing | |
| 13:48:46 | averi | dansmith, sean-k-mooney: sorry for the direct poke, got any pointer on the question above? | |
| 13:49:15 | sean-k-mooney | i did not see the quest can you repeat it. i can check scollback | |
| 13:49:20 | averi | ah sure, sorry | |
| 13:49:26 | averi | <averi> even killing one of the library files results in the binary not to fail like the file was still around | |
| 13:49:26 | averi | <averi> even when spinning up a new image based on the nova-compute one, it doesn't work, code changes are there but they're like ignored all together | |
| 13:49:26 | averi | <averi> hi, anyone has an idea on why code changes are not picked up by nova_compute containers (OSP 13)? | |
| 13:49:51 | averi | I cannot troubleshooting anything as soon as oslo service comes into play | |
| 13:50:35 | sean-k-mooney | how are you modifying the code and restarting thet container | |
| 13:50:40 | sean-k-mooney | are you using docker directly | |
| 13:51:17 | sean-k-mooney | if you exec into the contienr with doeck an modify the code then do a docker restart for the container it will pick up the changes | |
| 13:51:37 | dansmith | sean-k-mooney: I haven't tried it, but yeah it was U not T | |
| 13:51:51 | averi | I spin up a new container based on the upstream image, then exec within it, modify the library (interested in pymysql debugging), then shut down the container and start it again | |
| 13:52:02 | sean-k-mooney | if you are using paunch it pull a clean copy of the image every time you get it to restat the container so your changes will be lost | |
| 13:52:11 | averi | sean-k-mooney, the changes are there in the code, they persist, but they are completely ignored | |
| 13:52:16 | sean-k-mooney | dansmith: ok just traiging a donwstream bug | |
| 13:52:24 | dansmith | averi: this is probably not the best channel for that question | |
| 13:52:59 | averi | dansmith, sorry, a contact internally mentioned this was a possible good channel for that type of question | |
| 13:53:08 | sean-k-mooney | averi: then i would guess its not using the files you are modifying and the kolla or ooo folks would be betere able to help | |
| 13:53:26 | averi | what would be the correct channel? | |
| 13:53:50 | sean-k-mooney | averi: #openstack-kolla or better #openstack-tripleo | |
| 13:53:56 | averi | thanks | |
| 13:54:12 | averi | mm.. 4 folks in #openstack-tripleo | |
| 13:54:28 | dansmith | averi: are you a redhatter? | |
| 13:54:32 | averi | yes | |
| 13:55:07 | sean-k-mooney | maybe that is not there normal channel | |
| 13:55:23 | dansmith | averi: this is the upstream nova channel.. people here don't know anything about OSP :) I'll pm | |
| 13:56:31 | sean-k-mooney | averi: fyi is just #tripleo | |
| 13:56:36 | averi | ack | |
| 14:00:04 | gibi | sean-k-mooney: cross cell resize merged in Ussuri not supported in Train | |
| 14:01:01 | sean-k-mooney | gibi: yep i just have a resize bug specificly in a multi cell enve and i wanted to triple check that cross cell resize is not supported | |
| 14:02:45 | bauzas | gibi: sorry, I was not around since this morning | |
| 14:02:54 | bauzas | gibi: I haven't yet looked at the bugs | |
| 14:03:02 | bauzas | thanks for working on it | |
| 14:03:26 | openstack | Launchpad bug 1841932 in OpenStack Compute (nova) "hide_hypervisor_id extra_specs in nova flavor cannot pass AggregateInstanceExtraSpecsFilter" [Undecided,New] | |
| 14:03:26 | rambo_li | sean-k-mooney: maybe their is an error, for the bug :https://bugs.launchpad.net/nova/+bug/1841932. when we set the metadata "hide_hypervisor_id=true"in aggreate,so we will go to the https://github.com/openstack/nova/blob/46a3bcd80b41e99ec4923c7cf3d0f8dd8505e97c/nova/scheduler/filters/aggregate_instance_extra_specs.py#L69-L71, but this should not break, because the aggregate_val doesn't match the req. | |
| 14:03:27 | gibi | bauzas: no worries there was one potential regression around cyborg but we just ruled it out as unsupported scenario | |
| 14:03:56 | gibi | bauzas: and honestly I did not triaged any bug, I'm just reviewing https://review.opendev.org/#/c/719163 | |
| 14:04:49 | rambo_li | the aggregate_vals is "true" | |
| 14:04:50 | gmann | melwitt: stephenfin can i get your review on this which cover remaining policy of server (not reviewed previously ) - https://review.opendev.org/#/c/720104/ and its scope and defaults change patch. | |
| 14:08:27 | melwitt | gmann: yeah can do. I didn't review it yet because earlier patch in the stack I wanted to wait for johnthetubaguy since he spotted issues before. but you are right, can still look at the others | |
| 14:08:53 | gmann | melwitt: yeah, thanks. | |
| 14:09:17 | bauzas | gibi: ack, will do as well later | |
| 14:09:18 | melwitt | gibi: hi, I have small follow ups here for the host_status:unknown-only policy rule here if you could please look https://review.opendev.org/713295 | |
| 14:09:41 | gibi | melwitt: sure. looking | |
| 14:09:46 | melwitt | thanks | |
| 14:11:02 | openstackgerrit | Andreas Jaeger proposed openstack/nova master: Remove Babel requirement https://review.opendev.org/720725 | |
| 14:23:07 | rambo_li | sean-k-mooney: if we set the metadata "hide_hypervisor_id = true "in aggregate, so the code https://github.com/openstack/nova/blob/master/nova/scheduler/filters/aggregate_instance_extra_specs.py#L62 , the aggregate_vals in code is "true". so last will also return False.so workaround this is to set hw:hide_hypervisor_id replace hide_hypervisor_id in flavor extra_spec and aggregate metadata. | |
| 14:39:13 | gibi | melwitt: +A on the followup | |
| 14:39:23 | melwitt | danke | |
| 14:51:10 | melwitt | gmann, bauzas, gibi, dansmith: does anyone know about babel to help review this? https://review.opendev.org/720725 it seems ok based on the ML post but I don't understand it well enough whether there could be any issue with removing it as a requirement | |
| 14:51:39 | melwitt | stephenfin too | |
| 14:51:52 | bauzas | weirdo | |
| 14:52:10 | gibi | melwitt: I have to pass on that now. I hope somebody else can take it | |
| 14:52:32 | bauzas | we don't use babel for translations | |
| 14:52:33 | melwitt | it's not urgent, just wanted to mention it while people are around | |
| 14:52:38 | bauzas | but I can git blame | |
| 14:53:11 | bauzas | melwitt: wow, this was old | |
| 14:53:32 | bauzas | melwitt: https://review.opendev.org/#/c/3870/ | |
| 14:53:52 | bauzas | but the translation team no longer uses it AFAIK | |
| 14:53:56 | bauzas | (for a while) | |
| 14:54:26 | bauzas | https://docs.openstack.org/i18n/latest/infra.html | |
| 14:54:37 | bauzas | this is now zanata | |
| 14:54:43 | bauzas | so I think we can drop it | |
| 14:54:52 | bauzas | but I leave the decision to other folks :p | |
| 14:55:11 | melwitt | yeah. hm, so maybe we would want to remove all references. ajaeger had said babel is used to build translations so I was not sure what's going on | |
| 14:55:12 | stephenfin | melwitt: That _seems_ correct. You need Babel to run the e.g. 'python setup.py extract_messages' distutils command but I think _that_ would require it already be present, like setuptools | |
| 14:55:16 | bauzas | I'm just afraid of breaking things so close to the HardStringFreeze so I'd defer this to later | |
| 14:55:29 | melwitt | ah, nevermind | |
| 14:55:39 | stephenfin | Also, AJaeger suggested it and he knows these things so I'd trust him on that | |
| 14:55:43 | stephenfin | *on this | |
| 14:56:15 | bauzas | FWIW, that's how translations work atm https://docs.openstack.org/i18n/latest/reviewing-translation-import.html | |
| 14:56:28 | melwitt | I thought it'd be wise to see if anyone in the team understands this before merging it | |
| 14:57:00 | bauzas | melwitt: like I said, I would maybe defer this to post-RC1 | |
| 14:57:13 | melwitt | if literally no one understands it, then fine, but I wanted to check first | |
| 14:58:12 | bauzas | melwitt: we should first look at the translation jobs I think | |
| 14:58:23 | bauzas | or ask someone in their team | |
| 15:00:22 | bauzas | stephenfin: sean-k-mooney: trust me, if I was able to use the existing functional helpers, I'd use them | |