15:00:25 <SamYaple> #startmeeting loci
15:00:25 <openstack> Meeting started Fri Aug 31 15:00:25 2018 UTC and is due to finish in 60 minutes.  The chair is SamYaple. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:29 <openstack> The meeting name has been set to 'loci'
15:00:31 <SamYaple> there it is
15:01:32 <SamYaple> This is probably going to be more like an office hours everyweek
15:01:54 <SamYaple> I added two things to the agenda, #link https://wiki.openstack.org/wiki/Meetings/LOCI
15:02:08 <SamYaple> I started a Stien ptg etherpad for LOCI
15:02:49 <SamYaple> #link https://etherpad.openstack.org/p/openstack-loci-ptg-stien
15:03:58 <SamYaple> While we do have some historical information with plans for versioning, we can discuss it anew at the PTG and come to an agreement before implemntation
15:04:43 <SamYaple> Anyone is welcome to add bits to the etherpad, but the primary topics we need to solve are around versioning and testing/integration with deployment projects like Kolla/OSH
15:06:43 <evrardjp> versioning, you mean branching?
15:07:11 <SamYaple> No, this would be avoiding branching
15:07:32 <SamYaple> So right now master can build Newton->HEAD of Master
15:08:19 <SamYaple> 1.0.0 would be able to build all that, and potential future versions. But what happens when we have to drop Newton/Ocata/etc is what the versioning could control.
15:08:40 <evrardjp> well I'd like to discuss this, as I am not sure it actually can reliably in gates, but I am all ears
15:09:06 <SamYaple> absoulutely
15:09:29 <SamYaple> ive discussed this with a few peoples around infra, describing the issue and the workaround
15:09:39 <SamYaple> so let me reiterate the issue now
15:10:12 <SamYaple> If we do backports, we will need to backport most everything we do. Most of our patches are "thing A change upstream, change B in container" and that normally doesnt affect the code
15:10:51 <SamYaple> so 1.1.0 would be able to deploy 15.1.3 and 15.1.0 (for example), but 1.0.0 might only be able to deploy 15.1.0
15:11:24 <evrardjp> backporting is not too hard, but it's a burden I agree.
15:11:47 <evrardjp> By not branching I have the impression you'll increase technical debt
15:11:53 <SamYaple> we do also have a small community, and that community used Newton and Ocata and Pike (as well as Queens and Rocky, but im not sure in production)
15:11:54 <evrardjp> just having conditions that pile up
15:12:24 <SamYaple> ah, well thats the thing. we wont have conditionals unless they are required to support the supported branches
15:12:53 <evrardjp> do we think that should happen?
15:13:05 <evrardjp> I mean we are talking about images here, not deploy tooling
15:13:18 <evrardjp> so images almost never will have a change
15:13:19 <SamYaple> i definetely do, yes
15:13:30 <evrardjp> ok can you give me an example?
15:13:31 <SamYaple> right, but the ability to *build* them will
15:13:49 <SamYaple> if we build Newton right now, dont backport changes, in a month you *cannot* rebuild Newton
15:13:59 <evrardjp> I don't see why rocky shuld be built differently than newton
15:14:15 <evrardjp> SamYaple: that's a problem, but I don't understand why
15:14:29 <evrardjp> the process itself doesn't change, right?
15:14:41 <evrardjp> So the only moving target is code, which is restricted by shas
15:14:49 <SamYaple> not if we keep patching it for changes in pip/pypi/infra/openstack/etc
15:14:58 <SamYaple> then it builds the same way
15:15:03 <evrardjp> I am very confused
15:15:13 <SamYaple> if we dont backport through 5 branches, newton will be broken due to upstream changes
15:15:20 <SamYaple> changes in upper-constraints break things
15:15:30 <evrardjp> yeah but it doesn't change the process
15:15:50 <SamYaple> not for backporting, causes 5x the work and a mixed state of "stable" for all "stable" versions
15:16:04 <evrardjp> what changes are inputs, i.e. the requirements sha, the version of the series of dependencies
15:16:20 <SamYaple> thats not all, no
15:16:47 <SamYaple> newton use pycrypto, ocata cryptography (those might be switched)
15:16:51 <SamYaple> little stuff like that
15:18:33 <SamYaple> there is about a year of conversation leading up to this, so perhaps im glossing over some stuff
15:18:54 <SamYaple> but the desire is something like `docker build --build-arg PROFILES="newton"`
15:19:06 <SamYaple> where that is changable and has all the selectors
15:20:02 <SamYaple> we are building less of an openstack project and more of a openstack packager. No reason that packager can't be a single version and allow us to support many versions of openstack without adding overhead
15:23:27 <SamYaple> evrardjp: if you want to flip it around, what are we gaining towards our goals with stable/branching?
15:23:39 <evrardjp> sorry I am in 2 other meetings
15:23:40 <evrardjp> :(
15:23:47 <SamYaple> no problem, im also doing work :)
15:31:24 <evrardjp> I think it's a discussion we should have with more eyes :)
15:32:17 <SamYaple> We will
15:32:26 <SamYaple> Also, closing the office hours, but ill still be around!
15:32:27 <evrardjp> In this case I think it's more semantically correct to have branching :)
15:32:32 <SamYaple> #endmeeting