| opendevreview | Merged openstack/ironic-prometheus-exporter stable/ussuri: CI: Various fixes https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/860183 | 02:31 |
|---|---|---|
| *** mnasiadka_ is now known as mnasiadka | 06:29 | |
| arozman | Hi Ironic! | 07:45 |
| rpittau | good morning ironic! o/ | 08:02 |
| dtantsur | TheJulia: hi! you seem to be familiar with IPv6 PXE, do you know why we hardcoded 343 (Intel) here? https://github.com/metal3-io/ironic-image/blob/d79c07796a8ef43ad25fe741cab2ee20bd4e7f5b/ironic-config/dnsmasq.conf.j2#L40 | 10:06 |
| dtantsur | JayF, stevebaker[m], Bifrost is interesting, it tends to rot quite quickly because of all the distro changes.. | 10:28 |
| dtantsur | W has CentOS 8 in its jobs, which is not functioning any more | 10:29 |
| dtantsur | kubajj: maybe try removing UUID first and get another run? I have a feeling the tests may be misreporting the actual failure.. | 11:34 |
| kubajj | dtantsur: Ok, will do | 11:35 |
| kubajj | dtantsur: It seems that the error remains the same (except now it doesn't complain about index uuid). | 12:15 |
| dtantsur | kubajj: oookay, let's upload the new patch through | 12:19 |
| opendevreview | Jakub Jelinek proposed openstack/ironic master: WIP: Implements node inventory: database https://review.opendev.org/c/openstack/ironic/+/862569 | 12:20 |
| viks__ | Hi, in the normal vm's i can create a snapshot of the instance and in case any backend node failure, i can recreate the instance from the snapshot.. Is it somehow possible to achieve the same in case of baremetal instance? | 13:18 |
| opendevreview | Harald Jensås proposed openstack/ironic master: [WIP] Use ORM relationship for ports node_uuid https://review.opendev.org/c/openstack/ironic/+/862933 | 13:19 |
| TheJulia | good morning | 13:23 |
| TheJulia | dtantsur: no idea... | 13:23 |
| TheJulia | w/r/t enterprise 343 | 13:24 |
| TheJulia | viks__: ... So from an automation standpoint, Ironic does not support snapshots | 13:25 |
| TheJulia | viks__: but, you can image disks, it just requires knowledge of how to do it and package the contents. The downside is the size of the resulting disks sometimes | 13:25 |
| viks__ | TheJulia: ok.. thanks.. one more question.. suppose i have my baremetal instances in region A and region B.. so is there a way if i can migrate the baremetal instance node from region A to B and in region B and start accessing it from B? | 13:30 |
| TheJulia | viks__: not really. I mean, you could say "hey, put that server on a truck and move it to the other data center", but there is no automation to capture that system state and move it for you | 13:32 |
| viks__ | TheJulia: Ok thanks.. | 13:32 |
| dtantsur | TheJulia: good morning. okay, I wonder if it was just copied from somewhere.. | 13:35 |
| TheJulia | I've never seen that done before quite like that, but enterprise 343 may be more referring to intel architecture ? | 13:38 |
| TheJulia | i suspec thte question is what does the field it is matching serve | 13:38 |
| JayF | dtantsur: https://zuul.opendev.org/t/openstack/config-errors majority of them left for Ironic are because old-old-old bugfix branches have queue:Ironic | 13:54 |
| JayF | except that link is dead now (?) | 13:55 |
| JayF | it's the right link; it's just busted right now | 13:55 |
| JayF | from https://etherpad.opendev.org/p/zuul-config-error-openstack | 13:55 |
| dtantsur | ack, will check when I can | 14:12 |
| JayF | dtantsur: apparently the JS renderer is broke; you have to hit the bell in the top corner, but the info is there lol | 14:37 |
| dtantsur | JS amiright? | 14:37 |
| JayF | only thing worse is actual-java | 14:37 |
| dtantsur | true | 14:38 |
| dtantsur | so, everything I can find is about queue, which is easy to fix if it makes infra people upset | 14:38 |
| JayF | I think, bluntly, that's a little naive given I've been personally fighting, along with TheJulia at times, to get these patches through *actually maintained CI* | 14:42 |
| JayF | I also don't think it's OK or good for us to have a dozen open dead branches when, in all other openstack projects, it's a baked-in assumption that a branch existing means it's maintained | 14:42 |
| JayF | I don't wanna retire things that you all are using (and I saw on the list, and I responded), but I also am not onboard to just leave these dangling open forever and ever with no end | 14:43 |
| JayF | I find it hard to believe that anyone is using an Ironic bugfix branch from 5 major version ago, for instance, lol | 14:44 |
| dtantsur | yeah, and I don't think we will too | 14:48 |
| dtantsur | rpittau: wdyt about bugfix branches lifetime? | 14:48 |
| JayF | Like I said on list, I'm even OK with explicitly saying "this bugfix branch represents code shipped in $product and will be maintained while $product is maintained" | 14:49 |
| JayF | like, that's maybe a little more on the nose than we'd typically do | 14:49 |
| rpittau | mmmm as far as I'm concerned I really care about 4 of them at the moment :) | 14:50 |
| JayF | I just want there to be documented upstream method to our madness, which at least somewhat controlled by your downstream usage | 14:50 |
| rpittau | I think what we have int he etherpad now is pretty accurate | 14:50 |
| TheJulia | which etherpad? | 14:50 |
| rpittau | sorry, the whiteboard | 14:51 |
| rpittau | L49 | 14:51 |
| rpittau | and below | 14:51 |
| JayF | https://etherpad.opendev.org/p/IronicBugfixBranchCleanup is based on that | 14:52 |
| JayF | so I think my updated version, with the "needs to have branch retired" list, is accurate | 14:52 |
| rpittau | let me double-check that | 14:52 |
| rpittau | JayF: yep, that's perfect IMHO | 14:53 |
| dtantsur | btw the notion of vendor-sponsored branches is not new, at least the kernel does it | 14:53 |
| rpittau | spoiler alert: next april we should be able to retire 18.1, 8.1 and 10.7 | 14:54 |
| dtantsur | I do agree that we should probably put a cap on how long a branch is supported even in this mode. rpittau thoughts? | 14:54 |
| dtantsur | rpittau: or to phrase it differently: can we declare how long we want to maintain a branch upstream even if the downstream release is in some sort of an extended support mode? | 14:54 |
| JayF | I mean, I'm completely game for all that; the pieces I think are missing are: 1) being more explicit about why and what branches are supported and 2) an upstream understanding of life-cycle for these (e.g. RH sponsors these branches thru 4/2023 is exactly what I'd like to be able to say) | 14:54 |
| dtantsur | I think we should take https://specs.openstack.org/openstack/ironic-specs/specs/approved/new-release-model.html, adjust it to match the reality and put to the docs. | 14:55 |
| rpittau | dtantsur, JayF, from what I know the standard timeframe of downstream support is roughly 18 months | 14:55 |
| dtantsur | including, yeah, vendor commitment to maintain certain branches longer than they're supposed to | 14:55 |
| JayF | dtantsur: that's what I'm working towards :D | 14:55 |
| JayF | dtantsur: I made the thread partially to tease out the preexisting consensus into something explicit so we could document it | 14:56 |
| rpittau | does 18 months sound reasonable ? | 14:56 |
| JayF | Let me put it this way: if you'd be doing the work to maintain it downstream if it wasn't upstream; I'd rather it be upstream | 14:56 |
| JayF | so whatever timeline that requires is reasonable, as long as the CI stays alive and we document it :) | 14:56 |
| rpittau | JayF: the longest I saw was 24 months downstream and it was an exception | 14:56 |
| dtantsur | 18 months is how long "normal" stable branches are maintained, right? | 14:57 |
| rpittau | dtantsur: correct | 14:57 |
| dtantsur | rpittau: I think we can ignore our long-term support release for the sake of upstream sanity | 14:57 |
| dtantsur | (we WILL need to figure out how to backport things to them downstream, but that shouldn't be the upstream headache IMO) | 14:57 |
| rpittau | mmmm ok, so full support is 6 months | 14:57 |
| rpittau | I lied | 14:58 |
| rpittau | 8 months | 14:58 |
| rpittau | sorry | 14:58 |
| dtantsur | LIER! | 14:58 |
| rpittau | :P | 14:58 |
| dtantsur | sorry, JayF, we're still trying to figure out how long we support our product :D | 14:58 |
| * dtantsur reads https://access.redhat.com/support/policy/updates/openshift | 14:58 | |
| JayF | As I've offered many times, I'm willing to be the bad cop you blame all your problems on if it helps downstream lol | 14:58 |
| rpittau | the support likes changing :) | 14:58 |
| JayF | "this new PTL is a real hardass, he's demanding we [checks notes] know how long we support products" | 14:59 |
| JayF | lol | 14:59 |
| dtantsur | :D | 14:59 |
| dtantsur | okay, so full+maintenance support is 18 months, I suggest we definitely do not go beyond that upstream | 14:59 |
| rpittau | jokes aside, standard support is 8 months, extended maintenance is 18 months, if I can count correctly | 14:59 |
| JayF | 18 months would be like Wallaby, which is already feeble | 15:00 |
| rpittau | yeah | 15:00 |
| rpittau | I don't mind keeping track and retiring old bugfix branches when it's the time | 15:00 |
| JayF | My thing is, I want it somewhat written down, not just personal responsibility | 15:01 |
| dtantsur | I agree with Jay, this makes us better prepared | 15:01 |
| JayF | because if upstream has a maintained branch; we can't leave the details of how long that branch is supported as downstream-only knowledge | 15:01 |
| rpittau | let's write it down then, I can take care of that, just need to find the right place | 15:01 |
| JayF | I'm working under the (likely false but good to pretend it's true) assumption that the bugfix branches hold value upstream outside of making RH's life easier | 15:01 |
| dtantsur | rpittau: my intuition is to say "12 months" for OCP-supported branches (and we'll deal with the remaining 6 months + EUS ourselves) | 15:02 |
| JayF | that assumption makes it much easier to support bugfix branches with upstream hats on :D | 15:02 |
| dtantsur | IIRC community support for bugfix branches is 6 months per my spec | 15:02 |
| JayF | We don't communicate that through actual branch EOL, like we would for stable branches | 15:02 |
| rpittau | dtantsur: yes, it was 6 months, we cheated | 15:02 |
| dtantsur | we did indeed | 15:03 |
| JayF | and if we did, we'd probably break your downstream given what I'm hearing now lol | 15:03 |
| dtantsur | I don't think we actually EOL stable branches too | 15:03 |
| JayF | which is why I'm asking questions instead of just going ka-pow because I don't think that doc aligns with reality | 15:03 |
| dtantsur | at least at some point we just let them stay in EM forever | 15:03 |
| JayF | dtantsur: we just EOL'd Q/R/S | 15:03 |
| dtantsur | nice! | 15:03 |
| JayF | dtantsur: and stevebaker[m] and TheJulia are talking about doing T/U/V as well | 15:03 |
| JayF | because CI is so busted on them | 15:04 |
| dtantsur | rpittau: V going away will mean we'll need to figure out 4.7, so this question is timely | 15:04 |
| rpittau | 4.7 is gone | 15:04 |
| JayF | I am onboard for keeping V a little longer too if we can fix CI | 15:04 |
| dtantsur | rpittau: oh my sweet summer child ;) | 15:04 |
| rpittau | :D | 15:04 |
| JayF | for T/U/V I sorta wanna take an "as needed by CI" approach | 15:04 |
| dtantsur | I'll explain you downstream | 15:04 |
| TheJulia | dtantsur: I was thinking the exact same thing | 15:04 |
| JayF | e.g. no desire to EM->EOL Victoria unless CI is demanding it | 15:05 |
| JayF | but Train seems already lost, and I think Ussuri is getting close to that point w/CI | 15:05 |
| TheJulia | I *think* we got most of the usssuri stuff happy, but that might have changed in the last ?week or two? | 15:06 |
| JayF | not all of it, but if it's doable we should do it \o/ | 15:06 |
| JayF | TheJulia: https://review.opendev.org/c/openstack/ironic-lib/+/860176 you're right, this is the only U patch still needed to fix CI | 15:07 |
| JayF | TheJulia: we did remove a job on ironic-prom-exporter to make it land in that one's ussuri tho | 15:07 |
| TheJulia | ohh, that might just work on rehceck | 15:07 |
| * JayF kicks it | 15:08 | |
| TheJulia | Oh, just did as well | 15:09 |
| * TheJulia shrugs | 15:09 | |
| JayF | https://review.opendev.org/c/openstack/ironic-lib/+/860175 is all that's left for victoria queue param stuff too, I'm going to kick it as well | 15:11 |
| * TheJulia raises an eyebrow | 15:13 | |
| TheJulia | I guess because centos8? | 15:13 |
| JayF | I didn't kick that one | 15:14 |
| JayF | it looks actual-broken | 15:14 |
| TheJulia | yeah | 15:18 |
| TheJulia | steve updated it to depend on the requirements change, but no dice it looks like | 15:18 |
| TheJulia | I guess on a plus side, is how often have we *actually* needed to backport ironic-lib fixes | 15:19 |
| TheJulia | ... in recent history | 15:19 |
| JayF | Yep. This is one of those cases where I'm probably OK just removing the integration testing | 15:24 |
| JayF | I'll put it this way: I think for things the age of V, if we can keep it going with just unit tests and then be judicious about what we backport we can get more longevity | 15:24 |
| TheJulia | agreed | 15:25 |
| JayF | I'm going to update that patch to do just that, then | 15:26 |
| TheJulia | ok | 15:26 |
| opendevreview | Jay Faulkner proposed openstack/ironic-lib stable/victoria: CI: Various fixes https://review.opendev.org/c/openstack/ironic-lib/+/860175 | 15:28 |
| TheJulia | JayF: remember mentioning hardware assisted software raid? | 15:43 |
| TheJulia | during the PTG I think? | 15:43 |
| JayF | Intel RSTe! | 15:44 |
| JayF | I knew it well | 15:44 |
| TheJulia | well, VROC now | 15:44 |
| JayF | I changed that o to an e because any knowledge I had it in a rackspace wiki | 15:44 |
| JayF | lol | 15:44 |
| TheJulia | heh | 15:44 |
| TheJulia | Anyway, as of this morning, I have a customer asking for it | 15:44 |
| TheJulia | lolz | 15:44 |
| JayF | so if I say it, it comes | 15:45 |
| JayF | I always have wondered how our bare metal provisioning system would hold up with a million dollars on top of it | 15:45 |
| JayF | <.< >.> | 15:45 |
| opendevreview | Merged openstack/bifrost master: Fix initial python/venv dependencies https://review.opendev.org/c/openstack/bifrost/+/861534 | 15:45 |
| opendevreview | Merged openstack/bifrost master: Switching netstat to ss in report https://review.opendev.org/c/openstack/bifrost/+/861542 | 15:45 |
| opendevreview | Merged openstack/bifrost master: Remove remaining traces of Suse https://review.opendev.org/c/openstack/bifrost/+/861541 | 16:06 |
| rpittau | bye o/ | 16:39 |
| opendevreview | Harald Jensås proposed openstack/ironic master: Add port/portgroup list conductor groups filter https://review.opendev.org/c/openstack/ironic/+/862292 | 17:55 |
| opendevreview | Julia Kreger proposed openstack/ironic-specs master: Add a shard key https://review.opendev.org/c/openstack/ironic-specs/+/861803 | 18:35 |
| stevebaker[m] | good morning | 19:43 |
| opendevreview | Ebbex proposed openstack/bifrost master: Enable epel repository for more than CentOS https://review.opendev.org/c/openstack/bifrost/+/861082 | 23:05 |
| opendevreview | Ebbex proposed openstack/bifrost master: Move kpartx to dib_host_required_packages https://review.opendev.org/c/openstack/bifrost/+/861539 | 23:23 |
| opendevreview | Ebbex proposed openstack/bifrost master: Use a more traditional ansible approach to include_vars https://review.opendev.org/c/openstack/bifrost/+/855806 | 23:29 |
| opendevreview | Ebbex proposed openstack/bifrost master: Refactor use of include_vars https://review.opendev.org/c/openstack/bifrost/+/855807 | 23:29 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!