| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-11 | |||
| 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 | bauzas | https://meetings.opendev.org/meetings/climate/2013/climate.2013-10-28-10.00.log.html | |
| 08:36:34 | sean-k-mooney | ya ok just never had a reason to try so never looked into it | |
| 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 | |
| 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 | |