15:30:14 <j^2> #startmeeting openstack-chef
15:30:15 <openstack> Meeting started Fri Nov 21 15:30:14 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:30:19 <openstack> The meeting name has been set to 'openstack_chef'
15:30:25 <j^2> Hey everyone!
15:30:29 <libsysguy> o/
15:31:26 <j^2> There were a couple topics that we have on the agenda, libsysguy is there anything you’d like to add?
15:32:10 <libsysguy> nah, not really
15:32:21 <j^2> ok
15:32:30 <j^2> well i’ll jump right in then
15:32:48 <j^2> #topic Spitballing on a testing idea
15:33:05 <j^2> over this week i had a community member show up and ask some questions
15:33:11 <j^2> #link https://botbot.me/freenode/openstack-chef/2014-11-20/?msg=25847921&page=1
15:33:35 <j^2> he was setting up his cluster with our cookbooks and he had an issue that i don’t think we’ve thought about
15:34:05 <j^2> we’ve though about breaking out the network node, the compute nodes, but his issue was that he had a shared db that someone else used
15:34:17 <j^2> I think we should try to figure out a way to do remote testing with remote dbs
15:34:23 <j^2> but i have no idea how we could
15:34:27 <j^2> any thoughts on this?
15:35:15 <libsysguy> so mysql was already set up on a remote node?
15:35:22 <j^2> yeah
15:35:30 <j^2> he had another box that was owned by someone else
15:35:41 <j^2> and he was leveraging it for the db for his cluster
15:35:51 <j^2> i’m thinking this “would be pretty common?"
15:35:52 <j^2> right?
15:35:57 <libsysguy> yeah that is what I do
15:35:58 <libsysguy> well
15:36:04 <libsysguy> except I own the box
15:36:16 <libsysguy> but I keep mysql and rabbit on one box
15:36:20 <j^2> ah
15:36:27 <libsysguy> and the other controller fucntions on a different box
15:36:29 <j^2> i think i might be over thinking this though
15:36:42 <j^2> i think we should stay simple first?
15:36:44 <j^2> i’m not sure though
15:37:00 <j^2> this is where i’d hope markvan would pop up and start talking :)
15:37:11 <frickler> if we get a proper bug report for this, we should certainly fix it
15:37:24 <libsysguy> well as far as testing goes I am fairly useless
15:37:28 <frickler> but I wouldn't invest much into debugging this myself
15:37:39 <j^2> frickler: yeah but i’m not sure it’s a “bug” per-se it seems like another test case
15:38:02 <markvan> sorry, late to this show
15:38:06 <j^2> no worries :)
15:38:19 <frickler> once your multi-neutron is running, you could easily do another setup with a split-mysql
15:38:37 <frickler> if you want to build a testing environment for that case
15:38:44 <j^2> frickler: that seems like the path, but is that over engineering something though
15:39:04 <j^2> i mean then we could have no split on the mysql but with the rabbitmq box
15:39:11 <j^2> and then all the different databases
15:39:20 <j^2> i mean it could open up a HUGE can of worms
15:39:50 <frickler> yes, that why I would put it rather low on priority
15:39:56 <markvan> it's very common to have the DB on a dedicated or remote node, but not something we need to focus on for our integration testing
15:40:04 <j^2> i’m looking for feedback here, i’m leaning towards the “KISS” idea with the testing framework and maybe just mention this in the refarchs?
15:40:19 <j^2> ok cool
15:40:32 <j^2> i just wanted to bring it up to the group to make sure it was at  least talked about
15:40:33 <j^2> :)
15:41:12 <j^2> next topic?
15:41:13 <libsysguy> yeah I would agree (as an outsider) that it would be nice in a ref arch, but not so much in the integration tests
15:41:35 <j^2> libsysguy: :D awesoem tahnks, and no you’re an insider now, one of us one of us
15:41:47 <j^2> #topic Moving of this meeting
15:42:05 <j^2> frickler: mentioned this morning that we were supposed to have this yesterday….
15:42:17 <j^2> I take full responsibility for this not happening
15:42:40 <j^2> I’m proposing that we move this to thursdays as of two weeks from today
15:42:49 <j^2> Being next thursday is Thanksgiving in the US
15:42:52 <j^2> any objections?
15:43:00 <frickler> so next week no meeting at all?
15:43:07 <j^2> I’ll have the hangout though
15:43:21 <j^2> os-chef-bot: !status-meeting
15:43:21 <os-chef-bot> Our hangout (live) status meeting are at 15:30 GMT 10:30 EST 07:30 PST on Mondays and we post the links to the Google Group: https://groups.google.com/forum/#!forum/opscode-chef-openstack
15:43:29 <frickler> no IRC meeting I wanted to say
15:43:53 <frickler> or IRC on Friday next week?
15:43:57 <j^2> yep, i dont think we’d have a very good turn out and i’ll be….cooking most if not all of the day ;)
15:44:17 <frickler> k
15:44:18 <j^2> and friday is a huge shopping day in the US and i’ll be…..shopping
15:44:23 <j^2> :’(
15:44:28 <j^2> i hate shopping
15:44:31 <j^2> anyway i digree
15:44:33 <j^2> digress
15:44:57 <j^2> any objections to offically moving this meeting to thrusdays after the thanksgiving break?
15:45:45 <j^2> k, i’ll post something to the ML today to make this happen
15:46:19 <j^2> frickler: you have a few things you’d like to talk about; so i’ll let you have the floor from now on i’ll take some notes on the dicussion points if taht’s cool
15:46:28 <j^2> #topic frickler’s show
15:46:58 <j^2> could we start with: How do we properly handle blueprints? There is a specs-repo, but as long as on can create them directly via launchpad, this seems to mostly get ignored
15:47:18 <frickler> yes, this occured to me after I had created mine
15:47:29 <j^2> markvan: thoughts? :)
15:47:42 <j^2> libsysguy: you too ;)
15:48:01 <j^2> this also can go into the “storyboard” conversation, but that’s a different topic
15:48:49 <frickler> so my proposal would be to either make the specs-repo mandatory, or drop it again
15:48:55 <libsysguy> well I don't really like the blueprints process
15:49:03 <libsysguy> but either way it needs to be standard
15:49:11 <libsysguy> so I'm with frickler
15:49:54 <j^2> the challange with the blueprints is we have no discussion and/or history around it
15:50:02 <j^2> it’s just basicly a text box
15:50:21 <markvan> I guess I like the spec reviews, we just need to get used to using them.
15:51:14 <j^2> there really is no way to mandate this either, we can have an agreement, but anyone can still put in the blueprint and circumvent the process
15:51:24 <j^2> like frickler did
15:51:31 <frickler> how do other projects solve this?
15:51:34 <j^2> which highlights this
15:51:53 <j^2> nova-specs have a big enough team that they can enforce this
15:52:00 <frickler> I did this accidentally, read the mail about the repo only later
15:52:11 <j^2> we’re only a rag-tag group of devs trying to make this stuff work
15:52:13 <markvan> I think the other projects keep a mich tigher watch on the blueprints....and enforce the process from there.
15:52:26 <libsysguy> well if we are going full tote with the openstack process we should probably use the specs repo
15:52:35 <j^2> frickler: i’m not blaming you, i’m just restating the issue i guess in “my words?"
15:52:50 <j^2> libsysguy: there’s a flip side to this though
15:53:03 <j^2> the storyboard thing, openstack-infra offically moved to it
15:53:16 <markvan> Is there a blueprint template we could update to point to the spec repo, thus helping the process along
15:53:21 <j^2> i think there are parts and processes in it that can inforce the issues we’ve been having
15:53:38 <markvan> like we did with the Bugs
15:53:44 <j^2> markvan: not a horrible idea
15:53:57 <libsysguy> I am all for automatic enforcement
15:54:11 <j^2> have another page on the wiki for a “templatized blueprint” page?
15:54:35 <markvan> and yeah, storyboard is coming, but I think we can wait for the base projects to shake that tree first.
15:54:51 <libsysguy> link for storyboard?
15:55:00 <libsysguy> I think I missed that announcement from openstack-infra
15:55:00 <j^2> #link https://storyboard.openstack.org/
15:55:15 <j^2> libsysguy: yeah it was a tweet that i found out about the move
15:55:36 <j^2> i’m still trynig to figure out how to filter the emails that get blasted out
15:55:41 <libsysguy> so is this mimicking agile style storyboards?
15:55:50 <j^2> “yes?"
15:56:11 <j^2> but i guess this brings up the topic, would we want to start the process of moving to it?
15:56:31 <j^2> or like markvan says wait for the other groups to adopt
15:56:31 <markvan> and/or maybe we can set the Specification URL to required instead of optional?   Not sure what is configurable in the lanuchpad blueprint register page.
15:56:32 <libsysguy> if it is an official move on the part of openstack, I wouldn't be opposed
15:56:38 <libsysguy> but then again I like the bleeding edge
15:56:41 <frickler> so how about sticking with launchpad until we either go directly to storyboard or decide it takes too long to become useable?
15:56:48 <libsysguy> ^^
15:57:08 <j^2> markvan: yeah we can’t configure anything on launchpad iirc
15:57:41 <j^2> frickler: that’s the challange though, how do we know when that is, and how do we know about the migration process?
15:57:48 <j^2> i’ve got a feeling it might be a lot of work
15:59:28 <j^2> i mean we don’t have to have the desicion here right now, but i wanted to bring it up for people to think about
16:00:05 <markvan> since most of the base projects are still using spec/blueprint process for kilo, I thnk we should continue down that road as well and learn more about storyboard
16:00:16 <j^2> anyway, sorry, i kinda diverted the conversation, frickler would a templatized blueprint for specs help? would that fullfill your issue?
16:00:25 <j^2> markvan: sounds good
16:01:01 <markvan> humm, we already have a template for the specs, it just that we can't configure launchpad blueprints to enforce anything.
16:01:01 <frickler> mainly I want to clarify whether the specs-repo is optional
16:01:09 <markvan> is has to be done by the cores
16:01:22 <frickler> or whether thats the standard way for doing blueprints
16:01:43 <j^2> frickler: offically no it’s not optional per our decisions a couple months ago
16:01:57 <j^2> but it’s not enforced it seems
16:02:14 <frickler> o.k., so I'll try that next time
16:02:17 <j^2> :D
16:02:37 <j^2> your next topic was: There is an issue with "rake unit" if run twice in a row, because "berks vendor" will refuse to install the cookbooks into an existing directory.
16:02:54 <j^2> have you opened a bug on this?
16:03:04 <frickler> no, not yet
16:03:06 <j^2> markvan, libsysguy have you seen this also?
16:03:57 <j^2> yeah whenever i run the tests, i don’t use the rake file honestly, i run rspec spec
16:03:59 <libsysguy> I didn't have a problem running rake *test* twice yesterday on the neutron cookbook
16:04:03 <markvan> yup, I have seen that.  Seems like a bug to me as old berks did not do that.
16:04:22 <frickler> well it's a feature of the new berks, they say
16:04:29 <libsysguy> I also didn't let it run to completion
16:04:37 <j^2> interesting
16:04:51 <frickler> not to accidentally overwrite stuff
16:04:59 <markvan> humm, not sure on their intent here...it just makes dev slower if I have to grab cookbooks each time
16:05:08 <j^2> yeah frickler can you open the bug for it, and we can start championing this, hell maybe even send it upstream?
16:05:33 <j^2> frickler: agreed, i think this is so you don’t overwrite stuff
16:05:35 <markvan> Is there an option on verdor that would allow it?
16:05:38 <markvan> vendor
16:05:46 <j^2> markvan: i dont think so
16:05:54 <j^2> at least not that i know off the top of my head
16:06:24 <frickler> no, one has to rm_rf to berks_cookbook directory
16:06:50 <j^2> yeah there is no option in berks vendor for this
16:07:02 <j^2> this seems like a upstream bug then
16:07:13 <markvan> or we could wrapper this with our own check to just skip it if we think the cookbooks are up to date
16:07:37 <j^2> markvan: i thnk thats over engineering this, i’m betting others have seen this
16:07:42 <markvan> wow, they missed open source rule #1, everything needs an option.
16:07:49 <j^2> markvan: ha!
16:08:14 <j^2> but how about this, lets start small, frickler can you take the Action Item to write the bug report then we can start floating it around?
16:08:40 <j^2> please put in a good description of teh usecase too, so i can poke the berks devs about it
16:08:54 <frickler> o.k., will do
16:08:56 <j^2> iirc most/all of them work for chef now?
16:09:06 <j^2> :)
16:09:09 <j^2> thanks!
16:09:22 <j^2> so your last topic was: Can we do some cleanup regarding CHEF-3694 being done? Most of the warnings seem to come from upstream cookbooks, but I think there is some room for improvement here on our side
16:09:41 <j^2> i have idea what that CHEF-3694 is, can you tell us about it and i’ll look for the link?
16:10:00 <j^2> #link https://tickets.opscode.com/browse/CHEF-3694
16:10:24 <markvan> #link http://scottwb.com/blog/2014/01/24/defeating-the-infamous-chef-3694-warning/
16:10:24 <frickler> it is about cloning resources
16:10:46 <j^2> oh wow
16:10:57 <markvan> This is a great topic and it usually shows that a design needs some improvement.
16:10:57 <j^2> i completely gloss over this now-a-days
16:11:01 <frickler> when I do a chef-client run, the log gets spilled with these warnings
16:11:05 <j^2> yep
16:11:14 <markvan> And yes, we have quite a few in our own cookbooks to deal with
16:11:18 <frickler> and I want to get rid of them, because they may hide interesting stuff
16:11:30 <markvan> ^ +1
16:11:51 <j^2> nice
16:12:05 <j^2> ok, so we can start the process of cleaning this up?
16:12:30 <j^2> i’ll need to read that link that markvan just linked to, and i think we should all look to help out here
16:12:38 <j^2> no?
16:12:42 <frickler> so I would say do a blueprint where we can collect the places where this happens
16:13:06 <j^2> heh, don’t you mean a spec? :P
16:13:12 * j^2 runs
16:13:49 <markvan> humm, yeah I guess this is really not a bug, but a poor design somewhere, so a spec/bp would be right path.
16:13:49 <j^2> in this case yeah identifing this issue in a centralized location is a great idea
16:14:07 <markvan> But the spec/bp and be fairly generic
16:14:16 <frickler> and it will be tedious
16:14:35 <j^2> i’m seeing a list of the effected cookbooks and the general line numbers of the effected areas
16:14:42 <j^2> and just update it when you see it
16:14:54 <j^2> and someone takes ownership of fixing that mess?
16:14:57 <frickler> but once we have some progress in our own cookbooks, it will be easier to nag the upstream cookbooks about it
16:15:05 <j^2> frickler: agreede
16:15:16 <markvan> I was think more high level then even that, just here's the issue with the links above, and maybe one example of it, and then cover the rest as we go.
16:15:59 <frickler> yes, just have something consistent to reference from the patchsets
16:16:14 <markvan> I think the network cookbook will be a challange for this type of change...
16:16:23 <j^2> and have “partial fix” in the commit message so it hooks back to the issue?
16:16:39 <j^2> so when we fix it it’s tracke?
16:16:44 <j^2> tracked*
16:16:59 <markvan> for blueprint, I think you use "Implememets"
16:17:15 <markvan> (wow can't speel or tpye today)
16:17:30 <j^2> so maybe then we should have it as a bug?
16:17:36 <j^2> it would be faster that way right?
16:17:56 <j^2> it’s been a while since i’ve looked through the bugs to be honest
16:18:16 <j^2> oh nice only 30 open :)
16:18:32 <j^2> yeah the more i thnk about it a bp isn’t the correct answer here
16:18:40 <j^2> it’s not a design, it’s a refactor
16:18:52 <j^2> and you refactor to reduce bugs right?
16:18:57 <markvan> Yeah, we could go the Bug route and use the "Partial-Bug: #"
16:19:21 <j^2> granted this is a very symantic conversation, as long as it gets done right?
16:19:46 <markvan> I try to go thru bug list once a week to see what's new and what's getting way old
16:20:23 <j^2> frickler: has this covered what you’d like to dicuss? I’d like to make sure that we’ve hit all the major points?
16:20:32 <j^2> 10 mins btw :)
16:20:55 <frickler> yep, fine for me and I'm also through with my collection now :)
16:21:03 <j^2> awesome
16:21:10 <markvan> I had one other small topic
16:21:12 <j^2> #topic General Discussion
16:21:18 <j^2> markvan: go ahead
16:21:32 <markvan> #topic supermarket cookbooks
16:21:37 <j^2> i’m a piseces, i do sometimes like long walks…oh you’re not asking that...
16:21:49 <j^2> markvan: oooohhh mark you’re killing me
16:22:01 <j^2> yeah we cant upload ours to the supermarked
16:22:08 <libsysguy> oh?
16:22:10 <libsysguy> why not?
16:22:22 <j^2> it requries ownership of the repo, and because stackforge does we cant
16:22:31 <j^2> and there are someother little things
16:23:07 <j^2> i’ve discussed this also with a couple people, including puppet people asking why we hadn’t and we just don’t have the ability
16:23:29 <markvan> I have seen some pull requests that look valid, but are going no where fast.  And these are fixes that impact our cookbooks.  Ref: https://github.com/kennonkwok/rabbitmq/pull/154
16:23:55 <j^2> oh ouch
16:24:14 <j^2> oh shit, this is Kennon from chef?
16:24:18 <markvan> What can be done to get those moved along....without the gerrit review process, seems like pull requests are very slow at times
16:24:18 <j^2> i’ll ping him asap
16:24:28 <j^2> no need, i’ll get on this
16:25:07 <markvan> is there a "recommend" way to help move these along....besides having inside contacts?
16:25:15 <j^2> just ping’d him :P
16:25:39 <j^2> markvan: that’s a great question, and i think that’s the downfall of OS software, it’s about people as much as code
16:25:48 <j^2> sometimes you just need to pester
16:26:12 <markvan> was hoping the supermarket would have some better oversight on these...
16:26:41 <j^2> that’s a great point
16:27:03 <markvan> (and since your chatting with him, I'll pile on: https://github.com/kennonkwok/rabbitmq/pull/148)
16:27:30 <j^2> done
16:27:51 <j^2> if he dosent get back to me today, i’ll start pestering :)
16:28:00 <j^2> it’s still early in PST
16:28:11 <markvan> Since we rely on these dependent cookbooks through out our openstack cookbooks, folks are seeing the great activity on our side, but become very frustrated on the supermarket side.
16:28:30 <j^2> that’s a great point
16:28:33 <j^2> it really is
16:28:42 * markvan step down from soap box
16:28:44 <j^2> i’m not sure on who/or what we can do about this
16:29:04 <j^2> i can hook you up with teh supermarket guys and maybe they have an answer? i dunno
16:29:28 <markvan> Yeah, getting them some direct feedback would be great, thx.
16:29:54 <j^2> cool, i’ll see what i can make happen
16:30:21 <markvan> btw, i think the switch from the internal opscode bug tracking to github issues has really slowed down some of the response times
16:30:49 <markvan> not sure why, maybe just to many projects out there...
16:31:02 <j^2> that’s interesting feedback, i actaully thought it was the opposite for my interactions
16:31:38 <markvan> that is for me, nice discussion today.
16:31:39 <openstackgerrit> Federico Gimenez Nieto proposed stackforge/cookbook-openstack-object-storage: Use cookbook_file resource for drive-audit.conf  https://review.openstack.org/136410
16:31:46 <j^2> ok, any last topics taht want to be discussed?
16:32:00 <j^2> going once?
16:32:09 <libsysguy> none from me
16:32:13 <j^2> going twice?
16:32:21 <frickler> not here either
16:32:24 <j^2> Thanks everyone!
16:32:27 <j^2> #endmeeting