17:00:34 #startmeeting app-catalog 17:00:39 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:44 The meeting name has been set to 'app_catalog' 17:00:50 #topic rollcall 17:01:05 courtesy ping kfox1111 kzaitsev_ws ativelkov toddjohn 17:01:08 o/ 17:01:12 toddjohn here 17:01:17 o/ 17:01:27 o/ 17:01:32 kind-a o/ 17:02:56 Agenda can be found here: 17:02:59 #link https://wiki.openstack.org/wiki/Meetings/app-catalog 17:03:11 #topic Updates 17:03:58 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 #link https://review.openstack.org/266218 17:04:46 That lead to a good discussion and some re-thinking, as the proposed change includes a completely reformatted assets.yaml file 17:05:30 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 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 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 but anyway, that's a debate for later :) 17:07:51 kfox1111 also has proposed a tool to find when a record was updated (link coming one sec) 17:08:07 #link https://review.openstack.org/267087 17:09:04 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 Any other updates? 17:09:28 * docaedo stops typing for one minute 17:11:05 ok, moving on... 17:11:08 #topic Adding Mistral workflow templates to the catalog 17:12:01 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 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 since then though, we haven't actually had any additional types to include (though tosca, mistral and others were expected/considered) 17:13:42 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 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 spzala: great, thanks for joining! 17:14:08 Who did you speak to in Mistral team? 17:14:26 docaedo: np, thank you! 17:14:33 ninag, toddjohn and .. someone else :) 17:15:05 We're working on a set of operator type workflows 17:16:32 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 Sounds good 17:17:24 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 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 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 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 toddjohn: I agree - is there any central place for mistral stuff right now? I couldn't find anything 17:19:17 hi everyone 17:19:27 rakhmerov: welcome! 17:19:30 I think the mistral team maintains a mistral-extras project 17:19:41 but not sure we want to use that 17:19:45 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 docaedo: the only central place (which is not really a good place) is mistral-extra repo 17:20:07 So it probably should be more of mistral's folks decision, right? 17:20:40 in short: I fully support the idea of keeping Mistral workflows in apps catalog but my concerns are 17:20:42 I agree the app-catalog cores would be the wrong ones to validate/review mistral workflows 17:20:58 * they should be kind of certified 17:21:01 so app-catalog repo should not be the home/review-point for the workflows 17:21:10 against a certain DSL version 17:21:20 right that's what i was thinking too, some kind of cerification 17:21:25 * they should be probably as universal as possible 17:21:49 because it may not make sense to have a bunch of very specific stuff there 17:22:12 or alternatively we can come up with an idea how to categorize them well 17:22:14 structure 17:22:28 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 the first question leads to another question: who's going to be responsible for this certification process 17:23:11 my thought was we just use gerrit and use the standard core review process 17:23:13 docaedo: maybe, I'm sort of thinking loudly 17:23:41 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 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 docaedo: yep, agree 17:24:15 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 yes 17:26:16 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 may I ask a question: where does this idea initially come from? 17:26:28 who would want it? 17:26:34 and why 17:27:17 best practices - no problem 17:27:18 rakhmerov: We are working on a set of operator workflows (cleaning up after tenant delete) 17:27:33 ok 17:27:58 The idea is make these easily available 17:28:22 ok, fair enough 17:29:00 rakhmerov: do you have reservations to adding "just any" mistral stuff to the catalog? 17:29:18 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 docaedo: what do you mean by "reservations"? 17:30:08 sorry, not sure I understood you ) 17:30:40 rakhmerov: wondering if you were concerned that there should be certification/gating or something is all - sounds like no though 17:30:52 I'm excited about it, as I want to get more exposure for mistral 17:31:05 yeah 17:31:06 so 17:31:21 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 as far as certification yes, it's a matter of project reputation kind of 17:32:15 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 just because of a buggy workflow 17:32:28 this is my only concern 17:33:10 badly-written workflows would influence the whole project 17:33:11 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 rakhmerov: well, someone has to support it =) That's why there are supported-by and other stuff 17:33:25 at least "some" certification should apply I guess 17:33:47 So basically if something goes wrong with that asset — the person who has problems basically has someone to ping about it 17:33:56 Do you think that is something that would be beyond the review process? 17:33:58 hm... ok 17:34:04 I think kzaitsev_mb has it right - it's supported by someone in that case 17:34:11 well, it's a valid point, agree 17:34:18 Which actually leads me to the idea of adding irc-handle there as an optional argument 17:34:32 kzaitsev_mb: +1 17:34:35 ok 17:35:14 btw, I personally was really angry when I tried some of the apps from the catalog and they didn't work ) 17:35:36 which apps? 17:35:45 the first strong desire in my head was to blame Murano :) 17:36:00 but that's a general topic I guess and not really relevant to discussion 17:36:05 haha yeah 17:36:15 but it touches on a really good point 17:36:29 right now, as a consumer, you don't have any way to say "tried it, didn't work, ruined my day!" 17:36:37 well, kubernetes apps didn't work well for me at that time 17:36:49 they may have been fixed though already 17:36:50 We are planning to include ratings and feedback, but it's blocked until we implement the v2 api on glare 17:37:11 well the murano team DID just update the kubernetes bits in the catalog! 17:37:26 true ) 17:37:33 yeah, glare is very wanted in many ways ) 17:37:39 (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 ok 17:39:09 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 I mean just to help ourself to keep good image of the project 17:39:54 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 so that if we find bad stuff we could come up with recommendations on how to improve them 17:40:22 sounds good to me 17:40:33 thanks for bringing this up! 17:40:47 rakhmerov I definitely agree it would be valuable to have a way to test/certify/improve the workflows 17:41:05 yeah 17:41:18 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 docaedo: should you need some specific info feel free to reach out to us 17:42:08 rakhmerov: absolutely, thanks - I'm on the IRC channel so will speak up there as things progress 17:42:11 we'll provide necessary assistance 17:42:18 (and on the mailing list of course) 17:42:19 ok, deal 17:42:25 sure ) 17:43:13 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 #topic Open discussion 17:43:55 docaedo: any question related to TOSCA ? 17:44:23 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 ativelkov: thanks, it's on my calendar (I couldn't make it this week, but will next!) 17:44:52 spzala: thanks, actually I did have one thing to say 17:44:55 docaedo: for the current heat templates on catalog - can they be deployed from catalog? (or they are just hosted) 17:45:01 Sure 17:45:39 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 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 docaedo: :-) 17:46:30 docaedo: OK, gotcha 17:46:34 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 But regarding TOSCA, I was going to say something about hosting the heat-translator 17:47:14 docaedo: sure 17:47:16 in looking into it further, I realized part of the translation process includes local resource introspection 17:47:56 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 but I'm happy to be corrected if I'm mistaken 17:49:19 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 will require similar env as in general for any heat template 17:50:52 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 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 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 but if it finds a openstack env then it will try finding best match of flavors based on TOSCA constraints etc. 17:53:48 so technically it's possible to create a generic translation, but how useful would that "generic" version be? 17:54:48 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 docaedo: so for a start I think 17:55:40 Hosting CSAR (contains template, scripts, binaries etc) and hosting individual templates 17:55:47 would be great 17:56:04 spzala: agreed! 17:56:33 docaedo: cool 17:56:47 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 sorry if it's a repeating question but one last question - 17:57:05 no prob 17:57:15 does the uploading of template (e.g. current heat template) go through review process? 17:57:24 btw spzala the work on helping define the attribute schema for the TOSCA parts will be on you 17:57:41 well yes, getting anything added to the catalog goes through review 17:57:50 docaedo: ok, NICE 17:57:57 but the review is just focused on the asset listing matching the schema, and having the right information 17:58:08 it does not validate the heat template even works, or is not malicious 17:58:24 (ie you could upload a glance image that includes your own bitcoin mining daemon) 17:58:24 docaedo: sure, let's discuss the work commitment from my team later as meeting is almost over 17:58:36 you got it 17:58:46 OK, gotcha :-) 17:58:56 time to wrap up - thanks everyone for coming, and I'm looking forward to expanding the catalog with your help! 17:59:24 #endmeeting