20:01:17 #startmeeting tc 20:01:17 Meeting started Tue Apr 4 20:01:17 2017 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:21 The meeting name has been set to 'tc' 20:01:26 Hi everyone! 20:01:30 o/ 20:01:30 Thanks EmilienM for chairing last week 20:01:32 hello 20:01:45 Although my plan to skip the meetign failed completely 20:01:47 * Rockyg is snuffling and sneezing as far away from everyone else as possible 20:01:59 * ttx blames DST 20:01:59 ttx: my pleasure. I can do it anytime again 20:02:04 Our agenda for today is at: 20:02:07 * flaper87 blames ttx 20:02:07 o/ 20:02:08 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:16 #topic Renew & add Zanata dev members as extra ATC 20:02:22 #link https://review.openstack.org/451625 20:02:28 I had trouble matching some of those to active Foundation memberships 20:02:55 Is it OK if I approve this as soon as I get the confirmation of active membership ? 20:03:03 ++ 20:03:05 +1 ttx 20:03:05 Will be tight to include them to the TC election 20:03:06 +1 20:03:13 ++ 20:03:17 ttx: ++, I'm fine with it once you sort that out 20:03:24 yeah, i think we've generally fast-tracked extra-atcs changes as long as the ptl votes in favor 20:03:27 +1 20:03:29 +1 20:03:30 #agreed OK to approve once we clear out the question of active Foundation membership 20:03:48 #topic Clarify project addition process 20:03:55 #link https://review.openstack.org/452073 20:04:02 The idea here is to make the process slightly more discoverable 20:04:12 and encourage projects to engage early on with the Technical Committee on the question of scope match 20:04:19 I did fix the comments that were posted 20:04:35 Looks like we have quorum 20:04:35 i like the word "adequation" 20:04:51 It's a pretty common French word, but I checked that it existed in English before using it :) 20:04:56 o/ 20:05:10 Alright, approved, thanks! 20:05:28 #topic Propose the addition of an assert:maintenance-mode 20:05:32 amrith: around ? 20:05:35 yup 20:05:37 #link https://review.openstack.org/449925 20:05:38 hello 20:05:55 * ttx reads recent comments 20:06:20 sorry, I was multitasking, let me shut down other tasks 20:06:32 I made the same assumption dtroyer did about the purpose of this tag as an indication that a project is not necessarily healthy 20:06:38 mtreinish: to answer your question, I think it's OK for a project with an otherwise-active team to declare a specific deliverable in maintenance-only mode 20:06:59 dhellmann, that isn't the only situation where this would happen 20:07:20 and I expect that there are times, and I certainly see this with trove moving forward where a specific deliverable may become maintenance mode 20:07:21 ttx: sure, but I think maintenance mode means something different to me then the core team is AWOL 20:07:28 I think the distinction between 'entire project' and 'deliverable' is important here 20:07:34 which is what the tag is written as 20:07:37 one of the things I want to do with trove is to split the deliverables to make the project more modular 20:07:37 well, we have lots of deliverables that don't see many changes but that are actively maintained. I'm not sure we would want to apply this to them except as an indication of a possible problem. 20:07:55 currently we have all databases in a single deliverable, trove 20:07:59 dtroyer: 'entire project' is the team 20:08:06 I'd like to split that and make it per deliverable database 20:08:10 dhellmann: you mean, there is no value in describing a project that is in maintenance-mode ? 20:08:24 dtroyer: this does feel a bit per deliverable 20:08:27 flaper87: it is also the set of all fo the deliverables, which is not people 20:08:33 should be able to do either at the project or deliverable level 20:08:37 ttx: the only reason I could see to declare that is if we think that state is either good or bad. Otherwise, it's just normal, right? 20:08:43 dhellmann, ttx, I have removed the project wide maintenance mode notion 20:08:48 It feels like communicating to users that a project will not grow new features at the moment, is a useful thing to communicate 20:08:54 dims: ++ 20:08:54 amrith: good 20:09:05 this is a signal to outside world to set expectations 20:09:17 dtroyer: I meant to say that project team covers that, people and set of deliverables. 20:09:19 amrith: ++ although there may be a shred or two of that still present 20:09:25 ttx: ++ 20:09:34 dims: I'd rather keep tags applied at team OR deliverable level, not AND 20:09:35 ok, I guess I can see that. The oslo libraries we have that might otherwise fit this description aren't being prevented from having new features, they're just sort of done. 20:09:36 the ONLY thing that can have maintenance mode is a deliverable. now, if you set all deliverables to maintenance mode, you are signaling something is not good with the project. 20:09:39 if i applied this to the sqlalchemy-migrate library, can i stop getting a bunch of random useless pep8 and typo fix patches? 20:09:40 so, while it was removed, just for the record I'd be fine with project wide maintenance mode tag 20:09:49 ttx : yep, OR is good 20:09:54 mriedem: I thought we -2ed most of those :) 20:09:54 sdague, YES 20:10:06 mriedem: heh, isn't that maintenance? 20:10:08 I am hoping that with this, I can get some of that. 20:10:21 mriedem : we should definitely apply this tag to sqlalchemy-migrate 20:10:22 mtreinish: yes 20:10:26 dhellmann: ++ 20:10:31 ++ mriedem 20:10:36 * amrith steps back and lets the tc deliberate :) 20:10:43 you know the patches will continue to come, 20:10:46 The idea of the tag is to communicate the effect to the user 20:10:48 because no one will read the tag first 20:10:49 I think this tag makes sense, FWIW. I like what it communicates and how it communicates it 20:10:55 not to make a statement on the team state 20:11:04 mriedem : we are not going to stop people from posting patches 20:11:07 flaper87, ++ I agree, a well written proposal 20:11:14 :) 20:11:16 ttx: seems like a side effect 20:11:19 amrith: rofl 20:11:21 *if* a team is so abandoned that it can't do basic maintenance, then yes it should die 20:11:29 amrith, ttx: the use of the term "transient period of low activity" makes me think you believe this would be a temporary situation for a deliverable 20:11:34 we've sort of got the same situation with a number of infra deliverables, where we really don't want to add new features/complexity to them but contributors seem to take that message as a hostile rejection of their right to innovate 20:11:37 for some teams that don't have much deliverables 20:11:59 dhellmann: I think the idea there was to say that it's something you could recovber from. I agree it's slightly unlikely though 20:12:02 dhellmann, yes. transient is the operative word 20:12:05 dhellmann: that's how I read it, yep. 20:12:07 dims: well, we could always have maintenance bot which replies "this project is in maintenance mode, most patches won't be accepted." just so that there is some feedback to contributors that don't realize 20:12:09 ttx : +1 to basic maint else die 20:12:18 sdague : true 20:12:22 amrith, ttx: I'm reading your responses to my question as not being aligned. 20:12:24 * ttx reads latest patchset 20:12:27 dims, ++ 20:12:29 well, I guess you are. 20:12:39 dhellmann, let's look at them specifically 20:12:41 I think we are 20:12:42 it seems like we're talking about 2 slightly different things 20:12:48 dhellmann: I'm fine withthe wording, but could support its removal :) 20:12:49 but if I'm conveying the idea that I'm not, let's clarify 20:12:53 either the team is moribund or the deliverable is "done" 20:13:06 having a "done" deliverable, as unlikely as that seems, is a good thing 20:13:11 having a moribund team is less good 20:13:12 dhellmann: that's the distinction I was tring to get at before 20:13:27 dhellmann, there are two use cases; yes. 20:13:27 dhellmann: is there value in discerning between the two cases, from a user perspective ? 20:13:28 and the way the proposal is written is more for the former 20:13:39 mtreinish: the intent was to keep it positive 20:13:47 so if we're going to say "this project is not receiving new features" then let's focus on that, rather than all of the "not guaranteeing to be responsive with feature reviews" phrasing 20:13:50 in the short term, I would like to mark all trove deliverables to be maintenance mode; that use-case is the indication that the project is in a 'not good' state. 20:13:50 we've talked about bugfix/stability cycles, too, that seems like it could apply here (but not sure it would be a useful way to communicate that) 20:13:56 personally, it feels like maintenance mode is very in line with graceful step down. It is signaling honestly that some bit of things has wound down. That can be data for people that care to step up, or for people that deploy things that are concerned about features to consider what they are going to do next. 20:13:56 but I believe that this is transient 20:13:57 ttx: I think there is. If the team is moribund then all its deliverables might be affected 20:14:04 there are things I'm working on to get us to a better state. 20:14:16 but once we remove the tag on all deliverables, I would like to split the project 20:14:18 sdague : that's what I thought, but I don't think that's what amrith and ttx actually mean 20:14:36 into multiple deliverables, like trove-mysql, trove-mariadb, trove-mongodb, ... and so on 20:14:43 dhellmann: ok, I could be misreading and putting a lot of my expectations in there 20:14:46 if that happens, different 'drivers' could be in different states of done'ness 20:14:56 sdague : my expectations aligned with yours, which is why I'm trying to clarify 20:14:59 amrith: I get, in the trove case would it make more sense to just deprecate a bunch of those dbs 20:15:10 s/I get/I guess/ 20:15:17 sdague, i don't think so 20:15:19 consider this 20:15:25 in mysql there are two kinds of replication 20:15:30 binlog and guid 20:15:32 I guess the question is whether we want to conflate things that are maintenance-only because they are done, with things that are maintenance-only because their team is in low-activity mode 20:15:45 The tag conflates the two cases 20:15:47 ttx: I don't think we do 20:15:48 if I went to the place I want to, I'd have trove-mysql-binlog-replication as a deliverable (not the best name) 20:15:48 yes 20:15:55 I think "low activity team" is another tag 20:15:58 ttx: do we need status:done or status:mostly-done? 20:16:00 ttx: team status should be specified at a team level, I think 20:16:02 and I could mark that in maintenance while -guid would remain active 20:16:08 sdague ^^ 20:16:09 I'm not sure what the trove case is, but I think it's "low activity team" 20:16:21 flaper87 : ++ 20:16:37 dhellmann, yes. now it is, to paraphrase someone, a 'low energy team' 20:16:40 flaper87: why ? Corner case a moribund team would place most of its deliverable in maintenance mode to focus on one 20:16:50 dhellmann : they way i saw it, if it was set a deliverable level then that thing is in maintenance, if applied at project level then team is going away 20:17:08 hopefully soon, the project would go to a different place where the current unwieldy deliverable is replaced my many deliverables 20:17:19 and individual deliverables could be pushed to maintenance mode 20:17:20 amrith : I don't know how valuable it is to say that driver X is only being maintained and not seeing new features. I do see it as valuable for a whole project, or for a team. 20:17:28 or at best the team is in stasis with a hope of eventual recovery 20:17:41 dhellmann, the latter (whole project or team) is the current use case 20:17:45 so let's focus on that one for now 20:17:53 rather than status done, how about complete? it has all the features that it's going to have. Any changes are bugfixes now. 20:17:54 dims : yeah, we want to describe those cases separately, though, and it's easier to think of tags as having one scope or another 20:17:58 it's not the same. As unlike as it may sound a team that used to have drivers might merge everything into a single repo and mark the drivers as maintenance mode 20:17:59 fwiw I'm not attached to the current (conflating) version, just trying to explain why it ended up in that place, since I reviewed an early draft and influenced it :) 20:17:59 I think the ambiguity between a project being done and a project (or deliverable) being unattended is bad here. Because "being done" should be considered not just a good thing, but a goal. 20:17:59 it is the stated intent to mark all of trove's deliverables as maintenance mode right now 20:18:04 is "no-new-features-now" the flag we want here? there do seem to be lots of overlapping things here. 20:18:13 don't want too many tags either... 20:18:13 probably not the best example (ttx see my prev message) 20:18:17 cdent : ++ 20:18:21 cdent: I am leaning in your direction here 20:18:47 OK, all, could we assert that for the purposes of this tag, we only discuss the 'team is low energy for now' use case 20:18:54 and ignore the per-deliverable maintenance mode? 20:18:56 amrith, ttx: I feel like the case we have right now is not well covered by this tag because of the conflation. Do you want to modify the definition to focus on the team aspect? 20:18:59 cdent: agree. I can't decide if "maintenance mode" here means "slow" or "unattended". the latter implies a lack of maintenance. 20:19:02 OK, so it sounds like we should rewrite this in a way that makes it more of a team tag, like team:low-activity 20:19:04 amrith: in that case maintenance is the wrong word 20:19:13 ttx++ 20:19:18 amrith : make a team:low-activity tag 20:19:19 amrith: I think we should look at those as separate things (team vs deliverable) 20:19:19 basically describe minimal activity levels before removal 20:19:24 right 20:19:27 designate would qualify as well 20:19:29 cdent, I'm happy to pick another word. and make a team flag 20:19:40 happy to leave name choice out for now 20:19:45 amrith: sounds like that's where the majority lies 20:19:48 and focus on the theme cdent dhellmann 20:19:55 the proposal is to come up with 20:19:57 ttx: would this tag considered an official step before retiring a project? 20:19:58 (a) a team tag 20:20:03 EmilienM: no 20:20:05 (b) indicates that the team is in a low energy mode 20:20:11 (c) is expected to be transient 20:20:24 EmilienM, or reviving the project 20:20:26 why (c)? 20:20:26 amrith: s/expected/hoped/? :) 20:20:31 ttx: why not? 20:20:32 EmilienM: I think it's good to say that the minimal activity requires releases, security bugs watch etc 20:20:35 dims, the idea is that this is transient 20:20:37 * flaper87 things there's room for both a team level and a deliverable level tag 20:20:38 amrith : and then this would be a tag a team asserts about itself or the TC attaches to a team if the team fails to participate over the course of a cycle (I don't know where the minimum bar would be, but 0 releases should be in there somewhere) 20:20:47 ttx: I agree with that statement 20:20:52 EmilienM, mriedem: some projects will just go directly to sub-minimal 20:20:52 (c) will imply someone will have to curate the tag periodically 20:20:58 dhellmann, Yes 20:21:05 amrith : I wouldn't focus on the transient aspect. We're all just dust in the wind, after all. 20:21:07 ++ flaper87 20:21:08 Like if a project doesn't do releases at all, it should not get the tag 20:21:17 dhellmann : ++ 20:21:20 if activity is low enough that you can't even land the security fixes through the gate, then it's time to retire... 20:21:30 dhellmann, ok. with that, the proposal would be (a) and (b) stated above 20:21:33 ttx : ++ 20:21:37 ttx: mriedem EmilienM and there's also the project team and deliverable distinction, which is important 20:21:38 with the prerequisites as stated in the proposal 20:21:44 ttx: if they do no releases they should *not* get the tag? 20:21:56 dhellmann, they WILL do releases 20:21:56 should get the low tag :) 20:22:00 that is a stated expectation 20:22:00 ttx: +1 20:22:08 seems like there's a bit of subjective fuzzyness regardless. i expect most teams have more work to do than they can reasonably expect to get through and leave some on the floor 20:22:16 dhellmann: the tag basically describes the minimal activity level 20:22:22 dhellmann, see line 65 20:22:36 ttx: so in that case all teams will have it, because they're doing the minimal amount of work? 20:22:40 separate the deliverable tag from this proposal. Keep this just team 20:22:40 minimal acceptable activity level includes doing releases 20:22:42 or at least the minimum 20:23:01 dhellmann: it also describves a list of things that those teams will not commit to do 20:23:07 but if there are no patches? we still need the release to bump requirements? 20:23:09 I think we want this to work like the single-vendor flag. If you fall below a threshold, you get the tag. 20:23:15 yeah, no point in fixing security vulnerabilities if you don't make releases to include/distribute them 20:23:19 dhellmann: there's three levels, AIUI: 1) active, no tag; 2) low activity, does bare minimum, yes tag; 3) no activity, no tag, pls retire 20:23:26 dhellmann: that's how I read it 20:23:31 dhellmann: right. It describes that threashold, but also the threshold under which you should not fall 20:23:42 lest you shalt be removed 20:23:48 jroll : if a team is so low activity to not even apply for the tag or do a release, I think we would just retire it, no? 20:23:53 maybe one thing to do is to have a couple of passes at defining a metric which we can assess programmatically like the single vendor tag. I'll take the action item to do that if y'all would like 20:24:06 ttx: ok, the threshold to stay official should be documented separately 20:24:10 dhellmann: yes 20:24:12 OK, looks like amrith has the feedback he needs now 20:24:19 amrith: honestly, a metric seems less useful here than the team itself asserting it 20:24:20 ttx, yes I do 20:24:25 I wouldn't want to figure out a crazy metric 20:24:28 sdague : I think I agree with that. 20:24:30 dhellmann: probably yes 20:24:34 am with sdague, wanted teams to self-apply 20:24:39 sdague: ++ 20:24:42 sdague: ++ 20:24:55 so, this may be premature, but I'm hoping that by the end of the week I can tell you that trove won't need the tag after all. but no promises on that. 20:24:57 don't want to broker or judge or check periodically 20:25:11 sdague: dhellmann said that it should not be an assert, as those are desirable behavior. I kinda agree 20:25:15 amrith ++ 20:25:27 But can be self-influcted team tag in 99% of the cases 20:25:32 inflicted* 20:25:36 I think the TC may need to encourage teams to take the tag now and then, though 20:25:37 OK, I think we can move on 20:25:45 jroll : that's fair 20:25:47 amrith: we look forward to know 20:25:48 ttx, sdague : let's call this team:low-activity and let teams add it themselves or have the TC add it based on subjective judgement 20:25:55 dhellmann: ++ 20:25:58 EmilienM, you and me both :) 20:26:00 well if the teams not doing anything, will the remember about the tag? I guess thats what jroll said 20:26:03 i think if the tc needs to apply the tag, it's something worse than warrants that tag 20:26:10 I think it's a great tool to signal teams taht are struggling and need help 20:26:10 johnthetubaguy: right :) 20:26:20 amrith: what is the key factor here? 20:26:23 johnthetubaguy : its a bat signal for, we need help here too right? 20:26:26 johnthetubaguy : right, if a team is so inactive as to not even think about this tag, it's probably on its way to being moribund enough that we would just retire it 20:26:38 ah ttx beat me to it 20:26:43 dhellmann: possibly yeah 20:26:44 fwiw i'm in an active team and never think about our tag status 20:26:46 EmilienM, I don't follow your question 20:26:48 I don't think teams often think about tags 20:26:50 mriedem: ++ 20:26:51 ttx: dims: if there are bat signals for that, let me know. infra could use a few ;) 20:26:56 b/c there are so many tags and i'm separated from them 20:26:59 amrith: what happens this week? I might have missed something 20:26:59 Alright, let's move on 20:27:00 :) fungi 20:27:12 amrith has everything he needs for next rev 20:27:14 mriedem : yep 20:27:20 EmilienM, time is up, ttx says move along :) 20:27:30 amrith: well done ;-) 20:27:32 thanks all, I have the feedback I need for now 20:27:44 Thanks for pushing this amrith 20:27:49 #topic Use case analysis for Golang addition to Openstack 20:27:51 but if things don't work, I'll blame dims 20:27:56 #link https://review.openstack.org/451524 20:28:02 * dims bows 20:28:02 is thiago here ? 20:28:05 hello 20:28:10 hello 20:28:13 tdasilva: oh, hi! 20:28:17 tdasilva: notmyname yo yo! 20:28:19 ttx: o/ 20:28:26 Looks like exactly what I had in mind for a "Step 1" 20:28:31 this is a nice write up, thanks for putting it together 20:28:40 but then I didn't write /that/ process 20:28:46 * flaper87 is happy to see this moving forward 20:28:52 dhellmann: thanks 20:28:52 That was flaper87's 20:28:59 * flaper87 looks around 20:29:17 Any last-minute question before I approve ? 20:29:30 not from me, thanks everyone for reviewing 20:29:45 * flaper87 was about to make a terrible joke... holding back 20:29:50 alright then 20:29:51 no questions 20:29:51 last-minute +1 from me. looks great 20:30:01 flaper87: meetings are prime for terrible jokes 20:30:10 amazing ps1 merge 20:30:11 this is a great write-up, thanks tdasilva :) 20:30:12 approved 20:30:19 jroll: :P 20:30:20 flaper87, dims: Now it's approved, does that mean we need to start working / finalize the work on step 2 now ? 20:30:22 achievement unlocked 20:30:28 As a reminder, step 2 means setting up the CI pipelines, define how the deliverables are distributed, how dependencies will be managed... 20:30:34 Define how stable maint, i18n & docs will work, define a way to share code/libraries, and guarantee compatible functionality for the base common libraries. 20:30:45 ttx : yes, i'd like to see some work on the common libraries etc 20:30:46 yes, it means all that needs to happen :) 20:30:49 flaper87: can you pm the private joke? 20:30:50 Feels like we already started that 20:30:56 ttx: we have 20:31:06 some of it at least 20:31:27 are there any ci jobs building/testing gocode yet? 20:31:30 ttx : we have brought up a lot of infrastructure already. but a lot more work needs to be done 20:31:34 fungi : yep 20:31:38 awesome! 20:31:38 I'm happy to help and follow-up on the process aspects of this work 20:31:44 fungi: golang-client has a small unit test job 20:31:52 if there are questions about the expectations, do let me know 20:32:04 one small step for golang-client, one giant leap for the ecosystem 20:32:05 tdasilva: and myself had a convo about this at the PTG, tho 20:32:09 flaper87: cool, just want to make sure we cross all the T's based on your process description 20:32:10 fungi : i was just poking at devstack+k8s+k8s-e2e tests (http://logs.openstack.org/53/453253/2/check/gate-k8s-cloud-provider-golang-dsvm-conformance-ubuntu-xenial/80726c8/console.html) 20:32:31 nice 20:32:53 the dependency mirroring bits for CI are going to take some work 20:32:54 alright, anything else to discuss on this topic ? 20:33:06 in terms of CI jobs I noticed a jenkins job for golang, but not sure where that is being used yet 20:33:11 tdasilva : can i expect swift team to help with the golang commons library? 20:33:25 dtroyer: consider retrieving deps through our caching proxy as an alternative maybe? 20:33:35 tdasilva : y, ping me later on openstack-golang, and will walk you through what is there 20:33:41 I'd rather say "members of the Swift team", don't think everyone needs to jump in 20:33:42 dims: sounds good 20:33:49 ++ ttx 20:34:00 fungi: expect questions tomorrow 20:34:00 dtroyer: though could get similarly complex since it sounds like there's no central host for go deps 20:34:07 right 20:34:30 yes the dep situation still needs to be clarified a bit 20:35:08 From a release management perspective, the fallback will be to publish signed tarballs, but ideally we'd like to support whatever makes the most sense in this world 20:35:24 which is *not* signed source code tarballs apparently :) 20:35:27 ++ 20:35:38 ttx: heh 20:35:39 ttx: the biggest thing I'm worried about for releases are the genrated files and how to include those 20:35:58 dtroyer: I gave in an committed them to the repo in oaktree 20:36:09 dtroyer: I still feel dirty and wrong - but it's how go works 20:36:09 mordred: boo 20:36:13 fungi, dtroyer : I wonder if we can learn anything about mirroring build dependencies from some of the distros. I know RH doesn't like to have a build depend on outside servers, either. 20:36:14 the gocosystem seems perfectly happy with git tags (or even just random git commit shas from arbitrary foks on github at times?) sounds like 20:36:24 ttx: there is literally no other choice when the consumptoin model is only via git 20:36:46 mordred: what's next. Jars deployed with maven ? 20:36:53 ttx : so question for you, what's the next check point before we allow an official release of a go based deliverable? 20:36:58 that's where tools like glide are helpful, as an indirection step to setting up the GOPATH dirs 20:36:58 All my certainties are gone 20:37:06 ttx: :) 20:37:19 dtroyer: this is true - although once you get in to things like generating protobuf code from .proto files ... 20:37:30 * flaper87 looks at ttx and mordred suspiciously 20:37:44 dims: I think we can add stuff in now, as long as the step 2 work is in progress and we are pretty confident the work will be completed 20:37:45 ttx: time is circular 20:37:51 But then flaper87 designed that process 20:38:06 ack ttx 20:38:17 so I'm happy to defer to him on when time is right 20:38:32 OK, let's move on 20:38:35 dims: As far as release go, the step 2 should be completed 20:38:45 but that doesn't prevent projects from being created 20:38:46 flaper87 : ack on that 20:38:50 right 20:38:54 Like I said, for release management we have a fallback 20:39:09 and we can incrementally improve from there 20:39:23 for dependency management, not sure we have such a fallback 20:39:29 * flaper87 wonders if ttx is trying to hack "The Process" 20:39:34 :P 20:39:35 It's more just a fall 20:39:57 abyss! 20:39:58 Today is pun day 20:40:06 OK, moving on! 20:40:13 #topic Add a "docs:install-guide-verified" tag 20:40:17 #link https://review.openstack.org/445536 20:40:24 dhellmann: you sent an email to ask that we table this until you have a chance to work out the next draft with Alexandra ? 20:40:25 asettle and I are working on a new draft of this 20:40:35 yeah, I think we'll have something next week 20:40:36 ok, so maybe useless to talk about it now 20:40:51 yeah, let's skip it for now 20:40:52 Have several topics for open discussion, so ok to skip 20:41:09 #topic Open discussion 20:41:17 I had a few topics to cover 20:41:21 * Centrally documenting API versions for exposure in project navigator 20:41:26 #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114690.html 20:41:34 The web team at the Foundation would like to expose accurate API version information in the Project Navigator 20:41:37 A noble goal 20:41:45 So they would like to collect things like http://paste.openstack.org/show/604775/ or http://paste.openstack.org/show/604776/ (which rosmaita proposed) 20:41:56 I would rather not add this to projects.yaml though, because it's not governance, nor does it need TC approval 20:42:05 lsell suggested that they create a specific project-navigator repository to collect that information 20:42:11 we have links to api-ref docs now, is there a reason why thats not enough? 20:42:14 (and any other non-governance-releated information they will need for the navigator in the future) 20:42:17 ttx: yeah it seems out of place in projects.yaml 20:42:26 Does that sound like a good idea ? We can make it a TC-owned repo and delegate review. 20:42:32 Or would you rather collect that information somewhere else ? 20:42:46 johnthetubaguy: I think the issue is if each project does things differently 20:42:47 it just feels like a failure of the existing API docs 20:42:59 johnthetubaguy : ++ 20:43:17 so, I think a machine structured overview in api-ref feels like the right thing here 20:43:18 ttx: I'm with johnthetubaguy, it feels like the projects can expose this in a standard way 20:43:25 we just need a schema 20:43:28 what if it's consumable by the existing api docs, simply extracted into its own tree/repo for reduced duplication? 20:43:32 ttx: if we want to standardize, then let's get the API WG to set a standard 20:43:32 sdague: that works 20:43:36 johnthetubaguy: so the new project navigator wants to show which API versions are supported in (the current?) release. I would show you but the dev version is broken 20:43:46 sdague: that makes sense to me 20:43:58 seems a lot like the discussion about coming up with a standard format for driver feature matrices between projects 20:44:04 jroll : the question is, why is that in the navigator to begin with? 20:44:06 dhellmann: it's blocking the release of the new version though, so it's not realkly a one-year thing 20:44:09 johnthetubaguy: ah here it is, see version history toward the bottom http://devbranch.openstack.org/software/releases/ocata/components/glance 20:44:11 fungi : ++ 20:44:19 ttx : the question is, why is that in the navigator to begin with? 20:44:32 dhellmann: good question, I can't answer that :/ 20:44:45 the project navigator wants a project/api versioning history, the marketplace wants driver feature matrices and contact details... 20:44:48 dhellmann: I asked the question, and it was mentioned as a useful piece of information to communicate about a given service 20:44:55 ttx: I'm also not sure why you think agreeing on a standard outside of any of our processes is going to be faster or work better than using the working group :-) 20:44:59 the API version information seems useful honestly, I have no problem with it being there 20:45:21 it should be correct though 20:45:28 and should include the list of versions each release supports 20:45:29 I think we just need an owner on defining a schema 20:45:32 like, that glance page is wrong 20:45:36 dhellmann: well, the API WG was very busy for the last 3 months defining API compatibility :) 20:45:48 then, yeah, I guess let's set up a new repo to hold whatever data the navigator team needs that isn't available somewhere else 20:45:48 mordred: right, hence why we're talking about a machine readable format :) 20:45:58 dhellmann: ++ 20:46:13 options seem to be in a central repo or distributed across teams 20:46:15 sdague : wouldn't that be the navigator devs? 20:46:17 dhellmann: ++ 20:46:17 I mean - we do already have a machine readable format for versions in a release - maybe we just use that? 20:46:20 dhellmann: sure 20:46:24 but with a consistent schema in either case 20:46:26 I mean, *if* data ends up being covered somewhere else, we can delete it from the project-navigator extra-information directory 20:46:28 fungi : centralize it 20:46:35 mordred: we do? for api versions? 20:46:35 and whereit diverges across projects, use this as an opportuntity to fix that 20:46:37 jroll: yes 20:46:38 mordred: it's not super readable 20:46:45 no - it's Machine readable 20:46:48 mordred: where? 20:46:50 a program can read it 20:46:53 yeh, where? 20:47:02 the version discovery document each service services from / 20:47:15 mordred: ok, but you have to stand up the services at all those versions 20:47:18 so literally you have to stand the service up and ask it 20:47:18 mordred: you want the project navigator to run every version of every api service? 20:47:23 nono - I get that ... 20:47:25 no 20:47:30 I'm not saying we collect it that way 20:47:38 I'm saying we HAVE a format - we just need to collect it and stick it somewhere 20:47:41 so it can be read 20:47:45 right 20:47:46 oh, just use the same format 20:47:47 why not each project keep a chunk of yaml in its own git. the projects.yaml knows where those repos are 20:47:48 the question is where :) 20:47:49 literally ever project can already produce this data 20:47:56 cdent: yeh, pretty much 20:48:14 mordred: we could dump that information in that project-navigator git repo alright 20:48:20 cdent: sure. but maybe keep that chunk of yaml in an identical document format to what GET / would return 20:48:33 * johnthetubaguy is still confused what people use that info in the navigator for, has CD too ingrained in his head 20:48:35 I don't know. I'd just put it in one repo. It's much easier to change the schema as needed that way, since the tools could live there, too. 20:48:37 I'm fine with something in api-ref per project or a central repo. tend to prefer the former so we can update it in the same patch that changes the microversion 20:48:46 dhellmann: much easier to collect the information too 20:48:47 mordred: yeah, that would be nice 20:48:54 cloning a thousand repos is not taht fun 20:49:01 ttx: ++ 20:49:06 yep, so comes back to the same as the driver feature matrix discussion. we agree there should be a common schema, there's disagreement on whether it's centralized (and whose responsibility it is to review proposed changes) or distributed across teams to each maintain their own 20:49:13 but, will it be kept up to date if it is centralized? 20:49:17 thing is - if there is a single document with a collection of discovery documents for a release 20:49:20 ttx: cloning them is more fun then forgetting to update the centralized repo 20:49:24 then one would imagine a tool for reading it 20:49:25 johnthetubaguy : will it be kept up to date if it's not? 20:49:25 what fungi said 20:49:32 which would mean maybe a _cloud_ would also post such a documentfor itself 20:49:35 that could also be read 20:49:40 without having to hit every service 20:49:47 and we baby step towards users knowing what's going on 20:49:53 dhellmann: it seems as likely as the api-ref to be up to date, if its part of that 20:50:05 yeh, api-ref has high incentive to stay up to date now 20:50:10 johnthetubaguy : they want the history, too, though, right? not just what's current? 20:50:14 * cdent gives mordred hope and glory 20:50:17 and that's part of a normal management process 20:50:27 dhellmann: that seems like a one time thing that needs adding as a release goal 20:50:30 anyway, we still need a schema 20:50:32 dhellmann: ironic is able to keep something like this up https://github.com/openstack/ironic/blob/master/doc/source/dev/webapi-version-history.rst 20:50:34 just needs a format 20:50:45 dhellmann: the schema could be append-only and you just stop updating it in stable branches? 20:50:56 ok. I'm not doing the work, so I'll let others decide on central or distributed data storage. 20:51:02 ttx: whoever is doing this from foundation side able to tackle the schema question, as they are parsing it? 20:51:04 please don't define a new schema. please please please 20:51:24 mordred: then you define the schema :) 20:51:31 mordred : are all of the services returning data in the same schema? 20:51:34 would like to bring up that for the Market Place, the projects are coming together on Nova's originally matrix in a ini file as a common format to suck in the information to the foundation's site. 20:51:39 mordred: available to work with jimmy on a format ? 20:51:40 mordred: what current schema do you have that encapsulates the release-by-release portion of the requirement? 20:51:44 dhellmann: it's nearly identical - the schema being the superset is not hard 20:51:47 these come from each project's repo. could probably just follow that idea 20:51:48 because I guess I don't quite see how we get from the single release one we have to the multi one 20:51:52 mordred : ok, cool 20:52:00 mordred: but if you solve it, will totally implement it 20:52:10 sdague: awesome. I will sign up to do that 20:52:29 * dims checks what's on mordred 's plate already :) 20:52:32 I just don't want them to be stuck until we agree on a file format when all they need is a piece of information from each project :) 20:52:39 * dhellmann hands mordred another plate to hold this new task 20:53:20 #agreed mordred will come up with a format that avoids creating yet another format for this information 20:53:23 ttx: well, mordred hopefully figures it out quick with jimmy 20:53:24 perhaps we could, in parallel, give them the info they need for the initial veesion of teh site and work on a format/parser so they don't have to keep asking? 20:53:30 then we implement quick 20:53:36 sdague: yes, I'm hopeful :) They are in the same TZ 20:53:42 any ask is basically just doing that with an adhoc schema 20:53:51 heck, they're in the same state a lot of the time 20:53:53 fungi: that's plan B if plan A takes forever 20:54:09 OK, I'll connect the dots 20:54:18 * TC election - this is nomination week 20:54:24 #link https://governance.openstack.org/election/ 20:54:34 As a reminder, the following members have terms ending in April: dims, dtroyer, flaper87, johnthetubaguy, mtreinish, thingee, ttx 20:54:42 Whether you plan to run (or plan not to run), you should probably post something this week to the -dev list. 20:54:50 * johnthetubaguy nods at ttx 20:54:54 Anything else, anyone ? 20:54:57 I have announced my non-candidacy http://lists.openstack.org/pipermail/openstack-dev/2017-April/114974.html 20:55:00 I added the footnote with implementation info that sdague requested to https://review.openstack.org/#/c/447031/ 20:55:00 TC vision draft is out 20:55:01 dhellmann, EmilienM, thingee: quick update on Forum topics selection, maybe ? 20:55:07 #link https://review.openstack.org/#/c/453262/ 20:55:08 sdague: ++ 20:55:12 ttx: we are working on the selection this week 20:55:23 * dims thanks thingee for his work and guidance on the TC! 20:55:25 and we are ranking the sessions 20:55:26 ttx: we have a process in place to start selecting before our meeting this thursday I believe? 20:55:27 we're reviewing now and meeting thursday to discuss the forum sessions 20:55:28 ttx: I think you are on the hook for doing the email broadcast around that 20:55:32 dims: he is not gone yet 20:55:43 sdague: yes 20:55:44 * mtreinish is still working on his election repo patch 20:55:46 :) 20:56:13 dims: i think that means there's still time to change his mind? ;) 20:56:16 sdague: we should tweet it :D 20:56:24 EmilienM: feel free :) 20:56:25 fungi :) 20:56:30 sdague: I'm bad at that 20:56:45 I was just making sure it got out there, and I think ttx said he was going to do the publicizing 20:57:26 sdague: I'm fine with sharing the task with whoever 20:57:27 does that come once we have the survey ready? 20:57:36 Just thoughts I would use my -dev ML juice for the cause 20:58:17 * ttx gmances at the TC backlog 20:58:22 glances even 20:58:41 we should get this out (castellan/oslo - https://review.openstack.org/#/c/451131/) 20:58:44 johnthetubaguy: good question, probably worth getting gothicmindfood looped in on that. It would be nice to have survey feedback ready to go 20:58:48 zaneb's Resolution on OpenStack's mission for cloud applications shall be back on the table next week 20:58:49 when the ML post hits 20:59:02 sdague: +1 20:59:08 dims : I think that one falls under the "one week with no objections" rule 20:59:21 ah cool thanks dhellmann 20:59:26 ttx: I updated the review after last week's discussion 20:59:36 zaneb: yes, looks like it's going well 20:59:52 I think that addresses everything sdague requested 20:59:54 mordred's "Add tag assert:never-breaks-compat" might be back if there is some new rev in it 21:00:10 zaneb: yes, thank you 21:00:12 I'll probably skip next meeting, due to the leadership training 21:00:13 I like the cloud application thing, its really the same thing I was trying to do with the VM & BM resolution, so I might think on how to do the same thing for that 21:00:15 a non-trivial subset of us will be in MI next week… 21:00:16 We'll also discuss the App Catalog team removal 21:00:18 sdague: cool, thanks 21:00:19 outta time... 21:00:20 EmilienM: as will i 21:00:26 Oh right 21:00:28 michigan \o/ 21:00:29 * fungi updates excuses list 21:00:32 We might want to skip 21:00:46 5 by my count 21:00:48 You clearly should not have a TC meeting during that week 21:00:57 that's a big group to be missing 21:00:58 ok, I'll move that discussion to the -tc ML 21:01:01 ++ 21:01:08 #endmeeting