16:00:37 <jklare> #startmeeting openstack-chef
16:00:38 <openstack> Meeting started Mon Feb 15 16:00:37 2016 UTC and is due to finish in 60 minutes.  The chair is jklare. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:41 <openstack> The meeting name has been set to 'openstack_chef'
16:00:50 <jklare> hi everyone
16:02:06 <alexandrelevine> hi
16:02:28 <jklare> hi alexandrelevine
16:03:46 <jklare> lets wait some more minutes to give more people time to join before we start
16:04:00 <markvan> howdy
16:04:04 <jklare> hey markvan
16:05:57 <jklare> so, for today i got 3 topics so far: 'endpoint refactoring', 'failing gate-jobs' and 'the new ec2 cookbook'
16:06:02 <jklare> anything you guys want to add?
16:08:22 <jklare> i hope that sc` and j^2 will join the meeting later
16:08:41 <jklare> but i guess we can start right away with alex
16:08:45 <sc`> didn't realize there was a meeting today
16:08:49 <sc`> it's a US holiday
16:09:00 <jklare> sc` ahhhh, i did not know that :)
16:09:03 <sc`> i'm here, regardless
16:09:06 <jklare> great
16:09:16 <jklare> why are you not on holiday markvan ?
16:09:30 <sc`> some companies don't observe it
16:09:36 <sc`> mine does
16:09:44 <jklare> #topic adding a cookbook for nova ec2 endpoint
16:09:46 <markvan> this one is for the kids...no school...and all of mine are college+ now
16:09:54 <jklare> i see
16:10:09 <jklare> so alex, you want to go ahead and explain some details about your project?
16:10:27 <alexandrelevine> Ok, Jan.
16:10:53 <alexandrelevine> First of all I want to introduce Anastasia - nick tikitavi. She's the main developer of the stuff.
16:11:01 <tikitavi> hi
16:11:08 <jklare> hi tikitavi
16:11:24 <sc`> hi tikitavi
16:11:38 <markvan> howdy and welcome
16:11:38 <alexandrelevine> We wanted to create a set of cookbooks the same way you did for the rest of the OpenStack components
16:12:03 <alexandrelevine> However we found out that some of the stuff is implemented in your core projects so we can't just put everything in our own
16:12:23 <alexandrelevine> Also we had troubles because we don't yet have packages - rpm or deb
16:12:28 <alexandrelevine> We do have pypi though.
16:12:57 <alexandrelevine> So with all of that we did what we can accordingly to your examples and provided workarounds wherever needed.
16:13:20 <alexandrelevine> Now we have our project in cloudscaling github: https://github.com/cloudscaling/cookbook-openstack-ec2
16:13:40 <alexandrelevine> And it can be installed on top of OpenStack provisioned with your chef and vagrant
16:14:06 <alexandrelevine> Basically what we'd like to do now is to somehow end up in a family of your other projects.
16:14:09 <alexandrelevine> I'm finished.
16:14:21 <alexandrelevine> I've finished :)
16:14:27 <alexandrelevine> I'm still alive :)
16:14:32 <jklare> :D
16:14:42 <jklare> ok, i think what you have there is a great start
16:15:38 <jklare> to integrate the cookbooks, we need to refactor these like we did for our own core cookbooks
16:15:54 <jklare> which should be quite easy, since the cookbook is not yet that big
16:16:04 <alexandrelevine> Ok. Where do you look to see how it should be done?
16:16:20 <jklare> we have this blueprint https://blueprints.launchpad.net/openstack-chef/+spec/cookbook-refactoring
16:16:30 <alexandrelevine> Ok. We'll take a look.
16:16:38 <jklare> which also points to a spec, which i still have to adapt a bit
16:16:53 <jklare> since we moved slightly away from the original design in the spec
16:17:04 <alexandrelevine> Do we keep going in our separate github or do you think it's time to apply for an openstack project?
16:17:05 <jklare> but its still applicable for the biggest part
16:17:41 <jklare> i think we can move the project to the openstack namespace like all the other openstack cookbooks
16:18:02 <sc`> +1 - i don't see any particular reason not to
16:18:10 <alexandrelevine> Ok. However, the question is who's going to create this project? If I do I'll become the PTL by default.
16:18:23 <alexandrelevine> I understood that you guys manage all of your projects, no?
16:18:35 <jklare> i can create the project and you can do the first patch
16:18:47 <alexandrelevine> Yes, sounds perfect.
16:19:23 <jklare> so if you need any help with the refactoring, i am usually around during european working hours in our irc room
16:19:30 <jklare> and can try to help
16:19:40 <alexandrelevine> Perfect. If we have questions we'll find you in IRC.
16:19:55 <jklare> sc`, j^2 and markvan are usually available during the rest of the day :D
16:20:14 <alexandrelevine> great
16:20:15 <markvan> If possible I would also recommand a series of small patches to makes reviews easier.
16:20:22 <alexandrelevine> We
16:20:24 <jklare> or night, as we european people call that time of the day
16:20:28 <alexandrelevine> We'll try to split, ok.
16:20:37 <markvan> and then look ahead to trying to create a new Repo env for testing
16:20:39 <sc`> i'm UTC-8 and usually around during US hours
16:20:48 <sc`> and yes, smaller patches are easier to digest
16:21:10 <alexandrelevine> What do you mean by Repo env exactly?
16:21:36 <markvan> #link https://github.com/openstack/openstack-chef-repo/tree/master
16:21:59 <sc`> makes sense
16:22:14 <alexandrelevine> Yes that's what we used. But what do you mean by us creating a new one?
16:22:16 <markvan> It's a project where we try to bring all the cookbooks together and run some basic tests, also used for our gate integartion testing
16:22:35 <jklare> i think mark points to the environments we use for different scenarios
16:23:10 <sc`> new environment file like for c7 and such, right markvan?
16:23:16 <jklare> so we will have to see if we can just add it to our most basic allinone test or if we should rather create a new one with some specific setting to test and deploy ec2
16:23:17 <alexandrelevine> Would it be possible to let us in with only pypi package for the time being? Later rpms will be available, but I'm not sure when.
16:24:08 <jklare> i think the package source should not be an issue
16:24:20 <jklare> as long as its coded in an idempotent way
16:24:28 <markvan> As long as the pypi can work with the openstack packages used already, should be fine.
16:24:32 <jklare> but there are also resources for managing pypi i guess
16:24:38 <sc`> it does
16:24:57 <alexandrelevine> Ok I guess we'll start with refactoring and you'll guide us down the rest of the road.
16:25:08 <sc`> we use pypi for some things. i think tempest itself
16:25:10 <jklare> sure
16:25:33 <alexandrelevine> Great we'll check the tempest project then and do the same.
16:26:16 <jklare> it the ec2 project completely replacing the nova-api-ec2?
16:26:25 <alexandrelevine> Yes.
16:26:29 <sc`> sorry, we as in my org, not we as in the project
16:26:33 <alexandrelevine> nova-api-ec2 is out of nova already
16:26:38 <sc`> E_NOCOFFEE
16:27:15 <alexandrelevine> mitaka will come out with our ec2-api
16:27:36 <alexandrelevine> Sorry, newton
16:28:43 <alexandrelevine> no, mitaka. Damn, I went to Tokyo and got totally confused with all those names :)
16:28:50 <jklare> :9
16:28:53 <sc`> :D
16:29:01 <jklare> no worries
16:29:57 <jklare> we are currently working on our mitaka release and if you are willing to refactor your cookbook like we did for our core ones, i think we should be able to integrate it to our project during this cycle
16:30:19 <alexandrelevine> Would be perfect. We'll try to jump in
16:30:24 <jklare> cool
16:30:41 <jklare> more comments for this topic or should we go ahead to the next one?
16:30:55 <alexandrelevine> Please go ahead. At least we got all we need for now.
16:31:12 <jklare> #topic failing gate-jobs
16:31:29 <jklare> currently our integration job is broken
16:31:49 <jklare> and as far as i can tell this looks like its related to the new apt mirror
16:32:03 <jklare> for some reason we can not install the ubuntu-cloud-keyring package anymore
16:32:44 <jklare> anybody any ideas?
16:32:50 <jklare> or time to look into that?
16:33:36 <markvan> yeah, I saw some of the ML discussion about the new mirrors, but have not looked at them yet
16:34:40 <jklare> http://logs.openstack.org/93/277193/2/check/gate-openstack-chef-repo-chef-rake-integration-nv/7f6edb0/console.html.gz
16:35:12 <jklare> this is from a patch that was just changing minor things in the docs and for vagrant boxes
16:35:33 <sc`> interesting. the failure isn't consistent between repos
16:35:44 <sc`> for repo, it's ubuntu-cloud-keyring
16:36:06 <jklare> ?
16:36:18 <sc`> http://logs.openstack.org/96/279696/2/check/gate-cookbook-openstack-common-chef-rake-integration-nv/9c4c198/console.html.gz
16:37:28 <sc`> that one was against common
16:38:40 <jklare> that issue is patch related
16:39:07 <jklare> it breaks since we moved the endpoint logic around
16:39:18 <jklare> which is the next topic
16:39:19 <jklare> :)
16:39:37 <sc`> :D
16:41:35 <jklare> ok, i guess we should look into that issue to get our integration testing working again
16:41:51 <markvan> I have not tried locally, but does this also fail locally (not finding the key pkg)
16:42:01 <jklare> no, works fine
16:44:17 <jklare> i think its related to the apt mirror
16:44:36 <jklare> but thats just because the timing correlates
16:44:46 <jklare> have not talked to infra yet
16:45:27 <markvan> yup, that's probably the next step here
16:46:03 <jklare> ok, next topic?
16:46:30 <jklare> #topic inverting endpoints during refactoring
16:46:56 <jklare> ^^ i take 30secs without a response as a yes :D
16:47:21 <markvan> sounds reasonable to me
16:47:35 <jklare> calbers and me have pushed up a set of changes like this one here https://review.openstack.org/#/c/279696/
16:48:00 <jklare> during the refactoring, we accidentally switched the order of public/internal/admin and service
16:48:09 <jklare> which we should not do imho
16:48:17 <jklare> so these patches revert this switch
16:48:48 <jklare> i think we should stick with the order node.openstack.endpoints.public/internal/admin.service
16:49:02 <jklare> since this way its a lot easier to get all the public endpoints defined
16:49:20 <markvan> agreed
16:49:20 <jklare> without running a select on all defined services
16:49:46 <jklare> and then there is another related thing which came up today during deployment
16:49:53 <jklare> which is about the bind_service attributes
16:50:24 <jklare> which follow the same logic after refactoring, because i started with identity and identity acutally has three different endpoints and can also bind to them
16:50:28 <jklare> because it runs in apache
16:51:03 <jklare> sadly none of the other service can actually bind to different ip addresses or even ports for these endpoints
16:51:41 <jklare> so i think we should stick with the three different endpoints for all services, but reduce the bind_service attribute to just one for all services but keystone
16:52:27 <jklare> so the attributes would look like node.openstack.bind_services.all.network.host = '127.0.01'
16:53:14 <jklare> node.openstack.bind_service.all.network.port = 9292
16:53:28 <jklare> while identity would look like this
16:53:59 <jklare> node.openstack.bind_service.public/internal.identity.port = 5000
16:54:19 <jklare> node.openstack.bind_service.admin.identity.port = 35357
16:54:51 <jklare> so they would all have the same structure, but allow binding to multiple ports/addresses for services running in apache
16:55:20 <jklare> not sure if there are other services like keystone which can bind to multiple addresses ports
16:55:37 <jklare> btw. we have only 5min left :D
16:56:28 <markvan> so that 'all' would just be a simplified approach for the rest of the services, sounds ok with me
16:57:55 <sc`> sounds fine with me, too
16:58:21 <jklare> cool, calbers and me will push the patches later
16:58:32 <markvan> k ,will look for them
16:58:55 <jklare> ok, i guess we are at the end of our meeting (since we only have 1:30min left)
16:59:06 <jklare> any fast statements or comments?
16:59:17 <jklare> thanks for attendings
16:59:21 <jklare> see you in the channel
16:59:22 <jklare> :D
16:59:28 <jklare> #endmeeting