15:01:19 #startmeeting vahana 15:01:20 Meeting started Wed Nov 25 15:01:19 2015 UTC and is due to finish in 60 minutes. The chair is Ng. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:24 The meeting name has been set to 'vahana' 15:01:55 Greetings 15:02:20 #topic roll call 15:02:22 Sorry, I didn't realise that was going to make me the chair :) 15:02:30 hehehe 15:02:33 no worries 15:02:34 go for it 15:02:45 I think, for the purposes of future history, we might start with a quick introduction about what Vahana is? 15:03:09 #topic Introduction 15:03:31 sure 15:03:38 There might still be room for disagreement about what Vahana is, so this probably shouldn't be seen as set in stone :) 15:04:15 but we're building an iOS client for OpenStack, in the form of one or more frameworks for interacting with the OS API, and a front end app 15:05:33 There was an effort put together back in 2010 to achieve a similar goal, but it never took off as a mature project 15:06:00 (and the code hasn't changed for 4 years, making it a bit rough to use with current OpenStack) 15:06:14 +1 15:06:23 so our intention is to start pretty much over 15:07:11 also for the historians of the future, I think jasondotstar is leading this project, unless he objects strongly to that? 15:07:43 I don't object. 15:07:50 \o/ 15:08:34 excited to make the attempt to re-ignite what I believe is a valuable companion client for OpenStack Admins 15:08:36 jasondotstar: anything else on introduction stuff? or shall we move on? 15:08:47 nope, let's keep moving 15:09:11 I was thinking we should talk a little about goals for the project and what we want the app to be capable of 15:09:20 sure 15:09:22 (and how we can test those ideas against what users actually want) 15:09:29 #topic Goals and Use Cases 15:09:44 this is probably a good time to share the etherpad link? 15:09:51 good point! 15:09:57 #link https://etherpad.openstack.org/p/openstack-mobile-ios-brainstorm 15:10:29 I have to admit that I am more interested in, and motivated by, the underlying framework stuff, than the visuals of the app, but if we're making both, it would seem to be sensible to make an app that is useful and compelling :) 15:11:14 agreed. I'm interested in both aspects, but I'm hoping that we get some app designer types to join us 15:11:58 we should probably have a long-term action to actively try to involve the UX folk, but it might be a little early for that 15:12:02 that way the under-the-hood guys can work on that exclusively..... 15:12:21 +1 15:12:45 #action someone to loop in UX folk 15:13:20 I have a couple of crude attempts to mockup UX but I'd rather see someone else with UX chops tackle that. 15:14:11 jasondotstar: what sort of vision do you have for the app itself? a nice interface to all the features of OpenStack, or more of a dashboard kinda thing? (or both) 15:15:51 I think the near term goal should be a dashboard view 15:15:55 b/c I think that most OpenStack admins would appreciate the ability to get a quick glance of what's going on in their OS deployments 15:15:57 then in an iterative way 15:15:59 we can add actionable features 15:16:01 for each of the components 15:16:03 starting w/ nova I'd say. 15:16:14 +1 15:16:17 launching a VM, rebooting a VM, creating a new VM 15:16:31 simple rest API calls 15:16:34 #agreed early goal to be a simple dashboard view 15:16:45 i dont think console access is somethign we should tackle just yet.. 15:17:24 eventually we move through the core components 15:17:33 adding new networks via neutron 15:17:34 That has the potential to explode complexity in a lot of ways, and there are already very very good apps that just do VNC/SSH/etc, so we might want to look at their URL schemes, so we can do Open With... type functionality 15:17:38 adding storage, etc. etc. 15:17:50 +1 15:18:19 +1 on open with... 15:18:20 #agreed console access is likely out of scope, when excellent third party apps exist for doing that, and have URL schemes 15:19:32 there's also the goal 15:19:48 of making the dashboard view skinnable 15:19:51 huh, talking of URL schemes makes me think that it might be nice if admins could share their current view with each other, so like you're looking at a problem machine and you can do a standard iOS share sheet to send a URL to your colleagues so they can jump straight to the same thing you're looking at 15:20:39 hmmm 15:20:41 interesting 15:21:31 I like that idea 15:21:43 since everything has a UUID, it shouldn't be super hard to make a vahana:// URL scheme that can express a location in an infrastructure 15:21:55 +1 15:23:14 as for the framework, I think my main goal there is that it grows into something that anyone working on some internal enterprise app, or a public cloud related app, can integrate the framework and easily interact with an OpenStack cloud 15:24:48 jasondotstar: I'm not really sure who we should be reaching out to to talk about what operators/tenants would actually like out of an app, so maybe we have an action item there - figure out who to talk to? 15:25:07 (I'm thinking someone at the foundation, they probably do the most centralised talking to operators at least) 15:25:52 maybe also some of the folk running large and/or public OpenStack instances? 15:26:27 yes 15:26:31 we should add that as an action item. 15:26:32 I think having a list of use cases and/or wish list would be valuable 15:26:35 one other thing I wanted to mention: perhaps the project is a set of iOS libraries that we release, as opposed to an actual app 15:26:49 Ng: re: large/public OS instances - yes, something to test against would be good 15:26:53 #action someone to figure out who we should talk to about identifying specific use cases 15:27:27 I can almost see someone using the libraries to create a *very* niche app 15:27:31 jasondotstar: I don't disagree, a single app is likely to be problematic, since many installations of OpenStack differ wildly in their features/versions/etc 15:27:45 right.... 15:28:35 we should look at considering the project as a collection of libraries and/or frameworks 15:28:50 #action someone to start talking to large/public OpenStack installs for testing and use-case-gathering 15:28:54 that might be more palpable to those who are simply going to take what we have and create something of their own 15:29:17 +1 15:30:06 a framework of reusable UIView subclasses that use the API framework seems like it would be super useful 15:30:31 right 15:30:35 anything else on goals and use cases? 15:30:48 nope, great start I think. 15:31:47 jasondotstar: any particular topic you'd like to do next? 15:32:33 let's see, we had a couple of questions on the etherpa 15:32:39 *etherpad 15:32:52 like how early should we start creating blueprints, specs, etc. 15:33:13 are we basically whiteboarding this out on etherpad until we nail down what direction we're taking 15:34:01 I think we're still at a whiteboarding stage, yes. I feel like I have a bunch more R&D to do on some core classes and project infrastructure before I'm ready to start proposing solid plans for work 15:34:04 or should we start with the end in mind as far as getting as much documented as we can 15:34:22 +1 15:34:23 tjat 15:34:35 *that's my feeling as well. 15:34:43 #agreed we're still at whiteboarding/R&D stage, too early for blueprints/specs 15:35:21 the R&D we're currently doing.... 15:35:38 #topic Current R&D 15:35:51 we're both working using Swift as the pref. lang? 15:36:00 yep 15:36:23 I've been working on figuring out a sane way to have a core REST client class that I think most of the API framework will inherit from 15:36:29 currently using AlamoFire 15:36:44 my next intention is to figure out using GYP to generate .xcodeproj files 15:37:17 but there are so many fundamental tech decisions that we need to make :/ 15:37:23 yep 15:37:39 perhaps we start with evaluations 15:37:47 of different ways of delivering this work 15:37:59 the big one I have at the moment is how to handle the results of the asynchronous REST operations - the options being delegates, blocks, KVO or NSNotificationCenter 15:38:24 I'm currently running with blocks for no particularly good reason 15:40:24 I think I want to have some NSNotificationCenter stuff too, so the API framework can emit things like "I have successfully authenticated", for apps to react to 15:40:28 KVO or observation is like the listener pattern 15:41:38 +1 re: NSNotificationCenter 15:41:56 #agreed API framework should send NSNotifications of important/relevant events 15:42:46 blocks feel like the more "modern Apple" way of doing it, but the modern hispter way would be to use ReactiveCocoa ;) 15:43:09 hehehe 15:44:11 so is it worth it for us to evaluate a couple different ways to 'do things' 15:44:19 perhaps present the pros/cons 15:44:32 then agree on which way is best 15:44:50 sorta like how you arrived at using AlamoFire vs. NSHTTP 15:45:11 I don't think that would be a bad idea, but I'm not sure we'll know which is best until we get much higher up the stack and discover that turns out to be painful 15:45:50 +1 15:46:56 I think the delegate pattern is probably unsuitable long-term, because you're going to end up with the same sort of mess that happens with UITableViewDelegate/DataSource, where each delegate method first has to figure out which of 18 different operations are being sent to it 15:47:13 YES 15:47:39 and OpenStack has a *lot* more operations than UITableView ;) 15:49:04 jasondotstar: anything else on R&D progress? 15:49:04 what are you testing against, btw? 15:49:14 devstack 15:49:22 ok that's cool. 15:49:36 same here. 15:49:38 but at this stage I could honestly be testing against any URL that emits JSON ;) 15:49:47 that's true 15:50:06 ok that's it on R&D 15:50:32 I think we can open the floor for general q&a 15:50:38 #topic Q&A 15:50:41 we've got about 10mins left 15:51:08 how are you finding Swift? :) 15:51:24 I like it. it's very javascript like 15:51:28 I feel like I'm understanding more than half of the code that I'm writing, but by no means all 15:51:31 but here's the thing 15:51:36 I dont really like js. 15:52:04 syntactically it's better than OBJ-c 15:52:33 there's certainly a lot more native syntax to deal with 15:53:40 yeah 15:53:57 I do enjoy the playground 15:54:13 yes 15:54:21 having a place to simply run code w/o building an app 15:54:24 did you discover the trick for having a playground run indefinitely, for async stuff? 15:54:29 is helpful 15:54:43 no..... plz share that one 15:55:12 import XCPlayground 15:55:12 XCPlaygroundPage.currentPage.needsIndefiniteExecution = true 15:56:14 ok 15:56:21 nice! 15:58:06 I'll give that a shot 15:58:21 :) 15:58:34 I don't think I have anything else for today 15:58:37 well, I think that's it for our first meeting. 15:58:41 \o/ 15:58:45 #endmeeting