14:00:18 #startmeeting javascript 14:00:19 Meeting started Wed Jul 20 14:00:18 2016 UTC and is due to finish in 60 minutes. The chair is vkramskikh. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:23 The meeting name has been set to 'javascript' 14:00:25 hi everyone! who's here? 14:00:28 o/ 14:00:31 Hey ! 14:00:43 I'm here 14:00:43 #link https://etherpad.openstack.org/p/javascript-meeting-2016-07-20 14:00:45 hello 14:00:46 here is the agenda 14:01:09 #topic where shall we publish the api doc built by jsdoc? 14:01:28 hi! 14:01:30 Is there any hosted place for openstack docs we could use? 14:01:43 I have the same question 14:01:47 o/ 14:02:10 I know there is http://docs.openstack.org/ , but don't know how to post anything there 14:02:17 * krotscheck is here, but had to skip chairing this time because his son's too sick for daycare. 14:02:36 * krotscheck isn't certain about docs. 14:02:44 krotscheck: hope he gets well soon!! 14:02:59 I can check with the docs team, I beleive it's just another job that we need to add. 14:03:25 Yeah, it would definitely be cool to be in an official openstack doc 14:03:37 docs.openstack can be amended from within the project i think 14:03:41 so it's let's confusing for people using the lib 14:03:44 #action krotscheck to contact docs team regarding jsdoc hosting 14:03:49 Well, we're not an official project, we're just in the big tent, but I'll explore options. 14:03:58 so if you have a section called docs and set the project up for doc jobs i think it sorts itself... 14:04:08 It seems there is an catagory of api doc in docs 14:04:13 betherly++ 14:04:32 Also, there's docs vis-a-vis getting started with the openstack libs, i.e. shade and so forth, which we should probably hook into. 14:04:42 krotscheck: indeed, neither is ironic-ui technically as its a subproject, but since it has its own repo it should have the ability to have docs within it 14:04:44 Lots of things for me to look at :) 14:05:07 krotscheck: do you want me to take a look into the docs side from within the project and see if that can be done in this scenario? 14:05:23 betherly: If you're volunteering, sure! 14:05:28 :D 14:05:39 krotscheck: sure ill add it to my agenda for tomorrow 14:05:46 betherly: ALrightey 14:06:08 #action betherly to help krotscheck with the docs 14:06:32 awesome, next topic :) 14:06:37 #topic We've just merged all build/testing stuff - what next? Project architecture - what should it be? 14:07:03 it was a topic for the previous meeting, but I failed to answer this question 14:07:20 I believe krotscheck has lots of ideas what to do next :) 14:07:20 it's a bit of a broad topic, no? 14:07:37 I think we should adopt an architecture similar to pythonopenstack-sdk. I actually don't know how it's architectured, but would be nice to have a seamless transition for people using python or js sdk 14:07:53 I agree 14:07:56 Either that or shade. 14:08:00 python is very different from js 14:08:04 Honestly, shade seems to be a bit more popular. 14:08:18 With that in mind, we can also draw inspiration from pkgcloud 14:08:29 could you please give me a link to that shade? I have no idea what it is 14:08:32 Alright with shade then 14:08:43 http://docs.openstack.org/infra/shade/ 14:08:46 #link http://docs.openstack.org/infra/shade/ 14:08:57 thanks, I'll take a look 14:09:16 azemlyanov I agree we should code for js, but have our public api similar to one of those sdk in python 14:09:21 My initial thoughts were: "let thing = new OSCloud(config);" 14:09:23 Internals is another matter I guess 14:10:05 The tricky thing is- what does that instance look like, since different clouds may have different services available. 14:10:15 And discovery can't happen until we're authenticated against keystone 14:10:16 JS discourage exceptions that is standard in Python, JS is async and rely on promices 14:10:30 promises 14:10:32 azemlyanov: Promises or callbacks ;) 14:10:39 or callbacks of cause 14:10:40 (Anyone here prefer callbacks to promises? I don't) 14:10:57 would be nice to support both 14:11:03 both are better 14:11:24 in simple cases callback is often prefferable 14:11:27 You're right, promises is definitively better 14:11:46 Well it's nice for chaining calls 14:12:17 I suggest to support promises only, don't see any value in supporting both. jquery 3 dropped support for callback for jqXHR 14:12:36 +1 14:13:25 We'll see how it shakes out once we start writing code. I'm more curious about the "create api instance, discover services" step. 14:13:26 I think we should try to implement something simple like Keystone client and discuss all that stuff in gerrit 14:13:32 okay, so what kind of promises? does ES6 have "official" promises built-in, or was that pushed to ES7 or whatever it's going to be called 14:14:08 msmol: yes there are native Promises, and fetch() already utilizes them 14:14:08 #link http://caniuse.com/#search=promise 14:14:08 msmol: yes, they are built in: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise 14:14:52 I agree with vkramskikh: MOst of the complicated bits regarding initialization of a cloud, including auth, config structure, and service discovery, will be best discussed in code. 14:15:03 And, well, keystone is the first thing we really need to implement. 14:15:18 Yes 14:15:35 One thing I'd like to make sure we keep in mind though is that services may not be deployed with keystone, so that auth layer should be optional. 14:15:37 indubitably 14:17:02 Does anyone want to take a stab at it? Gathrt requirements from this discussion and throw some code at the wall? 14:17:58 I'd like to, but I'm already late with the devstack setup 14:18:36 Sounds like we don't have resources this coming week to write that code. 14:18:49 * msmol slowly raises his hand 14:18:58 Wooo! 14:19:46 I'll do my best, hopefully either of cardeois or jprivard will be able to lend a hand or two as well, seeing as they're sitting right next to me ;-) 14:19:54 I can 14:20:13 That actually sounds perfect, three brains can think of more edge cases than one :) 14:20:16 so what do we want to do by the next week? simple keystone client? 14:20:32 that's my understanding 14:20:32 msmol: What do you want to commit to by wednesday? 14:21:25 I suppose a simple client that can authenticate with keystone and a test or two 14:21:46 #action msmol to try to implement a simple keystone client 14:21:50 ALrightey 14:22:05 msmol: Thanks for taking this on :) 14:22:14 #topic Open discussion 14:22:32 nodejs6 jobs are currently under review by infra: https://review.openstack.org/#/q/topic:npm_jobs 14:22:34 hehe I'll do my best :D 14:22:48 does anyone have anything else to discuss? 14:23:00 I have a subject ! How to we mock "fetch" calls for our unit tests? 14:23:17 There is this thing https://www.npmjs.com/package/fetch-mock but didn't try it 14:23:42 However it says it handles node-fetch and the webpack polyfill, so that would be cool to give it a try. 14:23:49 cardeois: we're trying out https://github.com/wheresrhys/fetch-mock in fuel: https://review.openstack.org/#/c/338338/ it seems to work fine 14:24:24 Ok cool ! so we could give it a try to 14:24:28 I have a topic: Has anyone submitted JS-related sessions to Barcelona? 14:24:55 * krotscheck has one titled: "Beyond Horizon: Building custom interfaces with the JavaScript SDK" 14:25:06 So, yeah, I kinda have to deliver this thing by barcelona ;) 14:25:25 :) 14:25:54 haha nice. We'll try to do our best 14:26:36 since everyone is here, I'd like to discuss my review request enabling ES2015 rules for the project: https://review.openstack.org/#/c/342228/1/.eslintrc 14:26:58 they're needed not to mix ES5 and ES2015 syntax in the library code 14:27:13 though I was asked by krotscheck to add these rules to eslint-config-openstack 14:27:17 I took a look at those, overall my view on those rules are either "meh" or OMG yes we need that. 14:27:45 but adding these rules will lead to breaking existing ES5 code - we cannot enforce using arrow functions for ES5 code 14:28:05 does anyone have any idea how to deal with such rules? 14:28:43 So if I understand we can either use eslint-config-openstack which is the default for all js project? or override our own? 14:29:08 we're using eslint-config-openstack, and adding extra rules 14:29:26 In that case changing the default would be nice, but yeah it will break existing ES5. So is it possible to have ES2015 default in eslint-config-openstack ? 14:29:47 Well, we have a couple of options. 14:29:48 like "extends: openstack-es2015" instead of "extends: openstack" ? 14:30:02 .eslintrc can live in different directories and define the rules for all subdirectories 14:30:33 Secondly, eslint rule packages can have multiple rule sets in them, so eslint-config-openstack could ship with an es2015 rule est. 14:30:54 I'm partial to the latter. 14:31:01 For the first: But do we want different rules inside our project? 14:31:01 and +1 for second 14:31:07 interesting, didn't notice such feature in the docs 14:31:08 * krotscheck thinks the syntax would be extends: openstack:es2015 14:31:12 (or something like that) 14:31:24 sure 14:31:43 vkramskikh: eslint itself does that with its default rules, I don't know how easy it is for third-party packages, but I can investigate. 14:32:11 I can take care of this since I proposed that review requet 14:32:31 x``Here we go: http://eslint.org/docs/developer-guide/shareable-configs 14:32:39 If I have any obstacles I'll reach you out 14:32:40 There's a section called "sharing multiple configs. 14:33:12 awesome 14:33:39 #action vkramskikh to create a review request to eslint-config-openstack with es2015-only rules 14:34:11 wfm. 14:34:41 though I believe this request https://review.openstack.org/#/c/342228/1 still need to be fixed and merged first 14:34:53 so people won't start writing ES5 code :) 14:35:02 :D 14:35:08 I agree 14:35:23 any other topics? 14:35:26 We can merge it, and create another review when the es2015 default exists 14:35:33 +1 14:35:48 * krotscheck thought he had one, but can't remember. 14:36:11 Yeah, I'm working on devstack gate (slowly), any idea how to setup CORS headers globally for devstack? 14:36:54 I can do it for one config (keystone), but don't want to setup one conf for every component we'll talk to in our functional tests (because browsers test need cors) 14:37:50 cardeois: i have a few thoughts, but myt son jyust went ballistic. rain check? 14:38:47 son > us 14:39:07 thanks 14:39:12 * krotscheck tags out 14:39:35 #action krotscheck talk to cardeois about cors 14:40:00 cool, we could talk about that in #openstack-javascript later 14:41:57 anyone have anything else they want to discuss? 14:42:07 not on my side 14:42:17 me neither 14:42:28 fine, if there are any other topics left, let's continue in #openstack-javascript 14:42:33 #endmeeting