| *** diogogmt has quit IRC | 00:04 | |
| *** diogogmt has joined #kolla | 00:07 | |
| *** jasonsb has joined #kolla | 00:16 | |
| sdake | pbourke awake ? | 00:21 |
|---|---|---|
| *** bmace has quit IRC | 00:21 | |
| *** bmace has joined #kolla | 00:23 | |
| sdake | bmace around? | 00:23 |
| loth | sdake: need to be reviewer to vote? | 00:24 |
| bmace | maybe ;) | 00:24 |
| sdake | nope anyone can vote loth | 00:24 |
| sdake | need to have signed the cla i think tho | 00:24 |
| sdake | https://review.openstack.org/#/c/189157/ | 00:24 |
| sdake | bmace plz review :) | 00:24 |
| bmace | yeah, i have been looking at it | 00:24 |
| bmace | looking good so far | 00:24 |
| sdake | pretty different from v1.0 huh :) | 00:25 |
| bmace | a bit | 00:25 |
| bmace | as long as all I find is typos I'll be giving it a +1 :) | 00:26 |
| sdake | i type fast with lots of mistakes :) | 00:27 |
| bmace | i type at medium speed, with a lot of mistakes | 00:27 |
| sdake | haha | 00:27 |
| sdake | 110wpm or so here | 00:27 |
| sdake | less when writing code | 00:27 |
| sdake | but that is my copy speed | 00:28 |
| bmace | ever play typing of the dead? nothing like using your typing powers to kill zombies! | 00:28 |
| sdake | soudns interesting : | 00:28 |
| sdake | ) | 00:28 |
| loth | that game's amazing | 00:28 |
| bmace | amazing is a good term for it :) | 00:29 |
| loth | will really teach you proper punctuation and symbols if you turn the difficulty up | 00:29 |
| loth | also http://play.typeracer.com/ | 00:29 |
| sdake | i dont even know what i type it just comes out | 00:29 |
| sdake | i think a word and out it appears | 00:29 |
| bmace | i use a mechanical keyboard.. i end up typing very very loudly I think. nothing like being charged by the undead to make you pound that keyboard. | 00:30 |
| loth | 100 ansible tasks seems a bit low if its doing everything | 00:30 |
| sdake | loth possible samyaple gave the quote based on yaodu | 00:30 |
| sdake | just to show it snot a billion tasks :) | 00:30 |
| sdake | but something decomposable and solveable | 00:30 |
| sdake | its not | 00:31 |
| loth | in my rough bare-metal ansible deployment that covers everything i have 250~ | 00:31 |
| bmace | i think it lays out 7 tasks / role, so as the number of containers grow the tasks will grow, but nothing huge per container at least. | 00:31 |
| loth | of course the containers will take care of a lot of those tasks | 00:31 |
| sdake | the difference between 100 and 250 isn't significnat imo | 00:32 |
| sdake | 100 tasks in ansible is pretty small | 00:32 |
| sdake | and its mostly cut and paste | 00:32 |
| bmace | which is sort of a shame. maybe harder to do reuse in ansible tasks vs. real code | 00:33 |
| *** dims has quit IRC | 00:33 | |
| bmace | done | 00:35 |
| bmace | ship it ;) | 00:35 |
| sdake | all we need to do is clone samyaple a few times | 00:35 |
| sdake | and we are good togo | 00:35 |
| loth | one thing i can see needing is a kolla requirements doc for what OS we support deploying on and what network configurations should already be setup | 00:37 |
| bmace | clone him and wait about 20 years, or you are talking about transporter malfunction type cloning? lets just hope we don't end up with evil SamYaples.. with beards. | 00:37 |
| sdake | agree our docs need some love | 00:39 |
| sdake | bmace evil samyaple - I think we already got one of those :) | 00:40 |
| sdake | samyaple I jest :) | 00:40 |
| loth | as an operator i like the 'keystone.aug' function since often times deployment methods dont give you the options needed for your targted use case | 00:46 |
| *** dims has joined #kolla | 00:46 | |
| bmace | lol | 00:47 |
| *** jtriley has quit IRC | 00:49 | |
| loth | sdake: I see '/etc/kolla/keystone.aug' mentioned and also '/opt/kolla/configs' are we storing configs in two locations? | 00:50 |
| sdake | /opt/kolla/configs are on the host | 00:50 |
| sdake | /etc/kolla/keystone.aug is on the deployment system | 00:51 |
| sdake | loth make sense? | 00:57 |
| loth | (ansible location) /etc/kolla/keystone.aug -> (docker host) /opt/kolla/configs/keystone.conf -> (container) /etc/keystone.conf ? | 00:59 |
| sdake | roger | 01:00 |
| sdake | actually it gets merged with the default | 01:00 |
| sdake | at the ocker host | 01:00 |
| *** Slower has quit IRC | 01:00 | |
| sdake | at the docker host | 01:00 |
| loth | sdake: I'd like to see a koll-ansible status command, to see which containers are operational or need work | 01:01 |
| sdake | /etc/keystone/keystone.conf | 01:01 |
| sdake | pleae leave comments in the review | 01:01 |
| sdake | just click a line and type away | 01:01 |
| sdake | then click save | 01:01 |
| sdake | then you ahve to review +1 or -1 | 01:01 |
| sdake | review -1 if action is needed on my part | 01:01 |
| sdake | if you dont click the review button your comments are not saved | 01:02 |
| loth | sdake: add edits here? https://review.openstack.org/#/c/189157/5/specs/ansible-multi.rst | 01:03 |
| sdake | loth yes | 01:05 |
| *** bmace has quit IRC | 01:06 | |
| *** Slower has joined #kolla | 01:07 | |
| sdake | slower u around | 01:07 |
| *** fangfenghua has joined #kolla | 01:08 | |
| sdake | fangfenghua around? | 01:08 |
| * sdake harasses everyone 1:1 :) | 01:08 | |
| *** fangfenghua has quit IRC | 01:13 | |
| loth | sdake: replie | 01:14 |
| loth | d | 01:14 |
| sdake | thanks loth | 01:16 |
| sdake | first review? | 01:16 |
| loth | i think in that system | 01:17 |
| sdake | cool grats then! welcome to openstack ;) | 01:17 |
| sdake | if you want to review more stuff we take more reviews :) | 01:17 |
| *** bmace has joined #kolla | 01:18 | |
| sdake | the ha spec could use a review as wel | 01:18 |
| sdake | https://review.openstack.org/#/c/181983/ | 01:18 |
| *** Haomeng has joined #kolla | 01:19 | |
| *** tobe has joined #kolla | 01:19 | |
| *** Haomeng|2 has quit IRC | 01:19 | |
| loth | that svg just outputs raw into my browser heh | 01:20 |
| *** erkules has joined #kolla | 01:21 | |
| *** erkules_ has quit IRC | 01:23 | |
| loth | sdake: missing mongo/ceilometer mentions in https://review.openstack.org/#/c/181983/5/specs/high-availability.rst are there plans to support that or no? | 01:23 |
| sdake | ya you can ignore tht | 01:23 |
| sdake | we don't currently implement ceilometer | 01:24 |
| *** jtriley has joined #kolla | 01:24 | |
| sdake | looking for someone to tackle that | 01:24 |
| sdake | we have a mongodb container not sure on its status | 01:24 |
| sdake | https://blueprints.launchpad.net/kolla/+spec/ceilometer-container | 01:25 |
| loth | unfortunetly ceilometer is a pretty big requirement for a lot of users :( | 01:25 |
| sdake | no assignee | 01:25 |
| sdake | there is nothign unfortunate about it | 01:25 |
| sdake | its schedueld for liberty | 01:26 |
| sdake | and priority high | 01:26 |
| sdake | i suspect will be tackled in l2 or l3 | 01:26 |
| sdake | ccrouch has a public github with a fork of it partially working | 01:26 |
| sdake | when i said you can ignore that above, i was referring to xvg, not ceilometer | 01:29 |
| sdake | svg that is | 01:30 |
| sdake | loth if you want to review code ,you can add kolla to your watched projects list in gerrit | 01:31 |
| sdake | will help you learn the codebase and structure of the project | 01:32 |
| sdake | and the openstack workflow | 01:32 |
| sdake | ping me if you need help figuring that out ;) | 01:32 |
| jasonsb | sdake: did you decide on mid-cycle meetup days yet? | 01:32 |
| sdake | its not particuarly obvious | 01:32 |
| sdake | jasonb 17th is deadline for voting | 01:32 |
| jasonsb | ah ok | 01:33 |
| sdake | then i need a couple days turnaround with facilities | 01:34 |
| sdake | jasonb settling the date is right at the top of my list :) | 01:34 |
| jasonsb | sdake: no problem at all | 01:34 |
| jasonsb | if we are going to help kolla we need to ramp up regardless of meetup | 01:35 |
| sdake | csco's facilities people need 3 weeks turnaround | 01:35 |
| sdake | err lead time i mean | 01:35 |
| jasonsb | but its tantalizingly close | 01:35 |
| jasonsb | we would like to do some source installs and work out a way to do upgrades | 01:35 |
| jasonsb | and contribute as much as we can along the way | 01:35 |
| sdake | cool there are a few folks working on from source | 01:36 |
| jasonsb | even without upgrades its still good stuff | 01:36 |
| sdake | do you have a preferred container os | 01:36 |
| jasonsb | ubuntu at the moment | 01:36 |
| jasonsb | i wasn't sure what you thought of that | 01:36 |
| sdake | ok well that is a good place to start | 01:36 |
| sdake | fedora, ol, centos are only container oses implemented at the moment | 01:36 |
| jasonsb | and i was also curious to talk to you more about dockering the big tent | 01:36 |
| jasonsb | wrt to fedora | 01:37 |
| sdake | sure what would you like to know | 01:37 |
| *** zhiwei has joined #kolla | 01:37 | |
| jasonsb | to be honest, as we ramp up, we will track closer to head than the distros can | 01:37 |
| jasonsb | so a combination of distro + source is probalby where we will end up | 01:37 |
| sdake | we would absolutely take a container os implementaton for ubuntu | 01:37 |
| jasonsb | excellent | 01:38 |
| sdake | and from source absolutely take that | 01:38 |
| jasonsb | excellent | 01:38 |
| jasonsb | i was sort of thinging kolla was the way to package big tent | 01:38 |
| jasonsb | because we need to ramp up testing | 01:39 |
| sdake | ya we have our roots in rdo but open to source packaging | 01:39 |
| jasonsb | what was the reasoning for rdo? | 01:39 |
| jasonsb | broadest distro ? | 01:39 |
| sdake | i'd prefer to only package things IN the big tent though | 01:39 |
| sdake | open source freely available packaging seemed easy early team were all rpm experts from rht | 01:39 |
| jasonsb | oh sure makes sense | 01:40 |
| sdake | so for example i'd prefer not to package stackforge projects | 01:40 |
| sdake | or containerize them for example | 01:40 |
| sdake | but we haven't set that boundry in any team meetings | 01:40 |
| jasonsb | hmmmmm | 01:41 |
| jasonsb | this will be interesting | 01:41 |
| jasonsb | this is good place for tc + testing to step in and give some guidance | 01:41 |
| jasonsb | you aluded to this in vancouver | 01:41 |
| sdake | if you look at our launchpad it is filled with openstack git namespaced projects that are un-containerized | 01:41 |
| sdake | by tc you mean technical committee? | 01:41 |
| jasonsb | yes | 01:42 |
| sdake | i dont think we really need much guidance there | 01:42 |
| sdake | could you expand on your thoughts? | 01:42 |
| sdake | projects define their own mission not the tc :) | 01:42 |
| jasonsb | i was thinking tc could set tags for things which kolla would containerize | 01:42 |
| jasonsb | (distro-worthy) | 01:42 |
| sdake | our mission is here https://wiki.openstack.org/wiki/Kolla | 01:43 |
| jasonsb | oh, your right, projects do define | 01:43 |
| jasonsb | i was hoping once something was deemed worthy of containerizing, qa would measure it | 01:43 |
| jasonsb | i'm using qa term loosely | 01:44 |
| jasonsb | full disclosure, i'm in tailgate, which wants to find an answer for qa in big-tent | 01:44 |
| sdake | what is tailgate | 01:44 |
| jasonsb | https://etherpad.openstack.org/p/openstack-tailgaters | 01:45 |
| sdake | don't be offended i don't know - too many names | 01:45 |
| jasonsb | not offended at all | 01:45 |
| jasonsb | we got together on friday of vancouver | 01:45 |
| jasonsb | to try to find answers for qa in big-tent | 01:45 |
| jasonsb | its also partially a matter of qa going on inside companies (redhat + canonical + rackspace + cisco, etc) | 01:46 |
| jasonsb | which didn't have a community, and hence alot of duplicated effort | 01:46 |
| jasonsb | i like the idea of combining kolla and thomas goirand's packing-as-upstream along with some kind of qa-in-big-tent | 01:47 |
| jasonsb | its ambitious but the idea is appealing i think | 01:47 |
| sdake | anyone can edit our meeting agenda, suggest introducing your effort to the team at our next team meeting | 01:49 |
| jasonsb | i would love to | 01:49 |
| sdake | i think its too early for us to tackle QA as an objective though | 01:49 |
| jasonsb | lets give tailgate little bit more time | 01:49 |
| jasonsb | i would like to have actionable things | 01:49 |
| jasonsb | and we are just starting down that road | 01:49 |
| jasonsb | but i sure appreciate your support | 01:50 |
| *** dims has quit IRC | 01:50 | |
| jasonsb | in any case, we will participate in irc and weeklies | 01:51 |
| jasonsb | and see what we can do which aligns with your bp's | 01:51 |
| sdake | cool we are going through a fairly large change in architecture around ansible deployment atm | 01:52 |
| sdake | so things are going to change | 01:52 |
| sdake | looks like this version will make it through the guantlet :) | 01:53 |
| sdake | https://review.openstack.org/#/c/189157/ | 01:53 |
| jasonsb | good stuff | 01:54 |
| jasonsb | i hope we can help in effort | 01:54 |
| sdake | cool welcome aboard :) | 01:55 |
| jasonsb | might take some translation in our installer | 01:55 |
| jasonsb | but if we can move over to this model that would be great | 01:55 |
| jasonsb | thank you sir, sure appreciate | 01:55 |
| sdake | enjoy | 01:56 |
| jasonsb | the trick will be to find a way to align ourselves with kolla so we can contribute short-term | 01:57 |
| sdake | you mean the qa part | 01:57 |
| jasonsb | i think we can | 01:57 |
| sdake | i dont have any easy answers there ,we have a pretty full plate for l2 and l3 | 01:57 |
| jasonsb | more on the ansible+source+ubuntu peices | 01:57 |
| sdake | that would be of emmense help | 01:58 |
| jasonsb | ideally we can make our installer for our product kolla compatible | 01:58 |
| jasonsb | we have to ramp up on your bp's more | 01:58 |
| sdake | or just use kolla as an upgtream :) | 01:58 |
| jasonsb | exactly | 01:59 |
| jasonsb | we have to make a few adjustments to get everything to line up | 01:59 |
| jasonsb | but then we can just work on kolla which would be awesome | 01:59 |
| sdake | if you need help seeing an example ol from source container try pinging bmace | 02:00 |
| sdake | feeding time i'm off | 02:02 |
| jasonsb | oh nice, i'll do that | 02:04 |
| *** alisonholloway has quit IRC | 02:08 | |
| bmace | i think pbourke had a review up or already committed the code for the ol from source base container. | 02:20 |
| *** fangfenghua has joined #kolla | 02:25 | |
| *** alisonholloway has joined #kolla | 02:30 | |
| *** fangfenghua has quit IRC | 02:30 | |
| *** bradjones has quit IRC | 02:35 | |
| *** bradjones has joined #kolla | 02:35 | |
| *** bradjones has joined #kolla | 02:35 | |
| *** juggler has quit IRC | 02:39 | |
| *** alisonholloway has quit IRC | 02:50 | |
| *** jtriley has quit IRC | 02:50 | |
| *** jtriley has joined #kolla | 03:20 | |
| *** tobe has quit IRC | 03:20 | |
| *** tobe has joined #kolla | 03:23 | |
| *** vinkman has quit IRC | 03:32 | |
| *** sdake has quit IRC | 03:32 | |
| *** Haomeng|2 has joined #kolla | 03:37 | |
| *** Haomeng has quit IRC | 03:40 | |
| *** jtriley has quit IRC | 03:44 | |
| *** nihilifer has joined #kolla | 03:46 | |
| *** dims has joined #kolla | 03:46 | |
| *** dims has quit IRC | 03:51 | |
| *** fangfenghua has joined #kolla | 03:55 | |
| *** nihilifer has quit IRC | 03:56 | |
| *** alisonholloway has joined #kolla | 04:07 | |
| SamYaple | wow lots of stuff here | 04:08 |
| SamYaple | anyone want to summarize the days conversation for me? | 04:08 |
| SamYaple | i saw a "new containers dont need to support selfconfiguration" | 04:08 |
| SamYaple | that interests me, be cause i could drop in ceph in a heartbeat | 04:08 |
| *** sdake has joined #kolla | 04:17 | |
| sdake | mandre awake ? | 04:22 |
| SamYaple | hey sdake, did yo usee my question above? | 04:23 |
| sdake | no sir | 04:23 |
| sdake | fire away again plz | 04:23 |
| SamYaple | 04:08 < SamYaple> wow lots of stuff here | 04:23 |
| SamYaple | 04:08 < SamYaple> anyone want to summarize the days conversation for me? | 04:23 |
| SamYaple | 04:08 < SamYaple> i saw a "new containers dont need to support selfconfiguration" | 04:23 |
| SamYaple | 04:09 < SamYaple> that interests me, be cause i could drop in ceph in a heartbeat | 04:23 |
| sdake | who said containers dont need to support self config | 04:23 |
| sdake | did you read the spec | 04:24 |
| SamYaple | i think you? hold on lots of scroll back | 04:24 |
| sdake | *new* containers | 04:24 |
| SamYaple | i said new... | 04:24 |
| sdake | oh | 04:24 |
| SamYaple | lol | 04:24 |
| sdake | just woke up | 04:24 |
| sdake | from a nap | 04:24 |
| SamYaple | youre cool | 04:24 |
| sdake | slack plz :) | 04:24 |
| sdake | plz review spec | 04:25 |
| sdake | i'd like it merged asap | 04:25 |
| sdake | and want to fix errors or problems | 04:25 |
| SamYaple | anyway, if *_-new-_* containers dont need self config i could drop ceph in like BAM | 04:25 |
| SamYaple | sdake: im ocmmenting on it now | 04:25 |
| sdake | mandre not around? | 04:25 |
| SamYaple | i dunno | 04:25 |
| sdake | samyaple what do you think of this status idea loth had | 04:36 |
| SamYaple | is loth tyler wilson? | 04:36 |
| sdake | yup | 04:36 |
| SamYaple | im responding to it now | 04:37 |
| SamYaple | but the status is in the wrong location | 04:37 |
| SamYaple | kolla-ansible is a wrapper | 04:37 |
| SamYaple | it doesnt _do_ things | 04:37 |
| SamYaple | it calls things | 04:37 |
| SamYaple | I dont want to have a tool that can't be consumed by native ansible | 04:37 |
| sdake | well your the expert | 04:37 |
| SamYaple | im ok with ansible tasks to pull status info though, which could then be wrapped by kolla-ansible | 04:38 |
| sdake | i saw it and it hit my -ETOOHARD bucket | 04:38 |
| sdake | considering we have about 5 weeks to work with | 04:38 |
| SamYaple | yea it should go on the todo list | 04:38 |
| SamYaple | i dont htink it will be hard | 04:38 |
| SamYaple | but it shouldnt hold up the spec | 04:38 |
| sdake | we can file a wishlist bug for it | 04:38 |
| sdake | if the review hits the repo | 04:38 |
| sdake | or a low priority blueprint | 04:39 |
| *** jtriley has joined #kolla | 04:41 | |
| loth | SamYaple: thats what I meant for it to call, sorry if that wasnt clear | 04:41 |
| sdake | boy tis hot here | 04:41 |
| sdake | 100f at night | 04:41 |
| sdake | rediculous | 04:41 |
| loth | I dont expect the shell script to do anything except interact with our deployment method | 04:41 |
| sdake | time to get out the outdoor cooler | 04:42 |
| SamYaple | loth: no problem, i just wanted to make it clear. Your suggestion should probably be above. I do like the idea alot, but i think its a feature and not a requirement to hold up the spec | 04:42 |
| SamYaple | im a big fan of on call status checks | 04:42 |
| sdake | ya spec is minimum set of things needed to get us rolling | 04:42 |
| loth | as a real-world use of the project, there is no way im running a blind kolla upgrade without knowing things first :) | 04:43 |
| SamYaple | loth: agreed | 04:44 |
| sdake | didn't say we wouldn't do it | 04:44 |
| sdake | specs are guidelines to get people on the same page about implementation | 04:44 |
| sdake | so it doesn't hae to be communicated 10 different times to 10 different people | 04:44 |
| sdake | and we dont end up with dueling implementations :) | 04:44 |
| sdake | but thank you for your contribution - it is valued :) | 04:45 |
| SamYaple | i think the spec will also undergo slight changes in the coming weeks | 04:46 |
| SamYaple | issues we cant anticipate | 04:46 |
| SamYaple | the general idea will stay the same though | 04:46 |
| sdake | guideline | 04:46 |
| SamYaple | ^^ | 04:46 |
| sdake | no need to update teh spec imo :) | 04:46 |
| *** jtriley has quit IRC | 04:46 | |
| SamYaple | if its a major change? | 04:46 |
| sdake | read containerize-openstack.rst | 04:46 |
| sdake | tell me if what we have today is anything like that spec reads :) | 04:46 |
| SamYaple | fair enough. but old info should be remove | 04:47 |
| sdake | i guess if someone wants to update it to the current state that wfm | 04:47 |
| sdake | i dont have time for that :) | 04:47 |
| *** tobe has quit IRC | 04:47 | |
| sdake | as in - its not a priority for me, but for someone else it maybe ;) | 04:48 |
| SamYaple | sdake: reviewed. only one major thing that was a concern to me | 04:49 |
| sdake | taking a look | 04:49 |
| sdake | samyaple instead of writing an essay about why my shell script is bad, could you suggest an alternative wording :) | 04:53 |
| sdake | TIA :) | 04:53 |
| sdake | or check out the review and make changes as you like | 04:54 |
| sdake | the second would be preferred ;) | 04:54 |
| SamYaple | fine | 04:54 |
| SamYaple | be that way | 04:54 |
| sdake | which way? | 04:54 |
| SamYaple | making me do work | 04:54 |
| sdake | been expense reporting days around here, my whole day has been grumpy | 04:55 |
| sdake | 5 hours of beating oracle into submission is not fun | 04:55 |
| sdake | one more reason not to travel! | 04:55 |
| sdake | add yourself as a coauthor while yoru at it since its mostly your ideas :) | 04:56 |
| sdake | are the work items accurate | 04:56 |
| sdake | i'll leave a few comments i noticed as errors too | 04:57 |
| sdake | ok put my comments in ;) | 05:00 |
| sdake | i'd actually do the job myself but i need to ptfo | 05:01 |
| sdake | and i don't want to hold things up longer | 05:01 |
| *** tobe has joined #kolla | 05:07 | |
| *** nihilifer has joined #kolla | 05:26 | |
| *** gfidente has joined #kolla | 05:36 | |
| *** gfidente has joined #kolla | 05:36 | |
| *** tobe has quit IRC | 05:37 | |
| openstackgerrit | Sam Yaple proposed stackforge/kolla: Ansible multi-node specification https://review.openstack.org/189157 | 05:46 |
| *** tobe has joined #kolla | 06:02 | |
| *** shadower has quit IRC | 06:06 | |
| *** shadower has joined #kolla | 06:06 | |
| *** Haomeng|2 is now known as Haomeng | 06:08 | |
| *** alisonholloway has quit IRC | 06:12 | |
| *** sdake has quit IRC | 06:14 | |
| *** inc0 has joined #kolla | 06:16 | |
| inc0 | good morning | 06:16 |
| nihilifer | o/ | 06:17 |
| *** dasm|afk is now known as dasm | 06:21 | |
| SamYaple | hey guys | 06:22 |
| *** fangfenghua has quit IRC | 06:28 | |
| *** bmace has quit IRC | 06:35 | |
| *** bmace has joined #kolla | 06:47 | |
| SamYaple | everyone review the multinode spec? lets get this merged in | 06:53 |
| diga | SamYaple: Hi | 06:54 |
| diga | good spec idea | 06:55 |
| SamYaple | sdake did the heavy lifting, i just did the latest revision | 07:06 |
| SamYaple | diga: any thoughts? | 07:06 |
| diga | Yes, I am going through the spec now | 07:06 |
| SamYaple | oh boy.... | 07:07 |
| SamYaple | ;) | 07:07 |
| diga | :) | 07:07 |
| inc0 | I haven't seen new version yet | 07:09 |
| SamYaple | https://review.openstack.org/189157 | 07:09 |
| inc0 | thank you SamYaple | 07:09 |
| *** mstachow has quit IRC | 07:09 | |
| openstackgerrit | Sam Yaple proposed stackforge/kolla: Ansible multi-node specification https://review.openstack.org/189157 | 07:10 |
| SamYaple | dont freak out guys, just removed whitespace | 07:10 |
| inc0 | getting your ATC the hard way I see? | 07:11 |
| inc0 | ;) | 07:11 |
| SamYaple | eh ivs had ATC | 07:11 |
| SamYaple | ive* | 07:11 |
| SamYaple | no ATC for stackforge anyway | 07:11 |
| inc0 | ahh, damn it | 07:13 |
| *** zhiwei has quit IRC | 07:13 | |
| SamYaple | like i said inc0, docs are a core project | 07:13 |
| SamYaple | contribute to them, its quick and easy | 07:14 |
| inc0 | well, I have heat for that, so I don't worry too much | 07:14 |
| inc0 | I've already got several patches in | 07:14 |
| SamYaple | yea but the docs suck sometimes ;) | 07:14 |
| inc0 | heat too, sometimes, but don't tell anyone;) | 07:15 |
| inc0 | on the other hand, there is nova... | 07:15 |
| *** akwasnie_ has joined #kolla | 07:15 | |
| *** Haomeng|2 has joined #kolla | 07:15 | |
| *** shardy_ has joined #kolla | 07:15 | |
| *** shardy has quit IRC | 07:16 | |
| inc0 | about spec, we haven't yet decided which way will be default | 07:17 |
| SamYaple | itll be a wont | 07:17 |
| SamYaple | vote* | 07:17 |
| SamYaple | during the mettings, sdake put it on the agenda | 07:18 |
| inc0 | on meeting? | 07:18 |
| inc0 | kk | 07:18 |
| SamYaple | dont let it hold up the spec | 07:18 |
| inc0 | I'll try to attend, but that's kinda hard for me...1am | 07:18 |
| SamYaple | its basically 1am for me too, i work 3rd | 07:18 |
| *** Haomeng has quit IRC | 07:18 | |
| inc0 | I think I'll just tell sdake my feelings before since I already know what I want:) | 07:19 |
| *** shardy_ has quit IRC | 07:21 | |
| *** shardy has joined #kolla | 07:21 | |
| SamYaple | smae | 07:21 |
| *** fangfenghua has joined #kolla | 07:23 | |
| *** Haomeng|2 is now known as Haomeng | 07:24 | |
| *** bradjones has quit IRC | 07:30 | |
| *** bradjones has joined #kolla | 07:36 | |
| *** bradjones has joined #kolla | 07:36 | |
| *** mickt has joined #kolla | 07:38 | |
| *** tobe has quit IRC | 07:40 | |
| jmccarthy | morning | 07:46 |
| *** tobe has joined #kolla | 07:47 | |
| diga | SamYaple: see this - http://paste.openstack.org/show/294841/ | 07:49 |
| diga | I am installing kolla where my openstack is already setup | 07:49 |
| SamYaple | morning jmccarthy | 07:49 |
| SamYaple | fangfenghua: you around? | 07:49 |
| diga | Getting this error | 07:49 |
| diga | now able to pull all the images | 07:50 |
| SamYaple | diga: yea keystone cli is deprecated | 07:50 |
| SamYaple | its been that way for a while | 07:50 |
| SamYaple | openstack is the new cli | 07:50 |
| diga | SamYaple: okay | 07:50 |
| diga | do I need to download it manually | 07:51 |
| SamYaple | python-keystoneclient will sitll be used for imports (but the cli portiion is no longer being developed) | 07:51 |
| diga | but I never got this error before | 07:51 |
| SamYaple | im pretty sure this needs a patch to resolve | 07:51 |
| SamYaple | let me check hte code | 07:51 |
| SamYaple | diga: it is probably a package update | 07:52 |
| *** shardy_ has joined #kolla | 07:52 | |
| diga | okay | 07:52 |
| diga | its issue only related to keystone CLI, right ? | 07:52 |
| *** shardy has quit IRC | 07:53 | |
| diga | SamYaple: then CLI portion should be removed here, otherwise it will give error everytime | 07:54 |
| SamYaple | correct | 07:55 |
| *** shardy_ has quit IRC | 07:57 | |
| *** shardy has joined #kolla | 07:58 | |
| *** shardy has quit IRC | 07:58 | |
| *** shardy has joined #kolla | 08:01 | |
| diga | SamYaple: | 08:02 |
| diga | SamYaple: Heyy | 08:02 |
| diga | my setup is ready now, now heading with Ansible multinode | 08:02 |
| *** tobe has quit IRC | 08:06 | |
| *** jmccarthy has quit IRC | 08:13 | |
| *** tobe has joined #kolla | 08:16 | |
| *** jmccarthy has joined #kolla | 08:18 | |
| inc0 | SamYaple, akwasnie_ and me were just having a discussion about installation from source | 08:22 |
| inc0 | do you have a moment to discuss this topic? | 08:22 |
| SamYaple | maybe... | 08:23 |
| inc0 | thing is, we want for people to choose which way they want to deploy it right? source or packages | 08:24 |
| SamYaple | kinda | 08:24 |
| inc0 | but we can't make this kind of decision while container build, because there is no openstack.env there | 08:24 |
| akwasnie_ | hi | 08:25 |
| inc0 | and we don't want to pull sources from github on deploy, because that would be...suboptimal | 08:25 |
| SamYaple | right so the source build structure is only for people wanting to deploy from source | 08:25 |
| SamYaple | kolla wont build any images for it | 08:25 |
| SamYaple | kolla will only build "official" binary images | 08:25 |
| SamYaple | but source built containres should be able to be deployed the same way | 08:25 |
| inc0 | well, that might also be hard if we'd want to use tripleo. TripleO wants sources, and I kinda agree | 08:26 |
| inc0 | especially if we consider multi-os | 08:26 |
| SamYaple | so triple-o can build there own containers? | 08:26 |
| SamYaple | we dont build the containers with the deploy tools | 08:26 |
| inc0 | I guess at some point they will | 08:26 |
| SamYaple | we dont deploy from source at runtime either | 08:27 |
| inc0 | yeah, but we're kinda coupled with os package repos | 08:27 |
| inc0 | and that might bite us | 08:27 |
| SamYaple | i would be ok with a kolla "official" from source container, but that isnt going to be configurable | 08:27 |
| SamYaple | itll be tags or master | 08:28 |
| inc0 | so we'd ditch yum based builds alltogether...which I'd like, but that would be hell lot of work | 08:28 |
| SamYaple | no | 08:28 |
| SamYaple | we can support all as automated builds | 08:28 |
| SamYaple | centos-binary-base | 08:29 |
| SamYaple | ubuntu-source-base | 08:29 |
| SamYaple | ubuntu-binary-base | 08:29 |
| SamYaple | thats are uniquie images | 08:29 |
| inc0 | yeah, but Dockerfiles of services would need that kind of info | 08:29 |
| SamYaple | why | 08:29 |
| inc0 | because there is RUN yum install ... | 08:29 |
| inc0 | ofc we can have keystone-binary and keystone-source containers | 08:30 |
| inc0 | but that would double number of containers | 08:30 |
| inc0 | if we add multihost, it goes exponential | 08:30 |
| *** mstachow has joined #kolla | 08:30 | |
| SamYaple | i dont think you are understanding the structure | 08:31 |
| SamYaple | the dockerfiles are unique | 08:31 |
| SamYaple | always | 08:31 |
| SamYaple | the only thing binary/source share are some scripts | 08:31 |
| SamYaple | scripts dont install packages | 08:31 |
| SamYaple | multihost wont require different containers (that defeats the purpose) | 08:32 |
| inc0 | multi-os, my mistake | 08:32 |
| SamYaple | so for each "{distro}-{type}-" iteration would be unquie containers yes | 08:32 |
| inc0 | yeah, that's what I'm referring to | 08:32 |
| inc0 | we want to add new base OS, we have to make bunch of new containers | 08:33 |
| SamYaple | yea os I imagine that we will only hard support Ubuntu and Centos binary and maybe source | 08:33 |
| SamYaple | the rest may break | 08:33 |
| inc0 | and I mean a lot if we consider big tent | 08:33 |
| SamYaple | thats the only way to go about it though | 08:33 |
| SamYaple | and its a good way too in my opinion | 08:33 |
| inc0 | there is always some possible magic in ./build | 08:33 |
| SamYaple | thats a bad idea in my opinion | 08:34 |
| SamYaple | its not nearly as flexible and very confusing | 08:34 |
| mstachow | good morning :) | 08:34 |
| SamYaple | morning mstachow | 08:34 |
| * mstachow exited because of FF VII ! | 08:34 | |
| SamYaple | mstachow: wait whats this news? | 08:35 |
| inc0 | yeah, I guess that would be hard. but I don't like idea of shitloads of containers as well | 08:35 |
| SamYaple | inc0: the containers/Dockerfiles are the easy part | 08:35 |
| inc0 | but scripts may differ as well | 08:35 |
| mstachow | SamYaple Mariadb 10 is working fine. I've got broken network configuration. | 08:35 |
| inc0 | in terms of file locations and so on | 08:35 |
| SamYaple | i looked into this inc0, the files would be only slightly different in _some_ cases, not the majority | 08:36 |
| SamYaple | that can be fixed with a simple if then | 08:36 |
| SamYaple | because we are calling the binary directly, the distro built init scripts arent used | 08:36 |
| SamYaple | so way less differences | 08:36 |
| *** erkules has quit IRC | 08:36 | |
| *** erkules has joined #kolla | 08:36 | |
| openstackgerrit | Michal Stachowski proposed stackforge/kolla: Galera container https://review.openstack.org/187225 | 08:37 |
| inc0 | making default of source installations might give us some additional flexibility | 08:37 |
| SamYaple | inc0: with the stable release naming thread going on upstream, that may be what we do | 08:37 |
| SamYaple | but we dont have source containers so it wont be the default for liberty that can be almost gauranteed | 08:38 |
| mickt | hi guys, a quick Q: I've just done dev-quickstart and the *-data containers show Exited - | 08:51 |
| mickt | ecdc53f6eb5a kollaglue/centos-rdo-mariadb-data:latest "/bin/bash" 9 minutes ago Exited (0) 9 minutes ago | 08:51 |
| *** zhiwei has joined #kolla | 08:52 | |
| mickt | ea3869bc8283 kollaglue/centos-rdo-nova-compute-data:latest "/bin/true" 45 minutes ago Exited (0) 45 minutes ago compose_computedata_1 | 08:52 |
| mickt | No logs for these that I can find and "docker-compose logs ecdc53f6eb5a" returns the following: | 08:52 |
| mickt | Can't find a suitable configuration file. Are you in the right directory? | 08:52 |
| mickt | Supported filenames: docker-compose.yml, docker-compose.yaml, fig.yml, fig.yaml | 08:52 |
| mickt | Anyone hit this and know how to resolve? | 08:52 |
| *** zhiwei has left #kolla | 08:53 | |
| SamYaple | mstachow: that is functioning as designed | 08:53 |
| SamYaple | its a "data" container, its just to reserve the space | 08:53 |
| SamYaple | i will be turning that into a "sleep" command later so the containers stay active | 08:53 |
| SamYaple | mickt: ^^ | 08:54 |
| pbourke | mickt: also you need to specify a yml file to compose | 08:55 |
| pbourke | e.g. docker-compose -f compose/maria.yml logs | 08:55 |
| mickt | cheers to both | 09:02 |
| inc0 | duh. you made me sad person SamYaple | 09:09 |
| inc0 | but I have a gut feeling that source install can be done right somehow | 09:09 |
| inc0 | maybe dynamic Dockerfile generation? | 09:09 |
| SamYaple | inc0: i like generated things, but will that really be more effiecent? | 09:11 |
| SamYaple | and my word isnt law inc0 ;) | 09:11 |
| inc0 | well what I essentialy mean, community likes to add things. Look, we're merging oraclelinux now, and its good! | 09:12 |
| inc0 | and at some point I suspect we'll have shitloads of more or less supported base images | 09:12 |
| SamYaple | define supported | 09:12 |
| SamYaple | i imagine there will be a regression test in the future and i bet we only support centos/ubuntu for regression and major tests | 09:13 |
| inc0 | you can pull our repo and set up working openstack at any point | 09:13 |
| inc0 | what I essentially mean, there will be shitloads of base distros because each corpo has their own favorite distro and ops will push to have their own favorite distro | 09:14 |
| nihilifer | the problem in having many base images will be responsibility for supporting concrete containers in some distros | 09:14 |
| inc0 | and if we force adding new distros with *every* single container together...even reviewing this thing will be huge pain | 09:14 |
| nihilifer | will we require making images for centos, ubuntu, oracle for every new contributor? | 09:14 |
| SamYaple | how else would you propose to do it? | 09:15 |
| inc0 | nihilifer, that's exactly what I'm reffering to | 09:15 |
| SamYaple | code generation will be the same amount of work, just more complicated | 09:15 |
| inc0 | well, puppet did that by providing an abstraction layer of sort | 09:15 |
| SamYaple | sure. but this is layers and complication | 09:15 |
| SamYaple | it is still the same amount of work, just more inaccessible | 09:16 |
| inc0 | less than shitloads of containers imho | 09:16 |
| nihilifer | making generated Dockerfiles will be hard, but will not break stuff with responsibility | 09:16 |
| nihilifer | and will not make some distros less supported | 09:16 |
| SamYaple | having seperate containers will gaurantee things wont break | 09:16 |
| inc0 | with each new image you'll expose its API, like "install_package" | 09:17 |
| inc0 | I disagree | 09:17 |
| inc0 | we make container upgrade | 09:17 |
| inc0 | and some base OS won't like it | 09:17 |
| inc0 | by the time you make all OS happy, new upgrade will be rolling out | 09:17 |
| SamYaple | what you guys are proposing is alot of overhead. if you want to write the code and make a spec I am cool with that. I dont see it being simpilier or more useable, but I would love to see it | 09:18 |
| inc0 | I'm not saying its the way to go | 09:18 |
| nihilifer | separate Dockerfiles are simplier IMO only now | 09:18 |
| *** dims has joined #kolla | 09:18 | |
| inc0 | but I don't think having exponential number of dockerfiles is the way as well | 09:18 |
| nihilifer | imagine creating new containers for i.e. suse after i.e. year | 09:19 |
| nihilifer | when kolla will be much more complex | 09:19 |
| inc0 | I guess that's good thing to discuss broadly and find best way early on | 09:19 |
| SamYaple | oh you must be under the impression that to build a new container you must support all distros | 09:19 |
| SamYaple | that is not the case | 09:19 |
| inc0 | rhel probably will be rolling soon, even tho it might be similar to centos | 09:19 |
| inc0 | ubuntu/debian | 09:19 |
| inc0 | but you must support distros this container is already supporting | 09:20 |
| inc0 | essentially what I mean is to somehow decopule support of service containers from support of base distros | 09:20 |
| SamYaple | as I said, "support" is relative. I see ubuntu/centos being first class citizens, the rest would not be | 09:21 |
| inc0 | so you have to fix a bug only once | 09:21 |
| SamYaple | a bug that only exist in one distro is far more likely | 09:21 |
| inc0 | yes, but we'll have lots of these too | 09:21 |
| inc0 | essentially, we'll be fighting with dependencies a lot | 09:22 |
| inc0 | ask ceilometer how they manage notifications...its just one type of message, but it happends every service has their own schema and it changes | 09:22 |
| SamYaple | what do you propose | 09:22 |
| inc0 | and it's still around openstack | 09:22 |
| inc0 | I need to think. I'll come back with something later on | 09:23 |
| SamYaple | sure | 09:23 |
| inc0 | that's non-trivial at best | 09:23 |
| *** dims has quit IRC | 09:23 | |
| SamYaple | for the record, dockerfile should be really simple for what we are doing. scripts too. I dont see there being much overhead at all | 09:24 |
| inc0 | well, it should, but even file locations will be pain | 09:25 |
| inc0 | and all the small differences | 09:25 |
| SamYaple | like what | 09:25 |
| SamYaple | if we are calling the binary, we are calling the configs in most cases too | 09:25 |
| SamYaple | the differences are really minimal | 09:25 |
| inc0 | I'm not saying they are big, I'm saying there will be lot of them | 09:26 |
| SamYaple | there are no config differences between ubuntu and centos, I verified by comparing kolla to yaodu | 09:26 |
| SamYaple | al lthe binaries are the same, al lthe configs are too | 09:26 |
| inc0 | package naming might slightly differ | 09:26 |
| inc0 | versions | 09:26 |
| inc0 | in repo | 09:26 |
| SamYaple | hence seperate dockerfiles | 09:26 |
| inc0 | yeah, but for example you want to deploy nova compute | 09:27 |
| inc0 | and new feature comes with libvirt xxx | 09:27 |
| inc0 | and as it happends this version is default in 50% of distros | 09:27 |
| inc0 | and ok, we might not use this feature, but that's suboptimal | 09:28 |
| SamYaple | this scenario makes no sense | 09:28 |
| SamYaple | use it or dont is a config option the user has control over at time of deploy | 09:28 |
| inc0 | allright, different PATH might bite us in scripts | 09:29 |
| SamYaple | thats why i call /usr/bin/env | 09:29 |
| inc0 | I mean, it all will be solvable | 09:30 |
| inc0 | even easily solvable | 09:30 |
| inc0 | and maybe its just a matter of creation list of howtos of script writing | 09:30 |
| inc0 | and small tools to make stuff easyier | 09:30 |
| SamYaple | no the scripts are across all containers. that wouldnt add overhead from the many dockerfiles | 09:30 |
| inc0 | python is for that, because it has several os-compatible abstractions in stdlib | 09:31 |
| SamYaple | those changes would be need anyway | 09:31 |
| inc0 | let's pay this topic a bit more thought | 09:33 |
| inc0 | and revisit it later with more people | 09:33 |
| inc0 | maybe create a spec like multihost | 09:34 |
| SamYaple | that would be the way to go | 09:34 |
| *** tobe has quit IRC | 09:46 | |
| *** tobe has joined #kolla | 09:56 | |
| *** vbel has quit IRC | 10:39 | |
| *** vbel has joined #kolla | 10:40 | |
| *** tobe has quit IRC | 10:50 | |
| *** tobe has joined #kolla | 10:51 | |
| *** tobe has quit IRC | 10:56 | |
| *** rhallisey has joined #kolla | 11:14 | |
| openstackgerrit | Michal Jastrzebski (inc0) proposed stackforge/kolla: Keepalived container https://review.openstack.org/187981 | 11:15 |
| *** ChanServ sets mode: +o rhallisey | 11:15 | |
| rhallisey | morning | 11:15 |
| inc0 | hello rhallisey | 11:16 |
| mstachow | o/ rhallisey | 11:17 |
| jmccarthy | o/ | 11:20 |
| *** dims has joined #kolla | 11:20 | |
| rhallisey | hey! | 11:22 |
| *** dims has quit IRC | 11:25 | |
| SamYaple | hey rhallisey | 11:25 |
| SamYaple | new spec is out. please review | 11:26 |
| SamYaple | need ot get it merged | 11:26 |
| inc0 | we need to look how to decouple tripleo's config generation from different logic | 11:26 |
| inc0 | like package installation | 11:26 |
| SamYaple | inc0: can you elaborate on that? | 11:27 |
| inc0 | SamYaple, yesterday we had a talk with slagle, and we agreed that crudini won't be long term solution for tripleo as well (Steven included that into spec) | 11:27 |
| SamYaple | i read some of that, yes | 11:28 |
| inc0 | tripleo will want to place config outside container, which is cool | 11:28 |
| SamYaple | awesome | 11:28 |
| inc0 | but we need to check out puppet scripts if we can limit then to *just* create config | 11:28 |
| inc0 | not do any other installations, app running and so on | 11:28 |
| SamYaple | which scripts? | 11:28 |
| inc0 | that would be container role | 11:29 |
| *** dims has joined #kolla | 11:29 | |
| inc0 | that's one thing I need to find out, I don't know tripleo flow well enough to point you to exact place and problems | 11:29 |
| SamYaple | so something to keep in mind. ansible is able to track when something tchanged and trigger a task. if you are making config changes external, ansible will not know it needs to restart the container | 11:29 |
| inc0 | maybe there won't be any at all | 11:29 |
| rhallisey | inc0, I'm also still investigating this | 11:29 |
| rhallisey | I'm not sure if I like the plan yet | 11:29 |
| inc0 | of crudini removal? | 11:30 |
| inc0 | you were one who wanted to push full configs into container in the first place;) | 11:30 |
| rhallisey | correct I think that's a good feature, but it needs to be used correctly | 11:30 |
| inc0 | agree on that, I think best way would be for tripleo to just create config | 11:31 |
| rhallisey | one of the advantages to having containers is they can come with config build in | 11:31 |
| inc0 | and let heat deploy container | 11:31 |
| inc0 | why is that an advantage? | 11:31 |
| SamYaple | rhallisey: how will that work for multiple nodes though? | 11:31 |
| slagle | i didn't exactly say crudiini wouldn't be the long term solution for tripleo | 11:31 |
| rhallisey | removes some complication | 11:32 |
| inc0 | immutability you mean? | 11:32 |
| slagle | merely that i don't know that we've picked the long term solution | 11:32 |
| SamYaple | config built in just doesnt work large scale | 11:32 |
| rhallisey | but, I know that might not be possible if you want to customize your setup | 11:32 |
| inc0 | well, we kinda agree that crudini doesn't seem like the way to go - no big decissions yet | 11:33 |
| rhallisey | inc0, when I came up with the idea to push in config the goal was to try and stockpile containers that can be consumed | 11:33 |
| rhallisey | try and hit 95% of the use cases | 11:33 |
| inc0 | but you can't really do that upstream | 11:34 |
| inc0 | addresses may differ | 11:34 |
| inc0 | if anything | 11:34 |
| rhallisey | ya so there will be a few things that will change across all containers | 11:34 |
| rhallisey | crudini can finish that off | 11:34 |
| SamYaple | rhallisey: you back from pto? | 11:35 |
| rhallisey | SamYaple, ya | 11:35 |
| SamYaple | cool | 11:35 |
| inc0 | essentially what I'm saying, I don't want to be responsible for configs, that's a swamp that can pull you in | 11:35 |
| SamYaple | inc0: agreed | 11:35 |
| SamYaple | i just spent an hour going over the new "bare minimum options" needed to run kilo | 11:35 |
| inc0 | TripeO did fine job sorting this thing out, lots of hours went to this config generation | 11:35 |
| SamYaple | and thats after i had a template for juno | 11:35 |
| SamYaple | lots of things changed | 11:35 |
| inc0 | I'd be keen to take laverage on this | 11:36 |
| rhallisey | inc0, I do agree to, but I'm not saying kolla generates all these. That's what the config files are for | 11:36 |
| rhallisey | but kolla hosts those containers | 11:36 |
| rhallisey | in its namespace | 11:36 |
| inc0 | but, as you deploy base system, for example by ironic | 11:36 |
| inc0 | that's not too big of an overhead to include one additional folder with configs | 11:36 |
| inc0 | and containers on deploy will consume this | 11:36 |
| inc0 | and we will provide runtime without configs. | 11:37 |
| inc0 | that's basic idea I guess | 11:37 |
| inc0 | what do you think? | 11:38 |
| SamYaple | +1 | 11:38 |
| rhallisey | the way I envisioned kolla to be a 'central hub' of containers | 11:38 |
| rhallisey | we provide the basic and you built the more advanced | 11:38 |
| rhallisey | but we host them | 11:38 |
| inc0 | problem is, installators are hard. Bacause of all these little decisions | 11:39 |
| inc0 | I'd rather let someone else do them. Or kinda-exsternal-to-kolla Ansible | 11:39 |
| inc0 | instead of providing container to deploy, we'll provide container, you provide config, and deploy that | 11:40 |
| inc0 | kinda like with stack and environment in heat | 11:40 |
| inc0 | template and environment* | 11:40 |
| rhallisey | it wasn't 100% what I had in mind originally, but I understand your point | 11:41 |
| SamYaple | has anyone suggested using kubernetes? | 11:42 |
| inc0 | ew... | 11:42 |
| SamYaple | im kidding, dont hurt me | 11:42 |
| inc0 | well I was going to play with tectonic+kolla | 11:42 |
| rhallisey | I don't think it has all the support we need | 11:42 |
| rhallisey | kube that is | 11:43 |
| rhallisey | brb | 11:43 |
| SamYaple | rhallisey: interestingly, the "we provide runtime, you provide configs" doesn't break kubernetes or something like coreos fleet | 11:43 |
| SamYaple | i like that | 11:43 |
| inc0 | it's kinda elegant approach in my opinion...and leaves us a lot of space to "wash our hands" | 11:45 |
| inc0 | let ops do configs, we'll never be better at this than people who hand tailored these for last few years | 11:46 |
| rhallisey | my proposal is similar in that we don't have to be responsible for all containers. I just want to encourage people to share them and to avoid a sometimes scary config setup | 11:48 |
| rhallisey | whenever possible | 11:48 |
| inc0 | we can still do that - we'll have ansible module | 11:49 |
| inc0 | and people can commit to ansible part, and this will generate configs | 11:49 |
| rhallisey | but the difference is what we encourage people to use as their primary use case of kolla | 11:49 |
| rhallisey | do we encourage them to just make their own config or pull form our stash to see if some work for you and if not build your own | 11:50 |
| inc0 | for me it's like | 11:50 |
| inc0 | hey, you want to try this out? use ansible, it will do this with one command | 11:50 |
| inc0 | you want to really deploy it? We get that configs are detailed enough for you to play with, here they are | 11:51 |
| inc0 | put them on git, make gerrit over them | 11:51 |
| SamYaple | hey you see random configs from an article that you think fixes your problem and you want to try them out? copy/paste them | 11:51 |
| SamYaple | i like that part anyway | 11:52 |
| rhallisey | I do too that's why I want this method | 11:52 |
| rhallisey | the way were telling people to use it is slightly different | 11:53 |
| SamYaple | how so? | 11:53 |
| rhallisey | but it's find. It's just my opinion | 11:53 |
| rhallisey | I want them to pull containers with config instead of building it | 11:54 |
| inc0 | I think we can get good marketing around that | 11:54 |
| inc0 | it will boil down to how our initial howtos in docs will look like | 11:54 |
| SamYaple | rhallisey: oh sure | 11:54 |
| rhallisey | I guess it's pretty similar | 11:54 |
| rhallisey | I don't know | 11:55 |
| rhallisey | inc0, yes exactly | 11:55 |
| inc0 | that's something we need to think about, agree | 11:55 |
| inc0 | after that, people will know how that tool works anyway, so they can make their own educated decisions | 11:55 |
| SamYaple | the initial ansible deploy can be one command with no config changes (except for the host inventory) | 11:56 |
| SamYaple | i have all the barebones templates prepared | 11:56 |
| inc0 | with good tutorial of kolla+ansible, I think its achievable to make initial deploy easy enough | 11:56 |
| *** jtriley has joined #kolla | 11:56 | |
| *** athomas has quit IRC | 11:56 | |
| inc0 | so we can keep ease of use and config decoupled | 11:56 |
| inc0 | anyway, lunch time for me, bbl | 11:57 |
| *** inc0 is now known as inc0|afk | 11:58 | |
| *** fangfenghua has quit IRC | 11:58 | |
| *** jtriley has quit IRC | 12:01 | |
| *** athomas has joined #kolla | 12:05 | |
| *** dwalsh has joined #kolla | 12:18 | |
| *** dwalsh has quit IRC | 12:36 | |
| *** diogogmt has quit IRC | 12:54 | |
| *** nihilifer has quit IRC | 13:00 | |
| *** dwalsh has joined #kolla | 13:14 | |
| *** Haomeng|2 has joined #kolla | 13:16 | |
| *** inc0|afk is now known as inc0 | 13:19 | |
| *** Haomeng has quit IRC | 13:19 | |
| *** dasm is now known as dasm|afk | 13:20 | |
| *** jtriley has joined #kolla | 13:31 | |
| *** sdake has joined #kolla | 13:32 | |
| *** sdake has quit IRC | 13:32 | |
| *** sdake has joined #kolla | 13:33 | |
| inc0 | hi sdake, mind if I start bugging you from very morning? | 13:34 |
| sdake | morning | 13:34 |
| sdake | inc0 give me 5 minutes for my eyes to warm up | 13:35 |
| inc0 | counting | 13:35 |
| inc0 | ;) | 13:35 |
| sdake | inc0 did you review the ansible-multi spec | 13:35 |
| sdake | if not go do that | 13:35 |
| inc0 | yes, +1 from me | 13:35 |
| sdake | cool | 13:35 |
| inc0 | also, if I couldn't attend to todays meeting (hours are horrible for me..) I want to cast my vote on default config option | 13:36 |
| inc0 | and that's 3rd - bind-copyalways | 13:36 |
| openstackgerrit | Michal Stachowski proposed stackforge/kolla: Galera container https://review.openstack.org/187225 | 13:39 |
| sdake | today is tuesday | 13:39 |
| sdake | we have meetings on wednesday | 13:39 |
| inc0 | or even thursday in my case;) | 13:40 |
| inc0 | yeah, my mistake | 13:40 |
| sdake | mandre awake still? | 13:45 |
| mandre | hi sdake, I'm here now | 13:47 |
| sdake | ok inc0 shoot | 13:49 |
| *** nihilifer_ has joined #kolla | 13:49 | |
| inc0 | soo, along with akwasnie_ and mstachow today we brainstormed around installing from source | 13:49 |
| inc0 | because there is a problem - we want to install everything on container build | 13:50 |
| sdake | agree, how is that a problem | 13:50 |
| inc0 | and at the same time we can't really parametrize build | 13:51 |
| sdake | we have unique docker files for everythhing | 13:51 |
| inc0 | yeah, and that's that...we'll have expontential number of Dockerfiles | 13:51 |
| sdake | exponential is wrong word :) | 13:51 |
| inc0 | number of base os * 2 (source|binary) * number of services | 13:51 |
| sdake | right | 13:52 |
| inc0 | so basically there will be number of services ** (2*number of os) | 13:52 |
| sdake | ok | 13:52 |
| sdake | dockerfiles are easy to write | 13:52 |
| sdake | its the start.sh that takes all the time | 13:52 |
| *** gfidente is now known as gfidente|afk | 13:52 | |
| inc0 | that's also may slightly differ | 13:53 |
| pbourke | inc0: if the start.sh differ slightly we can use if/else cases | 13:53 |
| inc0 | our idea is to have docker file with placeholer like ENV %%deploy_from_source%% | 13:53 |
| inc0 | and if we call ./build --source our build script will add this env to dockerfile | 13:54 |
| inc0 | and then we call RUN install.sh | 13:54 |
| inc0 | and inside install.sh there will be logic to install from source or from packages depending on this env | 13:54 |
| inc0 | since installation from source will be somewhat similar on every os | 13:54 |
| inc0 | we could even try to decouple it alltogether | 13:55 |
| inc0 | pbourke, we'll have lots of if/elses;) | 13:56 |
| inc0 | but that's problem of multios, which isn't trivial itself | 13:56 |
| sdake | i disagree ont he lots of conditions required | 13:56 |
| sdake | lets tackle one problem at a time shallw e :) | 13:56 |
| sdake | which is the dockerfiles | 13:56 |
| sdake | I haven't used ENV before let me read the docs | 13:56 |
| inc0 | it just adds environment val | 13:57 |
| inc0 | and it's there even for container build afaik | 13:57 |
| nihilifer_ | doing RUN install.sh has one big disadvantage - we lose caching commands by Docker | 13:58 |
| sdake | inc0 are you suggesting build at runtime? | 13:58 |
| inc0 | nihilifer_, but we can't use if in dockerfile as well | 13:58 |
| inc0 | no, I'm suggesting build it once with or without this variable | 13:58 |
| inc0 | and while building, logic will slightly differ depends on this env value | 13:59 |
| nihilifer_ | I see also another problem with such parametrized Dockerfile. how we will build it as prebuilt container in registry? | 14:00 |
| sdake | RUN install.sh is runtime building | 14:00 |
| sdake | we don't want to do runtime buiding | 14:00 |
| sdake | that slows down things considerably | 14:00 |
| mandre | sdake: i'm about to take off, anything you wanted? | 14:00 |
| sdake | mandre sec i sent you private mesages but apparently to wrong person | 14:01 |
| SamYaple | nihilifer_: losing the command caching history of docker is not a concern in my opinion | 14:02 |
| nihilifer_ | inc0: to sum it up, I agree that we shoudn't have as many wxplicitly written Dockerfiles as currently. but I also think we should find another solution that making RUN something.sh with strong env dependencies | 14:02 |
| nihilifer_ | explicitly* | 14:02 |
| SamYaple | for the record, I like the "number of base os * 2 (source|binary) * number of services" for Dockerfiles, it will not duplicate scripts | 14:03 |
| inc0 | I'd guess most of Dockerfiles will actually be copypasta with little differences | 14:04 |
| SamYaple | inc0: i think you are wrong | 14:04 |
| SamYaple | most of them will be uniqie to distros | 14:04 |
| inc0 | as I said, installation from source on ubuntu won't be THAT different from one on centos | 14:04 |
| SamYaple | right, for the openstack sources | 14:04 |
| SamYaple | and we can talk about that for sure | 14:04 |
| SamYaple | we may be able to keep _those_ files the same | 14:04 |
| sdake | we should follow the same model openstack or not for all dockerfiles | 14:05 |
| inc0 | I don't think we'll install other stuff from sources tho? | 14:05 |
| SamYaple | sdake: fair point. i do not feel as strongly, but i wont fight that point | 14:05 |
| SamYaple | inc0: the mariadb container will not be from source. niether will the pass. or the dependencies. or rabbitmq | 14:05 |
| sdake | so i udnerstand the concern | 14:05 |
| sdake | lets take a real world example | 14:05 |
| sdake | ol, centos, fedora, rhel, ubuntu, debian | 14:06 |
| sdake | that is 6 distros | 14:06 |
| openstackgerrit | Michal Stachowski proposed stackforge/kolla: Galera container https://review.openstack.org/187225 | 14:06 |
| sdake | and we have about 30-40 containers | 14:06 |
| SamYaple | centos/fedora/rhel count as one due to symlink'd Dockerfiles (except for the base) | 14:06 |
| *** nihilifer_ is now known as nihilifer | 14:07 | |
| *** kevsi has joined #kolla | 14:07 | |
| inc0 | SamYaple, that will create symlink spaghetti in many cases :/ | 14:07 |
| SamYaple | inc0: i dont like symlink spaghetti either | 14:07 |
| SamYaple | but i like it better than generated dockerfiles | 14:07 |
| inc0 | and 99% may not be different...but there will always be 1% | 14:08 |
| sdake | my calculator is not working | 14:08 |
| SamYaple | inc0: you have very valid points. And I want to rework the build system. But I dont think it will happen before liberty with the massive amount of multinode we need done | 14:08 |
| sdake | what is 6^40 | 14:08 |
| *** dwalsh has quit IRC | 14:08 | |
| SamYaple | uhhh alot | 14:08 |
| *** diogogmt has joined #kolla | 14:09 | |
| SamYaple | 1.33674945388437 * 1031 | 14:09 |
| sdake | that is the # of docker files we are talking about? | 14:09 |
| SamYaple | 1.33674945388437 * 10^31 | 14:09 |
| inc0 | :D | 14:09 |
| SamYaple | no it is not | 14:09 |
| rhallisey | lo | 14:09 |
| rhallisey | lol | 14:09 |
| sdake | lets get a handle on how many docker files we are talking about | 14:09 |
| SamYaple | 6*40 | 14:09 |
| sdake | can someone put a real # on it plaz | 14:09 |
| sdake | my brain doesn't operate at 7am | 14:09 |
| inc0 | 13367494538843734067838845976576 | 14:10 |
| *** diogogmt has quit IRC | 14:10 | |
| sdake | so 240 dockerfiels? | 14:10 |
| SamYaple | sdake: correct | 14:10 |
| sdake | ok, well that is a pita but manageable | 14:10 |
| SamYaple | but i disagree with the numbers for various reasons | 14:10 |
| sdake | just thinking worst case | 14:11 |
| sdake | if we had to maintain 300 docker fies, coudl we do it | 14:11 |
| sdake | the answer is yes | 14:11 |
| inc0 | thing I'm more afraid will be cost of applying new services | 14:11 |
| SamYaple | I think we should have a matrix of "supported" distros, Ubuntu/Centos would be first clase citizens for example | 14:11 |
| sdake | if we had to maintain 300 start.sh could we do it | 14:11 |
| sdake | not sure | 14:11 |
| inc0 | because testing every new container on every supported os will be high | 14:11 |
| sdake | i think we want to be careful about throwing around the word support | 14:11 |
| sdake | support is something downstream do | 14:12 |
| SamYaple | if we require a new container to be implemented across all distros, this will never work | 14:12 |
| inc0 | so we'll end up with containers that only support subset of these...pretty random at the end | 14:12 |
| sdake | we will "maintain" :) | 14:12 |
| SamYaple | not if we treat ubuntu and centos as "maintained" | 14:12 |
| SamYaple | yea | 14:12 |
| SamYaple | so ubuntu/centos require these containers, the rest are wishlist/best effort | 14:13 |
| sdake | there isn't even ubuntu code i nthe code base atm | 14:13 |
| inc0 | but then we shouldn't agree on any other distro in core...maybe something like contrib | 14:13 |
| SamYaple | i know, but you get teh point | 14:13 |
| mandre | i'm off good night | 14:13 |
| mandre | zZZ | 14:13 |
| SamYaple | night mandre | 14:13 |
| sdake | we have a strong contigent from oracle who has an interestin ol | 14:13 |
| inc0 | gn mandre | 14:13 |
| sdake | think ol should be first class as well, assuming the oracle cats intend to maintaint hem | 14:13 |
| inc0 | I'm pretty sure RH people would like to see rhel there as well | 14:13 |
| sdake | night mandre thanks | 14:14 |
| SamYaple | fair enough, but these are distinctions we can make to keep the number of maintained dockerfiles ot a minimum | 14:14 |
| rhallisey | mandre, see ya | 14:14 |
| inc0 | however similar that would be to centos, it will be rhel... | 14:14 |
| sdake | inc0 we can't support rhel as first class becuase we cna't ibuidl the containers without licenses | 14:14 |
| sdake | unless the rht contigent commit to doing that work | 14:15 |
| sdake | i actually have a site license, but I cant share it :) | 14:15 |
| inc0 | another idea, one SamYaple didn't like ;) how about making sort of puppet-like cross-os APIs? | 14:15 |
| inc0 | so by definition of base container you implemnt things like install_package | 14:16 |
| sdake | i think the general rule we should make is that any group that commits to maintaining a various distro - we maintain | 14:16 |
| inc0 | and in dockerfile we'll replace %%install_package%% python-pip to apt-get install python-pip | 14:16 |
| sdake | the group that is closest to the upstream implements it, we a a team maintain it | 14:16 |
| sdake | new implementations can lead with centos | 14:17 |
| sdake | or from source some other distro of choice | 14:17 |
| pbourke | sdake: I think that's reasonable | 14:17 |
| sdake | if the maintainers fall away, perhaps maintenance for the distro drops away as well | 14:17 |
| inc0 | so we'll have just centos binary and later keep pushing source install to a point it will be only maintained way? | 14:17 |
| sdake | no i want rdo maintenance | 14:18 |
| inc0 | at the end we'll have centos-binary, centos-source, ubuntu-source, rhel-source | 14:18 |
| inc0 | and 2 docker files - centos binary and source? | 14:18 |
| inc0 | per container? | 14:18 |
| sdake | inc0 we ballparked that at 300 dockerfiles | 14:18 |
| sdake | dockerfiles take 5 minutes to write | 14:19 |
| inc0 | what does "ballparked" mean?;) | 14:19 |
| *** dwalsh has joined #kolla | 14:19 | |
| sdake | "in the neighboorhood of" | 14:19 |
| sdake | "around" | 14:19 |
| sdake | sorry for my slang | 14:19 |
| inc0 | thank you | 14:20 |
| inc0 | no worries, I'm learning happily, just forgive me if I pop questions like that | 14:20 |
| sdake | its a-ok | 14:20 |
| sdake | i try to teach new people lots of things :) | 14:20 |
| sdake | its part of my charm :) | 14:20 |
| SamYaple | "charm" | 14:20 |
| sdake | rather teach peopel lots of new things | 14:20 |
| sdake | hmm that came out wrong ;) | 14:21 |
| sdake | so from source, i'd like to lead there with centos as well | 14:21 |
| sdake | its neutral ground as far as i'm concerned | 14:22 |
| SamYaple | but my yaodu ubuntu-source is already done.... | 14:22 |
| SamYaple | ;) | 14:22 |
| inc0 | I think if we keep our guard high, we can keep source pretty universal | 14:22 |
| sdake | samyaple should be an easy port ;) | 14:22 |
| sdake | i mean for new containers | 14:22 |
| SamYaple | inc0: for the final step. but lots of the containers have packge installs right as you would need to do the source install | 14:22 |
| sdake | so the model is new work goes into cnetos-source and centos-rdo (if available) | 14:23 |
| SamYaple | so you would have yet another container layer to keep the all the same Dockerfiles | 14:23 |
| SamYaple | the contaents should be similiar, but it wont be identical | 14:23 |
| inc0 | how about message like that: source and centos-binary is a must, other is as-needed-basis? | 14:23 |
| sdake | inc0 i recognize what you propose (generate dockerfiles) but *really* think it is the wrong way to go | 14:23 |
| sdake | inc0 i wasn't finished lead with centos binary and source | 14:23 |
| sdake | and the other distro related interesets can fill in tthe blanks | 14:24 |
| sdake | it hsould be mostly c&p | 14:24 |
| inc0 | I'm not emotionally bound to "generated Dockerfiles". Just trying to not get into lots of dependencies for new containers | 14:24 |
| sdake | and we can gate the build for each distro seprately per source/binary | 14:24 |
| sdake | this is somethign we should probably vote on as a community | 14:25 |
| sdake | i'll add to agenda for weekly meeting | 14:25 |
| inc0 | let's first pop up spec and then gather ideas | 14:25 |
| sdake | i dont want specs | 14:25 |
| inc0 | why? maybe someone will come out with better solution | 14:26 |
| sdake | the general guideline for a spec is "if its going to create a bunch of discussion, lets do it in a spec" | 14:26 |
| inc0 | ? | 14:26 |
| sdake | inc0 spec introduces alot of overhead and slows the project down | 14:26 |
| sdake | just htis ansible-multi spec takes two weeks to go from first draft to approval | 14:26 |
| sdake | in that case it was necesary | 14:26 |
| sdake | in this case it is not | 14:26 |
| sdake | daneyon wrote teh ha spec a month ago still not hit the repo | 14:27 |
| inc0 | first containers from it are almost in;) | 14:27 |
| sdake | the specs process in mature projects is necessary becaue there are hundreds of people working on the code base | 14:27 |
| sdake | we have maybe 20 people | 14:27 |
| sdake | we can manage without specs for the most part | 14:27 |
| inc0 | allright..but I think we should at least brainstorm arount it | 14:28 |
| sdake | i have heard time and time again from mature projects the developers are threatening to rage quit over the specs process | 14:28 |
| inc0 | maybe leave it for midcycle? Policy decision thingy | 14:28 |
| sdake | i want to avoid that problem | 14:28 |
| sdake | lets vote this week just to get a general consensus | 14:28 |
| sdake | see if there is any major heartburn | 14:28 |
| sdake | and we can bring up at midcycle for further discussion/refinement | 14:28 |
| inc0 | fair enough | 14:29 |
| inc0 | for now, to not keep akwasnie_ back at her work, let's agree to create another Dockerfile for source right? | 14:29 |
| *** diogogmt has joined #kolla | 14:30 | |
| pbourke | SamYaple: wrt to adding variables for tarballs in source based downloads. would having a file with default urls for each service that build sources sound ok to you? | 14:30 |
| pbourke | then buildconf can override per service if required | 14:31 |
| pbourke | inc0: that's the direction Im going in https://review.openstack.org/#/c/191833/1 | 14:31 |
| pbourke | inc0: akwasnie_: are you creating source installs for centos? | 14:31 |
| sdake | inc0 pbourke can you guys sync on a best practice | 14:33 |
| pbourke | yup thats where I was headed | 14:33 |
| sdake | pbourke i know its outside your immediate goals, but if you could work with akasnie_ on centos source installs first that would rock ;) | 14:34 |
| sdake | is there a from source blueprint? | 14:34 |
| sdake | pbourke if you could also comment on the ansible_multi.rst spec that would rock :) | 14:35 |
| pbourke | sdake: I can do that. no bp that I know of, I was doing it implicitly as part of the OL bp | 14:35 |
| pbourke | sdake: already +1'd the ansible spec | 14:35 |
| sdake | make a new blueprint plz | 14:35 |
| sdake | nice i guess i need to take a look at who to haraass to review it :0 | 14:36 |
| sdake | its a a big change, want to make sure people are on board | 14:36 |
| pbourke | im very pleased with it | 14:36 |
| sdake | we already decided we are doing it with our mission statement | 14:36 |
| sdake | now its a matter of how | 14:36 |
| sdake | i'll target form source for l2 | 14:37 |
| sdake | link blueprint once its available plz | 14:37 |
| sdake | with relevant decisions here | 14:37 |
| pbourke | ok ill draft it up now. akwasnie_ ping me when you're free | 14:37 |
| sdake | inc0 what is akwasnie_'s location (or tz) | 14:38 |
| inc0 | other side of hall from me;) so Poland | 14:38 |
| pbourke | not too far away then :) (ireland for me) | 14:38 |
| sdake | pbourke what is your tz? | 14:38 |
| sdake | nice your both in same tzs | 14:38 |
| sdake | sort of | 14:38 |
| pbourke | UTC+1 | 14:38 |
| sdake | we should add a developers list to our wiki | 14:39 |
| sdake | with tz info | 14:39 |
| sdake | since we are globally distributed that should help communication | 14:39 |
| sdake | pbourke can you start out the list - alphabetical - above core reviewer in the wiki | 14:40 |
| inc0 | sdake, there is bp about source | 14:40 |
| sdake | inc0 link for pbourke to add relevant decisions to whiteboard | 14:40 |
| inc0 | https://blueprints.launchpad.net/kolla/+spec/install-from-source | 14:40 |
| pbourke | ok im going to add the tz list first, then will look at bp | 14:41 |
| inc0 | lets work around this one | 14:41 |
| sdake | i set to essential | 14:41 |
| sdake | enjoy :) | 14:41 |
| sdake | it was already marked for l2 | 14:41 |
| inc0 | pbourke, as we'll leave our beloved work soon, let's talk tomorrow | 14:42 |
| pbourke | inc0: sure :) | 14:42 |
| sdake | pbourke add the core team to the list of developers plz | 14:42 |
| sdake | when you make the wiki changes | 14:42 |
| sdake | include irc nick and utc offset | 14:42 |
| inc0 | brb | 14:43 |
| sdake | kolla is ON at 5am-10am my tz and 6pm-12am my tz :) | 14:43 |
| sdake | and if I make any rash decisions at this hour argue with me plz, my brain needs booting at 7am :) | 14:44 |
| sdake | i try to take a nap during the day to be fresh at our later tz offsets relative to me, so feel free to argue with me anytime :) | 14:45 |
| kevsi | SamYaple: Thanks for clarifying the 4 points in review comments. | 14:46 |
| *** vinkman has joined #kolla | 14:49 | |
| sdake | kevsi welcome aboard :) | 14:50 |
| sdake | kevsi thanks for the review - highly appreciated | 14:50 |
| sdake | only 8am - already feels like sleepy time | 14:51 |
| pbourke | sdake: want me to merge the core list with the new table and just add a column for core? | 14:53 |
| pbourke | or leave as is | 14:53 |
| sdake | leave core team separate in list | 14:54 |
| pbourke | kk | 14:54 |
| sdake | actually column would work | 14:54 |
| pbourke | https://wiki.openstack.org/wiki/Kolla#Active_Contributers | 14:54 |
| sdake | if you do that, put my name at top plz so people know how to harrass first :) | 14:54 |
| pbourke | there is the start, each will need to update and add their own TZ as I dont know most of them | 14:54 |
| pbourke | also Im missing a lot of people | 14:55 |
| sdake | pbourke next step is send an email to the mailing list asking people to populate themselves - use [kolla] tag | 14:55 |
| sdake | pbourke and add core team into active contributors | 14:55 |
| sdake | spelled contributors incorrectly btw :) | 14:55 |
| pbourke | doh | 14:55 |
| sdake | ya I change my mind alot | 14:55 |
| sdake | smart people do it all th time - get used to it :) | 14:55 |
| sdake | or learn to like it :) | 14:56 |
| pbourke | so you mean merge the lists | 14:56 |
| sdake | I'd suggest a "Role" column | 14:56 |
| pbourke | yeah | 14:56 |
| sdake | and put developer/core/ptl | 14:56 |
| pbourke | your wish is my ... :) | 14:56 |
| sdake | plz | 14:56 |
| *** jasonsb has quit IRC | 14:56 | |
| sdake | my offset is UTC-7 | 14:57 |
| *** jasonsb has joined #kolla | 14:57 | |
| sdake | while your editing :) | 14:57 |
| kevsi | sdake: thanks for the welcome | 14:57 |
| sdake | jpeeler rhallisey around? | 14:58 |
| sdake | samyaple what is your offset? | 14:58 |
| jpeeler | i'm here | 14:58 |
| sdake | jpeeler what si your offset | 14:58 |
| sdake | pbourke is kind enough to edit the wiki for us and populat eour tzs | 14:58 |
| rhallisey | sdake, ya | 14:59 |
| jpeeler | UTC -4:00 here on east coast (think Ryan is that too) | 14:59 |
| rhallisey | ya same EST | 14:59 |
| sdake | pbourke rhalliseyjpeeler are utc-7 | 14:59 |
| sdake | jut put offset, not EST/Irish Summertime/etc | 14:59 |
| jpeeler | uh, -4 | 14:59 |
| sdake | there done armchair editing :) | 14:59 |
| *** sami__ has joined #kolla | 14:59 | |
| *** blahRus has joined #kolla | 15:00 | |
| sdake | pbourke don't forget our newest core Harm Weites :) | 15:00 |
| *** sami_ has quit IRC | 15:01 | |
| sdake | pbourke if you dont want to do it, let me know and i'll finish it up | 15:01 |
| jpeeler | honestly i think it would be less confusing if we collected both daylight savings and not | 15:01 |
| pbourke | no worries, on it | 15:01 |
| inc0 | me, akwasnie_ and mstachow are GMT+2 | 15:01 |
| inc0 | and nihilifer | 15:01 |
| sdake | jpeeler idea for tz is just to get a ballpark around when someone might be around | 15:02 |
| inc0 | its CEST | 15:02 |
| * jpeeler always prefers more info over less | 15:02 | |
| *** jasonsb has quit IRC | 15:02 | |
| jpeeler | i'm not editing it though! | 15:02 |
| sdake | jpeeler lol | 15:02 |
| sdake | well if you put in CEST/PST/EST/MST, put after the offfset so ppl can sort by offset plz :) | 15:03 |
| sdake | (vs sorting by randomly named timezones that someone came up with | 15:03 |
| sdake | daneyon hansen is PST - gmt -8 | 15:04 |
| sdake | not sure what tz martin andre is | 15:04 |
| sdake | japan whatever that is | 15:04 |
| pbourke | I reckon that's enough, easier to let people fill in the rest themselves | 15:05 |
| pbourke | ill send a note on ML | 15:05 |
| sdake | pbourke please remove bold on my name, but put me first | 15:05 |
| sdake | again so people know who to harass:) | 15:06 |
| pbourke | ok im adding harmw then Im done! | 15:07 |
| sdake | and change "Core" to "Core Reviewer" | 15:07 |
| sdake | and PTl to "Project Technical Lead (PTL) | 15:07 |
| sdake | ok when you are done let me know and i'll adjust as necessary :) | 15:07 |
| * sdake hates editing wikis | 15:07 | |
| sdake | Weites is harm's last name :) | 15:09 |
| sdake | pbourke thanks for the heavy lifting o nthe wiki :) | 15:10 |
| pbourke | you must have got it wrong in the core nomination mail then ;) | 15:10 |
| sdake | ya I did fail | 15:11 |
| sdake | but I got it right in irc :) | 15:11 |
| pbourke | does the ML auto preprend [openstack-dev] or do add all tags yourself? | 15:11 |
| sdake | that auto-prepends | 15:12 |
| sdake | just add [kolla] | 15:12 |
| pbourke | thanks | 15:12 |
| sdake | explain why we want to know (for tz / contact communication info) | 15:12 |
| SamYaple | catching up hold | 15:13 |
| sdake | sire any message for the queen | 15:14 |
| sdake | none that need be spoken | 15:14 |
| sdake | such an epic quote | 15:14 |
| SamYaple | pbourke: re vairables for tarballs. My opinion is the tarball should be outside the container. This can be downloaded via teh .buildconf file. It can also be manually placed should the builder so please | 15:14 |
| SamYaple | pbourke: gitclones/tarballs should NOT be downloaded in the container | 15:15 |
| sdake | samyaple what about downloading during docker build step? | 15:15 |
| SamYaple | kevsi: anytime! | 15:15 |
| pbourke | SamYaple: what sdake said | 15:15 |
| sdake | I don't want to download tarballs during the building process | 15:15 |
| sdake | outside the container | 15:16 |
| sdake | and I dont want to check tarballs into the repo either ;) | 15:16 |
| SamYaple | sdake: downloading tarballs outside the container is a must here | 15:16 |
| rhallisey | sdake, wow how many time have you seen 300 :P | 15:16 |
| SamYaple | no checking into repos needed | 15:16 |
| sdake | over 9000! | 15:16 |
| sdake | i've got a collection of movies and I watch them | 15:16 |
| sdake | when things go bad, I watch no country for old men :) | 15:17 |
| SamYaple | sdake: i dont know my offset | 15:17 |
| sdake | samyaple what is your timezone | 15:17 |
| SamYaple | CST | 15:17 |
| sdake | UTC-5 | 15:17 |
| SamYaple | cool. i wont remember | 15:17 |
| sdake | i'll add to wiki hang tight | 15:17 |
| pbourke | so you mean as part of the container startup process? doesn't sound right? | 15:17 |
| sdake | assuming you dont mind people knowing your offset | 15:17 |
| sdake | we dont want to do as part of startup process any building | 15:18 |
| SamYaple | i dont care? | 15:18 |
| SamYaple | tarballs are checked/downloaded when the .buildconf script is sourced. This allows the most flexibility | 15:18 |
| SamYaple | then we simple ADD them into the container | 15:18 |
| SamYaple | not container dependacies | 15:18 |
| SamYaple | no* | 15:18 |
| pbourke | not convinced | 15:19 |
| SamYaple | for the record, if you look at yaodu history I have about 5000 permutations of this. what im proposing is the best way and i will talk about it as long as needed | 15:19 |
| SamYaple | everything you have proposed/done i already did | 15:19 |
| *** nihilifer has quit IRC | 15:19 | |
| SamYaple | i can go over why it didnt work | 15:20 |
| sdake | sweet would love to learn from your experiences | 15:20 |
| sdake | what precisely do you do in yaodu | 15:20 |
| sdake | for the build part | 15:20 |
| SamYaple | hopefully someone can propose a better way, that would be nice | 15:20 |
| SamYaple | so for the build part the "build" script did the downloading | 15:20 |
| SamYaple | the dokcer file simply did an ADD on the tarball into the container | 15:21 |
| SamYaple | the tarball was a variable that could be pulled formanywhre | 15:21 |
| SamYaple | that oculd be expanded into a git clone/ref checkout as well | 15:21 |
| SamYaple | but the key is keeping the download external to the container | 15:21 |
| sdake | this was to solve the multi-version problem? | 15:21 |
| sdake | eg, deployingmaster vs stable? | 15:21 |
| SamYaple | yes. it also solved upgrades (juno to kilo was a 2 line change in the whole project) | 15:22 |
| SamYaple | expanding the buildconf file to support all the variations would work well. git clone/refcheckout/custom tarball/official tarball etc | 15:22 |
| SamYaple | in the end the container only needs to know "i have a tarball, extract and install" | 15:23 |
| sdake | pbourke I understand samyaple's rationale, think it is the way to go | 15:24 |
| sdake | but it will require surgery to the build script | 15:24 |
| *** gfidente|afk is now known as gfidente | 15:24 | |
| SamYaple | wrong sdake | 15:24 |
| sdake | pbourke the main reason is to support the case of installing kilo vs liberty and the various stable branches without having to change the dockerfile | 15:25 |
| SamYaple | when the buildconf is sourced it will execture code. custom tarballs can be specified/downloaded in the buildconf | 15:25 |
| sdake | i think we dont want ot edit the dockerfiles if we can help it | 15:25 |
| SamYaple | no change to build script | 15:25 |
| sdake | stand corrected then :) | 15:25 |
| pbourke | right but hang on | 15:25 |
| sdake | are the environment variables available in the docker build operation? | 15:26 |
| pbourke | why not have what you want to download as a variable that is sed'ed into the dockerfile, similar to the FROM line | 15:26 |
| sdake | pbourke how does that work for buld-all? | 15:26 |
| sdake | samyaple same q for u :) | 15:27 |
| pbourke | you have a file with key/value env pairs, one per line. KEYSTONE_TAR=http://... | 15:27 |
| pbourke | build-all sources this | 15:27 |
| SamYaple | pbourke: that is ugly. and requires modification to the build scripts. AND requires the container to download the tarball | 15:27 |
| SamYaple | some people build these cotainers on hosts without internet connections | 15:27 |
| sdake | I think we have to accept containers will be built from a lcoation that has internet connections | 15:28 |
| SamYaple | pbourke: and what about ref changes? | 15:28 |
| sdake | we make that assumption all over the place | 15:28 |
| pbourke | yeah that's a requirement | 15:28 |
| SamYaple | how would you do that in a container? | 15:28 |
| SamYaple | sdake: nah there is no place that requires it with teh appropriate caches | 15:28 |
| SamYaple | but i accept internet as a requirement, sure | 15:28 |
| SamYaple | i dont want to get sidetracked | 15:28 |
| sdake | hey folks, we have 14 people in the ctive contributors list, and that is just the people that are here in the last 1 hour of pbourke's amazing job of editing the wiki for this purpose :) | 15:29 |
| SamYaple | yay pbourke | 15:29 |
| sdake | ask rhallisey about the times when we had 2 people in our meetings - me and him :) | 15:29 |
| rhallisey | ya you all missed out | 15:30 |
| pbourke | SamYaple: ok it sounds like you've thought a lot about this tarball issue and been through the mill on it. just wanted to be sure we'd considered all options and understand why you want to avoid downloading as part of the build | 15:31 |
| SamYaple | pbourke: i can speak further on it if you wish | 15:31 |
| SamYaple | and answer any questions you have | 15:31 |
| sdake | what is the exact issue with downloading inside the docker build context? | 15:31 |
| sdake | i'm fuzzy on that | 15:32 |
| pbourke | i need to read the bp and digest what we know | 15:32 |
| pbourke | did inc0 link it | 15:32 |
| sdake | yes he did but it has scrolled away | 15:32 |
| sdake | it is in the logs | 15:32 |
| sdake | rhallisey could you do me a solid since you have oper | 15:32 |
| pbourke | sdake: internet access Im guessing? | 15:32 |
| inc0 | https://blueprints.launchpad.net/kolla/+spec/install-from-source here you go | 15:32 |
| SamYaple | i have screaming baby, conversation will have to wait | 15:32 |
| pbourke | inc0: thanks | 15:32 |
| sdake | pbourke samyaple said he accepts that and didn't want to get sidetracked on that conversation | 15:32 |
| sdake | so i'd rather stay on the main track which is? :) | 15:33 |
| sdake | jsut so I know, when people ask me | 15:33 |
| sdake | which invariably will happen | 15:33 |
| inc0 | there isn't much to read about, we really need to check all that stuff | 15:33 |
| sdake | rhallisey can you change the topic of the channel to add a "This channel is logged. Weekly Kolla*" | 15:33 |
| pbourke | inc0: you can say that again, three words currently on it :) | 15:33 |
| *** rhallisey sets mode: +o sdake | 15:34 | |
| * sdake was delegating not asking for ops :) | 15:34 | |
| *** rhallisey sets mode: -o sdake | 15:34 | |
| rhallisey | I take them! | 15:34 |
| *** ogelbukh has joined #kolla | 15:35 | |
| sdake | pbourke recommend linking a log to this day's eavesdrop discussion | 15:35 |
| sdake | so people know how we got to where we are in the future | 15:35 |
| SamYaple | so. why not download in the container? what happens if we want to support testing patch and providing a ref_change? (I do want that) | 15:36 |
| SamYaple | pbourke: how would you do that? | 15:36 |
| SamYaple | from a dockerfile | 15:36 |
| inc0 | downloading in container on startup will be painful in dc | 15:37 |
| inc0 | with network proxies, firewalls, and all that stuff | 15:37 |
| sdake | not on startup | 15:37 |
| inc0 | on build? | 15:38 |
| sdake | docker build existss for a reason - tobuild :) | 15:38 |
| SamYaple | inc0: before build | 15:38 |
| sdake | rhallisey would you mind making that topic change plz :) | 15:38 |
| pbourke | SamYaple: you could make it a variable but I think Im on board with you now anyway | 15:38 |
| sdake | or are you just typing slowly :) | 15:38 |
| pbourke | SamYaple: your way is more flexible | 15:38 |
| rhallisey | sdake, was talking to someone sorry | 15:39 |
| sdake | np | 15:39 |
| pbourke | it also nails the issue of proxies as inc0 mentions | 15:39 |
| rhallisey | that's why I gave ops :) | 15:39 |
| rhallisey | just a second | 15:39 |
| SamYaple | pbourke: you cant actually make it a variable since you need to git checkout/cherry-pick/generate tarball (last step optional) | 15:39 |
| *** jtriley has quit IRC | 15:39 | |
| sdake | so if I coud get a list of the top 3 reasons we don't pull/download tarballs inside Dockerfile they woudl be what: | 15:39 |
| sdake | not being dense, but I know I will be asked by many people over and over | 15:40 |
| sdake | and I want to understand the reasons | 15:40 |
| inc0 | installation from source also requires installation of dependencies | 15:40 |
| inc0 | probably something like pip install -e . | 15:41 |
| pbourke | inc0: yes but those can be cached | 15:41 |
| inc0 | can we do that in Dockerfile? | 15:41 |
| SamYaple | sdake: 1. firewall/proxy/networking 2. cannot be flexible/cannot support ref_changes 3. containers have extra deps (git) | 15:41 |
| SamYaple | i guess thats my answer? 2 is the selling pont for me | 15:41 |
| pbourke | yeah 1 and 3 I would not lose sleep over | 15:42 |
| SamYaple | Dockerfiles getting a tarball is a known point. they know how to "take it from here" | 15:42 |
| SamYaple | that is big for readability | 15:42 |
| inc0 | I have to run now, please let me know tomorrow what did you find out | 15:42 |
| pbourke | inc0: ill update the bp | 15:42 |
| inc0 | thank you | 15:42 |
| inc0 | we'll sync up tomorrow and split work items | 15:42 |
| SamYaple | https://github.com/SamYaple/yaodu/blob/master/ansible/roles/docker_build/templates/ubuntu/keystone/Dockerfile.j2#L4-L8 | 15:43 |
| inc0 | have a nice day guys, bye | 15:43 |
| sdake | what is the ref change thing you talk about | 15:43 |
| SamYaple | all ^ that is the ADD and install of openstack | 15:43 |
| SamYaple | inc0: bye! | 15:43 |
| SamYaple | sdake: git fetch https://SamYaple@review.openstack.org/stackforge/kolla refs/changes/86/191486/1 && git cherry-pick FETCH_HEAD | 15:43 |
| SamYaple | we can test changes from a commit before merge | 15:44 |
| SamYaple | we can be a devstack replacement as an added value with no extra work | 15:44 |
| sdake | oh please not more pain :) | 15:44 |
| sdake | i can only take so much :) | 15:44 |
| SamYaple | sdake: this is pleasure. get you senses right | 15:45 |
| sdake | oh perhaps im confusing the two :) | 15:45 |
| SamYaple | anyway, its literally requires no extra work to allow ref/changes _if_ we pull outside the container | 15:45 |
| sdake | so the main reason I see is to be able to cherrypick changes wihtout hand-editing the dockerfile | 15:45 |
| ogelbukh | 53 | 15:46 |
| sdake | i'll go with that argument | 15:46 |
| SamYaple | probably the biggest, but it does make other changes easier too | 15:46 |
| *** absubram has joined #kolla | 15:46 | |
| SamYaple | your company has a patch to neutron, generate a tarball locally and put it in the right place. then it deploys. bam | 15:46 |
| sdake | ya makes sense | 15:46 |
| sdake | thanks | 15:46 |
| *** sami_ has joined #kolla | 15:47 | |
| *** jtriley has joined #kolla | 15:47 | |
| sdake | one cisco perk is i get to use company rate on hotels/car rentals | 15:48 |
| *** inc0 has quit IRC | 15:48 | |
| sdake | boy I'd like to take advantage of that with a vacation :) | 15:48 |
| *** rhallisey changes topic to "Weekly Kolla meetings will be held every Wednesday 1600 UTC for even weeks of the month and 2200 UTC for odd weeks in #openstack-meeting-4 | https://wiki.openstack.org/wiki/Meetings/Kolla | Install from source discussion http://eavesdrop.openstack.org/irclogs/%23kolla/%23kolla.2015-06-16.log.html#t2015-06-16T14:40:58" | 15:48 | |
| rhallisey | sdake, how's that look | 15:48 |
| pbourke | sdake: good discount? | 15:48 |
| sdake | rhallisey we dont need the install from source discussion in the logs | 15:48 |
| sdake | rather in the topic | 15:48 |
| sdake | what we need is a "This channel is logged @" | 15:48 |
| sdake | openstack requires us to notify people the channel is logged | 15:49 |
| sdake | and we aren't doing that | 15:49 |
| rhallisey | O.o I misunderstood | 15:49 |
| sdake | np | 15:49 |
| *** sami__ has quit IRC | 15:49 | |
| *** rhallisey changes topic to "Weekly Kolla meetings will be held every Wednesday 1600 UTC for even weeks of the month and 2200 UTC for odd weeks in #openstack-meeting-4 | https://wiki.openstack.org/wiki/Meetings/Kolla | This channel is logged here: http://eavesdrop.openstack.org/irclogs/%23kolla/" | 15:50 | |
| sdake | thanks - more in compliance :) | 15:50 |
| *** dwalsh has quit IRC | 15:50 | |
| sdake | this is part of the channel logging change that we didn't follow | 15:50 |
| sdake | oh well cant fix the past | 15:50 |
| rhallisey | :) | 15:50 |
| sdake | but now everyone knows :) | 15:50 |
| bmace | too bad there isn't an eavesdrop.nsa.gov.. then we wouldn't even need our own bot.. just look at their logs ;) | 15:51 |
| *** rhallisey has quit IRC | 15:51 | |
| *** rhallisey has joined #kolla | 15:51 | |
| *** fangfenghua has joined #kolla | 15:52 | |
| Slower | I was reading you're supposed to put it in the channel topic that we are logging | 15:58 |
| *** sami__ has joined #kolla | 15:59 | |
| *** fangfenghua has quit IRC | 16:00 | |
| bmace | it is at the end | 16:02 |
| *** sami_ has quit IRC | 16:02 | |
| *** dwalsh has joined #kolla | 16:02 | |
| Slower | ah I'm oldschool | 16:04 |
| Slower | txt based client | 16:04 |
| sdake | bmace i suspect there is :) | 16:04 |
| jmccarthy | sdake: re:multi_ansible bp feedback: Thanks ! - Yea I sort of knew it was probably out of scope of that blueprint but went ahead and asked the question anyway - I'll follow that other blueprint and check what's cooking there. Yea from backup or maybe audit point of view ., folks may want to know what/when changes have been made across nodes over time or that sort of thing I was thinking | 16:05 |
| sdake | slower add your name to the kolla dev wiki if you like | 16:05 |
| *** jtriley has quit IRC | 16:05 | |
| sdake | ya makes sense, blueprints are just an implementation guideline not comprehensieve "here is how it must be done" :) | 16:06 |
| sdake | I dont know if you saw v1.0 but v2.0 is much different | 16:06 |
| sdake | based upon the 40 feedback items from version 1 | 16:06 |
| sdake | I htink I got everyone's concerns convered :) | 16:06 |
| sdake | looking good so far, lots of +1's :) | 16:06 |
| sdake | slower https://wiki.openstack.org/wiki/Kolla | 16:08 |
| rhallisey | lol 'Developer-wannabe' | 16:09 |
| jmccarthy | lol | 16:10 |
| sdake | either your a devleoper or not :) | 16:10 |
| *** nihilifer has joined #kolla | 16:10 | |
| sdake | so I changed that | 16:10 |
| rhallisey | pretty funny :D | 16:10 |
| *** daneyon has joined #kolla | 16:11 | |
| sdake | daneyon around? | 16:11 |
| *** sami__ has quit IRC | 16:13 | |
| *** sami__ has joined #kolla | 16:14 | |
| *** daneyon_ has joined #kolla | 16:14 | |
| sdake | daneyon_ around? | 16:14 |
| daneyon_ | ya, give me a few though | 16:14 |
| sdake | ping me when avialable | 16:14 |
| SamYaple | ok guys i need sleep | 16:17 |
| *** daneyon has quit IRC | 16:17 | |
| *** vinkman has left #kolla | 16:17 | |
| Slower | sdake: cool, done | 16:17 |
| Slower | I did developer-wannabe though :) | 16:17 |
| sdake | in your case its appropriate ;) | 16:18 |
| sdake | j/k | 16:18 |
| Slower | haha | 16:18 |
| Slower | I thought so :) | 16:18 |
| sdake | can you change it to developer plz | 16:18 |
| Slower | I was j/k | 16:18 |
| sdake | I appreciate how you view the distinction | 16:18 |
| sdake | but either ppl are developers or not develoeprs :) | 16:19 |
| *** dasm|afk is now known as dasm | 16:19 | |
| dasm | sdake: and how about semi-developers? | 16:19 |
| dasm | when someone is half-active? ;) | 16:19 |
| Slower | lazy-developer? :) | 16:19 |
| sdake | if your part time, but an active contributor | 16:20 |
| sdake | your still an active contributor | 16:20 |
| sdake | i am part time on kolla ;) | 16:20 |
| sdake | actually more realistically I am 100% on two projects :) | 16:20 |
| dasm | sdake: which one part? between 00-12 or 12-24? | 16:20 |
| Slower | haha | 16:20 |
| Slower | ya he only works 12 hrs a day on it.. half time | 16:21 |
| sdake | dasm just add in developer there for yourself | 16:21 |
| sdake | we have alot of peeps that are only 20-50% time on kolla | 16:21 |
| sdake | mandre is probably like 20% and he is a core reviewer :) | 16:21 |
| dasm | sdake: done | 16:23 |
| dasm | so right now there are 6 CR + 1 PTL + 10 devs... 17 ppl for Kolla project. | 16:23 |
| sdake | there are more unaccounted in the wiki | 16:24 |
| sdake | that list is only 1 hour old ;) | 16:24 |
| dasm | ah... that's why i didn't see it previously ;) | 16:24 |
| *** daneyon_ has quit IRC | 16:25 | |
| *** daneyon has joined #kolla | 16:25 | |
| daneyon | sdake hey! | 16:28 |
| sdake | daneyon will you copresent iwth me at summit | 16:29 |
| sdake | Kolla: Deploying OpenStack Using Ansible in Docker Containers | 16:29 |
| daneyon | i would be honored to | 16:29 |
| Slower | tokyo here we come! | 16:29 |
| sdake | 3 cheater words :) | 16:29 |
| daneyon | Docker | 16:29 |
| daneyon | containers | 16:29 |
| daneyon | beer | 16:29 |
| sdake | four if you count containers :) | 16:30 |
| Slower | haha | 16:30 |
| rhallisey | ha! | 16:30 |
| daneyon | rhallisey getting ready to test the latest cinder ps | 16:31 |
| daneyon | i assume the only thing i need to do to prep is create my cinder vg, correct? | 16:31 |
| rhallisey | daneyon, no I create the vg in a script | 16:32 |
| rhallisey | all you need is docker 1.7 | 16:32 |
| daneyon | oh | 16:32 |
| *** nihilifer has quit IRC | 16:32 | |
| daneyon | will the script bypass creating the vg if it exists? | 16:32 |
| Slower | beer saki cigars ... need a 4th | 16:33 |
| rhallisey | if it exists with X name then it won't | 16:33 |
| Slower | oh 3 cheater words, I'm good then | 16:33 |
| rhallisey | daneyon, you can create it by hand just call it the same name you pass as the 'volume group' param | 16:33 |
| daneyon | I'm not a big fan of the vg create script | 16:34 |
| rhallisey | I think that's the name | 16:34 |
| daneyon | I setup my lab env to use a real phys vol for my cinder vg | 16:34 |
| Slower | ya we need to have a check in there | 16:35 |
| rhallisey | daneyon, ya you can use that just use the same name | 16:35 |
| daneyon | I think we should make it configurable between a real volume and a loopback/file backed volume | 16:35 |
| Slower | daneyon: definitely | 16:35 |
| daneyon | It should be pretty easy to expose a param like USE_LOOPBACK or something like that. | 16:35 |
| sdake | slower rhallisey daneyon jpeeler plz review https://review.openstack.org/#/c/189157/ | 16:36 |
| rhallisey | daneyon, ok I'm cool with that | 16:36 |
| daneyon | I think volume-group-create.sh in the cinder-vol start script should only be executued if a param like CREATE_VOLUME_GROUP=true | 16:37 |
| Slower | daneyon: I think we should iterate on it | 16:37 |
| daneyon | fair enough | 16:37 |
| Slower | in fact you should test a change to add physical volume support since you have that set up ;-) | 16:37 |
| daneyon | ok, let me work on updating Docker to 1.7 | 16:38 |
| rhallisey | daneyon, ya we didn't have it setup :P | 16:38 |
| rhallisey | hence the backing file | 16:38 |
| *** jmccarthy has quit IRC | 16:38 | |
| daneyon | Slower I will do just that. Excited to test this stuff out!!!! | 16:40 |
| *** akwasnie_ has quit IRC | 16:41 | |
| Slower | daneyon: very cool! | 16:43 |
| daneyon | Slower rhallisey I cant get 1.7 installed due to deps: docker-selinux selinux-policy | 16:43 |
| daneyon | Do you use --skip-broken or how do u install the 2 deps? | 16:44 |
| daneyon | I'm going to try skipping the deps | 16:46 |
| daneyon | I guess ^ didn;t work | 16:46 |
| daneyon | sdake do you have any advice on how to get around this: https://gist.github.com/danehans/d79a4077c9cfea899844 | 16:47 |
| sdake | download the rpm | 16:48 |
| sdake | via curl | 16:48 |
| sdake | rpm -Uvh --nodeps file.rpm | 16:48 |
| daneyon | sdake nevermind, i think i got it | 16:48 |
| daneyon | ya, duh | 16:48 |
| Slower | I think we were just downloading the binary :) | 16:50 |
| Slower | because evil | 16:50 |
| *** dwalsh has quit IRC | 16:52 | |
| *** dwalsh has joined #kolla | 16:56 | |
| Slower | is bashate failing normally? | 16:59 |
| openstackgerrit | imain proposed stackforge/kolla: Set up glance to use a data container. https://review.openstack.org/191975 | 17:01 |
| *** jtriley has joined #kolla | 17:02 | |
| *** jtriley has quit IRC | 17:06 | |
| *** sdake has quit IRC | 17:19 | |
| *** sdake_ has joined #kolla | 17:19 | |
| *** sami_ has joined #kolla | 17:24 | |
| *** sami__ has quit IRC | 17:27 | |
| *** dwalsh has quit IRC | 17:30 | |
| *** jasonsb has joined #kolla | 17:35 | |
| *** athomas has quit IRC | 17:41 | |
| *** jtriley has joined #kolla | 17:51 | |
| *** dwalsh has joined #kolla | 17:55 | |
| *** daneyon_ has joined #kolla | 17:57 | |
| *** daneyon has quit IRC | 18:00 | |
| *** fangfenghua has joined #kolla | 18:06 | |
| openstackgerrit | Jeff Peeler proposed stackforge/kolla: Fix Heat container env vars and dependencies https://review.openstack.org/189974 | 18:08 |
| jpeeler | i'm a bit confused how gerrit has conflicts, but then when i rebased locally none were present | 18:08 |
| *** fangfenghua has quit IRC | 18:12 | |
| *** gfidente is now known as gfidente|afk | 18:24 | |
| *** diogogmt has quit IRC | 18:25 | |
| *** bmace has quit IRC | 18:34 | |
| *** daneyon has joined #kolla | 18:42 | |
| *** nihilifer has joined #kolla | 18:45 | |
| *** daneyon_ has quit IRC | 18:45 | |
| *** nihilifer has quit IRC | 18:45 | |
| *** bmace has joined #kolla | 18:46 | |
| *** nihilifer has joined #kolla | 18:46 | |
| *** diogogmt has joined #kolla | 18:47 | |
| daneyon | rhallisey Slower what version of device-mapper are you using with 1.7? | 18:47 |
| *** diogogmt has quit IRC | 18:48 | |
| rhallisey | device-mapper-1.02.93-3.fc21.x86_64 | 18:48 |
| *** jruano has joined #kolla | 18:51 | |
| loth | sdake_: i need to revote? | 18:52 |
| harmw | sdake_: underscore-alert | 18:54 |
| daneyon | rhallisey me too | 18:54 |
| rhallisey | daneyon, are you having issues? | 18:54 |
| bmace | i tried device mapper a few times on systems that had old aufs revs but i got some odd failures pretty consistently on several different os types with device-mapper | 19:02 |
| bmace | much happier with an up to date aufs, as far as stability / lack of errors | 19:02 |
| daneyon | rhallisey i am trying to get 1.7 to run | 19:03 |
| daneyon | working through it... i think | 19:03 |
| Slower | daneyon: I'm pretty sure we just curl'd the binary and copied it over what was there and it magically worked | 19:04 |
| Slower | I could be wrong though.. I'm old | 19:04 |
| rhallisey | that's right looking for link.. | 19:05 |
| *** diogogmt has joined #kolla | 19:08 | |
| *** fangfenghua has joined #kolla | 19:12 | |
| *** sdake_ is now known as sdake | 19:13 | |
| sdake | loth each review needs a vote ya | 19:13 |
| sdake | loth its not like a mandatory thing | 19:13 |
| sdake | its up to you | 19:14 |
| sdake | curl of docker 1.7 from upstream does not work | 19:14 |
| sdake | you have to use the rpm version | 19:14 |
| *** sdake has quit IRC | 19:15 | |
| *** sdake has joined #kolla | 19:15 | |
| *** fangfenghua has quit IRC | 19:16 | |
| *** jruano has quit IRC | 19:18 | |
| Slower | sdake: are the bashate tests always failing or am I missing something? | 19:22 |
| Slower | https://review.openstack.org/191975 | 19:23 |
| sdake | we are waiting on the cinder review to hit the repo | 19:23 |
| rhallisey | Slower, the new cinder patch will remove like 50 of those errors | 19:23 |
| Slower | ok cool | 19:24 |
| rhallisey | and swift will need to be fixed later | 19:24 |
| sdake | rhallisey if you could rubber stamp https://review.openstack.org/#/c/189166/ - that would fix that problem :) | 19:24 |
| rhallisey | oh :) | 19:24 |
| rhallisey | Cinder has first +2 :D | 19:27 |
| sdake | jpeeler I noticed you reviewed https://review.openstack.org/#/c/189157/ but didn't provide a vote | 19:28 |
| sdake | would you mind voting plz | 19:28 |
| sdake | rhallisey can you review https://review.openstack.org/#/c/189157/ | 19:28 |
| sdake | need to get this spec approved or fixed to unblock loads of people | 19:28 |
| sdake | harmw ^^ :) | 19:28 |
| rhallisey | sdake, ya still reviewing | 19:28 |
| sdake | ha spec same story | 19:28 |
| harmw | yo | 19:29 |
| sdake | please place specs at your highest review priority :) | 19:29 |
| sdake | wow its hot i nphx | 19:29 |
| harmw | icecream alert! | 19:29 |
| sdake | snowball earth alert :) | 19:29 |
| sdake | bmace if ou wouldn't mind reviewing would appreciate as well :) | 19:30 |
| bmace | sure thing | 19:31 |
| bmace | ah, guess it was re-patched since my last +1.. :/ | 19:32 |
| sdake | anyone else is welcome to review as well ;) | 19:32 |
| sdake | ya sam edited it | 19:32 |
| sdake | anyone that is a contributor to kolla, please feel free to add your name/utc/irc nick here if you want | 19:34 |
| sdake | https://wiki.openstack.org/wiki/Kolla | 19:34 |
| sdake | slower since your around and not busy welding, perhap you can review the ha and ansible-multi specs too :) | 19:34 |
| Slower | sdake: haha | 19:38 |
| Slower | damnit | 19:38 |
| bmace | +1 on the spec. still looks good to me and the sort of issues being brought up are small enough that i don't think we need a bunch more spec iterations on them. better to stay out of a deep level of detail in a spec anyway unless you want it immediately irrelevant / out of date once real dev starts | 19:38 |
| sdake | bmace that owuld be a great comment to leave in the review :) | 19:39 |
| sdake | I know exactly what you mean | 19:39 |
| jpeeler | agreed - do we have a policy of all cores voting on a spec? | 19:39 |
| sdake | no such policy | 19:40 |
| sdake | it would be nice if the core reiewers were in agreement though | 19:40 |
| sdake | requiring a unanimous vote on a spec seems onerous to me - we dont even require that for acceptance to the core reviewer team | 19:41 |
| sdake | we require 3 votes for core reviewer and no veto | 19:41 |
| sdake | maybe we should just adopt that for specs | 19:41 |
| *** dasm is now known as dasm|afk | 19:42 | |
| jpeeler | maybe that in addition to some length of time to assure everybody sees it | 19:43 |
| bmace | nice to have some defined criteria at least, even if it is just 2 + ptl, since it would be odd to not have ptl weigh in on spec level stuff. | 19:43 |
| Slower | I basically brought up the idea of maintaining 2 installation methods to ensure an agnostic interface to the containers | 19:45 |
| bmace | i guess it depends on what you mean by installation methods? supporting copy in / copy over is pretty darn agnostic. those configs can be generated / managed in whatever way someone wants. | 19:46 |
| Slower | I mean ansible + something else | 19:49 |
| Slower | but I guess in teh spec it is saying it will continue to support crudini | 19:49 |
| bmace | sure, but ansible in the end is just passing in regular openstack service config files, nothing ansible specific. so from a container point of view ,the containers know nothing about ansible. it is completely agnostic of the install process. | 19:50 |
| *** inc0 has joined #kolla | 19:53 | |
| sdake | bmace agree with your assessment | 19:54 |
| inc0 | good evening | 19:54 |
| sdake | jpeeler the spec has been up for a week+, ha spec up for a mo | 19:54 |
| sdake | bmace problem with 2+ptl is if ptl is the spec author | 19:54 |
| Slower | sdake: link to ha spec? | 19:54 |
| jpeeler | i wasn't worried about the existing specs, just was talking about if a new policy were formed | 19:55 |
| sdake | bmace spec authors can't approve their own changes | 19:55 |
| Slower | sdake: so are we going to ditch the compose dir and stop testing env file config of containers? | 19:55 |
| sdake | slower https://review.openstack.org/#/c/181983/ | 19:56 |
| bmace | makes sense sdake. | 19:56 |
| sdake | slower no | 19:56 |
| sdake | compose dir staying | 19:56 |
| sdake | kolla being renamed kolla-compose | 19:56 |
| sdake | we will gate the two major config strategies separately | 19:56 |
| sdake | ocne we have gating that works :) | 19:57 |
| sdake | hopefully for each container distro + install method (source/binary) avialable | 19:57 |
| inc0 | wow, that escalated quickly, this is new idea? | 19:57 |
| sdake | inc0 we have always had ci gating as a goal | 19:57 |
| Slower | sdake: well that's kind of what I was thinking.. sounds good | 19:57 |
| inc0 | I know, but I mean kolla-compose | 19:58 |
| sdake | inc0 this is nothing new, we have discussed it for the last 3 mo | 19:58 |
| sdake | inc0 I thought that was in the spec? | 19:58 |
| sdake | it was in one version I wrote atealset :) | 19:58 |
| sdake | maybe I imagined writing it let me check the spec | 19:58 |
| inc0 | as different install strategu | 19:59 |
| bmace | i remember reading it :) | 19:59 |
| sdake | what we are not goint tto do slower is continue to make new containers using crudini | 19:59 |
| sdake | unless at request | 19:59 |
| Slower | right, or unless contributed I presume? | 19:59 |
| sdake | right | 19:59 |
| sdake | if somone really wants to do the work, wfm :) | 19:59 |
| Slower | yeah I hear ya | 19:59 |
| sdake | slagle suggested this idea | 20:00 |
| inc0 | idea is to allow deployment tool to prepare full config file, which is cool for tripeo I guess | 20:00 |
| sdake | it wasn't mine :) | 20:00 |
| sdake | inc0 what is it that yo uthink a new idea was generated around? | 20:02 |
| *** jasonsb has quit IRC | 20:02 | |
| inc0 | renaming kolla to kolla-compose | 20:02 |
| inc0 | I must have missed that | 20:02 |
| *** jasonsb has joined #kolla | 20:02 | |
| sdake | bmace confirmed it was in atleast one version of the spec :) | 20:02 |
| inc0 | yea I believe you, I might misread this part, I dont worry too much | 20:03 |
| inc0 | after a thought:) | 20:03 |
| bmace | it is down near the end, at least in the current rev, under Work Items | 20:06 |
| inc0 | yeah, I see it, I guess I didn't read work items too carefully | 20:06 |
| inc0 | mea culpa | 20:06 |
| sdake | that is the most important part ;) | 20:06 |
| inc0 | and kolla will just hold containers right? | 20:09 |
| sdake | huh? | 20:10 |
| inc0 | sorry, its 10pm for me | 20:10 |
| sdake | could you expand on your question | 20:10 |
| inc0 | we'll have kolla-compose and kolla-ansible right? | 20:10 |
| sdake | right | 20:10 |
| sdake | these aren't new repos | 20:10 |
| sdake | these are shell scripts | 20:10 |
| inc0 | aaaa | 20:10 |
| sdake | i guess that could have been more clear :) | 20:10 |
| inc0 | now it makes sense;) | 20:10 |
| inc0 | I misunderstood this part | 20:11 |
| inc0 | again 10pm, my mind isn't used to work now | 20:11 |
| harmw | ok, notes on mansible pushed | 20:13 |
| *** sdake_ has joined #kolla | 20:16 | |
| *** fangfenghua has joined #kolla | 20:17 | |
| openstackgerrit | Michal Jastrzebski (inc0) proposed stackforge/kolla: Keepalived container https://review.openstack.org/187981 | 20:17 |
| *** jtriley has quit IRC | 20:18 | |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make get-image.sh bashate compliant https://review.openstack.org/189156 | 20:18 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make swift bashate compliant https://review.openstack.org/189166 | 20:18 |
| sdake_ | rhallisey/jpeeler if you could rubber stamp those two reviews, they are a rebase - gerrit got busted somehow | 20:19 |
| sdake_ | or harmw use your new +2 powers :) | 20:19 |
| *** sdake has quit IRC | 20:20 | |
| jpeeler | sdake_: what was the reason you changed the backend to use qemu directly? | 20:21 |
| sdake_ | where? | 20:21 |
| sdake_ | oh because I dont run libvirt | 20:21 |
| sdake_ | I guess I could have documented that :) | 20:22 |
| sdake_ | our docs recommend turning off libvirt | 20:22 |
| *** fangfenghua has quit IRC | 20:22 | |
| sdake_ | is the reason | 20:22 |
| jpeeler | image can be built anywhere though | 20:22 |
| sdake_ | so get_image as is is not usper compatible with our dev quickstart | 20:22 |
| sdake_ | yes but typically they are built on the same system | 20:22 |
| sdake_ | i couldn't test it with it as is | 20:23 |
| jpeeler | yeah i'm not saying the change is wrong or anything, just curious | 20:23 |
| sdake_ | thats why :) | 20:23 |
| sdake_ | harmw re ansible spec thanks for comments - if you thin kthey warrant a new spec revision, please vote -1 if you think we are good to go vote +1 or +2 | 20:24 |
| harmw | well, I'm not sure if they do... I'd like some clearification, so yes I'd love to see them adressed/added | 20:25 |
| harmw | then again, it's just some grey-area text | 20:25 |
| harmw | (I want to know how it works a week from now, without having to re-read the whole damn thing again like I just did :P) | 20:27 |
| sdake_ | samyaple when you arise, spec needs an update | 20:44 |
| sdake_ | samyaple I'd do it myself but there are technical questions I don't have the answers to | 20:44 |
| sdake_ | name for midycle - Kollapalluza | 20:47 |
| inc0 | I'm curious, what's history of this name? | 20:49 |
| rhallisey | lol | 20:51 |
| inc0 | http://www.urbandictionary.com/define.php?term=palooza ah... | 20:51 |
| inc0 | that's my second new word in English today! | 20:51 |
| rhallisey | inc0, haha! nice! | 20:51 |
| rhallisey | inc0, I wan't laughing at you , but rather the name :) | 20:52 |
| rhallisey | it's very funnt | 20:52 |
| rhallisey | funny | 20:52 |
| sdake_ | blame robyn | 20:52 |
| rhallisey | I like it | 20:52 |
| daneyon | how the heck is anyone getting docker 1.7 to run | 20:52 |
| sdake_ | daneyon maybe your rpm is bust | 20:53 |
| daneyon | I'm on 3.19.5-200.fc21.x86_64 | 20:53 |
| daneyon | I'm following: https://github.com/stackforge/kolla/blob/master/devenv/kollanode.yaml#L164-L167 | 20:54 |
| daneyon | seems like devicemapper is a problem. I'm using device-mapper-1.02.97-1 was using .93 and same problem | 20:55 |
| inc0 | anyway, I just came here for late call | 20:57 |
| inc0 | take care, see you all tomorrow | 20:57 |
| *** inc0 has quit IRC | 20:58 | |
| Slower | I've never had devicemapper issues | 20:58 |
| Slower | didn't even know it had a package | 20:58 |
| sdake_ | slower why does that not surprise me :) | 20:58 |
| Slower | daneyon: setenforce 0 ? | 20:58 |
| Slower | geez | 20:59 |
| openstackgerrit | Michal Rostecki proposed stackforge/kolla: Add designate-sink service https://review.openstack.org/189393 | 20:59 |
| daneyon | Slower seems like I'm hitting this: https://github.com/docker/docker/issues/12889 | 20:59 |
| openstackgerrit | Merged stackforge/kolla: Make get-image.sh bashate compliant https://review.openstack.org/189156 | 21:00 |
| openstackgerrit | Merged stackforge/kolla: Make swift bashate compliant https://review.openstack.org/189166 | 21:00 |
| rhallisey | daneyon, just a second | 21:00 |
| sdake_ | daneyon that curl line is wrong | 21:01 |
| sdake_ | use the rpm version | 21:01 |
| sdake_ | the upstream version is busted with fedora | 21:01 |
| Slower | I don't dare try to reproduce it here.. :) | 21:02 |
| daneyon | adding --storage-opt dm.override_udev_sync_check=true got docker daemon to start, but it sounds like it can cause unexpected bahavior | 21:02 |
| *** dwalsh has quit IRC | 21:03 | |
| Slower | doesn't sound good.. docker has issues already.. | 21:04 |
| daneyon | now hopefully it will work with the cinder container patch | 21:04 |
| daneyon | Slower To test the cinder patch, I need to build my cinder images instead of pulling the from the registry, correct? | 21:06 |
| rhallisey | daneyon, correct | 21:07 |
| daneyon | thx | 21:07 |
| *** jtriley has joined #kolla | 21:14 | |
| *** jtriley has quit IRC | 21:19 | |
| *** nihilifer has quit IRC | 21:23 | |
| *** fangfenghua has joined #kolla | 21:23 | |
| *** fangfenghua has quit IRC | 21:28 | |
| *** juggler_ has joined #kolla | 21:40 | |
| *** gfidente|afk has quit IRC | 21:47 | |
| sdake_ | daneyon did you get my msg about that link being wrong in the curl in the heat etmplate | 21:58 |
| sdake_ | you need to download the rpm from redhat, it is dynamically linked | 21:58 |
| daneyon | sdake_ let ,e try the rh rpm | 22:01 |
| daneyon | however, i got 1.7 started but my system still doesn't seem to be working right | 22:01 |
| *** sdake_ is now known as sdake | 22:02 | |
| *** juggler_ is now known as juggler | 22:04 | |
| rhallisey | daneyon, https://fedorapeople.org/~rhallisey/docker-engine-1.7.0-0.1.rc1.fc21.x86_64.rpm | 22:05 |
| rhallisey | that's what I used | 22:05 |
| daneyon | rhallisey thx | 22:05 |
| *** rhallisey has quit IRC | 22:22 | |
| daneyon | rhallisey or Slower 2 questions Are you using fedora atomic for your host OS? Are you using compose or just running docker with the env file? | 22:32 |
| *** openstackgerrit has quit IRC | 22:38 | |
| *** openstackgerrit has joined #kolla | 22:38 | |
| *** diogogmt has quit IRC | 22:39 | |
| *** diogogmt has joined #kolla | 22:41 | |
| *** pbourke has quit IRC | 22:44 | |
| *** pbourke has joined #kolla | 22:44 | |
| *** jtriley has joined #kolla | 23:03 | |
| *** fangfenghua has joined #kolla | 23:04 | |
| *** fangfenghua has quit IRC | 23:04 | |
| *** shardy has quit IRC | 23:05 | |
| *** jtriley has quit IRC | 23:07 | |
| sdake | samyaple alive yet | 23:07 |
| sdake | diga | 23:16 |
| sdake | can you add your name here plz | 23:16 |
| diga | hi sdake | 23:16 |
| diga | where ?? | 23:16 |
| sdake | https://wiki.openstack.org/wiki/Kolla | 23:16 |
| sdake | onl yif you want | 23:16 |
| sdake | not mandatory by any means | 23:16 |
| diga | sure | 23:16 |
| sdake | helps people figure out your tz fo rcommunication purposes | 23:17 |
| diga | okay | 23:18 |
| diga | sdake: done :) | 23:23 |
| *** blahRus has quit IRC | 23:26 | |
| *** absubram has quit IRC | 23:31 | |
| *** jasonsb has quit IRC | 23:42 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!