| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-11 | |||
| 08:26:05 | bauzas | this is just, touching the UTs and functtests of keypairs is really... fuky | |
| 08:26:07 | bauzas | funky | |
| 08:28:17 | 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:20 | gibi | I guess they were not touched for a long time and gathered some dust | |
| 08:28:45 | gibi | Uggla: no need for rights other than assigning you to be chair at the beginning | |
| 08:28:55 | gibi | then the bot will listen to you :) | |
| 08:28:58 | 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:29:58 | opendevmeet | The meeting name has been set to 'foo' | |
| 08:29:58 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 08:29:58 | 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:58 | gibi | #startmeeting foo | |
| 08:30:02 | opendevmeet | Log: https://meetings.opendev.org/meetings/foo/2022/foo.2022-07-11-08.29.log.html | |
| 08:30:02 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/foo/2022/foo.2022-07-11-08.29.txt | |
| 08:30:02 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/foo/2022/foo.2022-07-11-08.29.html | |
| 08:30:02 | 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:02 | gibi | #endmeeting | |
| 08:30:04 | gibi | heh | |
| 08:30:08 | gibi | not even chair right needed | |
| 08:30:59 | 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:32:08 | Uggla | any specific commands to know ? | |
| 08:32:38 | bauzas | sean-k-mooney: no, anyone can start any meeting with the bot | |
| 08:33:02 | sean-k-mooney | #link #agreed #undo #topic? | |
| 08:33:03 | bauzas | someone can litterally hijack our nova meeting without having problems | |
| 08:33:07 | sean-k-mooney | i think thos are the main ones | |
| 08:33:09 | bauzas | Uggla: sec | |
| 08:33:21 | bauzas | https://docs.releng.linuxfoundation.org/en/latest/meetbot.html | |
| 08:33:34 | bauzas | we use this bot ^ | |
| 08:33:35 | sean-k-mooney | its in the bot output above too | |
| 08:34:18 | bauzas | sean-k-mooney: yeah but the wikipage lacks some actions | |
| 08:34:28 | bauzas | the one I provided has better documentation | |
| 08:34:52 | 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:59 | bauzas | no | |
| 08:35:06 | bauzas | I'm even not op in this chan | |
| 08:35:17 | sean-k-mooney | ack | |
| 08:35:32 | sean-k-mooney | did that change since we moved to oftc or was that alsway the case | |
| 08:35:53 | bauzas | Uggla: if you wanna run the end of the meeting, you'll just have to copy/paste the agenda, that's it | |
| 08:36:03 | bauzas | sean-k-mooney: was always the case | |
| 08:36:08 | sean-k-mooney | i guess it makes sense since it would have been annoying to maintain in the shared meeting rooms | |
| 08:36:34 | sean-k-mooney | ya ok just never had a reason to try so never looked into it | |
| 08:36:34 | bauzas | https://meetings.opendev.org/meetings/climate/2013/climate.2013-10-28-10.00.log.html | |
| 08:37:01 | bauzas | that's the first meeting I ran IIRC :) | |
| 08:38:02 | bauzas | and I wasn't op in the chan this time | |
| 08:38:27 | Uggla | bauzas, if it can help I'm ok. | |
| 08:38:53 | Uggla | bauzas, I'll try to do my best. | |
| 08:39:08 | bauzas | Uggla: you'll need high-leveled skills | |
| 08:39:21 | bauzas | 1/ open a webpage | |
| 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 | |