15:01:08 <EmilienM> #startmeeting puppet-openstack
15:01:09 <openstack> Meeting started Tue Aug 25 15:01:08 2015 UTC and is due to finish in 60 minutes.  The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:13 <openstack> The meeting name has been set to 'puppet_openstack'
15:01:18 <EmilienM> #link agenda: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150825
15:01:18 <angdraug> hi
15:01:21 <bogdando> hi
15:01:22 <IBerezovskiy> hi
15:01:24 <aderyugin> hi
15:01:25 <mwhahaha> hi
15:01:25 <skolekonov> hi
15:01:36 <mfisch> prevyet
15:01:37 <degorenko> hello
15:01:39 <clayton> morning
15:01:39 <crinkle> o/
15:01:43 <jpena> o/
15:01:54 <EmilienM> #topic Review past action items
15:01:56 <richm> hello
15:02:03 <EmilienM> angdraug to share negative feedback on current state of keystone/WSGI over the Mailing list, using the thread about acceptance
15:02:09 <EmilienM> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/072599.html
15:02:25 <EmilienM> you might need to patch puppet-keystone to support new parameters: https://review.openstack.org/#/c/212439/19/deployment/puppet/openstack/manifests/keystone.pp,cm
15:02:25 <iurygregory> o/
15:02:57 <EmilienM> bogdando: ^
15:03:14 <EmilienM> instead if using keystone_config, I would suggest to add the params to puppet-keystone module
15:03:47 <mwhahaha> we can do that
15:03:50 <EmilienM> cool
15:03:53 <bogdando> EmilienM, good point
15:03:53 <EmilienM> #topic announcements
15:03:58 <mwhahaha> i'll do that today
15:04:05 <EmilienM> Federation blueprint has been approved
15:04:12 <EmilienM> #link federation specs: http://specs.openstack.org/openstack/puppet-openstack-specs/specs/liberty/enabling-federation.html
15:04:16 <EmilienM> iurygregory: thx for this work
15:05:02 <EmilienM> #topic midcycle
15:05:12 <EmilienM> #link midcycle agenda https://etherpad.openstack.org/p/puppet-liberty-mid-cycle
15:05:49 <EmilienM> so it will happen on #openstack-sprint from september 2 to 4
15:06:03 <EmilienM> pabelanger, anteaya and I will be in Montreal but everything should happen on IRC
15:06:31 <EmilienM> feel free to feed the agenda with topics and split in other etherpads, like it's for CI
15:06:39 <clayton> EmilienM: I have a patch in progress to add external hooks for the heat module like we've done for the designate module.  I'm also working on an os_docker module we're going to use for adding docker support using the hooks.  I hope to have something a few days, but we can work on that stuff for the mid-cycle also
15:07:15 <EmilienM> clayton: cool, I see a topic in the agenda - maybe if you describe the work that needs to be done in an etherpad, folks could help you
15:07:21 <clayton> sounds god
15:07:23 <clayton> good
15:07:33 <sgolovatiuk> o/
15:07:34 <_ody> morning
15:07:52 <EmilienM> #action clayton to prepare an etherpad about  external install & svc management patches in puppet-* for midcycle
15:07:55 <vinsh_> o/
15:08:06 <EmilienM> clayton: you'll lead that work
15:08:10 <clayton> wfm
15:08:43 <EmilienM> richm: maybe we could define some user stories to work on during the midcycle
15:08:46 <EmilienM> richm: about v3 work
15:08:57 <richm> ok
15:09:19 <EmilienM> richm: can you also create an etherpad and define one or 2 goals that we could achieve during the midcycle?
15:09:34 <richm> yes
15:09:48 <EmilienM> richm: iirc, you're attending the midcycle too
15:09:54 <richm> no
15:10:00 <EmilienM> richm: virtually, no?
15:10:02 <richm> yes
15:10:05 <EmilienM> fine
15:10:06 <richm> virtually
15:10:19 <EmilienM> richm: so if you don't mind too, I'll let you lead v3 work during the 3 days
15:10:36 <richm> ok
15:10:47 <EmilienM> coordinate the work that you think urgent for a liberty release
15:10:55 <EmilienM> that's the right words I think :)
15:11:01 <richm> works for me
15:11:04 <EmilienM> cool
15:11:27 <EmilienM> #action richm to start a new etherpad for midcycle about keystone v3 work that we could achieve in 3 days
15:11:55 <richm> EmilienM: Is there an etherpad for midcycle?
15:12:02 <EmilienM> richm: https://etherpad.openstack.org/p/puppet-liberty-mid-cycle
15:12:25 <EmilienM> pabelanger: we might need to continue to work on https://etherpad.openstack.org/p/puppet-openstack-CI
15:12:37 <EmilienM> for the agenda at least
15:12:51 <pabelanger> ok
15:13:08 <EmilienM> pabelanger: maybe you could write down in this etherpad what we need to discuss, our recent blockers & discussions - I would be happy if we would solve our questions
15:13:22 <pabelanger> sure
15:13:24 <EmilienM> pabelanger: specially regarding your concerns
15:13:27 <EmilienM> cool, awesome
15:13:50 <EmilienM> #action pabelanger and EmilienM follow-up https://etherpad.openstack.org/p/puppet-openstack-CI about puppet-openstack-integration
15:14:23 <EmilienM> mfisch: are you interested to lead bug triage during midcycle?
15:14:39 <EmilienM> I'm asking because you love LP :P
15:14:43 <mfisch> sure
15:14:58 <EmilienM> maybe if mgagne is around you guys can coordinate the work
15:14:59 <mfisch> I was going to generate a list of 20 or so t hat we should walk through and see how far we get
15:15:04 <EmilienM> awesome
15:15:50 <EmilienM> so that's the only topics I see in the agenda, do you guys have something else to add ?
15:16:24 <richm> yes
15:16:39 <EmilienM> richm: ?
15:16:39 <richm> my topic that I added after the meeting started :P
15:16:46 <EmilienM> richm: about midcycle
15:16:54 <richm> ah, no, sorry
15:16:55 <EmilienM> richm: we are still talking about midcycle topics
15:17:03 <EmilienM> feel free to add them in the etherpad otherwise, let's go ahead in the agenda
15:17:21 <EmilienM> #topic CI
15:17:26 <EmilienM> I have a couple of CI informations
15:17:40 <EmilienM> first, we merged puppet-openstack-integration basic structure
15:17:55 <EmilienM> we are facing a lot of Liberty issues
15:18:11 <EmilienM> #link liberty packaging blockers: https://etherpad.openstack.org/p/puppet-liberty-blocker
15:18:34 <EmilienM> so you might see jenkins failures because of ^
15:18:49 <EmilienM> before doing 'recheck', please check the etherpad to see if errors still occur
15:19:19 <EmilienM> if you're willing to help about that pkging stuffs, please ping me, I'm trying to get them solves every day
15:19:34 <EmilienM> but any help is really appreciated
15:19:35 <mfisch> good idea on the etherpad for that
15:20:25 <EmilienM> so far having puppet-openstack-integration basic structure is really helpful, we found a bug in tempest (not yet reported, will do after the meeting) and in puppet-glance https://launchpad.net/bugs/1488277
15:20:25 <openstack> Launchpad bug 1488277 in puppet-glance "glance_image provider: orchestration issue when running keystone wsgi" [Undecided,In progress] - Assigned to Emilien Macchi (emilienm)
15:20:57 <EmilienM> so we are iterating like we wanted - thx for crinkle & pabelanger for that
15:21:45 <EmilienM> a next step would be to run integration in puppet-keystone & oslib: https://review.openstack.org/215723
15:21:53 <EmilienM> anteaya: you might help by reviewing this patch ^
15:22:03 <EmilienM> do we have anything else about CI ?
15:22:15 * anteaya looks
15:23:14 <EmilienM> #topic Summit preparation
15:23:23 <EmilienM> so I got an email from ttx
15:23:32 <ttx> that happens
15:23:39 <EmilienM> we are allocating session slots
15:24:08 <EmilienM> I need to tell ttx if we need Fishbowl slots or Workrooms or/and Contributors meetup
15:24:38 <EmilienM> #1 is: Our traditional largish rooms organized in fishbowl style, with
15:24:38 <EmilienM> advertised session content on the summit schedule for increased external
15:24:38 <EmilienM> participation. Ideal for when wider feedback is essential.
15:24:48 <EmilienM> #2 is: Small rooms organized in boardroom style, with topic buried in the
15:24:48 <EmilienM> session description, in an effort to limit attendance and not overcrowd
15:24:48 <EmilienM> the room. Ideal to get work done and prioritize work in small teams. New
15:24:48 <EmilienM> in Tokyo: those rooms now come with a large monitor in case you want to
15:24:48 <EmilienM> display common stuff.
15:24:57 <EmilienM> and #3 is: Half-day session(s) on the Friday to get into the Mitaka action while
15:24:57 <EmilienM> decisions and plans are still hot, or to finish discussions started
15:24:57 <EmilienM> during the week, whatever works for you.
15:25:11 <mfisch> I like #2 for our group
15:25:29 <EmilienM> yeah and also #3 to get feedback from operators
15:26:00 <mfisch> its difficult for me (maybe others)) to block off a half day for anything unfortunately
15:26:09 <EmilienM> it makes sense
15:26:19 <clayton> especially when speakers haven't been selected yet
15:26:31 <EmilienM> but a Puppet meetup is always useful iirc, isn't?
15:26:44 <clayton> yep, that seems essential
15:27:05 <_ody> I like 2 and 3.
15:27:29 <EmilienM> iirc, we had 1 and 3 in the last summits, right?
15:27:31 <clayton> it seems like a couple of #1 slots would cover that
15:27:47 <EmilienM> clayton: right
15:28:09 <EmilienM> clayton: so I could ask for a couple of #1 (for 2 hours maybe), #2 for our dev sessions, and that's it
15:28:21 <clayton> that seems good to me
15:28:41 <mfisch> +1
15:28:48 <EmilienM> any thoughts? I'll make it official today by sending an email to ttx
15:29:19 <_ody> Would you try to get the #1 back to back or spread them out with different topics?
15:30:11 <EmilienM> _ody: #1 would be for a 2 x1h meetups I guess - get feedback from operators & users
15:30:56 <clayton> probably easier to get people to sit in one place for two hours than to come to two separate sessions
15:31:02 <EmilienM> 2 hours seems reasonable to block until we have an agenda
15:31:08 <EmilienM> clayton: yes
15:31:17 <mfisch> are we going to be exiled again this time or will we be in the main building
15:31:20 <EmilienM> clayton: 1 hour is always too short
15:31:40 <_ody> +1 on priortizing them to be back to back as a total of 2 hours.
15:31:57 <EmilienM> mfisch: no idea, maybe ttx knows
15:32:13 <clayton> if we're really short on time, we can choose to redirect people to one of the dev sessions
15:32:15 <ttx> mfisch: main building
15:32:24 <ttx> for some definition of main building
15:32:35 <ttx> at least, "same building as other project teams"
15:32:44 <EmilienM> #action EmilienM to sends an email to ttx about Summit rooms (2 hours of Fishbowl slots) and Workroom slots for dev sessions
15:32:57 <EmilienM> ttx: cool
15:33:00 <mfisch> thx
15:33:12 <EmilienM> anything else about summit so far?
15:33:43 <xarses> sounds good =)
15:33:43 <EmilienM> #topic Keystone v3 resource naming for domain scoped resources
15:33:46 <EmilienM> richm: o/
15:34:02 <richm> There has been hardly any feedbackj
15:34:05 <richm> feedback
15:34:11 <EmilienM> true
15:34:14 <richm> my email to openstack-operators was met with silence
15:34:21 <EmilienM> richm: link?
15:34:31 <clayton> I think most operators are hoping that they can continue to ignore keystone v3 :)
15:34:50 <mfisch> +1000
15:34:52 <richm> http://lists.openstack.org/pipermail/openstack-operators/2015-August/007927.html
15:34:54 <EmilienM> #link http://www.gossamer-threads.com/lists/openstack/operators/48812
15:34:59 <EmilienM> richm: thx
15:35:15 <richm> The upstream Keystone devs would like ::domain to be used everywhere
15:35:44 <richm> It would certainly be simpler from a dev standpoint to make resource naming unambiguous
15:35:50 <richm> it would simplify the coding too
15:36:17 <richm> I think from an operator standpoint it would be better to explicitly state which domain a resource is in
15:36:43 <mfisch> I think logically that makes sense, from a lazy POV I'm with clayton
15:36:55 <crinkle> I forget, what about when the domain is Default?
15:36:59 <richm> as long as it is easy to change the domain - which means having to parameter-ize all Keystone resource names, including keystone_user_role names
15:37:22 <richm> crinkle: The preferred way is that you have to specify ::Default
15:37:46 <crinkle> is it a significant issue to just assume Default if there's no :: ?
15:38:55 <richm> crinkle: I don't know - it would also depend if default_domain_id is set to something other than "default"
15:39:13 <mwhahaha> maybe throw a warning if there is no ::
15:39:21 <richm> mwhahaha: ok
15:39:38 <Hunner> No ::default could always just declare ::domain with title of "default"
15:39:41 <mwhahaha> unless it's required by keystone, shouldn't prevent a user from doing something
15:39:47 <mfisch> there are 2 camps here, people who ignore domains and wish they didnt exist and people who enthusiastically use them, I dont think many will not use them and rename the default
15:40:12 <richm> One of the main uses cases for domains is this:
15:40:15 <crinkle> I'm not an operator but it seems like a major barrier to upgrade, if it could just assume the hardcoded "default" and not worry if the default was changed that would work for the people who didn't care about domains
15:40:31 <clayton> crinkle: +1
15:40:34 <richm> Separation of service accounts from enterprise accounts
15:40:43 <EmilienM> crinkle: yes +1
15:40:52 <mfisch> thats the main use case for sure but wont work for me unfortunateloy
15:40:56 <EmilienM> we need to think at a smooth upgrade between kilo & liberty
15:41:01 <richm> Keep the service accounts in the default domain, but have the users in a separate "users" domain
15:41:11 <crinkle> mfisch: you change the default domain?
15:41:26 <bogdando> Please clarify, would the "always do specify a domain" break the backwards compatibility?
15:41:26 <mfisch> no I dont I was saying people who dont use domains will not change the default
15:41:33 <richm> bogdando: yes
15:41:38 <crinkle> mfisch: oh I see
15:41:56 <bogdando> richm, well, we have a strict policy for this in PO
15:42:22 <bogdando> could we do this still compatible but with warnings? to be removed later?
15:42:33 <clayton> I would be fine with saying that for liberty the default is optional and telling people it will go away with M
15:42:34 <bogdando> to be reworked, actually...
15:42:47 <clayton> but upgrades already have enough moving parts, I don't want to add more
15:43:06 <richm> ok - then the proposal should be this:
15:43:09 <clayton> and the projects themselves are moving away from having as much done at upgrade time (Lazy DB migrations for example)
15:43:31 <richm> The domain is required unless default_domain_id is not set, in which case "Default" will be assumed.
15:44:27 <richm> There will be no warning in M
15:44:34 <EmilienM> that sounds fair
15:44:41 <mfisch> this makes sense
15:44:47 <richm> In some future release, if a resource is specified without "::domain", a warning will be issued
15:45:07 <richm> If default_domain_id is set, and a resource is used without "::domain", a warning will be issued
15:45:42 <richm> Ok.  This sounds like something that everyone can live with.
15:45:44 <EmilienM> richm: yes for future stable/liberty
15:45:57 <bogdando> so that would be the deprecation for the M-behavior, right?
15:46:03 <EmilienM> richm: we can be a bit less tolerant in M
15:46:14 <richm> bogdando: Yes
15:46:18 <bogdando> LGTM
15:46:40 <EmilienM> richm: can you inform ML with this update?
15:46:41 <bogdando> and in N, no domain will result in error, IIUC
15:47:13 <richm> EmilienM: Yes
15:47:15 <EmilienM> #action richm to inform ML about Keystone v3 resource naming for domain scoped resources Liberty and M behaviors
15:47:17 <bogdando> hm, or in O
15:47:28 <richm> . . . and I think i have my Keystone v3 topic for the mid-cycle . . .
15:47:53 <EmilienM> richm: cool
15:48:01 <EmilienM> we have 15 min for open discussion
15:48:04 <richm> Thanks all
15:48:06 <EmilienM> anything else about v3 ?
15:48:19 <richm> This will hopefully unblock gildub
15:48:38 <EmilienM> ok let's go ahead
15:48:39 <EmilienM> #topic open discussion - bug/patches triage
15:49:20 <bogdando> Do patches https://review.openstack.org/#/c/213957/ and https://review.openstack.org/#/c/213603/ address the same issue with API versions to be used with providers? The latter one was merged, but the former one has a major disagreement.
15:49:20 <bogdando> Meanwile, in the fuel downstream we accepted the abandoned approach instead https://review.openstack.org/#/q/status:abandoned+project:openstack/puppet-openstacklib+branch:master+topic:bug/1479879,n,z -> https://review.openstack.org/#/c/207548/
15:49:20 <bogdando> It would be nice to finish https://review.openstack.org/#/c/213957/ so we could rework this downstream later as well
15:50:09 <EmilienM> bogdando: for #1, patches are not the same
15:50:31 <bogdando> ok, when I think there is no questions left
15:50:46 <bogdando> we will sync the module, eventually.
15:50:59 <EmilienM> bogdando: I suggest to keep discussion happen on gerrit for https://review.openstack.org/#/c/213957/
15:51:16 <bogdando> yes please
15:51:31 <EmilienM> bogdando: it's not abandoned
15:51:35 <EmilienM> it's just not backward compatible
15:51:50 <EmilienM> so it's not possible to merge it
15:52:14 <bogdando> understood
15:52:40 <EmilienM> so I guess https://review.openstack.org/#/c/213957/ will be updated to not break BC
15:53:04 <EmilienM> do we have anything else? jpena, angdraug ? skolekonov ?
15:53:07 <degorenko> can we move to next question? :)
15:53:25 <degorenko> Sahara module is outdated now and needs to be updated.
15:53:39 <degorenko> Process of reviewing Sahara patches so slow, how to speed up it?
15:53:48 <degorenko> I've resolved all comments, have some +2 and here no more another comments
15:53:51 <EmilienM> I'm aware of this issue
15:54:12 <mfisch> I can review from a puppet pov but have no domain knowledge, I dont use sahara and have never even tried it
15:54:30 <EmilienM> that's one of the root causes I would say ^
15:54:56 <degorenko> I see, but my patches have +1 from Sahara devs and i'm from Sahara team :)
15:55:09 <mfisch> then we should take their word for it from a sahara pov
15:55:12 <mfisch> that makes sense
15:55:24 <EmilienM> cool
15:55:33 <angdraug> I've added a comment on https://review.openstack.org/#/c/209412/6/manifests/backend/rbd.pp
15:55:34 <EmilienM> we should just review the puppet code then
15:55:52 <EmilienM> and see if it's backward compatibile with stable/kilo and if CI pass and if it's following our coding style
15:55:53 <angdraug> rbd needs a special treatment there, so I don't think it makes sense to move this parameter to init
15:55:59 <mfisch> EmilienM: I have one small topic before we run out of time when this is done
15:56:06 <EmilienM> 5 min
15:56:31 <degorenko> Also i want to discuss Murano module implementation
15:56:43 <mfisch> I can bring mine up in channel later
15:56:51 <mfisch> go ahead
15:56:58 <degorenko> As you know, Murano module is a new module. And i want to discuss how we should to implement this?
15:57:12 <degorenko> How to split our patches, because i think, that patches in 500 or 600 lines is not very good for review.
15:57:17 <EmilienM> https://wiki.openstack.org/wiki/Puppet/New_module
15:57:31 <EmilienM> degorenko: true. We need to iterate
15:57:49 <angdraug> should we import the whole history from fuel-library?
15:58:00 <EmilienM> first, basic structure of the module (puppet requirements) then, init, then api, etc... and each time with according tests (unit at least, not acceptance is required yet I guess)
15:58:22 <EmilienM> it's up to you but I would start from scratch here, I'm not sure fuel module is compliant
15:58:46 <angdraug> almost definitely isn't, just wanted to get that option out of the way
15:59:42 <EmilienM> cool
15:59:50 <EmilienM> so yeah, iteration is a good idea
15:59:54 <EmilienM> and will help reviewers
15:59:56 <degorenko> ok, thanks
16:00:01 <EmilienM> we should target M cycle
16:00:05 <xarses> its not compliant, but it's the best working copy, and a large effort went in from relative folks to clean it up for upstream
16:00:19 <angdraug> time
16:00:23 <EmilienM> we also need to poke RDO & Ubuntu packages (even if you already have your own packages) so we can actually test your work
16:01:02 <EmilienM> oops
16:01:05 <EmilienM> #endmeeting