15:30:21 <j^2> #startmeeting openstack-chef
15:30:22 <openstack> Meeting started Fri Sep 26 15:30:21 2014 UTC and is due to finish in 60 minutes.  The chair is j^2. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:30:25 <openstack> The meeting name has been set to 'openstack_chef'
15:30:30 <j^2> #chair markvan
15:30:31 <openstack> Current chairs: j^2 markvan
15:30:37 <j^2> Hey everyone!
15:30:50 <markvan> Howdy
15:31:40 <j^2> I only have two topics that i'd like to discuss, unless there are anything outstanding that anyone would like to bring up?
15:32:00 <j^2> jklare: has one that i'm going to relay
15:32:19 <j^2> and the second one is about versioning from an issue we saw yesterday
15:33:08 <markvan> j^2: my main topic for this week is trying to figure out a way around the rebase for Changelog I keep hitting.
15:33:23 <j^2> cool, got that on the agenda
15:33:30 <markvan> and that we still have a high backlog of patches/bugs/specs to review
15:33:41 <j^2> though we have started purging our Core list
15:33:51 <markvan> review actions notes from last meeting first?
15:33:58 <j^2> ohh! that's the third thing, ideas/suggestions for new core reviewers
15:34:03 <j^2> markvan: yep, sounds good
15:34:38 <j^2> hmmm
15:34:39 <j^2> http://eavesdrop.openstack.org/meetings/openstack-chef/2014/
15:34:43 <j^2> there arent any notes there
15:35:09 <j^2> ah my bad: http://eavesdrop.openstack.org/meetings/openstack_chef/2014/
15:35:35 <j^2> last meeting notes: http://eavesdrop.openstack.org/meetings/openstack_chef/2014/openstack_chef.2014-09-19-15.30.html
15:35:38 <j^2> #link http://eavesdrop.openstack.org/meetings/openstack_chef/2014/openstack_chef.2014-09-19-15.30.html
15:35:47 <j^2> #topic Previous Action Items
15:36:17 <markvan> I did create a spec for the Chef 11.16 bump here: https://review.openstack.org/#/c/122817/
15:36:57 <markvan> For git rebase, I started a ML thread https://groups.google.com/forum/#!topic/opscode-chef-openstack/1uLa1g8Q4ok
15:37:24 <markvan> It appears for me that just adding blank lines in between Changelog entries avoid the rebase issue for the most part.
15:37:38 <j^2> jklare: did you do any research on the rebasing yourself?
15:37:51 <j^2> markvan: hey if that's the quickest fix i'm good with that
15:37:55 <markvan> Would like to get feedback/approval to start doing it that way as I don't think it can hurt anything if not 100% correct.
15:38:04 <jklare> yeah i tried to reproduce what mark did with the newlines
15:38:09 <jklare> also found this git rerere
15:38:41 <jklare> but after some talking to coworkers i guess that maybe we a are doing it wrong
15:38:44 <markvan> jklare: yeah, I have not had a chance to look at that yet
15:38:56 <jklare> maybe we should autocreate the changelog
15:39:11 <jklare> i think mark and me talked about that at the beginning of this week
15:39:16 <j^2> that brings us into the next conversation then i guess :)
15:39:30 <markvan> jklare: yup, that would be the next step...or just remove it all together and create once one the stable branches only
15:39:40 <jklare> i really liked the idea of this post-commit hooks
15:39:54 <jklare> but not sure if thats what we want
15:39:59 <j^2> you cant mandate post-commit hooks, hooks for that matter though
15:40:57 <j^2> it would be nice though to have the bots do the work for us
15:41:37 <markvan> yup, some automation is always good, bt I don't see that happening right away.   so, I'm suggesting we try the extra lines for a while and go from there.
15:42:25 <jklare> sounds like a valid temporary solution
15:42:35 <j^2> any opposed to the blank lines?
15:43:06 <j^2> sounds good
15:43:25 <j^2> #topic discussion about auto generating configs from attributes
15:43:41 <j^2> jklare: we’ve already touched on this
15:43:54 <j^2> but would you like to propose what you think we should do completely?
15:44:25 <jklare> i think right now we are having a lot of commits just for the sake of making things from the configs configurable
15:44:34 <emagana> I have a few questions that I want to discuss in this forum, please let me know when will be the right time!
15:44:35 <jklare> we always have to change  at least 3 files
15:44:48 <j^2> emagana: certianly, give us a bit :)
15:44:52 <jklare> and i do not think that thats optimal or needed
15:45:15 <jklare> i think it should be possible to autogenerate the most common configs from the attributes
15:45:49 <jklare> in the end all the information is already in hashes
15:45:58 <jklare> and just needs to be picked from the attributes file
15:47:12 <j^2> if i recall correctly there was talk at the Ops meetup about this also, let me see if i can find the ether pad on how we think we should fix this problem
15:47:21 <j^2> #link https://etherpad.openstack.org/p/SAT-ops-chef
15:48:14 <jklare> so i think the config templates should contain some logic to build up a valid config from those attributes or we should skip these templates completely and do the autogenerate in some methods in our libraries
15:48:53 <j^2> there was some disucssion about: Possibility of using tox filter to generate templates this seems like a great idea
15:49:01 <j^2> wouldnt that help is this situation
15:49:31 <j^2> that was a question, sorry :P
15:49:51 <jklare> maybe it will
15:50:10 <jklare> i will have to look into that
15:50:29 <j^2> leveraging tox to create the standarized templates, take it out of chef apart from some overrides or what not? (it’s just an idea not a solution  atm)
15:50:39 <markvan> We have some attributes that are simple and basically "flow thru" to the template.   But there ar emany others that are processed or would need some type of handler.
15:50:50 <j^2> then we become more inline with “core” openstack?
15:51:44 <markvan> And the other issue I have been hitting lately is that we have almost NO support for the actual conf file format, where [sections] are a becoming more important.
15:52:17 <j^2> i have to admit though, there are a lot of patches coming in that seems superfluous when adding an attribute that defaults to nil, that seems like it should already be there and we dont have to code it in. but that’s my opinion :)
15:52:59 <j^2> markvan: that’s a great point
15:53:13 <markvan> Yes, the concept of having default values or nil dates back from the beginning.
15:53:40 <j^2> ah
15:53:50 <j^2> ok, i won’t go after that gorilla…yet.
15:54:13 <markvan> What I don't like about using nil (when base has a valid default) is that it requries ugly if/check logic in the template.   I think that we should extend the chef template code to better handle that for us.
15:54:24 * j^2 looks menacing
15:54:30 <jklare> but that gorilla is the core of it i guess
15:55:04 <jklare> i think we do not really need that if statement, a config option without a value will do nothing even if its there
15:55:12 <markvan> yup, since the base is moving away from even sample conf files, and you can gen your own from the source...we should be able to leverage taht somehow.
15:55:42 <j^2> ok, sorry guys, but we are hitting time for this discussion, there are a couple other things i’d like to discuss and we have a community member that would like to ask a couple questions too. Next topic?
15:55:56 <markvan> jklare: good point, but in the beginning I think we saw some issues with that in some template, but don't recall.
15:56:21 <jklare> i think we can continue that discussion on monday
15:56:21 <j^2> this obviously needs much more discussion :)
15:56:22 <markvan> sure, maybe we take this on to ML for a while
15:56:42 <j^2> lets start with monday then if it continues (which it probably will, move to ML)
15:56:48 <markvan> k
15:56:51 <jklare> k
15:57:04 <j^2> #topic Versioning Discussion
15:57:27 <j^2> I’d like to just open this up real fast, becase well markvan  and i ran into this and wanted to make sure it was captured
15:57:51 <j^2> Should the Berksfile.lock/Gem.lock on stable/icehouse require a bump?
15:58:10 <j^2> I say yes, we should get someone to update the wiki to explicitly say that.
15:59:29 <j^2> thoughts?
15:59:55 <markvan> I think yes as well here as stable hits are important to track in the versions.    Now what level?  How big of impact was change?
16:00:58 <j^2> I’m thinking this should only be a x.y.Z update. it is _just_a_patch_ right?
16:01:10 <jklare> i think all changes to stable should do a version bump
16:01:48 <j^2> #info all changes to stable should be a version bump, agreed by jklare markvan j^2
16:01:51 <markvan> just an example of the grief this could cause someone....if berks or gem pulls in new items, some folks have to update their env's/product with test and legal approvals.  so might consider a x.Y.z bump
16:02:08 <j^2> good point
16:02:35 <j^2> i really am at a loss here
16:02:46 <j^2> another discussion for monday?
16:03:03 <markvan> And we don't know the amout of change that an external dep could have had...so be safe and use minor version bump.
16:03:23 <j^2> i guess i could be ok with this
16:03:51 <j^2> jklare: thoughts?
16:03:59 <j^2> @core thoughts on this?
16:04:00 <os-chef-bot> @core thoughts on this?
16:04:00 <jklare> i go with mark here
16:04:02 <markvan> bumping patch level is when it's obvious it has very little impacts to anyone besides fixing a bug.
16:04:10 <jklare> at least a minor bump
16:04:22 <jklare> and depending on the impact of the update maybe more
16:04:39 <j^2> #info MINOR version when you add functionality in a backwards-compatible manner
16:04:55 <j^2> #info PATCH version when you make backwards-compatible bug fixes.
16:05:05 <j^2> #link http://semver.org/
16:05:11 <jklare> at least patch i meant
16:05:13 <jklare> sry
16:06:05 <j^2> I see marks logic, but if we are pushing semver it seems that it should be patch. Hence my hesitation/confusion. This is one of those grey areas yeah?
16:06:07 <markvan> yeah with touching berks/gems the extent of change could vary greatly....so case-by-case basis?
16:06:17 <j^2> markvan: that’s even worse :’(
16:06:23 <jklare> i think we can go with the standards
16:06:43 <j^2> ok, lets bring it up on Monday
16:06:50 <j^2> next topic
16:07:01 <j^2> #topic General Discussion
16:07:07 <j^2> emagana: you have some questions for us?
16:07:16 <emagana> j^2: Yes!
16:07:38 <emagana> What is the right forum to send questions regarding chef deployments
16:07:42 <emagana> T\
16:08:00 <j^2> can you give us an example of your question?
16:08:47 <emagana> My team is facing some issues with the all-in-one deployment with CentOS 6.5. For instance, Horizon shows Floating IP errors and we are not able to login with a new created user if that user is not an admin
16:09:16 <emagana> I believe the Neutron cookbook is broken because we have 404 errors when calling the routers API
16:10:33 <emagana> I mentioned before, I am leading a very serious effort of deploying OpenStack Icehouse on CentOS6.5 with HA for production! Not able to getting the stable/icehouse cookbook and deploy successfully a All-in-one system.. its scary!
16:10:36 <emagana> Help!
16:10:38 <emagana> :-)
16:10:50 <j^2> Here would be probably the “better” place to ask this type of question, or the mailing list at https://groups.google.com/forum/#!forum/opscode-chef-openstack but a lot of people have very different setups which is the beauty and *cough*pain*cough* of leveraging chef
16:11:25 <j^2> so it seems that neutron is the main culprit?
16:11:45 <j^2> do you have stacktraces/chef converges that you can gist them so we can take a look?
16:12:40 <j^2> emagana: when it comes to stable/icehouse my singlestack build hase nova networking running with centos6.5 leveraging chef-metal if that’s any help
16:12:58 <emagana> well, we dont want to use nova-network
16:13:03 <j^2> the singlestack build is the evenutal acceptance test framework
16:13:19 <emagana> j^2: is there any CI with Neutron running?
16:13:27 <j^2> ah, there is a neutron build too, it starts everything up but fails on something that i havent figured out on
16:14:16 <j^2> emagana: not that i know of, something our community has/is lacking in true acceptance/integration testing, I’ve taken that on my shoulders and am making progress, slow, but progress
16:14:31 <emagana> j^2: nice to hear!
16:14:59 <emagana> j^2: I will be posting the logs here
16:15:14 <j^2> awesome thanks, any more info would always be more helpful :)
16:15:16 <emagana> hopefully we can help to get the networking issues fixed
16:15:41 <emagana> The fact that nobody else is reporting those issues means that few people is testing properly
16:15:55 <markvan> j^2: thx for the efforts, any progress in CI front is great news!
16:15:57 <emagana> we need a campaign in favor of CHEF!!
16:15:59 <j^2> totally, we (the community) want you to succeed
16:15:59 <emagana> :-)
16:16:47 <MrMonkey> current Berksfile appears to have issues "Unable to satisfy constraints on package openstack-ops-messaging due to solution constraint"
16:16:54 <j^2> markvan: :D thanks yep, i’m almost ready to start putting it together and explaining it to people, but not quite yet. It’s 3rd on my priority list out of like a billion :P
16:16:56 <MrMonkey> is this part of versioning discussion?
16:17:05 <markvan> Actually as j^2 stated, we are using this internally, but again have a slightly different setup  (DB2, qpid, multi nics, multi nodes)  with success.
16:17:30 <j^2> MrMonkey: not exactly, can you give us more context?
16:17:56 <j^2> MrMonkey: what branch/what version is it trying to pull down? etc?
16:18:32 <MrMonkey> j^2, just did a clone of openstack-chef-repo.  on master branch 'berks vendor' fails as above
16:18:57 <j^2> MrMonkey: ah yes, it’s out of date at the moment. please use my singlestack build instead for stable/icehouse
16:19:14 <MrMonkey> pretty sure it worked last week
16:20:01 <j^2> emagana: just to tie off my train of thought, i’m very much in the mindset of leting the automated testing do the work for us, the challange is getting the automated testing up and running so then all we have to do is hack on code and let the bots do the confirmation for us :)
16:20:25 <emagana> j^2: let me know if we can help
16:20:35 <j^2> MrMonkey: berks vendor is markvan correct me if i’m wrong here, Berkshelf 3.x and chef-repo was 2.x right?
16:20:47 <j^2> or something to that effect
16:20:54 <j^2> emagana: totally, thanks for the offer
16:22:05 <j^2> One last thing for the offical meeting
16:22:09 <markvan> yup, repo at master has not been updated in a while
16:22:22 <j^2> #topic Core-Reviewers
16:22:39 <j^2> I sent out an email to the core-reviewership
16:22:59 <j^2> we have had some people step down, which was expected, and we thank them for their work and help
16:23:28 * MrMonkey hopes he did not interrupt irc meeting
16:23:31 <j^2> I’d like to open it up to the community, are people interested in becoming core-reviewers?
16:23:53 <j^2> MrMonkey: no problem :) i just wanted to make sure this was captured :) we can continue yoru discussion after :)
16:24:32 <j^2> If you are interested please don’t hesiate to ping me either here or jj@getchef.com if you have questions also
16:25:08 <j^2> markvan: am i forgetting anything?
16:26:22 <markvan> j^2: no, that was good start for core list.  I don't have anything else right now....except for my patch backlog to nurse along.
16:26:35 <j^2> #topic End of meeting
16:26:56 <j^2> To markvan’s point, yes we need more +1’s and people looking at our backlog
16:27:05 <j^2> if you have time please take a look
16:27:17 <markvan> yup, the more eyes the better....
16:27:37 <j^2> We’ll probably continue discussing a lot of this stuff again on Monday with the live status meeting, so if you can make it please do
16:27:44 <j^2> os-chef-bot: !status-meeting
16:27:44 <os-chef-bot> Our hangout (live) status meeting are at 16:30 GMT 11:30 EST 08:30 PST on Mondays and we post the links to the Google Group: https://groups.google.com/forum/#!forum/opscode-chef-openstack
16:28:52 <j^2> i’m willing to move it if there is a better time to get a larger group of people, please contact me at jj@getchef.com if you would but cant make it because of something like a *cough*scrum*cough*
16:29:12 <j^2> any other final words that need to be captured?
16:30:18 <j^2> awesome, thanks for everyone being here!
16:30:22 <j^2> #endmeeting