18:05:16 <SergeyLukjanov> #startmeeting savanna
18:05:17 <openstack> Meeting started Thu May 16 18:05:16 2013 UTC.  The chair is SergeyLukjanov. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:05:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:05:21 <openstack> The meeting name has been set to 'savanna'
18:06:23 <ErikB> seems mail is taking a while. Here are the 2 docs just posed to the wiki: https://wiki.openstack.org/w/images/0/00/Hadoop_Configuration_Flow_For_Mockup.pdf and https://wiki.openstack.org/w/images/9/99/Hadoop_cluster_configuration_mockup.pdf
18:07:03 <SergeyLukjanov> I think we have no agenda for the todays meeting
18:07:24 <ErikB> Can we discuss the two docs just posted - concerning advanced confif?
18:07:43 <ErikB> s/fif/fig
18:08:32 <SergeyLukjanov> we have a lot of discussions of plugin mechanism and Savanna's overall arch last week
18:08:34 <SergeyLukjanov> ErikB, yes, sure
18:08:58 <SergeyLukjanov> give us a moment to take a look on them
18:12:06 <SergeyLukjanov> for newcomers - here are the channel logs - http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-alt/%23openstack-meeting-alt.2013-05-16.log
18:12:21 <dmitryme> Erik, in your UI mocks. Does the Node Group section appears after user selects the file?
18:12:49 <jspeidel> the advanced file is optional
18:13:17 <jspeidel> either way it is populated from result of plugin.populate_node_groups
18:13:27 <jspeidel> could be using default configuration
18:14:22 <ruhe> it looks the same as what Dmitry sent about three hours ago? just with different layout :)
18:14:34 <jmaron> kind of..yes ;)
18:14:58 <ruhe> cool
18:15:05 <ErikB> it was put together independently of what Dmitry did - so that is good that we are thinking the same
18:15:15 <ruhe> right
18:16:13 <rnirmal> sorry guys got in a little late and may have to leave early as well
18:17:03 <jspeidel> keep in mind that we were not trying to design the UI, just provided the mockup for reasons of discussion
18:17:14 <jmaron> in both cases, the selection of the template (standard or advanced) yields a view of the node groups
18:17:19 <jspeidel> to better explain the flow
18:17:35 <ruhe> in the Object model changes. there is new field "vm_requirements". is it intended to help user to select appropriate flavor?
18:17:45 <jspeidel> yes
18:17:46 <SergeyLukjanov> am I right that "vm_requirements" is the minimal requirements for vms in node group?
18:17:51 <jspeidel> yes
18:17:58 <rnirmal> we may be better of not looking at the UI first  ;)
18:18:37 <jspeidel> the associated flow doc describes how the ui uses vm_requirements
18:18:49 <jmaron> node count, cardinality, memory etc
18:18:51 <jspeidel> it will allow the UI to do some validation
18:19:03 <rnirmal> +1 for the vm requirements part... makes for good validation
18:19:04 <jspeidel> and only populate legal value
18:19:06 <jspeidel> valus
18:19:18 <SergeyLukjanov> jspiedel, yep, I see it
18:19:58 <rnirmal> so let me bring up my concern from earlier about the plugin choosing a vm to use for a role
18:20:34 <SergeyLukjanov> our main point is to use one cluster object in all plugin api calls
18:20:37 <jmaron> in the current proposed scheme, the plugin simply provides guidance via the requirements.  it's not choosing
18:21:04 <jspeidel> SergeyLukjanov, agreed
18:21:09 <jmaron> yes. we are following the same approach for advanced config
18:21:14 <ErikB> The controller chooses placement of VM
18:21:48 <rnirmal> ok that's good
18:22:16 <rnirmal> also in the future it would be good to have discussions around how the interactions happen via the api rather than the UI
18:22:40 <jspeidel> rnirmal, you main the REST API?
18:22:40 <rnirmal> make the API simple enough and the UI will naturally flow in
18:22:48 <SergeyLukjanov> "vm_requirements" looks good, I think that we should include such ability to specify minimal requirements for node groups
18:22:53 <rnirmal> jspeidel: yes
18:23:09 <jspeidel> yes, will need to discuss ramifications to REST API
18:23:19 <jspeidel> but lets settle on SPI first
18:23:25 <rnirmal> sure
18:23:26 <jspeidel> between controller and plugin
18:23:34 <jmaron> +1
18:24:12 <SergeyLukjanov> yes, we should discuss the SPI first
18:24:17 <jspeidel> for the vm_requirements, we would need to have a defined set of properties that could be included
18:24:35 <jspeidel> that both the plugin and controller would understand
18:24:58 <jspeidel> for the UI to actually do any validation
18:24:59 <jmaron> a minimal set of expected values.  there could always be more for specific functions
18:25:12 <jspeidel> otherwise it is still useful, but more of guidance to the user
18:25:17 <SergeyLukjanov> jspeidel, all supported properties of flavor object plus cardinality
18:25:47 <jspeidel> + default_count
18:25:59 <rnirmal> what you'll have there looks good, just addition of vcpus would finish it up
18:26:12 <jspeidel> good
18:26:24 <rnirmal> not sure about the default_count
18:26:46 <jspeidel> it would allow users to "clone" an existing cluster
18:26:56 <rnirmal> so if the user doesn't specify a count for that node-group is the default_count used
18:27:03 <jspeidel> is just used to pre-populate vm count
18:27:07 <jmaron> exactly
18:27:08 <jspeidel> can still be changed by user
18:27:12 <ErikB> default_count is just what is recommended and can be changed by the user in the UI (it would be the default rendered in the UI)
18:27:15 <jspeidel> it is just the initial value
18:27:28 <dmitryme> mmm, why can't we just use existing 'count' field for that?
18:27:39 <rnirmal> but what about from the API
18:27:46 <jspeidel> let us look ...
18:27:47 <rnirmal> you don't get that sort of an interaction from the rest api
18:27:57 <rnirmal> I'd suggest not have the default_count for now
18:28:01 <SergeyLukjanov> I think "default_count" is the very simple thing, lets discuss more important things for now
18:28:18 <jspeidel> SergeyLukjanov, agreed
18:28:24 <jmaron> and yes "count" may server the purpose
18:28:29 <jmaron> serve
18:28:41 <jspeidel> we can discuss later after spi is nailed down
18:29:44 <SergeyLukjanov> are there any concerns in SPI?
18:29:54 <SergeyLukjanov> any other*
18:30:06 <jspeidel> are you ok with the flow that we just posted with the mockup?
18:30:12 <rnirmal> is anyone else working on a plugin other than ambari
18:30:19 <jmaron> and the modified APIs?
18:30:59 <jmaron> I had a thread on the list about the user_input object, but it a given input can reference it's source config object that should be more than sufficient
18:31:11 <jmaron> its
18:31:12 <SergeyLukjanov> jspeidel we published our new vision several ours ago and I think that we have the very similar vision
18:31:16 <ErikB> rnirmal, not as far I know