17:03:42 <colindixon> #startmeeting
17:03:42 <odl_meetbot> Meeting started Wed Jan 29 17:03:42 2014 UTC.  The chair is colindixon. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:42 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:03:46 <colindixon> #topic roll call and agenda
17:03:52 <colindixon> pelase #info in
17:03:56 <regXboi> #info regXboi for opendove
17:03:59 <edwarnicke> #info Ed Warnicke controller
17:04:08 <dmm> #info dmm
17:04:13 <colindixon> so, it's not clear to me whether this is supposed to be a release review meeting or not
17:04:23 <dmm> colindixon: no
17:04:35 <colindixon> dmm: good to know
17:04:41 <colindixon> not sure how I got that impression
17:04:41 <abhijitkumbhare> #info Abhijit Kumbhare for openflow plugin
17:04:48 <edwarnicke> dmm: Are Release Reviews Friday?
17:05:26 <colindixon> ok, in that case the agenda should be light today, it's basically about the remaining tasks to get this release done
17:05:30 <dmm> edwarnike: yes
17:05:31 <cdub> #info Chris Wright for good measure
17:05:37 <dmm> 0900 PST
17:05:52 <dmm> probb sent an email around
17:06:02 <tykeal> #info Andrew Grimberg for infrastructure support
17:06:07 <edwarnicke> dmm: That was what I remembered :)
17:06:13 <colindixon> ok, and it's friday only?
17:06:17 <rovarga> #info Robert Varga for bgpcep/yangtools
17:06:19 * edwarnicke is amazed that he wasn't crazy on this point...
17:06:22 <phrobb> #info phil robb here for various items
17:06:24 <dmm> colindixion: that is the plan
17:06:37 <tykeal> just sent an FYI email out about the rather persistent 502 errors from nexus showing up in merge builds. I still don't have an ETA on resolution :(
17:06:41 <colindixon> #info the agenda today is remaining items to finish off the release plus topics others want to bring up
17:06:43 * regXboi don't look to regXboi to judge, he knows his sanity is questionable
17:06:47 <edwarnicke> dmm: Would this be a good place to close the loop with folks about the Release Reviews on Friday?
17:06:52 <colindixon> #topic release reviews
17:07:03 <phrobb> EdWarnicke: you should have received and email
17:07:17 <dmm> edwarnike: sure
17:07:24 <colindixon> release reviews will be held here, on Friday, January 31st at 0900 PST, correct?
17:07:29 <colindixon> so I can #info it
17:07:35 <dmm> colindixon: please do
17:07:36 <colindixon> welcome abhijitkumbhare
17:07:41 <colindixon> welcome aboch rather
17:07:48 <colindixon> (damn tab completion)
17:07:50 <abhijitkumbhare> :-)
17:08:12 <colindixon> #info release reviews will be held here, on Friday, January 31st at 0900 PST
17:08:12 <abhijitkumbhare> that was thanks - even if not intended for me :-)
17:08:38 <colindixon> #link https://wiki.opendaylight.org/view/Sample_Release_Review for those that haven't already copied it, this is the sample template for a release review
17:08:48 <colindixon> #info the intent is for these to be 10-15 minutes per project max
17:08:55 <edwarnicke> Who from each project is committed to being here for their release review with the completed Release Review Doc?
17:08:57 <colindixon> abhijitkumbhare: don't worry, I still love you
17:09:10 <abhijitkumbhare> cool :-)
17:09:11 <edwarnicke> colindixon: Could you also point to the guidance on Release Review placement?
17:09:19 <colindixon> edwarnicke: I think dave is gathering that on the mailing list
17:09:34 <edwarnicke> #info Ed Warnicke commits to being here Friday at 9am PST with a completed Release Review doc for controller
17:09:52 * edwarnicke waits for everyone to be shocked
17:09:56 <edwarnicke> ;)
17:09:57 <colindixon> #link https://wiki.opendaylight.org/view/HydrogenRelease:Documentation_Scope_and_Location this page gives advice on the placement/naming of the release reviews
17:10:14 <regXboi> edwarnicke: you cloning or delegating or ???
17:10:16 <colindixon> if people that are here can #info that they'll attend for their project or who will, that would be great
17:11:28 <regXboi> #info regXboi should be there for OpenDove - if not, I'll draft colindixon :)
17:11:31 <colindixon> abhijitkumbhare, regXboi rovarga, aboch: that would be you guys
17:11:32 <rovarga> #info Robert Varga will attend review for BGPCEP and yangtools
17:11:35 <colindixon> yay
17:11:52 <colindixon> rovarga: I can see that you, already sent mails
17:12:16 <rovarga> as noted, I would appreciate an earlier slot
17:12:17 <colindixon> abhijitkumbhare: can you make it? or who will be there for ofplugin?
17:12:23 <abhijitkumbhare> #info Abhijit Kumbhare will attend for OpenFlow plugin
17:12:34 <colindixon> that's everyone that's attending
17:12:40 <colindixon> that's here
17:12:50 <colindixon> ok, next topic is docs unless anyone stops me
17:12:51 <abhijitkumbhare> Hopefully Michal Rehak will also be there to keep me honest :-)
17:13:02 <regXboi> flip the topic
17:13:09 <colindixon> #topic documentation
17:13:22 <colindixon> so, in my mind this is the biggest remaining hurdle
17:13:59 <colindixon> #link https://wiki.opendaylight.org/view/Release/Hydrogen this is the root page of current documentation
17:14:07 <cdub> i like doc-a-thon idea
17:14:15 <colindixon> we really need help here
17:14:23 <colindixon> I tossed out the idea of having a doc-a-thon tomorrow
17:14:25 <edwarnicke> I am down for the doc-a-thon
17:14:28 <regXboi> doc-a-thon?
17:14:32 <regXboi> not during the week
17:14:36 <edwarnicke> Especially since extra eyes make it easier to spot bad docs
17:14:39 <dmm> cdub: probb suggested the doc-a-thon idea some time ago
17:14:58 <colindixon> where we try to have everyone that was writing code until monday instead write docs as much as possible
17:14:58 <cdub> yeah, although that was more offsite, in person, multi-day
17:15:03 <colindixon> maybe tomorrow
17:15:06 <cdub> maybe a kickstart of irc tomorrow?
17:15:10 <ermagan> #info Vina will attend for LISP release review
17:15:18 <colindixon> thanks ermagan
17:16:02 <colindixon> so, that leaves the other part of this which is when are we going to call our docs good enough, sweep the cobwebs away and get it ready for having links from the download page
17:16:29 <colindixon> #info colindixon and cdub float the idea of a doc-a-thon, possibly starting tomorrow coordinated (loosely) via IRC
17:16:53 <ermagan> <colindixon> sure, thank you  :)
17:17:01 <edwarnicke> colindixon: I don't expect docs to 'freeze' quite the way code does (at least on a wiki)
17:17:13 <edwarnicke> But rather to evolve as we see user confusion
17:17:27 <edwarnicke> I like the doc-a-thon idea
17:17:29 <colindixon> edwarnicke: I agree, but we probably want to remove the "Scratch" section from the root page before release
17:17:39 <colindixon> ok
17:17:50 <colindixon> #help we really need help with docs, please try to lend a hand
17:18:12 <colindixon> #action cdub, edwarnicke, and colindixon will try to coordinate running a loose doc-a-thon tomorrow
17:18:27 <colindixon> ok, I'm going to move to the next topic unless anyone objects
17:18:30 <rovarga> one question: BGP/PCEP come pre-loaded in SP
17:18:32 <cdub> *nod*
17:18:38 <colindixon> also, everyone feel free to raise new topics
17:18:43 <rovarga> what sort of install guide should we have?
17:19:03 <colindixon> rovarga: I don't think you need to worry about the install guide as long as it gets things up and running
17:19:18 <colindixon> I think the key is to provide a user guide that walks through some example using the project
17:19:24 <edwarnicke> rovarga: I think that we probably have install guides per edition, not per project
17:19:38 <rovarga> okay, great
17:20:01 <cdub> could simply point that out in a sentence (you got this via SP...)
17:20:29 <edwarnicke> cdub: Also a good possibility
17:20:35 <edwarnicke> Or link to the SP install guide
17:20:43 <colindixon> #info I think that what projects need to worry about the most with documentation is: (1) making sure the install guide for the relevant edition walks through enough to get something working and (2) work through some simple, but useful, example of getting the part of the edition that relies on your project to do something
17:21:20 <colindixon> #info part (2) above would be in the user guide
17:21:41 <colindixon> #info cdub and edwarnicke point out that it's probably worth having a sentence in the user guide pointing to the relevant installation guide, probably with a link
17:21:42 <colindixon> ok
17:22:01 <colindixon> do we have luis?
17:22:04 <colindixon> I think not
17:22:23 <colindixon> #topic download page and downloadable artifacts
17:22:28 <aboch> #info Alessandro will attend controller release review
17:22:52 <colindixon> there was some back and forth about VMs, OSes, and things on the mailing list in the the last 12 hours or so
17:23:00 <colindixon> can anyone summarize it?
17:23:36 <colindixon> the other part is that if your project requires non-OSGi-bundle things, they need to be wrapped up somehow and made avaiable for downlaod, but I think that's only VTN and OpenDOVE
17:23:46 <regXboi> I'm not sure I understood it the first time through!
17:23:59 <colindixon> shague: are you around
17:24:00 <colindixon> ?
17:24:07 <shague> yeah
17:24:29 <colindixon> so, do you understand what the conversation this morning was about the VMs on the download page
17:24:47 <colindixon> or anything else you want to disseminate/make people aware of going into the last 5 days or so
17:25:12 <shague> The dicsussions was around that the VMS are not represnetative of how a true deployment would be.
17:25:35 <shague> People are not likely to deploy odl on  ubuntu 13.04, they would use a LTS release.
17:25:41 <phrobb> summary is that Luis' VM's are for tools/testing, not for the controller.   So the VM's we have from the Integration team are not actually tested for running OpenDaylight.  Instead it is used/tested for running the tools that test OpenDaylight
17:25:44 <colindixon> (also dbainbri, I'd love to have a quick readout of docker stuff)
17:25:49 <edwarnicke> shague: Is the issue there just CPqD?
17:25:54 <regXboi> um
17:25:57 <edwarnicke> (or something else)
17:26:08 <regXboi> then how are we distributing non-OSGi artifacts?
17:26:12 <shague> 13.04 compare to 12.04LTS
17:26:21 <edwarnicke> regXboi: Do you have packages (rpms etc)
17:26:53 <shague> My thought is the VMS are just a quick start for users.
17:26:54 <edwarnicke> I'd suggest we either go with the latest LTS or the latest Ubuntu Release generally
17:27:01 <edwarnicke> shague: I tend to agree with you
17:27:02 <regXboi> edwarnicke: no, ashaikh sent spec files to shague, and I was under the impression they'd be used to make rpms that would be used to distribute
17:27:08 <regXboi> that's not what I'm seeing now
17:27:20 <edwarnicke> What do you need to do *something*: the installed ODL pieces, OVS, mininet, etc
17:27:27 <edwarnicke> regXboi: How are you seeing it?
17:27:32 <cdub> shague: right...as in precanned install of ODL
17:27:50 <regXboi> I've got a zip file for the virtualization edition and the rest (right now) is source code and build
17:28:02 <colindixon> #info There was a discussion on the discuss mailing list this morning about what the VMs being provided on the download page are for and thus what OS they should be running. It appears as though the VMs we have now are more angled for testing than deployment of OpenDaylight.
17:28:49 <edwarnicke> regXboi: Source code and build strikes me as *radically* un-user-friendly
17:29:03 <regXboi> edwarnicke: exactly, that's why I'm not happy
17:29:06 <edwarnicke> When I see that as a user/dev... I tend to read it as a giant "Don't use me" sign
17:29:10 <colindixon> so, what's the current plan here? along two axes, first what are we doing for a VM version of the OpenDaylight editions instead of jus testing stuff? second, what are we doing w.r.t. other parts of projects for things like VTN and OpenDOVE?
17:29:34 <colindixon> also, if dbainbri is around, I'll toss in docker
17:29:44 <shague> To Luis's point, though, people have questions around what the VMs are and we are having a hard time getting the  message that they are just a quick start. We just happen to overlaod the test VMs since they were already built.
17:29:53 <edwarnicke> regXboi: Are you going to have packages?
17:30:07 <regXboi> it looks like I'm going to have to package things myself (grumble)
17:30:15 <colindixon> edwarnicke: regXboi and anees send in spec files
17:30:22 <colindixon> I"m not sure what happened after that
17:30:28 <regXboi> colindixon: yes, but that was for the quick start VMs
17:30:34 <edwarnicke> shague: Were you able to do something with their spec files?
17:30:39 <shague> the specs are under review.
17:30:41 <colindixon> so, are we not having quick start VMs?
17:30:55 <regXboi> if that's not for general distribution, then we need to pull the rpms back out and put them on the download page
17:31:12 <edwarnicke> colindixon: I certainly hope we do :)  Are we not converging on them?
17:31:33 <edwarnicke> regXboi: Either way I'd say we should have either the rpms or a yum repo on the download page
17:31:35 <colindixon> I don't know phrobb and shague do you have a good read on that?
17:32:14 <shague> I assumed the rpms would be there for OpenDove, Separate from the VM.
17:32:16 <regXboi> edwarnicke: no arugment - I was *hoping* to leverage the build for the quick start VMs and pull the rpms out of that
17:32:32 <regXboi> but it looks like the ball has been dropped somewhere
17:32:46 <edwarnicke> Guys... we've got paulz here... he's a crackerjack doc guy... was hoping maybe he could help as a bit with doc organization and presentation
17:32:57 <shague> The idea was if you wanted your non-edition stuff in a vm you would add them
17:33:20 <colindixon> LuisGomez: hey
17:33:23 <regXboi> ok, so it looks like there was a breakdown in communication somewhere along the line
17:33:37 <LuisGomez> hi, sorry for joining late
17:33:56 <colindixon> LuisGomez: we're trying to figure out the VMs for the download page
17:34:06 <edwarnicke> regXboi: Can we unbreak communication here and get things going?
17:34:14 <colindixon> that's what I'm hoping
17:34:22 <LuisGomez> ok
17:34:34 <regXboi> if I need to produce the rpms, that's a task I wasn't planning for
17:34:40 <regXboi> and it's going to make things dicey
17:35:10 <colindixon> right now, it sounds like we *don't* have quickstart VMs that are built to just nab the editions and run them without having to install anything on your computer outside of a VM
17:35:14 <colindixon> is that right?
17:35:45 <shague> regXboi: the specs that Anees pushed, aren't those what you need to build the rpms?
17:35:57 <LuisGomez> colindixon: i think that is correct
17:36:00 <regXboi> shague: not quite
17:36:14 <regXboi> I wouldn't need to build an rpm for the controller
17:36:19 <regXboi> just for the other components
17:36:28 <colindixon> LuisGomez: it *seems* like we really do want to have quickstart VMs
17:36:38 <cdub> indeed
17:36:47 <regXboi> and to colindixon's point
17:37:02 <cdub> we have VMs...they just aren't "quickstart VMs" they have an overloaded purpose
17:37:11 <LuisGomez> colindixon: thing is it is so easy to download the zip and run it on any environment that why you need a VM for that?
17:37:22 <colindixon> both for consumability and to act as a base for building other components for other projects, like VTN and OpenDOVE
17:37:28 <edwarnicke> colindixon: I think *definitely* for the vtn and opendove pieces... stuff that just runs out of a zip file isn't *so* bad for the other stuff (though even there VMs with mininet and OVS would be good)
17:37:32 <cdub> LuisGomez: VTN and OpenDOVE have binary components
17:37:51 <regXboi> worse, OpenDove has kernel mods
17:37:59 <regXboi> for part of our components
17:38:01 <LuisGomez> cdub: yes we need VMs or rpms for those components
17:38:13 <edwarnicke> regXboi: Not sure how that will play nicely with others in a VM :(
17:38:29 <colindixon> LuisGomez: so, is there any reason why we can't use the current VMs as quickstart VMs?
17:38:36 <regXboi> edwarnicke: that particular piece would need to be installed in its own VM
17:38:44 <regXboi> because of that concern
17:39:04 <colindixon> edwarnicke: I think regXboi was just hoping he could clone and corrupt the VM and then post it as a separate thing
17:39:21 <cdub> heh corrupt
17:39:24 * edwarnicke sees the wisdom in regXboi's corruption ;)
17:39:33 <cdub> that's "augment"
17:39:37 <regXboi> yeah, that idea isn't going to work though
17:39:37 <LuisGomez> colindixon: current VM you mean test VM?
17:39:49 <regXboi> what's the kernel in the test VM?
17:40:08 <colindixon> shague: feel free to jump in here too
17:40:11 <colindixon> LuisGomez: yes
17:40:29 <LuisGomez> test VM is made with test purposes
17:41:00 <colindixon> LuisGomez: sure, but it contains a bunch of useful tools and could be augmented with an installation of each edition, right?
17:41:12 <LuisGomez> yes
17:41:15 <colindixon> and it's been tested
17:41:25 <colindixon> you've even run the controller from inside it, right?
17:41:25 <shague> that was the idea. Start with the test VMs. That worked fine for most editions. If you had some thing you needed to augment, then take that VM and augment it. But it would be differnt.
17:41:30 <LuisGomez> i am good to add installables there
17:41:39 <colindixon> ok, so that sounds like plan A
17:41:43 <LuisGomez> as i said in the beginning
17:41:44 <shague> Lui's gave us a platform that was tested and know to work.
17:42:46 <colindixon> #action LuisGomez and shague to work to turn the test VM into a per-edition quickstart VM that users can download to play around with the controller. Not intended as a production deployment vector though.
17:42:54 <colindixon> ok, that's good
17:43:09 <colindixon> the next thing is figuring out what VTN and OpenDOVE will do
17:43:22 <colindixon> but if we get *that* VMs working with the virtualization edition in it, it's a good start
17:43:34 <colindixon> and I think then brings us back to where we thought we were
17:43:48 <colindixon> LuisGomez, regXboi, shague: does that make sense and is it doable?
17:44:04 <regXboi> sorta
17:44:13 <regXboi> it will get opendove most of the way there
17:44:20 <regXboi> but not 100% across the finish line
17:44:33 <regXboi> colindixon: you and I will have to come up with a separate VM to push across the finish line
17:44:41 <colindixon> regXboi: yes, but it will at least return us back to where we thought we were
17:44:47 <colindixon> shague, LuisGomez?
17:45:24 <LuisGomez> test sorry i am a little lost here, what is this, another VM?
17:45:46 <shague> yeah. The VMs are already per-edition so we are good there.
17:46:01 <LuisGomez> ok
17:46:08 <colindixon> LuisGomez so, I want to know if you and shague are on board with with turning the test VM into a VM per-edition and it sounds like we are
17:46:11 <edwarnicke> Are VTN and OVSDB and Affnity goingto be OK with the kernel mods
17:46:11 <colindixon> ok
17:46:22 <regXboi> whoa, edwarnicke
17:46:25 <colindixon> edwarnicke: I don't think we're planning on breaking their VMs
17:46:34 <regXboi> I'm not proposing kernel mods on the per-edition VM
17:46:36 <cdub> kernel mods?
17:46:48 <colindixon> we're planning on having a separate OpenDOVE VM for the components that require kernel mods
17:46:49 <LuisGomez> sorry, how can we make the test VM an edtion VM?
17:46:50 <cdub> ok, whew didn't think so ;)
17:46:58 <regXboi> cdub: I'm not THAT crazy
17:47:06 <regXboi> I'm certifiable, but not nutz
17:47:23 <cdub> heh
17:47:32 <colindixon> LuisGomez: there will be a VM that runs the controller part of OpenDOVE and there will be a different VM for running the OpenDOVE gateway and the other components that will require kernel mods
17:47:34 * edwarnicke stamps certifiable on regXboi's forhead
17:48:04 <regXboi> colindixon: let's say it this way
17:48:16 <colindixon> the first VM will be an edition VM, the second VM is something that regXboi (and I) will be responsible for creating
17:48:32 <regXboi> there will be a VM that can run the controller part and/or the other parts of OpenDove that don't require kernel mods... and then go on
17:48:41 <colindixon> yes
17:48:44 <regXboi> everything else you said is fine
17:48:54 <LuisGomez> ok, just to be clear, the test VM can easily have controller artifacts and can be run as controller for demo/test purposes
17:49:07 <regXboi> that's part 1
17:49:20 <LuisGomez> but why we need then  VM/edition?
17:49:29 <LuisGomez> it will be the same VM
17:49:46 <regXboi> because the controller is different in the different editions?
17:49:47 <dbainbri> #info dbainbri - docker
17:50:04 <regXboi> the base controller doesn't have the virtualization bundles...
17:50:43 <shague> the integration vms have all three editions in them, Luis correct me if I am wrong.
17:50:47 <edwarnicke> additionally... virtualization edition has very different options than the other two
17:51:44 <colindixon> hey dbainbri
17:51:49 <dbainbri> hello
17:52:33 <colindixon> dbainbri: there's a lot of back and forth about VMs for the last 30 minutes now, you could read that and then I'll maybe ask for some docker info
17:52:41 <colindixon> ok
17:52:49 <dbainbri> ACK
17:52:58 <LuisGomez> regXboi:testVM has 3 folders for 3 different editions
17:53:01 <edwarnicke> colindixon: docs?
17:53:17 <colindixon> so, given that what's left over is basically a back and forth between shague, LuisGomez, regXboi and maybe VTN later, I'm going to say we take that offline
17:53:21 <LuisGomez> regXboi: so no point to deplot 3VMs
17:53:27 <colindixon> and move back to docs quickly
17:53:32 <colindixon> and then maybe to docker
17:53:44 <LuisGomez> colindixon: agree, we can take it offline
17:53:54 <regXboi> yeah, let's do that
17:53:56 <colindixon> #topic documentation again quickly
17:54:07 <edwarnicke> Guys... meet paulz
17:54:13 <edwarnicke> He's a great doc guy
17:54:25 <edwarnicke> I was hoping he could help us a bit with doc presentation and organization
17:54:35 <paulz> Hi all, I worked on the original ODL docs, so happy to help this time too
17:54:52 <colindixon> ok, cool
17:54:54 <edwarnicke> paulz: I know you've just been looped in, any thoughts on how we could effectively engage with you to make docs better?
17:54:56 <paulz> Ed sent me links to the current content, looking for priority, etc
17:55:04 <colindixon> is there anything else you wanted to add? or to know?
17:55:48 <colindixon> paulz: my personal take is that what we need is to make sure the installation guides work and are bulletproof and then we need to have canonical tutorials that take people through using different parts of the editions
17:55:59 <dbainbri> colindixon: fire when ready
17:56:14 <paulz> OK, that makes sense...
17:56:16 <colindixon> paulz: for the most part right now I think that's going to be something like per-project tutorials
17:56:17 <edwarnicke> colindixon: I think you also pointed to having at least one simple thing to show per edition
17:56:24 <colindixon> yeah
17:56:36 <colindixon> edwarnicke: though for virtualization it's 3 simple things, right?
17:57:08 <edwarnicke> Probably :)
17:57:23 <colindixon> #info paulz will help us out trying to get the docs together, he did work on the original docs that were released when the consortium went public
17:57:29 <colindixon> edwarnicke: and probably similarly for SP?
17:57:35 <colindixon> base will have one simple thing
17:57:42 <colindixon> and that's documented somewhat I think
17:57:47 <colindixon> but needs to be reviewed
17:57:51 <paulz> Yes, I did work on the original docs
17:58:01 <colindixon> anyway, welcome paulz, we really need the help
17:58:17 <colindixon> feel free to rope people in on IRC and the mailing lists as much as possible
17:58:26 <paulz> This is helpful... I can start with this and if I have more questions, I can bring it up at tomorrow's chat...
17:58:30 <colindixon> (I'm going to move on to dbainbri and docker quickly and then end)
17:58:38 <edwarnicke> paulz: Also... its a wiki, so feel free to edit :)
17:58:39 <colindixon> paulz: don't wait that long if you don't have to
17:58:47 <edwarnicke> colindixon: sounds great :)
17:58:49 <paulz> OK
17:59:00 <colindixon> do first, then think about asking for forgivness later, but better yet, don't :p
17:59:05 <colindixon> #topic docker
17:59:19 <colindixon> dbainbri: so, what's going on with docker at this point?
17:59:29 <dbainbri> basically it is ready to go.
17:59:40 <colindixon> dbainbri: that's an awesome answer
17:59:47 <dbainbri> i have put sample images built from the release distros (ZIP) at https://index.docker.io/u/davidkbainbridge/
18:00:08 <dbainbri> once ODL gets an offical docker.io account i can put them in the official place
18:00:16 <edwarnicke> :)
18:00:21 <colindixon> edwarnicke, cdub: any idea how we can do that?
18:00:44 <edwarnicke> I've already emailed helpdesk ccing dbainbri
18:00:46 <Madhu> hi guys. I just got out of another meeting.
18:00:53 <edwarnicke> And its in tykeal queue
18:01:04 <Madhu> also noticed network static is not on line
18:01:10 <colindixon> #link https://index.docker.io/u/davidkbainbridge/serviceprovider/ dbainbri has created the docker images and put them here, the are ready to go plus or minus anything not included in distribution zips
18:01:11 <dbainbri> i am biased, but i think people can try ODL out much faster using docker than the VM approach. (docker run davidkbainbridge/base:latest) and you are good to go.
18:01:18 <Madhu> is there anything for ovsdb
18:01:18 <tykeal> hai, it's in my queue. I'll get the docker account setup today
18:01:30 <cdub> dbainbri: same binary issues as VM (dove and vtn)
18:01:37 <tykeal> I've been troubleshooting the 502 errors from nexus though so...
18:01:41 <colindixon> #action tykeal will get an opendaylight docker.io account set up and copy the images from dbainbri today
18:01:42 <edwarnicke> Madhu: Do you guys have someone committed to be here for Release Reviews Fri 9am with a completed Release Review doc?
18:01:58 <cdub> dbainbri: have you looked at that, by chance?
18:02:00 <colindixon> tykeal: understood
18:02:05 <dbainbri> basically this is the distro ZIP files (base, SP, virt) in a ubuntu 12.04 docker image
18:02:06 <Madhu> Yes. myself and networkstatic
18:02:21 <edwarnicke> Madhu: Awesome, could you #info it in?
18:02:37 <dbainbri> cdub: same binary issues?
18:02:45 <regXboi> hoho
18:03:05 <cdub> dbainbri: vtn and opendove require compiled code (not just java)
18:03:40 <cdub> dbainbri: so virt edition is incomplete w/out support for those binary bits
18:04:00 <dbainbri> ah, so i would say yes and no. the images should work on all linux distros. and for win7/mac0s you have to vargrant up a VM to use docker ;)
18:04:39 <colindixon> dbainbri: I think that's not quite it
18:04:57 <cdub> right, but the docker image itself needs binary bits
18:05:07 <dbainbri> are they not in the ZIP file?
18:05:13 <colindixon> basically, there are extra rpms (or just compiled code) other than just the edition zip/rpm whatever that need to be included
18:05:13 <regXboi> no
18:05:21 <cdub> no, they need to be compiled for the platform
18:05:22 <colindixon> dbainbri: exactly, they are *not* in the zip
18:05:23 <dbainbri> ah, then yes ;)
18:05:26 <regXboi> colindixon: be honest
18:05:38 <regXboi> there's more there than just compiled code
18:05:48 <dbainbri> easy to change/fix if someone points me to where they are and how to install them.
18:06:37 <regXboi> dbainbri, I'll try and find you and work through this
18:06:41 <colindixon> #info Madhu and networkstatic will attend the release reviews session at 9a PST on friday on behalf of OVSDB
18:06:43 * cdub needs to go, bbl
18:06:44 <regXboi> along with colindixon's help :)
18:07:17 <colindixon> #action dbainbri and regXboi to work on seeing if docker can help us with getting the other binary artifacts into an OpenDOVE VM or two (with colindixon's help)
18:07:18 <edwarnicke> dbainbri: regXboi One way to look at it is this... for opendove, there's the controller node and the agent node... and maybe the agent node is just a VM
18:07:21 <colindixon> ok
18:07:39 <regXboi> actually, I look at it a little differently
18:07:49 <colindixon> I'm going to call this meeting unless somebody needs more meeting topics?
18:07:54 <regXboi> but we are almost there :)
18:07:57 <colindixon> and regXboi and edwarnicke and dbainbri can keep talking
18:07:59 <regXboi> kill it
18:08:06 <colindixon> #endmeeting