16:00:10 <jklare> #startmeeting openstack_chef
16:00:11 <openstack> Meeting started Mon Nov 23 16:00:10 2015 UTC and is due to finish in 60 minutes.  The chair is jklare. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:15 <openstack> The meeting name has been set to 'openstack_chef'
16:00:30 <jklare> hello everybody o/
16:00:38 <sc`> o/
16:00:42 <calbers> hi there
16:02:17 <jklare> any topics from you guys for today?
16:02:54 <sc`> i don't have anything for this week
16:03:41 <jklare> ok then lets start with this one
16:03:51 <jklare> #topic refactoring the cookbooks
16:04:38 <jklare> calbers and me have pushed up some refactored versions of compute and network and the network cookbook seems to be already working again in our integration tests
16:04:54 <jklare> it would be great so have some more eyes on this
16:05:07 <jklare> to check if these patches go into the right direction
16:06:01 <jklare> another thing i realised while going through the network cookbook is our (in my eyes) completely broken way of handling the identity (and maybe most of the other) endpoints right now
16:06:26 <jklare> i think somewhere along our path we decided to split the endpoints into internal, admin and public like the projects do
16:06:36 <jklare> which is great
16:06:56 <jklare> the issue is, that judging from the current state of the code, the refactoring never finished completely
16:07:25 <jklare> which led to something like this https://github.com/openstack/cookbook-openstack-network/blob/56c95b6ce3ad2f9fd2ff2882a05e03781f73b8ca/recipes/default.rb#L148-L153
16:08:57 <sc`> the endpoint stuff is rather fragile, at least that's what my experience was backporting some code to icehouse
16:08:58 <jklare> in line 148 the internal_endpoint is defined by calling internal_endpoint on 'identity-internal', which will first search for an attribute like node.openstack.endpoints.internal.identity-internal.... and after not finding it, fall back to node.openstack.endpoints.identity-internal... which exists
16:09:30 <jklare> so the fact that it is working is currently based on a fallback
16:09:38 <jklare> and some workaround definitions
16:10:15 <jklare> since these methods and the definition of endpoints is very important for all cookbooks, we should try to fix this during this refactoring cycle imo
16:10:26 <sc`> +1
16:10:36 <jklare> :)
16:10:50 <jklare> so you want to go for it sc` ?
16:11:11 <sc`> may not have as much time as i'd like
16:11:22 <jklare> yeah, i know that feeling :D
16:12:23 <sc`> being as $job is icehouse, there's a good deal of context switching that has to happen
16:13:18 <jklare> in my opinion this endpoint methods are too complicated and to workaroundy right now
16:14:54 <sc`> it is rather complicated to work with. suggestions on how to improve it?
16:15:35 <jklare> i think we can define a more generic endpoint method, that depends on some more sane user input
16:16:19 <jklare> right now our endpoints and uri methods try to correct things from attributes that might be set wrong
16:16:35 <jklare> like removing '/' or replacing 'v3.0' with 'v3'
16:17:42 <sc`> bad node attribute data is just a consequence of chef. i can see where consolidating methods would be useful
16:17:48 <jklare> if we agree that the cookbook user knows what he is doing and has read the documentation (which needs to be updated ofc), we could remove a lot of complicated code here and go with a lot more 'convention over configuration'
16:18:29 <sc`> assuming people read documentation is a lofty assumption :D
16:18:34 <jklare> i know
16:18:42 <jklare> sad but true
16:20:01 <jklare> so, since nobody has touched the common cookbook and its methods yet, i could give it a shot and refactore these methods
16:20:04 <sc`> but i agree. we shouldn't be managing the configuration of openstack as much as we are
16:20:22 <jklare> -e
16:21:49 <sc`> if the cookbooks move away from ubuntu/centos packages and use something a la giftwrap, a good deal of things could go down to the packages themselves and be out of the cookbooks
16:22:22 <jklare> thats true, but does not change anything regarding the dynamic configurations
16:22:53 <jklare> except if we include the whole package and service configuraiton in the postinst scripts ;)
16:23:21 <sc`> i think it depends on how we want the future to look
16:23:30 <jklare> ?
16:24:08 <sc`> continuing the use of upstream packages the way we are locks us to certain assumptions at the packaging level
16:24:21 <sc`> less control, etc.
16:25:10 <jklare> but that is mainly the installation path and the init scripts right?
16:28:01 <sc`> one thing that pops out is keystone.wsgi vs wsgi.py. i don't have a comprehensive list of what's different between distros, but it's plausible that there are other variances versus upstream openstack
16:29:49 <j^2> hey all :D
16:29:52 <jklare> true, but i am not sure if we should try to move away from upstream packaging to correct these minor things and face all the heavy lifting of packaging ourselfs instead
16:29:57 <jklare> hey j^2
16:30:08 <sc`> ohai j^2
16:30:17 <calbers> hi j^2
16:30:22 <j^2> it seems my NAS at home got hacked :(
16:31:17 <jklare> CIA?
16:31:24 <jklare> NSA?
16:31:29 <j^2> the "LOL" hack
16:35:41 <jklare> would you volunteer to try some automated building of packages that we could use sc` ? because my main objection with this right now is, that we only have so much resources and i have not seen anybody working on this packaging thing for our project so far
16:36:13 <jklare> i also have tried the giftwrap thing and spend 2 hours patching code to get it to build some packages from master
16:36:30 <jklare> i have no idea if they work or not
16:36:38 <jklare> and no automation to test them right now
16:37:33 <jklare> so from my point of view the " we should package ourselfs" idea is great, but not doable right now
16:37:57 <jklare> and i would love to be proven wrong here
16:38:30 <sc`> indeed. perhaps a 'not right now' thing given the number of active contributors. i can see if i can spend some time over the coming US holiday
16:39:03 <jklare> sounds good
16:39:29 <jklare> @j^2 i heard you have some desginate things to tell?
16:39:43 <jklare> #topic designate-cookbook
16:40:21 <j^2> yeah
16:40:27 <j^2> so i've started a POC for designate
16:40:39 <j^2> i havent gotten common put in yet, but it's a start
16:40:58 <j^2> there is no "production" instructions so this is the best i got
16:41:13 <j^2> #link https://github.com/jjasghar/cookbook-openstack-dnsaas
16:41:21 <j^2> I'd love some eyes/PRs if yall have some time
16:41:44 <sc`> j^2: apparently this is the "production" instructions - http://docs.openstack.org/developer/designate/install/ubuntu-kilo.html
16:41:46 <j^2> when it's "ready" i'll squash/not squash everything down to one and cerate the openstack/ repop
16:42:00 <j^2> oh levely
16:42:02 <j^2> lovely
16:42:19 <j^2> this is the one i used: http://docs.openstack.org/developer/designate/getting-started.html
16:42:28 <j^2> i'll go through that link jklare and make the changes
16:43:07 <j^2> luckly designate looks pretty straight forwarbd
16:43:18 <j^2> i'm planning on tk'ing it also too so
16:43:29 <j^2> and then we can add it to the openstack-chef-repo and have it part of the aio
16:44:26 <jklare> seems like great progress
16:45:25 <j^2> thanks
16:45:27 <j^2> i'm trying
16:45:29 <j^2> :D
16:45:43 <j^2> it looks like it's only Ubuntu for the time being
16:46:07 <jklare> adding support for other distributions should not be too hard
16:46:17 <jklare> chef should be build for that ;)
16:46:18 <j^2> I posted to openstack-dev too; trying to figure out if anyone had any suggestions, but no responses
16:46:28 <j^2> yeah the install guide only says Ubuntu :(
16:46:52 <sc`> one person responded this morning, which is where i got that link
16:47:10 <j^2> oh, i must have missed it in the FLOOD of email :'(
16:47:14 <j^2> i hate -dev for that reason
16:47:25 <sc`> i have a filter specifically for [chef]
16:47:37 <j^2> yeah but they sometimes fuck up the subjects :(
16:47:51 <j^2> anywho, i'll filter through again
16:48:17 <j^2> jklare: that's more or less all i got, i just want to make sure yall have seen it
16:48:38 <j^2> and ideally i should be able to take that same frame/skeleton and make magnum out of it too
16:49:38 <j^2> can i answer anything else about it?
16:50:33 <jklare> no i think i am good here
16:50:52 <j^2> cool, i'll be at their meeting too
16:51:01 <j^2> sc`: thanks for the heads up on the email
16:51:23 <sc`> np
16:51:25 <j^2> jklare: fearless leader, back to you ;)
16:51:49 <jklare> #topic anything else
16:52:04 <jklare> i was at the ha-openstack meetup this morning
16:52:35 <j^2> i bet that was an exciting conversation! :P
16:53:08 <jklare> was a quite interesting discussion on how to improve the documentation and how to get started in documenting all the solutions people have build for archieving the ultimate and true HA
16:53:29 <jklare> they will start with creating some etherpads and diagramms to sync up
16:54:22 <jklare> i think we should try to get involved after that initial step has happened and see if we can use these diagramms and documentation to build some ha-wrappers
16:55:02 <j^2> jklare: that's a great idea
16:56:33 <jklare> all from my side :D
16:56:44 <jklare> anything anybody wants to add?
16:56:56 <sc`> getting ha configurations in will be good
16:56:57 <jklare> 4mins left
16:57:07 <sc`> i'm good
16:57:55 <j^2> same here i'm good
16:58:13 <jklare> ok, thanks for attending and see you around
16:58:16 <jklare> #endmeeting