14:00:14 <krotscheck> #startmeeting javascript
14:00:15 <openstack> Meeting started Wed Aug 24 14:00:14 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:18 <krotscheck> Good morning everyone!
14:00:19 <openstack> The meeting name has been set to 'javascript'
14:00:26 <cardeois> hello !
14:00:27 <krotscheck> #link Agenda https://etherpad.openstack.org/p/javascript-meeting-2016-08-24
14:00:30 <vkramskikh> hi
14:00:32 <krotscheck> #chair vkramskikh
14:00:32 <openstack> Current chairs: krotscheck vkramskikh
14:01:10 <yujunz> Hi all
14:01:11 * SotK lurks
14:01:21 <krotscheck> #topic Action Followup
14:01:32 <krotscheck> I've moved both the microversion and the method promise discussion to the topics.
14:01:40 <krotscheck> JSDoc building is also funcitonal.
14:01:55 <krotscheck> #link https://review.openstack.org/#/c/358120/
14:02:05 <krotscheck> #link http://docs-draft.openstack.org/20/358120/4/check/gate-js-openstack-lib-nodejs6-npm-docs/e531b12//doc/build/html/
14:02:12 <betherly> o/
14:02:20 <krotscheck> That second link is probably better - see the content generated under 'Reference Documentatino'
14:03:08 <krotscheck> There's some gotchas, as outlined in the review
14:03:25 <krotscheck> However, with the option of "Not quite perfect" documentation and "no documentation", I'll vote for the former.
14:03:30 <krotscheck> Go leave your comments on the review :)
14:03:42 <betherly> awesome
14:03:43 <krotscheck> Any questions?
14:04:08 <yujunz> I've add a -r for recursive
14:04:25 <yujunz> #link https://review.openstack.org/#/c/359445/
14:04:34 <cardeois> no it's awesome, great job!
14:04:36 <krotscheck> yujunz: Oh, good, thanks.
14:04:57 <yujunz> And the 'Children' thing
14:05:06 <yujunz> I looked into jsdoc-sphinx a bit
14:05:14 <yujunz> Haven't figure out why yet
14:05:33 <yujunz> But should be useful if we want multi level
14:05:33 <krotscheck> Yeah, there's a bunch of things in there that aren't wrapped with if statements.
14:06:05 <krotscheck> We'll want to reach out to the  maintainers of that and see if they're willing to accept some patches.
14:06:32 <krotscheck> It's not super critical though. Maybe worth creating a story though
14:06:46 <krotscheck> #action krotscheck Create story to fix bugs in jsdoc-sphinx
14:07:07 <krotscheck> Cool, let's move on, we've got a lot of big topics to discuss
14:07:19 <krotscheck> #topic Team Purpose and Scope
14:07:27 <krotscheck> vkramskikh: I think this one was yours?
14:07:30 <krotscheck> Why do we exist?
14:08:07 <vkramskikh> I have one reson for contributing into this project - I want to reuse it for Fuel
14:08:39 <krotscheck> Fuel only uses keystone though, right?
14:08:50 <vkramskikh> I also see a lot of potential to reimplement Horizon in a better way, though I don't see any Horizon folks contributing
14:08:51 <vkramskikh> right
14:09:33 <krotscheck> Yeah, I've spoken with the horizon team. Most of them are not being paid to build something new, they're being paid to maintain something old.
14:09:44 <krotscheck> cardeois and the others at internap though seem rather interested.
14:09:55 <krotscheck> cardeois: What's your interest?
14:10:07 <cardeois> You mean contribute to horizon?
14:10:20 <krotscheck> cardeois: Why's Internap interested in the JS efforst ehre?
14:10:21 <cardeois> I guess yeah that would be cool, but the sdk needs to mature before I guess.
14:10:54 <cardeois> We are interested because we used our own sdk in the past (python, js or whatever) and are interested in contributing in a unified one
14:11:01 <krotscheck> Got it.
14:11:15 <krotscheck> What do you consider "mature"? From my experience, that's in the eye of the beholder.
14:11:30 <betherly> cardeois: thats my view as well. i am also interested in contributing to horizon to build a new infrastructure for it but the sdk needs to be more mature to be taken seriously as a replacement
14:11:39 <cardeois> I would say being able to create an instance with a specific flavor and defined networks
14:11:40 <vkramskikh> I've also seen some other folks in project-config who are interested. Maybe once we've got something useful we'll see more contribution
14:11:47 <cardeois> that would be the mvp I think
14:11:58 <krotscheck> That's the MVP for the App Eco group as well.
14:12:06 <vkramskikh> +1 to cardeois
14:12:14 <msmol> hello, sorry for being late
14:12:20 <betherly> cardeois: ++
14:13:16 <krotscheck> Ok, so: instance (nova), flavors, image (glance), auth (keystone)... any cinder?
14:13:55 <krotscheck> Neutron
14:14:00 <cardeois> Yes I think cinder would be nice too, (or phase 2)
14:14:14 <krotscheck> So, that's a lot of work. Is anyone other than myself actually willing to contribut to this to get it to MVP state?
14:14:48 <krotscheck> Because, quite frankly, I gave notice to HPE this monday, and will be moving on to non-OpenStack things in two weeks.
14:14:52 <cardeois> I am, I didn't work that much these last weeks on the project but I'd like to catch up and contribute to one component
14:15:02 <betherly> krotscheck: i am
14:15:03 <cardeois> oh wow
14:15:04 <krotscheck> So my ability to contribute will be VERY restricted.
14:15:04 <msmol> +1
14:15:18 <krotscheck> (Basically 20% time, if Im lucky)
14:15:28 <betherly> i just dont know exactly how to bring things together but i definitely want to help and learn :)
14:15:43 <vkramskikh> I'm still busy with Fuel and cannot commit to anything, though I still can review the patches
14:15:51 <yujunz> 10%-20% on my side
14:16:04 <krotscheck> Right.
14:16:13 <cardeois> yeah 10-20%  for me too
14:16:53 <betherly> ditto
14:16:54 <krotscheck> Ok, so there's willingness to contribute, however I want to make sure that everyone's got their expectations set.
14:16:58 <cardeois> But if we get things clear with Keystone, and it gets well defined, it would be easier to develop other components bases on Keystone
14:17:18 <krotscheck> #link https://review.openstack.org/#/q/status:open+project:openstack/js-openstack-lib+branch:master+topic:keystone
14:17:29 <krotscheck> just sayin ;)
14:18:04 <cardeois> yeah I need to catch up
14:18:17 <krotscheck> I'll talk more about progress.
14:18:18 <krotscheck> later
14:18:22 <msmol> indeed. yeah we've definitely got some catching up to do
14:18:54 <krotscheck> So to summarize: We think the SDK's a grand idea, everyone's trying to scrape time together to contribute, but we don't think we can really make an argument without an MVP, yes?
14:19:26 <vkramskikh> +1
14:19:30 <cardeois> +1
14:19:37 <yujunz> +1
14:20:03 <krotscheck> Add to that generator-openstack, which is our "Here's how you use our SDK" tool.
14:20:23 <krotscheck> Righto.
14:20:42 <msmol> maybe cardeois and I can convince mr notmars to let us work on this more than 20%. I think it's a longshot but we can try
14:20:55 <krotscheck> SO here's what I propose. We figure out which methods in the various API's are required to get us to the mvp, and we only implement that.
14:21:24 <krotscheck> I've got patches up for keystone that will get us tokens and the service catalog list.
14:21:26 <betherly> how are we going to collaborate on this with regard tasks and getting things moving forward without duplication?
14:21:35 <jprivard> and of course I can contribute more as well. I'm having a hard time handling with my responsibility of dev + scrummaster, but I definitely can contribute more
14:21:36 <krotscheck> From that we can attach nova, cinder, glance, and neutron
14:21:58 <cardeois> Good idea, I think everybody needs to check Keystone reviews so we all agree and take that as a base
14:22:03 <vkramskikh> I agree, I don't think we need all of that: http://paste.openstack.org/show/562622/ for keystone MVP
14:22:16 <krotscheck> i agree
14:22:32 <krotscheck> We may need regions? well see
14:22:54 <cardeois> Yes region is important for us, unless you can specify it in the config and it uses this config
14:23:32 <krotscheck> Can I get some help identifying which bits we need to implement?
14:23:54 <cardeois> I can help
14:24:47 <krotscheck> cardeois: Thanks! I'll check in with larainema to see how he's coming along with glance, and dig into nova's flavor things. If you could take on neutron, that'd be best.
14:24:57 <krotscheck> Also, everyone go argue about keystone.
14:25:01 <krotscheck> :D
14:25:07 <betherly> :D
14:25:29 <krotscheck> Ok, let's move on.
14:25:33 <krotscheck> Wait
14:25:38 <krotscheck> Any questions before we move on?
14:25:57 <cardeois> ok sound good
14:26:44 <krotscheck> #action krotscheck, cardeois, and larainema to figure out what methods are needed to get to MVP
14:26:54 * krotscheck is going to throw code at those.
14:27:07 <krotscheck> #topic Token Persistence
14:27:14 <krotscheck> Keystone issues tokens.
14:27:22 <krotscheck> Those tokens might expire.
14:27:46 <krotscheck> We can have the SDK handle the tokens, however it'd be difficult to do so in a way that will meet all edge cases.
14:28:08 <krotscheck> vkramskikh made a point last week that we should leave it to the user to manage their tokens.
14:28:25 <krotscheck> The more I worked on the keystone SDK, the more I ... sortof... agree with him.
14:28:31 <msmol> I think it should be up to the SDK's users to reauthenticate... e.g. +1 vkramskikh
14:28:55 <krotscheck> So, what we're building now is a very low level SDK. We basically just construct HTTP calls for our users.
14:28:59 <cardeois> So you mean our choices are: #1 if the token expires we generate an error and the user handles it. #2 we catch them and reconnect and handle the exception ?
14:29:14 <krotscheck> cardeois: Yep.
14:30:00 <breton> keystoneclient now does #2
14:30:07 <breton> *python-keystoneclient
14:30:09 <cardeois> Yep I agree with #1 then. Too many edge cases otherwise. If the sdk is used on a server side it "might" be instanciated with an existing token already and we "might" not have any user credentials to relogin
14:30:24 <msmol> I don't see how we'd reauth automagically in the browser. If say the page is refreshed that means we lose not only the token, but also the config (unless we start storing stuff in local storage)
14:30:34 <krotscheck> breton: Thanks, that's good to know :)
14:30:54 <krotscheck> msmol: THat's certainly an option.
14:31:06 <krotscheck> Personally, I think that high-level features like that would be AWESOME... but not for an MVP.
14:31:23 <krotscheck> What I've done so far is pass the token in to the method as a first parameter: https://review.openstack.org/#/c/358085/5/src/keystone.js
14:31:59 <krotscheck> And, maybe, at some point in the future the OpenStack class becomes the "We'll do magic for you" implementation
14:32:15 <cardeois> +1 for not necessary for MVP
14:32:19 <krotscheck> But that's a future kind of question.
14:33:13 <msmol> ok, so then we're all agreed I think. would be nice to have but not in the scope of the MVP?
14:33:52 <krotscheck> Any disagreements?
14:34:28 <krotscheck> #agreed Token Persistence not necessary for MVP.
14:34:35 <krotscheck> #topic Outreach Education
14:34:37 <krotscheck> betherly!
14:34:45 * krotscheck apologizes for totally dropping the ball on that
14:36:14 <krotscheck> Urm.
14:36:15 <krotscheck> betherly?
14:36:51 <betherly> sorry i dropped off for a moment
14:37:37 <krotscheck> No worries.
14:37:46 <betherly> so the summit isnt too far away and so probably that is the number one place for us to be talking about the sdk and the projects
14:38:15 <betherly> it would be good to have a meeting with the purpose of education which could form part of a talk krotscheck has proposed or potentially a webinar
14:38:24 <betherly> which then gets built into documentation
14:38:56 <krotscheck> We're still in brainstorming mode, yes?
14:39:17 <betherly> contribution outreach also leads into a q i touched on earlier in terms of knowing where people can contribute and what needs to be done.
14:39:44 <krotscheck> Our goals are to increase use and increase contributors?
14:39:44 <betherly> indeed. sorry, this is all potential ideas floating around totally open
14:39:50 <betherly> yup
14:40:19 <betherly> and also general awareness of the project even if people dont want to or cant contribute right now
14:40:24 <krotscheck> Ok, so let's focus on individual goals.
14:40:37 <krotscheck> Both require that we build awareness. How do we do that?
14:40:47 <krotscheck> More mailing list discussions.
14:40:55 <krotscheck> Release announcements (requires releases)
14:42:02 <krotscheck> betherly: did you have an etherpad?
14:42:14 <betherly> https://etherpad.openstack.org/p/js-sdk-outreach
14:42:26 <krotscheck> Oh, awesome.
14:42:33 <betherly> i havent had a chance to develop it as much as i hoped (yet)
14:42:50 <krotscheck> Do you want to discuss things now, or let it develop for another week?
14:44:05 <betherly> my first messages in the topic were a sort of rambling of my thoughts on it at the moment and whats going through my brain. any feedback on that and thoughts would always be great
14:44:43 <krotscheck> RIght, so everyone should be talking up the SDK at the summit :)
14:44:50 <krotscheck> I lvoe this idea.
14:45:05 <krotscheck> We'll want to have a response ready for the inevitable "but what about horizon" question.
14:45:38 <betherly> i think our response has been discussed really. once there is an mvp we can look at application
14:45:51 <krotscheck> Right.
14:45:52 <krotscheck> Sorry
14:46:15 <krotscheck> So all of this hinges on actually getting the MVP.
14:46:33 <betherly> part of what we are working towards is something that could be awesome to horizon but its so much more than that so we can probably quite easily shift that discussion
14:47:05 <betherly> well no, i think we can still have discussions before the mvp. talk about the vision of the project and what it 'could' do and be used for
14:47:24 <betherly> but being careful not to make solid statements of intent before things have been planned
14:48:05 <krotscheck> Ok, so what do you recommend we do right now?
14:49:31 <betherly> right now i would recommend we continue improving docs so we can point people to the right place
14:49:44 <krotscheck> That sounds good to me :)
14:49:50 <betherly> cool
14:50:47 <krotscheck> #action krotscheck split design-by-documentation into to-implement segments.
14:51:08 <krotscheck> ^^ Is probably my biggest action here, since once keystone lands we should land the getting-started section for that.
14:51:21 <krotscheck> 10 minute warning
14:51:46 <krotscheck> betherly: Are you ok if we move on?
14:51:52 <betherly> krotscheck: yup yup!
14:51:52 <betherly> :)
14:52:01 <krotscheck> #action everyone Brainstorm outreach ideas.
14:52:14 <krotscheck> #action everyone Make sure you insist on documentation patches :)
14:52:21 <krotscheck> Ok, next topic:
14:52:39 <krotscheck> #topic Microversions
14:52:51 <krotscheck> We had an action last week for everyone to brainstorm about microversions
14:53:12 <cardeois> oh, oops I didn't do anything
14:53:16 <krotscheck> All I came up with is "oh, keystone doesn't do microversions yet, I guess we just support 3.7"
14:53:38 <krotscheck> However.
14:53:58 <krotscheck> I have this patch that sortof outlines my thoughts on it: https://review.openstack.org/#/c/356751/
14:54:20 <krotscheck> Basically, it's up to the SDK to read all available versions, and figure out which one it knows how to talk.
14:54:35 <krotscheck> Right now, we only have one version. That will get more complicated as we add others.
14:54:57 <krotscheck> And I have no recommendations yet on how to support multiple API versions.
14:55:33 <krotscheck> So unless anyone has a strong opinion, we'll discuss things on the review and move on.
14:55:47 <cardeois> Ok so maybe let's focus for the MVP on reading the version of the API, fail if the version is not supported.
14:55:47 <cardeois> Then later we'll handle different versions?
14:56:14 <krotscheck> Right. And maybe what we'll do is release an SDK with every openstack release, and just support that version in that release.
14:56:22 <krotscheck> And handle bugfixes in branches.
14:56:31 <cardeois> +1
14:56:34 <krotscheck> Alrightey
14:56:37 <vkramskikh> +1
14:57:11 <krotscheck> #agreed Stick to one version for the MVP. Handle Most-Recent-OpenStack version at all times, and support older versions via release branches until deprecated.
14:57:15 <krotscheck> 3 minutes
14:57:25 <krotscheck> #topic Method Promise Response Signatures
14:57:56 <krotscheck> So far, on success, I'm retuning the decoded body, while on failure I'm returning the Response instance.
14:58:06 <krotscheck> Any opinions on that?
14:58:12 <cardeois> sounds good for now
14:58:15 <vkramskikh> I love it
14:58:22 <betherly> :)
14:58:34 <cardeois> if the documention is explicit about that I'm ok with it
14:58:40 <vkramskikh> I see in some cases you're not returning the body, but header value or value of some key of body and i'm totally fine with it
14:58:44 <krotscheck> Coolio. The big change that was needed there was to send 4xx and 5xx to the fail handler, which is one of my patches.
14:58:56 <krotscheck> True. I'm returning "That thing that you asked for"
14:59:06 <krotscheck> 1 minute!
14:59:11 <krotscheck> Skipping keystone
14:59:16 <krotscheck> 'cause we covered it.
14:59:19 <krotscheck> #topic Open Discussion
14:59:27 <krotscheck> 40 seconds, what's up?
14:59:28 <krotscheck> :)
14:59:48 <cardeois> haha nothing for me, anyway not enough time
14:59:56 <krotscheck> Alright, thanks everyoen!
14:59:56 <krotscheck> #endmeeting