| JayF | ack; I'll look into this for ipa-builder as a quick win. These check-image jobs mainly just run to pass today, having them output an artifact would be helpful information | 00:01 |
|---|---|---|
| clarkb | as an alterative you could have the jobs validate them automatically rather than doing it manually? | 00:01 |
| clarkb | I don't know what that looks like for those images but we definitely have dib build images in nodepool then check nodepool can boot and ssh into them for example | 00:02 |
| JayF | we run real-CI against them in some places | 00:02 |
| JayF | e.g. Ironic Python Agent runs check-image jobs and also has jobs that perform the same build as part of a devstack run and tests them | 00:03 |
| JayF | in this case, it's ipa-builder, we try not to saddle that with a thousand tempest jobs | 00:03 |
| clarkb | also because I feel this is a persistent openstack problem I think its worth noting that I personally think projects should stop trying to ship the foo tool on distro X, Y, Z, and Ω if the thing is expected to be pulled off the shelve and used as is its probably best to have one "distribution" that is well understood, tested, and expected to work | 00:04 |
| clarkb | and even more so I'm not sure why there is value in having both a bullseye and a bookworm image for ipa | 00:05 |
| JayF | ipa-builder vs ipa is meaningful difference there | 00:09 |
| JayF | and usually if we test an image there it's because we have someone who knows they use it | 00:10 |
| JayF | honestly I kinda agree with you somewhat philosophically, but because I need orange painted sheds, other people need red painted sheds, and someone else needs their painted a different color, I think it's nice that we try to be more agnostic | 00:10 |
| JayF | it's one piece of the always-ongoing struggle for openstack-itself to be a product and not just the base for a product, if you get what I mean? | 00:11 |
| clarkb | ya I guess from my perspective we/openstack has spent a lot of time over the years trying to solve problems multiple times (once for each distro) rather than trimming the list where it makes sense. Some ephemeral tool that is used to splat down bytes on a drive for baremetal seems liek a place where the underlying distro and python doesn't matter as long as the tool functions | 00:11 |
| clarkb | similarly for say osa or kolla they provide container images containing openstack. I don't actually care what linux those containers based on as long as the openstack contained in them works | 00:11 |
| clarkb | and from experience going from multiple distro support to single distro support drastically simplifies things and makes it easier to produce functional tools when you can get away with it | 00:13 |
| JayF | To some extent, ensuring our dependency list is accurate is a big part of the output/value that something like ipa-builder brings. Even folks who don't use dib to build IPA images often look at that as a reference implementation. | 00:17 |
| JayF | I'm glad that we ensure that value is seen regardless of OS (at least commonly-used ones in our userbase) | 00:18 |
| mnasiadka | Well, Kolla builds three distros because there are people needing different color sheds (as in security requirements, their own weird feeling of safety and other things that we don’t have a clue about). | 10:00 |
| mnasiadka | We thought of moving all api services to one minimal distro - but there are not enough contributors to pull it off in a sensible timeframe. | 10:00 |
| jrosser | Regarding OSA there seems to be a misconception that we build container images, and thats just not the case | 10:05 |
| jrosser | LXC containers are equatable to VM or hosts, rather than docker/podman-esque application containers | 10:05 |
| jrosser | *build and distribute, i mean | 10:06 |
| ralonsoh | hi folks, I have a CI job that "requires" another project, to test usually with master branch | 11:11 |
| ralonsoh | there is an issue and I want to test with other commits | 11:12 |
| ralonsoh | something like this is correct? | 11:12 |
| ralonsoh | - name: github.com/svinota/pyroute2 | 11:12 |
| ralonsoh | override-checkout: abace8d4e54b2f462a1c50e69143eef8a2bc6f20 | 11:12 |
| ralonsoh | using the hash in override-checkout | 11:12 |
| ralonsoh | the problem is that is actually don't see in the logs what exact version/hash has been installed | 11:12 |
| frickler | ralonsoh: I think that that should work, do you have a pointer to a job result so I could check it? | 11:20 |
| ralonsoh | one sec | 11:20 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/942695 | 11:20 |
| ralonsoh | still in zuul, but there are some results | 11:21 |
| ralonsoh | https://zuul.opendev.org/t/openstack/build/4429d03dc43342f692d2c16b0b4f4f13 | 11:21 |
| frickler | it looks like zuul is using the master branch for that repo, not sure why your override doesn't work, let me dig a bit more | 11:28 |
| frickler | hmm ... zuul docs only talk about branches or tags as ref, so possibly using a SHA isn't supported | 11:33 |
| ralonsoh | hmmm that's a problem | 12:05 |
| ralonsoh | frickler, do you know who is the most appropriated person to ping? | 12:21 |
| ralonsoh | I'm checking the zuul code and that should work too | 12:21 |
| ralonsoh | in any case, I've pushed a new PS with a broken hash (doesn't exist in the code) | 12:22 |
| ralonsoh | that will confirm if zuul is NOT using it | 12:22 |
| frickler | ralonsoh: either wait for some other infra-root to be around or try to ping corvus either in #opendev or in the zuul matrix channel | 12:50 |
| ralonsoh | sure thanks! | 13:29 |
| opendevreview | Ron Stone proposed openstack/project-config master: Update StarlingX docs promote job for R10 release https://review.opendev.org/c/openstack/project-config/+/942795 | 13:43 |
| opendevreview | Merged openstack/project-config master: Update StarlingX docs promote job for R10 release https://review.opendev.org/c/openstack/project-config/+/942795 | 15:03 |
| clarkb | jrosser: lxc runs an image whether we want to call that a container or a vm image though. Are you not testing such artifacts for different distros (I thought you were but maybe I misread the CI setup). Also I tried to make it clear that its a personal opinion that doing that extra work is not necessary. Clearly people disagree because its done in a lot of places around | 15:58 |
| clarkb | openstack. But I know for opendev related stuff we were able to simplify dramatically when we trimmed the distro list to one. And the places where we don't (building CI test images, openafs, and a couple others continue to be an outsized headache. For example centos 10 stream with its requirement or network manager now and removed compatibility layers and x86_64-v3 baseline | 15:58 |
| clarkb | cpu requirement) | 15:58 |
| clarkb | if it were up to me I would avoid all those problems entirely everywhere that I possible can | 15:58 |
| jrosser | clarkb: it's been incorrectly stated several times that osa builds and ships artefacts | 15:59 |
| jrosser | that was in a discussion about if certain software licences were OK in kolla or not | 16:00 |
| clarkb | jrosser: right but my point is less about building artifacts and more about tryinng to test N combinations when 1 would be fine in some situations (definitely not all) | 16:00 |
| jrosser | well, similar to kolla, end users are opinionated about what OS they want to run | 16:00 |
| clarkb | and I guess if you aren't publishing concrete artifacts there isn't a singular entity you can point people to so they are expceted to build it up on $localplatform? | 16:01 |
| jrosser | thats what the tooling does automatically | 16:02 |
| clarkb | got it | 16:02 |
| jrosser | but its building nothing but a base rootfs with debootstrap | 16:03 |
| jrosser | and then treating that as a host in the ansible inventory | 16:03 |
| fungi | and in theory kolla could take the same approach (aiui first and foremost they produce recipes for building container images, the images they build and publish aren't supposed to be for production use) | 16:03 |
| jrosser | as such the containers that may exist can be entirely exchanged for bare metal hosts | 16:04 |
| jrosser | so you can have any of the services as bare metal or some other VM you have just by settings that in the ansible vars | 16:05 |
| clarkb | oh interesting. Does that replace/update the underlying system disk then reboot into the newly built out system? | 16:07 |
| jrosser | no, its up to the deployer to get their bare metal environment setup however they want first | 16:07 |
| clarkb | I think one of the very early openstack infra ci systems did something similar and kexec'd into new fresh environments using a RO partiation on baremetal nodes | 16:07 |
| JayF | I also think tied up in this discussion is an unstated reality for many people; even if it's implied in the discussion: | 16:58 |
| JayF | if you gave a kolla container (or build code for a container) built against $distroA, but internal policy is $distroB, I can't run that container; no matter how well it's "applicationized" | 16:59 |
| JayF | or appliancized or whatever | 16:59 |
| JayF | (I've even worked 2x places where that policy shifted and we had to migrate cloud from distroA->distroB, too, including things like IPA ramdisks which distro doesn't /shouldn't matter) | 17:00 |
| clarkb | which is unfortunate because I'm sure that in many cases the same companies will happily buy appliances from vendors like cisco and bigip and f5 for networking and firewalls and so on | 17:00 |
| clarkb | and don't apply the same requirements to their deployments | 17:00 |
| JayF | I'm not saying I think it's a good policy, I'm saying that most folks are trying to provide a service to their business under a set of parameters they don't have control over | 17:01 |
| JayF | This is interesting, and is going to be added to my OIF Days talk: this is kinda an anchor that internal clouds wear that external vendors/clouds don't have to | 17:01 |
| jrosser | the Internal policy thing is very real even if it’s not policy as such, investment in tooling often makes a distro choice quite sticky | 17:08 |
| fungi | it's just interesting to see that extend into the implementation details of a container, which in theory has a fairly standardized interface to the host system and is intentionally isolated | 17:09 |
| jrosser | we were just discussing today the unfortunate divergence between the Debian and Ubuntu pxe installers, one of the features we quite like is only possible with one of those | 17:10 |
| jrosser | for my deployments that then drives the choice of distro pretty heavily | 17:11 |
| *** dviroel is now known as dviroel_bbl | 21:31 | |
| *** dviroel_bbl is now known as dviroel | 23:17 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!