15:30:22 <j^2> #startmeeting Openstack-Chef
15:30:23 <openstack> Meeting started Thu Jan 22 15:30:22 2015 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:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:30:26 <openstack> The meeting name has been set to 'openstack_chef'
15:30:38 <j^2> Hey everyone!
15:30:44 <zhiwei> hi
15:31:07 <markvan> Howdy all!
15:31:31 <j^2> :D
15:32:23 <j^2> The agenda is pretty light, so zhiwei i’ll let you have the floor and discuss issuses
15:32:34 <j^2> #topic zhiwei’s topics
15:33:01 <zhiwei> thanks
15:34:50 <zhiwei> I just found an issue, there is no default passwords when set use_databags to false.
15:35:49 <j^2> i think that’s by design
15:36:17 <j^2> if you set use_databags to false, you should be using “debug_mode” or whatever it’s called so you don’t have any
15:36:35 <libsysguy> developer_mode = true I think
15:36:41 <j^2> https://github.com/stackforge/openstack-chef-repo#databags
15:36:45 <zhiwei> dev mode will be dropped.
15:36:45 <j^2> yeah developer_mode
15:37:27 <markvan> I think there's been a chnage of heart for developer mode....seems like it's still useful, or something like it.
15:38:05 <zhiwei> I think adding the use_databags to false is to replace the dev mdoe.
15:38:37 <zhiwei> and for now the dev mode and use_databags conflicts with each other.
15:39:24 <markvan> humm, use_databags false I thought meant that you went down the attribute path for passwords, which is valid for some folks.  Where as dev mode is strictly for hacking
15:40:25 <zhiwei> use_databags = false need below attribute openstack.secret.key.type = password.
15:40:42 <zhiwei> and dev_mode = true need  openstack.secret.key = password.
15:41:16 <zhiwei> so, if you set use_databags, the openstack.secret.key = {type=> password}
15:41:41 <j^2> i think i follow, that makes sense
15:42:27 <zhiwei> may i ask a question? why use openstack.secret.key.type not openstack.secret.type.key?
15:43:19 <j^2> probably because the original dev wrote it that way and no one bothered to change it ;)
15:43:44 <zhiwei> yeah.
15:43:48 <markvan> the dev-mode = true is probably used by most folks without any attributes.  that dev_secret method was added to allow further hacking dev passwords, but not sure if anyone uses it.
15:44:29 <zhiwei> I think we will remove dev-mode in Kilo, is it?
15:45:07 <markvan> I'm thinking we have other items to worry about, and that would be way down on the list and easily pushed out or never done.
15:45:15 <zhiwei> and as Mark said before, there are more than one services use admin as user name. this will cause all services with the same uesrname must have the same password.
15:45:42 <j^2> yeah i like the idea of removing dev-mode, hell the testing-stack has default passwords in the databags for you and you can always change them for a real deployment if you want
15:46:49 <zhiwei> maybe we can discuss this later. But I just want to make sure in stable/juno branch the use_databag = false can work properly.
15:47:06 <zhiwei> with default attributes and value.
15:47:09 <markvan> yup, but your right zhiwei even with databags as they are today, we have the issue of name collisions, so can't have different passwords for same user names.  That issue I would like to see fixed.
15:49:09 <j^2> do we have a bug reported on this?
15:49:23 <j^2> with examples/links to places in the code to referance?
15:49:55 <zhiwei> I remember Mark had report a bug.
15:50:27 <j^2> awesome, can we link it here?
15:50:42 <zhiwei> https://bugs.launchpad.net/openstack-chef/+bug/1399076
15:51:13 <j^2> thanks
15:51:37 <zhiwei> I also opened a bug about the default attributes when not using databags: https://bugs.launchpad.net/openstack-chef/+bug/1413522
15:52:02 <zhiwei> should we solve this before Kilo branch?
15:53:31 <j^2> i don’t think so
15:53:39 <zhiwei> ok
15:53:55 <j^2> i think it should be a stretch goal, we have can have review in, but i don’t think we should make it a requirement
15:54:06 <zhiwei> are there any other import thing before Kilo release?
15:54:32 <markvan> humm, I think this was discussed before, about having default passwords set and the group decided no, the user can setup those attrs as needed.
15:55:20 <zhiwei> ok, I am ok for this.
15:55:22 <markvan> Is there a strong requirement to have default ones when not using databags?    Just like databags, you have to crate and put them somewhere.
15:56:01 <zhiwei> I just want to make it easy to deploy a test/dev environment.
15:56:10 <markvan> Maybe we could add a bit more doc around this databag-less topic to make that easier to do
15:56:47 <markvan> so, I would consider your patch something that should go int othe cookbook repo, or jj testing suite, ust like his databags
15:57:31 <zhiwei> ok, i will close that bug.
15:57:58 <markvan> or just switch your patch to update the repo or testing suite.
15:57:59 <j^2> yeah that’s why i created the databags with the key on the testing-stack
15:58:14 <j^2> it’s a good way to deploy over and over
15:58:14 <markvan> it's still a valid issue for testing/dev
15:58:57 <markvan> yup, I really like that you took the time to build up the databags in the testing suite as that still is the main path for password use
15:59:28 <zhiwei> ok, I will.
15:59:32 <markvan> so, adding attribute for databag-less also seems very reasonable and will help with good examples
16:02:15 <j^2> cool, so i’d like to open it up to anyone else now
16:02:25 <j^2> #topic General Discussion
16:02:33 <markvan> #topic blueprints
16:02:46 <markvan> just a quick plug about blueprints
16:03:28 <markvan> We have a couple spec's out there to review, please help out with that (add that project to your watched list).
16:03:53 <j^2> cool, will do
16:03:56 <libsysguy> yup
16:04:22 <markvan> And we need to start cleaning up the list of active blueprints in launchpad.  Please review that list and if your an owner, adjust your status as needed or add comments to others that you can help with
16:04:52 <zhiwei> ok
16:05:18 <markvan> We're looking for progress, and if you have a strong opinion on which branch is can be targeted for.  Right now we are really trying to close out Juno, so will push them to kilo unless given a good reason
16:05:50 <markvan> #topic Juno and redhat 7 support
16:06:01 <markvan> of just a quick comment on this.
16:06:38 <j^2> Juno is an LTS support, we will have to do it, but it requries a huge reswrite of at least 3-4 cookbooks
16:06:53 <markvan> I believe we have decided that redhat 7 support is wanted for juno, but we have priortized ubuntu14 ahead of that for now.
16:07:18 <j^2> mostly focused around mysql and the mysql 6.0.0 cookbook and the way that there isnt a mysql_service resource anymore and how the actual service is created
16:07:56 <j^2> so we’ll have to backport this; i don’t think we can realistticly get this done fro the cut
16:08:10 <markvan> yes, with redhat 7, we could use the mariadb?
16:08:14 <j^2> yep
16:08:25 <markvan> and yes, So, while we accept redhat 7 patches if they don't mess up the ubuntu 14 goal for the stable branch.
16:08:27 <j^2> but mysql 6.0.0+ knows that, and installs it correctly
16:08:54 <markvan> And then as jj stated we can hopefully get a few good backports to stand up juno stable on redhat 7.
16:09:07 <j^2> yeah and the problem is we’ll have to get mysql 6.0.0+ cookbook working with ubuntu14 before we even think about centos7
16:09:17 <zhiwei> we should use mysql 6+ in Juno if it can correctly use mariadb.
16:09:59 <j^2> zhiwei: agreed, but this is both the version of mysql AND the cookbook: https://github.com/chef-cookbooks/mysql
16:10:14 <j^2> as you can see the cookbook is in “chef-cookbooks” now
16:10:16 <j^2> not opscode
16:10:27 <zhiwei> yeah
16:10:44 <j^2> it’s one of the “blessed” cookbooks wit hthe way we are going to start writing the resource and providers to create resources for everything
16:11:28 <markvan> humm, so this cookbook will handle ubuntu 14 correctly, but we need changes on our side?
16:11:42 <zhiwei> It does not address forks or value-added repackaged MySQL distributions like Drizzle, MariaDB, or Percona.
16:11:53 <zhiwei> https://github.com/chef-cookbooks/mysql#scope
16:13:06 <zhiwei> it has package_name parameter.
16:13:29 <zhiwei> so we can use the RP in our recipes
16:13:34 <j^2> markvan: the mysql_service we call which flusdes the db and crap like that
16:13:41 <j^2> we’ll have to rewrite alot of set up
16:14:17 <markvan> yeah, we have some old hacky code in there, hopefully most of it just gets deleted
16:14:40 <markvan> what did you use to get the testing suite to work on ubuntu 14?
16:15:29 <j^2> honestly:
16:16:07 <j^2> https://github.com/jjasghar/chef-openstack-testing-stack/commit/0863abc61d3030e49b07ddfc5060fb2bf7433282
16:16:12 <j^2> https://github.com/jjasghar/chef-openstack-testing-stack/commit/7634b157049fd21e275925a5c8c2d3d6270487bf
16:16:15 <j^2> those two thnigs
16:16:21 <j^2> updated rabbitmq cookbook
16:16:28 <j^2> added ubuntu14
16:16:45 <j^2> and it just worked
16:17:52 <markvan> And you have no version on mysql cookbook, so your using the latest.
16:18:00 <j^2> actually no i’m not
16:18:14 <j^2> there are constrants lower that require 5.6
16:18:40 <markvan> ah, yup
16:18:46 <j^2> we have inconsistant constrants through our cookbooks which is annoying to say the least
16:19:00 <j^2> _but_ that’s by “design”
16:19:00 <markvan> yes, was my next topic.
16:19:57 <j^2> kk
16:20:54 <markvan> #topic dependent cookbook versions
16:21:17 <markvan> There has been some discussion on this lately and wanted to go over it
16:21:23 <zhiwei> yes
16:21:27 <zhiwei> https://blueprints.launchpad.net/openstack-chef/+spec/cookbook-version-constraint
16:21:34 <zhiwei> this link my be helpful.
16:21:40 <j^2> zhiwei: nice, thanks
16:22:12 <j^2> zhiwei: oh great doc man, thank you for putting this together
16:22:34 <markvan> yup, I think for the major dependencies like mysql and rabbit, we should go ahead and put in the 2 depends lines for Juno
16:23:49 <j^2> that’s not a horrible idea
16:23:57 <j^2> so we can scope it down
16:24:13 <j^2> but not get pigeon holed if you will
16:24:31 <markvan> yup, try to get some better control for a stable branch
16:25:12 <markvan> I know this blueprint does not have a spec, but if we agree here, we can approve it and mark it for Juno.
16:25:38 <j^2> i don’t want to commit to it yet, i need to think about it
16:25:45 <j^2> so i abstain
16:27:08 <markvan> sure, we can circle back on that one.  Maybe next step it to put in some explicit blueprint workitems to show the scope for Juno changes.  zhiwei can you start that piece?
16:27:18 <j^2> good idea
16:27:46 <zhiwei> ok.
16:27:53 <markvan> thx
16:28:08 <markvan> #topic  rake in infra
16:28:42 <markvan> Just a quick update on where we are.  we have patch https://review.openstack.org/#/c/148465/ to just begin sandbox for rake.
16:29:37 <markvan> Next steps are to switch that to running on trusty with a Chefdk prep step.    Then the BIG switch, allow branch specific gates to cover the non-Rake breanches and the new Rake ones.
16:29:54 <j^2> shit shouldnt that be chef exec rake test?
16:30:15 <j^2> so it leverages chafed?
16:30:18 <j^2> chefdk
16:30:27 <markvan> with next step and the chefdk, where not there yet.
16:30:31 <j^2> k
16:30:53 <markvan> this first pass is just to see what issue Rake will bring us.
16:31:01 <j^2> ack
16:31:07 <markvan> #link https://gist.github.com/jjasghar/48282346d7a3a0be6846   prep step for ChefDK
16:31:39 <j^2> we might want to put 0.3.6 in, it was just released yesterday
16:31:51 <markvan> I'm working on looking into the branch specific gates and how to do that with current infra templates.
16:32:28 <markvan> yup, installing 3.6 now, has many win updates for me
16:33:23 <markvan> #topic Open for general discussion
16:34:40 <j^2> cool, i think i’m good with the discussion today
16:34:50 <j^2> jklare: we missed you today ;)
16:34:57 <j^2> (yes i’ll call you out :P)
16:35:13 <j^2> any other topics?
16:36:01 <j^2> zhiwei: btw, i’ve been trying to think about a good time for a video meeting, i have a couple propsals, i should send something out to the ML today getting feedback
16:36:41 <markvan> im done for now
16:36:55 <zhiwei> ok, I will check ML and give you feedback.
16:37:29 <j^2> awesome, thanks everyone
16:37:32 <j^2> #endmeeting