21:01:38 <jokke_> #startmeeting crossproject
21:01:38 <openstack> Meeting started Tue Sep 29 21:01:38 2015 UTC and is due to finish in 60 minutes.  The chair is jokke_. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:40 <anteaya> russellb: thankyou
21:01:42 <openstack> The meeting name has been set to 'crossproject'
21:01:43 <ttx> sdague: agree that it's not the board top priority.
21:01:47 <jokke_> courtesy ping for david-lyle flaper87 dims dtroyer johnthetubaguy rakhmerov
21:01:50 <jokke_> courtesy ping for smelikyan morganfainberg adrian_otto bswartz slagle
21:01:52 <jokke_> courtesy ping for adrian_otto mestery kiall jeblair thinrichs j^2 stevebaker
21:01:55 <jokke_> courtesy ping for mtreinish Daisy Piet notmyname ttx isviridov gordc SlickNik
21:01:58 <jokke_> courtesy ping for cloudnull loquacities thingee hyakuhei redrobot dirk TravT
21:02:01 <jokke_> courtesy ping for vipul lifeless annegentle SergeyLukjanov devananda boris-42 nikhil_k
21:02:04 <notmyname> here
21:02:05 <j^2> o/
21:02:05 <morgan> stevemar, ^
21:02:07 <david-lyle> o/
21:02:07 <stevebaker> \o
21:02:10 <jroll> \o
21:02:11 <SergeyLukjanov> o/
21:02:13 <Rockyg> o/
21:02:14 <smcginnis> o/
21:02:16 <devananda> o/
21:02:20 * morgan has delegated PTL things to stevemar where at all possible. but is lurking
21:02:21 * fungi wants a discourteous ping
21:02:23 <gordc> o/
21:02:24 <devananda> ping for jroll too
21:02:25 <jokke_> Good evening Ladies and Gentleman ... This is cross Project Weekly Meeting and I will be your host tonight ;)
21:02:27 <jeblair> jokke_: should probably go ahead and s/jeblair/fungi/ in the pingy thingy
21:02:30 <devananda> also, my battery may die any minute :(
21:02:31 <docaedo> o/
21:02:34 <fungi> pingy thingy!
21:02:34 <xarses> \o
21:02:35 <morgan> fungi OMG PING SHEESH (better?)
21:02:36 <jroll> devananda: double \o then!
21:02:40 <morgan> fungi ;)
21:02:40 * bknudson lurks
21:02:43 * EmilienM can't attend today, will catch up logs
21:02:43 <fungi> morgan: much
21:02:45 <elmiko> o/
21:02:53 <stevebaker> also s/stevebaker/skraynev/
21:02:54 <jroll> fungi: I prefer "annoying loud ping for..."
21:02:56 <jokke_> #topic Review of past action items
21:02:58 <fungi> hah
21:03:04 <lifeless> o/
21:03:30 * edleafe is creepily lurking
21:03:33 <stevemar> o/
21:03:42 <jokke_> ttx: only action item was for you last week around the deprecation communications
21:03:49 <skraynev_> o/
21:03:51 <ttx> I did communicate
21:03:58 * ttx picks up link
21:04:03 <jokke_> ttx: you have anything else around that or do we just move on?
21:04:09 * Rockyg slaps a lurking creep
21:04:27 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/075608.html
21:04:28 <bknudson> is there a quick summary of the deprecation policy we should follow?
21:04:33 <ttx> jokke_: nope I'm done
21:04:42 <edleafe> ouch!
21:04:44 <ttx> bknudson: you don't have to follow it
21:04:54 <jokke_> ttx: thanks
21:05:05 <ttx> bknudson: you can opt to declare that you will follow it.
21:05:16 <ttx> and by you I mean a project team
21:05:20 <bknudson> I follow it
21:05:22 <bknudson> oh
21:05:37 <ttx> it's about setting expectations downstream
21:06:11 <ttx> anyway, moving on, feel free to hiut me with questions about it
21:06:16 <ttx> hit*
21:06:19 <jokke_> ttx: has that been communicated towards downstream some other ways that the e-mail thread you posted?
21:06:21 * loquacities is here, running late sorry
21:06:56 <jokke_> #topic Team announcements (horizontal, vertical, diagonal)
21:07:05 <stevemar> diagonal eh
21:07:39 <ttx> jokke_: it will be once enough projects asserted it
21:07:44 <ttx> On the release management front, we have only *2 weeks* before the end of the liberty dev cycle
21:07:45 <jokke_> ttx: want to continue right away and give us latest from release?
21:07:51 <jokke_> ttx: thnx
21:07:51 <ttx> We have release candidates for all projects except Swift (ETA end of week)
21:07:58 <ttx> We'll have a number of RC respins to include updated translations next week
21:08:05 <ttx> We just branched the requirements stable/liberty branch, so we are no longer freezing requirements master branch.
21:08:16 <ttx> so all is progressing nicely so far
21:08:26 <ttx> we haven't broken anything yet
21:08:32 <stevemar> ttx: we will probably have rc2 for keystone
21:08:33 <jokke_> gr8
21:08:39 <bknudson> are we capping reqs in stable/liberty
21:08:43 <stevemar> sometime next week
21:08:49 <ttx> As usual, if you have a red flag, come bring it in #openstack-relmgr-office. We collect them
21:08:54 <clarkb> bknudson: no, the constraints file should handle that instead
21:09:04 <bknudson> nice.
21:09:09 <skraynev_> ttx: when will be window for rc2 ?
21:09:12 <ttx> stevemar: we can sync it with the translations last import
21:09:20 <stevemar> yup
21:09:20 <dhellmann> ttx: dims and mtreinish suggested branching grenade and devstack before making any more requirements changes
21:09:44 <ttx> skraynev_: depends on the case. The RC respins for translations will be all done by Thursday next week
21:09:46 <jungleboyj> o/
21:10:00 <mtreinish> dhellmann: well I should rephrase, we should do that except for where I proposed the reqs changes
21:10:02 <ttx> It's geenrally a good thing to have nothing on the last week
21:10:05 <mtreinish> because I'm impatient
21:10:10 <skraynev_> ttx: got it. thx
21:10:15 <dhellmann> mtreinish: some patches are more equal than others? :-)
21:10:16 <ttx> frees up time to handle crisis things
21:10:40 <clarkb> mtreinish: we also need to add in the new grenade branch stuff and apply liberty jobs to the branchless repos (like tempest)
21:10:46 <jokke_> jungleboyj: did you have something around the release or announcement to make?
21:11:04 <clarkb> mtreinish: is that something that QA wants to hanlde or should infra just go through and do it (note it should be almost identical to last cycles changes)
21:11:16 <mtreinish> clarkb: yeah, that goes hand in hand with doing all the branching stuff
21:11:24 <mtreinish> clarkb: either or, we'll be working on it together anyway
21:11:32 <clarkb> ok just let me know what I can help and we go from there
21:11:34 <fungi> i would be thrilled if qa tackles the job config changes for it, but am happy to assist
21:11:36 <mtreinish> there are changes on both sides that needs to happen
21:11:45 <mtreinish> fungi: I think I did them for liberty
21:12:00 <mtreinish> the tempest ones at least
21:12:09 <fungi> okay, great
21:12:22 <jungleboyj> jokke_: No, just running late.  Sorry.
21:12:29 <jokke_> jungleboyj: ah, welcome
21:12:32 <mtreinish> err s/libery/kilo it's all the same anyway
21:12:58 <jokke_> ok, lets move on
21:13:11 <jokke_> #topic Service Catalog Standardization
21:13:22 <jokke_> #link https://review.openstack.org/181393
21:13:53 <stevemar> ohhh nice
21:14:02 <jokke_> annegentle: stage is yours
21:14:12 <morgan> stevemar (this is why you needed to be here)
21:14:25 <stevemar> sdague and i had a nice chat about this topic in the morning ^
21:15:15 <jokke_> sdague: you wanna take this instead?
21:15:58 <stevemar> jokke_: we wrote some ideas here: https://etherpad.openstack.org/p/mitaka-service-catalog
21:16:03 <stevemar> #link https://etherpad.openstack.org/p/mitaka-service-catalog
21:16:25 <jokke_> stevemar: thnx for that
21:16:35 <dhellmann> that looks like two highlighter markers got into a fight
21:16:45 * dhellmann turns off author colors
21:16:46 <stevemar> basically we want to fix up for service catalog, theres a lot of weirdness in it
21:16:56 <morgan> dhellmann: hehehe
21:17:10 <bknudson> we have a spec and an etherpad? Are these the same thing?
21:17:19 <stevemar> bknudson: there is a spec
21:17:23 <stevemar> it's 1 link up
21:17:41 <stevemar> bknudson: https://review.openstack.org/#/c/181393/ you've reviewed it
21:17:44 <bknudson> is the etherpad going to wind up in the spec?
21:17:50 <morgan> bknudson: etherpad is more general brainstorm on what needs to happen, spec is moving towards finalized "plan"
21:17:50 <bknudson> they look different
21:17:56 <morgan> bknudson: afaik
21:17:58 <stevemar> bknudson: probably, we're just writing out ideas
21:18:06 <stevemar> morgan: ++
21:18:11 <jokke_> stevemar: yes that was the question, so are these two competing, completing each other or why two different mediums?
21:18:34 <stevemar> jokke_: no, etherpad was just a brain storm, sorry if it's causing confusion
21:18:42 <jokke_> ok thnx
21:19:04 <bknudson> ok... not sure why I was reviewing the spec then.
21:19:48 <bknudson> seems like we haven't decided what we're going to do so maybe the spec needs to start over again.
21:19:55 <stevemar> i think the pain point of the spec is that its really hard for application developers to trust what's in the service catalog
21:20:07 <jokke_> so the spec had 2x +2 there already today, seems that we got new version of this since
21:20:33 <lifeless> Am I looking in the wrong place for the agenda? https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda doesn't mention the service catalog
21:20:50 <dhellmann> lifeless: there was an email
21:20:52 <lifeless> [I mean, its good to talk about it, but ECONFUSED]
21:20:56 <jroll> lifeless: http://lists.openstack.org/pipermail/openstack-dev/2015-September/075731.html
21:21:25 <jokke_> lifeless: that's my mistake ... I did send the agenda out and forgot to save the wiki change I did for these :(
21:21:35 <lifeless> jokke_: ah, that makes more sense. No worries.
21:21:35 <jokke_> all: sorry for that
21:21:52 <stevemar> lifeless: not like there is much on the agenda :)
21:22:03 <lifeless> stevemar: yes, but more than the wiki said :)
21:22:12 <dhellmann> lifeless: note your spec is up next :-)
21:22:24 <lifeless> dhellmann: indeed; I was looking to see if it was ...
21:22:45 <lifeless> back to the catalog - sorry for the distraction
21:23:26 <dhellmann> jokke_: is this spec ready for final approval, or does it need more work?
21:23:54 <xarses> what about returning multiple endpoints so client's don't require a LB?
21:24:02 <jokke_> dhellmann: that was actually my question as well ... this morning there was 2x +2 but it seems that we have new version
21:24:12 <jokke_> and there is still full brainstorming going on
21:24:13 <xarses> also token containing the catalog causes alot of size problems in production
21:24:24 <stevemar> xarses: yup!
21:24:34 <dhellmann> xarses: see line 14 of the etherpad
21:24:35 * ttx reapplies +2
21:24:37 <jokke_> and apparently the e-mail did not reach either annegentle nor sdague :(
21:24:38 <bknudson> keystone supports ?nocatalog
21:24:45 <bknudson> when getting the token
21:24:51 <dhellmann> jokke_: ETOOMANYMEETINGS
21:24:56 <stevemar> bknudson: we need a way to get the catalog without authenticating
21:25:04 <xarses> dhellmann: ya, I see 14, but that doesn't resolve getting it out of the token
21:25:21 <bknudson> with endpoint filtering you need the scope so that requires authenticating
21:25:21 <jokke_> so should we leave this for now and move to the next one?
21:25:22 <stevemar> bknudson: we only *need* to authenticate because there are silly tenant IDs in some URLs in the catalog
21:25:49 <jungleboyj> dhellmann: +++
21:26:24 <ttx> jokke_: yeah, bad timing
21:26:28 <jokke_> ok, moving on
21:26:33 <jokke_> #topic Backwards compatibility for clients and libraries
21:26:43 <jokke_> #link https://review.openstack.org/226157
21:26:55 <jokke_> lifeless: you're up!
21:28:01 <lifeless> oh hai
21:28:09 <lifeless> so there's a couple of intertwined things here
21:28:37 <lifeless> one is raising the bar slightly on our backwards compat story for both api clients and libraries
21:28:53 <lifeless> for clients we already promise it but we don't test it
21:29:02 <lifeless> for libraries we haven't really made a promise
21:29:10 <lifeless> (and I think we need to)
21:29:21 <lifeless> the second thing is that we have branches of all these things
21:29:45 <lifeless> and it makes consuming them harder - and if we're properly testing our backwards compat story, we may well not need them
21:30:18 <lifeless> its possible that they could be two specs, but I spent a bit of time poking at making them separate proposals and it didn't really work for me
21:30:40 <dhellmann> we started making branches because the backwards compatibility testing was hindering our forward progress as we rolled forward with dependencies and new features
21:30:50 <dhellmann> at least, that was part of it
21:31:21 <bknudson> we're planning to do a keystoneclient 2.0 that removes deprecated stuff
21:31:23 <lifeless> dhellmann: so we have to do multi-step dances on all changes anyway
21:31:36 <lifeless> bknudson: sure, thats fine - my proposal specifically permits tht
21:31:40 <jokke_> dhellmann: correct me if I'm wrong but that started just around release of kilo anyways
21:31:51 <clarkb> dhellmann: lifeless right we were testing this stuff until everyone revolted and said making the tests work was too hard
21:31:57 <jokke_> Is there something fundamentally broken around that approach?
21:32:32 <annegentle> jokke_: I'm sorry, I didn't see the email re: service catalog and multi-tasking meetings today
21:32:36 <lifeless> clarkb: It was my understanding we kept having gates break because we had cross-version asymmetry in play
21:32:54 <jroll> clarkb: yeah, it seems like this spec sets out to fix the 'too hard' part of this, it mostly deals with how to test things and handle dependencies
21:32:59 <jroll> (imho)
21:33:24 <clarkb> jroll: lifeless I fully expect that the first time kilo fails a change to novaclient that is required to make M do something there will be another revolt
21:33:34 <jroll> heh
21:33:35 <fungi> a huge trigger for the branch-everywhere change was as an upshot of pinning all requirements in stable branches
21:33:38 <clarkb> the underlying reason why things fail isn't important, devs generally don't care about the old version and get cranky
21:33:44 <dhellmann> clarkb: it's even more likely to happen with an oslo library
21:33:46 <lifeless> clarkb: so this can only apply from liberty up
21:34:01 <clarkb> lifeless: sure but you are ignoring the mindset at play here
21:34:05 <clarkb> lifeless: yes we ran into problems with deps
21:34:09 <dhellmann> lifeless: that just punts the revolt down the calendar to mitaka
21:34:12 <clarkb> But any fails will have the same problems
21:34:18 <lifeless> dhellmann: sure - but thats why this needs discussion
21:34:29 <lifeless> I don't want it to be '5 folk agreed, lets do it'
21:34:31 <fungi> if we _aren't_ pinning requirements any longer and can somehow keep the supported versions compatible between branches then we can potentially stop branching within those libraries
21:34:35 <lifeless> I want -buy- in
21:34:36 <dhellmann> lifeless: sure. I'm discussing why I think this is something we don't want to do. :-)
21:34:42 <jokke_> this is actually quite relevant topic for us in Glance as we just had a huge "fight" around our glanceclient 1.0.0 release and if we should make the client mimic v1 API functionality on top of v2 API as much as we can
21:34:45 <bknudson> we actually used to have tests in keystone that cloned old tags of keystoneclient and ran tests with it.
21:35:01 <lifeless> bknudson: right, so this is a generalised form of that
21:35:09 <lifeless> bknudson: did they add value ?
21:35:13 <bknudson> I will say the tests found problems.
21:35:14 <clarkb> bknudson: keystoneclient also had tests that ran against the ld devstack clouds
21:35:17 * edleafe has to run - catch up with the logs later
21:35:23 <morgan> lifeless: they did add some value, they caused a lot of issues
21:35:27 <dhellmann> what's the impact for the test matrix on a project like oslo.config, which is used in so many places?
21:35:30 <clarkb> IIRC jogo added those in around icehouse?
21:35:44 <ttx> There was also a *lot* of pressure to get security fixes backports from distros, so they liked having stable branches there
21:35:44 <morgan> lifeless: but it did help limit regressions in keystoneclient/server
21:35:46 <bknudson> the git clone when doing tox caused issues.
21:36:00 <lifeless> bknudson: right, this wont' have that issue because its zuul-integrated
21:36:28 <fungi> though in fairness to the distros' desires to add stable branches for libraries, that wasn't actually the main reason we ended up doing it. they'll just be disappointed if we take it back away from them
21:36:35 <bknudson> lifeless: I think this will be useful then and will likely find issues where we're not backwards compatible.
21:36:40 <lifeless> dhellmann: 'Changes to clients/libraries should run:' in the spec: - we'd run changes to oslo.config against each server branch
21:36:43 <ttx> fungi: right, that was my point in the review
21:36:51 <dhellmann> lifeless: right, how many  new jobs is that?
21:37:14 <ttx> fungi: I'm fine screwing the distros up, but it needs to be spelled out as a consequence of the change
21:37:49 <jokke_> dhellmann, lifeless: and od we have resources to run those jobs?
21:37:56 <ttx> they should see it coming so that we can properly assess the cost/benefit model of that spec
21:37:59 <dhellmann> jokke_: that's a good point, too
21:38:05 <lifeless> dhellmann: we currently support 2 server branches; if the stable release team keep that constant - 2x the dvsm jobs of oslo.config + 2x again [if we do the *full* matrix]
21:38:17 <lifeless> dhellmann: one 2x is the 'upper-constraints + modification'
21:38:29 <lifeless> dhellmann: and one 2x is the 'upgrade only oslo.config' case
21:38:54 <lifeless> dhellmann: the 2x is because master + -1 + -2 == 3
21:39:00 <jokke_> lifeless: so would oslo.config be the only special cupcake to get this?
21:39:04 <bknudson> the keystone test would test with ksc 1.0 and ksc 1.x and ksc diable and latest, something like that. It was strange.
21:39:20 <bknudson> diablo
21:39:20 <dhellmann> ok, it looks like we might have more issues with libraries that run more gate jobs then, and oslo.config only runs one dsvm job today
21:39:35 <dhellmann> tooz and oslo.messaging are probably better examples of where we would add lots of new test jobs
21:39:37 <clarkb> dhellmann: one per branch is probably sufficient
21:39:44 <ttx> (don't get me wrong, I think the single release channel is a lot saner for developers than the stable branch model, but I wonder about our users)
21:39:49 <clarkb> since using postgres or mysql isn;t going to make a difference for oslo.config
21:39:55 <clarkb> (but oslo.db would want both)
21:40:05 <dhellmann> clarkb: oslo.messaging runs 6 dsvm jobs now
21:40:05 <lifeless> clarkb: two per branch - one for just-the-change and one for all-the-latest-including-the-change
21:40:06 <ttx> (distros being a user)
21:40:16 <clarkb> lifeless: all the latest what?
21:40:24 <lifeless> clarkb: though we can discuss whether both of those are truely needed or not
21:40:36 <lifeless> clarkb: see lines 218 and 223 of the spec
21:40:37 <clarkb> it would be jobs today + jobs today against liberty instead
21:40:42 <dhellmann> I'll just state for the record that I'm opposed to this in principle, because I think it is going to make development of libraries even more difficult than it is now, and discourage contributions in areas where we should be encouraging them.
21:41:12 <lifeless> dhellmann: are you also opposed to backwards compatibility?
21:41:22 <jokke_> ttx: I might be the exception to make the rule, but I was really happy to see the libs moving to stable branching as well ... yes it brings overhead, but it made the developer life so much easier with the hope that every changed thing would not break downstream
21:41:36 <dhellmann> lifeless: I would not be opposed to individual projects deciding to take this on. I am opposed to making it a blanket thing.
21:41:53 <lifeless> jokke_: how does it make developer life easier ? A break is a break, whether it happens on the next release or in 6 months...
21:42:10 <dhellmann> lifeless: and I don't think backwards compatibility is as important for most of our libs -- clients may be the exception
21:42:25 <bknudson> the problem distros have with picking up newer releases of the libs is when the dependencies change
21:42:27 <lifeless> dhellmann: is oslo a single project or many, for this?
21:42:47 <bknudson> now you have to upgrade a bunch of other packages along with keystoneclient (for example)
21:42:50 <dhellmann> lifeless: I would look at it case by case
21:42:51 <lifeless> dhellmann: so I drill down a bit into the problems - right now the distros can't take our releases incrementally
21:42:51 <dhellmann> lib by lib
21:42:57 <lifeless> dhellmann: at all
21:43:24 <lifeless> dhellmann: the whole lot wedges into a big morass, and the disaggrating of servers won't be picked up in any meaningful way until we fix this
21:43:44 <jroll> I think maybe we need to take this in baby steps - we don't even test client master vs stable servers, let alone every library in openstack
21:43:59 <dhellmann> jroll: true
21:44:01 <lifeless> bknudson: right - so the thrust of this proposal is to make that cascade safe (not to remove it)
21:44:12 <lifeless> jroll: I'd like to do that but you have to start at the edge of the matrix
21:44:17 <lifeless> jroll: our clients use libraries
21:44:32 <lifeless> jroll: if those libraries are branched, then the clients are tied to those branches
21:44:44 <jroll> lifeless: ignoring the all-in-one server thing that makes a mess of dependencies
21:44:48 <jokke_> lifeless: I way rather see the backwards incompatible changes coming in future and have time to deal with them than being stuck with past bad decisions ... this is really more towards the libs than clients, but just more ... also no-one pays attention of the versioning and if it brings backwards incompatible changes or not as seen with glanceclient
21:44:59 <jroll> lifeless: thinking of a user running the latest novaclient against nova juno, for instance
21:45:00 <bknudson> this seems to also require upping the major release number when the deps change
21:45:29 <ttx> For the record, I'll starte that I'm not opposed to this in principle. I just think it's a major change that we need to analyze well before starting it, and look at all the hidden costs (upstream & downstream cost) before making a decision
21:45:36 <lifeless> bknudson: I don't think so
21:45:49 <lifeless> jroll: so yes, and python-novaclient depends on python-keystoneclient
21:46:01 <lifeless> jroll: and oslo.i18n, serualization, utils
21:46:08 <jokke_> lifeless: and the branching makes possible to backport critical/security fixes way more flexible manner than just version locks does for our stable servers
21:46:29 <lifeless> jroll: so for distros to consume a newer python-novaclient, they need to know that those dependency changes won't break servers that install the same packages
21:46:43 <jroll> lifeless: that's not what I'm talking about at all
21:46:51 <lifeless> jroll: ok
21:46:55 <lifeless> jroll: help me understand ?
21:47:11 <jroll> lifeless: I'm talking about taking a brand new machine, pip install novaclient, nova boot (against some older nova server)
21:47:14 <jroll> we don't even test that
21:47:24 <jroll> let alone the implications of doing this on a machine with all of openstack installed
21:47:27 <lifeless> jroll: ok - so yes, and I mention that in the spec
21:47:30 <jokke_> jroll: add to your earlier we do not even test lib masters agains our service master, that would be nice before we even talk about testing them against service stables
21:47:36 <ttx> i.e. not serverside libs but clientside libs
21:47:37 <lifeless> jroll: we would get that testing with this spec
21:47:54 <ttx> even if we currently use python*client libs for both.
21:48:15 <lifeless> jroll: assuming there are such tests, but as jokke_ mentions, our client testing is actually very sparse right now
21:48:31 <lifeless> jroll: most if it happens defacto via the servers using the libs to talk to each other
21:48:59 <jroll> lifeless: ok, I need to read deeper. I just think that this is way down the road from where we are now, and we should go one step at a time
21:49:04 <fungi> yeah, the limited amount of client testing we used to get with tempest backwards-compat jobs was nearly nonexistent (other than testing coinstallability). the hope was that as clients began adding their own functional test suites they could run them against varying devstack branches
21:49:13 <jokke_> lifeless: with the clients, do you mean that our client needs to be backwards compatible with old servers or that our client api/cli needs to be backwards comaptible with previous versions or both?
21:49:20 <lifeless> jroll: If we agree that its a place to head to, then I'm delighted and happy to work on making a first step thing
21:49:29 <jroll> nod
21:49:48 <lifeless> jroll: I've not figured out anything sane so far
21:49:51 <jroll> lifeless: I'm good with the general idea, with the caveat that it might take a year or two to get there, and there's lots more to think about :)
21:50:16 <lifeless> jokke_: so on security backports - we need to backport things because distros can't consume newer releases.
21:50:22 <lifeless> jokke_: its a self-created problem in a lot of ways
21:50:39 * jroll realizes this is a super hard problem
21:50:49 <lifeless> jokke_: (again, look at firefox and chromium - no stable branches, just roll forward)
21:50:53 <ttx> lifeless: can't, or don't want to ?
21:51:06 <lifeless> ttx: today - can't
21:51:44 <lifeless> ttx: because we're not committed to backwards compat through the stack
21:52:01 <lifeless> ttx: upgrading python-novaclient to get a security fix means upgrading multiple oslo libraries
21:52:04 <lifeless> ttx: and keystoneclinet
21:52:17 <lifeless> ttx: and the oslo libraries may have backwards incompatible changes
21:52:21 <jokke_> lifeless: but the problem starts with most of the 3rd party libs our libs and clients consume are not that either
21:52:22 <ttx> lifeless: firefox is teh exception rather than the rule though, it had to apply for a SRU exception
21:52:24 <lifeless> ttx: which forces an upgrade of the servers
21:52:30 <jokke_> and that has been breaking us all the time
21:52:53 <lifeless> ttx: so if Ubuntu *wanted* to take latest novaclient, it can't because the servers are a Big Deal to upgrade
21:53:08 <ttx> I don't think if we had aweosme backward compatibility that they would roll forward using featureful SRUs
21:53:17 <lifeless> jokke_: constraints has locked that down so we're not subject to those whims anymore
21:53:24 <ttx> those are quite a pain to test
21:53:25 <jokke_> lifeless: ref firefox and chromium, which way we should be backwards compatible ... towards the consumer or towards our services?
21:53:35 <lifeless> ttx: it would be 'won't' rather than 'can't' at that point
21:53:39 <jroll> imho, if we can actually do this, it's a huge win in the end, for both devs and deployers. it's just a super-not-fun path to get there, and we need to think about what that path is.
21:53:42 <lifeless> ttx: right now its can't :)
21:53:42 <ttx> lifeless: right
21:54:01 <jokke_> because I see firefox for example changing the user interface all the time and that's deifnitely not backwards comaptible
21:54:09 <lifeless> ttx: and there's no point trying to have a dialogue with  any distro about doing it while we haven't enabled it
21:54:30 <lifeless> jroll: what things are in your mind when you say super not fun ?
21:54:30 <ttx> jokke_: in the forefox ccase they accept to break their user expectations of painless upgrades against making their lives a lot easier
21:55:33 <Piet> Are we planning to have open discussion?
21:55:35 <jokke_> ok, lets continue this topic on the spec nad leave the last minutes for open discussion
21:55:46 <ttx> jokke_: it's just so much work (and risk) to backport security fixes in Firefox that they said "let's stop doing that and risk breaking users with featureful upgrades instead"
21:55:55 <jroll> lifeless: lots of dependency hell, gate breakage, etc. for someone like me that isn't as informed as you on those things, it's hard to wrap my head around :)
21:56:00 <jokke_> #topic Open discussion
21:56:05 <jroll> lifeless: I may be completely wrong, it might be easy
21:56:11 <Piet> OK - a couple of things
21:56:14 <Piet> First, we are running a persona working session next weak in Austin.  We already have a group of tentative roles, but want to flesh-out a handful into actual personas.
21:56:18 <ttx> jokke_: if Firefox continued to provide them with stable branches they would happily continue to use them.
21:56:26 <lifeless> jroll: so I think no gate breaking
21:56:34 <lifeless> jroll: it might be hard to get some patches in
21:56:46 <lifeless> jroll: but the point of this is to be protective of compat and the various systems
21:56:52 <jokke_> ttx: somewhat makes sense, but indeed sounds like really special case
21:57:26 <jroll> lifeless: yeah, I suspect if we spent an hour over beers this would be much more clear to me :)
21:57:38 <jokke_> Piet: mind to open "Persona" up a bit in the context
21:57:55 <ttx> jokke_: basically I'm not sure that distros would roll forward if we did that perfect backward compatibility. They would likely curse us and do their own stable branches instead.
21:58:02 <lifeless> I've put a slot for this up for the cross-project track in mitaka
21:58:11 <jokke_> ttx: yes, I agree
21:58:23 <Piet> Sure, the product working group needs a set of personas to help them focus their stories a bit
21:58:46 <Piet> Architects, operators, developers, etc
21:58:56 <ttx> jokke_: so in the end I'm not convinced of the value of the change for the user/distro
21:59:00 <lifeless> ttx: and you know, that would be ok. Because all the folk doing CD - every devstack user for instance - would be that much happier
21:59:11 <lifeless> anyone installing from pip
21:59:38 <ttx> lifeless: yeah, at least we would allow them to make the smart choice. They would likely not make it, but meh
21:59:38 <jokke_> last minute!
21:59:58 <jokke_> Piet: was that just announcement or did you actually seek some feedback from this group
22:00:02 <jokke_> ?
22:00:09 <Piet> We're looking for feedback from the PTLs on which roles should be the focus of the working session. I have a quick two minute survey for the PTLs to vote on which roles are important to their projects.
22:00:27 <Piet> Need to understand which roles the PTLs actualy care about
22:00:33 <Piet> https://www.surveymonkey.com/r/H6WS2HS
22:00:43 <jokke_> Piet: ok, thanks ... mind to send e-mail to the dev mailing list with [ptl] in the topic
22:00:47 <Piet> Will take you less than two minutes and add a ton of value
22:00:48 <jokke_> as we're out of time
22:00:55 <Piet> sure
22:00:57 <jokke_> #link https://www.surveymonkey.com/r/H6WS2HS
22:01:04 <jokke_> #endmeeting