16:30:20 <sdake> #startmeeting kolla
16:30:21 <openstack> Meeting started Wed Feb 17 16:30:20 2016 UTC and is due to finish in 60 minutes.  The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:30:23 <sdake> #topic rollcall
16:30:24 <openstack> The meeting name has been set to 'kolla'
16:30:27 <nihilifer> o/
16:30:28 <Jeffrey4l> o/
16:30:30 <inc0> o/
16:30:34 <dave-mccowan> o/
16:30:36 <sdake> in before stan [o] /
16:30:49 <SamYaple> o/
16:30:56 <elemoine_> o/
16:31:01 <SamYaple> pbourke: ping
16:31:21 <pbourke> o/
16:31:29 <pbourke> SamYaple: thanks :)
16:31:50 <jpeeler> hi
16:32:06 <sdake> #topic announcements
16:32:19 <sdake> hello meeting bot?
16:32:39 <ajafo> o/
16:32:47 <inc0> he didn't even acknowledge topic rollcall
16:32:56 <vhosakot> o/
16:33:04 <sdake> your right
16:33:14 <sdake> welll, not sure what to do about that atm, i'll just proceed :)
16:33:22 <nihilifer> freenode has some maintenance reboots, so
16:33:54 <sdake> 1. midcycle was really productive, I'd recommend people hae a look at the midcycle meeting notes if you weren't able to make it
16:34:26 <sdake> #link etherpad.openstack.org/p/kolla-mitaka-midcycle
16:34:55 <sdake> 2. meeting change about to enter the irc meetings repo - hopefully today
16:35:07 <sdake> what that means is we will have a meeting at 23:30 and 16:30 UTC alternating
16:35:13 <sdake> this was by vote
16:35:33 <sdake> I believe 23:30 was the highest vote, I need to double check - I had a patch in progress prior to midcycle but its not handy atm :)
16:36:15 <sdake> 3. speaking with the foundation, we will get plenty of sessions (more then before)
16:36:36 <sdake> we dont want to waste slots, but if there is stuff we need to discuss, we can do that
16:37:15 <sdake> #topic liberty-3 milestone
16:37:20 <SamYaple> mitaka?
16:37:26 <sdake> ya mitaka ;)
16:37:30 <sdake> busy busy morning sorry guys
16:37:51 <sdake> so there were some risks identified at the midcycle related to kolla development
16:37:54 <sdake> you can see those here:
16:38:36 <sdake> #link https://etherpad.openstack.org/p/kolla-mitaka-midcycle-roadmap
16:38:43 <sdake> line 12
16:38:55 <sdake> if your looking for work to do, I highly recommend working on those items
16:39:07 <sdake> can folks open that up real quick
16:39:31 <sdake> i want to touch on each one and get  a status of where things stand on those items
16:39:31 <vhosakot> looking at it
16:39:52 <sdake> diagnostics
16:40:01 <elemoine_> interested to know more about that
16:40:03 <sdake> elemoine_ - akwasnie is not present
16:40:30 <elemoine_> this is on akwasnie?
16:40:32 <sdake> just to be clear, these are things we identified as critical for mitaka
16:40:50 <elemoine_> I can definitely talk to her about that
16:40:51 <sdake> elemoine_ whoever is working on diags which atm is you and elemoine_
16:41:02 <sdake> i dont know if its at risk or not
16:41:05 <sdake> we had a session scheduled
16:41:18 <sdake> but the timezones and both of your availability didn't match up
16:41:49 <dave-mccowan> sdake i don't see 2-VIP support or TLS support for external network.  are they planned for m-3?
16:41:51 <elemoine_> does "diagnostics" include "logging"?
16:41:57 <SamYaple> dave-mccowan: yes
16:42:07 <SamYaple> dave-mccowan: i said I would handle them, but you are welcome to
16:42:13 <sdake> dave-mccowan i wanted to ad them to the tracking at risk but sam said they are not at risk :)
16:42:13 <SamYaple> its a few minutes worth of work
16:42:42 <sdake> dave-mccowan mind taking that off SamYaple's plate entirely?  He is  super overloaded
16:42:55 <sdake> seems like he is good with the idea :)
16:43:02 <SamYaple> ill make sure to submit a patch if its not there by Mar 1st
16:43:17 <sdake> so i would like to go in order tho :)
16:43:35 <sdake> elemoine_ can you give us a snapshot of the status of diagnositcs and if anything is at risk or if this item should just be dropped from the at risk list
16:43:57 <dave-mccowan> SamYaple  i'm happy to help.  let's chat some when you have time.  i'll need some pointers.
16:44:06 <SamYaple> dave-mccowan: sure thing
16:44:26 <sdake> nice
16:44:43 <sdake> ok elemoine_ may be having lag problems i'll move on and come back
16:44:45 <sdake> reconfigure
16:44:49 <elemoine_> sdake: my patch set is very close to be ready
16:45:04 <sdake> does it integrate with awkasnie's patch set?
16:45:12 <elemoine_> no
16:45:27 <elemoine_> I'd like them to be merged separately
16:45:34 <SamYaple> i would agree with that too
16:45:39 <elemoine_> as my patch set is already quite big
16:46:02 <sdake> after they are both merged, there is integration work to be done?
16:46:22 <elemoine_> sdake: yes, but that should be pretty straightforward
16:46:41 <elemoine_> and awkasnie and I agreed to collaborate on that
16:46:59 <elemoine_> we discussed it during midcycle
16:47:00 <sdake> ok
16:47:11 <sdake> where was I? :)
16:47:22 <elemoine_> during YOUR midcycle
16:47:25 <SamYaple> they were in the channel
16:47:29 <sdake> oh
16:47:32 <sdake> i didn't have irc open my bad
16:47:43 <elemoine_> I just want to add one commit to the patchset: removal of Rsyslog
16:47:43 <sdake> busy taking notes :(
16:48:31 <sdake> cool
16:48:32 <elemoine_> and I want to postpone logrotate, Elasticsearch integration, and doc changes (minor) until after the merge of the current patches
16:49:07 <sdake> so you want to go first on the patch merge you mean
16:49:44 <elemoine_> yes, merge what I have today (+ Ryslog removal), after final reviews obviously
16:49:44 <SamYaple> yea Heka first, then logrotate, then kibana/elastic search
16:49:54 <SamYaple> agreed
16:49:57 <elemoine_> exactly how I see things
16:49:57 <sdake> ok lets get that in the etherpad
16:50:03 <sdake> if that makes the most sense
16:50:12 <sdake> typically we give priority to first to write a patchset
16:50:18 <sdake> but if that makes more sense technically then lets do that
16:50:29 <sdake> line 15 please
16:50:33 <sdake> add what you think should be done
16:50:43 <sdake> and i'll run it by ak* when she is about
16:50:51 <elemoine_> I will
16:51:25 <sdake> inc0 infrastructure service upgrades
16:51:28 <elemoine_> tomorrow I'll test Swift
16:51:41 <elemoine_> this is the last thing I need to do/test
16:51:41 <sdake> inc0 iirc you were going to do a haproxy upgrade
16:51:43 <inc0> I'll push haproxy upgrade today
16:51:45 <inc0> yeah
16:51:55 <inc0> as soon as I rebase+test nova
16:51:56 <sdake> inc0 can you add that to the etherpad please
16:52:13 <sdake> line 19
16:52:32 <sdake> I think after this meeting i'll create a new at risk etherpad - if I do tha tI'll link from this etherpad
16:52:45 <sdake> any objections?
16:52:59 <sdake> so we can keep the roadmap and mitaka items separate
16:53:32 <elemoine_> no problem from me
16:53:50 <sdake> elemoine_ please put your data in the etherpad during this meeting or shortly thereafter thanks :)
16:54:02 <sdake> inc0 we have a slew of other services for infrasturcture
16:54:16 <sdake> so we need to find folks to work on those
16:54:17 <inc0> yeah, we had separate session for that
16:54:21 <sdake> right
16:54:28 <elemoine_> will do after the meeting
16:54:30 <sdake> i'll send an announcement to hte ml looking for contributors
16:54:42 <Jeffrey4l> FYI, i assigned the bp upgrade haproxy to me. Feel free to change it inc0
16:54:56 <sdake> migration path for data volumes is at risk
16:54:59 <inc0> Jeffrey4l, if you want to do it, it should be as simple as redeploy of containers
16:55:02 <sdake> because nobody is working on it
16:55:35 <vhosakot> sdake: I'm trying to become a contributor.. what other areas in the kolla infra need work ?
16:55:44 <sdake> samyaple re functional tests, is line 24 accurate?
16:56:02 <inc0> vhosakot, let's talk after meeting ok?
16:56:03 <sdake> vhosakot i'll send a note to the ml for upgrades, which are 9.2 on our priority list ;)
16:56:04 <Jeffrey4l> inc0, I have not started it.
16:56:06 <SamYaple> sdake: line 24 is haproxy
16:56:16 <inc0> ok, I'll do it then
16:56:16 <sdake> samyaple popele are inserting :)
16:56:19 <SamYaple> oh
16:56:27 <vhosakot> inc0, sdake : cool!
16:56:27 <SamYaple> you mean the functional test vm boot/ping?
16:56:28 <Jeffrey4l> thanks.
16:56:34 <sdake> SamYaple the part vm booting
16:56:35 <sdake> yes
16:56:40 <SamYaple> vms are booting with my patch
16:56:43 <SamYaple> no ping yet
16:56:49 <sdake> cool so no longer at risk
16:56:50 <SamYaple> but it validates the instance is ACTIVE
16:56:52 <sdake> oh ping remians
16:57:03 <sdake> well tbh I think that is a really rockin solid start
16:57:55 <sdake> #topic openstack service upgrades
16:58:03 <sdake> I think the meeting bot died, don't see in channel
16:58:29 <elemoine_> sdake: I'm done editing the etherpad, I will run this by awkasnie
16:58:45 <sdake> elemoine_ for the moment i am going to leave the atrisk items whre thy are
16:58:52 <sdake> so people ren't confused by a new etherpad
16:59:03 <sdake> after mitaka-3 i will cut them into a new etherpad so the roadmap doc is tidy
16:59:20 <sdake> because mitaka-3 is a roadmap item ;)
16:59:25 <sdake> ok upgrades
16:59:43 <sdake> at the midcycle we had a super productive session on openstack service upgrades
16:59:53 <sdake> I htink we have patches for every service in the queue but heat
17:00:00 <sdake> heat is on me
17:00:13 <sdake> literally and figuratively ;)
17:00:26 <sdake> does anyone have questions or concerns about openstack service upgrades?
17:00:35 <SamYaple> ive still got neutron
17:00:50 <sdake> thanks SamYaple i'm confident you can knock that out
17:01:03 <sdake> if that changes let me know :)
17:01:09 <inc0> less question more request, we need good multinode testing of this stuff, so if anyone have access, can you plz run plays?
17:01:36 <sdake> inc0 my gear is impaired atleast until mitaka-3
17:01:48 <sdake> I *might* be able to get access to a lab to test with
17:01:56 <sdake> my suggestion is test single node, and merge if it works
17:02:06 <sdake> sort out multinode in the rcs
17:02:16 <inc0> wfm
17:02:19 <sdake> i dont want to block on hardware availaility
17:02:29 <SamYaple> sdake: on that note
17:02:39 <SamYaple> please let me have a moment to the end of the meeting
17:02:46 <sdake> sure SamYaple
17:02:47 <SamYaple> toward*
17:03:02 <sdake> actually its open agenda, since nobody added agenda items :)
17:03:13 <sdake> so SamYaple if you want, you have the floor
17:03:13 <sdake> topic?
17:03:19 <SamYaple> multinode
17:03:24 <SamYaple> and testing
17:03:27 <sdake> #topic multinode testing
17:03:44 <SamYaple> so the main issue ive heard from alot of people is the inability to test multinode
17:03:54 <SamYaple> just lack of hardware to do so on
17:04:21 <SamYaple> Ive recently moved so I was down for a bit, but I have a decent amount of hardware in an openstack cluster running here at the house
17:04:37 <SamYaple> there was talk of thirdparty ci during the midcycle
17:04:45 <inc0> (I've seen it, it is a decent amount)
17:05:14 <inc0> wanna run 3rd party CI in your room Sam?;)
17:05:26 <SamYaple> my first though was to use the equipment as sort of a third party ci, but i think it may be better suited if i gave access to some of those heavier contributors to run multinode vm for kolla testing and development
17:05:42 <SamYaple> what does everyone think would benefit the community more?
17:05:47 <sdake> SamYaple the second
17:06:16 <sdake> third party ci should be company sponsored imo - although if someone sets up third party ci to comment on patches its not like wed stop them even if they were  running AIO third party cis :)
17:06:17 <inc0> I'd say first
17:06:19 <SamYaple> thats what I was leaning towrad too, but im not sure if everyone has access to multinode and just arent using it
17:06:30 <SamYaple> the second option that is
17:06:48 <sdake> anyone can get vms at rax or the like but its pretty expensive
17:06:54 <SamYaple> right
17:06:55 <inc0> non-heavy developer can break multinode just as much
17:06:55 <nihilifer> when i talked about 3rd party ci, i meant the one runned by mirantis
17:06:56 <sdake> how many vms can your environment support sam?
17:07:06 <pbourke> personally I have access to multinode, but it doesn't mean I have time to multinode every PS I review
17:07:14 <nihilifer> but i'm not sure whether you're talking about my idea of this ci ;)
17:07:14 <pbourke> but that's a different topic
17:07:23 <SamYaple> my hardware can do ~90 8GB vms
17:07:56 <sdake> actually a really solid idea SamYaple
17:08:05 * nihilifer has the same situation as pbourke
17:08:17 <SamYaple> im not hearing a concensus though. it soundsl ike everyone has multinode and doesnt use it
17:08:28 <pbourke> I wouldnt say everyone
17:08:37 <SamYaple> most heavy contributors
17:08:43 <sdake> can we get a poll
17:08:49 <sdake> who doesn't have access to multinode, please speak up
17:09:05 <Jeffrey4l> ( I am, only a laptop :( )
17:09:10 <nihilifer> well, i have one multinode env, but used only for mesos - that's why it's hard to me to test quickly kolla-ansible stuff
17:09:14 <nihilifer> that's what i meant
17:09:18 <sdake> Jeffrey4l GFC may be difficult for you
17:09:37 <SamYaple> Jeffrey4l: my stuff is hosted in US, is that an issue?
17:10:00 <Jeffrey4l> SamYaple, absolutely no.
17:10:23 <jpeeler> yeah i generally don't do multinode
17:10:31 <sdake> so atm my gear is afu and I don't have multinode but I think I can get that rectified
17:10:33 <SamYaple> so we have Jeffrey4l for multinode access rather than CI (right?)
17:10:38 <SamYaple> jpeeler: but do you have access?
17:11:03 <jpeeler> SamYaple: not really
17:11:03 <sdake> ya redhat has an internal development openstack environment SamYaple
17:11:17 <jpeeler> it's not very stable last i checked
17:11:19 <jpeeler> so i don't use that
17:11:49 <SamYaple> so really what this comes down to is do I volunteer my equipment to people or Jenkins.
17:11:58 <pbourke> you could do both?
17:12:01 <SamYaple> not really
17:12:05 <SamYaple> jenkins will tear it up
17:12:08 <pbourke> ok
17:12:17 <Jeffrey4l> I only a simple ( three vms running my laptop) env now. can not launch one more vms.
17:12:23 <Jeffrey4l> only have
17:12:48 <pbourke> SamYaple: I think you said rhallisey and inc0 were candidates
17:12:51 <pbourke> so with Jeffrey4l that's 3
17:12:55 <pbourke> there's probably more
17:13:03 <inc0> I can spawn more vms
17:13:12 <SamYaple> nah inc0 is covered now he said
17:13:16 <pbourke> but what I was getting at is path of least resistence means people generally dev AIO unless they really have to
17:13:20 <sdake> SamYaple if you can get it setup and want to maintain openstack hosting for kolla devs, its up to you :)
17:13:23 <sdake> sounds painful personally
17:13:31 <inc0> I'll have much better gear soon so I'm covered
17:13:32 <pbourke> so Im not sure it will magically get people doing more multinode testing
17:13:34 <sdake> pbourke agreed
17:13:45 <SamYaple> i qualified this with heavt contributors for a reason
17:13:53 <pbourke> without some sort of coercion :)
17:13:54 <inc0> that's why I'd rather go for 3rd party CI
17:14:03 <SamYaple> yea :/
17:14:04 <inc0> so we can at least catch stuff that breaks multinode
17:14:13 <SamYaple> really we should all be testing multinode primarily
17:14:24 <pbourke> we can figure out ways to promote that
17:14:24 <SamYaple> i thought it was resource contention
17:14:33 <sdake> so my take on this is we really wan tto try using the openstack infrasturcture for multinode rather then rolling our own third party ci
17:14:37 <SamYaple> it sounds like its laziness/time constraints
17:14:37 <pbourke> Im not sure I see the benfit of 3rd party CI
17:14:40 <inc0> I'd say it's rather efficiency thing
17:14:46 <Jeffrey4l> CI is necessary.
17:14:54 <SamYaple> im really effiecnt on multinode ic
17:14:55 <sdake> Jeffrey4l nobody denies that
17:14:55 <inc0> pbourke, you'll see "failed" gate job on CI
17:14:56 <SamYaple> inc0:
17:15:01 <inc0> that's alerting
17:15:05 <SamYaple> its no slower for me to test multinode than aio
17:15:09 <pbourke> inc0: I dont think its a good idea for it to do something infra cant
17:15:16 <pbourke> inc0: so with that said its just another env
17:15:19 <sdake> pbourke totally agree
17:15:28 <inc0> pbourke, infra is heavily limited
17:15:36 <inc0> we can barely run aio on infra
17:15:43 <pbourke> we should fix that then
17:15:48 <pbourke> im not disagreeing but...
17:15:51 <sdake> infra has repeadily said they will fix whatever we can't get to work
17:15:52 <inc0> I don't think we can currewntly
17:15:53 <pbourke> we cant gate on sams house
17:15:57 <sdake> but we haven't really tried multinode
17:16:13 <SamYaple> fyi with my gate patches we have ~3gb of ram before VM launch
17:16:18 <inc0> sdake, we needed to cut down services to boot single vm in infra
17:16:27 <sdake> inc0 yes i understand
17:16:45 <sdake> i am nervous about gating on mirantis gear, much less sam's personal lab ;)
17:16:59 <sdake> lets figure out gating in infra
17:17:01 <SamYaple> im also nervous about my equipment for gating
17:17:08 <inc0> so imho if we lose this gate, that's exactly what we have now
17:17:25 <inc0> it's a protesis before we can get normal infra to work with us
17:17:25 <sdake> inc0 except we have to develop the gating, which we could do in openstack-infra
17:17:40 <pbourke> you mean prototype?
17:17:51 <SamYaple> alright well to close out this topic ill say this. Im going to be setting up my lab for use by Kolla devs, if anyone wants to use it please contact me
17:18:06 <sdake> openstack-infra said repeatedly they would give us as many vms as we need, we just need to prove tha twe ccan for example do "two" vms
17:18:12 <inc0> I mean artificial leg that will keep us standing for now;)
17:18:13 <sdake> and then 3
17:18:17 <pbourke> SamYaple: I think you'll see up take on that offer. If not you can reconsider for other purposees
17:18:36 <sdake> cool we have 12 mins
17:18:41 <SamYaple> pbourke: did you not have access to multinode?
17:18:41 <sdake> #topic open discussion
17:18:45 <SamYaple> this is whats confusing me
17:18:56 <sdake> SamYaple people dont test multinode because they are -ELAZY
17:19:02 <pbourke> SamYaple: I do but Id be surprised if others didnt find it useful
17:19:08 <vhosakot> can I talk about what I'm working on as a new contributor ?
17:19:22 <SamYaple> vhosakot: yes
17:19:25 <SamYaple> go for it!
17:20:09 <vhosakot> Updating quickstart, hit keystone errors when cross-building (centos on Ubuntu), hence filed https://bugs.launchpad.net/kolla/+bug/1546652, will submit the fix soon
17:20:09 <openstack> Launchpad bug 1546652 in kolla "Add "--cross-build" argument to kolla-build" [Undecided,In progress] - Assigned to Vikram Hosakote (vhosakot)
17:20:25 <elemoine_> SamYaple: I think it would be useful to know/document how you set up you multinode env, so that people can mimic that and do the same in their labs
17:20:41 <SamYaple> vhosakot: would you explain what --cross-build is for the team?
17:20:45 <vhosakot> sure
17:20:48 <sdake> elemoine_ d_code has a single node centos setup script coming
17:20:55 <vhosakot> By default, "kolla-build" builds all containers using CentOS as the base image.
17:21:03 <vhosakot> ue to this, kolla-build fails to build many containers on Ubuntu due to the following errors.
17:21:07 <vhosakot> Due*
17:21:17 <vhosakot> INFO:kolla.cmd.build:keystone:Error unpacking rpm package httpd-2.4.6-40.el7.centos.x86_64
17:21:17 <vhosakot> INFO:kolla.cmd.build:keystone:error: unpacking of archive failed on file /usr/sbin/suexec: cpio: cap_set_file
17:21:17 <vhosakot> INFO:kolla.cmd.build:keystone:error: httpd-2.4.6-40.el7.centos.x86_64: install failed
17:21:20 <inc0> if you run centos containers on ubuntu host, you will have problems
17:21:22 <inc0> a lot of them
17:21:26 <vhosakot> Hence, a new argument "--cross-build" must be added for kolla-build. When the user builds CentOS images on Ubuntu and vice-versa, the "--cross-build" argument must be explicitly specified. If not, kolla-build must throw as error like "Your host OS is Ubuntu and you are building CentOS containers. Please use the "--cross-build" flag to do this" so that the user knows what he/she is doing.
17:21:34 <inc0> this is anti-pattern
17:22:07 <inc0> I'm -1 to that, you can print warning
17:22:19 <SamYaple> inc0: vhosakot spent 3 days building the wrong images
17:22:23 <SamYaple> it needs a hard stop
17:22:24 <sdake> vhosakot i think with our architecture this coudl be dangeorus to build on a distro with a different systemcall interface
17:22:31 <vhosakot> agreed
17:22:43 <sdake> this is the whole reason we have multi-distro support
17:22:44 <SamYaple> what vhosakot purposes is _blocking_ cross building by default
17:22:46 <vhosakot> i that case, how about kolla-build preventing what I did the past 3 days :)
17:22:50 <inc0> add the printed red capitalized warning "you are building wrong images, you will have issues"
17:22:56 <sdake> vhosakot that wfm
17:23:09 <SamYaple> inc0: no it should block. why continue if ther eare known issues?
17:23:19 <SamYaple> we currently block containers that we know dont work
17:23:24 <SamYaple> not just warn
17:23:44 <inc0> I just don't want to add new cli options
17:23:51 <sdake> inc0 me either
17:23:56 <vhosakot> cool, so, if host OS and container image type do not match, throw an error and exit... is this right ?
17:23:57 <SamYaple> fine well make it a conf only option
17:23:58 <inc0> and here I think it's redundant
17:24:01 <sdake> i ws pretty clear bout that in liberty ;)
17:24:08 <SamYaple> conf only option is fine
17:24:14 <sdake> vhosakot return i think
17:24:20 <SamYaple> but byy default it should block builds on cross-dristros
17:24:24 <sdake> vhosakot we want to amke the build.py work as a library
17:24:29 <sdake> even though it doesn't totally today
17:24:30 <vhosakot> ah
17:24:41 <inc0> one behaviour I would be more ok with is to raise on every container we know will break
17:24:51 <vhosakot> ok, throwa good error and return and do nothing.. cool
17:24:52 <inc0> and add --force to override all raises
17:25:01 <SamYaple> inc0: we do not currently track containers. I dont think its time we start
17:25:07 <ajafo> but build ubuntu images on centos works so maybe option would be good some --force
17:25:17 <vhosakot> --forece is good.. ok
17:25:29 <Jeffrey4l> btw, i am using Archlinux and I can build centos and ubuntu image successfully.
17:25:32 <inc0> SamYaple, you just want to start to some extend
17:25:43 <pbourke> thats interesting I thought the whole point of docker was you could build any base on any host (within reason)
17:25:43 <sdake> lets focus on simplicity first folks
17:25:53 <inc0> adding option per every case we run into is not scallable
17:25:56 <sdake> pbourke that is dangerous
17:26:17 <vhosakot> one more thing, I have a Python script that automates all the steps in the quickstart for Ubuntu. works great and the user need not have to run those commands manually to install kolla.. Can I commit this...
17:26:19 <sdake> pbourke docker may claim it works, but it does not 100% of the time safely]
17:26:21 <SamYaple> ok despite where this conversation is going, here is what we need. Hard block when you are building on the wrong familiy unless some option is specific (cli or conf only i dont care)
17:26:27 <pbourke> sdake: i see
17:26:39 <pbourke> SamYaple: sounds good to me
17:26:49 <sdake> i think we dont need an option
17:26:53 <pbourke> im surprised this is an issue honestly
17:26:53 <sdake> it should just block the build
17:27:00 <SamYaple> sdake: no because then it would block on archlinux
17:27:02 <pbourke> sdake: some may want to force?
17:27:05 <SamYaple> we dont want to limit people
17:27:13 <sdake> SamYaple i see
17:27:20 <pbourke> --force-cross-build maybe
17:27:21 <sdake> ok option in this case makes sense then
17:27:22 <inc0> do we agree that hard block + --force
17:27:30 <pbourke> inc0: yes
17:27:31 <inc0> ?
17:27:31 * sdake groans at options
17:27:33 <vhosakot> yes, --force-cross-build makes sense
17:27:50 <SamYaple> it doesnt need to be an option guys
17:27:50 <sdake> vhosakot i like that option
17:27:51 <inc0> I'm -1 to for creating option specifically for this case
17:27:54 <SamYaple> it can be a config
17:28:00 <sdake> this is all stuf fwe could talk about in launchpad tho :)
17:28:11 <SamYaple> inc0: im -2 on tracking per container what builds
17:28:18 <inc0> SamYaple, never said I want to
17:28:25 <SamYaple> you would have to though
17:28:26 <pbourke> vhosakot: thanks for bringing this up and proposing a solution
17:28:31 <inc0> no, not really
17:28:32 <vhosakot> sure, np
17:28:33 <SamYaple> yes thanks vhosakot
17:28:34 <sdake> vhosakot nice job ;)
17:28:38 <SamYaple> we are about to run over time
17:28:38 <vhosakot> :)
17:28:41 <inc0> if we know of issues (like now) we add hard block
17:28:44 <SamYaple> we should flow back to #kolla
17:28:46 <vhosakot> did you guys see me other comment ? :)
17:28:48 <vhosakot> one more thing, I have a Python script that automates all the steps in the quickstart for Ubuntu. works great and the user need not have to run those commands manually to install kolla.. Can I commit this...
17:28:51 <sdake> we have 1 minute left
17:28:57 <sdake> any one have something to bring up?
17:29:03 <pbourke> vhosakot: submit for review
17:29:07 <vhosakot> cool.. thanks!
17:29:14 <SamYaple> sdake: i think we have 5 secodns left....
17:29:15 <sdake> vhosakot don't ask for permission ;)
17:29:19 <elemoine_> sdake: nope
17:29:19 <vhosakot> :)
17:29:24 <pbourke> bye....
17:29:24 <sdake> ok folks
17:29:26 <sdake> thats it :)
17:29:27 <elemoine_> bye
17:29:28 <sdake> #endmeeting