14:00:02 <krotscheck> #startmeeting javascript
14:00:07 <openstack> Meeting started Wed Aug 17 14:00:02 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:08 <krotscheck> Gooood morning everyone!
14:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:10 <openstack> The meeting name has been set to 'javascript'
14:00:14 <krotscheck> #chair vkramskikh
14:00:15 <openstack> Current chairs: krotscheck vkramskikh
14:00:19 <vkramskikh> hello
14:00:26 <msmol> mornin'
14:00:26 <yujunz> Good evening!
14:00:32 <krotscheck> yujunz! You're here!
14:00:34 <krotscheck> Yi!
14:00:36 <krotscheck> Hi! I mean
14:00:54 <krotscheck> #link Agenda: https://etherpad.openstack.org/p/javascript-meeting-2016-08-17
14:01:03 <krotscheck> #topic Action Followup
14:01:18 <krotscheck> Alright, so vkramskikh managed to propose (and land) the eslint 4.0.1 update
14:01:26 <cardeois> hello
14:01:55 <krotscheck> I've been trying to convince infra to land our patches, with mixed results. There's a lot of pressure to get bindep landed first, which is tricky because AJaeger is in germany and just went on vacation.
14:02:33 <krotscheck> Upside, we have a docs draft build
14:02:53 <krotscheck> (which I'm currently testing with https://review.openstack.org/#/c/356481/)
14:02:57 <cardeois> but didn't you do the bindep thing already?
14:03:23 <krotscheck> cardeois: It's one thing to do the work, it's another to find two members from a different, busy team to +2 it :(
14:04:10 <cardeois> alright
14:04:33 <krotscheck> There's a bunch of projects that are under the infra banner that I can't +2, since I write most of the patches. Ergo, we have to convince two non-javascript types from the infra team to +2 it, and they're a little allergic to javascript
14:05:03 <krotscheck> I'm currently working on the keystone version selection API, more details later in the meeting.
14:05:15 <krotscheck> Has anyone thought about how to handle microversions at all?
14:05:31 <yujunz> What's it about?
14:05:57 <krotscheck> #link https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
14:06:12 <krotscheck> Basically, each service will slowly increment their versinos based on changes.
14:06:38 <krotscheck> That version is communicated via a header: "OpenStack-API-Version: <servicename> ##.##"
14:07:03 <krotscheck> Fact is that microversions can very easily break our client library if we're not careful.
14:07:42 <krotscheck> So we'll have to be careful about how/which versions we can support.
14:07:59 <krotscheck> At the moment it's not so much a problem, because we're really just making HTTP requests on our user's behalfs.
14:08:01 <msmol> do we want to support *every* version or a subset?
14:08:05 <krotscheck> But once we start writing convenience methods, that gets tricky.
14:08:12 <krotscheck> msmol: Exactly. I don't know.
14:08:36 <krotscheck> Even if we support a subset, how do we test that subset?
14:08:43 <cardeois> I think we should support at least latest version, and let people contribute older versions if they need it
14:08:57 <cardeois> If that's easy to plug a new version support, that shouldn't be a problem
14:09:13 <krotscheck> cardeois: Latest as in master, or latest as in the last integrated release?
14:09:29 <cardeois> Good question...
14:09:42 <krotscheck> OpenStack has a 2 version deprecation cycle.
14:10:33 <krotscheck> Part of me is thinking that we set up gate jobs that do DSVM against release-current, release-1, and master.
14:10:48 <krotscheck> And somehow make sure that our assumptions for the unit tests remain the same.
14:11:12 <krotscheck> Anyway- this is rapidly switching into design discussion - I'll take it that nobody's brainstormed on it yet?
14:11:26 <krotscheck> Does anyone want to take that on and write a proposal?
14:11:50 <cardeois> Yeah that would make sense. And when a release-1 becomes a release-2, we could keep the code say it's deprecated and rely on unit tests only (cause functional tests are not possible anymore)
14:11:58 <krotscheck> (note, we don't really have to deal with it until after Newton is released)
14:12:19 <krotscheck> ('cause that's when we start having to support two versions rather than just master)
14:12:28 <krotscheck> Also, we can ask the OSC people on how they do things.
14:12:32 <krotscheck> (openstack-client)
14:13:14 <krotscheck> Ok, we'll table this one for the time being.
14:13:23 <krotscheck> #action Discuss microversions in depth next meeting
14:13:39 <krotscheck> #topic jsdoc integration with sphinx
14:13:47 <krotscheck> yujunz: You've got a proposal?
14:13:54 <yujunz> Yes
14:14:12 <yujunz> Just curious that is there any existing example for library api?
14:14:19 <yujunz> I didn't find one.
14:14:52 <krotscheck> yujunz Not for javascript. Probably for the various client libraries like shade or libcloud
14:15:24 <krotscheck> #link http://docs.openstack.org/infra/shade/
14:15:47 <krotscheck> #link http://libcloud.readthedocs.io/en/latest/
14:16:21 <yujunz> OK, I'll have a look at them
14:16:53 <krotscheck> So, your overall proposal so far is to host jsdoc on a third party site.
14:17:05 <yujunz> Yes.
14:17:10 <krotscheck> I _think_ there's precedent for that in OpenStack. Let me doublecheck something
14:17:38 <yujunz> And for the layout, the default style looks good to me.
14:17:47 <yujunz> #link http://js-generator-openstack.openzero.net/
14:17:55 <krotscheck> #link https://rally.readthedocs.io/en/latest/
14:18:06 <krotscheck> There's an openstack project that's hosted on readthedocs.io
14:18:35 <krotscheck> yujunz: Urm... wiki.zte.com.cn’s server DNS address could not be found
14:19:05 <krotscheck> Wow, I love the formatting on those docs.
14:19:26 <yujunz> #info http://openzero-zte.github.io/js-generator-openstack
14:19:47 <krotscheck> yujunz: Is that a statically built site that's then uploaded?
14:19:55 <yujunz> Yes,
14:20:20 <yujunz> #info https://github.com/openzero-zte/js-generator-openstack/tree/gh-pages
14:20:36 <krotscheck> yujunz: We should be able to host that on developer.openstack.org. The only question remaining would be wether the documentation team will be unhappy if we don't follow OpenStack's formatting.
14:20:40 <yujunz> Just pushed the jsdoc_build directory to github page branch
14:20:44 <krotscheck> But, well, some documentation is better than pretty documentation
14:21:19 <yujunz> We can add openstack styling in TODO list
14:21:25 <krotscheck> I agree.
14:21:48 <krotscheck> HOw's everyone else feel about this? Get jsdoc output uploaded to developer.openstack.org, worry about integration into shinx later?
14:22:12 <vkramskikh> i'm fine with it
14:22:21 <betherly> sounds good to me
14:22:28 <krotscheck> Alright
14:22:29 <cardeois> Yeah me too, and I really like the jsdoc style
14:22:48 <krotscheck> #agreed Keep jsdoc output unintegrated from sphinx for the moment, get uploaded with the rest of our docs.
14:23:25 <krotscheck> yujunz: Do you have a patch that demonstrates how that documentation is built? I can get it integrated into our usual doc build.
14:23:44 <yujunz> `npm run jsdoc`
14:24:28 <krotscheck> Oh, I didn't see that patch!
14:24:48 <yujunz> I'm sure you have +2'ed it
14:24:59 <krotscheck> Ahh, betherly approved that one .
14:25:05 <krotscheck> https://review.openstack.org/#/c/322881/
14:25:06 <yujunz> Alright...
14:25:07 <krotscheck> Nice
14:25:11 <krotscheck> Ok, cool.
14:25:23 <krotscheck> #action krotscheck get jsdoc building added to our docs build
14:25:35 <krotscheck> Cool, does anyone else have questions on this topic before we move on?
14:26:09 <krotscheck> Ok
14:26:11 <krotscheck> #topic bindep
14:26:23 <krotscheck> Still a few outstanding patches, see https://review.openstack.org/#/q/status:open+branch:master+topic:bindep
14:26:34 <krotscheck> Only the ones that are specificiall js-* are relevant to us
14:27:18 <krotscheck> #topic Keystone Development progress
14:27:24 * krotscheck is making slow, but solid progress
14:27:45 <msmol> \o/
14:27:56 <krotscheck> I'm currently working on the versions() resource, which will hopefully provide a pattern for other resources.
14:28:01 <betherly> woot!
14:28:05 <krotscheck> Also, I discovered that ES6 has string variable replacement
14:28:23 <msmol> sorry krotscheck, I was on vacation until yesterday so I haven't been keeping up with reviews, of which I saw this morning there are a few
14:28:35 <krotscheck> msmol: Vacation is more important than Javascript
14:28:36 <krotscheck> :D
14:28:53 <krotscheck> msmol: The real discussion about what I'm doing is the next topic.
14:29:43 <krotscheck> My current goal is to create a series fo methods: versions(), version(), serviceEndpoint(), and catalog(), which will take us from Logging in all the way to "We know what's running on this cloud"
14:29:58 <krotscheck> Some of those will be cached promsies, since it doesn't really make sense to run the request more than once.
14:30:34 <krotscheck> My current hope is to get all that done by the end of this week.
14:30:49 * krotscheck is hoping things will get easier as he builds up a body of experience and copy/pasteable code :)
14:31:12 <krotscheck> Any questions?
14:31:51 <vkramskikh> can't wait to see how it will look like :)
14:32:04 <betherly> vkramskikh: ++
14:32:12 <cardeois> No question, reviewing the first steps right now
14:32:26 <krotscheck> Coolio, moving on
14:32:41 <krotscheck> #topic Method promise response signature
14:32:47 <krotscheck> Ok, so this is a messy one.
14:33:03 <krotscheck> 99% of requests will likely only care about the json() decoded response.
14:33:04 <krotscheck> In some cases (as with errors or responses with header metadata) more of the request should be accessible.
14:33:05 <krotscheck> Angular introduced $q in order to create a then((body, response) => {} ) signature (which @Krotscheck has found useful).
14:33:06 <krotscheck> How can/should we handle this?
14:33:20 <krotscheck> I've come up with three options.
14:33:24 <krotscheck> Wait, four.
14:33:30 <krotscheck> method() returns json, method.raw() returns raw response
14:33:37 <krotscheck> problem-> Can't grab the header when a response is unexpected
14:33:55 <vkramskikh> "Can't grab the header when a response is unexpected" - could you please elaborate?
14:34:13 <vkramskikh> what is an unexpected response?
14:34:21 <krotscheck> So, fetch() will trigger a .then() on a 3xx, 4xx, or 5xx.
14:34:26 <krotscheck> instead of a catch()
14:35:02 <krotscheck> So you make a request, and get a 401 response.
14:35:11 <krotscheck> That requires checking the WWW-Authenticate header.
14:35:26 <krotscheck> But since we automatically decode the json() content, the client has no idea that they've received an error response.
14:35:48 <krotscheck> (i.e. what if your keystone token expires)
14:36:19 <vkramskikh> probably fail callbacks should always get raw response, though this needs to be thinked through
14:37:08 <cardeois> what about `method()` returning json + status code would that help?
14:37:17 <msmol> doesn't fetch have response.ok to check that the status code is < 300
14:37:17 <krotscheck> Well, that's option two.
14:37:18 <vkramskikh> or porbably our new http abstraction should treat 3xx-5xx as errors
14:37:41 <krotscheck> method() returns { body, response }, permitting destructuring ( then({body, response}) => {} )
14:37:57 <krotscheck> Or (body,status, headers}, etc
14:38:22 <cardeois> body being json object?
14:38:26 <krotscheck> vkramskikh: If we do that, then we have to consider the difference between a thrown exception and an error response.
14:38:33 <krotscheck> cardeois:
14:38:46 <krotscheck> cardeois: Yeah, basically. Return a json structure that's consistent (enforced inside HTTP)
14:39:16 <krotscheck> The third option is "Do what angular did, introduce Q and use q.spread() internally."
14:39:24 * krotscheck played around with that one, it ended up a bit fiddly.
14:39:35 <krotscheck> And the last is the "Do nothing" action, Just return the raw response instance, let each developer invoke `return response.json()`
14:39:46 <krotscheck> So the cirst question I have is: Should we do anything?
14:40:24 <vkramskikh> I propose to always return raw response for keystone and see how it goes
14:40:43 <msmol> I am in favor of not introducing Q
14:40:53 * krotscheck agrees with msmol
14:41:18 <krotscheck> Does anyone like the idea of introducing Q?
14:41:33 <vkramskikh> +1 for not introducing q approach, it will be incompatible with await/async which are stage 4 since july
14:41:55 <krotscheck> That's three against Q, let's just drop that option.
14:41:59 <krotscheck> We have one in favor of not making any changes.
14:42:01 <cardeois> I'm not familiar with Q so I don't know if it' s a good idea. I don't like returning raw response where developper have to invoke `response.json`. I'm more in favor of handling `3xx - 5xx` as errors
14:43:04 * krotscheck is being assaulted by an angry toddler, afk for a sec.
14:43:40 <cardeois> (and always return a json object). On a second choice I'm still ok if we handle all responses as a `then` but still to the json decoding, I think we can safely assume response will always be json
14:44:28 <cardeois> Finally, in a future development it would be nice to introduce autoreconnect if your token expired, so I guess we'll have to do some logic and catch those authentication errors
14:45:36 <krotscheck> cardeois: That second choice I'm not a huge fan of, since we lose the HTTP resposne status context.
14:45:56 <vkramskikh> i believe there should be an action item for everyone to think about the approach and propose something on the next meeting - I believe we won't decide anything today
14:46:04 <msmol> +1
14:46:11 <krotscheck> I feel that it comes down to: Should we do a convenience response.json() for the user? If so, we should probably return a destructurable json object with both the body and the raw response.
14:46:19 <vkramskikh> this is crucial decision and needs to be thinked through thoroughly
14:46:40 <krotscheck> Not having a decision in place makes developing the keystone api a bit tricky.
14:46:52 <krotscheck> But I can go down one path and modify patches as I go.
14:47:08 <cardeois> yes I agree to do some homework, but as I'm not very familiar with the API can anyone give some usecases we want to cover?
14:47:36 <vkramskikh> I think we should make json decoding and treat 3xx-5xx as an error for the user
14:47:52 <cardeois> And I'm fine with that krotscheck, start with what you think is best, and we'll modify once we took a decision
14:48:03 <krotscheck> Alright, let's table this and have everyone think about it this week.
14:48:16 <krotscheck> #action Everyone brainstorm method promise response signatures.
14:48:21 <krotscheck> Moving on
14:48:32 <krotscheck> Open discussion!
14:48:36 <krotscheck> #topic Open Discussion
14:48:59 <krotscheck> So, there is a large but not absolute chance that my contributions to openstack will be severely limited starting in september.
14:49:38 <krotscheck> As such, I'd like to discuss potential contributor recruitment, elevation of new cores, and future plans for the SDK
14:50:52 <krotscheck> Does anyone have any ideas?
14:51:16 <cardeois> On our team we "could" have 2 more contributors, we definitely have to check with them, but they "could" help contribute build some code
14:51:44 <larainema> krotscheck, I am sorry no updates this week for glance api, I am still on travel this week and next week and have no time to work on it
14:52:10 <krotscheck> larainema: thanks for the update, have fun traveling!
14:52:34 <betherly> I think it would be good to have on the agenda at some point a discussion of the purpose of this team and the work we are doing so questions can be asked re the docs and people can feel included more to start contributing?
14:53:00 <krotscheck> good call, betherly
14:53:13 <krotscheck> cardeois Thatd be 20% time, right?
14:53:14 <betherly> also, docs are up for eslint-config-openstack https://review.openstack.org/#/c/356473/
14:53:20 <krotscheck> \o/
14:53:36 <msmol> krotscheck: yes, 20%
14:54:35 <krotscheck> #action Agenda for next meeting: team purpose and scope.
14:54:42 <betherly> when we decide when we plan to have an agenda item dedicated to education and questions we could promote that with all our connections and use it as an outreach thing
14:54:47 <krotscheck> 5 minute warning
14:55:33 <krotscheck> Good idea :)
14:56:58 <msmol> how are we (are we?) planning on handling persistence? if our lib is used in the browser, is it up to our users to store token in local storage (meaning we need to be able to instantiate client with an existing token), or do we need a re authentication every time?
14:57:23 <krotscheck> betherly: I thing that might need to be fleshed out  a bit more, could you do that?
14:57:33 <vkramskikh> msmol: I think it should be up to the user
14:57:59 <krotscheck> msmol: In the past, ive created cached promises.
14:58:00 <betherly> krotscheck: what are you referring to?
14:58:18 <krotscheck> betherly: outreach education.
14:58:39 * krotscheck is typing one handed
14:58:44 <krotscheck> #babyproblems
14:58:55 <krotscheck> Ok, le'ts add that to the agenda for enxt week.
14:59:13 <krotscheck> #action token persistence added to next week's agenda
14:59:29 <krotscheck> We're out of time.
14:59:39 <msmol> have a nice week everyone
14:59:47 <krotscheck> #action Outreach education on next week's agenda
14:59:51 <krotscheck> Thanks everyoen!
14:59:55 <krotscheck> #endmeeting