15:00:25 #startmeeting loci 15:00:25 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:29 The meeting name has been set to 'loci' 15:00:31 there it is 15:01:32 This is probably going to be more like an office hours everyweek 15:01:54 I added two things to the agenda, #link https://wiki.openstack.org/wiki/Meetings/LOCI 15:02:08 I started a Stien ptg etherpad for LOCI 15:02:49 #link https://etherpad.openstack.org/p/openstack-loci-ptg-stien 15:03:58 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 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 versioning, you mean branching? 15:07:11 No, this would be avoiding branching 15:07:32 So right now master can build Newton->HEAD of Master 15:08:19 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 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 absoulutely 15:09:29 ive discussed this with a few peoples around infra, describing the issue and the workaround 15:09:39 so let me reiterate the issue now 15:10:12 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 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 backporting is not too hard, but it's a burden I agree. 15:11:47 By not branching I have the impression you'll increase technical debt 15:11:53 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 just having conditions that pile up 15:12:24 ah, well thats the thing. we wont have conditionals unless they are required to support the supported branches 15:12:53 do we think that should happen? 15:13:05 I mean we are talking about images here, not deploy tooling 15:13:18 so images almost never will have a change 15:13:19 i definetely do, yes 15:13:30 ok can you give me an example? 15:13:31 right, but the ability to *build* them will 15:13:49 if we build Newton right now, dont backport changes, in a month you *cannot* rebuild Newton 15:13:59 I don't see why rocky shuld be built differently than newton 15:14:15 SamYaple: that's a problem, but I don't understand why 15:14:29 the process itself doesn't change, right? 15:14:41 So the only moving target is code, which is restricted by shas 15:14:49 not if we keep patching it for changes in pip/pypi/infra/openstack/etc 15:14:58 then it builds the same way 15:15:03 I am very confused 15:15:13 if we dont backport through 5 branches, newton will be broken due to upstream changes 15:15:20 changes in upper-constraints break things 15:15:30 yeah but it doesn't change the process 15:15:50 not for backporting, causes 5x the work and a mixed state of "stable" for all "stable" versions 15:16:04 what changes are inputs, i.e. the requirements sha, the version of the series of dependencies 15:16:20 thats not all, no 15:16:47 newton use pycrypto, ocata cryptography (those might be switched) 15:16:51 little stuff like that 15:18:33 there is about a year of conversation leading up to this, so perhaps im glossing over some stuff 15:18:54 but the desire is something like `docker build --build-arg PROFILES="newton"` 15:19:06 where that is changable and has all the selectors 15:20:02 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 evrardjp: if you want to flip it around, what are we gaining towards our goals with stable/branching? 15:23:39 sorry I am in 2 other meetings 15:23:40 :( 15:23:47 no problem, im also doing work :) 15:31:24 I think it's a discussion we should have with more eyes :) 15:32:17 We will 15:32:26 Also, closing the office hours, but ill still be around! 15:32:27 In this case I think it's more semantically correct to have branching :) 15:32:32 #endmeeting