14:00:10 <witek> #startmeeting monasca
14:00:11 <openstack> Meeting started Wed Sep 27 14:00:10 2017 UTC and is due to finish in 60 minutes.  The chair is witek. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:16 <openstack> The meeting name has been set to 'monasca'
14:00:34 <witek> hello everyone
14:00:38 <jgr> Hello
14:00:57 <nseyvet> hello
14:01:14 <witek> agenda is as usual here
14:01:17 <witek> https://etherpad.openstack.org/p/monasca-team-meeting-agenda
14:01:50 <witek> #topic Queens Priorities
14:02:19 <witek> thanks for submitting your votes to the google sheet
14:02:29 <witek> https://docs.google.com/spreadsheets/d/11X4kFHeyXl6ZcP0nqI54Hc_LL_DsYCUpsAgJY1hBGOs/edit?usp=sharing
14:02:59 <witek> hello rhochmuth
14:03:05 <rhochmuth> hello
14:03:15 <rhochmuth> ran a little late this morning
14:03:27 <witek> we just started
14:04:18 <witek> I have tried to sort the priorities
14:04:38 <witek> the first version is here
14:04:41 <witek> https://review.openstack.org/#/c/507534/
14:04:42 <patchbot> patch 507534 - monasca-specs - Add Queens priorities
14:04:53 <joadavis1> 2 quick questions about Queens priorities (at least the top ones). Should each priority also have a spec?  Should be spec be written in Launchpad, Storyboard, or the new specs repo?
14:05:41 <witek> not every prio is suitable for the spec
14:06:01 <witek> also, some efforts have already been started and documented in other way
14:06:30 <witek> but as a minimum we should have a short description on priorities page
14:06:40 <akiraYo> hi, all
14:06:40 <joadavis1> Fair enough.  Things like python3 I assume already have some sort of doc.
14:06:46 <witek> and a story in StoryBoard would be nice
14:07:10 <witek> I guess we won't use Launchpad any more
14:08:00 <witek> new changes affecting the API or otherwise strongly impacting the project should have a spec
14:08:11 <witek> hi akiraYo
14:08:38 <joadavis1> My follow-up question was going to be if we keep using Storyboard or focus more on the specs repo (and maybe migrate some of the stories we think are still relevant from Launchpad or Storyboard over to the repo)?
14:08:56 <witek> joadavis1: yes, python 3 is documented as community goal
14:10:02 <witek> we should use StoryBoard for all changes affecting the code
14:10:09 <witek> features and bugs
14:10:32 <rhochmuth> i know the api was looking a little involved to add python3 support
14:10:33 <witek> more complicated stuff should additionally has spec
14:10:38 <rhochmuth> has anyone taken a look at that recently
14:11:03 <rhochmuth> i started on it, and thought, this will be quick and easy, and then realized, it was more involved
14:11:26 <rhochmuth> i believe there was another review that was inflight for the conversion too
14:11:30 <witek> rhochmuth: kornica has come up to the same conclusion
14:12:53 <joadavis1> Thanks. I'm starting to think about work to submit the Monasca Publisher to ceilometer, so I'll write something
14:13:25 <witek> joadavis1: nice, could I assign you as the owner?
14:13:46 <joadavis1> you can put myself and Ashwin Agate as owners (I'm happy to share)
14:13:56 <witek> great
14:14:32 <witek> it would be good to have someone for Python 3 stuff
14:14:41 <witek> will check myself with the team
14:15:50 <witek> do we have any other items to add to prios?
14:16:34 <jgr> What about the documented policy thing we spoke about at the midcycle?
14:16:52 <jgr> (I don't see it anywhere in the list of priorities)
14:17:06 <witek> Service Domain for Self Service Agent Users
14:17:59 <witek> I guess it's what you mean, right?
14:18:03 <witek> should I rename?
14:18:09 <jgr> No, that's a different one
14:18:29 <jgr> It's somewhat related since I'll need to modify policy enforcement as well
14:19:03 <witek> oh, you mean the community goal
14:19:08 <jgr> But we talked about OpenStack projects being mandated to have in-code policy rather than policy.json
14:19:11 <jgr> Yes
14:19:38 <witek> I wasn't sure if we're affected
14:20:06 <jgr> Well, we're not even using oslo.policy right now...
14:21:13 <witek> OK, will add it to 'essentials'
14:21:22 <sc> jgr: and do you see a good use case to add oslo.policy?
14:21:23 <jgr> Ok
14:21:47 <jgr> sc: well, we're kind of supposed to under the Openstack umbrella.
14:22:14 <sc> so forced to use
14:23:07 <jgr> I for one would be happy to put it off until later myself, because it will either block the agent user thing or force a refactoring (not much refactoring, though) of the agent user code once the oslo.policy integration is merged.
14:24:07 <jgr> Yes, forced to use.
14:24:28 <jgr> I think there's a bit of an agenda behind the in-code policy thing.
14:24:51 <witek> jgr: can you elaborate?
14:25:13 <jgr> Keystone were making noises about surveying policy rules last year around December and they need this in-code policy thing in all projects to be able to do a proper survey.
14:27:21 <witek> rhochmuth: can I put you and me as Grafana thing owners?
14:27:50 <rhochmuth> sure
14:29:25 <witek> it would be nice when the owners could add a short description of the prio to the document
14:30:20 <witek> anything else to this topic?
14:30:45 <witek> #topic Service Domain for Self Service Agent Users
14:31:05 <witek> jgr has submitted the spec
14:31:16 <witek> https://review.openstack.org/507110
14:31:16 <patchbot> patch 507110 - monasca-specs - Add Service Domain Spec
14:32:20 <witek> one key question is if we should use Keystone for storing credentials, or should API handle it
14:32:59 <jgr> I for one prefer the Keystone approach.
14:33:23 <jgr> API keys are pretty messy and essentially amount to creating our own authentication/authorization infrastructure.
14:34:00 <witek> your comment in review is misleading then :)
14:34:37 <jgr> In the Alternatives section, you mean?
14:34:40 <nseyvet> In the monasca agent, one can specify the Keystone url to discover the monasca API endpoint. Would this change affect that as well?
14:34:59 <jgr> No, not at all.
14:35:41 <jgr> This change is transparent as far as monasca-agent is concerned.
14:35:52 <nseyvet> ok. need to read this more.
14:36:06 <jgr> The only change on the monasca-agent side is that one needs to specify a user domain in the configuration.
14:36:56 <witek> the old mechanism with authorized roles in API would still be available?
14:37:12 <jgr> Yes.
14:37:20 <jgr> I plan on making this configurable.
14:38:20 <witek> I also prefer storing credentials in Keystone
14:39:07 <jgr> Ok, good. Then I'll change that bit in the Alternatives section to make it appear less viable :-)
14:40:08 <witek> thanks for the document
14:40:11 <witek> nice job
14:40:18 <jgr> Thanks :-)
14:40:23 <witek> #topic open stage
14:41:03 <witek> do we have anything else to discuss?
14:41:06 <nseyvet> one more question: the "domain" is equivalent to a tenant?
14:41:13 <jgr> Kind of.
14:41:17 <nseyvet> ie there is a one-to-one relation?
14:41:20 <jgr> One can abuse a domain as a tenant.
14:41:49 <nseyvet> so with the current spec one tenant could have multiple domains and thus "user-agent"s
14:42:01 <jgr> No.
14:42:05 <jgr> There's only one domain.
14:42:19 <jgr> A domain is a container for users and tenants.
14:42:48 <jgr> Additionally, it can be abused as a tenant (one can create OpenStack resources in a domain, unfortunately).
14:43:02 <jgr> But that's not really its purpose.
14:43:16 <witek> I found this description useful:
14:43:19 <witek> https://www.mirantis.com/blog/mirantis-training-blog-openstack-keystone-domains/
14:43:34 <nseyvet> ok. But then is it OK that all users/projects share the same "user-agent" credentials?
14:43:40 <jgr> As far as the spec is concerned that domain is a secluded corner in Keystone where Monasca can create its own users that are entirely separate from Keystone users in the Default domain.
14:43:45 <akiraYo> can we share a service domain with other services like heat?
14:43:49 <jgr> No, absolutely not!
14:44:00 <nseyvet> or would some expect a separation b/w projects?
14:44:03 <jgr> Every user can create one or more agent user credentials.
14:44:24 <jgr> There's nothing shared anymore, which is the whole point of the spec.
14:44:44 <nseyvet> OK, and it is the user responsibility to insert those credentials in the agent?
14:44:48 <akiraYo> ok.
14:44:52 <jgr> Also, sharing a domain with Heat or Magnum is technically possibly but it would be a stupid admin who actually configured their cloud that way...
14:44:58 <jgr> s/possibly/possible/
14:45:15 <jgr> Yes, that's the user's responsibility
14:45:49 <nseyvet> thanks
14:46:03 <jgr> We could at some stage add a little plugin to Heat that generates an agent.yaml and a cloud-config snippet to deploy it to Heat, but first of all we need the capability to create agent users.
14:46:53 <jgr> s/deploy it/deploy it on an instance/
14:49:07 <witek> I guess we can further discuss in review
14:49:25 <witek> would be great to have your opinions
14:50:06 <witek> if there's nothing else, I'll be closing the meeting
14:50:14 <nseyvet> thank you for the links.  Will go through them.
14:50:37 <witek> thanks nseyvet
14:51:15 <witek> bye everyone, see you next week
14:51:21 <akiraYo> see you.
14:51:21 <jgr> See you!
14:51:25 <joadavis1> thanks again
14:51:30 <sc> bye now
14:52:00 <witek> #endmeeting