| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic-specs master: Firmware Interface https://review.opendev.org/c/openstack/ironic-specs/+/878505 | 04:22 |
|---|---|---|
| *** eandersson2 is now known as eandersson | 05:56 | |
| rpittau | good morning ironic! o/ | 07:54 |
| samuelkunkel[m] | Hello | 09:45 |
| samuelkunkel[m] | has anyone ever build a arm64 ipa ramdisk/kernel based on centos stream 9? | 09:45 |
| samuelkunkel[m] | on x86 it sure does not work as there are many steps that require e.g. chroot | 09:46 |
| samuelkunkel[m] | but I am building on an arm64 machine (ampere altra) | 09:46 |
| samuelkunkel[m] | debian ipa for arm64 works properly fine on the arm machine | 09:46 |
| samuelkunkel[m] | centos fails within the extract image stage already.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/jiSpFxHxZdHhzoYRCHeTGdMV>) | 09:48 |
| samuelkunkel[m] | need to check if x86 for 9-stream even works... brb | 09:48 |
| samuelkunkel[m] | Sideinfo: I am just trying the plain build (no ssh no extra dibs) | 09:49 |
| samuelkunkel[m] | export ARCH=aarch64 | 09:49 |
| samuelkunkel[m] | ironic-python-agent-builder -r 9-stream centos -vvvv | 09:49 |
| jssfr | that looks wrong | 09:49 |
| jssfr | it's somehow missing the device name | 09:49 |
| jssfr | and that comparison is weird | 09:49 |
| jssfr | as if collected from a command which had multiple lines of output, but only a single line was expected | 09:49 |
| samuelkunkel[m] | Vendor ID: ARM... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/HmgTbfINhJLlTaKgNsbzuXKX>) | 09:50 |
| samuelkunkel[m] | quickly checking if x86 build on x86 works | 09:50 |
| samuelkunkel[m] | I dont mind switching to debian-minimal though, was just strange | 09:50 |
| jssfr | wasn't there an issue with interface naming on debian vs. centos? | 09:50 |
| jrosser | samuelkunkel[m]: https://docs.openstack.org/openstack-ansible-os_ironic/latest/configure-ironic-multiarch.html | 09:51 |
| samuelkunkel[m] | yes. | 09:51 |
| samuelkunkel[m] | jssfr: but it seems like it was partly an error on my side as well. But I will test this for sure | 09:51 |
| samuelkunkel[m] | thanks jrosser - going to test the --extra-args=--no-tmpfs which is the only difference here | 09:53 |
| samuelkunkel[m] | also jssfr the issue was between centos and ubuntu. Tbh I never even tested debian ^^ | 09:54 |
| samuelkunkel[m] | The ubuntu ipa does some weird stuff. But I also founda n option to configure the interface naming there (via a dib env option) | 09:54 |
| jssfr | right | 09:54 |
| jssfr | I'm all in favour of debianisation | 09:55 |
| samuelkunkel[m] | If I recall correctly ubuntu is also not a validated os for the ipa | 09:55 |
| jrosser | samuelkunkel[m]: i have all this working on ampere - those docs are based on what i did | 09:55 |
| samuelkunkel[m] | thanks | 09:56 |
| jrosser | i built the IPA image using rocky linux on an ampere vm | 09:56 |
| samuelkunkel[m] | Ok I currently build on the baremetal ampere machine itself running Ubuntu22. There I run docker in which I have a arm64/v8 containerd based on debian with all the diskimage-builder tools installed | 09:57 |
| samuelkunkel[m] | I guess I need to drill down my chain a bit | 09:57 |
| samuelkunkel[m] | but thanks you for sharing! | 09:58 |
| jrosser | i think i might have abandoned trying to build the centos ipa on a not RH derivative OS | 09:58 |
| jrosser | it wasnt totally obvious what was / was not supposed to work | 09:58 |
| samuelkunkel[m] | so for x86 building centos on debian based systems works properly | 09:59 |
| samuelkunkel[m] | as we are mostly a complete ubuntu/debian based infrastructure it was fine for us to just keep the stream-9 ipa | 09:59 |
| samuelkunkel[m] | So it seems to be an issue running the build within a container as it seem to run properly just in a venv on the baremetal os | 10:06 |
| samuelkunkel[m] | interesting | 10:06 |
| samuelkunkel[m] | building centos arm ipa on ubuntu22 | 10:07 |
| dtantsur | for the reason I don't remember, we ended up building our ARM image on Debian. Maybe rpittau remembers why. | 10:10 |
| rpittau | mmm I don't remember exactly, I think it was missing something | 10:12 |
| dtantsur | TheJulia: I'm seeing a lot of "Client-side error: Agent token is required for heartbeat processing" on my environment, I wonder if something has regressed there.. | 10:13 |
| dtantsur | although.. fast track looks completely broken on this node. IPA not accessible, cannot SSH... | 10:28 |
| samuelkunkel[m] | debian ipa works better then expected. One interesting thing. (collectors in use are default, pci-devices, logs) the fields under the system_vendor key within the introspection data are not populated.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/lpkOupgTlzrAhPuKzfHzRkkz>) | 10:34 |
| samuelkunkel[m] | need to scroll some logs | 10:34 |
| samuelkunkel[m] | Could not get real physical RAM from lshw: Expecting ',' delimiter: line 24 column 8 (char 664): json.decoder.JSONDecodeError: Expecting ',' delimiter: line 24 column 8 (char 664) | 10:38 |
| samuelkunkel[m] | hmm | 10:38 |
| dtantsur | samuelkunkel[m]: I remember some (older?) lshw output invalid JSON | 10:38 |
| samuelkunkel[m] | older in case of older hardware? | 10:39 |
| dtantsur | no, i mean the version of lshw itself | 10:41 |
| samuelkunkel[m] | root@debian:~# lshw -version | 10:42 |
| samuelkunkel[m] | does not even give me an output | 10:42 |
| samuelkunkel[m] | uff | 10:42 |
| samuelkunkel[m] | :D | 10:42 |
| samuelkunkel[m] | apt tells me its lshw/now 02.18.85-0.7 | 10:42 |
| samuelkunkel[m] | do you have any reference to that issue? | 10:43 |
| dtantsur | samuelkunkel[m]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002025 | 10:46 |
| samuelkunkel[m] | thanks | 10:50 |
| samuelkunkel[m] | well, debian seems to be the only people that do not provide 2.19 yet... | 10:50 |
| samuelkunkel[m] | trying to get my build on a bookworm release (debian 12), but firmware-misc-nonfree was moved to a different repo | 11:38 |
| samuelkunkel[m] | is this something we should care about? (I assume I can just add the repo via deb deriving env var) | 11:39 |
| dtantsur | it's a good question, I don't have an answer immediately.. we probably do | 11:40 |
| * samuelkunkel[m] uploaded an image: (3KiB) < https://matrix.org/_matrix/media/v3/download/matrix.org/OhiJkCNdliboVWULfscHRVzS/image.png > | 11:45 | |
| samuelkunkel[m] | fyi: by using export DIB_DEBIAN_COMPONENTS="main,non-free-firmware" it works | 11:45 |
| samuelkunkel[m] | dtantsur: thx for the hint btw. using debian 12 as ipa with 2.19 lshw solves the issue | 12:01 |
| samuelkunkel[m] | "system_vendor": { | 12:01 |
| samuelkunkel[m] | "product_name": "PowerEdge R750 (SKU=090E;ModelName=PowerEdge R750)" | 12:01 |
| samuelkunkel[m] | works pretty good despite not being fully released yet afaik (debian 12) | 12:01 |
| jssfr | it's in some freeze already, so it won't break too much until the release :) | 12:02 |
| jssfr | (i.e. with the yaook hat on: I'm just fine with depending on debian 12 at this date) | 12:02 |
| iurygregory | morning Ironic | 12:13 |
| rpittau | dtantsur: I had a look at ipa-builder and I think the reason behind debian choice was just a matter of size, do we want to give ubuntu a try again? Also we should switch from bionic-focal to focal-jammy I guess and probably remove the ussuri job? | 12:47 |
| rpittau | also pinging TheJulia JayF iurygregory stevebaker[m] for this ^ | 12:48 |
| rpittau | could be a topic for the next meting | 12:49 |
| iurygregory | rpittau, I think it makes sense to give another try | 12:49 |
| iurygregory | yup, sounds like a plan to discuss in the next weekly meeting | 12:50 |
| dtantsur | rpittau: we need to revisit that trademark issue.. I also seem to recall that ubuntu images never worked for me for some reason | 12:54 |
| rpittau | I'm adding a topic to the next meeting | 12:55 |
| dtantsur | we also need to check how small these are | 12:55 |
| rpittau | yeah, that was a big point if I remember well | 12:55 |
| rpittau | I'll try to spin up an image these days to get an idea | 12:56 |
| TheJulia | brraaaains | 12:57 |
| dtantsur | TheJulia: how are you feeling today? | 13:00 |
| iurygregory | i like that the PTG page says "The PTG is on break until 13 UTC!" | 13:00 |
| iurygregory | :D | 13:00 |
| dtantsur | iurygregory: mmm, yeah, inconvenient | 13:00 |
| iurygregory | for some reason the https://ptg.opendev.org/ was directing me to the Useful Link page :D | 13:01 |
| dtantsur | yep, same | 13:02 |
| TheJulia | dtantsur: intermittent fever throughout the night | 13:14 |
| TheJulia | dtantsur: I feel *much* better, but also still tired | 13:14 |
| TheJulia | :( | 13:14 |
| dtantsur | *hugs* | 13:14 |
| TheJulia | Now the wife has it :( | 13:14 |
| dtantsur | le sigh. I was the 2nd here (just as with corona in summer) | 13:15 |
| TheJulia | dtantsur: on that client side error, is the agent re-launching on the systemd screen output? | 13:15 |
| dtantsur | TheJulia: I was trying to understand that, and seems like no. It's actually pretty puzzling, check out the description: https://issues.redhat.com/browse/OCPBUGS-11034 | 13:22 |
| JayF | dtantsur: you gave me flashbacks to custom compiled ipxe roms with custom CAs and TLS settings inside | 13:28 |
| dtantsur | lol | 13:28 |
| iurygregory | JayF, I've updated operator-hour-baremetal-sig in the #openinfra-events | 13:29 |
| TheJulia | dtantsur: so I *think* the issue here is that ssl is bombing on the very first request, but the retry works... except the token has been generated | 13:33 |
| TheJulia | Maybe we need to change the lockout until after the first use of the toekn | 13:33 |
| TheJulia | but that is inherently racey | 13:33 |
| TheJulia | and can conflict with systemd behavior | 13:34 |
| TheJulia | dtantsur: I think your agent is also starting up more than once | 13:41 |
| TheJulia | the ethernet port list order changes... | 13:43 |
| dtantsur | TheJulia: at least the error message is complaining about the / endpoint, not about lookup | 13:47 |
| TheJulia | ahhh, yes | 13:54 |
| TheJulia | so I *do* believe the container is getting restarted | 13:55 |
| * TheJulia goes to see if we randomize the lookup list order | 13:58 | |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic-specs master: Firmware Interface https://review.opendev.org/c/openstack/ironic-specs/+/878505 | 14:21 |
| JayF | iurygregory: NO LOGIN PUBLIC RH BUGS <3<3<3<3 | 15:28 |
| iurygregory | JayF, it will depend on the config of the bug | 15:29 |
| JayF | yeah, Julia said that in PTG :D | 15:30 |
| iurygregory | zoom decided to change my mic config LOL | 15:30 |
| rpittau | good night! o/ | 16:48 |
| opendevreview | Jay Faulkner proposed openstack/ironic-specs master: Retire now-outdated snapshot spec https://review.opendev.org/c/openstack/ironic-specs/+/878930 | 16:52 |
| JayF | ^^ as discussed in PTG mere minutes ago | 16:52 |
| JayF | kaloyank: Hey, we did get around to the item you requested in PTG. There are notes but basically: 1) Service Steps is expected to be the method we use to implement snapshot support so 2) The existing spec is invalid and will be moved to retired ^ 3) Once service steps are completed, it's expected to be a minimal add-on item to implement support for Snapshot from an Ironic | 16:53 |
| JayF | perspective. | 16:53 |
| ebbex | https://github.com/metal3-io/baremetal-operator/blob/main/docs/api.md#rootdevicehints there's nothing here in the api that would set `by_path` for the rootdevice, as per https://docs.openstack.org/ironic/latest/install/advanced.html right? | 16:54 |
| kaloyank | JayF: that sounds great | 16:58 |
| JayF | kaloyank: service steps are REALLY SUPER COOL if you're not familiar yet. Basically ability to apply "steps" (think: cleaning/deployment steps) to a node that's currently in ACTIVE state. Should be super useful for a lot of things, including implementing snapshot support :) | 16:59 |
| JayF | Is there anything anyone knows we need to get backported into Xena before the last release is cut? | 17:02 |
| JayF | It'll be moving to EM very soon, and I need to review that releases PR. I'll check for any pending patches but please make noise in my direction very soon if there's a bugfix in flight we want to get in before releases close on Xena for good :) | 17:03 |
| TheJulia | not that I'm aware of | 17:04 |
| * TheJulia lays down for hopefully quick nap | 17:04 | |
| kaloyank | JayF: I think I got the gist sometime ago when TheJulia was talking about them | 17:05 |
| * JayF is saving his respite for in 1 hour when the NY Pizza place opens | 17:05 | |
| kaloyank | I have one question regarding the "fate" of the IPA comms: what are the next steps? Someone should write a spec, the spec should get approved and move onto implementation? Or there's more to discuss | 17:07 |
| JayF | I think we surfaced a lot of concerns and possible solutions | 17:08 |
| kaloyank | and just to set the record straight: The "bug" I hit with fast-track integrated Neutron was with a flat network | 17:08 |
| JayF | it'll culminate in the spec being updated, or a new one being written, about how to fix those problems | 17:09 |
| kaloyank | OK, I'm just not aware how does the process work | 17:09 |
| JayF | Generally speaking for something there's two paths: | 17:10 |
| JayF | - It's small, so a simple bug is filed (or sometimes not even), and a patch is pushed, approved, and lands. This is how most of our simple bugfixes go. | 17:10 |
| iurygregory | JayF, shouldn't the spec go to retired ? (just wondering) | 17:10 |
| JayF | - For larger, or architecturally impactful changes, we write up a spec, it gets landed, someone implements it. There are often times aspec gets written+approved but because priorities shift it never gets implemented :( | 17:11 |
| JayF | iurygregory: this one? https://review.opendev.org/c/openstack/ironic-specs/+/878930 | 17:11 |
| iurygregory | yeah | 17:11 |
| iurygregory | I'm fine with just removing it also | 17:11 |
| iurygregory | just wanted to double check | 17:11 |
| JayF | it is, if you click the file it says: > rename from specs/approved/snapshot-support.rst > rename to specs/retired/snapshot-support.rst | 17:11 |
| JayF | https://review.opendev.org/c/openstack/ironic-specs/+/878930/1/specs/retired/snapshot-support.rst | 17:12 |
| iurygregory | oh ok | 17:12 |
| kaloyank | JayF: just asking because it wasn't evident to me what are the following steps. I'll just keep an eye on the ironic-specs repo then :) | 17:14 |
| kaloyank | generally, I'm interested in implementing the IPA comms changes | 17:14 |
| JayF | So she's out now, working thru illness so we can PTG, but TheJulia is the person to sync with I think if you're willing to lend a hand | 17:15 |
| JayF | and welcome to the team :) we have stickers and pins, I will send you some if you want (this is not a joke; I literally will post you some Ironic stickers if you want 'em, help or no help.) | 17:16 |
| kaloyank | sure, I'd love to :) | 17:16 |
| JayF | DM me an address to ship stickers to and I'll put them in my mailbox today :) | 17:17 |
| * TheJulia has insufficient cat cuddles to nap | 17:25 | |
| kaloyank | TheJulia: feel free to reach me via DM to sync | 17:28 |
| TheJulia | Ack, maybe in an hour. I’m going to have to capture a cat to take a nap | 17:28 |
| * TheJulia fails and takes migraine meds instead | 17:32 | |
| samuelkunkel[m] | JayF: can you share the link of the „security things to do as an ironic operator“ doc once you had a look? :) | 17:36 |
| JayF | https://docs.openstack.org/ironic/latest/admin/security.html#firmware-security I think does a pretty good job of my concerns | 17:36 |
| JayF | I wasn't going to edit it because that did a really good job | 17:36 |
| samuelkunkel[m] | Thanks! | 17:36 |
| samuelkunkel[m] | Also fine for me :) | 17:37 |
| TheJulia | JayF: I was thinking it might make sense to mention things that would be good to look out for, like you mentioned hidden i2c buses, and I have seen that, and ... yeah... you can flash firmware across them. | 17:46 |
| JayF | TheJulia: bluntly, I'm not sure how much of that ... highly specific information is public or not | 17:49 |
| JayF | TheJulia: I stick that in the realm of > Ideally, an operator would work with their hardware vendor to ensure that proper firmware security measures are put in place ahead of time. | 17:49 |
| JayF | Because at least IME, enable/disable of those interfaces is a compile time bios setting, not something that can be flipped on an image | 17:50 |
| JayF | I am worried if we list too many things to look out for, someone might think very wrongly that it's a comprehensive list. | 17:50 |
| JayF | When really I wanna say, pretty strongly "this is impossible to do alone, you need a vendor to help" | 17:50 |
| JayF | I guess I can edit that to say it pretty directly. | 17:53 |
| JayF | RFR, call for contributors for ARM CI: https://gist.github.com/jayofdoom/c26de64fde114125be48295a66341505 | 17:59 |
| * JayF AFK for a while | 17:59 | |
| TheJulia | JayF: That is reasonable | 18:04 |
| clarkb | I guess virtualized arm baremetal isn't sufficient here? | 18:06 |
| clarkb | you're worried more about the hardware management systems than software executing the arm instruction set? | 18:06 |
| TheJulia | We know some vendors have run into some weirdness on hardware with things such as booting when aspects worked just fine in VMs | 18:07 |
| jrosser | what specific thing is useful from people who are doing arm/ironic? kick the tyres on the experimental IPA image? | 18:11 |
| TheJulia | Primarily just make sure the image works and hopefully continues to work. We've had folks mention some arm weirdness in other areas like ipmi bmc interaction in some bugs, anything we can do to pin down/identify/fix those sorts of issues is super beneficial to the overall ecosystem. Without something like 3rd party CI, we're just sort of hoping. | 18:12 |
| jrosser | well it’s a sample of 1 but learning all about ironic from scratch was a bigger thing than the ARM-ness of the nodes, which basically “just worked” for the admittedly small subset of things we’ve excercised | 18:18 |
| TheJulia | jrosser: that is good | 18:20 |
| jrosser | I expect the variance between vendors is large though, so perhaps collecting some success/not success info would be useful | 18:22 |
| TheJulia | kaloyank: so, snapshooting! | 18:23 |
| kaloyank | TheJulia: yep | 18:33 |
| TheJulia | so I think the big challenge there is the mechanism and flow, not necessarily the trigger | 18:34 |
| kaloyank | just to be clear, I think JayF had in mind to sync over the IPA comms change, although I'm fine with working on snapshotting via service steps | 18:35 |
| kaloyank | as I would really enjoy having both features in my deployment :) | 18:35 |
| JayF | kaloyank: keep talking and you'll have volunteered for more stuff ;) | 18:39 |
| TheJulia | The comm stuff, I think we need to just write out what our solution is | 18:39 |
| TheJulia | JayF: hehe | 18:39 |
| kaloyank | JayF: we have a saying at work that goes: what you haven't told us can't be used against you in court | 18:40 |
| JayF | I have a saying here in Ironic, it goes "please continue volunteering for more things", usually followed by a cackle | 18:41 |
| JayF | ;) | 18:41 |
| kaloyank | ^^ | 18:41 |
| JayF | clarkb: I think all of us would be extremely nervous about publishing a thing as "supported" that literally zero contributors have ever seen /actually work/ | 18:44 |
| JayF | clarkb: So like, I don't think 3rd party CI is an absolute requirement, but maybe >1 contributor/operator saying "I can confirm this works with $specificHardware" + virtualized CI | 18:44 |
| JayF | clarkb: but the problem is twofold: we don't have hardware *and* we don't have time. If we hook a hardware vendor to work on third-party-CI, we can potentially solve both | 18:45 |
| kaloyank | I went over the "Fix options" points in the etherpad and over https://review.opendev.org/c/openstack/ironic-specs/+/777172 and it looks OK | 18:51 |
| TheJulia | dtantsur: so w/r/t https://review.opendev.org/c/openstack/ironic-specs/+/872349/6/specs/approved/service-steps.rst#277, we've traditionally not hidden/changed states except for the None->Available transition. I feel like going down that path may not be great, I know with nova it won't be breaking, but would it *really* be with Metal3 before it could be updated if a mismatch occurs? | 18:51 |
| kaloyank | I'm off for today, see you tmr o/ | 19:05 |
| clarkb | JayF: yup. I just ask because with historically x86 software moving to arm usually the concern is does this work with the different cpu instruction set | 19:37 |
| JayF | clarkb: yeah; I think we have a reasonable level of confidence it works, at least IPA running on an ARM node does. What we're less certain of is what the full architecture looks like, and where the sharp edges are | 19:38 |
| JayF | and without an invested party to help us navigate those edges, it's pretty tough to say "yep, we support ARM" | 19:38 |
| JayF | (not to mention the questions of: which ARM? Supported for ironic services or just IPA/as a deployment target) | 19:39 |
| clarkb | you should be able to test the ironic services pretty well on arm with our existing CI tooling | 19:40 |
| clarkb | the other reason I ask is that I am curious if the fake baremetal works at all without nested virt (arm64 doesn't support this or does but very recently?) | 19:40 |
| JayF | We had that conversation too :) | 19:41 |
| JayF | answering those questions takes time we don't want to spend without having an invested party | 19:41 |
| *** JayF is now known as Guest9308 | 19:44 | |
| *** JasonF is now known as jayf | 19:44 | |
| *** jayf is now known as JayF | 19:44 | |
| opendevreview | Julia Kreger proposed openstack/ironic-specs master: Add service steps framework https://review.opendev.org/c/openstack/ironic-specs/+/872349 | 19:48 |
| opendevreview | Merged openstack/ironic-specs master: Retire now-outdated snapshot spec https://review.opendev.org/c/openstack/ironic-specs/+/878930 | 20:32 |
| JayF | TheJulia: iurygregory: dtantsur: is one of you going to be at the session in one hour? | 20:50 |
| JayF | oh, in 10 minutes, apparently | 20:50 |
| iurygregory | one hour? .-. | 20:50 |
| JayF | I'm GUD at math | 20:50 |
| iurygregory | oh ok | 20:50 |
| iurygregory | yeah, I will be | 20:50 |
| JayF | iurygregory: can you moderate the session? | 20:50 |
| JayF | I'll be there, but would rather be camera off/silent | 20:50 |
| iurygregory | since I'm the owner of the spec | 20:50 |
| JayF | have a personal issue happening right now (my wife's school is in lockdown) | 20:50 |
| iurygregory | JayF, sure | 20:50 |
| iurygregory | can you send the code from the etherpad in private | 20:51 |
| JayF | she is fine but I am not in a good focused place to run a meeting | 20:51 |
| JayF | I'll join and give you host if I can | 20:51 |
| iurygregory | oh ok | 20:51 |
| iurygregory | cool | 20:51 |
| dtantsur | JayF: I was about to ask when exactly we have the session | 20:51 |
| dtantsur | TheJulia: re hiding states: I'll need to think more about it when my brain is not shrimp | 20:52 |
| TheJulia | sure | 20:53 |
| JayF | iurygregory: if you'll join up now, I'll invite you to host | 20:53 |
| * TheJulia coughs up a lung | 20:53 | |
| dtantsur | so, right now, not in an hour? | 20:53 |
| * TheJulia is sooo confused | 20:53 | |
| * dtantsur confused++ | 20:54 | |
| * TheJulia suggests whiskey | 20:54 | |
| JayF | schedule says right now | 20:54 |
| JayF | don't trust my top-of-the-head math | 20:54 |
| dtantsur | the etherpad used to say 2200 UTC hence my question | 20:55 |
| JayF | If I made the etherpad and the schedule mismatch, it'd explain *my* confusion too | 20:55 |
| TheJulia | 2200 UTC is in an hour | 20:55 |
| dtantsur | TheJulia: yep, but the PTG schedule says 2100 UTC | 20:56 |
| TheJulia | oh | 20:56 |
| TheJulia | oh! | 20:56 |
| JayF | I'll update PTG schedule now | 20:56 |
| JayF | we should respect the etherpad schedule, I think | 20:56 |
| JayF | Any dissent? | 20:56 |
| dtantsur | will be harder for me, but makes sense | 20:56 |
| * dtantsur is reaching for more ibuprofen | 20:56 | |
| TheJulia | :( | 20:56 |
| TheJulia | janders: you awake yet? :) | 20:56 |
| iurygregory | TheJulia, probably not | 20:57 |
| iurygregory | he is in asia | 20:57 |
| iurygregory | I think it's 4am or something for him | 20:57 |
| dtantsur | slack claims it's 7am for him. but slack may not be aware of his movements | 20:58 |
| TheJulia | ... I thought he was like 1 hour behind syd | 20:58 |
| iurygregory | exactly | 20:58 |
| dtantsur | anyway, just please tell me the time. if it's in an hour, I'll try to recover a bit by consuming some pancakes (with ibuprofen lol) | 20:58 |
| TheJulia | is he out camping with satellite internet again?! | 20:58 |
| JayF | 2200 UTC is the correct time | 20:58 |
| JayF | I screwed up the ptgbot schedule | 20:58 |
| iurygregory | he is in UTC + 7 | 20:58 |
| dtantsur | TheJulia: no more camping with a newborn :D | 20:59 |
| * TheJulia had no idea | 20:59 | |
| TheJulia | good for him! | 20:59 |
| dtantsur | okay, so I'm blending into the background again, see you in an hour | 20:59 |
| iurygregory | yeah, it's 4am for him :D | 21:00 |
| iurygregory | https://time.is/UTC+7 | 21:00 |
| iurygregory | so there is a small chance he can join in hour, if his newborn doesn't let him sleep | 21:01 |
| opendevreview | Julia Kreger proposed openstack/ironic-specs master: cross-conductor rpc/pxe hand-off https://review.opendev.org/c/openstack/ironic-specs/+/873662 | 21:12 |
| dtantsur | JayF, just in case you (or anyone else) is curious: I"m slowly working on first Ironic resources for rust-openstack: https://github.com/dtantsur/rust-openstack/pull/139 | 21:51 |
| iurygregory | PTG time | 22:00 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
