15:06:06 <alagalah> #startmeeting Clustering-Hackers
15:06:06 <odl_meetbot> Meeting started Mon Oct  6 15:06:06 2014 UTC.  The chair is alagalah. Information about MeetBot at http://ci.openstack.org/meetbot.html.
15:06:06 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:06:06 <odl_meetbot> The meeting name has been set to 'clustering_hackers'
15:06:19 <alagalah> #topic Uyen (HP) mentioned there are usability issues
15:06:34 <alagalah> #info Jan mentions we should continue this topic over next few weeks on Monday call
15:08:16 <alagalah> #info ghall mentions it maybe worth clearing a schedule for a couple of hours, and put themselves in the mindset of doing something simple.
15:09:32 <alagalah> #chair jmedved
15:09:32 <odl_meetbot> Current chairs: alagalah jmedved
15:09:58 <colindixon> hey all
15:10:01 <alagalah> Hey yall
15:10:19 <alagalah> #chair colindixon
15:10:19 <odl_meetbot> Current chairs: alagalah colindixon jmedved
15:10:27 <alagalah> colindixon: It just seems appropriate :-P
15:10:32 <colindixon> #topic hard topics
15:10:38 <alagalah> rovarga: Hi there, mate...
15:11:13 <colindixon> #info parent pom, e.g., parent pom structure is confusing, complicated, and has lots of duplicate things
15:11:29 <jmedved> #info topics to discuss: pom.xml and how to use them
15:11:30 <alagalah> #info ghall suggests we start with the POM structure inc. but not limited to, parent pom etc, with the end goal of making it clear what goes into a project's pom
15:11:46 <alagalah> #undo
15:11:46 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2833f90>
15:11:56 <alagalah> colindixon seems to have covered it
15:12:01 <jmedved> #info mlemay suggest that we look into the config subsystem and how its use can be abstracted
15:12:22 <colindixon> #info mlemay says that the XML part may be at least some of it, but not all of it
15:12:32 <jmedved> #info uyen says it’s the lack of transparency and how config subsystem hooks into OSGI; is there a chance to move to blueprint?
15:13:28 <colindixon> #info devinaverys says also, whatever we can do to make the tooling better, e.g., java binding 2.0 is a very good topic
15:13:49 <jmedved> #info devin says that we should tackle anything that concerns tooling (java bindings v2), design it in a way where it’s more consumable than what we have today
15:14:38 <jmedved> #info yuen want the generated apis more consumable - should we use annotations to make generated APIs more consumer friendly and/or easier to debug
15:15:26 <jmedved> #info colindixon says progress already made, existing generated APIs have javadoc, so we have to make use of some things already there
15:15:49 <jmedved> #info colindixon says we should just do the pom xml, and do it once
15:16:45 <jmedved> #indo devinavery already made a pass through pom.xml. use default configs where most of the developer population do not care how things are wired
15:16:50 <alagalah> devinavery: Want to work together on a walk thru we can document?
15:16:59 <alagalah> devinavery: ala your LISP session ?
15:17:13 <colindixon> alagalah: yeah
15:18:01 <colindixon> #info ghall says blueprint was mentioned, is that actually on the table?
15:18:05 <jmedved> #info colindixon, mlemay:  blueprints not really the solution, do not provide deterministic load order
15:18:09 <devinavery> @link https://git.opendaylight.org/gerrit/#/c/11704/ lispflowmapping pom restructure
15:18:19 <devinavery> #link https://git.opendaylight.org/gerrit/#/c/11704/ lispflowmapping pom restructure
15:18:28 <jmedved> #info: mlemay says that we need to make the configs work together better
15:18:30 <colindixon> #Info colindixon says that edwarnicke would say no because blueprint doesn’t get determnistic load order
15:18:42 <devinavery> alagalah: happy to have you look over changes in above gerrit and happy to discuss
15:18:43 <alagalah> devinavery: Was thinking more of a recording/tutorial based on that
15:19:20 <alagalah> devinavery: Was the LISP session at the summit recorded on the iPad ?
15:19:58 <devinavery> Ahh. Sure we can discuss that. I am not sure we have nailed it all down just yet. But we could start a tutorial on the pom.xml
15:20:31 <devinavery> No, it wasn't recorded. It was more of a hackfest then a presentation
15:21:08 <colindixon> #topic config subsystem
15:21:27 <jmedved> #info colindixon asks whether the config susbsystem is it?
15:21:54 <colindixon> #Info jmedved says that given the requirements, it’s the only thing that solves them that we’re aware of
15:21:58 <jmedved> #info devinavery; wants to know in writing what are the problems that the config susbsystem is desgined to solve?
15:22:23 <jmedved> #info uyen wants to know how does the config susbsystem help
15:22:28 <colindixon> #undo
15:22:28 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2497910>
15:22:29 <alagalah> #link Info on subsystem: https://wiki.opendaylight.org/view/OpenDaylight_Toolkit:MD-SAL-Simple_Archetype
15:22:43 <colindixon> #info uyen asks how much of the benefits do we get if not *everyone* uses the config subsystem
15:22:50 <jmedved> #info devinavery - wants to know why we should move to a single config system
15:22:58 <alagalah> #link More: https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Toaster_Tutorial#Config-subsystem_Context
15:23:10 <jmedved> #info rovarga: config subsystem solves 3 areas of problems:
15:23:10 <colindixon> #topic requirements/problems
15:24:17 <colindixon> #info first problem is service injection in a determnistic order, but also in a dynamic way, i.e., can be changed at runtime
15:24:19 <jmedved> 1. service injection in predictable order, such that service inhection is reconfigurable at runtime. designed for interactions outside of the container. it is really an agent. the reference implementation is using netconf to isolate components inside of the container from the outside
15:24:27 <colindixon> ^^^^^^^^^ is that one or two?
15:25:12 <jmedved> #info configuration can be used by jmx, but it needs it own serialization format and does not use the domain specific language
15:27:18 <colindixon> #info provides information about the configuration and runtime statistics about the controller that is, in some ways better than JMX
15:27:46 <colindixon> #info rovarga also notes that everything from the config subystem also integrates via JMX
15:29:10 <colindixon> #info the third part is making sense about namespaces and lifecycle managment between the two above things (that is serice injection and monitoring/config)
15:29:56 <colindixon> #info to summarize: (1) service injection, (2) runtime config/stats, (3) namespace/lifecycle managment for (1) and (2)
15:30:32 <colindixon> #info jmedved says that as part of (2) you get two phase, atomic comits on configuration of the system
15:31:38 <colindixon> #undo
15:31:38 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2580990>
15:31:40 <colindixon> #undo
15:31:40 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x24a9150>
15:32:20 <colindixon> #info to summarize: (1) service injection w/deterministic load order and runtime modification (2) runtime config/stats including atomic two phase commit config changes, (3) namespace/lifecycle managment for (1) and (2)
15:34:48 <colindixon> #info moiz asks if the runtime reloading modules things is somthing that people actually want to use
15:35:30 <colindixon> #Info tony (I think) answers that yes, we do this in our current system with netconf and the config subsystem do this
15:35:43 <colindixon> #Info moiz says that’s really more reconfig, not reloading
15:37:36 <colindixon> #info mlemay says he’s torn because he tends to reload things by bringing up a new clustered node with the right config without having to modifiy config (colindixon says that this is his experience as well)
15:37:58 <alagalah> Do we have any information from potential users on the proposed use-case?
15:38:39 <colindixon> alagalah: +1
15:38:40 <colindixon> not publicly
15:39:27 <alagalah> In the absence of hard data from end-users, devinavery's suggestion makes sense.. .lets progress until we reach a point where we have to break the status quo, then assess.
15:39:47 <colindixon> #info alagalah asks if we have actual customer wants requirements, in the absence of that it’s just us yelling at each other about our hunches
15:39:51 <colindixon> alagalah: is that right? :p
15:40:05 <colindixon> #undo
15:40:05 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2498750>
15:40:09 <colindixon> it’s not quite right
15:40:09 <alagalah> colindixon: ummm I thought I was a little more diplomatic but sure :)
15:40:21 <alagalah> The status quo bit from devinavery needs to be captured
15:41:04 <moizer> I was thinking maybe if we could dismiss some of the features as unneccessary we could switch to something which was more useable
15:41:18 <colindixon> #alagalah asks if we have actual customer wants requirements, in the absence of that we should keep going with the status quo and improving it and reassess only when it stops us from being able do things (or do thing easily)
15:41:26 <alagalah> colindixon: perfect
15:41:39 <jmedved> Moizer: what are your main usability beefs with the system as it is?
15:41:43 <alagalah> #info alagalah asks if we have actual customer wants requirements, in the absence of that we should keep going with the status quo and improving it and reassess only when it stops us from being able do things (or do thing easily)
15:41:55 <colindixon> alagalah: thanks
15:41:59 <alagalah> #info Notes: status quo portion attributed to devinavery
15:42:20 <colindixon> #info moizer asks if there are pieces of functionality we could drop to make things easier
15:42:28 <moizer> jmedved - don't want to start with yang
15:42:39 <jmedved> #info rovarga: we have a full feature set, let’s gather requirements to make things simpler
15:42:48 <moizer> and don't really see the benefit of run time reloading
15:43:14 <jmedved> #info colindixon says config subsystem issuse is less the substance rather than lack of documentation
15:43:30 <rovarga> #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Main
15:43:35 <mmarsale> this is main wiki page for config subsystem: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Main
15:43:56 <jmedved> #colindixon: working through a lot of documentation - but still need steps by step instructions
15:43:57 <alagalah> #link https://wiki.opendaylight.org/view/OpenDaylight_Toolkit:MD-SAL-Simple_Archetype
15:44:17 <jmedved> #info colindixon: working through a lot of documentation - but still need steps by step instructions
15:44:22 <raghu67> #link my proposal from earlier (Needs more work for completion) https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:JavaShim
15:44:59 <jmedved> #info rovarga: documentation exists but needs to be imrpoved; how to configure things, how to enable apps info is there
15:45:59 <jmedved> #info colindixon; does not see a step by step cookbook (detailed steps what to do at each step)
15:46:11 <alagalah> ^^^^^ +1
15:46:23 <moizer> jmedved - I want to be able to add a configuration to a config file and have an API to be able to read it
15:46:34 <rovarga> colindixon: #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Sample_Project
15:46:35 <jmedved> #info first tutorial gor java introduces basic concepts and how they work (string, integres, etc.)
15:47:52 <colindixon> colindixon notes that he’d love to be wrong about this, and this page looks like an excellent start at that
15:48:15 <alagalah> #info suggests a FIRST STEP may not be to re-write the wiki pages but make a decent way to navigate to these information
15:48:57 <alagalah> #undo
15:48:57 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x283e0d0>
15:49:04 <alagalah> #info devinavery suggests a FIRST STEP may not be to re-write the wiki pages but make a decent way to navigate to these information
15:49:25 <alagalah> Can we get a pound-action to do ^^^^^
15:49:35 <alagalah> (10min to go ,.... be nice to get an action)
15:50:24 <colindixon> #action colindixon to help try and convert this page into a step-by-step gude: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Sample_Project
15:50:42 <moizer> #action Everyone learn config subsystem :)
15:50:51 <colindixon> :-p
15:51:26 <mlemay_> @all.. Need to drop… sorry but if you need hands on help this week on some of this.. get in touch! :)  (I also would be able to help out on the config subsystem ) (especially trying to properly relate)
15:51:34 <alagalah> later mlemay_
15:51:42 <mlemay_> thx :)
15:51:55 <alagalah> colindixon: Yeppas
15:52:30 <alagalah> colindixon: I'd also suggest that a hierarchical structure == FAIL and meta-tagging is infinitely more useable for wiki pages
15:52:34 <raghu67> #info   FYI, In the ODL in 5 minutes series Ed has started first few episodes are related to config subsystem http://www.opendaylight.org/blogs/2014/07/opendaylight-5-minutes-or-less-video-series
15:53:09 <colindixon> +1
15:53:39 <alagalah> moizer: Count me as a volunteer
15:54:22 <alagalah> #action alagalah to be guinea pig to go through documentation linked in this meetbot to see if its useful for a noob to learn config subsystem... target: 10/13
15:55:14 <mmarsale> configuration netconf connector via Restconf: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Spawning_additional_netconf_connector_while_controller_is_running
15:55:20 <colindixon> #action rovarga to provide examples of how to to live reconfiguration to devinavery (and probably the controller-dev list)
15:55:34 <colindixon> #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Spawning_additional_netconf_connector_while_controller_is_running this maybe the result of that action item
15:57:37 <colindixon> #topic wrap up
15:58:06 <colindixon> #info devinavery notes that it sounds like we want to go understand things and refactor the wiki docs this week
15:58:44 <colindixon> #info devinavery asks if we could do that sooner in the week, that would be good since then we could iterate before next week
15:58:53 <alagalah> #info alagalah notes that in his opinion, its not that the issue is that we need new features, its just that the config subsystem is hard to consume without documentation/tutorials, so that they can get enough proficiency in it to identify what features are missing
15:59:18 <alagalah> colindixon: I will make time for this earlier in the week... but more than likely have something Thu
15:59:31 <colindixon> alagalah: that would be awesome
15:59:35 <colindixon> because i’m not sure
16:00:19 <alagalah> colindixon: To be clear, I am going to propose a project FOO, and I will try to create it locally using the docs and make notes about what worked, didn't work, what broke etc
16:00:33 <raghu67> I will work with moiz in updating the Java Shim proposal and send it out (I understand that is not the initial focus for the team)
16:02:40 <moizer> the docs need to be split into - user vs design
16:04:31 <alagalah> #endmeeting