Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-07-11
08:39:28 bauzas 2/ copy a line
08:39:43 bauzas 3/ paste it to the chan
08:41:20 Uggla ok
08:45:29 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:30 bauzas Uggla: oh, just one thing, you'll need to remove the starting space when pasting
08:45:59 bauzas the # char needs to be the first in the line
08:46:11 bauzas Uggla: yeah, I upgraded too
08:46:38 bauzas now I'm in performance unconditionnally
08:47:01 bauzas but I'd like to see how I could make it changing the mode depending on my battery plug
08:47:05 Uggla bauzas, I agree it seems we can stick it to performance mode.
08:48:38 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:49:59 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:53:51 gibi sean-k-mooney: do we have an alternative? passing this via flavor extra_spec?
08:55:17 sean-k-mooney we have several
08:55:41 sean-k-mooney first if we had that config optioon that would cause all volume attchments to fail on that host
08:55:50 sean-k-mooney it could instead prevent teh agent form starting
08:56:05 bauzas agreed with sean
08:56:10 bauzas on both concerns
08:56:16 sean-k-mooney but we could alos model this in the connetion info form cinder
08:56:18 bauzas 1/ we need a procedural stamp
08:56:31 sean-k-mooney and they could tell us if its required and we could schdule on it using traits
08:56:39 bauzas 2/ we don't want to have endusers wondering why this cloud fails while this other not
08:56:54 gibi I'm +1 on preventing the agent to start
08:57:06 bauzas see ? design solved.
08:57:38 sean-k-mooney not really
08:57:59 sean-k-mooney the agent start may or may not work depending on the backends
08:58:01 gibi bauzas: in this particular case this cloud fails because it is deployed incorrectly :)
08:58:12 sean-k-mooney i.e. if you have a mix of ceph and iscsi
08:58:51 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:59:10 sean-k-mooney i would really like use to treat this like neutorn qos and guarenteed bandwith
08:59:30 sean-k-mooney i.e. if we in tend to enforce or guarentee multipath
08:59:47 sean-k-mooney then we should make it discoverable to the scheduler via placment
09:00:05 sean-k-mooney and ideally requestable by the enduer via a property on the volume
09:00:44 sean-k-mooney otherwise we should keep this best effort and not enforce multipath
09:01:45 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:55 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:02:22 gibi that sounds like a simple solution^^
09:02:23 sean-k-mooney gibi: well the opartator really can only ask for it in two ways
09:02:38 sean-k-mooney the flavor or some atribute set on the volume_type
09:02:49 gibi yepp, I would say volume_type in this case
09:03:25 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:51 gibi yepp, so if killing the agent is enough to cover the use case then I would do that
09:04:56 sean-k-mooney ok i had proposed that more or less in my last top level comment on the review
09:05:09 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/845660/8#message-718400c522ed5bf53306f28a382300335d592f30=
09:06:35 gibi OK, noted my preference there too now
09:07:19 sean-k-mooney thanks
09:47:25 bauzas folks, I have a question
09:47:34 bauzas https://6f28c6786b3c06159e6f-ac3ef42d4a9c79eb41cb204944df5803.ssl.cf2.rackcdn.com/849133/1/check/nova-tox-functional-py38/9cf47c1/testr_results.html
09:47:53 bauzas test_rebuild_with_keypair fails because the regression test uses the latest microversion
09:48:25 bauzas https://github.com/openstack/nova/blob/master/nova/tests/functional/regressions/test_bug_1843708.py#L26
09:48:34 bauzas so, what would get your preference ?
09:48:58 bauzas changing the microversion used to cap to 2.90, or providing a pubkey ?
09:49:08 bauzas IMHO, the latter
09:49:12 gibi I would provide a pub key
09:49:20 bauzas yeah
09:49:36 bauzas I was thinking this
09:49:44 bauzas thanks
09:52:55 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:53:18 sean-k-mooney the regressiosn should be freestandign for the most part so i woudl do it in the test personally
11:21:22 opendevreview Gorka Eguileor proposed openstack/nova master: Support os-brick specific lock_path https://review.opendev.org/c/openstack/nova/+/849328
12:09:40 opendevreview Stephen Finucane proposed openstack/placement master: Fix typo in schema https://review.opendev.org/c/openstack/placement/+/849348
12:12:33 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:15:17 sean-k-mooney[m] ya we would need a new microverion i belive
12:15:29 sean-k-mooney[m] unless we were failing on a 500
12:15:46 sean-k-mooney[m] because we checked in the code somewhere else
12:17:10 bauzas stephenfin: I can try to take a look once I'm done with my own change
12:18:16 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:38 sean-k-mooney[m] ack
12:18:58 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:19:09 gibi so this value is never used by placement
12:19:22 gibi I think we don't need a microversion in this case
12:19:54 sean-k-mooney[m] oh its the provider tree mappings
12:20:12 sean-k-mooney[m] to lookup the provdier tree form the allocation
12:20:34 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:38 gibi )
12:20:55 sean-k-mooney[m] ack
12:21:26 sean-k-mooney[m] so we likely can fix it but we should have the release note to call it out
12:21:42 sean-k-mooney[m] which stephenfin has in there patch
12:26:06 gibi yepp, so I'm +2
15:22:37 bauzas https://paste.opendev.org/show/bR65i5QPAN7ieYOEJHF4/ fails because the pubkey doesn't re.match()
15:22:49 bauzas but... the pubkey is exactly good
15:24:17 bauzas wtf, /me is wrapping his head
15:27:56 sean-k-mooney my guess is maybe there are som spaces or other whitespace
15:28:10 sean-k-mooney i would try removeing the ^ and $
15:29:04 bauzas I can't remove those
15:30:17 bauzas sean-k-mooney: https://github.com/openstack/nova/blob/master/nova/tests/functional/api_samples_test_base.py#L248-L251
15:30:47 bauzas before adding the ^ and $ for regexp, I verified the strings
15:32:38 bauzas https://paste.opendev.org/show/bixG1pb6FdkuMcZNYBqK/ shows the strings matching before we add the trailing chars
15:46:00 bauzas oh, I think I spotted it
15:54:22 gibi -/16
15:54:48 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:55:18 ygk_12345 bauzas: any idea about this issue ?
15:56:09 ygk_12345 i tried pdb inside nova/cmd/compute.py file and could see that current_version is getting value 30
16:12:12 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:28 bauzas still a WIP due to UTs missing ^
16:17:45 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:57 sean-k-mooney ygk_12345: they cache the min compute version on start up of the service
16:18:07 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:14 ygk_12345 sean-k-mooney: is this in addition to the db entries deletion ?
16:18:42 sean-k-mooney yes so you will need to delete the old compute service records assuming those host nolonger exist

Earlier   Later