14:00:04 #startmeeting javascript 14:00:08 Meeting started Wed Aug 10 14:00:04 2016 UTC and is due to finish in 60 minutes. The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:12 The meeting name has been set to 'javascript' 14:00:18 #link https://etherpad.openstack.org/p/javascript-meeting-2016-08-10 14:00:19 Agenda! 14:00:23 hello all 14:00:25 o/ hallo! 14:00:29 hi! 14:00:48 * krotscheck is typing one handed 14:00:49 hi 14:00:56 #chair vkramskikh 14:00:58 Current chairs: krotscheck vkramskikh 14:01:28 #topic Action Followup 14:01:36 yujunz, you there? 14:02:08 cardeois is also MIA 14:02:27 Got it 14:02:37 nevermind, he literally just walked in the door 14:02:39 I see yujunz in the etehrpad. 14:02:50 Well, we'll see if he joins later. 14:03:03 #topic eslint-config-openstack 14:03:18 We have a new version! It's... version 4.0.1, caused by some fiddling with infra and not doing things in the right order. 14:03:29 Thanks betherly and vkramskikh for getting those patches together 14:03:44 woop! :D 14:04:00 yay! 14:04:12 thanks krotscheck for all your help getting that out 14:04:17 This version contain eslint2015 rules, so go nuts everyone 14:04:29 btw, why is the new version 4.0.0, not 3.0.0? 14:04:30 Anyone want to take on the job of updating the version in our various projects? 14:04:33 release docs coming soon. releasing a patch momentarily to create docs for eslint-config-openstack 14:04:47 vkramskikh: THat's a long and terrible tale involving infra, race conditions, and entirely too few donuts. 14:05:15 (we did things out of order, wedging the gate, and infra didn't want to clar the tags for us) 14:05:47 Alright. 14:05:58 #action Unassigned Update eslint rules to 4.0.1. 14:06:09 #topic Fetch-Mock working 14:06:12 It's working! 14:06:15 :D 14:06:19 yay 14:06:23 thanks krotscheck 14:06:26 yay ! (and hi !) 14:06:30 #topic SDK Midcycle & Hack Session 14:06:48 Everything here pending the open call for cross-project design sessions. 14:06:57 Out of curiosity, who here is going to be at the summit? 14:07:09 * krotscheck will be there entirely dependent on his talk acceptance. 14:07:12 msmol and me will be there 14:07:14 I'm going to attend, but it's not 100% 14:07:16 * msmol raises hand 14:07:19 \o/ 14:07:23 Woo! 14:07:31 I'm pretty certain betherly will be there. 14:07:50 Zara? 14:08:01 and are you coming krotscheck ? 14:08:12 oh sorry didn't see it 14:08:13 i should be there dependant on talk acceptance and travel approval etc :) 14:08:14 * SotK hopes to be there 14:08:23 I should be, still need to get things confirmed but should have conference budget for it 14:08:39 I do not know. There are things in motion I can't really talk about yet that will both decrease my chances of attendance but increase my budget should a talk be approved. 14:08:59 Moving on 14:09:04 #topic DSVM & Doc patches 14:09:12 Those are separated, but seem to be stalled out right now. 14:09:30 There was a brief wedge from infra because they _REALLY_ wanted us to move to bindep. 14:09:34 Overall, that's actually a good thing. 14:09:45 what's bindep? 14:09:54 I'm glad you asked! 14:10:12 It's a tool that checks for a bindep.txt file in the root of a project and installs all the packages it finds there. 14:10:16 https://review.openstack.org/#/q/status:open+branch:master+topic:bindep 14:10:53 Since we're dependent on python-sphinx (the package), and they're moving to bindep, infra decided to make us shave this yak before landing these jobs. 14:11:16 Long story short: We're in charge of apt-get install now. 14:12:02 In the meantime, our devstack gate scripts have already landed, so once the various patches land we'll be good to go (and debug failures) 14:12:16 I'll keep poking infra this week 14:12:16 ok interesting. But can we install packages depending on tags or something? meaning we want some deps for devstack tests, but not everything for unit tests 14:12:23 #action poke infra about build patches 14:12:35 cardeois: I don't think so 14:13:03 Ok, so I suppose it's not such a big deal as it's for jenkins jobs only. 14:13:12 Right 14:13:20 And we're installing from the infra mirrors, so it's assumably faster 14:13:35 And do we have node6 + node4 here? 14:13:47 No, those have to be installed manually. 14:13:51 "Manually" 14:13:57 Those macros will not be removed from infra 14:14:04 ok I understand 14:14:10 But things like install-firefox, install-chrome, etc will 14:14:38 Any other questions? 14:14:40 Yes it will be faster because every macro right now run "apt-get update" first 14:14:48 Exactly 14:14:52 so it's really slow to make like 10 apt-get update for nothing 14:15:04 anyway, no more question thanks ! 14:15:20 #topic Action https://review.openstack.org/#/c/345529/ 14:15:24 It landed! 14:15:32 \o/ 14:16:01 #topic General News 14:16:08 So, Neutron's now default in Devstack 14:16:28 That impacts our roadmap going forward, and pretty much means that we can ignore nova-network ;) 14:16:42 Anyone know of any other news that impact us? 14:17:31 I'l... take that as a no. 14:17:45 #topic JavaScript SDK design discussion 14:18:12 Ok, two things I want to hit here, first the draft documentation that I put together, secondly "what utility libraries are ok to use" 14:18:38 #link https://review.openstack.org/#/c/351875/ 14:18:46 What do people think? 14:19:50 I'll start writing some "advanced" docs for keystone 14:19:56 that draft seems sensible, but I've only glanced at it so far 14:20:06 \o/ 14:21:47 I'm actually pondering getting a release of the SDK pushed with the minimal Keystone work. 14:22:13 Reason is that we can now query the service catalog, which would allow us to pull it into generator-openstack. 14:22:47 msmol: Tha'd be awesome. 14:23:12 No comments? 14:23:24 Ok, what about lodash/underscore? 14:23:32 as for utility libraries, there was a patchset with keystone client which used "underscore" library, so I put the topic on the agenda. I think we shouldn't use any utility libraries since we're going to be a library which shouldn't bee to large, but if we have to, let's go with lodash. there is a babel plugin which does lodash-specific treeshaking, so it won't affect the size of the library dramatically 14:24:02 #link https://github.com/lodash/babel-plugin-lodash 14:24:15 Intreesting. 14:24:23 I'm definitely a fan of minimal dependencies overall 14:24:37 Though I can appreciate the velocity gained from somehting like these libraries. 14:24:56 If I remember correctly, lodash can be included on a per-method basis, yes? 14:25:15 I believe we could go without any utility library - it's highly unlikely we will do some complex transformations with API output which would require lodash 14:25:16 I don't mind, lodash/underscore are essentially the same project at this point, so either one is fine by me. +1 for lodash since that babel plugin looks awesome 14:25:29 krotscheck: yes, or we could use that plugin 14:25:54 the nice thing about es6 i suppose is that *most* of the things underscore/lodash used to be used for has native functions now 14:26:41 So, we can adopt it conservatively? 14:27:06 Yeah I agree, let's try to use es6 features first, and if at some point the code gets too complicated, let's integrate lodash 14:27:14 +1 14:27:31 As long as we have an agreed path forward, I'm content letting each contributor make a decision on what tools to use. 14:27:45 So, lodash-but-try-to-use-es6-first? 14:27:57 yes 14:27:59 lgtm 14:28:02 +1 14:28:15 #agreed Prefer ES6 features, integrate lodash via babel-plugin-lodash when necessary. 14:28:31 Coolio. 14:28:41 While we're talking design... 14:29:05 vkramskikh: I was hoping to get a feature list from you, to get an understanding of what features need to be built out for Fuel to start adopting js-openstack-lib 14:29:48 krotscheck: Fuel just needs keystone, so the first release providing only keystone client totally makes sense for me 14:30:02 vkramskikh: Nice. 14:30:33 msmol: ALright, I'm going to start coding hard against keystone to get us to that point 14:31:08 msmol: I'll ping you via email to make sure we don't step on each other's toes. 14:31:27 Any other questions on general design things? 14:31:38 sounds good to me 14:31:54 Alright, moving on. 14:32:03 ok 14:32:08 #topic Project Status: js-openstack-lib 14:32:27 I have an update from larainema... 14:32:45 " for glance client, I am still working on it, a little slow process this week and also looking at the keystone client to integrate with it" 14:33:00 msmol managed to land his basic keystone client ! 14:33:03 \o/ 14:33:10 * krotscheck already updated a patch against it ;) 14:33:35 And we don't yet have volunteers for nova, cinder, neutron, and (other) 14:34:01 I have to say I really appreciate the work that cardeois and msmol have been doing for this project :) 14:34:21 The same goes for betherly on eslint-config-openstack 14:34:42 So, thanks everyone! 14:34:48 Does anyone else have any actual dev questions on this? 14:34:52 Else we'll move on 14:35:39 Oookoay. 14:35:46 #topic Project Status: generator-openstack 14:36:05 busy with some urgent task, sorry to miss the meeting again 14:36:05 [07:14:05] jsdoc and sphinx is still in progress 14:36:12 That's all we got there. 14:36:16 #topic Open Discussion 14:36:25 Anything? I've got nothing that hasn't already been mentioned. 14:36:58 I've got some questions on where we need to go for keystone client beyond what we've already got, but I guess krotscheck we can talk about specifics outside this meeting 14:37:35 msmol: Well, I think the big thing is "How does a different API client get the token and decorate its requests. 14:37:45 Also, there's this: http://developer.openstack.org/api-ref/identity/v3/index.html 14:38:45 providing methods that will eventually allow domain acccess, project creation, groups, regions... you get the idea. 14:38:54 But the big one is the first one. 14:39:32 cool. like you said above though let's communicate via email to avoid stepping on each others toes 14:39:36 Yep. 14:39:37 Yeah, oh and while keystone client is not that big right now, it would be nice to have a structure to handle multiple keystone version (and have something similar for Nova etc) 14:39:58 Oh yeah, microversioning. 14:40:02 Whooooey 14:40:06 We could develop only v3, but it'll be easy to add v2 or vx in the future 14:40:07 That's going to be a fiddly one. 14:40:20 Yeah, how do we handle microversion negotiation? 14:41:08 But you're right, for now v3 is probably the first step. 14:41:27 And then maybe have the OpenStack class dynamically set itself up based on what it discovers. 14:41:27 no idea, I didn't think about it. But I was just thinking it would be important to have that. For example our internal openstack was keystone v2 until last month... 14:41:47 I agree. 14:42:10 That also talks about how we handled version deprecation and EOL of old Api versions 14:42:11 yeah exactly, I just want Keystone class to be prepared to handle that 14:42:24 right 14:42:40 So, msmol and I have our work cut out for us :) 14:43:20 :D 14:43:46 #action Unassigned Keystone version selection 14:43:55 #action Unassigned brainstorm microversion 14:44:16 Anything else? Otherwise we'll end early 14:44:25 all good on my end 14:44:57 Alrightey 14:45:00 Thanks everyone! 14:45:03 #endmeeting