17:01:05 <docaedo> #startmeeting app-catalog
17:01:08 <openstack> Meeting started Thu Jul  2 17:01:05 2015 UTC and is due to finish in 60 minutes.  The chair is docaedo. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:10 <elmiko> thanks etoews
17:01:12 <openstack> The meeting name has been set to 'app_catalog'
17:01:17 <docaedo> #topic rollcall
17:01:40 <docaedo> Who do we have here today? Might be a quicker meeting :)
17:01:54 <sgordon> >.>
17:02:04 <kfox1111> o/
17:02:31 <docaedo> ok, well .. here we go!
17:02:35 <docaedo> #topic Single YAML file switch status update (docaedo)
17:02:47 <docaedo> I've been taking a little time off so haven't been able to focus on this much but I think I should be able to sort it out and get at least a WIP checked in today.
17:03:00 <docaedo> My plan is to just add a new field "asset_type", and adjust the schema to have all the fields and only require the ones that are common across current assets.
17:03:12 <docaedo> We can easily adjust from there, but will appreciate feedback or thoughts on how to approach this if you have any.
17:04:07 <docaedo> The intention here is to make it easier to support new/unknown asset types. Once this is merged then we can work on a new layout for the site that can show new asset types as they are added to the yaml
17:04:23 <kfox1111> +1.
17:04:44 <docaedo> I added the work items I think we need to do this here: https://blueprints.launchpad.net/app-catalog/+spec/expand-asset-types
17:04:56 <kfox1111> it would be nice to copy some of the new attributes from glance too. like license.
17:04:57 <docaedo> would appreciate any addition steps or considerations
17:05:12 <docaedo> kfox1111: sure
17:05:42 <kfox1111> the work items looks good.
17:06:33 <docaedo> Thanks :)  Anything else on this topic? Pretty straightforward stuff I guess...
17:07:05 <docaedo> #topic Horizon panel status update (kfox1111)
17:07:24 <kfox1111> haven't gotten a chance to do anything else since last week.
17:08:10 <docaedo> no prob - would it be worth starting a ML thread to get input from anyone else on the topic?
17:09:08 <kfox1111> possibly? some folks last meeting said they were going to play around with it and maybe extend it for glance/murano. Maybe we wait a bit and see what falls out from that.
17:09:42 <kfox1111> one topic related to the ui that may need discussing...
17:09:55 <docaedo> sounds good to me (waiting a bit to see if there's anything coming from others)
17:09:58 <kfox1111> the app catalog is somewhat disjoint from any cloud release.
17:10:13 <docaedo> what's the UI topic?
17:10:36 <kfox1111> since it is continuously updated, while the cloud itself is probably older then the current release.
17:10:57 <docaedo> "it" in this case being the app catalog?
17:11:00 <kfox1111> so we could have two options. 1, we release plugins for given releases and have to maintain backwards compatability.
17:11:08 <kfox1111> yes.
17:11:51 <kfox1111> or b, the horizon code includes javascript/templates/etc directly from apps.catalog.org allowing it to be upgraded outside of a cloud's upgrade cycle.
17:12:34 <docaedo> I think most will lean towards option 1 - I know people get jumpy about pulling in even JS externally
17:12:42 <kfox1111> I'm kind of afraid with as much changes that will happen as quickly as they will happen once we start adding advanced features like faceting, or changing the yaml to json and do one template,
17:12:58 <kfox1111> that the option 1 will break frequently or we have to depricate frequently. :/
17:13:32 <kfox1111> the other option is somewhere in between. we release a plugin frequenty for all the major cloud versions we support, and like google does,
17:13:46 <kfox1111> unless the plugins the most recent, it says "notify yoru cloud admin to upgrade"
17:13:53 <kfox1111> and make it very simple to upgrade.
17:14:10 <kfox1111> like, seperate the javascript/template from the rest of the plugin, and make it simple to drop in the new files.
17:14:17 <docaedo> The way I see it, what we'll get together at this stage will be very much PoC for Horizon. Too late to even land a spec for L release, but possibly have something ready for M
17:14:43 <kfox1111> the nice thing about plugins is they don't have to land in horizon. they can be seperate.
17:14:46 <docaedo> That idea (upgradable plugin) sounds nice, but are there any other horizon components that work that way?
17:15:01 <kfox1111> I think it will be too much work to target before L, but L should be supportable.
17:15:17 <kfox1111> no. but there are no horizon components that are global in nature either.
17:15:39 <kfox1111> all the rest target the local cloud.
17:16:12 <docaedo> yeah - this is new territory as far as I can see. I would say plan for plugin, not worry too much about compatability or upgrating ATM, and expect to work closely with Horizon team to solve this
17:16:18 <kfox1111> if we don't do the upgradable plugin thing, then we have to define our data + api's very carefully since we will have to support them for years.
17:16:30 <docaedo> +1 for defining the data and APIs carefully
17:16:45 <kfox1111> I think it will be very hard to do that without a lot more experience though. :/
17:17:06 <docaedo> Yeah - guess this is not exactly easy but should be fun at any rate
17:17:08 <kfox1111> we're in the v1 age, and what openstack project thinks their v1 apis are still good ideas? :/
17:17:15 <kfox1111> agreed.
17:17:51 <kfox1111> if we go down that route, we should maybe make a work item for coming up with a v1 api then.
17:18:21 <kfox1111> I'm kind of afraid that the api for v1 with just flat files vs llike a v2 with elasticsearch woudl be so vastly different, maintaining v1 after v2 comes along will be next to impossible. :/
17:18:25 <docaedo> Suggest we focus just on showing how it could work for now, as a horizon plugin with the assumption that the data supplied by JSON won't change much. Then any work integrating glance as a backend will have to be closely tied to the horizon plugin
17:19:16 <kfox1111> yeah. was planning on doing that anway. just wanted to spark the conversation. cause its something we need to think about for the longer term.
17:19:58 <docaedo> agreed - think that conversation will need some input from glance and horizon folk (and we have neither here today as far as I can tell)
17:20:16 <docaedo> speaking of that...
17:20:30 <docaedo> ativelkov: able to make it today?
17:21:36 <docaedo> ok before we move on - I think we're on the same page re: short term work with horizon, right? I can help get more people engaged on this topic over the next few days too.
17:21:42 <docaedo> (well, more like, next week :)
17:21:52 <kfox1111> yup.
17:22:00 <kfox1111> just setting expectations at this point.
17:22:09 <docaedo> yep, thank you for that
17:22:13 <kfox1111> when we make the json available, it will break in the near future when we decide what to do with it.
17:23:18 <docaedo> yep - though we can include a version in the json itself (clunky but would work), and make the plugin "smart" about what to expect when it pulls in the JSON
17:24:02 <kfox1111> yes, just worred long term, if we get too many entries, that will just break entirely.
17:24:21 <docaedo> very true and good thing to keep in mind...
17:24:29 <kfox1111> we will have to put a search api in front and depricate the single file.
17:25:29 <docaedo> definitely, but I imagine that will come from glance artifact repository right? If we're going to store stuff there, might as well make use of the features and as I understand it, searching the glance repo is part of the package
17:26:06 <kfox1111> yeah. if the POC pans out, the glance api becomes the app catalog api.
17:26:27 <docaedo> +1
17:26:39 <docaedo> ok moving on I think?
17:26:44 <kfox1111> yup.
17:27:17 <docaedo> going to push this to next week and hope ativelkov can join "Backing catalog with glance POS status update (ativelkov)"
17:27:37 <kfox1111> k.
17:27:48 <docaedo> #topic Stale URL checker (gosha)
17:28:59 <docaedo> Think I'll remind one more time via email on this one, and if there's no response we'll have someone else (me probably) take it on.
17:29:19 <docaedo> Seems like a relatively easy thing to do, and there's already examples in the system-config repo
17:29:52 <docaedo> So next topic (and maybe it'll be very short?)
17:29:57 <docaedo> #topic Heat template env (kfox1111)
17:30:24 <kfox1111> was talking with the heat folks, and they believe the environment is somewhat part of the template to be provided by the app developer.
17:30:45 <kfox1111> so we probably should provide an environment_url in addition to the template_url as an option.
17:30:58 <kfox1111> And modify the horizon plugin to support that too.
17:31:42 <docaedo> would environment_url be different than the horizon URL? what would it contain?
17:32:11 <docaedo> (i.e. meant to say "this template only works in rackspace", or "this template only works in HP public cloud"
17:33:29 <kfox1111> long term, the env_url will contain all the options for making it specific to various clouds, and the heat engine will present the appropriate ui to the user to customize.
17:34:34 <kfox1111> so the env would have both nova-network and neutron support and the heat ui would provide the choice, for example.
17:34:40 <docaedo> interesting - I thought that was sort of handled by requirements already, but that expects the user to make sense of them and know what's offered by their provider...
17:34:51 <kfox1111> longer term, I'm pushing for them to make that more automagic in some cases. but baby steps.
17:34:59 <kfox1111> yeah.
17:35:21 <docaedo> yep - well I agree should be some magic there, in theory a template should "just work" :)
17:35:21 <kfox1111> heat now has some cloud introspection capabilities itself.
17:35:45 <kfox1111> yeah. so we talked, and the plan is to do it in heat, rather then try and do a bunch of logic in the app catalog ui.
17:36:27 <docaedo> +10 for that, app catalog should never try to resolve cross-cloud compatability issues IMO
17:36:28 <kfox1111> so we just provide the env file and template file to the heat ui, and they do the rest.
17:36:56 <docaedo> that approach makes sense to me
17:37:19 <kfox1111> I think we're going to still need to do some amount of that, just from the stand point of, if a template's known never to work on an older cloud for example, why bother the user with the option at all?
17:37:41 <kfox1111> same with glance images. don't present hyperv images if the cloud doesn't have hyperv support at all.
17:37:59 <kfox1111> a much easier filtering though.
17:38:11 <docaedo> I would argue that it's on the user to figure that out - yes, through a filter
17:38:23 <docaedo> i.e. uncheck hyper-v images, uncheck vmware images, etc.
17:38:51 <docaedo> so app catalog should not try to discover what a user can use (i.e. do not try to detect if murano is installed somehow)
17:38:58 <kfox1111> google does it with their store. if the phone isn't new enough for the apk, it just doesn't even show it to them.
17:39:13 <kfox1111> its a better user experience.
17:39:42 <kfox1111> it probably shouldn't detect it, but it might be something the operator is allowed to configure.
17:39:53 <docaedo> I see the UX advantage there for sure, but what a can of worms that becomes the further down the stack you try to walk
17:40:12 <docaedo> +1 on allowing operator to limit what is shown in horizon UI
17:41:15 <kfox1111> k.
17:41:59 <docaedo> ready for our last big exciting topic?
17:42:18 <docaedo> #topic Open discussion
17:42:44 <docaedo> sgordon: did you have anything you wanted to cover?
17:43:45 <docaedo> kfox1111: anything from your side?
17:44:00 <kfox1111> nothing else at the moment.
17:44:28 <docaedo> OK looks like we get 15 minutes back :)
17:44:50 <kfox1111> awesome. :)
17:44:56 <docaedo> Thanks - looking forward to continuing the conversation on #openstack-app-catalog
17:45:03 <kfox1111> have a great weekend. :)
17:45:11 <docaedo> you too!
17:45:20 <docaedo> #endmeeting