opendevreview | anguoming proposed openstack/placement master: Remove unicode literal strings https://review.opendev.org/c/openstack/placement/+/845531 | 02:22 |
---|---|---|
*** abhishekk is now known as akekane|home | 04:52 | |
*** akekane|home is now known as abhishekk | 04:52 | |
opendevreview | Takashi Kajinami proposed openstack/nova master: Retry attachment delete API call for 504 Gateway Timeout https://review.opendev.org/c/openstack/nova/+/845543 | 05:51 |
opendevreview | Takashi Kajinami proposed openstack/nova master: Retry attachment delete API call for 504 Gateway Timeout https://review.opendev.org/c/openstack/nova/+/845543 | 05:53 |
opendevreview | Takashi Kajinami proposed openstack/nova master: Retry attachment delete API call for 504 Gateway Timeout https://review.opendev.org/c/openstack/nova/+/845543 | 05:55 |
opendevreview | Takashi Kajinami proposed openstack/nova master: Retry attachment delete API call for 504 Gateway Timeout https://review.opendev.org/c/openstack/nova/+/845543 | 06:02 |
opendevreview | Takashi Kajinami proposed openstack/nova master: Retry attachment delete API call for 504 Gateway Timeout https://review.opendev.org/c/openstack/nova/+/845543 | 06:04 |
*** gibi_summit is now known as gibi | 06:43 | |
gibi | gmann, dansmith: I missed the pings about the RBAC here from last week. Sorry for that I did not hang out on IRC | 06:43 |
gibi | overall I don't think we get much usefull feadback about RBAC | 06:44 |
gibi | there was one discussion that I can mention about the service role | 06:46 |
gibi | there it was expressed that some operators wants service specific service role | 06:47 |
gibi | like a role use only by cinder to talk to nova | 06:47 |
gibi | as this role could be defined pretty restrictively | 06:48 |
gibi | compared to a service role that is used by each service to talk to another service | 06:48 |
gibi | we agreed that this can be a later step in the service role work | 06:48 |
gibi | anther feedback here was that some operators want to define the a set of policy rules describing a service - service interaction from the client perspective | 06:50 |
gibi | e.g. | 06:50 |
gibi | cinder can define what action it wants to call on nova | 06:50 |
gibi | so the cinder tree there could be a policy file for that | 06:50 |
gibi | when cinder is installed | 06:51 |
gibi | that policy file needs to be copied to the policy.d of the nova | 06:51 |
gibi | to grant the access for cinder | 06:51 |
gibi | priteau: hi! thanks for the patch https://review.opendev.org/c/openstack/nova/+/845262 I'm +2 on it. Are you planning to backport this to stable branches too? | 08:31 |
gibi | bauzas: fyi ^^ a simple fix we agreed on last week in berlin ;) | 08:32 |
opendevreview | Takashi Kajinami proposed openstack/nova master: Retry attachment delete API call for 504 Gateway Timeout https://review.opendev.org/c/openstack/nova/+/845543 | 08:32 |
gibi | sean-k-mooney: hi! Could you plug your +2 back to https://review.opendev.org/c/openstack/nova/+/829248 ? Thanks! | 08:33 |
bauzas | hello everyone | 08:43 |
gibi | Uggla: hi! I just started looking at your unshelve patch. Have you considered my comment about splitting it? https://review.opendev.org/c/openstack/nova/+/831507/11..13#message-9605cc5a2071898fa3da8d460761a3910f9bb55f | 08:43 |
gibi | bauzas: o/ | 08:43 |
bauzas | gibi: hope you're good | 08:43 |
gibi | I'm on ~75% energy level | 08:43 |
bauzas | priteau: gibi: https://review.opendev.org/c/openstack/nova/+/845262 sent to the gate | 08:45 |
gibi | bauzas: thanks | 08:45 |
bauzas | agreed with you, we should backport it | 08:45 |
gibi | priteau: let me know your view on backporting. I can take it if you have not time for it | 08:45 |
Uggla | gibi, Hi. Yes I tried to split into 2 patches as you explained. But I had a lot of tests that failed. Mainly because az=None not handled correctly by the REST API part. | 08:47 |
gibi | Uggla: the first patch after the split should not alter the api behavior | 08:48 |
Uggla | gibi, trying to explain --> REST api and compute_api are "coupled". You need some code to handled the az=None case. | 08:49 |
gibi | ack. I think there should be a way to split it. But I haven't tried it so you have more info than me about the hardness of it | 08:50 |
Uggla | gibi, look at --> patchet 11 --> 12 is the attempt. | 08:56 |
Uggla | gibi, and the functional-py39 --> result. | 08:58 |
Uggla | gibi, https://zuul.opendev.org/t/openstack/build/7544a9e1f3804d068abcab1bcf199dc1 | 08:59 |
Uggla | bauzas, gibi , so how was the summit ? Did you enjoy it ? | 09:00 |
bauzas | Uggla: yes and no, some Forum sessions were good while others were just presentations | 09:01 |
bauzas | at least it was productive discussions on hallways. | 09:01 |
Uggla | bauzas, did you meet operators as planned ? | 09:02 |
bauzas | yes | 09:07 |
bauzas | at the PTG, we won't unfortunately see them | 09:07 |
bauzas | it's a sad situation | 09:07 |
bauzas | I'd prefer operators and developers to be on the same venue | 09:08 |
gibi | Uggla: I think it is easy to fix the test failures in the split patches case https://review.opendev.org/c/openstack/nova/+/831507/comment/6d273ab6_17fa8e3f/ | 09:41 |
gibi | Uggla: basically you redefined what new_az=None means | 09:41 |
gibi | so you have to adapt either the caller or the callee to translate | 09:41 |
Uggla | gibi, to be honest, I was lazy. I did no see the benefits to fix those tests in the first patch to then change them in the next one. :) | 09:43 |
gibi | the fix is not in the tests | 09:44 |
gibi | it is about how to split :) | 09:44 |
gibi | you need one extra line of code to support the splitting | 09:44 |
gibi | btw, in general patches > 1000 lines of change considered too big to review, hence my request to split | 09:44 |
Uggla | gibi, agree, I will try it again. | 09:45 |
gibi | I let you hints in the review | 09:45 |
gibi | s/let/left/ | 09:45 |
sean-k-mooney | gibi: oh sure the pf mac patch | 10:11 |
gibi | sean-k-mooney: yepp that is gettin gold | 10:11 |
gibi | getting old | 10:11 |
sean-k-mooney | stephenfin: bauzas would either of ye care to be the second +2 on https://review.opendev.org/c/openstack/nova/+/829248 for gibi | 10:14 |
gibi | that would be much appreciated | 10:15 |
sean-k-mooney | im just looking at the nova status check https://review.opendev.org/c/openstack/nova/+/829248 | 10:15 |
sean-k-mooney | do we want to mention the workaround option for FFU case | 10:16 |
songwenping__ | sean-k-mooney: do you have the lastest local.conf for both one controller node and two compute nodes deployed by devstack? | 10:23 |
*** songwenping__ is now known as songwenping | 10:23 | |
sean-k-mooney | songwenping: what do you mean by default your local.conf can basically be empty | 10:24 |
gibi | sean-k-mooney: you mean in the upgrade check descrtiption? | 10:24 |
sean-k-mooney | songwenping: are you refering to in a ci job | 10:24 |
sean-k-mooney | gibi: https://review.opendev.org/c/openstack/nova/+/845262/2/nova/cmd/status.py#322 | 10:25 |
sean-k-mooney | the status check shoudl take account of the workarounds config option to determin if its a warnign or error | 10:25 |
sean-k-mooney | and the message when it prints shoudl mention the workarounds config option too | 10:26 |
songwenping | sean-k-mooney: no, i'm plan to deploy develop env with one controller and two computes. | 10:26 |
sean-k-mooney | for FFU this might fail depending on when you run it | 10:27 |
sean-k-mooney | songwenping: oh you just want a refernce local.conf to use | 10:28 |
songwenping | yeah | 10:28 |
sean-k-mooney | i think i have one ya one sec | 10:28 |
songwenping | i donnot know the services to enable or disable | 10:28 |
gibi | sean-k-mooney: replied | 10:28 |
sean-k-mooney | songwenping: its really only on the compute that you need to overried the default services but ill paste the ones my ansible code generate | 10:33 |
sean-k-mooney | songwenping: https://paste.opendev.org/show/bBQ5w8E9neWknQ6fF3CO/ | 10:35 |
sean-k-mooney | songwenping: those have mroe thigns set then you need to set but you can look at the enabled/disabeld services | 10:35 |
sean-k-mooney | songwenping: the other thing thats important for the comptue nodes is to ensure that | 10:36 |
sean-k-mooney | RABBIT_HOST="192.168.121.82" | 10:36 |
sean-k-mooney | RABBIT_PASSWORD="password" | 10:36 |
sean-k-mooney | RECLONE="True" | 10:36 |
sean-k-mooney | REMOTE_CEPH="True" | 10:36 |
sean-k-mooney | SERVICE_HOST="192.168.121.82" | 10:36 |
sean-k-mooney | SERVICE_PASSWORD="password" | 10:36 |
sean-k-mooney | the ip or the rabbit host and service host are set to the contoller | 10:36 |
sean-k-mooney | you proably dont want to have RECLONE=True" set by the way | 10:37 |
sean-k-mooney | im using these with ansibel automation and i have simple epo caching with rsync so i need to force devstack to checkout the correct branch so i have reclone=True to force that | 10:38 |
songwenping | sean-k-mooney: many thanks, great useful. | 10:38 |
sean-k-mooney | songwenping: those are just based on the gate jobs by the way. so if you ever want to recreate what a job does you can look in the logs and find the local.conf it used | 10:41 |
songwenping | sean-k-mooney: in the stack.sh.log? | 10:43 |
sean-k-mooney | not its there directly https://zuul.opendev.org/t/openstack/build/6f4ec842455e4231a659c7ac12fc5f7c/log/controller/logs/local_conf.txt | 10:45 |
sean-k-mooney | if that was a multi node job then you woudl also see a compute/logs/local.conf.txt | 10:45 |
sean-k-mooney | the local.conf is one of the files we capature and preserve in the log output dir | 10:46 |
songwenping | ok, thanks. | 10:49 |
sean-k-mooney | gibi: implying we supprot ffu in any way conviced me we should ignore my previous comment and put it down to a lack of morning coffee :) | 10:59 |
gibi | sean-k-mooney: FFU is hard | 10:59 |
gibi | without coffee it is even harder :D | 10:59 |
gibi | but yeah, if we want to talk about FFU then we need to start with testing it first | 11:00 |
gibi | as I'm not soo convinced that it can be done :) | 11:01 |
gibi | I mean can be FFU successfully | 11:01 |
rmart04 | Hey @sean-k-mooney hope you are well. Wondering if you might be able to provide some advice for some CPU profile pain? | 11:01 |
rmart04 | not strictly development I know :D | 11:07 |
rmart04 | I'll post the question just incase it piques your interest :D | 11:15 |
rmart04 | We're in the process of upgrading to C8Stream (OS Train) and noticed our crippled CPU profile (Skylake-Server-IBRS) we have been using across a couple of processor generations no longer works, nova-compute won't start. We get "invalid CPUinfo profile is not compatible with CPU". I'm guessing a microkernel update has changed the flags on the move from C7->C8 for our CascadeLake servers. Is there an easy way around this these days? I'm guessing | 11:15 |
rmart04 | if I change the flags I'm going to break future live migrations? :/ | 11:15 |
sean-k-mooney | rmart04: just back with coffee reading back | 11:17 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Refactor the nested if-else forest https://review.opendev.org/c/openstack/nova/+/845581 | 11:17 |
sean-k-mooney | rmart04: this s almost certainly caused by the fact that tsx was disabled/removed by intel in a microcode | 11:18 |
gibi | Uggla: I made an attempt to transform out the nested if-else forest from the unshelve patch https://review.opendev.org/c/openstack/nova/+/845581 | 11:19 |
sean-k-mooney | i belive the Skylake-Server-IBRS has tsx enabeld but the cascadelake cpus woudl have it disabeld by the new microcode in c8s | 11:19 |
sean-k-mooney | rmart04: you are currently using Skylake-Server-IBRS i would guess Skylake-Server-noTSX-IBRS will work | 11:20 |
rmart04 | I was pointed in that same direction by JGarbutt too, but I couldn't see the TSX flag specified in the old SkyLake profile so thought it might be somthing else. Possibly its still in play even though not specifically specified. | 11:21 |
sean-k-mooney | vagrant@compute ~]$ diff /usr/share/libvirt/cpu_map/x86_Skylake-Server-IBRS.xml /usr/share/libvirt/cpu_map/x86_Skylake-Server-noTSX-IBRS.xml | 11:22 |
sean-k-mooney | 2,3c2,3 | 11:22 |
sean-k-mooney | < <model name='Skylake-Server-IBRS'> | 11:22 |
sean-k-mooney | < <decode host='on' guest='on'/> | 11:22 |
sean-k-mooney | --- | 11:22 |
sean-k-mooney | > <model name='Skylake-Server-noTSX-IBRS'> | 11:22 |
sean-k-mooney | > <decode host='on' guest='off'/> | 11:22 |
sean-k-mooney | 33d32 | 11:22 |
sean-k-mooney | < <feature name='hle'/> | 11:22 |
sean-k-mooney | 58d56 | 11:22 |
sean-k-mooney | < <feature name='rtm'/> | 11:22 |
sean-k-mooney | it sthe hle and rtm flags | 11:22 |
sean-k-mooney | that are used to provde the tsx functionality | 11:22 |
rmart04 | ah OK I see, I was looking for TSX specifically. | 11:22 |
rmart04 | OK that's really useful, thank you. | 11:23 |
rmart04 | I see there is a tsx=on flag in the kernel which might make this go away quietly but unfortunately that probably won't fly on this deployment. | 11:23 |
sean-k-mooney | this is basically what nova/libvirt is comptueing https://paste.opendev.org/show/bMJWSQkhwySkS1FlGRSG/ | 11:24 |
rmart04 | If I change the profile, its going to break lots of LM i guess? | 11:24 |
sean-k-mooney | rmart04: tsx=on wont work | 11:24 |
sean-k-mooney | if they try to use the tsx functionality it will fail | 11:25 |
sean-k-mooney | rmart04: the only way to change the cpu modle is via a hard reboot or cold migration | 11:25 |
sean-k-mooney | so to resolve this you will need guest downtime | 11:26 |
sean-k-mooney | there is no way to avoid that im affriad | 11:26 |
rmart04 | eek. OK well thanks for this very useful info | 11:28 |
jhartkopf | Hey, I am currently working on the implementation for the approved spec for updating user data (https://review.opendev.org/c/openstack/nova-specs/+/816542). Part of the spec is to regenerate the config drive on hard reboots (reboot implementations are driver-specific). My approach would be to do this on every hard reboot as there seems to be no trivial way to check whether user data has been actually changed. | 11:52 |
jhartkopf | Would this be something that every driver needs to support? Any ideas/opinions on this? | 11:52 |
sean-k-mooney | jhartkopf: no this should be done only when requested | 11:55 |
sean-k-mooney | jhartkopf: the spec i tought said the hard-reboot api woudl be extended with a new paramter for this | 11:55 |
sean-k-mooney | jhartkopf: hum https://review.opendev.org/c/openstack/nova-specs/+/816542/7/specs/zed/approved/update-userdata.rst#96 might actully be insfficent | 11:57 |
sean-k-mooney | so that provide a way to update the metadta on hard reboot by providing the data again | 11:58 |
sean-k-mooney | but we likely shoudl have a seccodn boolean parmater like regenerate_configdrive=True|false | 11:59 |
sean-k-mooney | gibi: ^ what do you think? | 12:00 |
* gibi reads back | 12:00 | |
sean-k-mooney | im not sure we want the perfomance hit of always regenerating the config drive on hard reboot | 12:00 |
sean-k-mooney | jhartkopf: it should be implmented for all drivers that support config drive ideally but if you started with just libvirt that proably would cover most usecases | 12:00 |
gibi | so the user_data parameter on reboot will be optional, isn't it? | 12:02 |
sean-k-mooney | jhartkopf: actully the other way to do this is to store a flag in the instance_system_metadata | 12:02 |
sean-k-mooney | gibi: yes but the edge case here is | 12:02 |
sean-k-mooney | how to regenerate teh config drive if i have use server update | 12:02 |
sean-k-mooney | to modify the user data on the next reboot | 12:02 |
sean-k-mooney | jhartkopf: gibi so what we could do is add a flag to the instance_system_metadata to track that the config drive is dirty | 12:03 |
sean-k-mooney | and then check that on reboot and clear it | 12:03 |
sean-k-mooney | if its dirty regenerate the config drive with the new data if not use the exisitng one | 12:03 |
gibi | ahh I see | 12:04 |
sean-k-mooney | the user data on hard reboot is for when you want to fully replace it on reboot | 12:04 |
gibi | I'm fine with a flag in system meta | 12:05 |
sean-k-mooney | which is how i woudl expect this to be used most offten honestly | 12:05 |
jhartkopf | sean-k-mooney: Yes, so with an additional variable, we could track if the config drive should be regenerated or not | 12:05 |
sean-k-mooney | jhartkopf: yep the instance_system_metadata table is internal to nova and jsut a key value pair with the instance as a primary key | 12:06 |
sean-k-mooney | jhartkopf: so you can jsut add a flag to that on server update if you update the user-data field | 12:06 |
sean-k-mooney | then reboot can check it and clear it. does ^ work for you | 12:07 |
sean-k-mooney | if so we can leave the spec as it is. | 12:07 |
* sean-k-mooney stepping away for 10 mins brb | 12:08 | |
jhartkopf | Seems to be the part that was missing, thanks! I will then try to implement this for libvirt initially. | 12:10 |
* sean-k-mooney back | 12:14 | |
sean-k-mooney | jhartkopf: just an fyi the instance system metadata is a feild on the instance object https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L194= | 12:15 |
sean-k-mooney | so you will have direct access to that in the driver and you will be able to update it on save as part of the reboot flow | 12:16 |
sean-k-mooney | just set the key config_drive_dirty flag to false and it will be save when we next call save i.e. when we update the task/vm state | 12:17 |
sean-k-mooney | jhartkopf: if you want you can expose this directly as a property on the instance object to keep it clean so that the virt driver dont need to check the system metadata directly. | 12:18 |
sean-k-mooney | just have the property update the system metadata | 12:19 |
jhartkopf | sean-k-mooney: good point, I will look into this | 12:33 |
bauzas | sean-k-mooney: gibi: fwiw, I'm currently reviewing the hard https://review.opendev.org/c/openstack/nova/+/829248/9/nova/compute/manager.py | 13:11 |
bauzas | (that and doing some expense report...) | 13:11 |
sean-k-mooney | i dont think i have used concour sicne we switch to it | 13:12 |
sean-k-mooney | but if its like the deployment of concour we had at intel its much nicer | 13:12 |
sean-k-mooney | then the oracle suite we used to use for expenses | 13:12 |
gibi | expense was easy but that single line in the manager seems easier :D | 13:12 |
bauzas | concur is good for preparing your report | 13:12 |
bauzas | but there are some bugs in the concur android app | 13:13 |
bauzas | I can't modify some expenses | 13:13 |
sean-k-mooney | ah ok i have only really used the web app | 13:13 |
sean-k-mooney | i dont like haveing compay stuff on my personal phone | 13:13 |
sean-k-mooney | so i jsut take pictures fo the recipts and email them to my company adress and fill it out after the fact | 13:14 |
gibi | bauzas: yepp I had issues with the app but I was able to fix it with the web based too | 13:15 |
gibi | l | 13:15 |
gibi | I guess you hit the issue with setting expense type to ~food and the app asking for some additional fields that was not editable | 13:16 |
bauzas | gibi: yup | 13:17 |
bauzas | gibi: yeah, I provided all my receipts to concur thanks to the android app when waiting for my flight :) | 13:18 |
bauzas | gibi: but eventually I got some problem with a meal and for my hotel expense | 13:18 |
sean-k-mooney | bauzas: not to add to your paper work but are you plannign to send a writeup or operator feedback to the list or similar | 13:19 |
bauzas | but eventually, today I used the webapp and I was able to modify the expenses correctly | 13:19 |
bauzas | sean-k-mooney: we'll be discussing this tomorrow during the meeting and after that, I'll provide a feedback to the list | 13:19 |
sean-k-mooney | ack | 13:19 |
bauzas | sean-k-mooney: but most of the operators told they don't want to have a lot of emails from us | 13:19 |
sean-k-mooney | while you were away there was a request to do a release of stable yoga and xena by the way | 13:20 |
sean-k-mooney | i was going to bring that up in the meeting | 13:20 |
bauzas | sean-k-mooney: oh ok | 13:20 |
sean-k-mooney | i have not looked at whats pending but we have not done a release of yoga yet | 13:20 |
sean-k-mooney | so there proably are some valid bugfixes that would be good to release | 13:20 |
sean-k-mooney | bauzas: i asked mainly for people outside of redhat i was going to ask you about your feedback in our downstream meeting but if were planing to send somethign to the list anyway i was happy enough to just read that | 13:22 |
bauzas | sean-k-mooney: yeah I understand it about the feedback | 13:23 |
bauzas | like I said, I'd first discuss with our folks tomorrow before replying | 13:23 |
sean-k-mooney | no worries. did you enjoy the conference | 13:24 |
bauzas | sean-k-mooney: we had a problem with the etherpad, it became chinese but eventually thanks to fungi it was fixed | 13:24 |
sean-k-mooney | ah did we forget to add teh disclaminer at the top | 13:24 |
bauzas | sean-k-mooney: I actually prefered to discuss with the operators on hallways | 13:24 |
fungi | there was a disclaimer at the top, it was just ignored apparently | 13:25 |
bauzas | sean-k-mooney: we had the same issue with the ptg one, which had the disclaimer | 13:25 |
sean-k-mooney | fungi:ack it happens thanks for helping to fix it | 13:25 |
fungi | np | 13:25 |
sean-k-mooney | bauzas: ya when we are done with the ptg we shoudl share/archive the readonly link | 13:26 |
fungi | highly recommended | 13:26 |
bauzas | sean-k-mooney: if you see my feedback email from the ptg, I was providing the readonly link | 13:26 |
sean-k-mooney | ack | 13:27 |
bauzas | but if someone finds the writable one, then... | 13:27 |
sean-k-mooney | ya you can alway go back in the timeline and find the orginal content but thats hassel | 13:27 |
bauzas | I think the ptg one was changed because I provided a link to the writable etherpad in the session etherpad too | 13:28 |
sean-k-mooney | look liek we are starting to see videos form the summit | 13:28 |
gibi | at some point I was wondering how hard it would be to detect the translator from the etherpad software and bring up a warning | 13:28 |
sean-k-mooney | i would guess its clientside | 13:28 |
sean-k-mooney | so proably not trivial | 13:28 |
bauzas | so, if someone was looking at the operator session etherpad with a chinese translation app and if she/he was clicking the ptg etherpad from it... | 13:28 |
gibi | sean-k-mooney: yeah it would need some js magic | 13:29 |
bauzas | but that's a guess | 13:29 |
sean-k-mooney | bauzas: or right ya crosslinking would cause issues | 13:29 |
sean-k-mooney | its too bad there isnt a settign to mark teh main one readonly when we are done | 13:29 |
sean-k-mooney | i.e. to lock it | 13:29 |
bauzas | yeah | 13:30 |
sean-k-mooney | still i like the flexiblity that etherpad has so im still happy we have it | 13:30 |
sean-k-mooney | well the simplicty and the autour color trackign more then flexiblity | 13:30 |
fungi | etherpad has a pluggable extension architecture, so maybe there's a plugin opendev could add for it to provide that feature (or maybe someone who likes js could write one) | 13:35 |
fungi | we try to stay current with upstream releases, making it easy to develop against their master branch and latest api | 13:36 |
*** dasm|off is now known as dasm | 13:39 | |
sean-k-mooney | i dont see one that jumps out at me on https://static.etherpad.org/index.html but ya maybe | 13:39 |
bauzas | ideally a click button to lock/unlock would suffice | 13:41 |
fungi | agreed | 13:41 |
bauzas | but... I wrote JS a while ago | 13:41 |
sean-k-mooney | oh https://www.npmjs.com/package/ep_disable_reset_authorship_colours | 13:41 |
sean-k-mooney | we should add that one | 13:41 |
fungi | has clearing the authorship colors been a problem for folks? i tend to use that a lot when i'm writing some large bit of prose and want only subsequent edits highlighted | 13:42 |
sean-k-mooney | fungi: just the keybinding | 13:43 |
fungi | ahh, okay | 13:43 |
sean-k-mooney | i think its ctrl shift c | 13:43 |
fungi | what i end up seeing as more of a problem is when someone accidentally deletes everything and then pastes it back in | 13:43 |
sean-k-mooney | so doign it by mistack when copy pasting | 13:43 |
fungi | interesting, i didn't even realize there was a keybind for that, but i agree that sounds like a trap | 13:43 |
sean-k-mooney | yep we add that to the header now too since i did it by mistake when i tought i had selected my terminial but had not | 13:44 |
sean-k-mooney | so just disbaleing that one keybind would be nice | 13:44 |
sean-k-mooney | we can keep the feature but the keybind is not a good default | 13:45 |
fungi | if you want to propose that addition, you can push a change for our image builds here: https://opendev.org/opendev/system-config/src/branch/master/docker/etherpad/Dockerfile#L33 | 13:45 |
fungi | looks like it's already in the commented-out example even? | 13:45 |
sean-k-mooney | im not sure if that plugin disables it outright or just the keybind or if its configurable | 13:46 |
sean-k-mooney | just llook at the source now | 13:47 |
sean-k-mooney | https://github.com/ether/ep_disable_reset_authorship_colours/blob/main/static/js/disable_reset_authorship_colours.js looks like its just hiding the button | 13:47 |
sean-k-mooney | so that wont actully help | 13:47 |
sean-k-mooney | but ya good to know we can look into it sometime | 13:48 |
*** tbachman_ is now known as tbachman | 14:19 | |
opendevreview | Balazs Gibizer proposed openstack/nova master: Poison /sys access via various calls in test https://review.opendev.org/c/openstack/nova/+/844627 | 15:14 |
bauzas | gibi: sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/829248 got a second +2 with comments | 15:19 |
bauzas | nothing urgent to read, just left some notes | 15:19 |
bauzas | honestly, this was hard to review in terms of testing modifications | 15:19 |
bauzas | the patch in question is simple, but the impact is larged | 15:20 |
bauzas | large | 15:20 |
bauzas | but I trust you both | 15:20 |
sean-k-mooney | ack ill read over them after our downstream call | 15:21 |
bauzas | those are mostly bikeshed comments | 15:21 |
bauzas | not requiring a rebased | 15:22 |
gibi | bauzas: I read through your comments. I replied to them. I don't think anything needs to be changed with the patch per se. If you insist on some of the comments the please do and I will push a follow up patch | 15:52 |
bauzas | gibi: cool, wasn't an ask | 15:52 |
gibi | coolio | 15:52 |
gibi | thanks for the review | 15:52 |
bauzas | I'll click the submit button | 15:52 |
gibi | thanks | 15:53 |
bauzas | sent to the gate | 16:06 |
gibi | \o/ | 16:09 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Poison /sys access via various calls in test https://review.opendev.org/c/openstack/nova/+/844627 | 16:12 |
opendevreview | Artom Lifshitz proposed openstack/nova master: libvirt: remove default cputune shares value https://review.opendev.org/c/openstack/nova/+/824048 | 17:04 |
artom | sean-k-mooney, ^^ | 17:04 |
opendevreview | Merged openstack/nova master: Record SRIOV PF MAC in the binding profile https://review.opendev.org/c/openstack/nova/+/829248 | 17:25 |
sean-k-mooney | artom: comments inline | 17:37 |
artom | sean-k-mooney, fair point on the partial | 17:37 |
sean-k-mooney | i think im ok with the patch over all but i want to see the ci result to see if libvirt is ok with the empty cputune element | 17:50 |
sean-k-mooney | i woudl prefer if we did not set it if it had not atributes or child elements but if libvirt does not care then we proably could proceed as you currently have it | 17:51 |
sean-k-mooney | i would like to look at the other quotas however and see if there are other we set by defualt like this | 17:51 |
sean-k-mooney | i dont think we do but we shoudl check | 17:52 |
artom | Yeah, I didn't check with a real libvirt for an empty cputune | 17:52 |
sean-k-mooney | ok ill check back on the zuul resulst tomorrow o/ | 17:53 |
elodilles | erlon bauzas : we can discuss on tomorrow's nova meeting if we want to wait for any patch or can release these >>> https://review.opendev.org/q/project:openstack/releases+is:open+intopic:nova | 18:06 |
erlon | hey elodilles, sure. thanks for creating the release patches | 18:07 |
elodilles | np | 18:08 |
elodilles | sean-k-mooney: fyi, too ^^^ | 18:08 |
opendevreview | Rajat Dhasmana proposed openstack/nova master: Add API support for rebuilding BFV instances https://review.opendev.org/c/openstack/nova/+/830883 | 20:36 |
*** dasm is now known as dasm|off | 22:18 | |
opendevreview | Rajat Dhasmana proposed openstack/nova master: Add API support for rebuilding BFV instances https://review.opendev.org/c/openstack/nova/+/830883 | 22:53 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!