15:00:12 <EmilienM> #startmeeting puppet-openstack
15:00:13 <openstack> Meeting started Tue Dec  8 15:00:12 2015 UTC and is due to finish in 60 minutes.  The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:17 <openstack> The meeting name has been set to 'puppet_openstack'
15:00:19 <mfisch> hola
15:00:22 <mwhahaha> hi2u
15:00:22 <EmilienM> #link agenda: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151208
15:00:24 <iurygregory> hello o/
15:00:33 <EmilienM> o/
15:00:41 <degorenko> hey o/
15:00:42 <skolekonov_> o/
15:00:45 <Vinsh> 0_o
15:00:54 <clayton> o/
15:00:58 <mkarpin> o/
15:00:59 <chem> o/
15:01:03 <mentat> o/
15:01:09 <_ody> o/
15:01:15 <_ody> (yawn)
15:01:21 <EmilienM> let's start by a couple of announcements!
15:01:28 <iurygregory> \o/
15:01:31 <EmilienM> #topic announcements
15:01:48 <EmilienM> this blueprint has been accepted: Enhance inifile option deprecations
15:01:53 <EmilienM> #link http://specs.openstack.org/openstack/puppet-openstack-specs/specs/mitaka/config-deprecation-for-inifile-provider.html
15:01:56 <richm> hello
15:01:57 <EmilienM> clayton: thanks for this work!
15:02:19 <EmilienM> another good news for the group, Sofer is now part of puppet-keystone core team! Well done :-)
15:02:26 <clayton> Congrats :)
15:02:29 <xarses> o/
15:02:34 <chem> thanks :)
15:02:38 <iurygregory> congrats chem
15:02:42 <jasondotstar> o/
15:02:55 <EmilienM> let's move
15:03:05 <EmilienM> #topic using reno for release note management
15:03:11 <EmilienM> I created this topic for discussion
15:03:30 <EmilienM> there is a project in OpenStack that is called "reno" and becomes the official way to write release notes"
15:03:37 <richm> chem: ++
15:03:55 <iurygregory> nice
15:04:05 <richm> RNaaS?
15:04:10 <EmilienM> I spent some time looking at it
15:04:12 <EmilienM> richm: lol
15:04:19 <iurygregory> hasuhasuahsu
15:04:28 <EmilienM> I see is 3 possibilities
15:04:54 <EmilienM> 1/ we use reno and enforce each contributions (bugfix, feature, etc) to also edit a release note YAML file
15:05:17 <EmilienM> 2/ we use reno and the release note YAML file can be updated later (by the contributor or someone else)
15:05:31 <EmilienM> 3/ we don't use reno and continue to manually write release notes
15:05:51 <EmilienM> the #1 will implies a lot of -1 at the beginning because people would not know they have to do it
15:06:03 <EmilienM> the 3/ is not really what is doing other OpenStack projects
15:06:08 <clayton> I'd vote for 1, with 2 as needed to fix things
15:06:20 <EmilienM> I propose we go to 2/ with good documentation so people can start contributing themselves
15:06:48 <EmilienM> clayton: if we go for 1/, I thought some people would get frustrated to have -1 for something they did not have to care before
15:06:48 <richm> +1
15:06:50 <iurygregory> i ike 1 but 2 is good
15:07:10 <clayton> EmilienM: I'm also ok with starting with 2 and the goal being 1 over time
15:07:10 <xarses> 2 seems good
15:07:24 <EmilienM> note: using reno is an heavy work too, and the automation is not magic, we need to write ONE yaml per bug, per feature, per useful thing in release note.
15:07:30 <EmilienM> dhellmann: iiuc ^
15:07:32 <clayton> I think it will probably take some practice to know what really needs release notes.  Not every change will
15:07:48 <mwhahaha> that sounds awful
15:08:04 <EmilienM> clayton: yeah, the goal would be 1/
15:08:13 <EmilienM> mwhahaha: what is awful?
15:08:18 <mwhahaha> the yaml thing
15:08:24 <xarses> I haven't looked at reno, but it seems like it should pull some of this out automatically out of well made commit messages
15:08:33 <clayton> if you work on puppet and you're not comfortable with yaml, you may have other issues :)
15:08:42 <EmilienM> example: https://github.com/openstack/nova/tree/master/releasenotes/notes
15:08:45 <mwhahaha> no the fact you have to create one for every bug, etc
15:08:49 <clayton> xarses the goal with reno was to have it be outside of commit messages, so that they can change later
15:08:52 <mwhahaha> not yaml itself
15:09:04 <mwhahaha> i'd assume it'd also be per puppet module as well
15:09:21 <xarses> clayton: thats, fine but maybe it should start there. some commit hook or something
15:09:22 <mwhahaha> so our updates of all the modules would result in a similar number of yamls
15:09:24 <EmilienM> I think, and that's my proposal: we should start looking in Mitaka for using it in one or two modules
15:09:25 <clayton> but that if you cherry-pick a change that includes a release note, that gets backported also
15:09:29 <EmilienM> doing 2/ method
15:09:35 <EmilienM> and see
15:09:44 <clayton> EmilienM: I think doing it for a limited number of modules is probably a good way to start
15:09:54 <mwhahaha> i don't think release notes should be part of the change itself, it would be better to parse the git log and add it after the fact
15:09:54 <_ody> wow really a new yaml file for every commit.  That is indeed horrible.
15:10:01 <iurygregory> it will be hard but we can do o/
15:10:05 <clayton> if we have good success there, we can move to #1
15:10:08 <EmilienM> _ody: hence the "heavy work" I was saying
15:10:16 <iurygregory> agree with clayton for a limited number of modules
15:10:26 <clayton> _ody: no, one file for anything that needs to be in release notes
15:10:26 <EmilienM> _ody: BTW, when I prepared stable/liberty, I spent 3 days reading commit messages
15:10:40 <mfisch> do other projects do a note on every commit?
15:10:41 <clayton> lots of changes won't be mentioned in release notes.
15:10:47 <EmilienM> mfisch: look the example on nova
15:10:57 <clayton> the idea is that this is supposed to be a summary, not a copy of the commit log.
15:10:59 <mwhahaha> would it be better to start enforcing a must have a bug/blueprint per change?
15:11:01 <EmilienM> it's very new so I think the adoption is not 100% here
15:11:14 <_ody> EmilienM: Which is why I prefer 1 over 2.  Spread the load.
15:11:14 <ntpttr> Cinder is just starting to adopt it
15:11:22 <mwhahaha> so we could parse that out to create the release notes
15:11:50 <EmilienM> _ody: 1/ is the final goal, sure. But we don't want to frustrate our contributors. We need a smooth transition
15:12:00 <_ody> clayton: How do we judge what is and isn't worthy of a release note? Just guess until we get the hang of it?
15:12:15 <mfisch> up to reviewers?
15:12:26 <EmilienM> yes
15:12:38 <clayton> _ody: I think so, we'll just have to develop an eye for it, and I suspect before releases we'd have a patch (or several) to fix the release notes where they don't make sense
15:12:40 <EmilienM> we are developpers, we know when we fix a bug or add a feature, isn't?
15:12:48 <clayton> but that's still better than spending 3 days reading lots and then still missing things
15:12:53 <clayton> s/lots/logs/
15:13:10 <EmilienM> clayton: ++
15:13:27 <EmilienM> so I see we have different opinions here
15:13:31 <iurygregory> +1
15:13:34 <EmilienM> I would follow-up on the mailing-list
15:13:48 <EmilienM> and involve Doug who is not here I guess ( dhellmann )
15:13:54 <EmilienM> maybe he has some thoughts
15:14:20 <EmilienM> I'll summarize thoughts here
15:14:28 <EmilienM> feel free to participate to the thread :-)
15:14:46 <EmilienM> we definitly need to find a way to maintain release notes
15:14:54 <EmilienM> that's a lot of time
15:15:06 <_ody> any chance the reno project provides a commit hook?
15:15:08 <EmilienM> and automation will help us to scale the number of our modules
15:15:23 <xarses> _ody: +1
15:15:27 <xarses> I was asking that too
15:15:35 <EmilienM> _ody: to do what?
15:15:41 <xarses> To me, thats the only way to make it bearable
15:15:57 <xarses> populate both the commit message and the yaml at the same time
15:16:08 <_ody> Seems pretty straight forward to write the yaml on commit just like "git review" does with change-id.
15:16:16 <clayton> I do not think the commit message and the release note should have the same content.  they have different audiences.
15:16:30 <EmilienM> clayton is right
15:16:43 <degorenko> +1
15:16:44 <EmilienM> release notes are read by users/operators also
15:16:45 <clayton> keep in mind here that the alternative right now is emilien continuing to do all of it.
15:16:47 <xarses> yes, but they can be writen at the same time
15:17:10 <clayton> there is nothing stopping you from doing them at the same time, in fact that's the preferred workflow
15:17:21 <clayton> that the release note yaml file be in the same commit that it describes
15:17:50 <EmilienM> the content of the commit message & the release note can be different, that's the point of clayton iiuc
15:17:59 <ntpttr> as someone who recently started contributing, I don't mind writing release notes for patches that would need them tbh
15:18:15 <EmilienM> ntpttr: good feedback
15:18:46 <mfisch> I think most changes would need a release note
15:18:52 <EmilienM> so if you don't mind, I'll follow a discussion on our mailing list, with a summary of our meeting thoughts
15:18:52 <mfisch> new fields, deprecations, removals
15:19:07 <EmilienM> probably using cross project tag
15:19:17 <EmilienM> [all] I mean
15:19:20 <mfisch> good idea
15:19:27 <EmilienM> I feel like we're not alone in this case
15:19:42 <EmilienM> before I end the topic, anyone has more thoughts?
15:20:01 <EmilienM> oki
15:20:17 <EmilienM> #topic open discussion / bugs-review triage
15:20:31 <EmilienM> like usual, feel free to ask for reviews
15:20:37 <EmilienM> or raise an outstanding request/bug
15:20:42 <EmilienM> we will be happy to help
15:20:50 <mfisch> I'd like to discuss my ML topic from yesterday
15:20:51 <chem> I have three long standing review
15:20:53 <mfisch> openstackclient
15:20:58 <chem> on keystone
15:20:59 <mfisch> chem: you go 1st
15:21:06 <chem> mfisch: thanks
15:21:19 <chem> it's about specific domain conf
15:21:30 <chem> they add feature, so no backward change
15:21:33 <EmilienM> #action EmilienM to follow-up on mailing-list about reno
15:21:48 <chem> https://review.openstack.org/#/c/202689/, https://review.openstack.org/#/c/219289/, https://review.openstack.org/#/c/238164/
15:21:55 <EmilienM> chem: where is release note? (joke)
15:22:08 <iurygregory> lol
15:22:10 <chem> they have been +1/+2 serveral time and rebase countless times
15:22:19 * _ody should have beaker bug fixes in soon
15:22:24 <_ody> They passed CI
15:22:24 <chem> release what ?
15:22:33 <chem> hehe
15:22:42 <chem> _ody: a long time ago :)
15:22:45 <mfisch> arg no commas in URLs even at the expense of grammar
15:22:58 <clayton> mfisch you need a better irc client :)
15:23:04 <_ody> chem: I meant my patches. ;)
15:23:16 <EmilienM> mfisch: stop using windows!
15:23:36 <iurygregory> kkkkkk
15:23:39 <xarses> EmilienM:  +1
15:23:41 <EmilienM> chem: thanks for adding the patches in our radar
15:23:42 <chem> that's it for me :) please help me to get rid of thoses rebases
15:23:54 <EmilienM> that's a lot of LOC, I guess it needs more time to review it :-)
15:24:04 <iurygregory> i'll try to review chem o/
15:24:14 <chem> thanks
15:24:25 <ntpttr> I wouldn't mind getting some eyes on this multiple store configuration in Glance once I go and fix the merge conflict - https://review.openstack.org/#/c/242718/ some feedback on if this is the correct way to deprecate these options while moving them to api.pp would be appreciated
15:24:44 <ntpttr> I can go ahead and fix the merge conflict after this meeting
15:25:26 <EmilienM> mfisch: IMHO, we should just use ensure_resource everywhere for this case
15:25:55 <EmilienM> so the resource can be multiple times in the catalog
15:26:02 <clayton> EmilienM: what if I want to set package_ensure to something other than the default?  I have to set it everywhere?
15:26:19 <mfisch> I think ensure_packages() in openstackclient class and everyone else just includes it
15:26:45 <clayton> that works for me.
15:26:47 <EmilienM> clayton: in that case we need the conditional and use ::openstacklib
15:26:52 <iurygregory> +1
15:26:56 <EmilienM> yeah, +1
15:27:06 <mfisch> conditionally include it like keystone does now?
15:27:10 <clayton> I don't think we should be managing the resource in 25 different places
15:27:19 <EmilienM> clayton: did you have time to start a PoC of your blueprint?
15:27:21 <clayton> they should just include ::openstacklib::openstackclient
15:27:36 <EmilienM> clayton: yes, +1 with that
15:27:44 <mfisch> so the vote is to conditionally include it like https://github.com/openstack/puppet-keystone/blob/master/manifests/client.pp#L20-L26
15:27:48 <mfisch> or just include it bare
15:27:51 <clayton> No, I've been too busy with docker, docker, docker.
15:28:06 <clayton> mfisch: bare
15:28:10 <clayton> no conditional
15:28:29 <mfisch> lol ok I agree
15:28:30 <EmilienM> bare looks fine
15:28:36 <mfisch> hah
15:28:49 <EmilienM> I haven't found time to start looking at multi node jobs
15:28:59 <mfisch> bare means that everyone will need to use hiera to control openstack client
15:29:24 <mfisch> but its cleaner
15:29:30 <EmilienM> degorenko: what is the status of having Fuel CI gating our modules?
15:29:45 <degorenko> EmilienM, it is already implemented :)
15:29:49 <clayton> mfisch: I'm +1 on that for now
15:30:00 <mfisch> clayton: oh sorry, I misunderstood you when you said "no conditional" I read it as "no, conditional"...  I will add it bare
15:30:06 <EmilienM> degorenko: I mean, having Fuel jobs in our CI
15:30:11 <clayton> we can talk about other approaches later if we actually run into problems with that approach
15:30:24 <degorenko> EmilienM, oh, for our modules
15:30:25 <mfisch> need a review on the main fix: https://review.openstack.org/#/c/254502/
15:30:36 <degorenko> i think it's not started yet
15:30:42 <EmilienM> degorenko: ok
15:31:01 <xarses> EmilienM:  I'll add a topic to the Fuel IRC meeting for it
15:31:04 <EmilienM> I need review on https://review.openstack.org/252562 and final +A on https://review.openstack.org/252026 https://review.openstack.org/252003
15:31:05 <degorenko> EmilienM, i will raise this question in our fuel weekly meeting
15:31:21 <EmilienM> degorenko, xarses: thx guys
15:31:24 <degorenko> xarses, go 1st :)
15:31:47 <EmilienM> clayton: is it good time to discuss about keystone/eventlet drop ?
15:31:53 <clayton> sure
15:32:05 <EmilienM> I think the first question to me is:
15:32:06 <clayton> that's related to work I started yesterday :)
15:32:17 <EmilienM> should we still allow people to deploy eventlet in our mitaka cycle?
15:32:30 <degorenko> we have one old patch: can you guys review it please: https://review.openstack.org/#/c/220224/
15:32:33 <EmilienM> or follow keystone and drop it
15:32:33 <clayton> I don't think that's actually the right question
15:32:47 <clayton> EmilienM: what you're calling "eventlet" is actually "the way the distro packaged it"
15:32:56 <clayton> which may or may not be eventlet, especially if eventlet is dropped
15:33:21 <clayton> running service keystone start might start it under uwsgi, or nginx, or something completely different
15:34:31 <EmilienM> clayton: ok
15:34:50 <EmilienM> clayton: so I guess we don't have much to change then
15:35:03 <clayton> I'd be willing to rework the existing "eventlet" and apache support to both run under the hooks model I did for designate, heat and nova (under review)
15:36:27 <EmilienM> clayton: nice
15:36:47 <EmilienM> anything else for today?
15:37:36 <mfisch> we should consider canceling the meeting xmas week
15:37:37 <EmilienM> ok
15:37:47 <EmilienM> mfisch: or invite santa claus
15:37:49 <mfisch> and even the week after perhaps
15:37:49 <EmilienM> santa cloud?
15:37:53 <degorenko> :D
15:37:59 <EmilienM> I'll not cancel it but rather invite Santa Cloud
15:38:03 <mfisch> santa is still working on keystone v3
15:38:03 <iurygregory> hsaushaush good idea
15:38:07 <clayton> action, emilien to dress up as santa and give out presents?
15:38:09 <EmilienM> joking, ok let's cancel it
15:38:13 <EmilienM> clayton: YEAH !
15:38:28 <EmilienM> #action EmilienM to dress in Santa Claus for Christmas
15:38:32 <EmilienM> have a good day folks!
15:38:34 <EmilienM> #endmeeting