16:00:17 <j^2> #startmeeting openstack-chef
16:00:18 <openstack> Meeting started Mon Jun 22 16:00:17 2015 UTC and is due to finish in 60 minutes.  The chair is j^2. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:22 <openstack> The meeting name has been set to 'openstack_chef'
16:00:27 <j^2> hey everyone!
16:00:30 <carlp> ohai
16:00:36 <sc`> o/
16:00:48 <markvan> howdy
16:01:05 <j^2> as per useal i’ll give everyone a couple minutes to join, then start pulling topics from the agenda
16:02:53 <j^2> #topic sc` and the fight that is c7 repo
16:03:06 <j^2> sc`: so tell us of your trials and tribulations
16:04:25 <sc`> i've been able to get a mostly complete converge on c7 using the delorean midstream repos in https://review.openstack.org/189531
16:04:48 <j^2> nice
16:05:05 <sc`> i have a yet to be proposed change for mariadb to fully work with the centos package
16:05:11 <jklare> o/
16:05:13 <j^2> markvan: would you like to discuss the details here for this patch?
16:05:17 <libsysguy> \o
16:05:29 <j^2> jklare: kingkong in the house!
16:05:34 <j^2> :P
16:05:56 <j^2> sc`: nice makes sense
16:06:15 <jklare> j^2 markvan really pushed this one ;)
16:06:26 <markvan> sc`: for the delorean repo, is that a replacement for the repo we have defined in common, or it's just filling in the missing pieces?
16:06:30 <j^2> i like the idea of this patch moving forward, if it opens up cent7 which i believe it does, that helps us move towards stable
16:06:40 <sc`> markvan: it fills in the missing pieces, ie. ironic
16:07:04 <sc`> the delorean repos complement the main repo defined in common
16:07:37 <markvan> sc`: ah, ok.   But at some point we would want to disable the delorean as the main repo becomes complete/stable?   Hence we should have a flag/attribute to control this
16:07:50 <sc`> they may go away Eventually(tm) so as to make things easier from an operator point of view
16:08:08 <sc`> in which case the whole block could come back out of common
16:09:01 <markvan> I think we should consider adding a flag/attribute to enable this, such that we can make use of it, but not force it's use for others
16:09:24 <sc`> right. today it's needed just to deploy kilo the way we are deploying it using chef
16:09:58 <j^2> we can’t leverage that for the integration testing though, stupid ubuntu base images
16:10:12 <j^2> though i’m pretty sure there are other base images aren’t there?
16:10:54 <markvan> not sure what is available, I've heard that fedorea is used for some devstack stuff
16:11:10 <jklare> j^2 integration testing on c7? did i miss something?
16:11:13 <j^2> it might be something worth looking into down the line
16:11:37 <jklare> j^2 or are you talking about manual testing here?
16:11:59 <j^2> jklare: integration testing to verify the c7 repo feature flag. no reason why we shouldnt be able to build something that leverages the centos7 base image that I’ve heard rumors of
16:12:19 <j^2> jklare: oh yeah we could totally do it by hand, i was just hoping to let the bots do the work for us
16:12:42 <j^2> and when we finally have a passing build without c7 we can look towards making stable/kilo
16:12:51 <j^2> or at least that’s what my thought process was
16:13:29 <sc`> i can wrap the remote_file block in an attribute so it can be toggled off. until ironic is stabilized, however, it's a necessary requirement with the way the roles are structured
16:14:00 <j^2> sc`: cool, please update the review and we’ll continue the conversation there
16:14:12 <j^2> #topic specs.openstack.org
16:14:22 <j^2> I’ve kinda glossed over this one a few times
16:14:30 <j^2> i just wanted a quick poll:
16:14:50 <j^2> do we want to use the specs.openstack.org or should we stick with our own system for the time being?
16:15:09 <jklare> i think we should go for spec.openstack.org
16:15:10 <jklare> its nice
16:15:12 <jklare> and shiny
16:15:16 <j^2> there’s a hand full of migration things we need to do but all in all shouldn’t be too painful
16:15:47 <markvan> switching to it sounds fine to me
16:15:51 <j^2> puppet does use them: http://specs.openstack.org/stackforge/puppet-openstack-specs/
16:15:51 <sc`> i'm +1 on specs.openstack.org
16:16:31 <j^2> unless there is any major objection from anyone?
16:16:49 <j^2> i’ll take the action item to move us
16:17:15 <jklare> +2
16:17:50 <markvan> I see they also allow "Trival" specs, which are just launchpad blueprints, so that's good
16:18:06 <j^2> #topic How to handle cross procject CI testing
16:18:18 <j^2> markvan: i know you have some opinions there
16:19:15 <markvan> yeah, one item is that until we really conquer this, I believe we need to have the CI test be a non-voting job.
16:19:50 <jklare> patch in infra for that is in and marked as WIP
16:20:05 <jklare> link is on the etherpad
16:21:00 <markvan> I have only briefly looked ino hows the Depend-On works, but with our "special" berks vendor step, I think this will take more infra job work to allow cross patches to work.
16:21:47 <markvan> I have started a fork of my test-patch script that has a goal of working from within infra jobs to handle this
16:22:43 <j^2> markvan: http://docs.openstack.org/infra/manual/developers.html#cross-repository-dependencies
16:23:06 <jklare> i think if we want to test multiple patches in one, we need to change a lot in our testing procedure
16:23:13 <j^2> depends-on link ^^^
16:23:58 <jklare> j^2 yeah, but the problem is that we need to combine this with berks somehow
16:24:04 <j^2> yeah
16:24:08 <markvan> yeah, looks like depends-on just handles the sync/flow of the patches, such that they are done in correct order.  What we need is something like my test-patch script to allow for berks-vendor to pull in what we need across projects
16:24:47 <j^2> so untill we have a good answer for berks, we’re still at a impass
16:24:57 <j^2> like was mentioned above
16:24:58 <sc`> would that even be possible to do manually a la git-review?
16:25:23 <j^2> some crazy awk/sed/git-review magic sc` ?
16:25:26 <jklare> maybe it is possible to hand over related patch ids in the commit message and use them to pull and checkout the corresponding git repos (cookbooks) with berks
16:26:15 <markvan> Right now I kinda have it working, buy my hold up is that the Depends-On info is not easly presented in the gate job env.  So, I'm just grabbingthe info directly from the gerrit source and parsing that.
16:26:18 <jklare> basically git-review -d $PATCHID inside the berks vendor path
16:26:56 <j^2> yeah and the problem with the parsing stuff is that you can’t with the nodes
16:27:04 <markvan> yup that's what I'm doing....but had to get that patchID from the gerrit info
16:27:09 <j^2> there is the “zuul cloner” that should be able to get most of that info for you markvan
16:27:52 <markvan> yup, justy started to look into that, still not sure how to tell it what patch(s), but I'm digging
16:27:53 <j^2> and I’ve already asked if there is a “read only” gerrit user, and they say no you have to use zuul cloner
16:28:00 <j^2> :D
16:28:06 <markvan> ah, good no know
16:28:18 <j^2> #topic CI testing and the awesomeness that is markvan
16:28:48 <j^2> soooo lets merge this?
16:29:57 <markvan> yeah, what I have now is basically working, and I think ready for something like that periodic task, non-voting, and maybe we could also run it for repo  changes as voting, as a start.
16:30:22 <jklare> +2
16:30:24 <markvan> I think for the icehouse/juno, we should just add in a "skip-if" and ignore those
16:31:40 <j^2> i think we should use juno too
16:31:42 <jklare> the periodic patch https://review.openstack.org/#/c/194164/
16:31:43 <markvan> I would also like it to be available for all cookbooks, but still in a manaully mode, like the experimental gate
16:31:51 <j^2> juno is “LTS” remember
16:32:03 <jklare> icehouse and juno should be skipped by the regex we introduced before
16:32:30 <markvan> yean, juno could be a "backport" once we get better at this
16:32:39 <jklare> ^^+1
16:32:41 <j^2> cool
16:32:42 <j^2> that works
16:33:06 <j^2> as long as we are moving this forward :)
16:33:43 <j^2> #topic keystone under apache
16:33:44 <jklare> is think the periodic infra patch is mergable as soon as we merge the rake integration test job in
16:33:53 <jklare> :(
16:33:57 <j^2> heh
16:34:05 <jklare> well lets continue
16:34:10 <jklare> i can talk about this late ;)
16:34:14 <jklare> later
16:34:26 <j^2> sounds good ,we can take this to our main channel
16:34:33 <j^2> markvan: keystone?
16:35:08 <markvan> Since the recommended way to run keystone now is under apache, I thought I would take a stab at getting that done.
16:35:31 <markvan> I belive in the M release the keystone service will be gone and just apache will be used.
16:36:01 <markvan> My thought for kilo was to just get the new recipe done and up, but NOT change the role to start using it until Liberty.
16:36:09 <j^2> makes sense
16:36:18 <j^2> scoping of this work? i havent looked at this at all
16:36:32 <markvan> I'm also leveraging the latest apache cookbook which has some good bugs fixes
16:37:18 <markvan> The idea was to use this as the default in Liberty, but I wanted to get some code out to get this going now
16:37:22 <j^2> yeah there has been a lot of love on the apache cookbooks
16:37:50 <markvan> but there still using definitions  @$^&!
16:37:58 <j^2> booo
16:38:34 <markvan> So, there are 3 patches, please take a look: https://review.openstack.org/#/q/status:open++branch:master+topic:bp/keystone-apache,n,z
16:39:01 <j^2> will do
16:39:18 <j^2> #topic OpenStack client, libsysguy yell at us.
16:39:27 <libsysguy> GET OFF MY LAWN YOU KIDS
16:39:31 <j^2> ha!
16:39:37 <libsysguy> okay, now that's out of the way
16:39:54 <libsysguy> I've been giving openstack-client some love over the weekend
16:40:14 <libsysguy> and it came to my attention that there is really not a great way for this cookbook to maintain idempotency
16:40:35 <libsysguy> and I wanted to know if this was a concern or if anyone else has given any thought to it
16:40:41 <libsysguy> or if it was an abandoned cookbook
16:40:48 <libsysguy> I've been out of the game for awhile
16:41:24 * libsysguy had his coffee this morning
16:41:45 <j^2> :D
16:42:28 <markvan> for basic create if not exist type work (used during the converge) I think that can get done fairly easily.
16:42:51 <markvan> but for more complex, yup idempotency would be hard to achieve
16:43:12 <libsysguy> if not exist would have to rely on a uuid - which is only returned after a create - so you'd have to maintain a record of it outside of openstack
16:43:22 <libsysguy> which can be done - it's just no ideal
16:43:26 <jklare> i agree with mark here, depending on the special case, the use has to take care of the idempotency himself
16:43:40 <jklare> probably one can add some tools for that in the libraries
16:43:49 <jklare> that can also be utilized inside of the lwrps
16:44:22 <libsysguy> with a library like fog I don't think it's possible
16:44:29 <libsysguy> maybe if you used the api's directly
16:44:54 <libsysguy> anyway - I don't want to hog up too much meeting time
16:45:09 <libsysguy> but I just wanted to maybe get some wheels turning on it
16:45:21 <jklare> fog should be able to return a uuid, which a user can add into a attribute node['array_of_existing_stuff']
16:45:54 <libsysguy> ah - yes.  I have been running in solo mode so I don't really have node state available to me
16:46:29 <libsysguy> sorry guys - next meeting
16:46:49 <j^2> #topic Open Discussion
16:47:06 <j^2> anything else?
16:47:16 <j^2> or should we close and move to our channel?
16:47:47 <jklare> as i tried to add before ;) there are infra patches for our ci testing out there, that i put in as WIP
16:48:32 <markvan> yup, I think we should move on the periodic one, but maybe leave the experimental in place to continue cross cookbook work?
16:48:34 <jklare> they contain the things we discussed last meeting (and this one too) and if we want to merge them, just +1 them and i will remove the WIP
16:48:40 <sc`> from the project renames, should we purge older releases (g and h)?
16:49:34 <markvan> abandon these? https://review.openstack.org/#/q/status:open+branch:stable/icehouse+topic:project-rename,n,z
16:49:39 <jklare> i think for the patch which moves the experimental to non-voting we should add the rake integration jobs to all cookbooks first
16:49:55 <jklare> so this one will probably stay wip for a while
16:50:03 <j^2> markvan: +1 on the abandon it
16:50:08 <j^2> them*
16:50:42 <markvan> jklare: agreed, just get the periodic or repo gate one in first
16:51:10 <jklare> +1 on abandon
16:51:27 <j^2> 9 mins
16:52:38 <jklare> nothing to add from my side :)
16:52:52 <sc`> mariadb will most likely need a version bump for the centos-specific changes. that's an action item for me
16:53:13 <j^2> sc`: nice, that’s for tracking that
16:53:27 <j^2> cool, anything else or i’ll go ahead and close this meeting?
16:53:45 <sc`> i'm good
16:54:28 <j^2> #endmeeting