21:01:57 <ttx> #startmeeting crossproject
21:01:58 <openstack> Meeting started Tue Dec  2 21:01:57 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:00 <dhellmann> o/
21:02:02 <openstack> The meeting name has been set to 'crossproject'
21:02:03 <ttx> Our agenda for today:
21:02:11 <ttx> jeblair: can it wait until the end of the agenda ?
21:02:18 <ttx> #link http://wiki.openstack.org/Meetings/CrossProjectMeeting
21:02:33 <jeblair> ttx: yep.  i did not put it on agenda ahead of time, i lose.  :)
21:03:13 <ttx> I don't think johnthetubaguy is around yet, so let's invert the first two topics
21:03:26 <ttx> #topic Incompatible rework of client libraries (notmyname, morganfainberg)
21:03:32 * notmyname puts down his burrito
21:03:35 <ttx> So this was prompted by two different teams deciding to rework their client libraries in incompatible ways...
21:03:48 <ttx> ...and both proposing to do the new work in openstack-sdk, while keeping python client library for compatibility and CLI
21:04:01 <ttx> So I was wondering if there was a trend there, and if it's a technique we want to spread (or not)
21:04:09 <mikal> Hi
21:04:19 <ttx> morganfainberg, notmyname: could you briefly explain what you're after ?
21:04:30 <notmyname> I think your summary is pretty good
21:04:35 <morganfainberg> Or if sdk is the right place for this work?
21:04:49 <dhellmann> are the reworks incompatible with each other, or just with the old versions of the clients?
21:05:01 <ttx> old versions of the client iiuc
21:05:10 <morganfainberg> We have a lot of cruft for compat in ksc. Including cli. We would want to remove that rework it as a major rev. Or in sdk.
21:05:11 <bknudson1> I think we'd all be better off if we had a single python sdk.
21:05:18 <morganfainberg> bknudson1: ++
21:05:24 <jokke_> I do not agree
21:05:32 <dhellmann> yeah, I think there were several discussions at the summit to the effect of, don't rewrite your clients go help with the sdk
21:05:55 <morganfainberg> So this is the "is that really the way we're headed " topic.
21:05:58 <jokke_> We see already with tempest how it affects when the projects are not fully responsible for their piece
21:06:00 <morganfainberg> I think.
21:06:39 <notmyname> I'm not in love with "one sdk to rule them all", and I think there are issues we'll have to sort out later, but in the effort to focus on one thing (and since we see the -sdk team starting down the same road anyway) we wanted to work there. not a new thing
21:07:13 <notmyname> jokke_: yup. that's one of the things to figure out. (later)
21:07:38 <morganfainberg> notmyname: I am thinking perhaps we subteam the sections of the sdk. Overall team approvers and the project teams move towards contributing there instead of the to isolated clients.
21:07:45 <morganfainberg> Swift might be an exception.
21:07:50 <dhellmann> as a consumer of a cloud, I don't want to have 15 different clients with their own notion of what a good API is, so from that perspective having a team motivated to work on the SDK and keep it uniform where appropriate is an improvement
21:07:59 <morganfainberg> Due to its heavy consumption both in and out of openstack.
21:08:08 <maishsk> dhellmann: +1
21:08:10 <notmyname> I'm not too concerned about -sdk project structure right now. I'd much rather actually have code first
21:08:18 <ttx> yes, I think being under the same umbrella with some sdk-core to ensure consistency wouldn't hurt
21:08:33 <dhellmann> some of the discussions at the summit assumed that internally the cloud would still use the project-specific clients, at least for a while
21:08:37 <morganfainberg> dhellmann: I agree.
21:08:38 <ttx> as long as each project can own its piece too
21:08:45 <jokke_> notmyname: IMHO principal issues like that which has already proven to break things should be fixed before jumping into that train
21:09:37 <morganfainberg> There is one concern I have re unified sdk package
21:09:38 <ttx> I just have no idea of the state of the -sdk project right now, and if they are structured to drive some commoncality already
21:09:45 <notmyname> we're stating in swift that new dev work for client sdk features should happen in openstack-sdk. which means that yes we do have ownership of it (even if reviews aren't figured out yet)
21:09:46 <ttx> commonality*
21:10:01 <jungleboyj> o/
21:10:04 <morganfainberg> That is we often release more frequently to address issues / features in client.
21:10:13 <dhellmann> ttx: there's still only a small team, but I'm sure we would welcome other contributors
21:10:43 <asalkeld> jokke_, weren't  the issues with tempest largely due to gating - or a nervousness to add new flakey tests, not that it was one repo
21:10:50 <morganfainberg> If sdk is released monolothically this could prose more issues on that front.
21:11:00 <dhellmann> morganfainberg: how so?
21:11:10 <ttx> my concern is more to do it right before we start "supporting" it and ensure strong backward compat. I don't want us to jump to another project every time we want to rewrite in incomatible ways :)
21:11:16 <asalkeld> jokke_,  the sdk is in a different boat i think
21:11:21 <morganfainberg> dhellmann: we often track as close as we can for ksc to new features.
21:11:45 <morganfainberg> dhellmann: if sdk was released less frequently, new features would only be available in rest not Python.
21:11:57 <ttx> but I guess we can land code there and not yet "release" it
21:12:01 <ttx> or set wild expectations
21:12:09 <dhellmann> morganfainberg: I don't think the SDK team would want that either
21:12:27 <bknudson1> does the openstack CLI use the SDK?
21:12:47 <morganfainberg> dhellmann: right. Just want to raise the concern that coordinating a release is slower than each project. Not that I am against using sdk.
21:12:52 <jokke_> asalkeld: I do not know exact details, but when we tried to figure out how to move some of the testing to Tempest we were pretty bluntly told to not do that as there was no resouces to own those tests.
21:12:52 <dhellmann> ttx: concern about starting new projects to allow incompatibilities is fair, but in this case we, as a community, have been talking for a LOOOONG time about how we want to improve the overall state of the clients
21:13:01 <dhellmann> morganfainberg: have you talked to briancurtin?
21:13:15 <morganfainberg> Nope. Just thought about this just now. ;)
21:13:47 <dhellmann> morganfainberg: ok, I suggest you and notmyname chat with briancurtin or dtroyer if you haven't already (see #openstack-sdks)
21:13:55 <asalkeld> jokke_, well i hope we don't get that in the sdk
21:14:04 <morganfainberg> dhellmann: will do.
21:14:09 <notmyname> I have chatted with them both several times. they've been very helpful
21:14:11 <dhellmann> I think this is the direction we want to go, but I don't think it's a good idea to sneak up on them :-)
21:14:15 <dhellmann> notmyname: cool
21:14:20 <ttx> dhellmann: I'm not that concerned about project hopping as a work around to avoid backward compat issues. More concerned about random code landing there and having to be supported, before the SDK team defines guidelines they are happy with
21:14:45 <ttx> but I think it's a non-issue at this point
21:14:46 <dhellmann> ttx: sure, that makes sense
21:15:10 <ttx> I think openstack-sdk is a great place to land a next-gen API
21:15:13 <morganfainberg> I'll make it a point to chat with them soon and/or point jamielennox over to them.
21:15:23 <ttx> (client API)
21:15:27 <notmyname> no! the -sdk is not the api. it's a wrapper to the api
21:15:31 <dhellmann> morganfainberg: jamie has been contributing already, iirc
21:15:39 <morganfainberg> dhellmann: probably.
21:15:53 <bknudson1> so the alternative is to find some way to make incompatible changes to the existing libs.
21:15:57 <ttx> notmyname: ack
21:16:03 <asalkeld> notmyname, it's a library api surly
21:16:04 <ttx> API was the wrong term.
21:16:15 <bknudson1> either with a python-*client2 or a new module in the python-*client
21:16:22 <jokke_> bknudson1: or work around to make to incompatible changes compatible ;)
21:16:31 <dhellmann> bknudson1: it's not just a matter of incompatibility, though, it's a case of every project having to do the same work instead of having it done in one place
21:16:45 <notmyname> I'm concerned that we'll get too much into The Way Things Ought To Be by all piling on and saying this is the new openstack way to do an sdk. and we don't even really have much actual code there
21:17:22 <morganfainberg> jokke_: the incompatible changes are because we are carrying a lot of tech debt to maintain compatibility.
21:17:52 <morganfainberg> jokke_: for the most part. It's a "time to clean some of this up" but we can't break previous deployments.
21:17:53 <notmyname> I think it's a good way to figure out what we want to have. the -sdk team is essentially starting greenfield and it's a good opportunity to share and make things better without duplicating too much effort (eg teams and -sdk doing new versions)
21:18:02 <ttx> notmyname: ack
21:18:08 <morganfainberg> notmyname: ++
21:18:13 <bknudson1> jokke_: as morganfainberg says, we've been piling on workarounds to make incompatible changes compatible
21:18:16 <dhellmann> notmyname: it's possible that it's premature to say we won't make changes to the project-specific clients, but it's worth spending some time actually talking about how work on the sdk might work
21:19:04 <notmyname> dhellmann: sure. and the existing clients (eg python-swiftclient) still have enough scope to require new stuff to be added and bugs to be fixed
21:19:10 <dhellmann> notmyname: right
21:19:28 <ttx> OK, I think the next steps will happen in code proposed to openstack-sdk and discussions on the ml
21:19:43 <ttx> wuld be good to revisit this topic in a few months
21:19:51 <ttx> to check for progress
21:20:09 <notmyname> dhellmann: but in the attempt to focus, we're saying we want to see new stuff go there instead of swiftclient
21:20:14 <notmyname> ttx: yes! definitely
21:20:22 <ttx> last comments on this topic ?
21:20:27 <morganfainberg> Ttx +1
21:20:36 <dhellmann> notmyname: yeah, hence my "may be premature" comment
21:21:04 <ttx> #action ttx to add a revsiit of this topic to the agenda backlog in +2months
21:21:26 <ttx> still no johnthetubaguy?
21:21:39 <ttx> apevec: around?
21:21:44 <apevec> ya
21:21:46 <ttx> #topic 2014.2.1 point release status (apevec)
21:21:51 <ttx> apevec: Floor is yours
21:21:55 <ttx> #link https://etherpad.openstack.org/p/StableJuno
21:22:11 <apevec> yep, that's the etherpad with the status
21:22:18 <apevec> I've posted exceptions proposals
21:22:29 <apevec> on openstack-dev
21:22:34 <ttx> apevec: couldn't review them today. Is it OK if I review them tomorrow morning ?
21:22:39 <apevec> yep
21:22:39 <ttx> or too late ?
21:22:41 <ttx> ok
21:22:57 <apevec> there aren't known blockers to me,
21:23:11 <apevec> so release will be as scheduled Thu Dec 4
21:23:28 <apevec> I've just one cross-proj exception to raise here:
21:23:33 <apevec> https://review.openstack.org/#/q/status:open+branch:stable/juno+topic:openstack/requirements,n,z
21:23:44 <Daviey> apevec: There seems to be more release note requirements for this release.  How are the release notes looking?
21:23:47 <apevec> I'd like to push this cap reqs sync before the release
21:23:55 <jungleboyj> apevec: There is one more exception I may want to request:  If I can get this approved we should also get it into stable/Juno: https://review.openstack.org/#/c/138526/
21:24:11 <apevec> Daviey, I'm still collecting them, will review tomorrow
21:24:16 <Daviey> Super
21:24:26 <apevec> jungleboyj, please add in etherpad
21:24:32 <david-lyle> apevec: at least one patch proposed has a -2, https://review.openstack.org/#/c/138018/
21:24:35 <jokke_> apevec: Glance and specifically glance_store would greatly benefit if we get the cap in already for this round
21:24:37 <apevec> and reply in openstack-dev thread
21:24:38 <ttx> apevec: we should get all those in
21:24:38 <jungleboyj> apevec: Will do now.
21:24:53 <eglynn> apevec: FYI I removed one of the ceilo exception requests from that etherpad as it already inadvertantly landed ... https://review.openstack.org/138315
21:24:55 <ttx> will +2/aprv tomorrow morning if nobody else beat me to it
21:24:57 <apevec> david-lyle, all have scripted -2 that's freeze
21:25:16 <eglynn> apevec: I wasn't clear enough with my "Pending grant of 2014.2.1 freeze exception" comment on gerrit, shoulda -2'd it
21:25:30 <apevec> eglynn, I think all ceilo exceptions are fine to merge, you're PTL after all :)
21:25:37 <eglynn> apevec: coolness :)
21:25:47 <apevec> just wanted to wait for more feedback
21:26:20 <ttx> apevec: ok, anything else ?
21:26:32 <apevec> that's it from me, I'd just like to thank adam_g to tracking down that last gate issue :)
21:26:47 <apevec> (ironic grenade thing)
21:27:04 <ttx> apevec: juno gate status is green now ?
21:27:15 <apevec> yes, workaround in grenade juno was merged
21:27:42 <apevec> ttx, and after Dec 4 we implement new team structure right?
21:27:55 <ttx> apevec: what do you want for the xceptions: a reply to the thread, or +2/approvals on the reviews themselves ?
21:28:03 <ttx> apevec: yes
21:28:04 <apevec> ttx, both :)
21:28:19 <ttx> ok
21:28:20 <apevec> I need also to remove my scripted -2s
21:28:48 <ttx> After the release we'll work to set up the new teams (with fungi's help) and the new cappings (with anteaya's help)
21:28:58 <fungi> sounds good
21:29:15 <SergeyLukjanov> apevec, is it ok if I'll add a 1-2 excpeptions for sahara patches? (need to recheck)
21:29:32 <apevec> SergeyLukjanov, you're the boss for sahara
21:29:51 <ttx> I'd say today is the latest to propose exceptions though :)
21:29:58 <ttx> we need to land them all
21:30:10 <apevec> ack
21:30:12 <anteaya> came back from a walk and I'm doing stuff
21:30:17 <ttx> that should tyake most of wednesday :)
21:30:22 <anteaya> hope I don't disappoint
21:30:41 <ttx> Any more comment on 2014.2.1 ?
21:31:24 <ttx> still no johnthetubaguy so I guess we'll skip the spec topic and discuss it next week, sorry about that
21:31:32 <SergeyLukjanov> ttx, apevec, oh, just see that there is no need to add more exceptions, thx for apevec for handling https://review.openstack.org/#/c/135549/
21:31:42 <ttx> #topic Open discussion & announcements
21:31:53 <ttx> We had 1:1 syncs today, nothing really remarkable. Logs at:
21:31:57 <ttx> #link http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-12-02-09.10.html
21:32:30 <ttx> jeblair: you had something ?
21:32:34 <jeblair> hi, we're working on a change to the third-party ci process which will enable more self-service from folks standing up third-party ci systems, as well as giving ownership of voting rights to projects themselves
21:32:34 <jeblair> here is the documentation change that just merged: https://review.openstack.org/#/c/137240/
21:32:34 <jeblair> we'll be sending out an email to the dev list soon with information for projects
21:32:34 <jeblair> but the upshot is that project drivers will be able to allow/disallow individual CI system voting on their projects
21:32:53 <jeblair> just wanted to give folks an extra heads up about that
21:32:54 <notmyname> jeblair: cool
21:32:56 <mikal> jeblair: oh, nice
21:33:16 <anteaya> right now I have emagana and mestery for neutron, jogo for nova and DuncanT and jungleboyj for cinder
21:33:16 <morganfainberg> cool
21:33:25 <anteaya> as third-party project drivers
21:33:33 <mikal> anteaya: we can't reuse the nova-drivers group?
21:34:12 <anteaya> mikal: do the nova-drivers group want to learn what is required to be effecitve here?
21:34:17 <morganfainberg> mikal, ++ usign a current could be nice.
21:34:25 <anteaya> I asked and asked an noone in nova wanted to help
21:34:35 <anteaya> finally twisted jogo's arm
21:34:36 <mikal> anteaya: heh, I'd have to ask them. I think most would be ok with it at least.
21:34:45 <anteaya> now if nova-drivers want this, I'm all for it
21:34:46 <mikal> anteaya: the disinterested few could just ignore the requests
21:34:55 <mikal> anteaya: ok, let me take it to them and see what they say
21:34:58 <anteaya> just as long as it doesn't keep getting bounced back to me
21:35:03 <anteaya> mikal: let me know the outcome
21:35:41 <anteaya> mikal: the problem is the distinterested few are the majority
21:35:47 <anteaya> then it is all on my plate again
21:35:51 <morganfainberg> anteaya, when Keystone starts getting 3rd party CI (yes it's planned) I'll talk to you about who should be in the group or if keystone-drivers is suffiecient
21:35:51 <anteaya> hoping this changes things
21:35:58 <clarkb> anteaya: the plan was make nova-release do it until screaming happened
21:36:02 <anteaya> morganfainberg: I look forward to it
21:36:09 <anteaya> mikal: it is on you dude
21:36:17 <bknudson1> keystone has/had 3rd party ci for DB2
21:36:24 <anteaya> and johnthetubaguy I guess
21:36:28 <morganfainberg> bknudson1, haven't seen it vote in a while.
21:36:37 <bknudson1> morganfainberg: y, it's been broken.
21:36:39 <anteaya> bknudson1: great, I'll show up in a keystone meeting and learn more
21:36:46 <mikal> anteaya: I shall lead from the front
21:36:50 <anteaya> morganfainberg: add me to an agenda and we can dicuss
21:36:56 <anteaya> mikal: awesome, you're it
21:37:00 <jeblair> anyway, there will be details about group management in the email; i believe that we can accomodate either reusing existing groups or new ones if needed.
21:37:06 <morganfainberg> anteaya, ++ lets aim for not next week but the following (as i'm out next)
21:37:24 <anteaya> morganfainberg: neutron mid-cycle for me next week, let's do following
21:37:24 <saloa> #openstack-neutron
21:37:29 <morganfainberg> ++
21:38:11 <eglynn> bknudson1: interesting, who runs the DB2-based CI?
21:38:17 <jeblair> also gerrit downtime on saturday for some project renames: http://lists.openstack.org/pipermail/openstack-dev/2014-December/052031.html
21:38:29 <jeblair> ttx: end
21:38:36 <bknudson1> eglynn: IBM we've got folks in beijing
21:38:36 <ttx> Alright! Anything else, anyone ?
21:38:45 <eglynn> bknudson1: cool ... /me asks in relation to the ceilo DB2 storage driver
21:39:19 <maishsk> I was speaking to annegentle today and she said it might relevant to bring this up here.
21:39:27 <maishsk> I wondering if someone could explain why there are differences in the way specs are displayed in
21:39:38 <maishsk> http://specs.openstack.org ?
21:39:50 <anteaya> maishsk: what differences are you seeing?
21:39:53 <ttx> differences between what and what ?
21:39:56 <maishsk> For example http://specs.openstack.org/openstack/nova-specs/
21:40:01 <maishsk> as opposed to http://specs.openstack.org/openstack/heat-specs/
21:40:20 <anteaya> what differences?
21:40:20 <maishsk> they are presented in very different ways. Is that on purpose?
21:40:38 <anteaya> that is based on how the project sets up their information
21:40:47 <ttx> maishsk: ah, that would be a :titleonly: directive missing, probably not on purpose
21:40:49 <dhellmann> maishsk: it looks like the toctree settings are different in the 2 projects, and so nova is showing fewer headings than heat
21:40:50 <mikal> maishsk: the heat format wouldn't work for nova
21:40:55 <mikal> maishsk: we have too many specs
21:41:20 <mikal> maishsk: nova also does an "approved" vs "implemented" division that other projects probably don't do
21:41:21 * ttx is quickly becoming a sphinx guy
21:41:22 <anteaya> mikal: yeah, no kidding
21:41:38 <jeblair> someone might propose a change to heat-specs to change that, i think it's probably already too long in heat to be useful too
21:41:50 <maishsk> As someone who came to look at the different specs today - it is highly confusing.
21:42:02 <mikal> If people are itnerested in how we do the implemented thing, I could document that one day
21:42:06 <ttx> maishsk: actually, we were supposed to discuss convergence in -specs between projects
21:42:11 <ttx> at this meeting
21:42:13 <mikal> We do redirects and everything
21:42:30 <jeblair> mikal: fancy!
21:42:34 <ttx> but the person who asked for it is probably buried in work so we'll discuss that next week instead
21:42:44 <maishsk> ttx: ok then
21:42:56 <mikal> jeblair: you say that like someone who hasnt' read the sphinx plugin code
21:43:09 <ttx> maishsk: agree that the current situation can be a bit confusing, so we'll see if there are ways to make that a bit more convergent
21:43:27 <annegent_> darn I was hoping we'd talk about it anyway
21:43:29 <jeblair> mikal: don't shatter my illusions!
21:43:42 <ttx> #action ttx to add maishsk's question on specs.o.o differences on the spec convergence topic next week
21:43:55 <notmyname> ttx: is there bg info to read for that conversation
21:43:56 <notmyname> ?
21:44:01 <ttx> annegent_: we can! I just don't want to steal John's
21:44:06 <annegent_> ttx: sure
21:44:09 <bknudson1> there's probably some things that work well with specs for some group that others should pick up.
21:44:24 <ttx> notmyname: I think John wanted to compare how people used specs and see where they could adopt common practice
21:44:32 <ttx> a follow-up on the session we had at the summit
21:44:41 <annegent_> maishsk: ttx: did you get to the question of "what's the way to know whether a spec is being worked?"
21:44:59 <mikal> Oh, can I answer that one?!?
21:45:05 <mikal> I like sounding like I know stuff
21:45:06 <jokke_> maishsk: thnks for bringing that up ... first time I stumbled upon specs.openstack.org :)
21:45:09 <ttx> annegent_: I would follow the link to the blueprint :)
21:45:13 <ttx> but that's only me
21:45:13 <mikal> Dammit
21:45:14 <morganfainberg> annegent_, we [keystone] just merged the backlog concept... but we don't have anything there yet...
21:45:17 <mikal> There goes my answer
21:45:18 <annegent_> ttx: I figured Launchpad was more truth
21:45:22 <ttx> mikal: oops sorry
21:45:26 * jeblair awards 10 points to mikal
21:45:28 <mikal> Heh
21:45:35 <annegent_> gold star sticker to mikal
21:45:39 <mikal> Although nova also has the concept of wishlist specs now, which are always unowned
21:45:40 <morganfainberg> but soon. i expect "available" specs [not active] will be in keystone's backlog.
21:45:47 <mikal> I don't think we've actually merged one yet though
21:45:50 <devananda> fwiw, Ironic has adopted the idea of a backlog as well, including allowing shorter specs there (just problem description and goals, no specifics)
21:45:54 <annegent_> In patching all the specs repos with API info I've found different requests
21:46:09 <mikal> Yeah, nova modelled off keystone there
21:46:25 <jeblair> mikal: i like the idea that a wishlist spec must never have an owner ;)
21:46:29 <devananda> we also haven't had to deal with a large number of approved but not implemented specs at the end of the cycle yet. could happen this cycle ...
21:46:30 <annegent_> basically working with a stable API can go right into the project repo, one that is still being worked and needs discussion as things are added go into specs
21:46:41 <morganfainberg> devananda, that is my expectation.
21:46:43 <mikal> jeblair: a wishlist spec is also truncated for nova
21:46:55 <mikal> jeblair: i.e. you don't have to fill in the whole template, just the user story
21:46:56 <dhellmann> devananda: I had a small number that I reverted from oslo-specs last cycle (I just deleted them)
21:47:03 <morganfainberg> mikal, ++
21:47:10 <mikal> dhellmann: le huh
21:47:11 <ttx> dhellmann: devananda said he liked my spec2bp v2 version
21:47:15 <mikal> We had heaps of not implemented ones
21:47:20 <annegent_> also I guess I suprised a few people with the API spec patches -- that'll teach you to read What's Up Doc? I thought to myself
21:47:29 <mikal> So we have a fast track approve for kilo, and mark which ones got implemented in the spec repo
21:47:32 <mikal> Nothing gets deleted
21:47:38 <ttx> dhellmann: waiting for +1s on that one :)
21:47:41 <devananda> for ironic, a wishlist (/backlog) may or may not be truncated. it requires 2 of the headings, allows the rest, and rejects any new headings.
21:47:41 <morganfainberg> annegent_, Keystone loves the API specs being in that repo btw. Thanks for all the hard work.
21:47:52 <devananda> mikal: my approach last cycle: don't approve specs that I didn't think would make it in :)
21:48:08 <dhellmann> ttx: I'll take another look
21:48:18 <ttx> dhellmann: thx, won't merge it until you +1 it.
21:48:21 <dhellmann> devananda: ++
21:48:25 <ttx> as my only user..
21:48:28 <annegent_> thanks morganfainberg
21:48:32 <ttx> (of v1)
21:48:40 <annegent_> still found tables that weren't rendered well, but le sigh
21:48:49 <ttx> everyone speaks french now
21:48:54 <devananda> ttx: fwiw, now that spec2bp lets me manipulate BP's for unapproved specs, this is much much simpler
21:48:55 <maishsk> :)
21:48:55 <ttx> le french.
21:48:57 <morganfainberg> annegent_, happens, but we're way better than *go look at github*
21:48:58 <anteaya> le yay
21:49:11 <morganfainberg> ttx, le somethingthatsoundsnotfrench
21:49:18 <ttx> le spec2bp.
21:49:24 <morganfainberg> hehe
21:49:29 <anteaya> marketing alert
21:49:47 <annegent_> morganfainberg: heh, hadn't thought of that
21:50:02 <annegent_> so generally we're separating out the API spec template from the others
21:50:05 <mikal> I want a spec2bp tshirt
21:50:15 <annegent_> it's a bit experimental though, and nova microversions will certainly make it harder
21:50:16 <anteaya> it worked
21:50:30 <dhellmann> ttx: I'm still worried about what's going to happen to specs where the project is stevedore, cliff, and taskflow
21:50:40 <dhellmann> those should be oslo-specs, not foo-specs
21:50:43 <annegent_> hence a lot of discussion on https://review.openstack.org/#/c/129329/ and https://review.openstack.org/#/c/130550/
21:51:05 <ttx> dhellmann: you can set the blueprint URL field so that it finds the spec.
21:51:06 <annegent_> I also noticed that some projects test their templates for empty sections
21:51:25 <ttx> dhellmann: that's the ultimate workaround for weirdly-placed specs.
21:51:42 <ttx> dhellmann: we can improve from there, but it should already be usable.
21:52:00 <ttx> context for bystanders: https://review.openstack.org/#/c/108041/
21:52:06 <morganfainberg> annegent_, we at least check that all the sections exist.. i don't think if we care if they are empty
21:52:33 <annegent_> morganfainberg: seems like a good idea, just didn't do the same for API template since that template isn't really straightforward
21:52:50 <morganfainberg> annegent_, ++
21:53:00 <dhellmann> ttx: could you add an example of how I would do that to the readme, because I'm not seeing it
21:53:05 <annegent_> and I'd prefer to leave it pretty free form (API changes)
21:53:31 <devananda> annegent_: how are changes which affect both API and something_else being handled? (pardon the uninformed question if this is obvious)
21:53:44 <ttx> basically specrepo is not used if bp.specification_url is set and resembles a proper spec link
21:53:45 <annegent_> devananda: so far we haven't tested that
21:53:55 <ttx> dhellmann: will do
21:54:03 <annegent_> devananda: though morganfainberg may have already and I missed it
21:54:13 <ttx> #action ttx to add to spec2bp README how to use le ultimate workaround
21:54:15 <dhellmann> ttx: so now I have to manage those URLs by hand? that's backwards from what we were doing before
21:54:31 <devananda> I mean, I haven't had a spec come in to Ironic which changes the API without doing so because it seeks to change something else
21:54:46 <morganfainberg> devananda, we tend to include the API changes in the spec proposal - in some cases we do the API changes as a separate patch but require that change to merge before the code does.
21:54:47 <annegent_> devananda: https://review.openstack.org/#/c/130277/ is an example
21:55:10 <morganfainberg> devananda, in the spec proposal, i mean in the same patchset
21:55:23 <dhellmann> ttx: I just checked some stuff in to oslo-specs today that ensures that there is a blueprint somewhere in the oslo project group for each spec, so that when I run spec2bp it can update all of the fields on the blueprint
21:55:24 <annegent_> morganfainberg: oh maybe https://review.openstack.org/#/c/130277/ isn't an example
21:55:26 <morganfainberg> devananda, but that's keystone (we've long used identity-api in this way)
21:55:27 <devananda> ooh
21:55:49 <dhellmann> ttx: https://review.openstack.org/#/c/138392/
21:55:50 <devananda> morganfainberg: same spec document, separate change set
21:55:54 <ttx> dhellmann: it will set the URL automatically if everything is placed where it should be. But if it can't find the spec where it is looking, it will check the URL in the blueprint just in case
21:56:22 <morganfainberg> devananda, either way works, i *prefer* the same changeset to include the spec proposal *and* api changes ... but that isn't realistic to enforce.
21:56:23 <ttx> so you can workaround those corner cases by explicitely setting the URL.
21:57:06 <ttx> dhellmann: that's what the error message on lines 120-128 says
21:57:09 <dhellmann> ttx: you're saying that the solution to my problem is the problem I am trying to express
21:57:17 <dhellmann> I do not want to have to type URLs into launchpad
21:57:33 <ttx> I understand that.
21:57:42 <morganfainberg> devananda it has the advantage though that you can [in theory] revert out a spec and the API changes at the same time if you wanted to/needed to
21:58:31 <ttx> dhellmann: ok, I'll try to make it cover corner cases at the first iteration
21:58:53 <ttx> I just kind of wanted it in since some people started to use it, and then fix it to support corner cases
21:58:56 <dhellmann> ttx: the version I have now covers these cases, that's why I'm concerned
21:59:06 <ttx> dhellmann: fair enough
21:59:14 <ttx> ok, time to close
21:59:29 <ttx> Thanks, everyone!
21:59:35 <bknudson1> merci
21:59:36 <ttx> #endmeeting