15:00:03 <EmilienM> #startmeeting puppet-openstack
15:00:03 <openstack> Meeting started Tue Jun  7 15:00:03 2016 UTC and is due to finish in 60 minutes.  The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:07 <openstack> The meeting name has been set to 'puppet_openstack'
15:00:10 <EmilienM> #link agenda https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160607
15:00:14 <EmilienM> o/
15:00:17 <iurygregory> o/
15:00:26 <mwhahaha> hi
15:00:34 <iberezovskiy> hi
15:00:39 <mfisch> hola mi amigos
15:00:40 <skolekonov> hi
15:01:14 <zhongshengping> hi
15:01:21 <mkarpin1> hi
15:01:25 <EmilienM> #topic Review past actions items
15:01:31 <EmilienM> xarses and degorenko to make puppet-ceph working on Ubuntu Xenial
15:01:42 <EmilienM> we have a topic about xenial, we'll take it there
15:01:49 <EmilienM> but I haven't seen much progress
15:01:54 <EmilienM> EmilienM to follow-up release tagging on ML -> done
15:02:13 <EmilienM> EmilienM to produce newton b1 -> WIP (we have a topic later)
15:02:24 <EmilienM> EmilienM & degorenko to work on nova v3 backport to mitaka -> not done
15:02:31 <bkero> o/
15:02:33 <EmilienM> degorenko: should we postpone this one? ^
15:02:43 <degorenko> hey
15:02:47 <degorenko> sorry i'm late
15:02:55 <degorenko> yes we should i'm on today
15:02:57 <degorenko> but not ready yetr
15:02:59 <degorenko> yet
15:03:01 <EmilienM> ok
15:03:22 <EmilienM> #topic name/auth_name discussion
15:03:35 <EmilienM> mwhahaha, degorenko, iberezovskiy: o/
15:03:46 <mwhahaha> so there's lively debate on the patches
15:03:55 <mwhahaha> it seems that our *::keystone::auth classes are inconsistent
15:04:16 <iurygregory> woa
15:04:20 <mwhahaha> 1) we are using the auth_name as the title for the resource which can have odd UX
15:04:29 <mwhahaha> 2) some classes we've hardcoded the title (ie for v2 & v3)
15:04:45 <mwhahaha> so we need to come up with a suitable pattern and understanding for what these classes should be and should do
15:05:05 <EmilienM> 2) is I think only for cinder AFIK, right?
15:05:13 <mwhahaha> no nova too i think
15:05:18 <mwhahaha> it's in a few of the more used modules
15:05:20 <iberezovskiy> nova as well
15:05:23 <EmilienM> I think they are deprecated in nova
15:05:47 <mwhahaha> so i guess the question is should we hardcode the resource titles in these classes
15:05:53 <mwhahaha> and allow the auth_name to be configurable
15:05:57 <EmilienM> yeah, why not?
15:06:11 <mwhahaha> and also is there a way to specify the display name for the resource
15:06:53 <degorenko> for nova we have another title because of 3 endpoints in mitaka
15:07:06 <degorenko> and there is was issue for ldap - when we need 1 user for all endpoints
15:07:20 <degorenko> that's why we have different titles and passed directly auth_name
15:07:30 <mwhahaha> since the *::keystone::auth is a class, i'm leaning towards the hardcoding of the titles and passing auth_name
15:07:41 <degorenko> it make sence right
15:07:50 <degorenko> but i'm wondering about title
15:07:53 <mwhahaha> my concern is that the proposed reviews use the service name for the title (or auth_name if service is not available) which may lead to duplications
15:07:57 <degorenko> what should we put here?
15:08:09 <degorenko> mwhahaha: right, i have same concern too
15:08:34 <mwhahaha> perhaps '<servicename>-user' for the title?
15:08:46 <EmilienM> it sounds good
15:08:55 <iurygregory> +1
15:08:58 <mfisch> why -user?
15:09:00 <iberezovskiy> servicename:user
15:09:10 <mfisch> k
15:09:26 <degorenko> well we are managing not only user
15:09:28 <EmilienM> I wish chem could be around
15:09:41 <EmilienM> but yeah, this pattern should be ok
15:09:42 <degorenko> may be some 'servicename:endpoint' ? or something more common then user
15:10:17 <mwhahaha> well these classes configure keystone::resource::service_identity
15:10:23 <mwhahaha> so what exactly is that configuring?
15:10:35 <degorenko> service, user, roles
15:10:37 <degorenko> endpoints
15:10:41 <iurygregory> yeah
15:10:49 <mwhahaha> then i guess just 'servicename' should be the title
15:10:52 <degorenko> may be <service_name>:identity ?
15:10:56 <degorenko> i don't know :D
15:11:05 <mwhahaha> yea me neither which is why i thought to bring it up :D
15:11:22 <mwhahaha> I just think we need to improve the consistency for these
15:11:32 <degorenko> agree
15:12:21 <EmilienM> can we file a bug?
15:12:30 <mwhahaha> yea
15:12:36 <EmilienM> https://bugs.launchpad.net/puppet-mistral/+bug/1588275
15:12:36 <openstack> Launchpad bug 1588275 in puppet-mistral "service_name & auth_name need to be used properly in keystone auth manifest" [Undecided,In progress] - Assigned to Venkata Mahesh Jonnalagadda (vj884x)
15:12:42 <degorenko> i guess we have a bunch of bugs for this :D
15:12:51 <iurygregory> <service_name>:identity looks good to me =)
15:12:52 <mwhahaha> there's a bunch of bugs cause venkata created a bunch rather than one with multiple projects
15:12:53 <iberezovskiy> may be https://github.com/openstack/puppet-keystone/blob/master/manifests/resource/service_identity.pp#L120 ?
15:12:58 <EmilienM> they are all duplicated or?
15:13:15 <EmilienM> the bug description is not super helpful
15:13:23 <mwhahaha> yea it's not
15:13:25 <EmilienM> can someone file a bug explaining the problem correctly?
15:13:30 <mwhahaha> yea i'll do that today
15:13:33 <EmilienM> excellent
15:13:36 <mwhahaha> i think we need to properly pass auth_name all the time
15:13:36 <degorenko> mwhahaha: thanks :D
15:13:47 <degorenko> right
15:13:50 <mwhahaha> and i think hardcode openstack service name as the title
15:13:56 <iurygregory> if you guys need help let me know o/
15:14:10 <mwhahaha> so i just wanted to raise it
15:14:22 <mwhahaha> #action mwhahaha create bug around *::keystone::auth inconsistencies
15:14:55 <iurygregory> maybe also create a trello card and use same topic
15:14:57 <EmilienM> mwhahaha: maybe come up with a PoC
15:15:10 <EmilienM> mwhahaha: so we can discuss in gerrit review
15:15:13 <mwhahaha> k
15:15:16 <EmilienM> cool
15:15:47 <EmilienM> ok let's move
15:15:52 <EmilienM> #topic release status
15:16:15 <EmilienM> so last week we released 7.1.0 (liberty) and 8.1.0 (mitaka) and I was supposed to release 9.0.0 (newton beta) but had some blockers
15:16:30 <EmilienM> main blocker is this governance patch: https://review.openstack.org/323027
15:16:35 <EmilienM> and some CI stuffs that are fixed already now
15:16:57 <EmilienM> dhellmann confirmed to me on IRC that https://review.openstack.org/325680 would land and we will have 9.0.0 soon
15:17:19 <EmilienM> any question about releases?
15:17:46 <EmilienM> #topic CI status
15:17:52 <EmilienM> iberezovskiy: you have something to announce go ahead!
15:18:15 <iberezovskiy> just an announcement: we've replaced ubuntu_vlan_ha to more usniversal job
15:18:27 <iberezovskiy> now it will check deployment dependin on module
15:18:31 <EmilienM> can you summarize what does this job and how we should take care of it?
15:18:43 <iberezovskiy> puppet-ceph module will be checked throught ceph/radosgw
15:19:00 <iberezovskiy> puppet-ceilometer - through ceilometer deployment test
15:19:10 <EmilienM> cool, like we have with our scenarios
15:19:14 <iberezovskiy> similar
15:19:21 <EmilienM> excellent news
15:19:22 <iberezovskiy> it could be unstable for the first time
15:19:33 <iberezovskiy> but I'll be monitoring them
15:19:41 <EmilienM> ok, we'll let you know failures
15:19:43 <iberezovskiy> so feel free to ping me with any questions
15:19:49 <bkero> iberezovskiy: could you link us the test definition?
15:20:02 <bkero> s/test/job/
15:20:23 <iberezovskiy> link to the job here https://ci.fuel-infra.org/view/puppet-openstack/job/master.puppet-openstack.fuel-library.pkgs.ubuntu.review_in_fuel_library/
15:20:38 <iberezovskiy> but I don't have its description right now, I'll work on it
15:20:58 <iurygregory> we need to update the docs =D
15:21:24 <iberezovskiy> yep, I'll do
15:21:36 <EmilienM> I have 2 announcements about CI
15:21:58 <bkero> iurygregory: it would be useful to add descriptions to each job to the docs :)
15:22:08 <bkero> descriptions for each job*
15:22:11 <EmilienM> 1) we now have OpenStack Proposal Bot sending a patch to our CI to bump to latest RDO URL, so we're staying close to master every day
15:22:11 <iurygregory> bkero, right ;)
15:22:30 <EmilienM> to core reviewers: feel free to +2 +A the patch is passing all CI
15:22:57 <EmilienM> 2) I worked on zuul layout last week and we now have xenial jobs voting for master (newton)
15:23:10 <bkero> \o/
15:23:19 <iurygregory> aewsome :D
15:23:20 <EmilienM> any question about CI?
15:23:51 <EmilienM> #ŧopic xenial status
15:23:53 <EmilienM> degorenko: hey
15:24:06 <degorenko> hey
15:24:06 <degorenko> so
15:24:08 <EmilienM> so do we have some progress?
15:24:15 <degorenko> we have working ceph on deployment stage
15:24:28 <xarses> \o/
15:24:30 <degorenko> but we have some troubles with tempest and uploading images
15:24:34 <EmilienM> today I checked canonical repos and they still don't have usable packaging for newton
15:24:58 <EmilienM> degorenko: where do you see working ceph deployment?
15:25:01 <EmilienM> I see red CI jobs
15:25:04 <degorenko> yes
15:25:19 <degorenko> but if you will look on jobs - failed on stage with uploading cirros
15:25:31 <degorenko> on my local deployment is ok
15:25:34 <EmilienM> well, so ceph doesn't work :P
15:25:39 <EmilienM> ah?
15:25:41 <degorenko> but i didn't test it fully
15:25:45 <degorenko> :D
15:25:48 <iurygregory> lol
15:26:07 <EmilienM> mhh
15:26:21 <EmilienM> I would not say we're good at this stage
15:26:48 <EmilienM> we're still waiting for ceph packaging in centos SIG, I'm trying to contact them today
15:27:29 <EmilienM> degorenko: have you looked at https://review.openstack.org/#/c/313662/ failures?
15:28:37 <degorenko> well, i dont have such failures
15:28:44 <degorenko> but i'll doble check
15:28:48 <degorenko> may be i have old repos
15:29:03 <EmilienM> mhh ok
15:29:22 <EmilienM> keith already disabled rgw tests to make it pass
15:29:24 <degorenko> probably some beaker specific cases
15:29:32 <degorenko> yeah, i saw patch
15:30:02 <EmilienM> I'm wondering if we should disable beaker jobs voting for now on puppet-ceph
15:30:06 <EmilienM> they are really unstable
15:30:22 <EmilienM> maybe focus on our integration jobs
15:30:35 <EmilienM> and make tripleo/fuel jobs passing
15:30:49 <EmilienM> and accept this patch only if integ/ooo/fuel pass green
15:30:59 <degorenko> EmilienM: what's status of tripleo? is it fixed?
15:31:08 <EmilienM> degorenko: our CI is down
15:31:14 <degorenko> okay :)
15:31:20 <EmilienM> degorenko: it should be fixed by today hopefully
15:31:43 <EmilienM> degorenko: we're in transition to use centos7 dib, that's the main reason
15:31:45 <degorenko> ok, just wandering can we still merge patches with red tripleo
15:31:49 <EmilienM> instead of fedora22
15:31:54 <EmilienM> no, we can't
15:32:05 <EmilienM> it's a critical patch, please do not land this patch until ooo/fuel/integ is green
15:32:16 <EmilienM> ok, let's followup later on our channel
15:32:18 <degorenko> which one?
15:32:22 <EmilienM> https://review.openstack.org/#/c/313662/
15:32:36 <degorenko> ah, ok
15:32:47 <EmilienM> #topic Open Discussion, Bug and Review triage (submit modules to triage here)
15:32:47 <degorenko> but i'm about only tripleo
15:33:05 <EmilienM> there is a new bug reported: https://bugs.launchpad.net/puppet-keystone/+bug/1589933
15:33:05 <openstack> Launchpad bug 1589933 in puppet-keystone ""keystone::roles::admin" class can't assign a role to admin user when project is specified." [Undecided,New]
15:33:10 <degorenko> yeah
15:33:15 <degorenko> and i want to discuss
15:33:20 <EmilienM> go ahead
15:33:42 <degorenko> so, currently user role can assign only for tenant (project) or if first is unset - for domain
15:33:53 <degorenko> is it expected behavior? Or it should be assigned for both?
15:34:00 <EmilienM> richm: ^
15:34:05 <degorenko> may chem or richm ?
15:34:40 <degorenko> because we faced with such issue in fuel
15:35:14 <iurygregory> i think it should apply for only one
15:35:28 <degorenko> but we can have some project in some domain
15:35:44 <iurygregory> but if you pass both domain and project should apply to both (2 calls) ?
15:35:58 <iberezovskiy> iurygregory,  it probably should have 2 calls
15:36:08 <degorenko> it should, but provider uses only one
15:36:15 <iurygregory> humm
15:36:27 <degorenko> https://github.com/openstack/puppet-keystone/blob/master/lib/puppet/provider/keystone_user_role/openstack.rb#L88-L91
15:36:28 <iberezovskiy> #link https://github.com/openstack/puppet-keystone/blob/master/lib/puppet/provider/keystone_user_role/openstack.rb#L88-L92
15:36:34 <degorenko> :D
15:36:42 <EmilienM> I'm not sure we use the composite namevar correctly
15:36:55 <EmilienM> but if we do, there is a bug
15:37:14 <EmilienM> we need to get in touch with chem
15:37:16 <degorenko> yeah, that's why i want to discuss, may be it is correct
15:37:32 <EmilienM> I assigned it to him
15:37:40 <EmilienM> I'll ping him later
15:37:46 <EmilienM> he does not seem around
15:37:50 <EmilienM> anything else for today?
15:38:41 <EmilienM> ok thanks everyone
15:38:43 <EmilienM> #endmeeting