15:10:46 #startmeeting bgpvpn 15:10:47 Meeting started Tue May 24 15:10:46 2016 UTC and is due to finish in 60 minutes. The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:10:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:10:50 hi everyone 15:10:51 The meeting name has been set to 'bgpvpn' 15:11:09 hi doude, matrohon, pcarver, timirnich 15:11:30 hello 15:12:03 sorry for starting late 15:13:43 hi 15:14:04 hi doude 15:14:13 let's see if matrohon is hanging around... 15:14:26 hi 15:14:36 hi matrohon 15:14:41 let's start 15:14:42 sorry, I forgot the meeting 15:14:56 me nearly as well, hence the late start :) 15:15:00 topics for today ? 15:15:11 - bagpipe driver fixes 15:15:23 - discuss in progress on advanced routing features 15:15:29 - what else ? 15:16:49 - doc updates 15:17:57 #topic doc updates 15:18:12 we have had a few changes submitted to improve documentation 15:18:26 some of them are typo fixes from your colleagues pcarver 15:18:48 and another contribution are from one of our colleagues :) 15:19:00 good to see 15:19:21 good starting point to learn the ropes and be able to contribute more :) 15:19:25 tmorin: I'm not getting nearly as much stuff reviewed as I'd like. But we do have new folks who have come on board and are getting started. 15:19:32 +1 15:20:24 pcarver, good to hear! 15:20:53 any other update on doc side ? 15:21:19 tmorin: I haven't written anything yet, but still reading more on API docs. 15:21:31 This in particular https://github.com/openstack/os-api-ref/blob/master/doc/source/usage.rst 15:21:49 * tmorin is having a look 15:21:58 The building blocks of how to generate the dynamic API docs is becoming clearer. 15:22:56 It was proof-of-concept-ed in Nova and now is being spun out for other projects to use 15:23:01 that look like an efficient/simple improvement to having rst tables to describe the API 15:23:17 but its' something different than relying on a tool like swagger, right ? 15:23:56 The goal is for all the OpenStack API docs to have a similar appearance with dynamic Javascript to expand and collapse details 15:24:21 And to share repetitive parts of the API, e.g. multiple calls that have common parameters 15:24:43 that seems to make a lot of sense 15:25:30 it fills a different goal than trying to have bgpvpn apear somewhere at http://developer.openstack.org/api-ref.html, but I don't know how important that goal was 15:25:31 i.e. http://developer.openstack.org/api-ref.html 15:26:04 I am not following you 15:26:16 No, I don't think so. I think this is the mechanism by which we get the API docs on http://developer.openstack.org/api-ref.html unless I'm not understanding it correctly. 15:26:20 is http://developer.openstack.org/api-ref.html generated with oslo-api-ref ? 15:27:01 As I understand it, the Docs team is trying to change things so that API docs can live in the project repo but be published on the API site 15:27:22 I mean: we can't just use oslo-api-ref in our doc/source tree and expect it to appear under http://developer.openstack.org/api-ref.html, right ? 15:27:50 pcarver: ok, so that would be the idea, but not yet fully implemented 15:28:09 tmorin: Exactly. I'm not sure it's 100% implemented yet 15:28:23 But see Anne Gentle's comments on https://review.openstack.org/#/c/319393/ 15:28:34 then we could rewrite the API doc to use oslo-api-ref ; we may have to move the file and add triggers later, but that would seem like a good start 15:29:32 following this comment, I found: https://review.openstack.org/#/c/319476/2/doc/contributor-guide/source/api-guides.rst 15:29:59 I'm still trying to grasp how all the pieces work or will work, but as best I can understand, the idea is that the API docs will live in each projets repo and be published to api.openstack.org similar to the way that developer docs live in repo and are published to docs.openstack.org/developer/ 15:31:03 that sounds good 15:31:30 so the first step would be to move API doc to an "api-ref/source" under networking-bgpvpn 15:31:54 well, not "move" but rather "recreate with oslo-api-ref" 15:32:33 and a second step may be required to trigger publication (unless the infra tools auto-detect and publish?) 15:32:33 Yes, I think so, move and convert to a combination of YAML and .inc 15:32:41 +1 15:33:09 Yes, that's what I think may still be missing, a publish jobs in the Jenkins config 15:33:13 but until the oslo-api-ref is published, we shouldn't remove the old-style API doc 15:33:21 pcarver: probably so 15:33:23 ok 15:33:26 sounds good 15:33:35 Right, not removing anything until we're sure that this new approach is fully baked 15:33:48 ok, do you plan to start this pcarver ? 15:34:26 Yes. It's definitely on my todo list. Just taking a while to follow the twisty path of documentation and reviews to figure out how it's all supposed to work. 15:35:21 yep :) 15:35:43 #action paul to kickstart convertion of the API doc to oslo-api-ref 15:35:44 :) 15:35:54 #undo 15:35:55 Removing item from minutes: 15:35:55 I think it's very much a work in progress and up until recently the Docs team has been mostly focussed on the WADL migration of old Docbook API documentation rather than the howto of projects that don't have any WADL/Docbook 15:36:09 #action pcarver to kickstart convertion of the API doc to oslo-api-ref 15:36:14 thanks pcarver :) 15:36:18 next topic ? 15:36:42 #topic advanced routing features 15:37:03 the discussion is in progress since last week in the etherpad at: 15:37:22 #link https://etherpad.openstack.org/p/bgpvpn_advanced_features 15:37:44 the use-cases which may call for advanced features start to be quite well described for most of them 15:37:52 more input is still much welcom 15:37:57 welcome 15:38:28 pcarver: you are likely to be interested by some of these use cases, don't hesitate to have a look 15:38:37 tmorin: I will 15:38:48 doude: as well ^^ 15:39:09 doude: seeing how it will map to SDN controllers will be interesting 15:39:32 wdeclercq: hi, I've just seen your joined 15:39:49 tmorin: hey o/ 15:39:53 wdeclercq: same comment as the one for doude above ^^ 15:39:55 hey :) 15:42:12 next topic ? 15:42:36 #topic bagpipe driver 15:42:51 I've pushed a few fixes for bagpipe driver last week 15:43:17 a bugfix for an issue where OVS flow cookie where not correctly positioned 15:43:36 fix pending review... 15:44:01 and two other changes to adapt tests and code to recent upstream changes in Neutron notifications 15:44:12 a side benefit is that this allowed to make the code simpler 15:44:38 some of these are also pending reviews 15:44:46 matrohon: ^^ :D 15:44:52 tmorin, I know... :) 15:44:58 ;) 15:45:26 next topic ? 15:45:36 #topic nuage driver 15:45:59 wdeclercq: I've pushed a simple change to update the doc with minimal info on nuage driver 15:46:13 #link https://review.openstack.org/#/c/317348/ 15:46:40 wdeclercq: if you could provide a pointer to nuage doc, that would be nice 15:46:53 Yes, I've seen that,so far all I can tell is that it's definitely not wrong, I've been trying to ask if we (nuage) has some public documentation online somewhere but I Got no reply there.... Guess I'll be resending some emails :p 15:47:09 wdeclercq: ok, good to know :) 15:47:38 wdeclercq: if you end up concluding that it can't happen, we can as well push this change without a pointer... 15:48:36 okay, I'll probably let you know by the end of this week. Unless mails get lost in a pile of other emails again 15:48:48 ok :) 15:48:49 thanks 15:49:06 #topic open discuss / wrap up 15:49:11 anything else to discuss ? 15:52:14 ok, we are done for today it seems :) 15:52:21 thanks everyone! 15:52:29 #endmeeting