16:00:41 <markvoelker> #startmeeting defcore
16:00:41 <openstack> Minutes (text): http://eavesdrop.openstack.org/meetings/monasca/2016/monasca.2016-03-30-15.00.txt
16:00:42 <openstack> Log:            http://eavesdrop.openstack.org/meetings/monasca/2016/monasca.2016-03-30-15.00.log.html
16:00:44 <openstack> Meeting started Wed Mar 30 16:00:41 2016 UTC and is due to finish in 60 minutes.  The chair is markvoelker. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:47 <openstack> The meeting name has been set to 'defcore'
16:00:54 <markvoelker> #chair hogepodge
16:00:55 <openstack> Warning: Nick not in channel: hogepodge
16:00:56 <openstack> Current chairs: hogepodge markvoelker
16:01:08 <markvoelker> o/
16:01:11 <catherineD> o/
16:01:42 <kbaikov> o/
16:01:52 <docaedo> o/
16:01:52 <mfedosin> o/
16:01:53 <markvoelker> #link https://etherpad.openstack.org/p/DefCoreRing.17 Agenda
16:01:53 <luzC> o/
16:02:29 <ativelkov> o/
16:02:38 <markvoelker> #info eglute is away today
16:03:17 <markvoelker> #topic Need input on Glare API
16:03:33 <markvoelker> #link https://review.openstack.org/#/c/283136/
16:03:44 <markvoelker> nikhil, are you here?
16:04:38 <mfedosin> I request nikhil_k here :)
16:04:40 <Rockyg> o/
16:05:21 <mfedosin> anyway, if he's not here I can describe the spec
16:05:29 <markvoelker> mfedosin: go for it
16:06:07 <mfedosin> We proposed a spec for stable Glare API
16:06:46 <mfedosin> Glare is a new service in Glance repo, that includes Images API
16:07:24 <mfedosin> but it extends it with support of various Openstack services
16:07:30 <mfedosin> like Heat or Murano
16:08:01 <nikhil_k> o/
16:08:05 <mfedosin> api is unified for all artifact types
16:08:09 <nikhil_k> sorry a bit late, last meeting ran over
16:08:14 <mfedosin> oh, hi there :)
16:08:39 <mfedosin> I described the situation with Glare api
16:08:49 <nikhil_k> mfedosin: please go ahead, I will add more points after you're done
16:09:06 <mfedosin> Glance v2 image api is the subset of Glare v1
16:09:15 <mfedosin> only prefixes are different
16:09:26 <mfedosin> in glance it is '/v2/images/'
16:09:38 <mfedosin> in glare '/v1/artifacts/images/'
16:11:12 <mfedosin> also it's proposed to list all installed artifacts types with GET '/v1/artifacts'
16:11:54 <mfedosin> and also I'm interested should we support listing of 'all' artifacts, regardless of their types?
16:12:33 <ativelkov> +1 for listing all, since it adds interoperability for the clouds
16:13:08 <nikhil_k> I think we've a few questions for the committee:
16:13:19 <nikhil_k> firstly, thanks mfedosin for linking the spec
16:13:43 <markvoelker> +1, thanks for the briefing mfedosin
16:13:56 <nikhil_k> Q1) Would a option to support image records using the /v1/artifacts/images/ be okay? glare API will be a separate running process (service)
16:14:37 <nikhil_k> Q2) Listing of all the records in a particular DB table would mean that some clouds that support subset of artifacts types will return only those supported ones.
16:15:15 <nikhil_k> Q2 contd.) for ex: cloud 1 exposes heat and murano templates, cloud 2 exposes heat, murano and tacker
16:15:38 <nikhil_k> the return values for cloud 1 will not have mention of tacker records
16:16:13 <ativelkov> nikhil_k: cloud 1 will not have them in DB at all
16:16:21 <nikhil_k> right
16:16:23 <nikhil_k> Q3) what should be the bare minimum and maximum API exposed for this to be approved as a part of DefCore?
16:16:45 <markvoelker> nikhil_k: Ok, let's take those one at a time...
16:16:49 <markvoelker> nikhil_k: So for Q1: is the concern here that there's potential overlap with the glance API since one is a superset of the other?
16:17:26 <nikhil_k> markvoelker: the plan is to superset glance to help operators move their glance installations to glare at potentially some future cycle
16:17:45 <nikhil_k> with glance team maintaining both these services to help that cause
16:18:06 <markvoelker> nikhil_k: Ok.  So, in general there's nothing in DefCore's criteria that says "there shalt be one way to do a thing and only one way to do a thing"
16:18:12 <markvoelker> However
16:18:35 <markvoelker> When there's more than one way to do a thing, it often ends up hurting adoption of a particular API
16:18:44 <markvoelker> E.g. some clouds might expose Glare, some might not
16:19:16 <markvoelker> Adoption is a pretty key thing for DefCore as it ends up influencing multiple criteria (e.g. widely deployed, used by clients, used by tools, etc)