17:00:54 #startmeeting app-catalog 17:00:56 Meeting started Thu Aug 25 17:00:54 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:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:59 The meeting name has been set to 'app_catalog' 17:01:09 #link https://wiki.openstack.org/wiki/Meetings/app-catalog#Proposed_Agenda_for_August_25th.2C_2016_.281700_UTC.29 17:01:41 That's the agenda, but really I think today is all about glare (and that's what things will be all about likely until we transition :) ) 17:02:06 hi all 17:02:15 hello redixin! 17:02:56 as you may know, glare has disconnected from glance. we have new repository git://git.openstack.org/openstack/glare.git 17:03:22 I've switched http://r-ci.tk:8100/ to new glare 17:03:38 oh great, thanks for that update 17:03:39 also I've finished UI 17:04:01 and now working on "old api emulation" (for horizon plugin) 17:04:19 http://r-ci.tk:8100/api/v1/assets 17:04:26 redixin: excellent - it's looking really good 17:04:27 it almost done 17:05:00 if you want to test admin UI, you need to be member of app-catalog-core team on launchpad 17:05:20 this team is open, so you may join or leave this team at any time 17:05:52 o/ 17:05:57 hiyo 17:06:00 o/ 17:06:09 on other meeting right now, would get back soon I guess 17:06:13 redixin: cool - is that a different launchpad group than current app catalog core? 17:06:43 current app catalog core? O_O 17:07:02 I've created team 'app-catalog-core' like one week ago 17:07:13 sorry, I confused it with app catalog drivers group 17:07:14 I dont know other teams 17:07:20 oh, ok 17:07:57 #link https://launchpad.net/~app-catalog-core 17:08:08 also few people from mirantis are helping us with packages/puppets 17:08:31 yep, I've been talking to zynzel this last week and saw some of the work he's done 17:08:37 but I dont know much about their progress 17:08:50 one quick question before we move on to that 17:09:08 not only me :) im assigned for app-catalog automation, also we have Pether Zhurba - he will deliver glare automation 17:09:19 redixin: is there a URL for an admin interface for people to approve/disable assets? 17:09:36 great to have so many resources working on this :) 17:09:54 docaedo: admin UI is part of user UI. you will see some additional buttons if you are member of app-catalog-core team 17:10:21 redixin: awesome, yep I see now after logging out and back in 17:11:33 as an admin, I should be able to edit any artifact, but I don't see a button for that? 17:11:55 not you are not. only owner can edit own artifact 17:12:21 I also think so, why would you edit assets uploaded by others? 17:12:35 because you admin? =) 17:12:59 Need to have an approach similar to code review - you can comment, but it's up to patch owner to edit 17:13:28 sure, but that's not the same as what we have right now 17:13:34 cores can modify any asset and merge it 17:14:08 ie to fix something that has been abandoned by an owner (like someone adds something useful, but does not respond to comments to fix typos or a broken link) 17:14:35 It would be nice if admin can edit any asset. This sounds reasonable. I can fix it. 17:14:37 from the earlier design conversations, there was an agreement that core members of app catalog would have full admin rights to edit/modify anything in the catalog 17:14:45 Probably this needs to be discussed as a new upload workflow 17:15:38 possibly - at a minimum core members need to be able to disable any asset 17:15:57 docaedo: May be it's appropriate for the first stage to allow to switch to new backend asap, but for the future IMO we need to separate development team of app catalog and their rights and team managing the content of app catalog and their rights 17:16:13 also we should think about how to prevent this from being overrun by a spambot, like what has happened to the wiki 17:17:11 captcha? 17:17:12 igormarnat_: well I am not sure the app catalog project is big enough to be split into two project groups is it? 17:17:35 redixin: yep, I was just going to type captcha might be all we need for now, and we can address if it becomes a problem 17:17:45 docaedo: redixin actually having thought about it again I don't understand at all - why would admin edit any asset? What for? 17:18:17 I've fixed assets that people have added, when a link changes or breaks 17:18:40 docaedo: what if you make a mistake and break something? 17:18:41 if nobody can update anything except the original asset owner, everything will eventually get staile 17:18:43 stale 17:19:01 igormarnat_: if I break something from a mistake, the owner or another admin can fix it 17:19:15 at least this should be very visible and transparent 17:19:16 You actually cannot fix any blobs (including links to external resources) because of glare. You need to create new asset (new version) with new blob 17:19:27 blobs are immutable 17:19:50 igormarnat_: I completely agree it shoudl be transparent and clear who is doing what, but I'm also saying if only the owner can ever manage his/her own assets, many assets will be stale 17:19:51 maybe instead of modyfing smth silently, we should own 'abbandoned' apps 17:19:59 Yep, new version or something like that.Assets are versioned, operations are to be logged, right? 17:20:01 change owner from 'user A' to 'openstack infra' or smth. 17:20:14 much of the content has been added by people who no longer pay attention to it (like debian stuff, coreos stuff), sometimes it gets updated 17:21:07 Abandoned assets, or new versions of old asset are just completely new assets. Same name but other version. So there is no need to edit. Just create a copy 17:21:08 Again, this is probably ok but needs to be very transparent, versioned, logged 17:21:21 +1 17:21:49 I hoped we would be able to see previous versions of an asset, since everythign is versioned anyway - couldn't that be in a dropdown or something, to see previous versions of an asset? 17:22:34 older versions are available via glare, but not implemented in UI 17:22:40 so i'll add it to my TODO list 17:23:00 Good 17:23:40 sounds good :) to be clear I am not trying to asset editorial control over the catalog, but I do want to make sure the core of us (that's all of us who are working on this) can take care of it and keep things in shape 17:24:17 redixin: one thing, for "recently added apps", do you have a way to easily pull the 15 most recently modified assets, and then randomly choosing 5? 17:24:22 we need a "copy" button to add new versions or continue abandoned assets 17:24:33 that sounds good 17:25:01 docaedo: its hard to do with glare. probably searchlight can help 17:25:26 redixin: maybe you can fetch 5 latest things from each of the asset types? 17:25:27 redixin: oh right, I remember that conversation :/ 17:25:52 kzaitsev_mb: that sounds like an easy approach, but to be honest, we can skip that and remove it for the time being 17:26:00 and then mix and shape =) it's not like we need a cryptographically strong shuffle algorithm for those ) 17:26:04 I don't think it's essential, and I would say that's a nice to have, but not a show stopper 17:26:27 true, definitelly not a show stopper 17:26:32 kzaitsev_mb: yep -- if it's not too much work, great, but at least for me, I will not cry if that gets put on hold until searchlight is part of the picture 17:29:43 * redixin is removing "admin can edit any asset" and adding "copy button for UI" in TODO 17:29:49 so zynzel - want to talk about packages and stuff? 17:30:17 yep, sure 17:30:26 so guys, im working on automation for app-catalog 17:30:27 we have a package contrib/glare in app-catalog 17:30:33 packaging and automation of deployment is the last thing preventing us from switching to new backend, right? 17:30:42 i prepared short etherpad, with things which should (imho) be fixed 17:30:49 before we can create good quality automation 17:30:52 #link https://etherpad.openstack.org/p/app-catalog_automation 17:31:11 here is change [wip] for that 17:31:13 #link https://review.openstack.org/#/c/359029/ 17:31:58 so, long story short, we need packages for app-catalog, and we need cli wrapper over manage.py and all other tasks which should be executed after app-catalog deployment 17:33:56 I mostly agree, though the package does not have to be perfect for the transition - i.e. if there is a manual step infra has to perform on the box, that's OK 17:34:35 just talking about the things that happen only one time - like importing assets.yaml into glare 17:35:00 docaedo: and what happend when you break glare? 17:35:13 it can be imported manually 17:35:13 we will need to reinstall glare from scratch+import assets one more time 17:35:20 so this can be easly added to this cli wrapper :) 17:35:43 assets.yaml will be outdated just after switch to glare 17:35:44 redixin: everything can be done manually... 17:35:49 but we want to have automation 17:36:18 also remember the puppet manifest is run every 15 minutes, so have to make sure it's smart enough to only do the import when we want 17:36:38 docaedo: yep sure, this is why we need packages and other 'good puppet stuff' 17:36:46 that's the part that I think will be difficult, distinguishing between initial deployment, fix deployment, and regular run 17:36:47 manifests should be indepotent 17:37:11 docaedo: we have some experience with creating manifests which can be run multiple times without any issue 17:37:24 guys, we can run import only once. after this any changes will not be saved in assets.yaml 17:37:25 imho this should be doable for app-catalog 17:37:41 so assets.yaml will be outdated immediately 17:37:59 redixin: so maybe glare should allow to generate assets.yaml 17:38:03 yep, once we implement glare, assets.yaml (after import) becomes meaningless 17:38:03 from current data? 17:38:07 for some kind of backup? 17:38:42 (im not glare guy, i dont know how difficult this can be) 17:39:05 we can just backup database (postgres?) 17:39:28 database will be hosted, it won't live on this machine (will be delivered via trove) 17:39:32 currently glare have not any export/import or backup/restore things 17:40:19 also assets.yaml may be not quite compatible with glare 17:40:34 understood, but do you think that glare should allow to export/import content via api? 17:40:53 It's an overkill to generate assets.yaml for backup purposes or any other purposes (provided that assets.yaml is current app catalog backend which I'm not sure in) 17:40:54 We will discuss this with glare team tomorrow 17:41:00 also in looking at 359029, will need config file templates and a way to handle that - for instance access to mysql and swift will require secrets, those will be stored in heira by infra team (similar to how SSL cert is handled now) 17:41:01 it easier for anybody to use API calls, than dumping/importing database data :) 17:41:07 with encoding and stuff :) 17:41:45 docaedo: we can pass all credentials to app_site class as parameters 17:41:49 btw binary data is not stored in database 17:41:53 and read them from hiera from examples/instal.pp 17:42:08 zynzel: cool just making sure you had that in mind 17:44:47 so anybody have anything against packages+appcatalog-manage? 17:45:04 btw this should be deb packages? or just pypi? 17:45:18 redixin: any package, i can use pip or deb 17:45:34 I don't have anything against package plus manage 17:45:48 well, I have a faint objection against pypi =) 17:45:57 but am 100% for deb 17:46:02 and I like pypi more than debs :P 17:46:08 * redixin added "app-catalog manage" in TODO 17:46:13 thing is pypi is more transparent 17:46:34 deb packaging is not at all easy to see the background, where it came from, etc. 17:46:58 docaedo: but why don't we have up to date nova on pypi? =) 17:46:59 also pypi is easier to pin to a version than a deb pulled from an external repo 17:47:19 haha don't try to drag nova into this conversation! 17:47:21 (spoiler: I don't know the answer) 17:47:36 yeah, like I said my objection is rather faint 17:47:45 actually to be fair 17:48:00 the best thing for us to do would be to use the packaging tooling offered by infra 17:48:02 is it possible to publish two packages from one repository via openstack/infra? 17:48:16 I just gotta ping infra — why none of the services like glance/nova has pypi jobs/packages 17:48:21 but I don't fully understand how to use it so I can't advocate too strongly 17:48:29 redixin: dunno, you are thinnking about contrib/glare? 17:48:37 yep 17:48:58 redixin: if not, we can move contrib/glare to openstack-catalog/plugins/glare 17:49:01 there's got to be some explanation, rationale. just gotta ping the right folks to dig that up 17:49:03 and deliver this inside single package 17:49:14 on glare node simply, we will not configure app-catalog 17:49:22 redixin: you can, but not with current infra thing I suppose 17:49:23 only install this plugin for glare 17:49:25 also tags 17:50:15 sounds good (openstack_catalog.plugins.glare) 17:50:48 well, you need a setup.cfg file for a package (if we're talking about pypi, deb/rpm are a completely different story) 17:51:07 and if you follow post-versioning strategy of pbr — they would share version of the latest tag 17:51:31 anyway — wasn't there a plan to get a separate repo for glare-plugins? 17:53:04 we've hit that thing in murano with murano-glare-plugin. it's usually very hard to explain to packaging folks why they have tp build 2 packages from 1 repo. much cheaper to convince infra to make a new repo =) 17:53:17 I like openstack-catalog/plugins/glare more 17:54:10 pip install openstack_catalog but use only openstack_catalog.plugins.glare.(middlewares|artifacts|etc) 17:54:56 same as in the rest of openstack python-nova|neutron|glance 17:56:23 oh we are almost out of time (just looked at the clock) 17:57:48 * redixin added "merge contrib/glare into oenstack_catalog" in TODO 17:58:09 that makes sense to me .. 17:59:12 ok any other urgent topics before we end? 17:59:22 btw how about assign glare-work blueprint to me? %) 17:59:40 redixin: sure, I can do that 17:59:48 thanks 17:59:59 np 18:00:09 and we're out of time - thanks folks! 18:00:13 #endmeeting