16:01:40 <sdake> #startmeeting containers
16:01:41 <jay-lau-513> jay-lau-513
16:01:41 <openstack> Meeting started Tue May 26 16:01:40 2015 UTC and is due to finish in 60 minutes.  The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:45 <openstack> The meeting name has been set to 'containers'
16:01:53 <dims> o/
16:01:54 <diga> Digambar Patil
16:01:54 <thomasem> o/
16:01:56 <apmelton> o/
16:01:57 <tcammann> hello
16:01:58 <Tango> o/
16:02:02 <jay-lau-513> o/
16:02:02 <rbradfor> o/
16:02:03 <eghobo> o/
16:02:06 <juggler> o/
16:02:09 <joffter> o/
16:02:16 <sdake> #topic rollcall
16:02:26 <sdake> o/ ;)
16:02:35 <tcammann> \o/
16:02:42 <sdake> clearly runningon fumes here :)
16:02:55 <hongbin> \o
16:02:55 <sdake> we will wait for a moment for stragglers
16:03:25 <juggler> first time seeing the reverse \o before lol
16:03:35 <hongbin> typo ...
16:03:37 * apuimedo here
16:03:38 <jjlehr> o/
16:03:49 <juggler> hongbin nah it's cool :)
16:04:04 <sdake> the \o is a left hand
16:04:12 <juggler> yeah i know :)
16:04:12 <sdake> for all the cool kids with left handedness
16:04:21 <hongbin> ...
16:04:30 <juggler> i see tca is ambidextrous
16:04:33 <sdake> #topic announcements
16:04:53 <sdake> adrian won't be joining us for today's meeting
16:05:09 <apuimedo> ok
16:05:10 <sdake> I'm pretty sure his whirlwind tour requires some R&R
16:05:19 <juggler> haha seriously
16:05:29 <jjlehr> Well deserved
16:05:34 <sdake> juggler seriously I barely made it :)
16:05:42 <dims> :)
16:05:45 <juggler> i was going to say... :)
16:05:51 <sdake> ODS was a fantastic success
16:05:54 <sdake> we rocked summit
16:06:03 <sdake> my dad, attorney, smart dude, said something interesting
16:06:10 <sdake> I wanted to share
16:06:14 <juggler> go ahead
16:06:21 <sdake> he said CSCO got its full total compensation value out of me in 1 week at summit ;)
16:06:32 <sdake> I think that can be extended to the general magnum community at large
16:06:35 <sdake> so grats there :)
16:06:42 <juggler> +1
16:06:58 <dims> very true sdake. good work everyone!
16:07:10 <sdake> hopefully the check writers in your org are gung ho about magnum ;)
16:07:33 <sdake> there are several videos for those folks that have access to youtube
16:07:36 <dims> haha, we'll see
16:07:51 <sdake> #link https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/taking-risks-how-experimentation-leads-to-breakthroughs
16:08:10 <sdake> #link https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/magnum-containers-as-a-service-for-openstack
16:08:35 <sdake> and a magnum demo at
16:08:40 <sdake> #link https://wiki.openstack.org/wiki/Magnum
16:08:44 <eghobo> already sent first one to my VP, he is running from me now ;)
16:08:57 <sdake> pretty much, openstack is all in on cloud, and now openstack is all in on containers
16:09:10 <sdake> that is because of you!
16:09:14 <Tango> Hat off for the brave live demo in front of thousands of people
16:09:25 <juggler> agree!
16:09:30 <apuimedo> :-)
16:09:30 <sdake> there were several live demos ;)
16:09:35 <jjlehr> +1
16:09:49 <sdake> i would like to welcome new contributors
16:10:18 <sdake> since there are a bunch of cats I don't recognize inthe channel, would you mind introducing yourself and what you want to bring to magnum and your experiences in the past
16:10:41 <sdake> FIFO style
16:10:54 <sdake> go :)
16:11:14 <apuimedo> Hey, I'm Antoni Segura Puimedon. I was at the summit session about networking and I usually work on neutron (and a bit on nova plugging of net devices)
16:11:15 <brendenblanco> Hi, Brenden Blanco here from PLUMgrid, I hope to bring some Neutron expertise and improve the integration with Magnum from that perspective
16:11:37 <apuimedo> same target as ^^
16:11:44 <sdake> eghobo joffter
16:12:01 <hongbin> good to see neutron experts joining here
16:12:08 <sdake> ya we need that
16:12:15 <rbradfor> Ronald Bradford, relatively new to openstack contribution. consumer of clouds AWS/Rackspace/HPCloud for about 8 year. Been looking at testing, specifically coverage across the projects, so I've offered from a design summit to work into functional testing a unit test coverage component, and help identify areas for people to contribute to unit tests.
16:12:16 <sdake> my expertise is "holy crap I got neutron working!"
16:12:26 <juggler> lol
16:12:28 <eghobo> I am Egor Guz, I work for @Walmartlabs. we are looking to magnum as fast way to bring containers to our openstack environment
16:13:10 <jjlehr> joffter was a contributor to Kilo
16:13:20 <sdake> Atoni, Brenden, bradfor, egghobo welcome
16:13:24 <sdake> jjehr my apologies joffter
16:13:43 <sdake> if only my memory could be replaced by a really big SSD :)
16:13:59 <jjlehr> :)
16:14:00 <apuimedo> thanks ;-)
16:14:14 <sdake> we worked on a bunch of etherpads during summit
16:14:29 <joffter> :)
16:14:41 <sdake> #link https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Magnum
16:14:54 <sdake> use that for reference if your looking  for things to do
16:14:57 <sdake> or how to get involved
16:15:02 <sdake> or want to learn about the project
16:15:16 <sdake> its a snapshot in time of our liberty planning
16:15:32 <sdake> trust me, it will be far different at the end of the cycle ;)
16:16:06 <sdake> #topic action items
16:16:33 <sdake> adrian_otto had an AI to put the etherpads in one place - see link above - completed
16:16:48 <sdake> sdake had an action item to add the heat core to heat-coe-templates
16:17:04 <sdake> hey folks, I did one thing - :) completed
16:17:17 <juggler> haha, you do more than one thing
16:17:28 <juggler> (maybe 2+)
16:17:40 <sdake> maybe more ;)
16:18:02 <sdake> jack of all trades, master of <i>many</i> ;-)
16:18:20 <sdake> ok lets get down to business
16:18:27 <sdake> #topic blueprint review
16:18:58 <sdake> I created the l1 release of openstack, for which we will be executing our blueprints against nin the launchpad tracker
16:19:10 <sdake> rather OpenStack Magnum
16:19:27 <juggler> nin-new acro?
16:19:34 <sdake> thats right folks, we are OpenStack Magnum now ;-)
16:20:22 <dims> OM :)
16:20:26 <sdake> https://launchpad.net/magnum/+milestone/l1
16:20:30 <juggler> +1
16:20:33 <sdake> #link https://launchpad.net/magnum/+milestone/l1
16:20:49 <sdake> first lets go down that list
16:21:10 <sdake> #link https://blueprints.launchpad.net/magnum/+spec/objects-from-bay
16:21:19 <sdake> this is a prerequisitie for native client acces
16:21:31 <sdake> basically I plan to make magnum get its data from the magnum bay rather then the database
16:21:40 <sdake> this will negatively impact performance
16:21:40 <sdake> but positively improve feature set
16:21:57 <sdake> seems essential
16:22:05 <apmelton> +1
16:22:10 <sdake> and needs to be fleshed out in l1 because it will cause alot of breakage
16:22:10 <tcammann> Yeah, we came to that concensus in the design session
16:22:30 <hongbin> agree
16:22:40 <sdake> the database will be "deprecated" or atlaest minimized
16:22:46 <sdake> except for bays of course
16:22:51 <eghobo> +1
16:22:59 <jay-lau-513> sdake do we have bp for "deprecate database"
16:23:12 <jay-lau-513> for magnum bay related operations
16:23:19 <tcammann> hah, its a strong blueprint name :)
16:23:22 <sdake> jay-lau-513 no but I suspect the change set for the above blueprint will implement that
16:23:35 <jay-lau-513> sdake ok
16:24:02 <sdake> so sounds like everyone is in agreement this is essential for l1, yay - work for me to actually write code :)
16:24:13 <juggler> agree
16:24:22 <sdake> #link https://blueprints.launchpad.net/magnum/+spec/registryv2-in-master
16:24:38 <sdake> we spoke about putting registryv2 in the magnum master bay
16:24:43 <sdake> i assigned this to myself but am looking to offload it
16:25:02 <sdake> should be relatively easy
16:25:04 <sdake> any takers?
16:25:16 <tcammann> sorry, could you explain was registryv2 is again?
16:25:33 <sdake> that is so we dont have to wait 5 hours for a push/pull operation
16:25:35 <diga> yes, can you explain a bit more about it
16:25:40 <sdake> since it will be local to magnum
16:25:40 <jay-lau-513> also have same question, perhaps need more detail explanation
16:26:03 <sdake> the push pull will  use the gig40 or whatevernetwrok is in place
16:26:12 <sdake> rather then the dockerhub CDN which is way overloaded
16:26:44 <sdake> remember we are not taking away docker's monitization strategy, they can still monitize certificates as a service ;-)
16:26:46 <eghobo> sdake, are you proposing to run docker registry at master node by default?
16:26:54 <sdake> eghobo yup
16:26:56 <jay-lau-513> sdake so we need a local registery for magnum
16:27:44 <sdake> eghobo it wasn't my proposal, it was a summit proposal
16:27:53 <eghobo> it works for dev, but company usually have one shared docker registry for prod
16:27:56 <sdake> that received positive feedback
16:28:39 <eghobo> i am not against, i just try to understand use case
16:28:39 <apmelton> sdake: is the idea that the registry v2 in the master just acts like a caching proxy for docker's CDN?
16:28:42 <sdake> well lets assume for a moment its a good idea (it is, it was debated at summit)
16:28:56 <sdake> apmelton haven't the faintest idea
16:29:02 <eghobo> do we need to worry about HA for registry?
16:29:15 <sdake> that is what the magnum-er that takes it on will need to figure out
16:29:28 <sdake> eghobo we will tackle ha in a separate blueprint
16:29:38 <sdake> but at some point yes
16:29:58 <tcammann> Think was discussed in this meeting: https://etherpad.openstack.org/p/liberty-fishbowl-magnum-project-ideas
16:30:10 <sdake> ok what i'm looking for is a volunteer :)
16:31:01 <sdake> thanks for the link tcammann
16:31:16 <sdake> any takers for this blueprint?
16:31:49 <hongbin> :)
16:31:56 <sdake> hongbin hired!
16:32:13 <hongbin> I will take it if noone else take it
16:32:45 <diga> hongbin: do you mind if we split this https://blueprints.launchpad.net/magnum/+spec/mesos-bay-type BP in pieces
16:32:56 <sdake> diga hold up
16:33:03 <diga> sdake: okay
16:33:03 <sdake> we will get to uncategorized blueprints
16:33:22 <sdake> ok hongbin your the stuckee :) enjoy
16:33:33 <hongbin> k
16:33:42 <eghobo> sdake, hongbin: I may help, but I don't know my time allocation yet ):
16:34:00 <sdake> #link https://blueprints.launchpad.net/magnum/+spec/magnum-bay-snapshot
16:34:12 <sdake> this is snapshotting magnum bays
16:34:24 <sdake> i'm not quite sure how it works
16:34:30 <sdake> but it looks like its being tackled
16:34:38 <sdake> so we will just let that in :)
16:34:56 <jay-lau-513> sdake we are just leveraging heat feature for this bp
16:34:58 <tcammann> We can restore running containers with its volumes?
16:35:11 <sdake> tcammann running bays
16:35:16 <sdake> #link https://blueprints.launchpad.net/magnum/+spec/integrate-ci-metrics
16:35:31 <sdake> jay-lau-513 yes i read the reviews
16:36:13 <tcammann> Not sure how I feel about -1'ing a patch because it reduces code coverage by 1%
16:36:19 <sdake> I am not hot on voting gates related to coverage
16:36:38 <tcammann> Same
16:36:40 <sdake> no other openstack project votes on coverage
16:36:51 <sdake> and I know this for certain, I looked
16:36:59 <sdake> bradfor we are talking about integrate-ci-metrics
16:37:15 <rbradfor> sdake: sorry, lost connectivity on one machine, had to switch
16:37:17 <sdake> to summarize, I think some folks are not hot on a voting gate
16:37:26 <sdake> a non-voting gate seems ok
16:37:32 <rbradfor> I would agree.
16:37:44 <sdake> the blueprint is written to indicate it would be voting
16:37:45 <rbradfor> I think it would take a cycle to become familar with the process.
16:37:49 <sdake> could you improve that a bit?
16:38:00 <rbradfor> sure, I’ll indicate it’s a non-voting gate.
16:38:10 <sdake> ta :)
16:38:51 <rbradfor> before the gate however, I have some questions on where to we record this information for general consumption. Any recommendations? The wiki seems not the ideal place.
16:39:10 <tcammann> run coverage on HEAD, then run coverage on HEAD~1. Compare
16:39:32 <sdake> the gate is the place - project-config is the repo you need to take a look at rbradfor
16:39:38 <sdake> I added covergage to he post jobs
16:39:45 <rbradfor> information includes:  1. coverage reports, 2. overall coverage percentage, 3. Code that could benefit from Unit Tests.
16:39:46 <sdake> if you want to do what you propose you will need to add it as a check
16:40:23 <sdake> apmelton can you find the project config link so I can continue the meeting plz :)
16:40:26 <sdake> and add a link
16:40:31 <rbradfor> yes, that’s really the end game of using the Code Coverage as a metric.
16:40:34 <sdake> #topic uncategorized blueprints
16:40:51 <sdake> so we have a bajion of these
16:41:08 <apmelton> sdake: this what you're looking for: https://github.com/openstack-infra/project-config
16:41:10 <sdake> if you plan to work on something in liberty 1 which ends june 25th
16:41:12 <sdake> and have it working or partially working
16:41:14 <sdake> apmelton thanks
16:41:22 <sdake> bradfor thats what you want to add your work to
16:41:28 <sdake> join #openstack-infra for guidance
16:41:40 <sdake> tell them what you want to do
16:41:41 <sdake> they will tell you how ;)
16:41:46 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/mesos-bay-type
16:41:47 <rbradfor> thanks
16:41:55 <sdake> hongbin first on deck
16:42:20 <hongbin> Adding support for mesos have been discussed in the summit
16:42:30 <hongbin> Everyone agree
16:42:40 <tcammann> +1
16:42:47 <eghobo> +1
16:42:48 <juggler> +1
16:42:50 <jjlehr> +1
16:42:56 <hongbin> diga: I will investigate how to split this BP if I can
16:42:59 <sdake> where I have questions is the python language binding for mesos
16:43:02 <sdake> is there one?
16:43:07 <diga> hongbin: sure
16:43:07 <apuimedo> +1
16:43:17 <hongbin> sdake: will look into that
16:43:26 <sdake> we spent inordinate amount of time on python language binding for kubernetes
16:43:26 <tcammann> Has a python cli...
16:43:34 <sdake> and we have to spawn an entire new project to make it happen
16:43:41 <sdake> not hot on cli ;)
16:43:48 <sdake> but maybe we can call directly into it
16:44:00 <sdake> i.e. use it as a library
16:44:03 <diga> sdake: need to check but I have studied & did implement on vm
16:44:03 <hongbin> sdake: sure if that is the simplest way
16:44:04 <jay-lau-513> sdake I think that what we need is mesos framework python api?
16:44:23 <sdake> jay-lau-519 yup!
16:44:23 <eghobo> sdake they usually use static library, but Aurora folks working on pure python binding. I will post link later
16:44:33 <jay-lau-513> sdake because we need to tell end user install framework manually
16:44:41 <sdake> eghobo taht would be fantastic, likely on our wiki would be a good place
16:44:52 <jay-lau-513> but this bring trouble for  how we design magnum api for mesos
16:44:53 <apmelton> https://issues.apache.org/jira/browse/MESOS-946
16:45:02 <apmelton> sounds like they're having troubles packaging their cli
16:45:12 <apmelton> er their python binding
16:45:18 <sdake> ok well here is the deal
16:45:32 <sdake> we will go through the same native client nonsense we are going through with docker and kubernetes with mesos
16:45:42 <sdake> so it would be nice if we did the job right from the beginning
16:45:48 <sdake> that is my only guidance on this blueprint :)
16:46:01 <hongbin> k
16:46:10 <diga> sounds good
16:46:10 <sdake> next blueprint
16:46:45 <eghobo> apmelton: there is no cli, we need to communicate through libmesos
16:46:49 <sdake> just to put things in perspective, I think we will have to go through this blueprint planning process for most of l1 ;)
16:46:59 <sdake> so if we don't hav them all sorted out right this moment that is ok
16:47:04 <apmelton> eghobo: yes, it was a mis-type on my part
16:47:26 <apmelton> it does look like they have python bindings
16:47:27 <sdake> this is somethign the specs process fixes
16:47:35 <apmelton> but they are though to build
16:47:40 <sdake> but we aren't doing specs for liberty
16:47:44 <apmelton> build/package/upload to pypi
16:48:12 <sdake> are there other blueprints people are going to tackle in l1 that need to be placed in the tracker
16:48:27 <apmelton> #link https://blueprints.launchpad.net/magnum/+spec/async-container-operations
16:48:55 <apmelton> also, is there a BP already for the barbican/anchor/some other secrets store integration work?
16:49:11 <tcammann> +1 on the async work
16:49:21 <sdake> apmelton this blueprint you just linked is like what I"m doing for kubernetes
16:49:24 <sdake> so +1
16:49:25 <diga> +1
16:49:35 <hongbin> +1
16:49:38 <tcammann> Think the TLS stuff comes under https://blueprints.launchpad.net/magnum/+spec/secure-kubernetes
16:49:39 <brendenblanco> +1
16:49:42 <apmelton> sdake: the db-less bay objects?
16:49:46 <tcammann> but I think it should be broken out
16:50:22 <sdake> apmelton right
16:50:34 <sdake> tcammann thanks hang tight - i'm only one person :)
16:51:10 <sdake> apmelton arey ou assignee of this blueprint async-container-ops?
16:51:22 <apmelton> yes, sdake
16:51:39 <apmelton> I'll hopefully have it completely fleshed out by next meeting
16:52:13 <sdake> nice
16:52:16 <sdake> ok secure kube
16:52:27 <sdake> this will be the last bp we discuss before open discussion
16:53:11 <sdake> hongbin is madhuri on her own on this one?
16:53:18 <sdake> seems like you have a full plate
16:53:27 <hongbin> sdake: yes, she said she want to take that
16:53:43 <apmelton> I can help out on this piece as well
16:54:03 <apmelton> I'm being told it should be my highest magnum priority
16:54:09 <tcammann> I will certainly too
16:54:19 <sdake> it is the highest absolute highest magnum priority
16:54:40 <sdake> #link https://launchpad.net/magnum/+milestone/l1
16:54:46 <tcammann> maybe we should sort a google hangout to discuss
16:54:46 <sdake> there are current l1 blueprints
16:55:04 <sdake> if there are more that people want to contirbute for l1, please bring to next meeting
16:55:12 <sdake> #topic open discussion
16:55:18 <sdake> first off, I go first :)
16:55:25 <sdake> the energy is fantastic!
16:55:48 <sdake> lets rock l1 and really get all our planned blueprints implemented - June 25th is the deadline
16:55:56 <sdake> and we are sticking to strict deadlines this time
16:55:57 <sdake> no slipping
16:56:01 <sdake> if its not done, it will be bumped
16:56:21 <sdake> ok that is all :)
16:56:36 <juggler> anyone here attending this? https://developer.cisco.com/site/openstack-newcomer-training/
16:56:40 <sdake> 4 minutes - any open discussion?
16:56:54 <sdake> I was a newcommer about 4 yeas ago, so no :)
16:57:02 <apmelton> :P
16:57:12 <juggler> lol sdake
16:57:13 <sdake> but cisco training rocks
16:57:19 <thomasem> Glad they put the quotes around 'get' and not 'openstack'
16:57:22 <sdake> so I expect folks will appreciate it - for our new contributors
16:57:23 <thomasem> gets*
16:57:47 * thomasem snickers
16:58:11 <sdake> Adrian and I could really use help maintaining the blueprint tracker
16:58:19 <sdake> if your interested in helping, please contact me off-list
16:58:34 <sdake> typically the entire core team should be involved in managing the tracker
16:58:40 <sdake> not the ptl
16:59:10 <apuimedo> I was wondering if there is something new about the native networking
16:59:10 <sdake> it just means you need to have a good mouse, because you will have to click - alot ! :)
16:59:25 <sdake> apuimedo find the blueprint, bring up in next meeting
16:59:26 <apuimedo> because many people asked about it in the summit, I went to talk to the libvirt people
16:59:38 <sdake> if there is no bluerpint file one
16:59:40 <apuimedo> and even though there are now pci bridges
17:00:08 <apuimedo> it is not really an option for scale to just put/hotplug N devices to the VM
17:00:10 <sdake> ok our time has expired
17:00:14 <apuimedo> so that has to be put to rest ;-)
17:00:18 <sdake> overflow in #opentack-containers
17:00:20 <sdake> #endmeeting