16:34:14 #startmeeting kolla 16:34:15 Meeting started Wed Dec 30 16:34:14 2015 UTC and is due to finish in 60 minutes. The chair is SamYaple. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:34:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:34:18 The meeting name has been set to 'kolla' 16:34:27 #rollcall 16:34:42 #topic rollcall 16:34:46 ^ 16:35:06 o/ 16:35:11 thanks rhallisey 16:35:22 SamYaple, I can't set it copy paste that 16:35:30 #topic rollcall 16:35:35 cool 16:35:36 hi! 16:35:37 o/ 16:35:45 because I have started teh meeting I am the only one who can change topic? 16:35:50 ya 16:36:34 ok we will give a few for the meeting for people to join 16:36:49 nihilifer: ping 16:37:12 hello ajafo 16:37:19 hi 16:38:20 0/ 16:38:24 \o/ 16:38:25 o/ 16:38:28 Just forgot. 16:38:34 sorry. 16:38:37 no problem 16:38:47 waiting until 16:40 for rollcall 16:40:14 #topic binary-ubuntu 16:40:25 #link https://blueprints.launchpad.net/kolla/+spec/binary-ubuntu 16:40:47 So on this topic, ajafo has been doing alot of work to add in binary support for ubuntu 16:41:08 on the ML it was pointed out that canonical is attempting to do newer packages in the mitaka-staging repo 16:41:20 that repo however, only has some mitaka packages and some liberty packages 16:41:39 that has been my experince with cloud-archive from the beginning, half complete-ness 16:41:53 because of that at least for now, I would suggest _not_ switching to the staging repo 16:42:10 this means the original plan would stick in place of using liberty packages until mitaka is actually released 16:42:16 thoughts? 16:42:29 agreed. 16:43:01 at this moment imho it's right way 16:43:28 I saw nova 13.0.0 is updated few hours ago. we are told the mitaka staging will prepared in one week after the new year. So we can switch to that after that. 16:43:43 well you are doing most of the work ajafo, so I will trust your opinion here. as Jeffrey4l we can always change later 16:44:03 ajafo: do you have anything you would like to add on the subject of binary-ubuntu? 16:44:24 nothing else only sorry @all for my first commit and lots of mistakes at the beginning 16:44:37 now should be better 16:44:42 no need to apologies. it was a good commit! just large 16:44:53 thank you for your work, it is appreciated 16:45:01 thanks 16:45:10 #topic kolla ansible docker module 16:45:21 this will be short since it has been discussed before 16:45:31 the docker module is ready for review 16:45:35 #link https://review.openstack.org/#/c/248812/ 16:45:53 it allows us to remove the docker 1.8.2 and docker-py 1.5.0 pinning and move on 16:46:10 please all eyes are useful on that patch because it is a major change for kolla-ansible 16:46:24 any questions or concerns on this subject? 16:46:45 none 16:46:47 no 16:47:15 wonderful, moving on 16:47:24 #topic ssl all the things 16:47:38 #link https://blueprints.launchpad.net/kolla/+spec/ssl-kolla 16:48:05 This is a new blueprint i created with the goal to turn all of the interprocess traffic into ssl encrypted traffic for kolla 16:48:14 excellent 16:48:26 this was discussed at the last midcycle and there were no objections, just some questions about performance 16:48:37 as far as I can tell there are no performance issues on modern hardware 16:48:53 with the exception being rabbitmq ssl intercommunication is... tricky 16:49:03 well security > performance in business really 16:49:13 yes. SSL should be used everywhere for security. 16:49:21 my idea for how to proceed on this is as follows, please tell me if this approach is flawed: 16:49:26 and since performance hit is almost non-existent, for me it's no-brainer 16:49:56 we need to generate certs internally for kolla to use. it is not practical to tie into an external CA at this time 16:50:20 we can generate a CA and then sign on the other certs and distrubute that self-signed trusted CA to all the nodes and services 16:50:32 this means all the internal communication is signed and trusted, but its all self-signed 16:50:35 let's make this optional and allow people to put their own certs plz 16:50:48 inc0: thats not practical was my point 16:50:58 we need to generate certs _per_ _node_ 16:51:25 I'm thinking about situations where people already have certs deployed 16:51:26 the external communication through haproxy would have a cert of the users choosing (either provided or self-signed) 16:51:45 but do people care about interprocess communication? or just external 16:52:00 my thoughts were it was just external communication that mattered and there they can provide the certs 16:52:36 ok, if someone will want this optional, he/she can always implement it 16:52:38 SamYaple is right. Deploy only one cert to all service is not a good idea. 16:52:58 inc0: thats fair, if it can be done reasonably 16:53:19 it should, I'm not to worried 16:53:29 so the plan is generate CA and then sign certs based on that (generating a cert per node). 16:53:40 external haproxy can be provided by the deployer 16:53:41 I don't know how it'll be realized but if by some kind of script it can be splited on part to generate and part to deploy certs, and then if someone have certs maybe he could be only deploy them by script? 16:54:32 ajafo: it may be possible to do that, ill put up a patchset, can you describe how to accomplish that based on the patchset? 16:54:33 if no then we can ganerate certs to the same place and then deploy it the same way as external certs 16:55:12 I can try 16:55:20 thank you. 16:55:29 ok thats all i have on this subject. other thoughts about ssl? 16:56:06 What the OPs need to provide? a CA? 16:56:20 Jeffrey4l: nothing. They will need to provide nothing by default 16:56:40 we can generate the CA and the certs (since this traffic never leaves the internal network) 16:57:15 I know this case. What about the "if someone will want this optional, he/she can always implement it" 16:57:38 don't we support custom the CA/certs? 16:57:48 i dont have a problem if someone provides a CA, its the matter of "how well does the code do it" 16:57:58 ok 16:57:59 im trying to avoid bloated or bad code 16:58:22 i have a few ideas on the subject of how to do this, but i cant garuntee it works 16:58:40 i can gaurantee that the kolla generated ca and certs will work 16:58:58 Great. wait for you PS. 16:59:05 cool 16:59:13 anything else on ssl? 16:59:35 ok thats all i have 16:59:40 #topic open-discussion 16:59:46 who would like the floor? 17:00:28 at some point I'm going to try out kolla kube. Probably won't be until after the midcylce 17:00:56 rhallisey: cool. i feel like kolla-mesos and kolla-kube will be very similiar implemntations 17:01:16 are you planning on starting a kolla-kube repo? 17:01:27 ya 17:01:33 Will kolla-mesos/kolla-kube be merged back into kolla code base? 17:01:39 Jeffrey4l: no 17:01:40 no 17:01:48 infact the plan is to pull out the ansible code 17:01:50 to kolla-ansible 17:02:02 kolla will be for building containers 17:02:27 ok. 17:02:47 So where the ansible code go? 17:03:08 kolla-ansible repo (has not been created yet) 17:03:11 seeit. 17:04:18 ok well everyone I do not have anything else today. Would we like to end early? 17:04:46 yep 17:05:01 1 minute until i end meeting unless i hear otherwise 17:05:59 got nothing 17:06:03 thanks for coming out everyone! 17:06:08 live long and kolla 17:06:11 #endmeeting