| *** melwitt is now known as Guest344 | 02:26 | |
| *** bhagyashris is now known as bhagyashris|ruck | 03:04 | |
| *** bhagyashris is now known as bhagyashris|ruck | 07:05 | |
| Ammad | Hello, | 07:23 |
|---|---|---|
| Ammad | Anyone available from nova team ? | 07:23 |
| Ammad | I am able to live migrate vm that is on local disk of compute node to other compute node in wallaby but its not working in xena. | 07:24 |
| Ammad | Timed out during operation: cannot acquire state change lock (held by monitor=remoteDispatchDomainMigratePrepare3Params) | 07:25 |
| Ammad | Seeing above error from libvirt. | 07:25 |
| *** hemna7 is now known as hemna | 07:37 | |
| plibeau3 | hello, when you have time to review https://review.opendev.org/c/openstack/nova/+/820531 | 08:03 |
| opendevreview | Federico Ressi proposed openstack/nova master: Debug Nova APIs call failures https://review.opendev.org/c/openstack/nova/+/806683 | 08:22 |
| *** bhagyashris_ is now known as bhagyashris|ruck | 09:52 | |
| IPO | Hello ! | 11:47 |
| IPO | Is there any plans for https://review.opendev.org/c/openstack/nova/+/805649 ? | 11:48 |
| sean-k-mooney[m] | i have upgraded my vote to a +2 | 11:52 |
| sean-k-mooney[m] | IPO so i would like to see that merged sooner rather then later | 11:53 |
| sean-k-mooney[m] | stephenfin not sure if you are arround but you might have input on ^ otherwise bauza or gibi perhaps. | 11:54 |
| IPO | thx for info ! | 11:55 |
| sean-k-mooney[m] | stephenfin by the way i just noticed you have an old series up for removing vcpu_pin_set. i assume you wont have time to work on that. one of the patches is removing the reshape did we settle on that being an ok thing to do | 11:59 |
| sean-k-mooney[m] | at this point i think it makes sense to remove it and do the other clean up but i know there was some concern about that in the past. | 12:00 |
| gibi | sean-k-mooney[m]: ack, queued but my queue getting long this time as I'm spending quality time with placement SQL queries | 12:04 |
| sean-k-mooney[m] | gibi hopefully someone else will get to it before you, how is the placement work going | 12:16 |
| *** dasm|afk is now known as dasm | 12:38 | |
| gibi | sean-k-mooney[m]: some initial patches are up, but there is still work to do | 13:26 |
| gibi | I see you found them | 13:27 |
| gibi | thanks for the initial look | 13:28 |
| gibi | I will get to them | 13:28 |
| sean-k-mooney | my main uncertentiy for the first too is should we be returnning a 400 for the repated args since it not relaly supported and the current behvior is not what most would expect | 13:29 |
| gibi | yeah I felt the same | 13:29 |
| sean-k-mooney | but as i said inline i dont know if that requries a microverions | 13:29 |
| sean-k-mooney | if it does what you have is the best we can do | 13:29 |
| sean-k-mooney | well pluse a docs not about the behviaor | 13:29 |
| gibi | I will pull in others to agree on to make a separate fix to have that as http400 without a version bump | 13:29 |
| sean-k-mooney | ack | 13:30 |
| gibi | as I'm against silently ignoring things | 13:30 |
| sean-k-mooney | ill try and take a look at the rest of the series but swapping to email for a bit | 13:30 |
| gibi | sean-k-mooney[m]: thanks, no need to rush, I'm still working on the test for the top patch of the series then I will move from the db layer to the object / api | 13:31 |
| sean-k-mooney | ack. do you have any nova feature that will consome this this cycle by the way | 13:31 |
| gibi | no not at this cycle | 13:36 |
| gibi | in the future I'd like to extend the qos support for multisegment networks | 13:37 |
| gibi | where a port might belong to physnet A or physnet B hence the any-trait support need | 13:37 |
| sean-k-mooney | right although really your talking about adding suport for multi segment provider networks | 13:37 |
| sean-k-mooney | and just making sure it works with qos too | 13:38 |
| sean-k-mooney | since we dont really support the multi provider physnet extnsion at all in nova today | 13:38 |
| sean-k-mooney | we just use the first one always | 13:38 |
| gibi | yeah we have a big hole in that support, but in a certain edge case it works :) | 13:38 |
| sean-k-mooney | but yes that is a good use case for it | 13:38 |
| sean-k-mooney | edge case beign you dont use sriov or qos | 13:39 |
| gibi | if you use both, and the SRIOV is your first segment and you dont use numa aware vswitches then it works :) | 13:39 |
| sean-k-mooney | gibi: once we have the ablity to supprot multi segment network we can do generic physnet arare shculding | 13:39 |
| gibi | sean-k-mooney: yes, and I will look into making the generic case work of course | 13:40 |
| sean-k-mooney | ack which woudl be a nice win | 13:40 |
| gibi | I agree | 13:40 |
| sean-k-mooney | its kind of amazing that we will only strat checkign if the phynest is on thet host in the 26th release :) | 13:41 |
| gibi | better late than never :) | 13:41 |
| sean-k-mooney | gibi: by the way the totaly generic case required neturon changes or addtional placment changes to allow matching tratis form sharing RPs without resouce requests | 13:51 |
| sean-k-mooney | e.g. we need to be abel to create shareign RPs for the physnets and assocaited them with the compute nodes via aggreate | 13:52 |
| sean-k-mooney | thos can be resouceless or they can contian invnetories of subnets/ip wand the port can request an allocation form them | 13:52 |
| sean-k-mooney | so i suspect it will be simpler for you to get it working with qos ports first | 13:53 |
| gibi | hm | 13:53 |
| gibi | currently we have physnet RPs on the bridge RP or on the PF RP | 13:53 |
| sean-k-mooney | then netron can report the ip inventorires or port invetories or whatever we use so that all ports can have a resouce request form the provier or the trait | 13:54 |
| sean-k-mooney | gibi: yep we do | 13:54 |
| gibi | ahh I see now | 13:54 |
| gibi | we need a resource for the non QoS ports | 13:54 |
| gibi | and that would be the IP | 13:54 |
| sean-k-mooney | yes | 13:54 |
| sean-k-mooney | ip or port or something else universal | 13:54 |
| gibi | hm, there is a spec for ip less ports | 13:54 |
| sean-k-mooney | or a placment feature to allow matching tratis agiasts resouceless rps | 13:54 |
| gibi | so the ip is not universal | 13:55 |
| sean-k-mooney | ya port likely is the best candiate | 13:55 |
| gibi | OK, lets revisit this for the next cycle | 13:55 |
| gibi | but good points | 13:55 |
| gibi | thanks | 13:55 |
| sean-k-mooney | yep i dont see this as a blocker to what you want to enable | 13:55 |
| sean-k-mooney | just to the end goal fo network aware schdulign so it a sperate spec for the fully generic case | 13:55 |
| sean-k-mooney | shduing based on ip aviablity is partly there for routed networks but as you and bauzas found out when impleenting it they are currently doign a hack with the reserved value | 13:56 |
| sean-k-mooney | which we shoudl clean up eventually | 13:56 |
| gibi | yepp | 13:58 |
| *** bhagyashris is now known as bhagyashris|ruck | 14:35 | |
| opendevreview | Dan Smith proposed openstack/nova master: Add service version check workaround for FFU https://review.opendev.org/c/openstack/nova/+/826097 | 14:57 |
| Guest295 | sean-k-mooney: gibi ^ | 14:57 |
| *** Guest295 is now known as dansmith | 14:58 | |
| gibi | dansmith: ack , will check | 14:58 |
| dansmith | gibi: I assume you saw that thread on the ML | 14:58 |
| gibi | yes | 14:58 |
| dansmith | gibi: I've been working on an FFU grenade lately and poked that pretty easy :/ | 14:58 |
| gibi | and we talked it through with sean-k-mooney last week | 14:59 |
| gibi | I'm not against the WA flag | 14:59 |
| gibi | as it is disabled by default | 14:59 |
| dansmith | I think it sucks to need it, especially to set it for an upgrade, but I think it's probably the most straightforward mitigation at the moment | 15:00 |
| gibi | yeah. I'm +2 on it, it is simple | 15:01 |
| sean-k-mooney | i would proably have gone with "compute_service_check_is_fatal" to align with teh vif_plug checks but ya as a temp fix i think its the simplest thing to do | 15:01 |
| sean-k-mooney | i can take a looks at it in a few just finishing up something | 15:02 |
| dansmith | sean-k-mooney: workarounds were all supposed to be boolean, =False by default and opt-in to some alternate behavior | 15:02 |
| dansmith | so that they should all be "off" in normal operation | 15:02 |
| dansmith | we've deviated from that quite a bit unfortunately, but I hold the flame :) | 15:02 |
| sean-k-mooney | ya i agree it should be off by default | 15:02 |
| sean-k-mooney | and is_fatal woudl be one by default so what you suggested is more correct | 15:03 |
| sean-k-mooney | i was orginially thinking this would not be a workaround | 15:03 |
| sean-k-mooney | i guess my main question is do we know what we want to replace it with long term | 15:03 |
| dansmith | we probably need to figure out how to fix this without a workaround, as noted, but this is a simple backport to get people out of the box | 15:03 |
| dansmith | yeah, I dunno | 15:03 |
| sean-k-mooney | you made a good point that looking at "up" is potentially racy | 15:04 |
| dansmith | yeah | 15:05 |
| sean-k-mooney | so for your grenade job i assuem you are just going to set this to true | 15:05 |
| sean-k-mooney | we need to backport this to wallaby before that job can merge howere right | 15:06 |
| sean-k-mooney | since it need to be set pre upgrade | 15:06 |
| sean-k-mooney | or i guess xena not wallaby | 15:06 |
| dansmith | sean-k-mooney: no we only need it on the target | 15:06 |
| dansmith | but we need to backport it for people | 15:07 |
| sean-k-mooney | well we only need it on the target but we are not ment to requrie config updates on upgrade | 15:07 |
| sean-k-mooney | so to have both be true we should have the config option avaiable in the source version right | 15:07 |
| sean-k-mooney | so just another reason to backport | 15:07 |
| sean-k-mooney | actully so i guess design question for FFU are we going to assume the "no config updates are requried" part still hold true | 15:08 |
| sean-k-mooney | or is that just for n to n+1 | 15:08 |
| dansmith | well, this is really a FFU-specific config option, so it's appropriate for grenade until it's fixed, IMHO | 15:09 |
| dansmith | running (base) with this enabled would be wrong and not like production | 15:09 |
| sean-k-mooney | ack ok i can buy that. | 15:09 |
| dansmith | no config updates from n-2 to n is a different thing, and I don't think we need to stick to that, no | 15:09 |
| dansmith | however, this is an upgrade bug/quirk mitigation | 15:09 |
| opendevreview | Lee Yarwood proposed openstack/nova master: WIP libvirt: Register defaults for undefined hw image properties https://review.opendev.org/c/openstack/nova/+/800708 | 15:29 |
| opendevreview | Lee Yarwood proposed openstack/nova master: WIP manage: Add image_property commands https://review.opendev.org/c/openstack/nova/+/824392 | 15:29 |
| sean-k-mooney | dansmith: https://review.opendev.org/c/openstack/nova/+/826097/1/nova/service.py#265 do you want this to work for just the conductor/schduler or also the api | 15:30 |
| dansmith | sean-k-mooney: conductor is the important one, because it's how computes update their record.. does the api check separately? | 15:30 |
| sean-k-mooney | yes | 15:31 |
| sean-k-mooney | https://github.com/openstack/nova/blob/909cfc76369b94b026cf42b86fb5a310dce21a8c/nova/api/openstack/wsgi_app.py#L50 | 15:31 |
| dansmith | ah, for wsgi yeah | 15:31 |
| sean-k-mooney | when i was check rpc compatiabliy for train-> wallaby i had to commet out both | 15:31 |
| dansmith | yeah I'll update | 15:31 |
| dansmith | I imagine systemd is restarting api enough that it wasn't a problem for me in my grenade | 15:32 |
| dansmith | I'm running a job on top of that now, but I will update when it's done | 15:32 |
| dansmith | thanks for catching | 15:32 |
| sean-k-mooney | no worries ping me when its up and ill rereview. | 15:36 |
| opendevreview | Dan Smith proposed openstack/nova master: Add service version check workaround for FFU https://review.opendev.org/c/openstack/nova/+/826097 | 15:54 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: Extend the RP tree DB query to support any-traits https://review.opendev.org/c/openstack/placement/+/825849 | 16:01 |
| opendevreview | Balazs Gibizer proposed openstack/placement master: Extend the RP tree DB query to support any-traits https://review.opendev.org/c/openstack/placement/+/825849 | 16:06 |
| *** Guest344 is now known as melwitt | 16:18 | |
| dansmith | huzzah https://review.opendev.org/c/openstack/grenade/+/826101 | 16:52 |
| sean-k-mooney | nice | 16:55 |
| artom | Wow | 17:33 |
| artom | Also, I will never not think of https://knowyourmeme.com/memes/rage-guy-fffffuuuuuuuu | 17:33 |
| opendevreview | sean mooney proposed openstack/nova master: [WIP] add initial healthcheck support https://review.opendev.org/c/openstack/nova/+/825015 | 17:48 |
| ade_lee__ | gmann, sean-k-mooney trying to decide how to handle issue in https://review.opendev.org/c/openstack/tempest/+/810808 | 18:22 |
| ade_lee__ | gmann, sean-k-mooney it sounds to me like we're never going to fix the plain encryptor provider . | 18:23 |
| gmann | ade_lee__: I am very unclear on how many tests we are going to skip or fix for FIPs mode. so my suggestion is to exclude the tests run using --exclude-regex/--exclude-list instead of permanently marking those tests as skip in code. | 18:27 |
| gmann | that is how we do for ceph case, 'xyz list of tests does not work for ceph backend so just do not run' | 18:28 |
| ade_lee__ | ok | 18:29 |
| sean-k-mooney | gmann: the regex approch makes sense to me | 18:41 |
| sean-k-mooney | proably using the exclude regex in this case to skip non fips complent tests | 18:42 |
| gmann | cool | 18:42 |
| gmann | yeah | 18:42 |
| sean-k-mooney | the disadvantage to that is running locally | 18:42 |
| sean-k-mooney | so can we do it with a tox env | 18:42 |
| sean-k-mooney | rather then in the job | 18:42 |
| sean-k-mooney | so you can repoduce locally too | 18:43 |
| sean-k-mooney | e.g. like https://github.com/openstack/tempest/blob/master/tox.ini#L151-L162 | 18:43 |
| sean-k-mooney | we can define an integrated-fips target | 18:44 |
| gmann | yeah, we can do that. | 18:45 |
| sean-k-mooney | ade_lee__: does ^ work for you | 18:46 |
| ade_lee__ | gmann, sean-k-mooney we can do that. | 18:48 |
| sean-k-mooney | i think from a downstream pserspcitive that wil make things simpler since we wont have to translate the regex into a jenkins jobs it will just invoke the fips target and get teh same set of test as upstream | 18:48 |
| gmann | ade_lee__: cool, so let's add that in follow up patch after paramiko one which has already +2 and under zuul result. | 18:49 |
| sean-k-mooney | with that said i have not looked at what our downstream jobs will look like | 18:49 |
| ade_lee__ | gmann, sean-k-mooney I suspect for nova though the test suite might pass without the skip, given that the test did not have the fips flag set | 18:50 |
| ade_lee__ | so this may be moot for right now for the nova fips test -- it shows up for sure in the cinder tests though | 18:50 |
| sean-k-mooney | i dont really see how this would be project specific | 18:51 |
| sean-k-mooney | we are both using the the same integrated-fips jobs no? | 18:51 |
| ade_lee__ | sean-k-mooney, its more a matter of which tests run in which test jobs .. | 18:51 |
| sean-k-mooney | well my point is the latest version fo the nova patch uses a common job | 18:52 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/790519/20/.zuul.yaml | 18:52 |
| gmann | yeah it run all the tests | 18:52 |
| sean-k-mooney | its not nova specific | 18:52 |
| ade_lee__ | sean-k-mooney, gmann where the fips flag was shown to be needed was here -- https://review.opendev.org/c/openstack/cinder/+/790535/24/.zuul.yaml#134 | 18:53 |
| ade_lee__ | one or more of those in any case .. | 18:53 |
| sean-k-mooney | that because fo ceph? | 18:54 |
| sean-k-mooney | where is the common job currently defiend | 18:54 |
| ade_lee__ | tempest-integrated-storage-fips I think .. | 18:54 |
| gmann | this one https://github.com/openstack/tempest/blob/master/zuul.d/integrated-gate.yaml#L301 | 18:55 |
| sean-k-mooney | here https://github.com/openstack/tempest/blob/master/zuul.d/integrated-gate.yaml#L300-L314 | 18:55 |
| ade_lee__ | sean-k-mooney, remember this test is for skipping something related to encrypted volumes .. | 18:55 |
| sean-k-mooney | ya | 18:55 |
| gmann | not sure how that flag which is not there will pass the test. let's see in result | 18:55 |
| sean-k-mooney | right but in genally we woudl expect those test to run on nova too | 18:55 |
| gmann | yes, it will run | 18:55 |
| gmann | its tempest-full run | 18:56 |
| sean-k-mooney | ade_lee__: i would guess this is speicifc to useing ceph | 18:56 |
| sean-k-mooney | as by default we will use lvm + iscsi | 18:56 |
| sean-k-mooney | or rather looking at https://review.opendev.org/c/openstack/cinder/+/790535 | 18:56 |
| sean-k-mooney | it need in a few non lvm/isci default cases | 18:57 |
| sean-k-mooney | its proably related to ISCSID_ENABLE_FIPS: True | 18:57 |
| sean-k-mooney | that is set in all the jobs that failed | 18:58 |
| sean-k-mooney | but its not in tempest-centos8-stream-fips | 18:58 |
| ade_lee__ | sean-k-mooney, that just sets the iscsi chap algorithms to not use md5 -- we actually don't need that any more | 18:58 |
| ade_lee__ | sean-k-mooney, so it has no effect. | 18:58 |
| ade_lee__ | sean-k-mooney, abishop and eharney are still investigating the failures | 18:59 |
| ade_lee__ | sean-k-mooney, there is something going on with cryptsetup and fips | 18:59 |
| sean-k-mooney | i see well right now the generic fips env is running https://github.com/openstack/tempest/blob/master/tox.ini#L101-L113 | 18:59 |
| ade_lee__ | even in the luks case | 18:59 |
| sean-k-mooney | the fips jobs seam to be all using the singel node node sets is that intentinal | 19:00 |
| ade_lee__ | sean-k-mooney, no - not intentional - thats what we had defeined for nova while testing | 19:02 |
| sean-k-mooney | gmann: actully looking at how those run it proably does not make sense to use a tox target | 19:03 |
| ade_lee__ | sean-k-mooney, we can change if needed | 19:03 |
| sean-k-mooney | ade_lee__: for nova we would want multi node for live migration and colde migration coverage | 19:03 |
| ade_lee__ | sean-k-mooney, ack - so do we want to change in the generic job as defined here - or define a new job? gmann ^^? | 19:04 |
| sean-k-mooney | gmann: we will need to exclude non fips compatible test but we need to include tests form the tempest plugins for ceph ectra | 19:05 |
| sean-k-mooney | so doing that in the job configuation actully proable makes more sense then backing it into a bunch of tox envs | 19:05 |
| sean-k-mooney | ade_lee__: porbaly have both so just inhirt form the current jobs and defien the nodeset to be a multi node variant | 19:06 |
| sean-k-mooney | then the porject can decided which one they want to included | 19:07 |
| ade_lee__ | sean-k-mooney, sounds reasonable to me | 19:07 |
| gmann | sean-k-mooney: ade_lee__ ok, so for multinode case we can inherit from tempest-multinode-full-py3 https://github.com/openstack/tempest/blob/master/zuul.d/integrated-gate.yaml#L230 | 19:08 |
| sean-k-mooney | that also works | 19:08 |
| sean-k-mooney | i was thinking of just inhirting form tempest-centos8-stream-fips and setting the nodeset | 19:09 |
| sean-k-mooney | so you dont have to redfiene the fips specific things in two places | 19:09 |
| ade_lee__ | sean-k-mooney, though presumably you have to refine all the multinode things .. | 19:10 |
| sean-k-mooney | no | 19:10 |
| sean-k-mooney | all the devstack jobs inhrit form multinode | 19:10 |
| sean-k-mooney | so a single node job is a multi node jobs without a second node defiend | 19:11 |
| ade_lee__ | sean-k-mooney, I meant all the things in https://github.com/openstack/tempest/blob/master/zuul.d/integrated-gate.yaml#L232-L242 | 19:11 |
| gmann | ade_lee__: you do not need USE_PYTHON3 as it is default to true in devstack now | 19:12 |
| sean-k-mooney | ade_lee__ none of that is relevent to multi node | 19:12 |
| gmann | ade_lee__: sean-k-mooney so you are saying two jobs 1. existing tempest-centos8-stream-fips 2. new multinode one ? | 19:13 |
| sean-k-mooney | what we need to do is https://github.com/openstack/devstack/blob/master/.zuul.yaml#L179-L207 | 19:13 |
| sean-k-mooney | for centos | 19:13 |
| gmann | if so why not converting the existing one to multinode | 19:13 |
| sean-k-mooney | gmann: we could convert it to multinode | 19:13 |
| sean-k-mooney | but we still need to override the nodeset to use centos-8-stream | 19:13 |
| sean-k-mooney | since the current jobs assumes that | 19:14 |
| gmann | yeah | 19:14 |
| sean-k-mooney | so either in devstack or in tempest we need a openstack-two-node-centos-8-stream nodeset | 19:14 |
| gmann | we need to define that in devstack | 19:15 |
| sean-k-mooney | gmann: i was assumign it would be simpler to get the fips jobs stable single node then add multi node | 19:15 |
| sean-k-mooney | gmann: by convention yes. althoguh its not required by zuul | 19:15 |
| ade_lee__ | sean-k-mooney, we should probably stick with convention .. | 19:16 |
| gmann | sean-k-mooney: we can see what all test fails and if that is multinode related or not. if so then we can separate the efforty | 19:16 |
| sean-k-mooney | ack | 19:16 |
| sean-k-mooney | ok im going to go cook dinner so ill let ye figure out the best way forward | 19:16 |
| ade_lee__ | sean-k-mooney, gmann -- so , as I understand the plan | 19:17 |
| gmann | sean-k-mooney: have a good one. lunch time for me too | 19:17 |
| gmann | ade_lee__: thanks | 19:17 |
| * sean-k-mooney waits for summary | 19:17 | |
| ade_lee__ | 1. merge current patches for single-node (assuming all tests pass, as I suspect they will) | 19:17 |
| ade_lee__ | 2. add nodeset definition to devstack | 19:18 |
| ade_lee__ | 3. add multinode job to tempest with that nodeset -- basically same as single + new nodeset | 19:18 |
| ade_lee__ | 4. add to nova jobs / replace existing job | 19:19 |
| ade_lee__ | thats it .. I think .. | 19:20 |
| gmann | ade_lee__: in 3rd and 4th - let's modify existing job tempest-centos8-stream-fips to use multinode nodeset | 19:20 |
| sean-k-mooney | ya that sounds resonable to me i suspect say keystone wont care about multi node so having both makes sense to me but 3 could be "update single node job to multi node " too as an alternitive | 19:20 |
| ade_lee__ | jinx :) | 19:20 |
| sean-k-mooney | gmann: im ok with either option so ill defer to your preferocne on one job or two | 19:20 |
| ade_lee__ | deferring to ya'll - but I think its likely other projects may not care about multinode too | 19:21 |
| gmann | sean-k-mooney: ade_lee__ let's start with multinode and if things fails more or so then we can have single node and then multinode separate jobs | 19:21 |
| gmann | ade_lee__: sean-k-mooney you mean keystone only right? other projects anyways need to define the new jobs to include their tempest tests from their plugin | 19:22 |
| ade_lee__ | gmann, I'm just thinking that given that we have a common place for fips jobs, other projects might want to use or inherit from them | 19:23 |
| gmann | ade_lee__: ok, inherit is good point. | 19:23 |
| gmann | ok. let's define both in that case. | 19:24 |
| ade_lee__ | cool | 19:24 |
| sean-k-mooney | gmann: i picked keystone at randmon bascially because noting in keystone should affect cold/live migration so keystone proabley dont want to waste ci resouces testing multi node | 19:24 |
| sean-k-mooney | same for glance swift ectra | 19:24 |
| gmann | yeah and even it can be treated as base for other tempest plugin jobs too | 19:24 |
| gmann | so single and multinode jobs as separate sounds good | 19:25 |
| ade_lee__ | cool - sounds like a plan ! thanks ya'll | 19:25 |
| ade_lee__ | go eat! | 19:25 |
| gmann | thanks | 19:25 |
| gmann | :) | 19:25 |
| sean-k-mooney | o/ | 19:26 |
| *** melwitt is now known as Guest440 | 19:54 | |
| *** melwitt_ is now known as melwitt | 20:55 | |
| *** melwitt is now known as Guest450 | 20:59 | |
| -opendevstatus- NOTICE: review.opendev.org will have a few short outages over the next few hours (beginning 22:00 UTC) while we rename projects and then upgrade to Gerrit 3.4. See https://lists.opendev.org/pipermail/service-announce/2022-January/000030.html for details. | 21:04 | |
| *** melwitt_ is now known as melwitt | 21:05 | |
| *** melwitt is now known as Guest451 | 21:07 | |
| *** Guest451 is now known as melwitt | 21:10 | |
| *** dasm is now known as dasm|off | 21:30 | |
| *** ministry is now known as __ministry | 21:52 | |
| -opendevstatus- NOTICE: The review.opendev.org maintenance work is beginning now. Expect Gerrit outages over the next couple of hours. See https://lists.opendev.org/pipermail/service-announce/2022-January/000030.html for details. | 22:02 | |
| *** melwitt is now known as Guest456 | 22:04 | |
| *** Guest456 is now known as melwitt | 22:12 | |
| *** melwitt is now known as Guest458 | 22:13 | |
| *** Guest458 is now known as melwitt | 22:15 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!