| bauzas | good morning Nova | 08:13 |
|---|---|---|
| bauzas | gibi: I just realized I won't be able to lead our weekly meeting tomorrow and I'll be off until Friday | 08:13 |
| bauzas | mdbooth is visiting me this week for seeing two stages of the Tour de France in the Alps | 08:14 |
| kashyap | Nice | 08:14 |
| bauzas | not in Nice :p | 08:14 |
| kashyap | Heh | 08:15 |
| Uggla | bauzas, o/ | 08:18 |
| bauzas | \o (left-handed) | 08:18 |
| Uggla | bauzas, you are left handed, me too in fact. :) | 08:18 |
| bauzas | you won't never see me raising the right hand | 08:19 |
| gibi | bauzas: this tuesday I have to log off around ~18:30 CEST so I can start but I need somebody else also on the hook if we run longer than 30 mins | 08:20 |
| bauzas | gibi: we'll see if sean-k-mooney can do it or we'll punt | 08:21 |
| gibi | Uggla: would you like to try to run a nvoa meeting? I can help in the first 30 mins :) | 08:21 |
| gibi | bauzas: yeah, or sean-k-mooney | 08:21 |
| bauzas | heh, that's a good experience indeed | 08:21 |
| bauzas | I can prepare the agenda, I'll be working tomorrow | 08:22 |
| gibi | OK | 08:22 |
| bauzas | this is just, I have to leave early for arriving to the Lautaret pass not that late | 08:22 |
| gibi | bauzas: btw, I left +2 on the first patch of unshelve to host, and I have only minor nits in the func test in the second patch, so we could land that feature this week | 08:23 |
| bauzas | gibi: that's cool, I was about to do it | 08:23 |
| bauzas | but I'll need to be schizophrenic :p | 08:23 |
| bauzas | I just uploaded my own version of 2.91 :) | 08:23 |
| bauzas | so either I shoot myself in the foot when reviewing Uggla's patch or I leave him angry :D | 08:24 |
| gibi | nah, you 2.91 is still WIP, I vote for Uggla's 2.91 :) | 08:25 |
| bauzas | yeah I know | 08:25 |
| bauzas | today it should no longer be WIP but Uggla has the precedence :) | 08:25 |
| bauzas | this is just, touching the UTs and functtests of keypairs is really... fuky | 08:26 |
| bauzas | funky | 08:26 |
| Uggla | bauzas, gibi, I'd like to help with the meeting but I have never done it. May I miss rights to run it ? | 08:28 |
| gibi | I guess they were not touched for a long time and gathered some dust | 08:28 |
| gibi | Uggla: no need for rights other than assigning you to be chair at the beginning | 08:28 |
| gibi | then the bot will listen to you :) | 08:28 |
| sean-k-mooney | Uggla: bauzas or gibi just add you as a co chair for the meeting once they start it and that will give you the rights | 08:28 |
| gibi | #startmeeting foo | 08:29 |
| opendevmeet | Meeting started Mon Jul 11 08:29:58 2022 UTC and is due to finish in 60 minutes. The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot. | 08:29 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:29 |
| opendevmeet | The meeting name has been set to 'foo' | 08:29 |
| gibi | #endmeeting | 08:30 |
| opendevmeet | Meeting ended Mon Jul 11 08:30:02 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 08:30 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/foo/2022/foo.2022-07-11-08.29.html | 08:30 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/foo/2022/foo.2022-07-11-08.29.txt | 08:30 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/foo/2022/foo.2022-07-11-08.29.log.html | 08:30 |
| gibi | heh | 08:30 |
| gibi | not even chair right needed | 08:30 |
| sean-k-mooney | oh hum i guess i was under the impression that there as a list somewhere of who had permissions to do that | 08:30 |
| Uggla | any specific commands to know ? | 08:32 |
| bauzas | sean-k-mooney: no, anyone can start any meeting with the bot | 08:32 |
| sean-k-mooney | #link #agreed #undo #topic? | 08:33 |
| bauzas | someone can litterally hijack our nova meeting without having problems | 08:33 |
| sean-k-mooney | i think thos are the main ones | 08:33 |
| bauzas | Uggla: sec | 08:33 |
| bauzas | https://docs.releng.linuxfoundation.org/en/latest/meetbot.html | 08:33 |
| bauzas | we use this bot ^ | 08:33 |
| sean-k-mooney | its in the bot output above too | 08:33 |
| bauzas | sean-k-mooney: yeah but the wikipage lacks some actions | 08:34 |
| bauzas | the one I provided has better documentation | 08:34 |
| sean-k-mooney | bauzas: good to know i had assumed you needed to be an op in the irc channel to use teh bot | 08:34 |
| bauzas | no | 08:34 |
| bauzas | I'm even not op in this chan | 08:35 |
| sean-k-mooney | ack | 08:35 |
| sean-k-mooney | did that change since we moved to oftc or was that alsway the case | 08:35 |
| bauzas | Uggla: if you wanna run the end of the meeting, you'll just have to copy/paste the agenda, that's it | 08:35 |
| bauzas | sean-k-mooney: was always the case | 08:36 |
| sean-k-mooney | i guess it makes sense since it would have been annoying to maintain in the shared meeting rooms | 08:36 |
| bauzas | https://meetings.opendev.org/meetings/climate/2013/climate.2013-10-28-10.00.log.html | 08:36 |
| sean-k-mooney | ya ok just never had a reason to try so never looked into it | 08:36 |
| bauzas | that's the first meeting I ran IIRC :) | 08:37 |
| bauzas | and I wasn't op in the chan this time | 08:38 |
| Uggla | bauzas, if it can help I'm ok. | 08:38 |
| Uggla | bauzas, I'll try to do my best. | 08:38 |
| bauzas | Uggla: you'll need high-leveled skills | 08:39 |
| bauzas | 1/ open a webpage | 08:39 |
| bauzas | 2/ copy a line | 08:39 |
| bauzas | 3/ paste it to the chan | 08:39 |
| Uggla | ok | 08:41 |
| Uggla | bauzas, just to let you know that I have updated my laptop system fw to 0.1.23, and it looks better regarding thermal management and cpu throttling. | 08:45 |
| bauzas | Uggla: oh, just one thing, you'll need to remove the starting space when pasting | 08:45 |
| bauzas | the # char needs to be the first in the line | 08:45 |
| bauzas | Uggla: yeah, I upgraded too | 08:46 |
| bauzas | now I'm in performance unconditionnally | 08:46 |
| bauzas | but I'd like to see how I could make it changing the mode depending on my battery plug | 08:47 |
| Uggla | bauzas, I agree it seems we can stick it to performance mode. | 08:47 |
| sean-k-mooney | bauzas: gibi by the way i just want to highlight this to ye to get some highlevel imput on the direction https://review.opendev.org/c/openstack/nova/+/845660 i dont often -2 things but i feel like this needs a spec or at least a blueprint and i dont really agree directionally with haveing config driven api behaivor like this when there is nothign the enduser can do about it | 08:48 |
| sean-k-mooney | i was going to bring it up in the opendiscussion section tomorrow an either maintain or drop the -2 depending on the outcome but if ye wont be there then can ye leave some feedback on the direction on gerrit | 08:49 |
| gibi | sean-k-mooney: do we have an alternative? passing this via flavor extra_spec? | 08:53 |
| sean-k-mooney | we have several | 08:55 |
| sean-k-mooney | first if we had that config optioon that would cause all volume attchments to fail on that host | 08:55 |
| sean-k-mooney | it could instead prevent teh agent form starting | 08:55 |
| bauzas | agreed with sean | 08:56 |
| bauzas | on both concerns | 08:56 |
| sean-k-mooney | but we could alos model this in the connetion info form cinder | 08:56 |
| bauzas | 1/ we need a procedural stamp | 08:56 |
| sean-k-mooney | and they could tell us if its required and we could schdule on it using traits | 08:56 |
| bauzas | 2/ we don't want to have endusers wondering why this cloud fails while this other not | 08:56 |
| gibi | I'm +1 on preventing the agent to start | 08:56 |
| bauzas | see ? design solved. | 08:57 |
| sean-k-mooney | not really | 08:57 |
| sean-k-mooney | the agent start may or may not work depending on the backends | 08:57 |
| gibi | bauzas: in this particular case this cloud fails because it is deployed incorrectly :) | 08:58 |
| sean-k-mooney | i.e. if you have a mix of ceph and iscsi | 08:58 |
| sean-k-mooney | i assume tha tis why they did not go that route but to mee failing a tenant operattion due to a misconfiguration fo a system by a cloud admin is wrong | 08:58 |
| sean-k-mooney | i would really like use to treat this like neutorn qos and guarenteed bandwith | 08:59 |
| sean-k-mooney | i.e. if we in tend to enforce or guarentee multipath | 08:59 |
| sean-k-mooney | then we should make it discoverable to the scheduler via placment | 08:59 |
| sean-k-mooney | and ideally requestable by the enduer via a property on the volume | 09:00 |
| sean-k-mooney | otherwise we should keep this best effort and not enforce multipath | 09:00 |
| gibi | I'm not sure about that the enduser needs to ask for this explicitly. For me multipath information is an implementation detail of the cloud. So maybe the operator asks for it | 09:01 |
| sean-k-mooney | if we went with the enforce config option i basically would expect it to check in init_host or one of the subfucntion it calls that multipatd is running | 09:01 |
| gibi | that sounds like a simple solution^^ | 09:02 |
| sean-k-mooney | gibi: well the opartator really can only ask for it in two ways | 09:02 |
| sean-k-mooney | the flavor or some atribute set on the volume_type | 09:02 |
| gibi | yepp, I would say volume_type in this case | 09:02 |
| sean-k-mooney | right volume_type woudl be my preference too but we would need to do the same translation we do for neutorn ports on our side to make the enforcement work | 09:03 |
| gibi | yepp, so if killing the agent is enough to cover the use case then I would do that | 09:03 |
| sean-k-mooney | ok i had proposed that more or less in my last top level comment on the review | 09:04 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/845660/8#message-718400c522ed5bf53306f28a382300335d592f30= | 09:05 |
| gibi | OK, noted my preference there too now | 09:06 |
| sean-k-mooney | thanks | 09:07 |
| bauzas | folks, I have a question | 09:47 |
| bauzas | https://6f28c6786b3c06159e6f-ac3ef42d4a9c79eb41cb204944df5803.ssl.cf2.rackcdn.com/849133/1/check/nova-tox-functional-py38/9cf47c1/testr_results.html | 09:47 |
| bauzas | test_rebuild_with_keypair fails because the regression test uses the latest microversion | 09:47 |
| bauzas | https://github.com/openstack/nova/blob/master/nova/tests/functional/regressions/test_bug_1843708.py#L26 | 09:48 |
| bauzas | so, what would get your preference ? | 09:48 |
| bauzas | changing the microversion used to cap to 2.90, or providing a pubkey ? | 09:48 |
| bauzas | IMHO, the latter | 09:49 |
| gibi | I would provide a pub key | 09:49 |
| bauzas | yeah | 09:49 |
| bauzas | I was thinking this | 09:49 |
| bauzas | thanks | 09:49 |
| sean-k-mooney | ya proably the same i would proably generate a public key or just hardcode a pair in a fixture somewhere that we can reuse | 09:52 |
| sean-k-mooney | the regressiosn should be freestandign for the most part so i woudl do it in the test personally | 09:53 |
| *** xek__ is now known as xek | 10:20 | |
| opendevreview | Gorka Eguileor proposed openstack/nova master: Support os-brick specific lock_path https://review.opendev.org/c/openstack/nova/+/849328 | 11:21 |
| opendevreview | Stephen Finucane proposed openstack/placement master: Fix typo in schema https://review.opendev.org/c/openstack/placement/+/849348 | 12:09 |
| stephenfin | gibi: bauzas: sean-k-mooney: I've already sort of made my mind up on this but can you take a look at https://review.opendev.org/c/openstack/placement/+/849348 (context is a change from ratailor at https://review.opendev.org/c/openstack/placement/+/848634) | 12:12 |
| sean-k-mooney[m] | ya we would need a new microverion i belive | 12:15 |
| sean-k-mooney[m] | unless we were failing on a 500 | 12:15 |
| sean-k-mooney[m] | because we checked in the code somewhere else | 12:15 |
| bauzas | stephenfin: I can try to take a look once I'm done with my own change | 12:17 |
| stephenfin | sean-k-mooney[m] If I revert the code change, the new test I added doesn't fail. That would suggest we were happily accepting an empty object at the code level (presumably because we do falsey checks or similar) | 12:18 |
| sean-k-mooney[m] | ack | 12:18 |
| gibi | "This field may be sent when writing allocations back to the server but will be ignored; this preserves symmetry between read and write representations." | 12:18 |
| gibi | so this value is never used by placement | 12:19 |
| gibi | I think we don't need a microversion in this case | 12:19 |
| sean-k-mooney[m] | oh its the provider tree mappings | 12:19 |
| sean-k-mooney[m] | to lookup the provdier tree form the allocation | 12:20 |
| gibi | (context, the mappings are generated by placement during GET allocation_candidates for the client to know which group are fulfiulled from which RP, so writing this back to placement only make sense for keeping the a_c result directly usable for POST allocations | 12:20 |
| gibi | ) | 12:20 |
| sean-k-mooney[m] | ack | 12:20 |
| sean-k-mooney[m] | so we likely can fix it but we should have the release note to call it out | 12:21 |
| sean-k-mooney[m] | which stephenfin has in there patch | 12:21 |
| gibi | yepp, so I'm +2 | 12:26 |
| *** damiandabrowski[m] is now known as damiandabrowski | 12:45 | |
| *** dasm|off is now known as dasm | 13:51 | |
| * bauzas is about to become crazy | 15:22 | |
| bauzas | https://paste.opendev.org/show/bR65i5QPAN7ieYOEJHF4/ fails because the pubkey doesn't re.match() | 15:22 |
| bauzas | but... the pubkey is exactly good | 15:22 |
| bauzas | wtf, /me is wrapping his head | 15:24 |
| sean-k-mooney | my guess is maybe there are som spaces or other whitespace | 15:27 |
| sean-k-mooney | i would try removeing the ^ and $ | 15:28 |
| bauzas | I can't remove those | 15:29 |
| bauzas | sean-k-mooney: https://github.com/openstack/nova/blob/master/nova/tests/functional/api_samples_test_base.py#L248-L251 | 15:30 |
| bauzas | before adding the ^ and $ for regexp, I verified the strings | 15:30 |
| bauzas | https://paste.opendev.org/show/bixG1pb6FdkuMcZNYBqK/ shows the strings matching before we add the trailing chars | 15:32 |
| bauzas | oh, I think I spotted it | 15:46 |
| gibi | -/16 | 15:54 |
| ygk_12345 | Hi all. we have a wallaby setup. the compute compute services are not starting saying "too old compute version 30". But we have deleted that version from the nova.services db table. But still it is picking up version 30 which we cant find. How to resolve this > | 15:54 |
| ygk_12345 | bauzas: any idea about this issue ? | 15:55 |
| ygk_12345 | i tried pdb inside nova/cmd/compute.py file and could see that current_version is getting value 30 | 15:56 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: WIP: api: Drop generating a keypair and add special chars to naming https://review.opendev.org/c/openstack/nova/+/849133 | 16:12 |
| bauzas | still a WIP due to UTs missing ^ | 16:12 |
| sean-k-mooney | ygk_12345: in addtion to deleting the old compute services you will have to restart the conductors and posibly the other contoller services | 16:17 |
| sean-k-mooney | ygk_12345: they cache the min compute version on start up of the service | 16:17 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: WIP: api: Drop generating a keypair and add special chars to naming https://review.opendev.org/c/openstack/nova/+/849133 | 16:18 |
| ygk_12345 | sean-k-mooney: is this in addition to the db entries deletion ? | 16:18 |
| sean-k-mooney | yes so you will need to delete the old compute service records assuming those host nolonger exist | 16:18 |
| sean-k-mooney | and if you have already tried to start the conductor ectra then you will have to restart it | 16:18 |
| sean-k-mooney | ygk_12345: you should only delete the old entries | 16:19 |
| sean-k-mooney | if those host are gone | 16:19 |
| sean-k-mooney | and will not be coming back | 16:19 |
| sean-k-mooney | ygk_12345: there is a workaround for this if you are fast forward upgrading | 16:19 |
| sean-k-mooney | but if you use that you need to be aware that we dont support configuration where the min compute service version is not met | 16:20 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.disable_compute_service_check_for_ffu | 16:20 |
| ygk_12345 | sean-k-mooney: when restarting the nova-compute service, do they cache any db entries as well ? | 16:20 |
| sean-k-mooney | restarting the nova-comptue service would clear any caching it had since it only caches info in memory | 16:21 |
| sean-k-mooney | we dont cache stuff on disk so there is nothing that would need to be cleaned up manually | 16:21 |
| ygk_12345 | sean-k-mooney: but from where is it picking up the 30 version , even though its not there in the db ? maybe from the memory ? | 16:23 |
| sean-k-mooney | either the binary you are starting is not at the min version or its coming from the db via an rpc to the conductor to get the min service version in the cell | 16:24 |
| ygk_12345 | sean-k-mooney: but the nova.services table doesn't have any trace of version 30 | 16:25 |
| ygk_12345 | sean-k-mooney: also this workaround , is it in control plane nova.conf or in compute nova.conf ? | 16:25 |
| sean-k-mooney | ygk_12345: have you recently done an upgrade to wallaby or are you in the process of an upgrade? | 16:25 |
| sean-k-mooney | ygk_12345: the workaround need to be set on all hosts | 16:25 |
| ygk_12345 | sean-k-mooney: we have upgraded only the control plane | 16:25 |
| sean-k-mooney | from what release | 16:26 |
| ygk_12345 | sean-k-mooney: and we are upgrading computes step by step | 16:26 |
| ygk_12345 | sean-k-mooney: OSA 23.2.0 | 16:26 |
| sean-k-mooney | what openstack release does that map too | 16:26 |
| ygk_12345 | wallaby | 16:26 |
| sean-k-mooney | so 23 is wallayby | 16:27 |
| ygk_12345 | yes | 16:27 |
| sean-k-mooney | and you are coming form victoria? | 16:27 |
| ygk_12345 | yes ussuri->victoria->Wallaby | 16:27 |
| sean-k-mooney | ok so you upgraded the contolers to victoria then upgreaed all the computes | 16:27 |
| sean-k-mooney | then upgraded contoler to wallayby | 16:27 |
| sean-k-mooney | then upgraded the computes | 16:28 |
| sean-k-mooney | you cant upgrade the controlers directly form ussuri to wallayby in one go | 16:28 |
| ygk_12345 | no no. upgraded first the control plane from stein->train->ussuri>vic>wallaby. Then upgraded the computes | 16:28 |
| sean-k-mooney | ok so you are doing a fast forward upgrade | 16:29 |
| sean-k-mooney | or skiplevel depneind on the branding | 16:29 |
| sean-k-mooney | that is not supported by nova directly | 16:29 |
| sean-k-mooney | so you will need to disable our validation with the workaround | 16:29 |
| sean-k-mooney | then upgade allt eh compute to a supported version | 16:29 |
| sean-k-mooney | then renable the check | 16:29 |
| ygk_12345 | so the version 30 is being picked up by cache somewhere ? | 16:30 |
| sean-k-mooney | nova and most service only suport a n to n+1 version delta | 16:30 |
| sean-k-mooney | unlikely | 16:30 |
| sean-k-mooney | its more likely that you are trying to start a stein compute with a wallaby contoler | 16:31 |
| ygk_12345 | yes | 16:31 |
| sean-k-mooney | right that is not supported | 16:31 |
| ygk_12345 | but stein is not 30 version | 16:31 |
| sean-k-mooney | victoria should be version 30 | 16:31 |
| ygk_12345 | i deleted older versions containers from nova.services tables completely | 16:32 |
| sean-k-mooney | that is not a good thing | 16:32 |
| sean-k-mooney | if you have intnaces on the cloud that would break placment | 16:32 |
| ygk_12345 | we have successfully upgraded in other platforms | 16:33 |
| ygk_12345 | sean-k-mooney: i wil try restarting all the nova services | 16:35 |
| ygk_12345 | sean-k-mooney: thanks bro for your time. appreciate it..... | 16:36 |
| sean-k-mooney | the compute service version in stien was 37 by the way https://github.com/openstack/nova/blob/stable/stein/nova/objects/service.py#L34 | 16:36 |
| ygk_12345 | yes | 16:36 |
| ygk_12345 | not 30 | 16:36 |
| sean-k-mooney | 30 was queens | 16:36 |
| ygk_12345 | yes | 16:36 |
| sean-k-mooney | and the miniutm version supproted by a wallaby controler is 52/victoria | 16:37 |
| ygk_12345 | we are totally putting a new os image with wallaby nova-compute version , retaining the vms from the older compute whil rebooting | 16:38 |
| ygk_12345 | the /va/lib/nova/instances is a separate partition | 16:38 |
| sean-k-mooney | so the conductor and other contoller service should not be able to start without bring the computes to victoria first if you are not using the workaround currently | 16:39 |
| sean-k-mooney | i dont know where the queens service is coming form if you have delete the serivcies in the db | 16:40 |
| ygk_12345 | thats what strange | 16:40 |
| sean-k-mooney | but the only place in code it could come form on teh compute node is the nova package | 16:40 |
| sean-k-mooney | implying you have queens code. other wise it has to be coming form the db | 16:40 |
| ygk_12345 | i think its db cache in the memory . i will try a control plane nova services restart and check | 16:42 |
| sean-k-mooney | ygk_12345: i would expect this code to prevent thet conductor form starting https://github.com/openstack/nova/blob/b320f16b851fd1e5238c0b49c780f6a9c6851e48/nova/utils.py#L1053-L1100= | 16:43 |
| ygk_12345 | sean-k-mooney: yes exactly. that part of the code is giving 'current_service_version' to 30 during the pdb | 16:44 |
| ygk_12345 | i cant understand from where it is picking it up | 16:44 |
| sean-k-mooney | have you checked both the api and cell db | 16:44 |
| ygk_12345 | which tables in api and cell ? | 16:45 |
| sean-k-mooney | the service table in the cell db | 16:46 |
| ygk_12345 | it is empty | 16:46 |
| sean-k-mooney | you dont have any entries in cell0 or cell1 | 16:47 |
| ygk_12345 | yes there are.. but ony nova.services table has entries | 16:47 |
| sean-k-mooney | i assume nova.service is cell0? | 16:48 |
| ygk_12345 | no | 16:48 |
| sean-k-mooney | ok its cell1 | 16:48 |
| sean-k-mooney | the nameing depends on the deployemnt too | 16:48 |
| ygk_12345 | just the plain nova db . inside it 'services' table | 16:48 |
| sean-k-mooney | right so that db name "nova" depends on your deployment too | 16:48 |
| ygk_12345 | i see nova.cell0 and placement dbs | 16:48 |
| ygk_12345 | and also nova and nova_api | 16:49 |
| sean-k-mooney | ok then its proably teh cell 1 database | 16:49 |
| ygk_12345 | is there a services table inside it as well ? | 16:49 |
| sean-k-mooney | ya so there should be a service table in every cell database | 16:49 |
| sean-k-mooney | but you should not delete the services | 16:49 |
| ygk_12345 | ok | 16:50 |
| sean-k-mooney | if you do it will break your deployment | 16:50 |
| ygk_12345 | yes got it | 16:50 |
| sean-k-mooney | if you delete the services then teh compute agent wil create a new service entry when it starts | 16:50 |
| ygk_12345 | so i will just retry with nova control plane restart | 16:50 |
| sean-k-mooney | that will resullt in a different serivce uuid and break placment | 16:50 |
| sean-k-mooney | since the hostname uuid pair will fail the unique constrait | 16:50 |
| ygk_12345 | ok | 16:50 |
| sean-k-mooney | try restartin the contolplane contianer but i expect them to fail | 16:51 |
| sean-k-mooney | without the workaround option set | 16:51 |
| sean-k-mooney | since your compute service versions shoudl be <56 | 16:51 |
| ygk_12345 | its working for our other setups perfectly | 16:51 |
| sean-k-mooney | since you have not started them | 16:51 |
| ygk_12345 | anyway let me try and will bother you later | 16:52 |
| sean-k-mooney | ygk_12345: what you are currently trying is not something we expect to wrok upstream so if you are able to do it else wehre you must have the workaround enabled or a downstream patch | 16:52 |
| sean-k-mooney | ok | 16:52 |
| ygk_12345 | sean-k-mooney: thanks | 16:53 |
| mnaser | does nova like to take cpu flag related decisions or is that not a direction nova wants to take anymore | 19:53 |
| mnaser | i've got 100% identical cpus in terms of make/model that fail to live migrate, and it seems like this is because some of them have `tsx-ctrl` and `taa-no` and others dont. | 19:53 |
| mnaser | those two are apparently found in cpu MSR and not in cpuid so they're not visible (see here https://www.qemu.org/docs/master/system/qemu-cpu-models.html?highlight=taa#important-cpu-features-for-intel-x86-hosts ) | 19:54 |
| mnaser | should we warn on it? should we just disable it? it seems like "Same cpu model" isn't really even valid anymore lol | 19:55 |
| *** dasm is now known as dasm|off | 22:18 | |
| TheJulia | It hasn't really felt valid for a long time, to me... but I had a 6 week order lag and ran into something super similar ~12-13 years ago. | 22:32 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!