17:01:40 #startmeeting app-catalog 17:01:41 Meeting started Thu May 26 17:01:40 2016 UTC and is due to finish in 60 minutes. The chair is docaedo. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:44 The meeting name has been set to 'app_catalog' 17:01:52 #link https://wiki.openstack.org/wiki/Meetings/app-catalog Agenda 17:02:21 Just in case, we're out of electricity in the office, so I can drop offline any minute. Will try to switch to mobile network then 17:02:31 #topic Glare status update 17:02:34 Can anyone give an update on glare status? 17:02:49 igormarnat_: thanks for the heads up, hope the electricity comes back quick 17:03:00 o/ 17:03:14 kzaitsev_mb: you had news about glare in app catalog, there was some progress, right? 17:04:04 Well, I've finished all the work I wanted to do with the UI side of the things 17:04:31 I blieve at the summit we've agreed to fill in how we can proceed with merging, but I still haven't done that %) 17:04:51 I have faith you'll get to it :) 17:05:02 hey! 17:05:06 kzaitsev_mb: When do you think we'll be able to switch catalog to glare backend, what else needs to be done? 17:05:09 The basic idea was that we can start merging the commits and turn glare code off by default 17:05:25 so, there is a spec 17:05:29 #link https://review.openstack.org/#/c/283136/ 17:05:44 next step would be to install glare on a.o.o and turn it on 17:05:54 it's about Glare v1 API and general use cases 17:06:22 And after doing so — we would need to make the API private, since it's going to change once we get to v1 API from GLARE team 17:06:25 I think there's a bunch of testing before we turn it on 17:07:02 current plan in glance team - to have 'core' code done by the 10th of June 17:07:04 have to validate we have an automated method to add/remove assets based on whats in assets.yaml because we don't have user auth yet, so only way to adjust the catalog is still going to be through assets.yaml 17:07:09 And in between those two — we still need to work on auth middleware. 17:07:18 and merge it on 15th 17:08:33 o/ 17:08:38 So my next steps from here are to update the patches, so that glare is turned off by default. I'll make a list of those patches (an etherpad maybe) with explanation of the impact, maybe. 17:08:40 somewhere along the way we can start working on puppetizing the installation of glare (assuming access to DB via trove) 17:08:51 mfedosin: thanks for update, merge by June, 15 sounds good 17:08:52 docaedo: kfox1111: does that sound ok? =) 17:09:07 kzaitsev_mb: that sounds good, once we can safely merge that stuff it'll give us a safe path forward 17:09:19 also means it becomes a little easier to test/validate locally 17:09:54 here's the log from todays glance meeting http://eavesdrop.openstack.org/meetings/glance/2016/glance.2016-05-26-14.03.log.html 17:10:05 oh and I should definitely get my hands on the auth stuff. 17:10:24 mfedosin: feel free to use #link ;) 17:10:34 #link http://eavesdrop.openstack.org/meetings/glance/2016/glance.2016-05-26-14.03.log.html 17:10:55 kzaitsev_mb docaedo folks, I'm not in context here, sorry. Is there a plan in place for auth implementation? 17:10:58 nikhil designated several items about Glare 17:11:20 igormarnat_: no exact plan, only that it's a known issue 17:11:42 igormarnat_: needs to auth people against their openstack ID, and let folks update their assets 17:11:44 igormarnat_: the plan is to delegate auth to ubuntu one, the same way review.openstack.org does 17:11:45 I think they should clarify some things 17:11:54 * nikhil lurks 17:12:02 igormarnat_: and the people listed as cores for app-catalog can change status of a recently added/updated app 17:12:47 exactly 17:12:57 docaedo: ok, but I mean - it's some functionality which needs to be implemented, do we know who'll implement this part? 17:13:45 my understanding based on previous conversations is that mfedosin or someone else working on glare would take the lead on the auth middleware 17:13:56 ah, ok 17:14:24 docaedo: correct 17:15:45 cool =) I thought I would be the one to do the heavylifting =) Well anyways, I'll offer mfedosin my help on that =) 17:15:53 kzaitsev_mb: OK if I add an action for you like "execute plan to disable glare by default and start merging the pieces"? 17:16:07 docaedo: please do =) 17:16:24 #action kzaitsev_mb to execute plan to disable glare by default and start merging those bits into app-catalog repo 17:16:53 Thanks for the glare update, I think we have a good picture on where it stands - moving on? 17:17:06 let's wait for a bit for comment from Mike 17:17:27 mfedosin: so please confirm you're ready to work on this auth middleware 17:18:02 so, the idea is to implement another auth middleware and use instead of current keystone middleware 17:18:24 I think they can already be written 17:18:49 ok, this is more or less clear. Not clear to me is who's gonna be doing it if it's not done. If it's done - where is the repository with the code? :) 17:18:59 * mfedosin is googling 17:19:29 kzaitsev_mb: do I understand correctly, that you plan to implement some Glare integration before the official release of v1 API ? I'm just wondering about estimates, and when we can start using it? 17:21:25 kraynevs: yes, if the v1 gets merged before we deploy glare — well, we would just be able to switch to using it, otherwise we would probably have to do some porting work 17:22:12 kraynevs: but the a.o.o API based on glare would stay private until V1 is there 17:22:35 and v1 a.o.o api wouldn't change anyway 17:23:00 #link http://stackoverflow.com/questions/4648838/wsgi-middleware-for-oauth-authentication 17:23:20 I was just going to say that - v1 API for a.o.o will not be v1 API for glare, but we're not advertising app.openstack.org as the canonical glare example anyway 17:23:22 kzaitsev_mb: ok 17:24:59 so this way or another kzaitsev_mb and mfedosin will figure it out with auth middleware 17:25:17 igormarnat_: we'll do =) 17:25:36 great, let's proceed than:) 17:25:56 #topic App Dev Community Discussion (Igor) 17:26:22 #link https://etherpad.openstack.org/p/OpenStackAppsCommunity 17:26:39 and two email threads on the subject: 17:26:42 #link http://lists.openstack.org/pipermail/user-committee/2016-May/000854.html 17:26:44 #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/095917.html 17:26:53 docaedo: thank you, Chris! 17:27:00 There's a LOT in this message, but I'm glad Igor kicked off this conversation 17:27:21 igormarnat_: what piece of this do you want to start discussing? 17:27:28 so what do you think about the plan? Do you want to discuss it in general in some more details or just to switch to the very first item from the plan? 17:27:33 I'd discuss about repositories 17:27:50 This part 17:28:01 - Introduce label openstack-apps, put repositories with source code of OpenStack Apps under it, i.e.: 17:28:01 * http://git.openstack.org/cgit/openstack-apps/murano-apps 17:28:01 * http://git.openstack.org/cgit/openstack-apps/heat-templates 17:28:01 * http://git.openstack.org/cgit/openstack-apps/tosca-workflows 17:28:26 I would say before repositories we need to work out what the testing would look like - otherwise there's not a lot of reason for the repositories to exist, or at least no reason to use those over your own github repo 17:28:38 there are people coming and asking how and where to put source code of their apps, besides Murano team would also like to split the repos 17:28:53 I'm +1 for Murano then, especially if people are already asking for it 17:29:11 Well, the testing depends on project. For murano we started working on CI for apps 17:29:23 I haven't seen anyone ask for it from Heat side - in fact I even suggested this over a year ago and basically heat team said "no way, we already have examples!" 17:29:40 I'm +1 for the openstack-apps, but I'm not 100% sold on the single repository for all the murano-apps in the openstack 17:29:47 final goal is to have automated pipeline which allows to automatically publish apps to the catalog 17:30:04 but for now - just non-voting jobs based on third-party CI 17:30:12 So yeah, getting back to repositories 17:30:36 there are many apps in openstack/murano-apps which are now part of responsibility of core murano team 17:31:00 whos responsibility will they be in openstack-apps/murano-apps? 17:31:20 and we'd like to move existing murano-apps to somewhere else (ideally - under openstack-apps label) and to leave it up to murano team to deal with their examples, they'll figure it out 17:31:34 we are ready to introduce murano-apps team:) 17:31:39 exactly this — it doesn't solve the problem of ownership 17:31:53 murano-apps is gonna be the owner 17:32:11 who will be the members for murano-apps? 17:32:40 igormarnat_: my question is — how would it scale when you would have, say 100 apps in that repository? 17:32:44 for now several core members of murano team and several new folks from our team who works on CI/CD app for murano, gerrit app, jenkins, ... 17:33:19 kzaitsev_mb: the thing is that however it will scale, it will scale better than now when it's responsibility of murano team, right? 17:34:21 igormarnat_: why not allow a repository per-app, to allow every app developer have their own team, speed, etc? 17:34:34 We should just make it easy to register this kind of teams 17:34:59 I think it's good to be clear at this point what this represents - it's a new repository to host murano apps (i.e. the gating/CI/CD stuff is for later, and will be dealt with separately) 17:35:01 kzaitsev_mb: docaedo nothing prevent us just to copy all the murano team to murano-apps team for beginning and then membership will be polished/elaborated using usual openstack approach based on their activity 17:35:21 igormarnat_: I'm basically on board and in support of this plan 17:35:35 just want to be really specific as we step through this, and start getting to the more complicated things later 17:35:46 kzaitsev_mb: you make a good point about separate repos - 17:36:04 it's a new repository to host murano apps, right. Owner can be newly created murano-apps team, who'll consist from the very beginning from exact copy of murano team + several new members 17:36:09 kzaitsev_mb: if I create an app, I'd prefer it to live in my own github repo where users can report issues, see updates, etc. 17:36:41 agree with the github example 17:36:46 kzaitsev_mb: docaedo ah, yes, this is what I meant, sorry, folks 17:37:32 igormarnat_: no need to apologize :) I'm just also anticipating the parts we'll have to be really clear about with the repo request, etc., expecting some similar questions 17:37:34 kzaitsev_mb: docaedo well, probably I'm confused now, yep. From one side it's good to have murano-apps team who owns several repositories they work on 17:38:02 docaedo: kzaitsev_mb on the other hand repo per app is good thing to have, some apps are very complicated 17:38:03 I understand that it is currently super-hard to add a new repo to openstack-space, and a single repo for all the murano-apps is a workaround 17:38:16 BTW maybe Murano team should think about this again? 17:38:19 #link https://blueprints.launchpad.net/murano/+spec/download-package-from-git 17:38:55 but let's at least take a look at the root problem and see if we can fix that (i.e. allow adding new repositories in a click or two)? 17:39:31 * olaph likes the git idea 17:39:38 docaedo: kzaitsev_mb I think I now understand it. We might want to copy all the existing repositories under label openstack-apps/murano-apps which is just the label, assign newly created murano-apps team as an owner for each of them (as they are owned by murano team anyways) 17:39:40 kzaitsev_mb: I don't think that adding dozens or hundreds of new repos is a thing the infra team wants to own 17:39:52 docaedo: I suppose, that have one core team - murano-apps make sense on the start, because we need to give users normal review from guys with expertise in this area 17:40:07 and this group may have right for +2 on all repos 17:40:12 but then.. 17:40:12 And then to add new repositories under openstack-apps/murano-apps on per project basis and discuss each time which team owns new repo 17:40:15 kraynevs: good point 17:40:32 you are right it should be separate teams with same rules like in main Openstack community 17:40:43 when we nominate new guys to core-team 17:40:47 docaedo: I think the git thing could be done on the client-side more or less easily =) 17:40:50 I'm not so much in support of endless repositories, most of which will eventually be abandoned... 17:40:54 but on the start we need support new comers 17:41:10 but that is an important question we'd need to get support from the infra team and/or TC 17:41:36 ("that" being "as many repos as anyone wants, so every app gets its own repo") 17:42:08 docaedo: well, github/bitbucket are more or less ok with hundreds of abandoned repositories, but those are commercial projects after all 17:42:16 docaedo: excuse me, but what do you meant by "supporting endless repositories"? 17:42:44 nothing prevent people from using their repositories if they want, but if they'll create them under openstack-apps/murano-apps, they'll be part of some community. They'll get support from it but in return they should contribute back by reviewing and writing code. Again, if someone want to create his repo outside - it's ok, but he'll not be reviewed than 17:42:44 I suppose, that in community nobody except core-team do not support repo..... 17:43:06 docaedo: I just try to understand what kind of supporting do you mean 17:43:29 I think I'm ok with agreeing to have single repo as step1, but we should probably get infra folks involved, they might have some insight 17:43:36 kraynevs: I mean that every new repository comes with some administrative cost from the openstack-infra team 17:44:00 kraynevs: and this proposal is "1 repo for now, many many repos later - as many repos as we have devs or apps" 17:44:01 kzaitsev_mb: docaedo why not to suggest single repo/single team for beginning 17:44:18 and then we'll figure it out with infra team as well 17:44:25 docaedo: kraynevs: exactly, after all they "own" the metadata about the repos 17:44:34 igormarnat_: I'm fine with one repo, but if the longer term intention is more repos under that, we need to be clear at the beginning that that's the long term expectation 17:45:46 so, guys, are you ok with requesting tc/infra team to move existing openstack/murano-apps to openstack-apps/murano-apps, create new team murano-apps and assign it as an owner of this repo? 17:46:03 I'm +1 on that 17:46:24 long term approach is to be discussed further with Infra team, tc and openstack-dev community (if anyone is interested:) ) 17:46:33 igormarnat_: I'm not ok with moving all the apps there 17:46:47 kzaitsev_mb: do your corrections than 17:47:00 fwiw I think we don't want any new "namespaces" on the gerrit server 17:47:07 igormarnat_: I'd rather have murano-apps renamed into murano-examples and transfer apps on per-app basis 17:47:18 if it were easier to remove openstack-dev it would be gone already 17:47:19 i.e. there is a number of apps, that have little value really 17:47:36 docaedo: oh. you talk about supporting it as it do infra team... yeah. it's pain. 17:47:56 kzaitsev_mb: I don't see much difference in move all the murano-apps first and then to recreate murano-examples in Murano by Murano team, but ... I don't have strong opinion here 17:48:49 clarkb: but it would be good to separate code which constitutes core openstack services from the code which is not openstack code but is openstack applications, isn't it? 17:49:11 kraynevs: correct - that's what I'm sensitive to, our infra team is small and overworked :) 17:49:12 no, that namespacing has no real purpose 17:49:15 clarkb: labels openstack and openstack-apps would allow to do it, but other ideas are welcome 17:49:29 it only causes confusion and special casing in tooling and so on 17:50:26 well, than we just can move murano-apps outside of murano, w/o introducing openstack-apps label, as an option. Key thing for me is to move it outside of responsibility of core murano team 17:51:32 it sounds like kzaitsev_mb is not entirely in support of moving all the apps out though? 17:51:42 igormarnat_: well, I'm ok with moving apps (and thus shifting some of the responsibility from myself and the team =)), just want to be a bit carefull here. you might be right and just moving all the apps is ok 17:51:47 Here is the suggestion then: move murano-apps outside of murano, make it top-level repository, assign newly created murano-apps team an owner, ask murano team to figure out exact way they want to transfer source code from murano/murano-apps to murano-apps outside of it. Would they work? 17:52:18 also sounds like we're talking about two things at the same time - 1) getting apps out of the main murano repo and 2) making a space where new murano app developers can work on stuff .. 17:52:20 docaedo: I just have to give it a bit of thought =) We've been wanting to clean-up some of the example apps, that have little value 17:52:21 kzaitsev_mb: docaedo clarkb ? 17:53:11 igormarnat_: I would support that if it's got buy in from murano - but in this case, really has nothing to do with me since I'm not a murano core or anything 17:54:05 docaedo: we can agree on it between ourselves as initial suggestion and then get agreement with infra team and murano team by email 17:54:47 igormarnat_: sure - from the "clean place to work on murano apps" perspective, it makes sense to me 17:55:39 Ok, let's agree on this suggestion, I can shoot an email with it to infra team and murano afterwards 17:56:12 #action igormarnat_ to send an email to infra and murano teams re: moving apps in murano repo to new top level repo 17:56:16 now it's official! 17:56:27 docaedo: thank you, sir! :) 17:57:30 docaedo: we are running out of time, let's make the first step with murano apps 17:57:32 and we're almost out of time - but thanks igormarnat_ for bringing this up, and looking forward to carrying this conversation forward in the weeks to come 17:57:37 hah yes 17:57:46 docaedo: and meanwhile hopefully heat team and other teams will say something in email 17:58:08 thanks all! 17:58:12 that would be nice - we can talk some next week (or else on #openstack-app-catalog) about what we would need for testing 17:58:31 because it basically needs a stable cloud without access to admin control plane, to test any of these things 17:58:48 or else SLOW path, stand up all in one devstack node for the test 17:59:07 I am out next week, but will work through agenda and stuff on the mailing list 17:59:09 thanks everyone! 17:59:20 #endmeeting