14:00:34 <krotscheck> #startmeeting javascript
14:00:35 <openstack> Meeting started Wed Aug  3 14:00:34 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:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:39 <openstack> The meeting name has been set to 'javascript'
14:00:41 * krotscheck peers at the bot
14:00:42 <krotscheck> There we go
14:00:44 <krotscheck> #chair vkramskikh
14:00:45 <openstack> Current chairs: krotscheck vkramskikh
14:00:46 <betherly> o/
14:00:49 <krotscheck> Good morning everyone!
14:00:49 <vkramskikh> hi
14:01:17 <krotscheck> Agenda: https://etherpad.openstack.org/p/javascript-meeting-2016-08-03
14:01:17 <msmol> mornin' all
14:01:35 <krotscheck> Good evening to our colleages in the european theater
14:01:46 <krotscheck> Good OMG why are you awake to yuyunz and larainema
14:01:58 <krotscheck> yujunz iI mean
14:01:59 <krotscheck> anywa
14:02:04 <krotscheck> Wow, typing fail
14:02:22 <krotscheck> #topic Action: JSDoc Sphinx (yujunz)
14:02:32 * krotscheck doesn't see a yujunz around
14:02:49 <krotscheck> We'll revisit this in a bit
14:03:07 <krotscheck> #topic Eslint-Config-Openstack 2015 (betherly, vkramskikh)
14:03:21 <krotscheck> Looks like the new ruleset landed.
14:03:27 <betherly> woot!
14:03:39 <Zara> :)
14:03:47 <krotscheck> We've also got betherly's new patch for Eslint3 here https://review.openstack.org/#/c/350530/
14:03:48 <timothyb89> hello all
14:03:53 <krotscheck> Hey timothyb89!
14:03:59 <betherly> thanks for linking to that krotscheck
14:04:32 <krotscheck> So, eyeballs on that, let's try to get a release out this week so we can update the js-lib
14:04:52 <krotscheck> betherly: Is there anything that you'd like to bring up about that topic??
14:05:26 <betherly> basically just that if people could take a look at the eslint patch as soon as they are able so we can get it merged and sort out the release
14:05:55 <msmol> will do
14:06:03 <cardeois> yup justed voted !
14:06:10 <krotscheck> woot!
14:06:15 <cardeois> (oh and hi everybody !)
14:06:20 <betherly> also, https://review.openstack.org/#/c/244257/ - do we want it in this release?
14:06:25 <betherly> thanks msmol cardeois :D
14:07:08 <krotscheck> #topic Keystone Client
14:07:21 <krotscheck> First of all, apologies to msmol for not actually getting a chance to review his code :(
14:07:34 <msmol> no problem krotscheck
14:07:42 <krotscheck> It sounds like you have a blocker though, and that's a dependency on larainema's glance work
14:07:43 <msmol> review is ehre for anyone interested: https://review.openstack.org/#/c/348015/
14:07:48 <krotscheck> So I moved it up in the agenda
14:08:02 <msmol> and yes, the blocker is fetch-mock, which I was unable to get working
14:08:22 <msmol> and I haven't had much of a chance to work on it since last week, so any help here would be much appreciated
14:08:26 <krotscheck> Anyone here have experience with fetch mock?
14:08:45 * krotscheck doesn't, but is willing to try.
14:09:07 <msmol> thanks krotscheck
14:09:12 <krotscheck> Alrightey.
14:09:23 <krotscheck> #action krotscheck to get fetch-mock working
14:09:24 <vkramskikh> I did, will try to have a lokk, though I'm still busy with fuel
14:09:49 <krotscheck> msmol: Note, I'll probably create a separate patch _just_ to get fetch-mock working, so I don't have too many deltas to manage.
14:10:04 <msmol> ok
14:10:16 <msmol> sounds good to me
14:10:19 <krotscheck> I'll rebase your work if you're not around
14:10:28 <krotscheck> Any other questions on that?
14:11:18 <cardeois> nope
14:11:28 <krotscheck> Moving on
14:11:37 <krotscheck> #topic Action: Glance client ( larainema )
14:11:46 <krotscheck> larainema: Any updates? (are you awake? ;) )
14:13:06 <krotscheck> Ok
14:13:17 <krotscheck> #topic SDK Session at the summit (krotscheck)
14:13:21 <krotscheck> Right, so a bit of movement here.
14:13:39 <krotscheck> I've talked to a few different people, and we potentially have two different homes for an SDK hack session
14:14:03 <krotscheck> Late august, there'll be an open call for cross-project sessions. That's the first
14:14:18 <krotscheck> I'd prefer we work there, because it will generally not overlap with other team sessions.
14:14:28 <krotscheck> It'll also be earlier in the week, so we will have brains
14:14:51 <krotscheck> The second home is infra. fungi's been kind to offer us SDK hack time in the infra sessions, however those will overlap with other teams'.
14:15:20 <cardeois> Yeah I guess it makes more sense to work on the first one
14:15:24 <krotscheck> Also, we've got interest from the IOpenstack, Shade, libcloud teams as well.
14:15:45 <cardeois> Do you know what potential day would it be?
14:15:46 <krotscheck> So we may get more than one hour, and we will likely have to share space (which is not a bad thing)
14:16:26 <krotscheck> cardeois: Hard to say with the new compressed schedule (T-F), but in the past the x-project sessions have been on the first day of the design summit
14:16:46 <krotscheck> (As opposed to the openstack conference, which overlapped in weird ways)
14:17:12 <cardeois> Alright cool ! thanks for taking this point, this will help a lot I think
14:17:16 <krotscheck> Anyway- takeaway from this is for us to pay attention to the dev list, and jump as soon as the call for x-project sessions goes out (around the 25th I believe).
14:17:25 <krotscheck> ALSO
14:17:32 <krotscheck> There's been talk about an SDK midcycle
14:17:56 <krotscheck> The last that conversation left off, it would be either right before, or right after, the boston design summit.
14:18:10 <krotscheck> I'm not certain I like the idea of two weeks travel
14:18:26 <fungi> ultimately, when there comes to exist an sdk team recognized by teh tc, repos like this can move there
14:18:41 <fungi> shade too, probably
14:18:42 <krotscheck> So I'll poke flanders to see if I can get a better idea of dates.
14:18:58 <krotscheck> fungi: As long as those are SDK's built by the community, yeah. external ones would be a bit harder.
14:19:37 <krotscheck> #action krotscheck Check with flanders on state of conversation with SDK midcycle
14:19:44 <krotscheck> That's it for me, any questions?
14:19:57 <cardeois> nope
14:20:51 <krotscheck> Alright, moving on.
14:20:52 <fungi> krotscheck: right, i specifically meant openstack sdks currently adopted by the infra team
14:21:03 <krotscheck> fungi: Right
14:21:13 <krotscheck> #topic DSVM Job
14:21:54 <krotscheck> My first comment on this is that I really need to pull the DSVM Patch out of the patch chain that also lands documentation
14:21:55 <cardeois> Yeah so on my side, I'm waiting for reviews of that: https://review.openstack.org/#/c/345529/
14:21:55 <cardeois> But it's still not clear how we'll read clouds congis
14:21:58 <krotscheck> 'cause dependencies
14:22:28 <cardeois> Yeah I saw your patch and didn't understand why documentation was there
14:22:46 <krotscheck> cardeois: It was what I was working on at the time.
14:22:58 <krotscheck> #action krotscheck Separate DSVM and Doc job patches
14:23:22 <krotscheck> The cloud config issue breaks down into two parts- where do we read it from, and how do we get it into a browser, yes?
14:23:45 <cardeois> Yes, but for the browser, I can handle that in js-openstack-lib
14:24:11 <krotscheck> clouds.yaml has three canonical locations. /etc/openstack/cloud.yaml, ~/.config/openstack/clouds.yaml, ./clouds.yaml
14:24:21 * krotscheck may have typod one of those.
14:24:33 <krotscheck> Now, the first of those is generated when devstack starts up.
14:24:59 <larainema> Sorry all, I am driving from airport to pick up my friends, the flight delay, so I might missing this time, will update my status later on JavaScript channel
14:25:07 <krotscheck> larainema: No worries, thanks!
14:25:22 <krotscheck> My question is, does it make sense for us, as developers, to add location detection for that file?
14:25:31 <cardeois> krorscheck But what about this comment from Monty: https://review.openstack.org/#/c/348056/8/jenkins/jobs/macros.yaml@302
14:26:18 <cardeois> Yeah, that's the big question. So we have 2 choices, either we read this file, or we source files in "~stack/devstack/accrc/" to create the clouds.yaml ourselves
14:26:50 <krotscheck> Well, I still like using clouds.yaml
14:26:57 <cardeois> We have to make a choice in order to progress and merges those reviews. For the js-op[enstack-part, I can handle both solutions
14:27:03 <krotscheck> And I'm thinking of the dev use case.
14:27:08 <cardeois> ok so let's use that, I think it's cool too
14:27:12 <krotscheck> So I have a devstack VM somewhere - in a cloud, locally, etc.
14:27:27 <krotscheck> And infra has a devstack VM somewhere, and it tells us where that is via clouds.yaml
14:27:53 <krotscheck> Maybe we actually have the clouds.yaml test helper test the various locations where it's supposed to be, and if it detects one anywhere it uses that?
14:28:19 <krotscheck> That way, if I run npm functional-test, it'll pick up my ~/.config/openstack/clouds.yaml instead and has no problems with the tests.
14:28:55 <cardeois> No we can't do that, because browser support it needs to know so webpack can preprocess the content. (Check my review https://review.openstack.org/#/c/345529/)
14:29:01 <vkramskikh> I like this idea, though we need to think how to make it work in browser tests
14:29:19 <krotscheck> vkramskikh: Yeah, that's the second part
14:29:27 <krotscheck> Which I think cardeois already has a solution for.
14:29:47 <krotscheck> (Do you?)
14:29:56 <cardeois> I handled the second part yeah, using webpack plugin so I do https://review.openstack.org/#/c/345529/5/test/functional/helpers/browser/cloudsConfig.js
14:30:27 <cardeois> And for node part: https://review.openstack.org/#/c/345529/5/test/functional/helpers/cloudsConfig.js
14:31:11 <krotscheck> Got it. vkramskikh, is that what you're looking for?
14:31:29 <vkramskikh> yes it is, I'll take a look
14:31:55 <cardeois> So as we use "require" I can't do any "if" to silently fail if the file doesn't exist. So this CLOUDS_YAML needs to be setup properly (but the post-test-hook script could check the existences of the files and set the proper env variable)
14:33:20 <krotscheck> cardeois: Can we throw an explosive exception? "Hey, we don't have a configuration, go fix this"
14:34:11 <cardeois> Maybe, but I can't check in the js code 3 different location and not fail on the first one (I think).
14:34:47 <persia> Those locations have a priority order, so it is safe to fail after finding the first one.
14:35:14 <krotscheck> Well, we're looking for a specific cloud name though, right?
14:35:18 <persia> The order is ./clouds.yaml, ~/.config/openstack/couds.yaml, /etc/openstack/clouds.yaml
14:35:20 <krotscheck> "devstack", "devstack-admin"
14:35:46 <krotscheck> So it might be safe to try (and fail) to read them all, and if the merged output of all those files doesn't include the config names we're looking for, fail.
14:36:24 <persia> Is there anything in the format specification that prevents duplicate conflicting information being present in the merge result?  That would be unusual for that class of file search.
14:36:49 <cardeois> Yeah I'll check if I can do that, but I don't guarantee anything. Also don't forget this code is for tests only, so we're more in control. As we don't want to include js-yaml library in the dependencies
14:36:59 <krotscheck> I get that.
14:37:18 <krotscheck> We'll see what you come up with. Maybe split your work into two different patches so we can focus on each?
14:37:40 <krotscheck> persia: No, but there's precedent in the JS community. eslint, for instance, will allow cascading overrides where the higher items in the priority queue will win.
14:37:42 <cardeois> My point being I'm not sure it's that useful to implement the merge thing, as it will be more complex
14:39:02 <krotscheck> cardeois: Up to you.
14:39:46 <krotscheck> cardeois The basic config name and structure is in my DSVM patch comment.
14:40:08 <cardeois> ok, but please let me know if you have any comment on the actual review so I can update it in the same time
14:40:17 <krotscheck> cardeois: Willdo.
14:40:29 <krotscheck> #action krotscheck, vkramskikh: Review https://review.openstack.org/#/c/345529/
14:40:45 <krotscheck> Anything else on this?
14:40:56 <cardeois> nope I think we're good
14:42:49 <krotscheck> ALright
14:43:02 <krotscheck> #topic developer.openstack.org
14:43:17 <krotscheck> I bring this up as an information point
14:43:39 <krotscheck> We'll likely be linked from the front page of developer.openstack.org once we do our first release.
14:43:55 <krotscheck> I'm starting the necessary conversations.
14:43:58 <krotscheck> So, be warned :)
14:44:03 <krotscheck> Lots of exposure :)
14:44:09 <krotscheck> #topic Open Discussion
14:44:17 <krotscheck> Lots of time for open discussino today!
14:44:38 <cardeois> Awesome !
14:45:32 <cardeois> I've nothing to say sorry
14:45:56 <krotscheck> vkramskikh: Anything from Fuel land?
14:46:09 <vkramskikh> krotscheck: nothing for now
14:46:15 <krotscheck> There's a bit of a dust-up on the dev list on whether fuel should be a part of the big tent.
14:46:27 <vkramskikh> nope, it's about fuel-ccp :)
14:46:37 <vkramskikh> fuel is in big tent already :)
14:46:38 <krotscheck> Oh, alrightey
14:46:50 <krotscheck> vkramskikh: Does fuel still have the single-vendor tag?
14:47:18 <vkramskikh> don't know about these tags but contributions from non-mirantis guys are not frequent
14:47:56 <vkramskikh> so yes, Fuel is developed mostly by single vendor
14:48:50 <krotscheck> vkramskikh: Right, that's the big argument right now: Should single-vendor projects be kicked out of the big tent after a certain period.
14:49:19 * krotscheck just wants to make sure the fuel team continues to contribute to us :)
14:50:02 <vkramskikh> I believe we will :) though I'll mostly be busy with Fuel feature until the end of august
14:50:09 <krotscheck> One topic I'd like to address: We need to put nova, neutron, and cinder on the code agenda :)
14:50:11 <vkramskikh> *features
14:50:49 <krotscheck> I think that completes the basic cloud functions - log in, provision node from image, attach to network, attach drive....
14:51:04 <krotscheck> And, in a perfect world, I'd like all of that to ship with our Newton release.
14:51:21 <krotscheck> Which means 2.2 months
14:54:01 <vkramskikh> I think we need to finish with keystone client and devstack testing patches, and other clients will be implemented faster
14:54:30 <msmol> reviews for keystone very much welcome ;-)
14:54:49 <krotscheck> #action everyone: Review keystone client :)
14:54:50 <cardeois> Yes, keystone one will take some time to agree on something well structured, but once it's done it will be fast yest
14:55:16 <krotscheck> I'm wondering if it might make more sense for us to write the "Getting started" documentatino first, so we can agree on how we want the world to use our lib.
14:55:22 <krotscheck> And then implement that
14:55:32 <msmol> that might be a very good idea
14:56:06 * msmol rephrases: "that *is* a very good idea
14:56:18 <krotscheck> Alright, I'll get that started. Even so, let's get msmol's patch reviewed.
14:56:28 <krotscheck> #action krotscheck Start the "Getting Started" documentaiton
14:57:18 <krotscheck> Alright, lack of topics means we're done.
14:57:21 <krotscheck> Thanks everyone!
14:57:23 <krotscheck> #endmeeting