17:00:26 <docaedo> #startmeeting app-catalog
17:00:27 <openstack> Meeting started Thu Mar 10 17:00:26 2016 UTC and is due to finish in 60 minutes.  The chair is docaedo. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:30 <openstack> The meeting name has been set to 'app_catalog'
17:00:36 <docaedo> Courtesy ping kfox1111 kzaitsev_mb markvan
17:00:46 <kzaitsev_mb> o/
17:00:48 <docaedo> Agenda:
17:00:49 <docaedo> #link https://wiki.openstack.org/wiki/Meetings/app-catalog
17:01:01 <markvan> hi
17:01:42 <docaedo> Pretty light meeting today, might be over in two shakes
17:01:48 <docaedo> #topic Status updates
17:02:28 <docaedo> For me, no big status updates from the last week other than I'm planning to run for PTL again :)
17:03:02 <kzaitsev_mb> with the glare thing — I've uploaded a https://review.openstack.org/#/c/290932/ That swithces V1 to glare. It's in a WIP state, since I found there are 2 attributes, that are missing in our schema =)
17:03:33 <kzaitsev_mb> so I'm planning to udpdate schema and the script for transfer today/tomorrow.
17:03:40 <kzaitsev_mb> #link https://review.openstack.org/#/c/290932/
17:03:53 <docaedo> excellent!
17:04:05 <kfox1111> o/
17:04:07 <kfox1111> sry.
17:04:12 <docaedo> markvan: how goes the integration testing?
17:04:16 <markvan> from me, just the last piece of integartion test job puzzle with this patch: https://review.openstack.org/#/c/290036/  with that it should be solid
17:04:31 <docaedo> kfox1111: np :) and if it's a timing thing, just wait, next week we're hit with daylight savings again!
17:04:34 <kfox1111> sorry. I was reviewing kzaitsev's patch.
17:04:38 <markvan> then can look to more tests
17:04:47 <kfox1111> hehe. stupid daylight savings...
17:04:50 <kzaitsev_mb> Still no update on public IP for the staging server, though. wonder if Mirantis actually has a pool of IP's. gotta ping the folks around more agressively, I guess )
17:04:54 <docaedo> markvan: thanks, this is great stuff to see
17:05:24 <docaedo> kzaitsev_mb: I can donate a VM with 8gb of ram and .. not sure how many cores. With public IP.
17:05:49 <docaedo> If you want to send me your public key we can coordinate via email - could get you that VM this morning (thanks IBM!)
17:06:15 <kzaitsev_mb> docaedo: Let's wait till next week and if there would be no update, I would probably ask you to do so )
17:06:57 <docaedo> kzaitsev_mb: ok.  I'll probably be running the glare version of app catalog there anyway, but likely your version will be more up to date - anyway, keep me posted
17:07:30 <docaedo> Any objections to me merging https://review.openstack.org/#/c/290036/ this morning?
17:09:00 <kfox1111> docaedo: looks like kzaitsev had a comment on it.
17:09:20 <kzaitsev_mb> docaedo: not really. should work just fine. I'm just usually a bit over-worried about shell script tidiness/correctness =)
17:09:53 <docaedo> I won't rush it then :) give markvan time to respond
17:10:01 <docaedo> Any other status updates?
17:10:11 <kfox1111> looks ok to me.
17:10:37 <markvan> not from me right now
17:11:04 <kzaitsev_mb> I've talked with Omar, and he's going to rething his UI-glare commits with angular.
17:11:40 <kfox1111> ok. cool. thanks.
17:12:15 <docaedo> cool that's good to hear
17:12:34 <docaedo> moving on to...
17:12:41 <docaedo> #topic Open discussion
17:13:47 <docaedo> Interesting thread on dev that has an impact on app-catalog-ui, and potentially app-catalog if we end up marrying the two very closely
17:13:49 <docaedo> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/088923.html
17:13:56 <kzaitsev_mb> looks like our Openstack Bot is not aware of reviews he already set up.
17:14:53 <kfox1111> docaedo: I responded to the thread at one point, and tagged it with [app-catalog] but no one responded to it.
17:16:11 <kzaitsev_mb> these https://review.openstack.org/#/c/290292/ https://review.openstack.org/#/c/291009/ two commits seem exactly the same. Probably it would require a bit more tinkering to checkout the latest 'Detect dead links' commit and work on top of it, like req updater does
17:16:31 <docaedo> kfox1111: I've been following, and saw that you were on it. My only thoughts on the matter don't really impact the bigger issue (how will horizon codebase handle xstatic)
17:17:21 <docaedo> kzaitsev_mb: yes - the expectation is that I will move quicker when the bot detects a dead link, just got caught out yesterday and never managed to circle back to that as I expected
17:17:38 <kfox1111> yeah, I haven't been following it too closely either. just wanted to let them know horizon wasn't the only one.
17:17:55 <kfox1111> I'm guessing there will be a work session at the summit related to it, and
17:18:04 <docaedo> normally the volume of dead links found should be virtually nonexistent, at least with the size of the catalog now. It will have to be handled differently when we switch to glare anyway
17:18:07 <kfox1111> I think we need to discuss with hrizon sharing more code anyway.
17:19:06 <docaedo> kfox1111: I agree - I think it makes more sense for the app-catalog-ui work to head towards being a native component of Horizon, leaving the app-catalog web site to grow on it's own
17:19:31 <docaedo> but good topic for debate at the summit, see if there's even a possibility of that ever happening
17:19:33 <kfox1111> no, not quite what ai meant.
17:19:54 <kfox1111> I think some of horizon's angular stuff is useful outside of horizon, and that we will want to use it on apps.openstack.org.
17:20:14 <kfox1111> the horizon angular smart table stuff is really nice for example.
17:20:30 <kfox1111> I'd like to see it broken out into its own standalone library.
17:21:31 <docaedo> I think there's some value there, but I'm also (and always have been) leery of making the app-catalog web site be tied to the horizon project - so I agree as long as it doesn't get hung up in/by horizon development
17:21:51 <kfox1111> yeah. agreed.
17:22:32 <kfox1111> we don't want to be restricted by horizon, but reusing a lot of the work on development if we can use it.
17:23:01 <kfox1111> since we have so few devs, any saved work will mean we can do more.
17:23:03 <docaedo> +1
17:24:00 <docaedo> I think there's a good chance we'll see an uptick in interested contributors soon at least - I'm working with the app developer ecosystem work group (or called SOMETHING like that) and we're trying to get app devs connected back here
17:24:35 <kfox1111> nice.
17:24:35 <docaedo> I'm also still trying to figure out the best way to start a thread (and even the right mailing list to start it on) regarding defining what an openstack app is exactly (and from there, how best to package and distribute it)
17:24:53 <kfox1111> +1. I can help with that.
17:25:17 <docaedo> Probably the biggest issue we have right now IMO is that we're talking to openstack service developers about openstack apps, and we have not really gotten good feedback or even useful interest, and it's largely due to perspective I believe
17:25:33 <kfox1111> exactly.
17:25:36 <docaedo> I'd hoped engaging the operators group would lead to more exposure, but they really have a different mission
17:25:51 <kfox1111> its because their definition of "user" doesn't include openstack app developers
17:26:02 <kfox1111> or what I've been calling cloud devs.
17:26:43 <docaedo> so .. yeah, I'm goign to focus on exposure for us from other people - as you've noted kfox1111, there's a real disconnect of how devs making openstack services define users, and how users of OpenStack clouds define users
17:26:53 <kfox1111> yeah. I've seen a lot of ops work against the app writer use case too.
17:27:31 <kfox1111> alot of ops only consider their current, emediate users, not future users that are not CS savy.
17:27:49 * kfox1111 nods
17:28:28 <docaedo> true - and there's also a much broader spectrum that can be served by an "app store" and I don't think the app catalog can satisfy every case
17:28:48 <kfox1111> possibly.
17:29:24 <docaedo> i.e. atomic apps intended for non-tech-savvy users is a different audience than a cloud-aware automatically scaling app-stack that you could build with heat
17:29:44 <kfox1111> -1
17:30:03 <kfox1111> its even more important for a non-tech-savvy user to be able to launch an autoscaling app.
17:30:17 <kfox1111> since its not in their capability to manually scale it.
17:30:38 <kfox1111> its really the same use case.
17:31:03 <docaedo> I would agree, but that's served best by a PaaS, not vanilla OpenStack.
17:31:26 <kfox1111> -1 again. pass is for developers.
17:31:26 <docaedo> Murano, OpenShift, Cloud Foundry - they attack that case
17:31:50 <kfox1111> openstack apps are more "software as a service" kind of level. "I want foo", you click, launch, and you have a foo.
17:31:54 <docaedo> how would you package and deliver a complicated autoscaling app for a non tech savvy user?
17:32:00 <kfox1111> sahara's like that. trove's like that already.
17:32:17 <kfox1111> heat/murano, added to the app catalog,
17:32:25 <kfox1111> and then they just "launch" from there.
17:32:48 <kfox1111> just like you would do for the android market.
17:33:33 <kfox1111> the app catalog should let you find it, help you install the pieces you need local to the cloud for it to run, and then let you launch one.
17:33:41 <docaedo> but android app is a radically different use case than a production-grade service living in a cloud - would it make sense for someone to stand up something complicated without any awareness of how to manage it, and count on that for the long term?
17:33:50 <kfox1111> so far, while a little rough around the edges, the app catalog horizon plugin does all of that today.
17:34:19 <kfox1111> depends?
17:34:23 <docaedo> :)
17:34:33 <kfox1111> while a cloud scaled app is archetected differently then a phone app,
17:34:48 <kfox1111> thats an implementation detail. why does it matter that its more fault tollerant?
17:35:04 <kfox1111> owncloud is one example. if its to be used as intended,
17:35:21 <kfox1111> everyone should get their own instance, and it should be pretty much self contained and easily updated.
17:35:30 <docaedo> phone apps dont live long, and generally have all their data held elsewhere so the app is little more than a front-end
17:35:34 <kfox1111> what it really is missing is a very very simple way to just launch one.
17:36:05 <kfox1111> webapps can be too. not sure I see the difference.
17:36:22 <kfox1111> I have users that launch a heat template for a web based R studio thingy.
17:36:34 <kfox1111> they run it when they need it, and hit delete when their done with it. then the next day do the same thing.
17:36:48 <docaedo> Difference is someone on the other side of that app is handling the persistence layer, and maintaining it over time (make sure the DB server is backed up, doesn't run out of space, etc.)
17:36:50 <kfox1111> they don't have to be heavy weight. we just have always thought about them that way.
17:37:15 <kfox1111> if appropriatly written, the cloud scaled app handles that stuff...
17:37:30 <kfox1111> it uses swift, so it has basically infinite storage, auto yum upgrades, etc.
17:38:06 <kfox1111> or has task as a service hooks to help with major upgrades, vm resizes, etc.
17:38:46 <docaedo> Fair enough, though I've never see a cloud scaled app that doesn't need help and knowledge from an experienced sysadmin eventually
17:39:03 <docaedo> but I think a debate like this would be useful on the mailing list
17:39:05 <kfox1111> yeah. because the infrastructure isn't proper yet. :/
17:39:11 <kfox1111> no heat conditonals, etc. ;)
17:39:46 <docaedo> (WHICH list though?? probably not openstack-dev) ..
17:40:01 <kfox1111> yeah. hard call. its not an op or a regular dev thing.
17:40:02 <docaedo> kfox1111: are you on defcore and the users list?
17:40:13 <kfox1111> neither i think.
17:40:16 <kfox1111> probably shoudl be.
17:40:36 <kfox1111> let me know which list you will post to before you do, and I'll make sure I'm subscribed.
17:40:46 <docaedo> #link http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
17:41:01 <docaedo> #link http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
17:41:12 <docaedo> I'll probably commit a cardinal sin and cross-post to both those lists
17:41:48 <docaedo> they're SUPER low volume, so I would encourage everyone to subscribe
17:42:02 <kfox1111> k. I'll do both.
17:42:46 <docaedo> I think we can wrap up and get our noses back to our respective grindstones?
17:42:59 <kfox1111> gota head to another meeting. will subscribe when I get back.
17:43:06 <kfox1111> yup. :)
17:43:09 <kfox1111> thanks.
17:43:30 <docaedo> thanks you guys - talk to you all later on!
17:43:38 <docaedo> #endmeeting