opendevreview | Merged openstack/ironic-python-agent master: destroy_disk_metadata: support 4096 sector size https://review.opendev.org/c/openstack/ironic-python-agent/+/915983 | 00:38 |
---|---|---|
rpittau | good morning ironic! o/ | 06:47 |
rpittau | JayF: thanks for starting that! | 06:53 |
cid | TheJulia: About the extra stuff in the mappings, I got a merge conflict, I believe it was with this change https://review.opendev.org/c/openstack/ironic/+/913440, I fixed it. But also noticed that the latest release and master were pointing at the same things in that change, so I did same. | 08:45 |
cid | Seems that was not exactly right | 08:49 |
opendevreview | Fabian Wiesel proposed openstack/sushy-oem-idrac master: Added method for getting kvm session https://review.opendev.org/c/openstack/sushy-oem-idrac/+/917020 | 10:35 |
opendevreview | Fabian Wiesel proposed openstack/sushy-oem-idrac master: Add DellAttributes for manager https://review.opendev.org/c/openstack/sushy-oem-idrac/+/917021 | 10:37 |
opendevreview | Fabian Wiesel proposed openstack/sushy-oem-idrac master: Add OEM DellAttributes to DellManagerExtension https://review.opendev.org/c/openstack/sushy-oem-idrac/+/917021 | 10:39 |
*** srelf_ is now known as ContinuitySR | 10:51 | |
Sandzwerg[m] | Above are the patches by my colleague | 10:58 |
TheJulia | cid, should have only changed master, I guess we need to add some prose in there to explain what and why for clarity :) | 13:15 |
TheJulia | I can take care of those words :) | 13:15 |
TheJulia | cid: The only time we create the other sections is when were doing things as part of release activities for version mapping | 13:18 |
cid | TheJulia: Yea. Thanks for clarifying. I mean, it made more sense when I realized that the conflicting change was only updating release mappings. | 13:31 |
opendevreview | Julia Kreger proposed openstack/ironic master: doc: Add extra context around release mapping https://review.opendev.org/c/openstack/ironic/+/917048 | 13:50 |
JayF | +2A ^ | 14:07 |
opendevreview | cid proposed openstack/ironic master: Remove special treatment of .json for API objects https://review.opendev.org/c/openstack/ironic/+/913467 | 15:53 |
opendevreview | cid proposed openstack/ironic master: Remove special treatment of .json for API objects https://review.opendev.org/c/openstack/ironic/+/913467 | 15:55 |
opendevreview | cid proposed openstack/ironic master: Remove special treatment of .json for API objects https://review.opendev.org/c/openstack/ironic/+/913467 | 16:00 |
rpittau | good night! o/ | 16:12 |
cid | o/ | 16:23 |
cid | TheJulia: Regarding this comment "... just create a single job or two which leverages arm", how would I go about this? The zuul jobs are not architecture specific, or maybe they were all setup with x86_64 in mind. | 16:33 |
cid | I have also been meaning to ask how CI configures Ironic, is there a config file or is it just the cli defaults? | 16:34 |
JayF | so if you look in zuul.d/*.yaml, those are the config files | 16:35 |
JayF | basically the primary form of CI config is environment variables | 16:35 |
JayF | right now, all the defaults are lined up for x86 to "just work" without being explicitly configured | 16:35 |
JayF | to get a job working, we'll have to add a new job/modify an existing job to set those various environment variables | 16:36 |
JayF | figuring out the exact list of things that need to change is sorta part of the task :D | 16:36 |
JayF | but as a starter, you can just look at what your change has already hooked up | 16:36 |
TheJulia | JayF: Thanks! | 16:37 |
TheJulia | cid: I think JayF covered what I was thinking. you can define a job to run with specific variables, you will see a lot of that in our various jobs | 16:38 |
TheJulia | zuul.d/project.yaml is just the list of jobs | 16:38 |
TheJulia | and in what case for them to run | 16:38 |
* JayF notes julia is more of a ci expert than I am | 16:38 | |
TheJulia | the other file has the actual definitions | 16:38 |
JayF | so if anything she tells you conflicts with me, I'd bet she's right :P | 16:38 |
TheJulia | So you would create a new definition with a new name in the one file, and then add that new name in the list of jobs to run. | 16:39 |
cid | I see. | 16:42 |
TheJulia | Hi, Weather, please make up your mind and stop it with the wind. I don't want my hand to be hurting today. | 16:43 |
opendevreview | Merged openstack/ironic master: doc: Add extra context around release mapping https://review.opendev.org/c/openstack/ironic/+/917048 | 16:43 |
JayF | ironic-standalone will be likely the best one to start with | 16:54 |
cid | I remember you said that, I will make a copy, tweak and test | 16:57 |
TheJulia | the standalone jobs have *tons* of tests, but they *are* definitely far less complicated than the full openstack stack | 16:57 |
TheJulia | In other words, don't take it failing out of the gate as your heading down the wrong path, it will fail, the challenge is to move it beyond that first failure | 16:58 |
TheJulia | ... if that makes sense :) | 16:58 |
opendevreview | cid proposed openstack/ironic master: Remove special treatment of .json for API objects https://review.opendev.org/c/openstack/ironic/+/913467 | 16:58 |
TheJulia | (The plus of this is it becomes a more focused engagement than trying to just make everything greeeeeeeeeen | 16:58 |
cid | it does make sense | 17:00 |
JayF | +++ a big rule of devops is changing the error is a success, you just have to keep going until you get 'em all unlayered | 17:02 |
JayF | there's going to be a long tail on this ARM project I suspect, but that's just a sign of the problem's complexity than anything else | 17:02 |
TheJulia | heh, That is an excellent point | 17:02 |
TheJulia | I'd almost change the test regular expression just to be a single test and then expand it from there | 17:02 |
TheJulia | The plus side is faster feedback then | 17:03 |
TheJulia | The jobs take a while to run in general, and fast feedback is always a plus | 17:03 |
JayF | honestly I'd expect devstack setup to crash out the first few cycles | 17:03 |
TheJulia | quite likely | 17:03 |
JayF | so that might be early overoptimization | 17:03 |
TheJulia | sort of like it did on VM creation | 17:03 |
TheJulia | due to the emulator path | 17:03 |
TheJulia | NobodyCam: fyi, the wind is presently forecast to be return to "normal" conditions on Saturday. | 17:07 |
cid | I will not only change the regex to start with one test and walk my way up, I will comment out every other gate jobs | 17:16 |
TheJulia | Excellent! | 17:17 |
* dtantsur watches BMO doing servicing \o/ | 17:32 | |
TheJulia | oooooh ahhhhhhhh | 17:32 |
dtantsur | https://github.com/metal3-io/baremetal-operator/pull/1689 if you're into reading convoluted Go | 17:33 |
TheJulia | Just limited to firmware and bios settings right? | 17:34 |
TheJulia | ... if I'm groking what I'm skimming in the patch correctly | 17:34 |
dtantsur | TheJulia: actually, only BIOS settings in this proof of concept - firmware updates will need a bit of work on the Ironic side | 17:36 |
dtantsur | do you have anything else in mind? | 17:36 |
TheJulia | Off hand, no. I guess I've got this idea that something like snapshooting might be really cool one day, but that is totally squarely inside of ironic's box to solve first | 17:37 |
TheJulia | settings and eventually firmware *are* kind of the major pieces for now | 17:37 |
dtantsur | *nod* | 17:38 |
TheJulia | I think we'll need to address child devices and deployment of them and chaining all that together | 17:38 |
TheJulia | but... one step at a time | 17:38 |
dtantsur | TheJulia: we have a generic "please support DPUs" epic downstream, but it's soooo underspecified at this point | 17:38 |
TheJulia | I know, trying to move that needle | 17:39 |
dtantsur | +++ | 17:39 |
JayF | TheJulia: really at this point, snapshotting is a hardware manager | 18:02 |
JayF | TheJulia: and maybe a step template once those exist | 18:02 |
TheJulia | oh, absolutely | 18:03 |
JayF | if someone came to us with the feature ask, we could lay out a reasonable implementation path | 18:03 |
JayF | that could even end with nova support for it tbh | 18:03 |
TheJulia | The ask has sort of surfaced before, the problem was credential management related | 18:03 |
TheJulia | and then modeling of *what* to snap | 18:03 |
JayF | sensible questions, but ones that could be answered (e.g. default to root device as determined by hints on the node) if we had a concentrated effort | 18:04 |
TheJulia | yeah, that was always the easy one ;) | 18:06 |
TheJulia | I think we stalled on the model that we basically thought we needed the user to submit the request with application credentials | 18:06 |
TheJulia | so there is a one time app key to be used to upload to say swift or whatever | 18:06 |
JayF | I was thinking one could route around that by having a conductor as a go-between | 18:08 |
JayF | but none of this matters unless we're going to do it; we have things we're actually going to do that I need to go write up :D | 18:09 |
TheJulia | Might be good to vision, I guess | 18:10 |
TheJulia | but yeah | 18:10 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!