17:00:34 <docaedo> #startmeeting app-catalog
17:00:39 <openstack> Meeting started Thu Jan 14 17:00:34 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:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:44 <openstack> The meeting name has been set to 'app_catalog'
17:00:50 <docaedo> #topic rollcall
17:01:05 <docaedo> courtesy ping kfox1111 kzaitsev_ws ativelkov toddjohn
17:01:08 <docaedo> o/
17:01:12 <toddjohn> toddjohn here
17:01:17 <spzala> o/
17:01:27 <kzaitsev_mb> o/
17:01:32 <ativelkov> kind-a o/
17:02:56 <docaedo> Agenda can be found here:
17:02:59 <docaedo> #link https://wiki.openstack.org/wiki/Meetings/app-catalog
17:03:11 <docaedo> #topic Updates
17:03:58 <docaedo> I made some good progress in the last week, and got proposal-bot to check for dead links and propose an updated assets.yaml
17:04:19 <docaedo> #link https://review.openstack.org/266218
17:04:46 <docaedo> That lead to a good discussion and some re-thinking, as the proposed change includes a completely reformatted assets.yaml file
17:05:30 <docaedo> I expected that, and figured after the first review, future changes would include minimal line changes, but there was some objection (noted in review), and the objection is pretty reasonable all things considered
17:06:10 <docaedo> We can debate on the channel, and I need to get an email thread started on this particular topic to see if there are other viewpoints that might help get things moving in a good direction
17:06:54 <docaedo> I'm inclined to be a little bit loose with things (i.e. allow one big ugly change like this) for the sake of making the catalog a little more dynamic while we're still using human-edited yamls
17:07:14 <docaedo> but anyway, that's a debate for later :)
17:07:51 <docaedo> kfox1111 also has proposed a tool to find when a record was updated (link coming one sec)
17:08:07 <docaedo> #link https://review.openstack.org/267087
17:09:04 <docaedo> it works and could be useful, but I feel like we're heading down the road of creating a relational database based on a few yamls, and some script-glue (and I'm pretty opposed that :) )
17:09:18 <docaedo> Any other updates?
17:09:28 * docaedo stops typing for one minute
17:11:05 <docaedo> ok, moving on...
17:11:08 <docaedo> #topic Adding Mistral workflow templates to the catalog
17:12:01 <docaedo> About a week ago I had a conversation with some folks working on Mistral workflows, and let them know we (app catalog people) are very interested in including their workflow templates in the catalog
17:12:28 <docaedo> we did a bunch of work last year to make the catalog schema more flexible so we could include additional asset types
17:12:58 <docaedo> since then though, we haven't actually had any additional types to include (though tosca, mistral and others were expected/considered)
17:13:42 <spzala> docaedo: I am here from TOSCA team to continue discuss on top of some discussion we had last year on hosting/translating TOSCA CSAR and templates
17:13:44 <docaedo> So from the schema/assets.yaml side, all we would need to do is define the metadata a mistral asset will include
17:14:04 <docaedo> spzala: great, thanks for joining!
17:14:08 <ativelkov> Who did you speak to in Mistral team?
17:14:26 <spzala> docaedo: np, thank you!
17:14:33 <docaedo> ninag, toddjohn and .. someone else :)
17:15:05 <toddjohn> We're working on a set of operator type workflows
17:16:32 <docaedo> I will get a blueprint topic started today on launchpad for this, and line up the work items I think we'll need (and those items of course will be debatable)
17:16:55 <toddjohn> Sounds good
17:17:24 <docaedo> in short though I think it's "define metadata, add new type to schema, argue about how to reflect this in the web site, argue about how to reflect in app-catalog-ui, then implement web site and app-catalog-ui changes"
17:17:53 <docaedo> I would say it's too early to argue how to show additional types on the web site, but that's going to be the biggest challenge
17:18:19 <docaedo> the site itself is really built for three asset types, and starting to add additional types to the horizontal bar will get crowded quickly
17:18:19 <toddjohn> I could be interested to know where we should put the workflows.  I would like them under some kind of gerrit review process ( i think)
17:19:05 <docaedo> toddjohn: I agree - is there any central place for mistral stuff right now? I couldn't find anything
17:19:17 <rakhmerov> hi everyone
17:19:27 <docaedo> rakhmerov: welcome!
17:19:30 <toddjohn> I think the mistral team maintains a mistral-extras project
17:19:41 <toddjohn> but not sure we want to use that
17:19:45 <kzaitsev_mb> toddjohn: I'm afraid, that app-catalog folks would not be able to tell you if this or that workflow is worthy of being put on a.o.o, though =)
17:19:50 <rakhmerov> docaedo: the only central place (which is not really a good place) is mistral-extra repo
17:20:07 <kzaitsev_mb> So it probably should be more of mistral's folks decision, right?
17:20:40 <rakhmerov> in short: I fully support the idea of keeping Mistral workflows in apps catalog but my concerns are
17:20:42 <docaedo> I agree the app-catalog cores would be the wrong ones to validate/review mistral workflows
17:20:58 <rakhmerov> * they should be kind of certified
17:21:01 <docaedo> so app-catalog repo should not be the home/review-point for the workflows
17:21:10 <rakhmerov> against a certain DSL version
17:21:20 <toddjohn> right that's what i was thinking too, some kind of cerification
17:21:25 <rakhmerov> * they should be probably as universal as possible
17:21:49 <rakhmerov> because it may not make sense to have a bunch of very specific stuff there
17:22:12 <rakhmerov> or alternatively we can come up with an idea how to categorize them well
17:22:14 <rakhmerov> structure
17:22:28 <docaedo> I would argue the app catalog could host mistral workflows that are very specific, just like it hosts glance images or heat templates that are very specific (as long as the constraints are noted)
17:22:40 <rakhmerov> the first question leads to another question: who's going to be responsible for this certification process
17:23:11 <toddjohn> my thought was we just use gerrit and use the standard core review process
17:23:13 <rakhmerov> docaedo: maybe, I'm sort of thinking loudly
17:23:41 <docaedo> rakhmerov: yeah, that's something I think that needs to be handled by the mistral team and the openstack community - if mistral workflows will also be "certified" somehow, that's a big conversation.
17:23:56 <rakhmerov> I just saw sets of workflows that some our users have :) Not sure if I'd like to see something similar at apps.openstack.org
17:24:12 <rakhmerov> docaedo: yep, agree
17:24:15 <docaedo> but that does not need to be solved before mistral workflows (that are usable by some people) could be included in the app catalog :)
17:25:18 <rakhmerov> yes
17:26:16 <toddjohn> The workflows we have in mind i don't think reallly need to be certified per se, it would be nice though if the community would review them.  Mostly for best practices, etc
17:26:20 <rakhmerov> may I ask a question: where does this idea initially come from?
17:26:28 <rakhmerov> who would want it?
17:26:34 <rakhmerov> and why
17:27:17 <rakhmerov> best practices - no problem
17:27:18 <toddjohn> rakhmerov: We are working on a set of operator workflows (cleaning up after tenant delete)
17:27:33 <rakhmerov> ok
17:27:58 <toddjohn> The idea is make these easily available
17:28:22 <rakhmerov> ok, fair enough
17:29:00 <docaedo> rakhmerov: do you have reservations to adding "just any" mistral stuff to the catalog?
17:29:18 <rakhmerov> it would be actually cool, we also accumulated a number of useful (as we think) workflows that we could contribute into apps catalog
17:29:39 <rakhmerov> docaedo: what do you mean by "reservations"?
17:30:08 <rakhmerov> sorry, not sure I understood you )
17:30:40 <docaedo> rakhmerov: wondering if you were concerned that there should be certification/gating or something is all - sounds like no though
17:30:52 <docaedo> I'm excited about it, as I want to get more exposure for mistral
17:31:05 <rakhmerov> yeah
17:31:06 <rakhmerov> so
17:31:21 <docaedo> I think it's really useful, and if we could catalog a few useful workflows and show them off, makes it easier for people to start to see the value of adding mistral to their environment
17:31:31 <rakhmerov> as far as certification yes, it's a matter of project reputation kind of
17:32:15 <rakhmerov> if one goes to apps catalog, downloads a workflow and it doesn't work then they would probably not want to deal with Mistral any more
17:32:22 <rakhmerov> just because of a buggy workflow
17:32:28 <rakhmerov> this is my only concern
17:33:10 <rakhmerov> badly-written workflows would influence the whole project
17:33:11 <docaedo> yeah that's a tricky one - in general the app catalog position is to accept whatever someone wants to submit - ie. we are not testing glance images or murano apps before inclusion
17:33:20 <kzaitsev_mb> rakhmerov: well, someone has to support it =) That's why there are supported-by and other stuff
17:33:25 <rakhmerov> at least "some" certification should apply I guess
17:33:47 <kzaitsev_mb> So basically if something goes wrong with that asset — the person who has problems basically has someone to ping about it
17:33:56 <toddjohn> Do you think that is something that would be beyond the review process?
17:33:58 <rakhmerov> hm... ok
17:34:04 <docaedo> I think kzaitsev_mb has it right - it's supported by someone in that case
17:34:11 <rakhmerov> well, it's a valid point, agree
17:34:18 <kzaitsev_mb> Which actually leads me to the idea of adding irc-handle there as an optional argument
17:34:32 <docaedo> kzaitsev_mb: +1
17:34:35 <rakhmerov> ok
17:35:14 <rakhmerov> btw, I personally was really angry when I tried some of the apps from the catalog and they didn't work )
17:35:36 <docaedo> which apps?
17:35:45 <rakhmerov> the first strong desire in my head was to blame Murano :)
17:36:00 <rakhmerov> but that's a general topic I guess and not really relevant to discussion
17:36:05 <docaedo> haha yeah
17:36:15 <docaedo> but it touches on a really good point
17:36:29 <docaedo> right now, as a consumer, you don't have any way to say "tried it, didn't work, ruined my day!"
17:36:37 <rakhmerov> well, kubernetes apps didn't work well for me at that time
17:36:49 <rakhmerov> they may have been fixed though already
17:36:50 <docaedo> We are planning to include ratings and feedback, but it's blocked until we implement the v2 api on glare
17:37:11 <docaedo> well the murano team DID just update the kubernetes bits in the catalog!
17:37:26 <kzaitsev_mb> true )
17:37:33 <rakhmerov> yeah, glare is very wanted in many ways )
17:37:39 <docaedo> (but I think kubernetes is still new enough to where it should probably be handled manually, but that's just the old operator in me talking)
17:38:00 <rakhmerov> ok
17:39:09 <rakhmerov> getting back to certification idea.. I guess we, Mistral team, would be interested in going to apps catalog once in a while and try out workflows
17:39:41 <rakhmerov> I mean just to help ourself to keep good image of the project
17:39:54 <docaedo> Then I think we're agreed on this topic for now? I need to do the blueprint, we can debate on #openstack-app-catalog, and in parallel maybe it's time to start up a conversation about certification of mistral bits (on ML and/or #openstack-mistral)
17:40:05 <rakhmerov> so that if we find bad stuff we could come up with recommendations on how to improve them
17:40:22 <rakhmerov> sounds good to me
17:40:33 <rakhmerov> thanks for bringing this up!
17:40:47 <docaedo> rakhmerov I definitely agree it would be valuable to have a way to test/certify/improve the workflows
17:41:05 <rakhmerov> yeah
17:41:18 <docaedo> I'll be part of the conversation if it gets started, but I don't know enough about mistral internals yet to have a strong opinion on a test harness or whatever
17:41:46 <rakhmerov> docaedo: should you need some specific info feel free to reach out to us
17:42:08 <docaedo> rakhmerov: absolutely, thanks - I'm on the IRC channel so will speak up there as things progress
17:42:11 <rakhmerov> we'll provide necessary assistance
17:42:18 <docaedo> (and on the mailing list of course)
17:42:19 <rakhmerov> ok, deal
17:42:25 <rakhmerov> sure )
17:43:13 <docaedo> the next topic on the agenda (glare outline) requires kfox1111, ativelkov and kzaitsev_mb ..  I think we have 1.5 out of 3 today, so we can push to next week
17:43:34 <docaedo> #topic Open discussion
17:43:55 <spzala> docaedo: any question related to TOSCA ?
17:44:23 <ativelkov> some glare update: we've moved the weekly glance/artifacts meeting to 17:00 UTC on Mondays at #openstack-meeting-alt, so please feel free to join to discuss glare agenda
17:44:44 <docaedo> ativelkov: thanks, it's on my calendar (I couldn't make it this week, but will next!)
17:44:52 <docaedo> spzala: thanks, actually I did have one thing to say
17:44:55 <spzala> docaedo: for the current heat templates on catalog - can they be deployed from catalog? (or they are just hosted)
17:45:01 <spzala> Sure
17:45:39 <docaedo> spzala: well regarding heat templates, the basic answer is "yes". The direct answer is that the catalog is just a pointer to where to find the template
17:46:02 <docaedo> so if you find a heat template in the catalog, the detail page tells you specifically where to get the template - and since heat lets you specify a URL for a template, you can just paste that URL in
17:46:11 <spzala> docaedo: :-)
17:46:30 <spzala> docaedo: OK, gotcha
17:46:34 <docaedo> the app-catalog-ui goes one step further though, and will pull in the template along with environment vars specified in the template AFAIK
17:46:57 <docaedo> But regarding TOSCA, I was going to say something about hosting the heat-translator
17:47:14 <spzala> docaedo: sure
17:47:16 <docaedo> in looking into it further, I realized part of the translation process includes local resource introspection
17:47:56 <docaedo> so the template that heat-translator generates is different from one environment to the next (as I understand it), which means we could not really host a page that says "convert this TOSCA template to a Heat template"
17:48:11 <docaedo> but I'm happy to be corrected if I'm mistaken
17:49:19 <spzala> docaedo: can you pl give example of local resource introspection? The heat-translator doesn't require a specific env but translated template which is 'heat template'
17:49:51 <spzala> will require similar env as in general for any heat template
17:50:52 <docaedo> ah then someone misled me - I thought part of the translation was to match up what resources are available (like glance images and flavors, networks, etc.)
17:52:09 <spzala> docaedo: well, it's mix so heat-translator if used outside OpenStack env then doesn't not use nova or glance and uses a pre-defined set of flavors and images
17:53:08 <docaedo> ok but I would argue a "generic" set of flavors and images would not be very useful, as almost every environment I have access to has different both
17:53:23 <spzala> but if it finds a openstack env then it will try finding best match of flavors based on TOSCA constraints etc.
17:53:48 <docaedo> so technically it's possible to create a generic translation, but how useful would that "generic" version be?
17:54:48 <spzala> docaedo: that's true.. though there are folks who may prefer to update image or flavor themselves later but I agree with you that not much useful as it doesn't give out  of box deployment experience
17:55:06 <spzala> docaedo: so for a start I think
17:55:40 <spzala> Hosting CSAR (contains template, scripts, binaries etc) and hosting individual templates
17:55:47 <spzala> would be great
17:56:04 <docaedo> spzala: agreed!
17:56:33 <spzala> docaedo: cool
17:56:47 <docaedo> we are almost out of time, but we should continue this conversation - I'll add it to next weeks agenda, and potentially start a thread on the ML as well
17:56:57 <spzala> sorry if it's a repeating question but one last question -
17:57:05 <docaedo> no prob
17:57:15 <spzala> does the uploading of template (e.g. current heat template) go through review process?
17:57:24 <docaedo> btw spzala the work on helping define the attribute schema for the TOSCA parts will be on you
17:57:41 <docaedo> well yes, getting anything added to the catalog goes through review
17:57:50 <spzala> docaedo: ok, NICE
17:57:57 <docaedo> but the review is just focused on the asset listing matching the schema, and having the right information
17:58:08 <docaedo> it does not validate the heat template even works, or is not malicious
17:58:24 <docaedo> (ie you could upload a glance image that includes your own bitcoin mining daemon)
17:58:24 <spzala> docaedo: sure, let's discuss the work commitment from my team later as meeting is almost over
17:58:36 <docaedo> you got it
17:58:46 <spzala> OK, gotcha :-)
17:58:56 <docaedo> time to wrap up - thanks everyone for coming, and I'm looking forward to expanding the catalog with your help!
17:59:24 <docaedo> #endmeeting