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