15:01:00 <jasondotstar> #startmeeting vahana
15:01:01 <openstack> Meeting started Wed Dec  9 15:01:00 2015 UTC and is due to finish in 60 minutes.  The chair is jasondotstar. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:04 <openstack> The meeting name has been set to 'vahana'
15:01:06 <Ng> .o/
15:01:07 <jasondotstar> #topic roll call
15:01:16 <jasondotstar> howdy Ng
15:01:19 <Ng> hey hey :)
15:01:19 <vtech> \o/
15:01:59 <jasondotstar> hey there
15:02:07 <jasondotstar> #topic Introduction
15:02:21 <jasondotstar> eventually I'll drop this section of the meeting
15:02:31 <jasondotstar> but it's new, so I figure I should remind folks...
15:03:20 <jasondotstar> friendly reminder that the OpenStack Vahana project is an effort to build an iOS client for OpenStack, in the form of one or more frameworks for interacting with the OS API, and *possibly* front end app
15:03:40 <jasondotstar> #link https://etherpad.openstack.org/p/openstack-mobile-ios-brainstorm
15:03:51 <jasondotstar> Interested parties are encouraged to join the #openstack-vahana IRC channel
15:04:25 <jasondotstar> we'll keep the train moving here......
15:04:36 <jasondotstar> I'm feeling like this might be another short meeting for us, but we'll see....
15:04:48 <jasondotstar> #topic Action Items from Last Meeting
15:04:56 <jasondotstar> so for some reason
15:05:11 <jasondotstar> the meetbot didn't keep the meeting log from our last meeting :-(
15:05:30 <Ng> jasondotstar: I think it did, but last week the topic was set to "openstack-vahana"
15:05:41 <jasondotstar> ahhh
15:05:45 <jasondotstar> so consistency is key
15:06:04 <jasondotstar> so i think we'll go with starting meeting as just vahana
15:06:25 <jasondotstar> that's what we started out with :-)
15:06:39 <Ng> +1
15:06:48 * jasondotstar wonders if we can find the agenda using openstack-vahana
15:06:53 * jasondotstar looks
15:07:15 <jasondotstar> http://eavesdrop.openstack.org/meetings/openstack-vahana/ 404
15:07:31 <Ng> http://eavesdrop.openstack.org/meetings/openstack_vahana/2015/openstack_vahana.2015-12-02-15.01.html
15:07:43 <jasondotstar> \o/
15:07:58 <jasondotstar> understore
15:08:05 <jasondotstar> underscore*
15:08:08 <jasondotstar> cool.
15:08:25 <Ng> so I had one action item, and I need to carry it over because I haven't done it yet, sorry!
15:08:31 <jasondotstar> no worries
15:09:20 <jasondotstar> I did get a chance to chat with the horizon folks yesterday
15:09:33 <jasondotstar> we had a decent talk about native vs. cordova
15:09:42 <jasondotstar> Piet from the UX team was actually there
15:09:52 <jasondotstar> so if you want to touch base w/ him
15:09:53 <Ng> ah nice
15:09:57 <Ng> yeah
15:10:03 <Ng> what was their feeling on native vs cordova?
15:10:06 <jasondotstar> he gave me some insight regarding going down this road before
15:10:33 <jasondotstar> well, several of them seemed to agree with the platform agnostic play
15:11:27 <jasondotstar> I gave them a few things to chew on regarding the benefits of going native
15:11:39 <jasondotstar> ending with a 'and i just dont want to do HTML/JS'
15:11:47 <Ng> hehe
15:11:54 <jasondotstar> tvOS dashboards
15:12:01 <jasondotstar> watchOS alerts
15:12:40 <jasondotstar> so trying to make a play for going native.... and there was one who jokingly spoke up and said 'oh so it's an excuse to play with the cool toys'
15:12:42 <jasondotstar> :-)
15:12:53 <Ng> mwaha
15:13:15 <jasondotstar> Piet did mention that there are making use cases for mobile
15:13:26 <jasondotstar> and *then* there are use cases for NATIVE iOS
15:13:36 <Ng> nice
15:13:44 <jasondotstar> they were having trouble with the use cases for mobile in the past
15:14:04 <jasondotstar> so it was suggested to do an operators survey
15:14:22 <jasondotstar> where we put together something that asks them which actions would you take where
15:14:49 <jasondotstar> and have like a browser tablet phone matrix
15:14:52 <jasondotstar> or something
15:15:23 <Ng> as in *we* do an operators survey? or is this something they are already working on that we can be part of?
15:15:41 <jasondotstar> good qn.
15:15:51 <jasondotstar> I was thinking he meant "we".
15:15:59 <jasondotstar> at that point I asked our colleagues at HP about it
15:16:14 <jasondotstar> and dhellmann spoke up and offered to do a warm intro to the user committee
15:16:22 <jasondotstar> who might help us set something up like this
15:16:39 <Ng> woot
15:17:01 <jasondotstar> so if you want to continue working the UX angle
15:17:19 <jasondotstar> while i work with dhellmann on getting somewhere with the survey
15:17:22 * Ng nods
15:17:29 <jasondotstar> those could be a couple actions we take this week....
15:18:07 <jasondotstar> #action Ng to continue chasing down support from the UX team
15:18:44 <jasondotstar> #action jasondotstar to take up dhellmann on his offer to introduce him to the user committee in an effort to kickoff the op survey
15:19:33 <jasondotstar> we also talked about technology to support they survey, but to me that doesn't matter as much. CIVS or Google Forms
15:19:44 <jasondotstar> we'll find the right tool to support it
15:19:49 <jasondotstar> s/they/the
15:20:44 <jasondotstar> ok so my other action item I'll have to roll fwd
15:21:05 <jasondotstar> it was this one: to chat with -infra about public cloud API testing environment(s)
15:21:25 <jasondotstar> I'll revisit that one this week
15:21:35 <jasondotstar> #action jasondotstar to chat with -infra about public cloud API testing environment(s)
15:21:59 <jasondotstar> alright the unassigned ones:
15:22:32 <jasondotstar> come up with a list of short-term MVP goals
15:22:41 <jasondotstar> we *sorta* started this one
15:22:54 <jasondotstar> but I think we should add a couple more
15:23:26 <jasondotstar> so far we've got:
15:23:27 <jasondotstar> Class that authenticates with keystone and stores the resulting token
15:23:45 <jasondotstar> and
15:23:47 <jasondotstar> Class that bears basic Nova (Compute) functions
15:24:04 <jasondotstar> things like, listing compute resources
15:24:12 <Ng> I now have a ridiculously simplified class that can fetch a token from keystone
15:24:23 <jasondotstar> NIIIIIIIIIICE
15:24:36 <jasondotstar> \o/
15:25:00 <Ng> it needs a bunch of work to be anything close to production ready, but that work all requires us to start making infrastructure decisions
15:25:02 * jasondotstar hears the brass ensemble playing a glorious fanfare
15:25:20 <Ng> like logging, which variation of the observer pattern we're going to use, etc.
15:25:24 <jasondotstar> +1
15:25:47 <jasondotstar> that brings me to our other unassigned task
15:25:52 <jasondotstar> git repo
15:25:59 <jasondotstar> i didn't look into this one at all.....
15:26:06 <jasondotstar> any thoughts here?
15:27:10 <jasondotstar> as I stated before
15:27:19 <jasondotstar> I jumped the gun a bit and created a couple
15:27:35 <jasondotstar> but with the concerted effort we should create a vahana git repo
15:27:58 <jasondotstar> somewhere.... esp now that we're making some progress developmentally
15:28:10 <Ng> the question is where
15:28:20 <jasondotstar> yep
15:28:26 <jasondotstar> big question
15:28:30 <Ng> github is easy, infra would be better, but I'm not sure what happens if you want a git repo from infra without any testing
15:28:31 <jasondotstar> github?
15:28:54 <jasondotstar> is it just a matter of asking -infra for it?
15:29:25 <Ng> I suspect it'll turn into a review adding it to infra's repos, but it's so long since I've done it, that I don't know :)
15:29:44 <jasondotstar> ok
15:29:53 <jasondotstar> I'll take that one since I've already got to talk to them
15:30:11 <jasondotstar> #action jasondotstar to chat with -infra about git repo hosting
15:31:14 <jasondotstar> OK
15:31:24 <jasondotstar> anything else on the action items?
15:31:37 <Ng> nothing from me
15:31:47 <jasondotstar> ok
15:32:04 <jasondotstar> #topic R&D
15:32:28 <Ng> so my R&D work was around getting the barest possible keystone authentication going, which I have done
15:32:30 <jasondotstar> you touched on what you've got working thus far
15:32:45 <jasondotstar> awesome
15:33:01 <jasondotstar> I'm behind on my R&D work
15:33:10 <jasondotstar> but I'd like to have a look at what you've got going
15:33:12 <Ng> I have a class that wraps AlamoFire, in case we need to change that, and an Identity class that at the moment just takes url/username/password as init parameters, and has a getToken()
15:33:30 <jasondotstar> nice
15:33:36 <jasondotstar> about what I was going to try
15:33:52 <Ng> http://pastebin.com/Fz9vcbw7 is what I have in my playground right now
15:35:06 * jasondotstar looks
15:35:18 <Ng> (I arbitrarily picked "OSV" as the class prefix, for OpenStack Vahana :)
15:35:34 <jasondotstar> yep
15:35:37 <jasondotstar> just peeped that
15:35:40 <jasondotstar> OSVBase
15:35:50 <jasondotstar> OSVRest, etc, etc.
15:35:51 <jasondotstar> I like it.
15:36:34 <jasondotstar> nice wrap
15:36:49 <jasondotstar> all the funcs needed
15:37:46 <jasondotstar> cool. I'll have to try this out with my devstack env
15:38:35 <jasondotstar> i honestly don't know much about keystone API
15:38:37 <Ng> so I said just now that logging and observerpattern were the things I care about next. I just added OSVBase right after saying that and added the logging functions to it, so that is now abstracted and we can defer any decision about logging until later
15:38:45 <Ng> but the observer one is a really important decision
15:38:51 <jasondotstar> is there much beyond grabbing the tokens and logging
15:38:51 <jasondotstar> ?
15:39:05 <Ng> that depends :)
15:39:21 <Ng> the keystone API has tons of stuff in it, and really it comes down to how a cloud/tenant is set up
15:39:27 <jasondotstar> gotcha
15:39:35 <Ng> e.g. you can get a token that's restricted to specific things
15:39:45 <jasondotstar> right
15:39:48 <Ng> the (very formal) API spec for keystone is http://developer.openstack.org/api-ref-identity-v3.html
15:40:22 <jasondotstar> do we state up from this the amount of the keystone API that we're going to implement?
15:40:30 <jasondotstar> or do we start small and work our way up?
15:40:38 <jasondotstar> s/from/front
15:40:56 <jasondotstar> s/this the/this is the/
15:41:01 <jasondotstar> typos galore this morning
15:41:04 * jasondotstar needs coffee
15:41:10 <Ng> yeah I'm struggling with that one a bit. I worry that if we start dumb and try to get smarter, the architecture will be wrong. I also worry that if we try to start smart, we won't be understanding the problem space properly and will still get it wrong ;)
15:41:45 <jasondotstar> true stmt.
15:42:04 <Ng> I think the latter worry pretty much forces me to start dumb and try to get smarter
15:42:09 <jasondotstar> this is where the survey would help
15:42:17 <jasondotstar> knowing what ppl might want to use mobile for
15:42:25 <Ng> yeah, that will definitely help
15:42:41 <jasondotstar> might steer us in the direction of which portions of the API to expose
15:43:03 <jasondotstar> meanwhile, we can continue R&D
15:43:07 <jasondotstar> (i guess)
15:43:24 <jasondotstar> figuring out what we can/can't should/shouldn't do
15:43:32 <Ng> ultimately though, the Identity class' main job is "here is some set of auth data and metadata, get me a token" and that should be reasonably possible to always entirely hide inside the class, so we can change/improve/expand it over time
15:44:03 <jasondotstar> yep
15:44:06 <jasondotstar> agreed
15:44:53 <Ng> and if people want it to be able to talk to the Policies part of keystone's API, that would just be more functions in OSVIdentity
15:45:07 <jasondotstar> #agreed on the role of the Identity class in openstack-vahana. it's job is to fetch the API token
15:45:17 <jasondotstar> +1
15:45:42 <jasondotstar> s/it's/its
15:45:49 * jasondotstar warms up the Keurig
15:46:20 <Ng> another question is whether we should support older API versions
15:46:35 <jasondotstar> hmmmmm
15:46:37 <jasondotstar> good one
15:47:23 <Ng> I am somewhat tempted to avoid that decision by just renaming OSVIdentity to OSVIdentity3
15:47:33 <Ng> then if people care for v2, it can be added
15:47:47 <jasondotstar> +1
15:48:40 <jasondotstar> #agreed we should concern ourselves with API v3 and not worry about supporting older API versions atm
15:49:07 <jasondotstar> good stuff.
15:49:59 <jasondotstar> ok we're about 10 mins out
15:50:09 <jasondotstar> any other R&D items?
15:50:25 <Ng> observer pattern, or as I rather suspect, pattern*s*
15:51:18 <Ng> this is a really tough one
15:51:23 <jasondotstar> indeed
15:51:33 <Ng> delegates are 1:1, KVO isn't really native to swift, and NSNotificationCenter is awfully blunt
15:52:58 <Ng> I'm currently looking at https://github.com/slazyk/Observable-Swift
15:53:03 <jasondotstar> https://developer.apple.com/library/mac/documentation/Swift/Conceptual/BuildingCocoaApps/AdoptingCocoaDesignPatterns.html#//apple_ref/doc/uid/TP40014216-CH7-XID_8
15:53:30 <jasondotstar> there's some KVO stuff there
15:53:38 <jasondotstar> but I haven't read through it all
15:54:16 <jasondotstar> #action evaluate how we are to implement Observer pattern(s)
15:54:38 <Ng> so the KVO you can do with Swift is actually using the objc runtime and only works for classes that derive from NSObject (which, for no especially good reason, all of mine currently do)
15:54:53 <jasondotstar> yep that's what i saw
15:55:10 <jasondotstar> subclassing NSObject should work
15:55:46 <jasondotstar> #topic Open Discussion
15:55:57 <jasondotstar> last five minutes
15:56:00 <Ng> I don't think I have anything else for this week :)
15:56:11 <jasondotstar> nope, I didn't think we'd take up the whole hour
15:56:17 <jasondotstar> but good discussion
15:56:21 <Ng> :)
15:56:30 <jasondotstar> I'm tapped out. :-)
15:56:38 <jasondotstar> well, thx again. until next week
15:56:45 <Ng> thanks :)
15:56:49 <jasondotstar> Ng++
15:56:55 <jasondotstar> #endmeeting