14:02:00 #startmeeting javascript 14:02:01 Meeting started Wed Sep 7 14:02:00 2016 UTC and is due to finish in 60 minutes. The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:02 bye 14:02:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:06 The meeting name has been set to 'javascript' 14:02:09 #chair vkramskikh 14:02:09 Current chairs: krotscheck vkramskikh 14:02:14 Good morning everyone! 14:02:17 hi 14:02:23 Hi 14:02:24 #link Agenda: https://etherpad.openstack.org/p/javascript-meeting-2016-09-07 14:02:30 o/ 14:02:41 omg larainema is here! 14:02:44 \o/ 14:02:51 Hello ! 14:02:59 In random project news, our DSVM gates are now voting. 14:03:21 \o/ 14:03:27 * larainema back from travel 14:03:36 Muchos thanks to cardeois for all his work on that :) 14:03:47 Alrightey, let's pick up last week 14:04:00 #topic Action followup: Storyboard story for jsdoc-sphinx 14:04:20 #link https://storyboard.openstack.org/#!/story/2000716 14:04:33 #topic krotscheck split design-by-documentation into to-implement segments 14:04:42 A bit of progress. 14:04:59 Oh wait. 14:05:10 There was progress, which I forgot to submit as a patch before I handed my HPE laptop back 14:05:17 Soooo no progress 14:05:20 * krotscheck facepalms 14:05:32 vkramskikh: Can you take over the meeting for a few minutes? My son just woke up. 14:05:32 Have we got contact with upstream maintainer? 14:05:33 oh no 14:05:42 krotscheck: sure 14:06:12 #topic Action followup: vkramskikh Swithc to babel-transform-runtime 14:06:30 so I've prepared the patch and it was merged 14:06:35 #link https://review.openstack.org/#/c/365728/ 14:06:45 Merged and working, good job vkramskikh 14:06:53 Yeah, super bonus on that 14:06:54 so the bundle is now 24kb instead of 250kb 14:07:01 yujunz: We have no contact yet. 14:07:12 ...but what's an order of magnitude between friends ;) 14:07:49 #topic MVP Progress: Glance.imageList 14:08:02 if I'm correct, this was implemented and merged 14:08:08 yes it was 14:08:08 That is correct. 14:08:28 good job folks :) 14:08:47 Lots of churn on trying to figure out why those tests were failing :) 14:09:10 Yeah but now that's fixed other components will be done faster 14:09:35 #topic MVP Progress: other services 14:09:40 for neutron, I've started and will soon open a review. Trying to fix some cors issues right now 14:09:54 awesome! 14:09:59 I already have this review to share more code between services https://review.openstack.org/#/c/366222/ 14:10:34 do I understand it right - we've agreed that all the services listed in the etherpad are required for MVP? 14:10:56 I think so yes 14:11:06 vkramskikh: Yes, the goal for MVP is "launch an instance with an image, network, and flavor" 14:11:19 ok, thanks 14:11:34 is anyone else working on some other servce? 14:11:45 I'm working on nova, however it brought up an annoying bit about version detection and the keystone catalog 14:11:54 So, some services can be registered with a specific version API. 14:12:04 Others are registered with the root API, from which a version can be detected. 14:12:13 The former requires auth. The latter doesn't. 14:12:34 (example: http://nova-host/v2 vs http://glance-host/ 14:12:34 Yeah right, but the component name in the catalog has one entry per version (if multiple ones are supported) 14:13:11 So it's not trivial, but it's like there is 2 standards (the old one with specific version) and the new one with version detection 14:13:33 Right. 14:14:00 My thought is that I can extend the version detection algorithm to first query the 'configured' endpoint with no auth token, and if it gets a 401 try the parent. 14:14:14 It's not optimal. 14:14:26 ok or should we assume for nova that we don't discover version and suppose the URL endpoint is correct? 14:14:40 I think it should be fine for MVP 14:14:50 cardeois: Can we do that? We may not support that particular API microversion 14:15:31 I'm not sure but if there's a new version I think it will be called something like "novav2" instead of "nova" 14:16:21 I don't have a catalog entry right now, but I think that's the case for some components where I've seen 3 different components for the same type (volume) with 3 different names 14:16:30 each containing the version 14:16:45 like "volume", "volume_v2" etc (still not sure as I don't have the catalog) 14:17:28 Yeah, exacly 14:17:35 I'll play with it, see what I can come up with. 14:17:43 sure 14:17:55 Should we be implementing keyList as well? Assign a key to an instance? 14:18:18 what's that? 14:18:30 ssh key preloaded on the host 14:18:43 oh, mhh yeah that would be nice I guess 14:19:18 Alright, let's put that in as a nice-to-have 14:19:34 sure 14:19:34 The other thing we need for an MVP is decent documentation 14:20:22 Which is the next topic. 14:20:30 #topoc MVP progress: Switch Keystone Configuration input to catalog entry. 14:21:41 oops 14:21:45 #topic Create wrapper class that takes clouds.yaml instance 14:21:58 Right, those two go hand in hand 14:22:08 No progress on my end. Anyone else want to volunteer for this? 14:22:09 Yeah so that's the main Openstack class right? 14:22:17 Yep. 14:22:36 First draft of that can just be a configuration reader, we can layer on the autoconfig logic in other patches 14:23:02 well I'd like to but I want to close neutron first, and I won't be able to start thoses tasks until next week or later 14:23:48 That's fair. 14:24:00 vkramskikh: Are you still focused on fuel-ui for newton? 14:24:24 krotscheck: yep, I'm still busy with Fuel, can't volunteer on this 14:24:32 I would like to volunteer, but i didn't catch up all the patches these weeks :( 14:25:13 larainema: The effort would be to replace the Test class in index.js with one called OpenStack, and to copy the configuration parsing from keystone.js into that class. 14:25:43 Then, to change the keystone.js class to take a configuration instance much like the glance.js class does (slightly different format, see /tests/helpers/data/glance.js for an example. 14:26:33 OK, i will first take it and I will ask questions if i didn't get it 14:26:34 larainema: The overall reason is that a query to get the service catalog from keystone returns a specific data format (see test data for keystone), which we'd like to be the default data format for instantiating a service. 14:26:43 larainema: Awesome, thanks! 14:26:50 * krotscheck is on a bouncer, feel free to ask :) 14:27:20 #action larainema implement OpenStack class which works with clouds.yaml 14:27:47 #topic MVP progress: Documentation 14:28:44 Right, so we actually need our stuff to be understandable, right? 14:29:05 We have library reference docs, but those aren't really as useful as narrative howto's. 14:29:42 The first step of that is updating the Readme.md 14:30:09 Which is pretty simple - Say: Here's what this is, our documentation lives Over There (tm), here's where you contribute, yay! 14:30:22 That's blocked though because our docs jobs haven't landed yet. 14:30:24 Yeah that's easy I can do it if you want. 14:30:28 Sorry 14:30:35 The doc PUBLISH jobs haven't landed. 14:30:42 #link https://review.openstack.org/#/c/346131/ 14:30:50 I'm really bad at writting documentation but this I can do 14:31:14 Why is this blocked? 14:31:43 Honestly, I don't know. 14:31:54 I need to talk to AJaeger about it when I get some time. 14:32:14 alright 14:32:27 You can at least write the readme and set up a depends-on so it doesn't merge until we know where the docs will live. 14:33:01 #action cardeois Write a better README.md file 14:33:08 ^^ not to be confused with a better mousetrap 14:33:54 afk, diaper 14:34:06 alright, I think we've already discussed Getting Started Documentation topic 14:34:18 #topic How to release documentation 14:35:24 yeah, we definitely need it, I don't know the whole process but AFAIR from eslint-config-openstack it includes some black magic jobs which publish new packages to npm 14:36:14 I think krotscheck can tell us a lot here, but he's AFK :) 14:36:27 Ok but what's the difference between what's your talking about and this https://review.openstack.org/#/c/346131/ ? 14:37:23 ohh, I think I was confused by the topic 14:37:37 I read it like we need docs for how to release the library 14:38:03 sorry, next topic then 14:38:09 #topic OSI Licenses 14:38:30 I've seen krotscheck today posted his concerns about React's license 14:39:08 what were his concerns? 14:39:09 Right 14:39:21 I was thinking "DOcumentation on how to release" 14:39:36 betherly is actually an expert on that. 14:39:40 But we've moved on. 14:40:05 ok let's maybe go back to this topic after the current one? 14:40:09 So, I put my concerns on the react.js license to the dev list, and dims immediately forwarded it to the legal-discuss list 14:40:30 https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg91713.html 14:40:33 From what I know of the history, Google had some serious issues with the license, but then facebook modified it, and suddenly google was ok. 14:40:42 So, it _could_ be fine. 14:41:31 BTW, fuel-ui is not the only openstacl project which uses react.js: https://github.com/openstack/tripleo-ui 14:41:39 However, I want to make sure we cover our butts on this 14:42:04 yeah, let's wait for the answer 14:42:15 Here's the link to the legal-discuss thread http://lists.openstack.org/pipermail/legal-discuss/2016-September/000418.html 14:42:47 That's all I have on that. 14:43:11 ok, let's go to the previous topic then 14:43:12 #topic How to release documentation 14:44:10 Ok, so releasing docs 14:44:19 Or rather, "how to release" documentaiton 14:44:50 A lot of this is already written, I just want to make sure the cores on the project go through and make sure they can read it. 14:45:11 THe important thing to note is that using 'npm version' is NOT the right way to do it. 14:45:21 The reason is really just a race condition. 14:46:03 npm version will tag and push a tag, but it won't send up the corresponding patch for review. The way that zuul-cloner works, it results in trying to check out a sha that doesn't exist, and the whole thing fails. 14:46:27 oh right 14:46:29 So we have to increment the version manually, then tag. 14:46:37 (after the patch has landed. 14:46:41 where can we read it? 14:47:32 betherly did an initial pass in this review https://review.openstack.org/#/c/356473/1/doc/source/releasing.rst 14:47:35 But can we still do tags with a patch? 14:48:23 Ok I remove my question, was answered by the review 14:48:44 Righto 14:49:04 #action krotscheck propagate https://review.openstack.org/#/c/356473/1/doc/source/releasing.rst to js-openstack-lib and js-generator-openstack 14:49:11 Okies 14:49:14 * krotscheck is done 14:49:29 A quick question. Why eslint-config-openstack skips version 3.x 14:50:03 npm info eslint-config-openstack gives '2.0.0': '2016-06-02T19:09:41.954Z', 14:50:03 '4.0.1': '2016-08-05T23:39:44.989Z' }, 14:50:17 #topic Open discussion 14:50:41 yujunz-zte: Yes - so, that was because when we tried to release eslint-config-openstack, we realized that we had to land the version before tagging. 14:50:44 yujunz-zte: AFAIR there were some issues with the jobs like krotscheck descrbied above 14:50:53 so v3 was not released correctly 14:51:26 Little comment on functional-test. Jasmine runner doesn't output test results anymore. That's a bug since 2.5.0 that will soon be resolved. We can either let it like that or fix to version 2.4.x 14:51:31 I thought we once wanted to align the version with eslint version 14:51:54 yujunz-zte: Yes, we did. Infra didn't want to oblige us by rolling the tag back. 14:52:12 OK... Let's wait for eslint to catch up 14:52:15 cardeois: Oh, good to konw. Thanks 14:52:26 Other thing: Did anyone notice that our coverage statistics are totally off? 14:53:10 No, since when? 14:53:33 I don't know since when, but there's symptoms. 14:53:41 well unit tests are not that bad. functional-test I'm not sure we should have coverage. I mean it's different as we can't handle exceptions like service is down or somthing 14:53:48 The browser tests all report 100% coverage (0 lines) 14:53:57 (I think( 14:54:24 Unit tests report one thing in the console output, but istanbul check-coverage seems to test against a different set of values. 14:54:54 To see that in action, try setting the failure threshold in istanbul.yml to just below what the console reports. 14:55:22 Also the "cover" directory gets pushed but is unreadable as links are broken. e.g http://logs.openstack.org/28/365728/2/check/gate-js-openstack-lib-nodejs4-npm-run-test/82370ab/cover/ 14:55:50 Oh, fun fun. 14:55:51 oh ok I didn't noticed that. Will check 14:56:07 Right. 14:56:13 Example of 100% coverage http://logs.openstack.org/28/365728/2/check/gate-js-openstack-lib-nodejs4-npm-run-test/82370ab/cover/unit/browser/Chromium%2051.0.2704%20(Ubuntu%200.0.0)/ 14:56:36 It's broken because the logs.openstack.org seems to allow only index.html files but doesnt allow URLS liks: http://logs.openstack.org/xxx/index.html only http://logs.openstack.org/xxx/ will work 14:56:48 Oh right. 14:57:07 That seems silly 14:57:13 Ok, seems like we should just put a story up. 14:57:20 yeah 14:57:20 https://storyboard.openstack.org/#!/story/2000717 14:57:23 There ya go 14:57:32 3 minute warning, anything else? 14:57:41 Any news for the coming summit? 14:58:07 * krotscheck is not attending. 14:58:16 * vkramskikh will attend 14:58:22 * cardeois will attend 14:58:30 Is there still interest in an SDK hack session? If so I'll try to get us space. 14:58:41 I'd like to yes 14:58:41 * jprivard is not attending. 14:58:43 * yujunz-zte will attend 14:59:01 well except if we're only 2 interested. 14:59:05 I've asked the API WG to push for an SDK program under the TC, peer with the other openstack projects 14:59:45 and did you get any status on that? 14:59:53 let's continue in #openstack-javascript - time is up 14:59:56 Basically a "Yes we want this too" 14:59:57 ok 14:59:58 #endmeeting