| samuelkunkel[m] | Good morning | 06:44 |
|---|---|---|
| samuelkunkel[m] | Would love to contribute to the ARM support / Support in CI - if you are looking for some helping hands | 06:45 |
| samuelkunkel[m] | Just saw the Call in the mailing list | 06:45 |
| rpittau | good morning ironic! o/ | 08:05 |
| rpittau | Happy Friday | 08:06 |
| frickler | this looks like a race condition in unit tests, just mentioning in case someone wants to investigate https://zuul.opendev.org/t/openstack/build/6391a419f35f48efb6890a1118433fcb | 09:22 |
| dtantsur | frickler: interesting, I haven't seen this one yet | 10:32 |
| dtantsur | I"m a bit puzzled how we even trigger that... | 10:33 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic master: Do not log into the template1 database during test-setup https://review.opendev.org/c/openstack/ironic/+/879148 | 10:37 |
| dtantsur | frickler: shooting in the darkness really, but ^^^ | 10:37 |
| kaloyank | morning everyone, is there something like a no-op option? I want to see what cleaning steps will be performed on node | 10:45 |
| dtantsur | I don't think so | 10:46 |
| kaloyank | :( | 10:52 |
| dtantsur | fg | 10:53 |
| dtantsur | ehhmm | 10:53 |
| kaloyank | follow up question: is it possible that I tell Ironic to only clean the root disk and leave any other disks alone? | 11:02 |
| dtantsur | I think we implemented that.. | 11:20 |
| dtantsur | kaloyank: https://docs.openstack.org/ironic-python-agent/latest/admin/hardware_managers.html#devices-skip-list | 11:20 |
| dtantsur | not literally what you're looking for, but may help | 11:21 |
| iurygregory | good morning Ironic | 11:25 |
| iurygregory | TGIF | 11:25 |
| kaloyank | I´ll give it a try. One more thing. I´ve set ´erase_devices_priority = 0´ and ´erase_devices_metadata_priority = 0´, shouldn´t these two options effectively disable erasing of drives other than the root disk? | 11:33 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic-python-agent master: Report system firmware information in the inventory https://review.opendev.org/c/openstack/ironic-python-agent/+/879049 | 12:28 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic-python-agent master: Add network interface speed to the inventory https://review.opendev.org/c/openstack/ironic-python-agent/+/879156 | 12:30 |
| dtantsur | this ^^ should be all that BMO needs | 12:30 |
| TheJulia | good morning | 13:32 |
| TheJulia | dtantsur: if you could take a glance at https://review.opendev.org/c/openstack/ironic/+/879060/2 and let me know if you want to scream and hide in the woods, that would be a good data point | 13:33 |
| dtantsur | sure, but a bit later - fighting with hard links here.. | 13:34 |
| TheJulia | oh no worries | 13:34 |
| TheJulia | could be monday | 13:34 |
| * TheJulia is still waking up and still fighting her not so fun cold | 13:35 | |
| TheJulia | step wisse, if we're cool with them, I can rip them all out of my specs since they are cross cutting | 13:38 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic master: Always fall back from hard linking to copying files https://review.opendev.org/c/openstack/ironic/+/879161 | 13:50 |
| dtantsur | TheJulia: same question re screaming ^^ | 13:50 |
| rpittau | dtantsur: wondering if that could give issues with selinux, hardlink maintains context, copy may not | 13:53 |
| dtantsur | yeah, I've been wondering that (but note that the fallback actually existed before this change) | 13:54 |
| dtantsur | I would expect the target directory context to be used.. | 13:54 |
| rpittau | right | 13:54 |
| rpittau | I think we fixed something similar recently, if I remember correctly | 13:54 |
| TheJulia | dtantsur: so the tldr is I think that is what I have wanted for a while on fallback | 13:56 |
| TheJulia | Yeah, copy should be new process rule context | 13:56 |
| rpittau | dtantsur: nvm, it was the other way around, copy should not cause issues as it indeed uses the destination context | 13:57 |
| opendevreview | Riccardo Pittau proposed openstack/ironic master: [WIP] Run metal3 integration with ironic-image from source https://review.opendev.org/c/openstack/ironic/+/879162 | 14:03 |
| iurygregory | dtantsur, do you think it's ok to start prototyping the FirmwareInterface? | 14:11 |
| TheJulia | from my pov, I suspect so. I *wouldn't* mind a little more delineation of the goals attempting to be achieved with the spec since we realized there was a whole set of thigns (hey, that is my method for pushing change!) | 14:16 |
| TheJulia | :) | 14:16 |
| JayF | samuelkunkel[m]: so our needs are basically 2x: we need a CI job running that provisions ARM VMs and validates our agent on them. | 14:18 |
| JayF | samuelkunkel[m]: the 2nd piece is we'd really, really like third-party CI to prove Ironic works on actual ARM hardware before we say "it works" | 14:18 |
| JayF | samuelkunkel[m]: but even if you can only help us with the virtualized CI job, that's a huge help, and we can leave the call out for hardware still :D | 14:18 |
| opendevreview | Riccardo Pittau proposed openstack/ironic master: [WIP] Run metal3 integration with ironic-image from source https://review.opendev.org/c/openstack/ironic/+/879162 | 14:19 |
| kaloyank_ | TheJulia: I´m available to continue the discussion from yesterday :) | 14:20 |
| TheJulia | kaloyank_: first my wife wants to go get some breakfast, then I'll come back | 14:21 |
| samuelkunkel[m] | JayF: sure, sounds good. I help were I can find time. My PO accepted my request to help here so I am allowed to find some dedicated time. :) | 14:34 |
| dtantsur | iurygregory: frankly, I think we should change our approach to specs. Previously, there was a deliberate element of gatekeeping in them. Now it's purely a way to discuss designs, so there is nothing wrong (IMO!) with patches written and even merged while the spec is still being polished. | 14:34 |
| dtantsur | JayF, TheJulia ^^ opinions? | 14:34 |
| samuelkunkel[m] | As there was a general call for help, how is the process from now on? Will we wait how many people are willing to contribute and then assemble a Team? | 14:34 |
| JayF | dtantsur: iurygregory: Eh-ish? I mean, putting patches up = yes. Merging them before the spec I just have an overwhelming feeling of "what's the rush"? | 14:35 |
| samuelkunkel[m] | <JayF> "samuelkunkel: the 2nd piece is..." <- That is nothing I can say for sure currently. We only have a hand full of HPE RL300 Nodes for our own testing and playing currently | 14:35 |
| samuelkunkel[m] | But I ask If I can buy more ;) | 14:35 |
| JayF | samuelkunkel[m]: even a contributor saying "I know it works on X physical hardware" is better than we have now (which is vague reports of it working) | 14:36 |
| dtantsur | JayF: I have an overwhelming feeling of why not :D Given how long we take to merge specs... | 14:36 |
| JayF | dtantsur: iurygregory: We should fix the last half of that piece. But like, I don't actually care, as long as any changes merged before the spec are not operator-facing/api-generating | 14:36 |
| dtantsur | We should fix is not a plan how to fix :-/ | 14:36 |
| dtantsur | So far, we're punishing people for writing specs vs just trying to sneak their changes in | 14:37 |
| JayF | I guess I'm confused, I didn't know we had a big issue with getting specs merged | 14:37 |
| samuelkunkel[m] | JayF: This I can and will test for sure. (for the HPE RL300 we are using) but we are checking some Supermicro stuff out as well. | 14:37 |
| samuelkunkel[m] | Its just: I dont know If I can provide constant node(s) that is only for CI runs from a current standpoint. I need to check that. | 14:37 |
| dtantsur | JayF: for one reason or another, the last actual spec was merged a year ago: https://review.opendev.org/q/project:openstack%252Fironic-specs | 14:38 |
| JayF | samuelkunkel[m]: third party CI is a pretty big commitment | 14:38 |
| JayF | dtantsur: that is weird, but I wonder if there are any https://review.opendev.org/q/project:openstack/ironic-specs+status:open that you think should be landed? | 14:39 |
| JayF | dtantsur: other than your inspector stuff, which I was actively reviewing until PTG (and am waiting for another contributor to review) | 14:40 |
| dtantsur | (okay, the shard one was merged recently - I stand corrected) | 14:41 |
| dtantsur | but hey, even the shard one took 2 months to merge, and it's not really complicated | 14:41 |
| jrosser | JayF: i can say ironic is working with the ipmi driver on Supermicro MegaDC with the Ampere CPU in a R12SPD-A system board | 14:46 |
| iurygregory | sorry, got pushing into helping my parents, just got back | 14:46 |
| JayF | jrosser: can you reply to the list with that specific detail so it's not lost in IRC logs forever? | 14:46 |
| JayF | dtantsur: that's mostly my fault for not being on top of it fwiw | 14:46 |
| jrosser | sure | 14:46 |
| JayF | dtantsur: I don't ever feel reviews were a primary concern | 14:47 |
| iurygregory | I think having the patches upda would help with the spec | 14:47 |
| dtantsur | yeah, that's another thing | 14:47 |
| dtantsur | (note: I definitely don't suggest we merge API changes before properly discussing them... although I'm guilty of doing exactly that for inventory API) | 14:47 |
| samuelkunkel[m] | I am not finished with my final tests - but once I am I can also provide the specs. What List JayF ? :D | 14:47 |
| iurygregory | but yeah, normally we take a long time to merge specs | 14:47 |
| dtantsur | we need to change this norm for sure | 14:48 |
| JayF | samuelkunkel[m]: that mailing list thread about ARM support is a good place for things, but if you're actively going to work on setting up that CI this cycle, I'll add it to the workstream doc that I'll create documenting things we discussed in PTG | 14:48 |
| JayF | samuelkunkel[m]: just grab an etherpad and start making notes, I deem you Ironic ARM subteam captain [taps shoulders with sword] lol | 14:49 |
| dtantsur | wow, fun, we have a spec that is on review since 2016: https://review.opendev.org/c/openstack/ironic-specs/+/186056 | 14:52 |
| samuelkunkel[m] | JayF: Not sure If should be happy or scared though | 14:52 |
| samuelkunkel[m] | * sure If I should be | 14:52 |
| JayF | samuelkunkel[m]: honestly, it's all about what you want to make of it | 14:53 |
| JayF | samuelkunkel[m]: just know one person can make a huge difference, and getting ARM CI up would be huge | 14:53 |
| JayF | samuelkunkel[m]: and not just because there'd be another brain I can recruit when the gate goes upside-down in any arch ;) | 14:53 |
| kubajj | dtantsur: if I implemented the python-ironicclient call to show (or whatever we want to do with it) the inventory, then it could be used with the openstack baremetal ... command? | 14:54 |
| JayF | dtantsur: it's ironic that one of my oldest specs is maybe actually going to merge (IPA comms) in some form | 14:54 |
| dtantsur | kubajj: correct. Please check my spec for the proposed format. | 14:54 |
| dtantsur | JayF: lol, true | 14:54 |
| dtantsur | I'd really want some old specs to merge.. https://review.opendev.org/c/openstack/ironic-specs/+/501511 for instance | 14:55 |
| sschmitt | Speaking of specs, is there a good starting point/template if I wanted to submit one for the more granular neutron port binding I brought up last week (i think) | 14:55 |
| JayF | I've wanted that, as an operator, since upstream-cleaning existed | 14:55 |
| JayF | might have even been a "fast follow" item after we landed it that never got done because of the technical headaches | 14:56 |
| JayF | and at the time, our general unwillingness to accept an 80% OK solution | 14:56 |
| dtantsur | yeah, I've become much more tolerant to "80% OK" things | 14:57 |
| TheJulia | dtantsur: given how many times we’ve gone “let’s debate that in code”, I do agree. The value is ask the questions, get the ideas out. I do think lowering the merge threshold makes sense. Hating on all positive agreement… just elongates the process. Doing so though means we need to reframe things a little. | 14:58 |
| dtantsur | TheJulia: I'm curious if you're still interested in https://review.opendev.org/c/openstack/ironic-specs/+/560152 | 14:58 |
| JayF | I will say, regardless of why it was created, etc, specs are a super useful tool for clarifying thinking about a feature | 14:58 |
| JayF | I've taken our spec template downstream to fill out for non-Ironic things before, just because the structure makes it easy to ensure you're thinking of more edges in your idea | 14:58 |
| TheJulia | dtantsur: me, meh. Others surely yes | 14:59 |
| TheJulia | JayF: I agree completely, but it is a giant gate keeping mechanism as well. And specs are always a “this was the discussion”, reality might be a little different | 15:00 |
| JayF | I think for specs, we need to get the API interfaces to like, 90-95% 'right', everything else just get in the ballpark and go | 15:00 |
| TheJulia | dtantsur: perfection is the enemy of good… | 15:01 |
| JayF | the time is long gone where we'd bikeshed over implementations if there weren't material tradeoffs inovlved | 15:01 |
| JayF | like, lets put a point on this: is there anything, right now, that needs the spec landed b/c it's blocked, or there's a perception it's blocked? | 15:03 |
| JayF | if ^^ that ever happens, please bring it up loudly, on the list, in the meeting, anywhere. I'll make it a huge priority to review it within 24 hours and we can hope other contributors would also give it priority | 15:03 |
| dtantsur | TheJulia: you say, the hold patch works? I'm quite puzzled by it.. | 15:05 |
| TheJulia | dtantsur: works for unit tests | 15:05 |
| dtantsur | Feels like it messes up the states somewhat.. | 15:05 |
| dtantsur | right | 15:05 |
| dtantsur | TheJulia: you expect DEPLOY WAIT -> DEPLOY HOLD -> DEPLOY WAIT. | 15:05 |
| dtantsur | I bet (and it makes more sense) it's actually DEPLOYING -> DEPLOY HOLD -> DEPLOYING | 15:06 |
| TheJulia | That is what I thought at first as well | 15:06 |
| TheJulia | But then the methods went “you can’t call this in that state | 15:06 |
| dtantsur | hmm, to make it actually work, probably DEPLOYING -> DEPLOY HOLD -> DEPLOY WAIT | 15:06 |
| TheJulia | So deploy wait since it is async | 15:06 |
| dtantsur | yeah, but you're calling process_even('hold') from a place where the node is in an 'ING state | 15:07 |
| dtantsur | lemme better comment | 15:07 |
| TheJulia | Yeah, seemed weird when I was doing it | 15:08 |
| TheJulia | And cold meds | 15:08 |
| dtantsur | TheJulia: yeah, that's tough :( anyway, left some comments. nothing critical, except for this issue. | 15:11 |
| TheJulia | Yeah, i need to go back and look at the state transitions around steps because at first I thought everything would be ING, but then it wouldn’t work as is and I realized the state past an executed step was wait | 15:12 |
| dtantsur | only if the step handler returns *WAIT | 15:13 |
| TheJulia | Hmm, so both are needed then | 15:14 |
| TheJulia | I was suspecting that would be the case yesterday | 15:14 |
| JayF | -ING -> HOLD vs WAIT -> HOLD might be the difference between oob step -> hold vs in-band step -> hold | 15:17 |
| JayF | I wonder | 15:17 |
| TheJulia | It is, in theory | 15:18 |
| * TheJulia has consumed breakfast and now wants a nap | 15:19 | |
| dtantsur | Not really. If I recall it right, we always return to ING before analysing what is left | 15:21 |
| JayF | if that's behavior, it's newish behavior | 15:23 |
| dtantsur | JayF: https://opendev.org/openstack/ironic/src/branch/master/ironic/conductor/manager.py#L1227-L1236 | 15:26 |
| dtantsur | we expect nodes to be in WAIT state while an async step is running, but we run "resume" before further processing | 15:26 |
| dtantsur | this is not really new | 15:26 |
| JayF | in... Ocata I never observed it pass thru -ING in those cases | 15:27 |
| JayF | but it was ocata and that was approximately two lifetimes ago | 15:27 |
| dtantsur | yep, newer than ocata is not necessarily new :) | 15:27 |
| JayF | yeah I didn't realize it was that old of an observation until I went to put a release name on it lol | 15:28 |
| opendevreview | Riccardo Pittau proposed openstack/ironic master: [WIP] Run metal3 integration with ironic-image from source https://review.opendev.org/c/openstack/ironic/+/879162 | 15:47 |
| TheJulia | JayF: how did you navigate https://github.com/openstack/ironic/blob/abbd859b766c339f5de33ff08704a7b9ad045bef/ironic/drivers/modules/agent.py#L580 downstream ? | 15:57 |
| JayF | TheJulia: we were using kickstart driver for all deployments | 15:58 |
| JayF | TheJulia: so basically I didn't have to navigate agent imaging at all, just make sure cleaning worked with hb-only | 15:58 |
| TheJulia | Ahh | 15:58 |
| TheJulia | Right | 15:58 |
| TheJulia | kaloyank: fyi ^ | 16:01 |
| JayF | TheJulia: how many of those places exist, I wonder? | 16:05 |
| JayF | TheJulia: if not many... we could just preemptively send the info as part of lookup? | 16:05 |
| kaloyank | aren´t partitioned disks already deprecated? | 16:05 |
| TheJulia | we still have to get the IDs for later commands | 16:05 |
| TheJulia | and partition images are not deprecated | 16:06 |
| kaloyank | O.o | 16:06 |
| TheJulia | 16 places where we directly invoke agent client calls in agent_base.py | 16:06 |
| TheJulia | finalize rescue.. which means credentials have to get downloaded again | 16:07 |
| TheJulia | refresh_steps | 16:07 |
| TheJulia | execution of steps | 16:07 |
| TheJulia | agent time sync, telling the agent to power off | 16:08 |
| TheJulia | and bootloader installation | 16:08 |
| JayF | ooooof | 16:12 |
| TheJulia | to do it all one way, we would have to intercept each call, build buffer of commands to convey, and return to that point in the sequence | 16:12 |
| JayF | so basically when doing this downstream and only using kickstart driver, I punted the hardest part | 16:12 |
| TheJulia | yeah | 16:12 |
| JayF | TheJulia: or put the logic into the conductor about what steps are next and have it ask in advance | 16:13 |
| JayF | TheJulia: sorta like mis-in-place for cooking | 16:13 |
| JayF | I know that's not possible for all cases, but might be for some | 16:13 |
| TheJulia | JayF: we already do that, but because steps can cause next steps to change, we have to ask it again | 16:13 |
| JayF | makes sense | 16:14 |
| JayF | Could we move more of the logic directly into the agent in some of the cases we're doing round trips from conductor? | 16:18 |
| TheJulia | at least the rescue password is hashed now so there is less concern about allowing the agent to just get it | 16:18 |
| * JayF just brainstorming feel free to ignore/not engage if you're doing actual-work | 16:18 | |
| JayF | I'm TC-PTG distracted | 16:18 |
| TheJulia | I think we could possibly, but we're going to need to have a compatability window as well | 16:18 |
| TheJulia | That overlap is the hard part | 16:18 |
| JayF | we can require you run min(ironic, ipa) of a given version to get access to hb-only mode | 16:19 |
| JayF | which means you could use old logic for old path; new logic for new path, yeah? | 16:19 |
| JayF | I guess if you felt strongly motivated to DRY it could get messy | 16:19 |
| TheJulia | basically yeah, this is in the someone likely just needs to go off in a corner and hack out territory unfortunately | 16:19 |
| * TheJulia feels super tired and thanks the cold for this feeling | 16:22 | |
| JayF | I am video-meeting'd-out right now. Trying to make it thru one more day then weekend, then one more week then it's vacation time (I'm out all of the week-after-next) | 16:24 |
| rpittau | TheJulia: hope you'll feel better during the weekend :) | 16:24 |
| rpittau | have a great weekend everyone! o/ | 16:24 |
| TheJulia | dtantsur: w/r/t ironic/common/states.py and allowing abort, do you think abort to just abort out of cleaning? | 16:25 |
| JayF | ++ hold step is abortable, and aborting it should act like abort does in all other cases (yeah?) | 16:25 |
| dtantsur | TheJulia: we allow aborting CLEAN WAIT, so it feels natural to allow it also for CLEAN HOLD | 16:25 |
| dtantsur | yep | 16:25 |
| JayF | IMO the only steps we ship that should not be abortable are ones that break the machine or leave it in a bad state if we stop (or if we just can't stop) | 16:25 |
| JayF | so pause? abortable. hold? abortable. | 16:26 |
| TheJulia | ack | 16:27 |
| opendevreview | Riccardo Pittau proposed openstack/ironic master: [WIP] Run metal3 integration with ironic-image from source https://review.opendev.org/c/openstack/ironic/+/879162 | 16:27 |
| TheJulia | okay | 16:27 |
| * TheJulia lays down for a little while | 16:29 | |
| JayF | I just gave a positive RSVP for Ironic for the PTG in Vancouver, with a request for us to have some kind of way to pull in remote folks. | 16:41 |
| JayF | I know we likely won't have a quorum unless we can include remote folks | 16:41 |
| JayF | I (once again) forgot to schedule a vPTG team photo :( sorry folks | 17:13 |
| dtantsur | with at least 2 people sick, it could be better to skip it actually.. | 17:35 |
| dtantsur | have a nice weekend folks, quick recovery to everyone with cold! | 17:36 |
| TheJulia | Ugh, i was feeling so much better yesterday evening :( | 18:15 |
| JayF | my wife has had a cold all week too. I'll give you both the same advice: go sit down and rest and don't do work :) | 18:16 |
| * TheJulia stumbles towards the espresso machine | 18:18 | |
| TheJulia | wife intercepted me and has convinced me to lay back down | 18:29 |
| TheJulia | my inner workahaulic does not like this | 18:30 |
| JayF | She is a very smart lady :D | 18:30 |
| samuelkunkel[m] | Will there be a Ironic PTG Session in Vancouver? | 18:44 |
| samuelkunkel[m] | Do you say „a“ ironic or „an“ ironic? Both fit ;) | 18:44 |
| JayF | I would probably say "an" but nobody is going to care about minor language nits :) | 18:47 |
| samuelkunkel[m] | „We have an ironic session“ | 18:47 |
| JayF | I am planning for Ironic to have space to discuss at the PTG in Vancouver. It's my expectation that we will not have enough core contributors to get "quorum" on important decisions unless we have a virtual option. | 18:47 |
| JayF | there will be a separate vPTG at the start of "C" release cycle as well | 18:48 |
| samuelkunkel[m] | Sounds good | 18:48 |
| samuelkunkel[m] | Is there already a timeslot? I assume its after the regular schedule? | 18:49 |
| samuelkunkel[m] | Like „on Friday“ | 18:49 |
| JayF | Signups for teams to get into PTG are open until April 5, per the email that hit the list recently | 18:49 |
| JayF | so I would assume the schedule won't be around for a while | 18:50 |
| JayF | I will be in Vancouver for the entire week. | 18:50 |
| samuelkunkel[m] | I think I arrive on Sunday and stay till saturday, so same for me | 18:50 |
| samuelkunkel[m] | If you add 11-12h flight I am also basically the a whole week on tour :/ | 18:51 |
| samuelkunkel[m] | * If you add 11-12h flight oneway I am also basically a whole week on tour :/ | 18:51 |
| JayF | I'm arriving sometime on Monday. I'm driving up from Tacoma, WA so I have about 4 hours on the road, unless the border checkpoint is backed up | 18:51 |
| TheJulia | I’m thinking of landing on Sunday and I may end up spending an extra week in yvr if the wifey gets her passport back in time | 18:54 |
| JayF | nice | 18:56 |
| samuelkunkel[m] | Thats cool | 18:56 |
| JayF | y'all are always welcome to swing by on the way back down and I can smoke something tasty | 18:56 |
| JayF | (assuming the new-less-dark bus is how you're getting there?) | 18:57 |
| * JayF afk for a while | 18:57 | |
| TheJulia | JayF: dunno yet. We really haven't decided | 19:09 |
| * TheJulia drinks coffee with a straw because... because. | 19:10 | |
| iurygregory | I love FW related bugs .-. people say after they updated to a specific version something is not working, I tested in the same type of machine with the FW they mentioned and couldn't reproduce the issue .-. | 19:30 |
| TheJulia | Oh those are the best bugs | 19:36 |
| TheJulia | My next favorite ones which are obvious kernel issues | 19:36 |
| iurygregory | I have 3 bugs related to BIOS Settings 2 seem to be related to using new iLO FW that is providing empty description of the attributes :D | 19:41 |
| TheJulia | sweet! | 19:44 |
| * TheJulia for some reason has forgotten how to add columns to the db | 19:44 | |
| iurygregory | upgrade existing table with new column using alembic? | 19:46 |
| TheJulia | yeah | 19:50 |
| TheJulia | remembered alembic | 19:50 |
| TheJulia | but not having luck on unit tests | 19:50 |
| TheJulia | oooh ahh invalid syntax now | 19:51 |
| iurygregory | \o/ | 19:54 |
| TheJulia | oh, I think the issue was I was trying to use an integer when... really, I should have just used a string due to orm. lets see! | 20:24 |
| TheJulia | gah, it was the way the test is setup | 20:39 |
| opendevreview | Julia Kreger proposed openstack/ironic master: Add jsonrpc port to database https://review.opendev.org/c/openstack/ironic/+/879210 | 22:14 |
| opendevreview | Julia Kreger proposed openstack/ironic-lib master: Add jsonrpc client port capability https://review.opendev.org/c/openstack/ironic-lib/+/879211 | 22:51 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!