17:00:38 <docaedo> #startmeeting app-catalog
17:00:40 <openstack> Meeting started Thu Jun 18 17:00:38 2015 UTC and is due to finish in 60 minutes.  The chair is docaedo. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:43 <openstack> The meeting name has been set to 'app_catalog'
17:00:58 <docaedo> Todays agenda available here:
17:00:58 <docaedo> #link https://wiki.openstack.org/wiki/Meetings/app-catalog
17:01:09 <docaedo> #topic rollcall
17:01:19 * fifieldt waves
17:01:23 <muralia> o/
17:01:26 <fifieldt> unfortunately, it's 1am, so I can't stay :)
17:01:35 <datsun180b> <--
17:01:40 <docaedo> ah yes, I know so late for you, sorry
17:02:12 <kebray> \o
17:02:23 <jlk> is this for the ops guide?
17:02:29 <devkulkarni> devkulkarni
17:02:35 <datsun180b> jlk: app catalog
17:02:38 <james_li> james li
17:02:42 <docaedo> jlk: this is for the app catalog http://apps.openstack.org
17:02:44 <jlk> strange, maybe there was a conflict.
17:02:45 <jproulx> I was also looking for ops guide
17:03:11 <docaedo> Hmm, this merged without conflict, and didn't show anything else on the calendar?
17:03:48 <kebray> jlk, maybe the ops meeting is an another hour?   A lof of the time conversion websites are wrong.  I tried to join the app-catalog meeting an hour ago.
17:04:00 <datsun180b> it's 1704Z by my clock
17:05:18 <docaedo> Moving on I think? sorry for confusion, I have 17:05 zulu on my clock too :)
17:05:42 <kfox1111> yeah.
17:05:46 <docaedo> #topic Announcements
17:05:54 <docaedo> Moving app catalog hosting to OpenStack infra complete as of 6/15:
17:05:54 <docaedo> #link https://review.openstack.org/187863
17:05:54 <docaedo> #link https://review.openstack.org/189993
17:05:54 <docaedo> #link https://review.openstack.org/187018
17:06:07 <docaedo> Regarding infra and hosting, changing the object store to community managed one (vs. current rackspace files location) is something I propose we discuss later, as it's not pressing.
17:06:27 <docaedo> We don't have a flood of incoming binaries to host ATM, and it's "on OpenStack" so not a rush - I will start a discussion on ML for how best to handle it going forward.
17:06:37 <docaedo> #action docaedo start ML discussion re: object store for app catalog
17:06:50 <docaedo> I also wanted to point out a few pending reviews for general openstack project housekeeping. If you want to review these, please do - they're basically ready to go AFAIK
17:06:56 <docaedo> #link https://review.openstack.org/191990 (add site to cacti)
17:06:56 <docaedo> #link https://review.openstack.org/190343 (enable IRC logging)
17:06:57 <docaedo> #link https://review.openstack.org/191478 (mailing list)
17:07:09 <docaedo> That last one, the mailing list, relates to the "handling stale entries" topic that I was going to let Gosha lead but he's on vaca until next week, so we'll pick it up next week.
17:07:26 <docaedo> Any other announcements?
17:08:19 <docaedo> ok, guess not - moving on
17:08:22 <kebray> docaedo, just that we'd like to get Solum languagepacks avaialble on apps.openstack.org.  what are the requirements?
17:08:46 <kebray> That is, how are things decided to be listed or not listed as a new category on apps.openstack.org?
17:09:02 <kebray> so, not an announcement.. a question.  we can take it up later if need be.
17:09:10 <docaedo> kebray: let's cover that later, but today - we need to discuss how to add more categories (and definitely want to see solum LPs in there)
17:09:19 <kebray> great!  thx.
17:09:24 <docaedo> #topic Proposal: stale entries (kfox1111)
17:10:02 <docaedo> kfox1111: you had started a conversation on the mailing list re: stale entries, and for a start, I think you wanted to add an additional field
17:10:13 <kfox1111> yeah.
17:10:19 <docaedo> something like "entry_maintainer" or so
17:10:26 <sgordon> makes sense
17:10:36 <kfox1111> if something breaks, how do we know how to contact the maintiner to fix their website,
17:10:46 <sgordon> i would think we could also do some automation to detect if a url is now a 404?
17:10:48 <kfox1111> or let them know we will pull the entry after some amount of time with it being broken.
17:11:05 <kfox1111> yeah. with such a field, eventually it could pull and notify directly.
17:11:11 <docaedo> makes sense to me, and yes, this field would be useful for an automatic script checking external links
17:12:11 <docaedo> Gosha volunteered to write a simple script that zuul would run periodically, to check external links and notify a mailing list (plus the email), so I see that as phase 2, but first off
17:12:27 <docaedo> add this field to the schema
17:12:55 <docaedo> should we populate the entries with whoever put in the patch relating to that entry?
17:13:16 <docaedo> (pre-populate for now I mean, and then going forward just make it a required field)
17:13:38 <kfox1111> that, and maybe email them letting them know we've done that, giving them the opertunity to change it if they want.
17:13:47 <docaedo> +1
17:13:48 <kfox1111> yeah. required as soon as possible would be good.
17:14:07 <docaedo> any volunteers to do this?
17:14:44 <kfox1111> I can take a stab at it I think.
17:15:08 <docaedo> thanks, I'll help, will coordinate with you on IRC
17:15:15 <kztsv_mbp> also. how would taking down work? Is there an enabled/disabled param, that can be switched on/off in a yaml file or shall the whole entry be removed?
17:15:34 <kfox1111> related to that, should we create a common.schema.yaml that we validate all the other yamls against? Then I can put the required admin metadata stuff in there.
17:15:47 <kztsv_mbp> Sorry if that has been discussed or if I'm asking a dumb question.
17:15:49 <docaedo> +1 on common.schema.yaml
17:16:10 <docaedo> kztsv_mbp: not a dumb question, and hasn't been decided exactly
17:16:23 <docaedo> the method for removal right now is a code review
17:16:28 <kfox1111> there isn't a field yet, but we could add one. a hidden/disabled" field?
17:16:49 <docaedo> I think it's better to pull something out completely if there's reason to - easy enough to add later, and to me makes sense to drop the entry entirely
17:16:59 <docaedo> with justification noted in the commit message
17:17:10 <kfox1111> yeah, so long as we're backing it with git, we still have all the history, so adding it back would be easy.
17:17:11 <docaedo> then there's an obvious trail of who wanted something out, and why
17:17:41 <docaedo> exactly - as much as possible I want to use the gerrit workflow
17:18:00 <kztsv_mbp> docaedo: the reasoning behind the question is that taking the whole entry down is a, rather drastic thing to do. A person who submitted the asset would have to go through the review process from scratch.
17:18:21 <kztsv_mbp> While flipping a bool field seems like a less restrictive approach
17:18:44 <kfox1111> I think we probably should come up with a policy of some sort. we send 3 or 4 emails over some time period, then pull it.
17:18:56 <docaedo> true, but just flipping the bool would only hide it from the web site frontend, it would still be in the yaml
17:19:08 <kfox1111> maybe we have a flag we set on the entry as soon as its detected flagging it visually to the users as potentially broken?
17:19:09 <docaedo> so if there is a need for somethign to be "not there", seems completely removing it is the best option
17:19:40 <sgordon> would the boolean be in the yaml anyway though?
17:19:53 <docaedo> but maybe in case of something being temporarily 404 (like while the zuul checker happened to run), completely removing would seem drastic, yeah
17:20:04 <kfox1111> agreed.
17:20:14 <kfox1111> or they are in a downtime for an hour or so.
17:20:27 <docaedo> and yes, the boolean would be in the yaml too - my question I guess is what's the advantage of hiding over removing
17:20:28 <kfox1111> shouldn't totally kill things.
17:21:00 <kfox1111> theres a window, 404 detected ...... user tries to launch,
17:21:08 <kfox1111> that it could be fixed between.
17:21:16 <kztsv_mbp> docaedo: it's more like a 2 step removing. If the entry is down for 2 days — flip the switch. If it's still down after a week and the author didn't contact anyone — remove completely
17:21:46 <sgordon> right
17:21:48 <kfox1111> if its only checked once a day for example, it could have been fixed after only an hour, and users wouldn't be able to use it for 23 more.
17:22:22 <sgordon> i dont think we would have to check as infrequently as once a day for a simple is the link valid
17:22:28 <docaedo> kztsv_mbp: I could see that, but would personally advocate for putting in a review that removes it, mark it WIP, and send the "owner" a warning that it's marked for removal
17:22:44 <sgordon> if we wand to download it and confirm that hash then that is more invasive
17:22:51 <sgordon> docaedo, +1 i like that approach
17:23:15 <docaedo> otherwise my fear is that we'll eventually be flipping that bool on and off a lot (and if we do that, we could end up with dozens of flipping on and off)
17:23:20 <kztsv_mbp> oh. yep. I'm not advocating automatic removing here.
17:23:22 <sgordon> to me if the bool is in the yaml anyway there is no advantage over proposing removal - in either case both the removal and adding it back later require a review cycle
17:23:57 <kfox1111> yeah. you'd have to have the bool outside the yaml that gets merged in on retrieve to be more automatic.
17:24:22 <docaedo> yeah when it comes to automating this stuff, I want to push that conversation down the road a little bit
17:24:22 <kfox1111> probably more trouble then its worth for now.
17:24:33 <kztsv_mbp> The flipping could possibly be a commit, by some bot then? but be approved by those with common sense =)
17:24:51 <docaedo> eventually, we are going to need to tackle that stuff, maybe even soon-ish, but right now with just having flat yamls, easier to minimize the number of commits
17:25:21 <docaedo> yep, whether it's a bool flip, or full removal, still needs human to +2
17:25:26 <kfox1111> It may be tricky to automate the yaml editing without causing other lines in the file to be rearanged.
17:25:36 <docaedo> how about this:
17:25:49 <docaedo> I'll write up the options, send to ML, and we'll let broader audience weigh in?
17:26:09 <kztsv_mbp> sounds right to me =)
17:26:11 <kfox1111> k
17:26:23 <docaedo> nice :) moving on...
17:26:24 <sgordon> kfox1111, mmm the marker for the start of an entry is fairly easy to spot though iirc
17:26:33 <sgordon> kfox1111, is simple a matter of chopping from there to the next one
17:26:54 <kfox1111> yeah. just not as simple as yaml import, set new value, yaml export though.
17:27:13 <sgordon> kfox1111, sure but if at some point you have to remove it anyway...
17:27:22 <docaedo> sgordon: I'm with you, adjusting or chopping is going to be pretty easy to automate
17:27:41 <kfox1111> thats why I'd kind of perefer it be in a seperate document thats merged on fetch.
17:28:01 <kfox1111> I'm thinking we may want to do that anyway down the line for stuff like user submitted stars.
17:28:21 <kfox1111> don't want to need a gerrit review for all of those. :/
17:28:42 <docaedo> kfox1111: user submitted stars as patches would overwhelm the catalog instantly, and poses too high a barrier for people to give their thoughts on an asset
17:29:00 <kfox1111> exactly.
17:29:09 <docaedo> that topic is a big one, in a little bit we'll have a quick throw down of things to discuss
17:29:18 <docaedo> for now, lets move on and take this topic to ML
17:29:24 <kfox1111> k.
17:29:26 <docaedo> #topic Versions for entries (docaedo)
17:29:28 <sgordon> yeah i dont think necessarily merging in a separate file scales for that use case anyway
17:30:00 <docaedo> It would be nice to version the entries in some way, but maybe it's not even worth discussing as long as we have everything in a flat yaml
17:30:12 <docaedo> but I wanted to bring up today because it's an issue that has popped up several times
17:30:31 <sgordon> docaedo, what kind of versioning were you imagining - different versions of the same asset class (e.g. Ubuntu 14.04 vs 15.04) or the entry itself
17:30:32 <docaedo> and not really sure the best way to deal with it right now - what do you think, do we even NEED to deal with this right now?
17:30:44 <docaedo> sgordon: the entry iteself
17:30:57 <sgordon> mmm, i guess what are the examples where it has come up?
17:30:58 <docaedo> the example would be an updated entry
17:31:02 <sgordon> right
17:31:05 <kfox1111> I was thinking the same thing earlier. If we want to be able to support downloading a set of artifacts that are dependencies of the app the user wants to launch, we proabably need some versioning stuff in the entries.
17:31:07 <sgordon> i just wonder if the user cares
17:31:18 <sgordon> or do they just want the most up to date entry always
17:31:22 <docaedo> like new murano asset with associated bits, gets a change -
17:31:33 <docaedo> sgordon: I think that's a good point, user shouldn't care
17:31:42 <kfox1111> no, often users do care. :/
17:31:49 <docaedo> and until we have a more complicated back end, probably not worth spending much time/thought on this
17:31:58 <sgordon> it depends on the class of user
17:32:10 <sgordon> the users who do care in my experience probably arent grabbing random stuff off the web
17:32:10 <kfox1111> because new software has a horible tendency to break old data/modules. :/
17:32:14 <sgordon> but maintaining their own catalog
17:32:31 <kfox1111> people tend not to care, until they do. :/
17:32:32 <sgordon> maybe a problem worth punting, not sure
17:32:43 <docaedo> kfox1111: I don't see where people are going to turn to app catalog as an update though, would they?
17:32:49 <kfox1111> ok punting for now, but I think we'll see it come back eventually.
17:32:52 <sgordon> right
17:32:54 <docaedo> yeah, agree with punting
17:32:55 <sgordon> atm for all classes
17:33:01 <sgordon> you have to pull the entire thing again
17:33:05 <sgordon> there is no update in place as such
17:33:34 <docaedo> lets move on, spend just a few minutes on the next topic:
17:33:37 <docaedo> #topic Discussion: ideas for getting more contributors involved?
17:33:39 <kztsv_mbp> sry, what's punting? +) are we postponing the issue for now?
17:33:55 <docaedo> yes, postponing the issue for now, but not forgetting about it :)
17:34:05 <kfox1111> oh. sorry. yeah, postponing.
17:34:29 <kztsv_mbp> ok. anyway with flat yaml I can't imagine a feasible way to version things
17:34:44 <docaedo> So just wanted basically a few quick thoughts on how we can get more people interested and involved, all of which will likely lead to work on mailing lists or something (but
17:34:53 <sgordon> mmm well you could but you'd basically have to keep all versions of each entry
17:35:07 <sgordon> plus versioning in a separate field, fairly manual and prone to error
17:35:11 <docaedo> I want to get more feedback from you all on that topic)
17:35:11 <sgordon> anyway...
17:35:26 <kfox1111> yeah.
17:35:36 <sgordon> well i think the conversations on the dev list are a good start at drumming up some interest
17:35:43 <sgordon> e.g. the solum lang packs thing that came up
17:35:56 <kfox1111> distro's have very similar issues.
17:35:56 <sgordon> trying to work out how to fit in with other existing efforts
17:36:22 <docaedo> sgordon: good point, and yeah - for now maybe there's not much more to do other than keep active on ML, as for other integrations
17:36:46 <docaedo> will pitch that as a topic to discuss in future meetings, kfox1111 and I have mentioned some of that on IRC
17:37:24 <docaedo> (but big topic - integrate with other projects, or make standalone app and horizon panel that plugs in to other projects)
17:37:45 <docaedo> actually that topic alone should stir up a lot of conversation on ML :)
17:38:03 <sgordon> yeah
17:38:08 <kfox1111> Yeah, I think we've got 3 different use cases we may want to cover.
17:38:17 <ativelkov> I still believe that it should be tigthly integrated with Glance Artifacts aka v3
17:38:29 <sgordon> it does seem to me like there is some scope for some additional UI, even though obviously murnao, heat, glance all have UI enablement of their own
17:38:35 <kfox1111> * Global place to find OpenStack compatable Artifacts.
17:38:47 <docaedo> I think we already moved on to next topic, perfect!
17:38:48 <docaedo> #topic Discussion: other topics to cover, longer-term roadmap ideas
17:38:50 <kztsv_mbp> actually integrating with horizon would be super-nice. Imagine you have app-catalog as a source of the image in glance. And say, have autosuggestions as you type, that suggest images from app-catalog.
17:39:19 <kfox1111> *Single global,  Google AppStore like thing for OpenStack Clouds. Ie, user runs app, it works. no need to assemble themselves.
17:39:28 <kfox1111> and 3,
17:39:57 <kfox1111> * Global repository for contributed OpenSource artifacts that can be maintaned by the community (OpenSource heat templates, for example)
17:40:48 <kfox1111> kztsv_mbp: I have a bit of a prototype on my box of horizon integration. :)
17:41:25 <kfox1111> the new angular stuff made most of it very simple.
17:41:50 <docaedo> OK - so first topic for deeper discussion: integration with other projects
17:42:59 <docaedo> kebray wanted to cover adding additional content, want to make sure we catch that during open discussion next
17:43:15 <kfox1111> +1.
17:43:26 <docaedo> but before moving on, what other points/issues/concerns did you all have in mind, for things we need to cover in the next few weeks/months?
17:43:33 <kfox1111> Would like some way to distinguish catagory #1 things from #2 things though.
17:43:52 <kfox1111> A user is never going to want to launch a "solum language pack" themselves, since its just a shared library artifact.
17:44:11 <kfox1111> so some tag that destinguishes "applications" from non apps would be useful.
17:44:48 <ativelkov> kfox1111: I believe that the user is not lauchning anything at all
17:45:12 <docaedo> ah that's a good point - catalog is meant to be a place for "things that run on openstack", not necessarily lower level things
17:45:22 <kfox1111> ativelkov: For the horizon prototype I've been working on, you'd be able to select a heat template for example, and then go right into the launch heat stack workflow.
17:45:23 <docaedo> like not the right place for puppet manifests
17:45:31 <kebray> docaedo, I have to go grab food before my next meeting in 15 minutes. If there are requirements to add new things, can you hit me up on IRC later in the app-catalog channel or send email to mailing list?
17:45:36 <arunrajan> +1 on Horizon plugin. I expect ability to "single click" deploy community verified apps would be useful. Curious - how to showcase credibility for templates/packages. i.e. anyway to see if other users have used and rated it high (thinking of an e-commerce shopping experience)
17:45:39 <ativelkov> kfox1111: right, but that is the HEAT which runs it
17:45:46 <ativelkov> so, apps are run by Murano
17:45:53 <docaedo> kebray: sure, will be sure to coordinate this with you on IRC or mailing list
17:45:54 <kfox1111> but it is a solum (openstack) artifact, so it does make sense to go in the catalog.
17:45:56 <ativelkov> Images are spawned into VMs by Nova
17:46:01 <ativelkov> etc
17:46:18 <kfox1111> yeah, so lets take glance.
17:46:28 <ativelkov> The catalog just provides artifacts for the services to consume it
17:46:32 <kfox1111> there may be applience images that are "apps" that the user can simply "launch".
17:46:51 <sgordon> right
17:46:56 <kfox1111> there may be images that need a murano app or heat stack to be useful. the image would not be tagged as an app.
17:47:08 <kfox1111> but still available so the machinery could find and download it as needed.
17:47:18 <sgordon> makes sense
17:47:40 <kfox1111> so users may want to filter out all things not marked with the app tag.
17:47:43 <sgordon> there may also be cases where the image is usable standalone *and* augment via heat and/or murano usage
17:47:49 <sgordon> but an app tag would cater to that too i think
17:47:56 <kfox1111> sgordon: then its an app I think.
17:47:59 <sgordon> right
17:48:02 <kfox1111> no reason an app cant be used by another.
17:48:19 <sgordon> similar situation exists as i understand it for the containerized apps on murano
17:48:24 <sgordon> where they depend on each other
17:48:38 <ativelkov> In Artifacts Repository we distinguish artifacts and just binary assets. The image which is unusable on its own is not a standalone artifact in this point of view
17:48:48 <docaedo> yep, I think the idea of tagging something as an app vs. a component makes sense to me
17:48:56 <muralia> +1
17:49:10 <sgordon> i guess the existential question i have is w.r.t. the operating system images
17:49:18 <sgordon> they aren't really apps, but they are used to layer apps on
17:49:25 <sgordon> some users will want to use them directly though
17:49:34 <kfox1111> yeah. they are rather gray. ubuntu is usually a building bloc, but could be considerdd an app of its own.
17:49:35 <docaedo> I would say if they work standalone, they count as an app in this context
17:49:47 <sgordon> yeah im ok
17:50:00 <kfox1111> +1.
17:50:10 <docaedo> so bigger topic here for further discussion: tagging and categorizing assets
17:50:12 <sgordon> in the case of a lot of the glance images i guess mentally i think of them more as appLIANCE than appLICATION
17:50:13 <sgordon> :)
17:50:13 <devkulkarni> docaedo: what do you mean by work standlone?
17:50:21 <kztsv_mbp> Can't the idea seems nice, although might not apply cleanly to murano apps, as some of them can be used both as a standalone app and a component. but that makes it an app. so I might be wrong =)
17:50:29 <devkulkarni> s/standlone/standalone/
17:50:44 <kfox1111> slight clarification. if its a bare os image, like "Centos 7", then tag as an app.
17:50:48 <sgordon> kztsv_mbp, right i think that is the same as what i was getting at above
17:50:55 <ativelkov> kztsv_mbp: well, Murano packages may be class libraries
17:51:02 <sgordon> kztsv_mbp, both the individual apps and their combination are an "app'
17:51:03 <kfox1111> if its somethting like "centos 7 with trove guest agent", its really a component of trove and not an app.
17:51:04 <docaedo> devkulkarni: I mean like a glance image that is useful on it's own, vs. a glance image that's really meant to be used by heat or murano as a base component for an application stack
17:51:44 <devkulkarni> docaedo: I see..
17:52:06 <muralia> docaedo: who add's these tags? in solums case, would solum add a tag to an atrifact once added to the catalog? or are these preset tags in the catalog?
17:52:08 <devkulkarni> kfox1111: solum languagepacks would be bare os images.. tagging them as an app seems bit incorrect.. is the tagging system extensible?
17:52:28 <kfox1111> devkulkarni: no, because there's no way to boot a bare language pack in solum I believe.
17:52:38 <docaedo> muralia: my thinking is that assets are tagged by whoever adds it
17:52:38 <kfox1111> you add a git repo that is your app.
17:52:44 <devkulkarni> ok, that makes sense
17:52:56 <devkulkarni> so solum lps won't be tagged as an app. makes sense
17:53:18 <sgordon> docaedo, +1
17:53:33 <devkulkarni> docaedo: +1
17:53:44 <sgordon> user tagging might be something we look at later but this one seems fairly fundamental as something you should know at the time you are adding the entry
17:54:03 <docaedo> but tagging is for next week (or mailing list this week), as the catalog is not structured to easily support that right now
17:54:11 <kztsv_mbp> +1. if the reviewer thinks that the tag is inappropriate he will -1 the review
17:54:19 <docaedo> I do see tagging as essential though for expanding the assets that the catalog can hold
17:54:29 <sgordon> inded
17:54:31 <sgordon> *indeed
17:54:31 <devkulkarni> yes
17:54:41 <docaedo> big topic, but maybe most important thing to sort next
17:55:04 <docaedo> because if we get it right (and we will!), makes the app catalog useful for more and more "things that run on openstack"
17:55:09 <muralia> i would like extensible tags as I'm also looking at storing lots of metadata for me to search for solum LPs
17:55:28 <muralia> such as: give me all LPs bases on ubuntu 14.04
17:55:41 <muralia> or all LPs of type Python
17:56:05 <docaedo> muralia: yes, also impacts ability to rate/star assets, and provide feedback about them as well - none of that works in flat yamls reviewed in gerrit
17:56:28 <kfox1111> that brings up elastic serch... :)
17:56:45 <docaedo> so I'm big +1 for more metadata, but -1 if we start cramming 75-100 lines per asset, all in a handful of yaml files
17:56:49 <muralia> +1
17:56:53 <kfox1111> should we install it on the server and dump all the yaml's in?
17:57:04 <kfox1111> would make searching it very simple.
17:57:15 <kfox1111> faceting too.
17:57:28 <docaedo> kfox1111: would need to see a blueprint with a way to see a POC of that I think, so we can get more eyes on it
17:57:41 <kfox1111> k.
17:57:41 <docaedo> seems a great idea though :)
17:57:51 <docaedo> (three minutes left, and I have to jump immediately after btw)
17:58:05 <kztsv_mbp> I have a really small and really unrelated topic — I would suggest we research/adopt a better UI, regarding copy-pasting the of the glance/murano name field. Currently it's 1) editable, 2) there is no copy button. If no one objects — I would like to volunteer and improve it. I have smth like gerrit or github fields in mind.
17:58:05 <muralia> one more question, will the catalog actually store the artifact, or just a pointer to glace or swift or whereever the actual artifact is stored?
17:58:48 <docaedo> kztsv_mbp: sounds good, want to put that in a blueprint?
17:59:13 <kztsv_mbp> It might require a flash solution, I guess there was some discussion about it on github. But in any case I feel that it really needs to be improved, as it is the UI, the user interacts with.
17:59:14 <docaedo> muralia: yes I think the ultimate plane is to have catalog store the asset (think docker repository)
17:59:23 <muralia> ok
17:59:23 <docaedo> flash! yikes!
17:59:25 <ativelkov> I want to try making a POC of running the catalog's API on Glance V3
17:59:28 <kfox1111> muralia: That was what I was talking about I think with use case #3. We have no such place currently.
17:59:58 <docaedo> we're out of time .. but good conversation!
18:00:09 <docaedo> let's take the rest up on #openstack-app-catalog
18:00:10 <muralia> thanks all.
18:00:16 <docaedo> and I'll send update later today to ML
18:00:19 <kztsv_mbp> docaedo: ok. I think I'll be able to do it over the weekend, maybe =)
18:00:27 <docaedo> thanks everyone!
18:00:31 <docaedo> #endmeeting