15:00:15 <crinkle> #startmeeting puppet-openstack
15:00:18 <openstack> Meeting started Tue Aug 11 15:00:15 2015 UTC and is due to finish in 60 minutes.  The chair is crinkle. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:22 <openstack> The meeting name has been set to 'puppet_openstack'
15:00:37 <crinkle> #link agenda https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150811
15:00:43 <crinkle> anyone here?
15:00:46 <iurygregory> me o/
15:00:46 <richm> hello
15:01:08 <spredzy> morning
15:01:29 <crinkle> #topic Review past action items
15:01:31 <xarses> o/
15:01:43 <crinkle> sbadia launch a initial msync on all our modules - sbadia ?
15:01:59 <sbadia> hi!
15:02:01 <mdorman> o/
15:02:03 <sbadia> sorry for the delay
15:02:09 <bogdando> \o
15:02:09 <sbadia> crinkle: still in progress
15:02:27 <angdraug> o/
15:02:29 <mattymo_> hi
15:02:30 <sbadia> but, I'll finish the clean just after the meeting
15:02:37 <sbadia> I'll send an email after on the ml
15:02:43 <mfisch> hey
15:02:49 <crinkle> People to review https://review.openstack.org/#/c/190361/ and eventually give feedback -1/+1 <-- looks like we need some more reviews
15:03:11 <iurygregory> well about the spec
15:03:25 <iurygregory> i've recived only 2 +1 and onde +2
15:03:33 <iurygregory> one*
15:03:37 <mfisch> I will look again today
15:03:47 <iurygregory> o/ thanks mfisch
15:04:17 <crinkle> #topic Liberty status
15:04:26 <crinkle> #link blockers https://etherpad.openstack.org/p/puppet-liberty-blocker
15:04:53 <crinkle> EmilienM's been looking into this, I'm sure he would appreciate help debugging those unknown failures
15:05:46 <crinkle> #topic CI
15:06:50 <crinkle> paul and emilien are working on setting up integration tests
15:07:02 <crinkle> #link integration https://review.openstack.org/#/q/project:openstack/puppet-openstack-integration+status:open,n,z
15:07:31 <crinkle> we're also trying to figure out how to gate that repo with a couple of "canary" beaker tests from the modules it affects
15:07:46 <spredzy> crinkle, could you define "canary" please ?
15:08:28 <iurygregory> ++
15:08:59 <crinkle> spredzy: we want to be able to test a module with the changes made to the integration repo to see if the changes will break the gate for the other modules
15:09:34 <crinkle> we'd use "canary" modules in the sense that we don't feel like we need to test every single module, just a couple would be good indicators of whether things will break
15:09:57 <spredzy> crinkle, ok thanks for the explanation. It makes sense
15:10:22 <crinkle> (comes from https://en.wiktionary.org/wiki/canary_in_a_coal_mine)
15:11:04 <iurygregory> nice reference
15:11:11 <iurygregory> ^^
15:11:18 * spredzy thinks poor canaries
15:11:37 <crinkle> we also need to start defining a few scenarios to test against, so operator input there would be very helpful
15:12:03 <mfisch> how complete would those be?
15:12:08 <crinkle> that's been started in https://review.openstack.org/#/c/207070/ but is not in its final form
15:12:19 <crinkle> mfisch: not sure
15:13:45 <crinkle> mfisch: do you have something in mind?
15:14:17 <mfisch> crinkle: well you just mean small openstack scenarios?
15:14:28 <mfisch> like a control node and compute node? that kind of thing?
15:14:57 <crinkle> mfisch: probably yes, I don't think we'd be able to handle massive deployments
15:15:16 <mfisch> even a single node setup would work
15:15:22 <mfisch> we do a 5 node here for our testing
15:17:06 <crinkle> awesome
15:17:26 <crinkle> at some point later we can maybe start an etherpad to brainstorm what kinds of deployments to test
15:17:44 <mfisch> sure
15:17:48 <mfisch> we should start small
15:17:48 <crinkle> anything else on CI?
15:19:07 <crinkle> #topic Keystone v3 - always include "::domain"
15:19:12 <crinkle> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/071433.html
15:19:14 <crinkle> richm: ?
15:19:58 <richm> So how does everyone feel about having to add "::domainname" to every single Keystone domain scoped resource everywhere?
15:20:26 <richm> e.g. every user has to be specified as "username::domainname"
15:21:05 <angdraug> mattymo_: you've been working on v3 related patches recently, do you have a strong opinion?
15:21:30 <angdraug> would it make your life more difficult?
15:21:37 <richm> From a purely developer standpoint - I think it's great - makes naming domain scoped resources completely unambiguous
15:22:05 <mfisch> even if its foo::default?
15:22:11 <mattymo_> I'd like to see it flexible and not have to specify domain in every single ref imaginable
15:22:14 <saneax> o/
15:22:15 <richm> mfisch: yes, and it probably will be
15:22:33 <mfisch> not sure we have any plans to use any v3 stuff here
15:22:33 <mattymo_> it only applies to multidomain scenarios which are currently quite rare
15:22:39 <richm> that is, the first pass would be to just do s/name/name::Default/g
15:22:39 <mfisch> so Im hoping for a simple path
15:22:57 <richm> The current solution is this
15:23:19 <richm> - use the name without the ::domain part if it is unique throughout all domains
15:23:56 <bogdando> lets follow KISS here
15:24:05 <richm> - if there is more than one resource with the same name, if there is one in the default domain, use it without a domain e.g. "admin"
15:24:22 <richm> - otherwise, a non-unique name not in the default domain must use "::domainname"
15:24:38 <richm> bogdando: The KISS approach varies depending on your perspective
15:25:15 <richm> bogdando: From a puppet/ruby dev standpoint, requiring "::domainname" everywhere is a very KISS approach
15:25:50 <bogdando> richm, I mentioned provider's perspective. And I agree with your comment. Less logic in provider - the better is
15:26:11 <richm> however, from an operator standpoint, if I have a user named "glance", there is obviously only going to be one user named "glance", no matter which domain it is in
15:26:31 <richm> so if I refer to a user named "glance", the code should just "do the right thing" and find and use the one and only user named "glance"
15:26:36 <mfisch> and some of us dont want to deal with domains at all
15:27:06 <richm> mfisch: at least, for the foreseeable future
15:27:18 <bogdando> this reminds FQDN or shortname
15:27:19 <angdraug> I'm still confused about the ::default case, why s/name/name::Default/g if "if there is one in the default domain, use it without a domain"?
15:27:38 <richm> angdraug: I guess I am confusing things
15:27:49 <bogdando> if there good examples for node names, we could follow
15:28:19 <richm> angdraug: When I said that, I meant that if we decide to require the domain name everywhere, the easiest thing to do would be to just stick "::Default" on the name of every resource
15:28:26 <bogdando> other modules I mean, how they solve FQDN vs shortname?
15:29:13 <richm> bogdando: yes, this is similar to the problem of host naming + aliases
15:29:18 <bogdando> use_fqdn could be a good way to treat names. So, probably use_domains could help us
15:29:37 <richm> bogdando: not sure what you mean - what is 'use_fqdn'?
15:29:39 <bogdando> which switch the provider's logic
15:30:15 <bogdando> When use_domains=true, foo::default would be considered as just a name, without domain
15:30:32 <bogdando> sorry, typo. When use_domains=false
15:30:52 <richm> bogdando: is that a facter fact?
15:31:18 <bogdando> I think it is not, just a class (provider?) parameter
15:31:18 <richm> or are you proposing a new resource parameter?
15:31:31 <bogdando> richm, yes
15:31:46 <bogdando> new param
15:32:06 <richm> bogdando: I think that would be very difficult to do - e.g. if you use use_domains=true in keystone_user, you would need to use it in keystone_user_role
15:33:23 <richm> a global fact I think would be the way to go - either all resources are domain aware, or none of them are
15:33:34 <richm> and you will need this logic at the puppet level as well
15:33:36 <bogdando> the UX would depend on defaults
15:33:54 <Hunner> Any time yop need to access something in the catalog (like use_domains) from a provider, things get ugly
15:34:15 <Hunner> Because self.instances can't really read facts, for example
15:34:25 <richm> ok
15:34:51 <richm> the way it works now, if there is the "::" character in a resource name, it means "use domains"
15:35:00 <richm> "::" string, not character
15:35:01 <bogdando> makes sense
15:35:44 <richm> mfisch: Am I correct in assuming you prefer the way it is now, where domains are not required?
15:36:02 <mfisch> well perfer it out of laziness
15:36:06 <mfisch> prefer it
15:36:18 <richm> ack
15:36:40 <bogdando> so we should either "require the domain name everywhere" or benefit users who "dont want to deal with domains at all". Cannot do both
15:36:51 <richm> bogdando: correct
15:36:55 <saneax> 2 cents, domains are realty in largeer deployments
15:37:04 <saneax> larger*
15:37:13 <richm> yes - we have to support domains, one way or another
15:37:31 <bogdando> use_domains could, but seems not a KISS at all...
15:37:51 <richm> gildub is the one who is running into problems with domain support in keystone_trusts and keystone_groups
15:38:14 <richm> Unfortunately he is East Australia and could not attend this meeting
15:39:39 <richm> I think he has made his case in the email thread mentioned above and in the etherpad
15:40:05 <bogdando> as we cannot do both, we have no choice actually, but benefit the most part of users who may want not have domains
15:40:32 <richm> bogdando: I don't know if our sample size is big enough to know if we have heard from "the most part of users"
15:41:17 <bogdando> I don't mean the most of users don't want domains
15:41:40 <angdraug> richm: what about adding openstack-operators to that thread, would that yield a bigger sample of users?
15:41:48 <richm> angdraug: +1
15:41:48 <bogdando> but we should not reject them
15:42:31 <richm> as it is now, gildub doesn't really want to proceed until this issue is solved, so this is holding up key v3 features such as trusts and federation
15:42:39 <bogdando> but I personally would prefer use_domains, to address both cases
15:43:03 <crinkle> okay, so continue this on the mailing list?
15:43:10 <richm> crinkle: ok
15:43:30 <crinkle> #action continue keystone domains discussion on operators ml
15:43:52 <crinkle> #topic Open Discussion, Bug and Review triage
15:44:13 <angdraug> #link https://review.openstack.org/198695
15:44:14 <crinkle> some patches have been submitted on the agenda etherpad to review
15:44:30 <mattymo_> can we discuss https://review.openstack.org/#/c/207890/ and https://review.openstack.org/#/c/207873/ ?
15:44:51 <angdraug> I'd like to register a concern about 198695 first
15:45:22 <angdraug> it was a month between the patch being submitted and it getting a -1
15:45:48 <angdraug> the -1 was submitted yesterday so it's too early to tell if it's in disagreement or if there will be a consensus about it
15:46:00 <angdraug> but the comment is about the general principle of the commit, not code specifics
15:46:12 <alex_didenko> as for https://review.openstack.org/198695 - I've added a comment there like 20 minutes ago
15:46:13 <angdraug> which means it shouldn't have taken a month to -1 it
15:46:53 <angdraug> I said my piece, if there's no objections lets move on to mattymo_'s patches
15:48:01 <crinkle> angdraug: thanks for bringing it up, we can continue discussing it on the patch
15:48:25 <sgolovatiuk> https://review.openstack.org/#/c/208462/ was rebased also, it had EmilienM +2 though
15:49:03 <crinkle> #link https://review.openstack.org/#/c/207890/
15:49:11 <crinkle> #link https://review.openstack.org/#/c/207873/
15:49:18 <crinkle> #link https://review.openstack.org/#/c/208462/
15:50:01 <angdraug> mattymo_: what's changed about your keystone patches since last week?
15:50:03 <mattymo_> What's tough here is how 207890+207873 should be tested.... 207890 is failing because adding "depends-on" doesn't actually ensure that code gets used
15:50:45 <mattymo_> the openstackclient commands fail when you use v2.0 api in auth_url... as I reported. so we need to consider if 207873 has enough test coverage to get merged and we can finish fixing keystone
15:51:25 <mattymo_> the test case seems to be adequate, but maybe too crude in https://review.openstack.org/#/c/207890/8/spec/acceptance/basic_keystone_spec.rb
15:51:43 <mattymo_> deploy normally, then add /root/openrc, apply again, add env vars, apply yet again
15:51:56 <crinkle> mattymo_: the depends-on should work here
15:51:57 <mattymo_> definitely covers regressions
15:52:25 <mattymo_> crinkle, is it possible for you to deploy that beaker scenario and see physically if the patch to openstacklib is there?
15:52:35 <mattymo_> I've spent the entire day trying to get a beaker deployment up
15:53:52 <crinkle> mattymo_: we can't use depends-on for local testing
15:54:06 <angdraug> is there a dev-usable canned beaker env anywhere?
15:54:08 <mattymo_> ok so we have a chicken and egg scenario?
15:54:24 <mattymo_> depends-on should work, but we can't prove it
15:55:06 <bogdando> do you mean gerrit dependency or just a commit message?
15:55:16 <angdraug> commit message
15:55:40 <mattymo_> bogdando,  dependency so that puppet-keystone uses my puppet-openstacklib patchset
15:55:41 <crinkle> mattymo_: I can investigate after the meeting
15:55:48 <bogdando> understood
15:55:48 <crinkle> we specifically set it up to work
15:56:06 <bogdando> seems like a major dev issue
15:56:29 <crinkle> to emulate it locally you can modify http://git.openstack.org/cgit/openstack/puppet-keystone/tree/spec/spec_helper_acceptance.rb#n48 to copy the module from a local directory
15:56:45 <crinkle> but we don't have a good solution to make beaker just do it based on the commit message
15:57:25 <mattymo_> as a short term workaround, we could push forward and consider my openstacklib patch first
15:57:26 <angdraug> 3 minutes left
15:57:36 <mattymo_> but if someone wants to discuss another bug, go ahead
15:57:49 <angdraug> action?
15:57:54 <angdraug> or back to ML?
15:58:36 <crinkle> #action crinkle to check on depends-on functionality in CI
15:59:08 <crinkle> I can do that quickly and if we find out it really doesn't work we can test the patch locally with my workaround ^ and go from there
15:59:22 <crinkle> any other patches?
15:59:32 <crinkle> #link https://review.openstack.org/#/q/status:open+branch:master+topic:fix_fixtures,n,z
15:59:33 <iurygregory> if you have time https://review.openstack.org/#/c/190361/
15:59:37 <iurygregory> ^^
15:59:42 <crinkle> #link https://review.openstack.org/202574
15:59:45 <bogdando> just please make more reviews, nothing more to add from my side, I'm not a patch author
15:59:51 <crinkle> #link https://review.openstack.org/#/q/status:open+branch:master+topic:inifile_proxy_provider,n,z
16:00:15 <crinkle> okay, thanks everybody
16:00:18 <crinkle> #endmeeting