15:00:20 <zns> #startmeeting Satori
15:00:21 <openstack> Meeting started Mon Mar 10 15:00:20 2014 UTC and is due to finish in 60 minutes.  The chair is zns. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:24 <openstack> The meeting name has been set to 'satori'
15:01:00 <zns> Hi! Who's here?
15:01:04 <caleb_> o/
15:01:08 <gusmaskowitz> o/
15:01:13 <hhoover> o/
15:01:14 <walker_> o/
15:01:44 <samstav> o/
15:01:45 <jasonpgignac1> o/
15:02:25 <zns> Welcome! I'd like to start with a quick review of action items from last time. caleb_ can you update on yours? I believe you had 4.
15:02:59 <zns> gusmaskowitz, samstav - you action items will be next...
15:03:13 <caleb_> Yes, I had 4 items all related to opinions
15:03:15 <caleb_> #link https://wiki.openstack.org/wiki/Satori/OpinionsProposal
15:03:29 <caleb_> The proposal on the wiki has been updated to address all 4
15:03:40 <zns> caleb_: thank you!
15:03:43 <caleb_> one note:
15:04:06 <caleb_> I had to fake a Heat resource name for Barbican items since Heat doesn't yet support Barbican
15:04:22 <caleb_> OS::Barbican::SSLCertificate
15:04:34 <caleb_> If we're okay with that spec
15:04:41 <caleb_> I'll move to implementation
15:04:49 <zns> Nice!
15:04:57 <caleb_> #link https://blueprints.launchpad.net/satori/+spec/poc-resource-opinions
15:05:30 <caleb_> any objections?
15:05:31 <zns> I haven't reviewed the spec with the updates. I'll take a look shortly. Where do we comment on the spec? On the bp whiteboard?
15:05:40 <caleb_> zns: Yes.
15:05:55 <caleb_> zns: Can you make yourself the reviewer then?
15:06:39 <zns> OK. Done (Approver, I think).
15:06:43 <zns> gusmaskowitz: ?
15:06:46 <gusmaskowitz> hi
15:06:49 <caleb_> Thank you for all of the feedback last week. I think we talked about this design a lot and it ate up our time but I think we are better off because of it.
15:06:56 <gusmaskowitz> I had two actions related to documentation
15:07:07 <gusmaskowitz> a terminology page exists.
15:07:12 <zns> caleb_: agreed. I like the evolution of it.
15:07:25 <gusmaskowitz> and
15:07:38 <gusmaskowitz> I had a failed git review on my doc push to satori readthedocs.
15:07:48 <gusmaskowitz> will be reposted shortly with a better example then done
15:08:09 <gusmaskowitz> for the record is passed Gerrit, but not the Oracle of ZNS :)
15:08:18 <zns> gusmaskowitz: Thanks for getting it up there.
15:08:38 <samstav> gusmaskowitz do you have a link to the terminology page? I wondered if you were referring to the glossary page that I started last week...
15:08:47 <gusmaskowitz> It's the glossary page. renamed.
15:08:50 <gusmaskowitz> link :
15:09:03 <gusmaskowitz> https://wiki.openstack.org/wiki/Satori/glossary
15:09:05 <zns> Hah! I like to think that if something is in gerrit, the action item is accomplished. It's hard to predict what the review process will be like...
15:09:14 <gusmaskowitz> on the front page says terminology. I hate duplication.
15:09:33 <samstav> Ah, excellent.
15:09:52 <gusmaskowitz> one quick question: the PYPI page is the readme from the github repo.
15:10:03 <gusmaskowitz> how do we set it to update? is that something you control zns?
15:10:16 <caleb_> #link https://pypi.python.org/pypi/satori/0.1.3
15:10:33 <gusmaskowitz> that content yes - it comes from the README.
15:10:41 <gusmaskowitz> does it update automagically?
15:10:42 <zns> gusmaskowitz - and all: do we want to get things like the glossary into the docs? We'd need to add the rat to the source and compile it and publish to readthedocs. The wiki feels uncontrolled to me...
15:11:00 <zns> that, not the rat!
15:11:06 <gusmaskowitz> im happy to do what you suggest.
15:11:17 <gusmaskowitz> terminology page in the code --> readthe docs ?
15:11:40 <caleb_> Maybe this could work: anything user related-> readthedocs, anything dev related->wiki ?
15:12:02 <caleb_> feels like we need a guiding principle to agree on.
15:12:21 <zns> How about following nova: http://docs.openstack.org/developer/nova/devref/index.html
15:12:44 <samstav> Would it be reasonable to have links from readthedocs to the openstack wiki or vice versa? Will we keep these sets of documentation totally separate?
15:12:49 <caleb_> I've picked up the feeling from other projects that the wiki may or may not be authoritative. Saw something like that on -dev last week.
15:12:51 <zns> I think specs and fluid docs go in the wiki. But once they're approved and locked in they get source-controlled.
15:13:11 <caleb_> zns: I like that.
15:13:27 <jasonpgignac1> So the wiki ends up being the edge docs, as it were?
15:13:32 <gusmaskowitz> so 'definate' things in the code and ones that are being discussed in the wiki - once 'solid' we code them and add the link.
15:13:44 <caleb_> gusmaskowitz: +1
15:13:49 <gusmaskowitz> OK.
15:13:50 <zns> jasonpgignac1: yes
15:14:01 <gusmaskowitz> terminology is solid. = code. I'll ad. sorry. Am n00b
15:14:14 <caleb_> I feel like zns should break out #agreed
15:14:17 <zns> Sounds like consensus. Any objections?
15:14:25 <jasonpgignac1> I'm good.
15:14:47 <caleb_> gusmaskowitz: nothing to apologize for. We didn't have a rule, now we do. Progress.
15:14:54 <zns> #agreed Final docs (including developer docs) go in the code. The wiki is for works in progress and specs.
15:15:12 <zns> samstav: update?
15:15:51 <samstav> First, ssh-module, then I'll go over ohai-solo. The latter will depend on the ssh module
15:16:01 <zns> You had an action item: catch exceptions in CLI so we don't stack trace
15:16:02 <samstav> ssh-module blueprint
15:16:38 <samstav> Yeah I did. But after some thought I felt it wasn't a high priority. No update re: exceptions in CLI
15:17:28 <zns> samstav: OK. Do you want to move it to next week or drop it from your list?
15:17:37 <samstav> Drop it.
15:17:54 <zns> OK. I think we still need to get it done. I can take it.
15:18:20 <zns> #action zns catch exceptions in CLI so we don't stack trace (consider --debug mode allowing exceptions through to allow for debugging) + blueprint
15:18:27 <zns> My update...
15:19:25 <zns> samstav actually started working on the ssh module (we pairs on the design). That's a prerequisite for the individual modules. So I'll carry the action item forward as it is not complete.
15:19:42 <zns> #action zns implement plugins own establishing the connection to start with, but we provide a built-in ssh module that they can use
15:21:12 <zns> Any comments on Templated Output? https://review.openstack.org/#/c/79098/
15:21:30 <zns> FYI - I can't seem to set the topic...
15:21:42 <zns> #topic Templated Output
15:21:50 <zns> There it is...
15:22:17 <caleb_> I haven't reviewed the code yet but the spec is rock solid, IMO.
15:22:22 <walker_> Agreed
15:22:24 <jasonpgignac1> I think its a good first step, yes.
15:22:30 <walker_> Templating is the way to go
15:23:07 <caleb_> can we get some folks assigned to following up on the review?
15:23:19 <gusmaskowitz> please forgive me but I need to go. Have a great one.
15:23:22 <zns> Volunteers?
15:23:32 <zns> Bye gusmaskowitz - thanks for joining.
15:23:44 <jasonpgignac1> I can review. I need to get in so I can doc the submission process et al, anyway.
15:23:52 <walker_> I can review
15:24:10 <zns> OK. I like having more than one reviewer.
15:24:29 <zns> #action walker_ jasonpgignac1 to review Templated Output
15:24:42 <zns> Everything is awesome (Lego movie song). Next topic
15:24:54 <zns> #topic SSH Modue (blueprint + spec)
15:25:25 <zns> Any comments on it? samstav - did you have something you wanted to add/comment on it?
15:25:33 <samstav> no
15:26:01 <zns> I think the spec is solid (not just because I helped write it)...
15:26:04 <zns> #link https://wiki.openstack.org/wiki/Satori/SSHModuleProposal
15:26:55 <zns> If ya'll could take a look at the spec because it starts to expose a python API for satori.
15:27:05 <jasonpgignac1> Looking...
15:27:06 <zns> from satori import ssh
15:27:13 <zns> and such...
15:27:41 <jasonpgignac1> In the long term, do we need to add an optino to open a persistent session to send multiple commands?
15:27:55 <samstav> zns and I were debating about whether to have too many instance attributes to cover the host credentials AND the proxy credentials
15:28:08 <jasonpgignac1> Perhaps also, if possible to do other ssh functions like scp?
15:28:25 <samstav> or to allow two dictionaries to be passed to the object when initializing
15:28:34 <jasonpgignac1> Two dicts.
15:28:47 <jasonpgignac1> That way it is clearer hwat is fro the proxy
15:28:57 <zns> jasonpgignac1: I think so, but we didn't have the need yet. We have actual use cases for what's implemented already (i.e. types of creeds and proxy)
15:29:04 <jasonpgignac1> OK.
15:29:44 <zns> OK. Next topic...
15:29:50 <zns> #topic ohai-solo blueprint
15:30:07 <zns> #link https://wiki.openstack.org/wiki/Satori/OhaiSolo
15:31:04 <samstav> I think this one might need some thought work for implementation
15:31:28 <zns> It does depend on the ssh module being implemented.
15:31:35 <samstav> Should a sys info provider module/plugin only expose one method?
15:32:10 <jasonpgignac1> Would this spec need to include the ability to install custom ohai modules? Or are we assuming that because its integrated with ohai solo?
15:32:12 <zns> Do we need more than one method? What's the story for that.
15:32:41 <samstav> According to this WIP
15:32:44 <samstav> #link https://wiki.openstack.org/wiki/Satori/SystemInfoProposal
15:33:19 <caleb_> walker_ and I discussed that
15:33:46 <caleb_> we landed on doing a very loose implementation where the sysinfo module is called and can do whatever it wants
15:33:53 <samstav> There is one method explicitly described. With the choice to build-in ohai-solo support, it's going to be important to do version management (which will be system dependent) on the remotes
15:33:56 <caleb_> including making SSH connections, installing software, etc.
15:34:04 <zns> jasonpgignac1: we have the blueprint for selecting one of many sysinfo plugins. Are you talking about how to configure one of them (ex. ohai-solo) to select different plugins?
15:34:15 <caleb_> and if we find a common pattern we can create a spec out of that
15:34:16 <samstav> caleb_ ack
15:34:30 <caleb_> but until we have the first implementation, lets not create a bunch of rules.
15:34:51 <jasonpgignac1> zns: It would seem to me that the addition of sysinfo plugins woudl be specific to the method of looking up sysinfo, yes?
15:35:07 <zns> +1 - We wait on the interface until we have an implementation to look at.
15:35:15 <jasonpgignac1> zns: So we'd need a spec on adding sysinfo to Ohai-Solo, one for Ansible, etc, etc, etc.
15:35:28 <jasonpgignac1> Or do I misunderstand? I woudl not be surprised if I do.
15:36:08 <zns> jasonpgignac1: sorry, I don't think I understand...
15:36:10 <samstav> jasonpgignac1 I see what you're getting at. I have questions about that. Are you anticipating a fundamentally different set of methods exposed depending on what kind of sys info provider we have?
15:36:30 <samstav> whether its a package, or a script, or an ansible playbook?
15:36:52 <jasonpgignac1> samstav: Yes, that's what I mean. Somewhere there must be a spec on...
15:36:54 <zns> jasonpgignac1: are you talking about how one implements a new plugin?
15:37:14 <walker_> I feel that the plugins should be independent. They can do whatever they want as long as they return data in a format we expect
15:37:24 <zns> +1 walker_
15:37:30 <walker_> therefore, it shouldn't matter how they are written
15:37:35 <walker_> and keeps the system agnostic
15:37:50 <zns> And I think what follows is that the interface is really simple... especially to get started...
15:37:51 <caleb_> walker_: +1
15:37:51 <jasonpgignac1> walker: I amfine with that, except that if we are using three different plugins that use three different providers, that seems problematic?
15:37:53 <walker_> We can provide modules for plugins to use (like ssh, etc.)
15:38:02 <walker_> why is that problematic
15:38:07 <jasonpgignac1> I may be misunderstanding, thoguh, and will be glad to be educated offline.
15:38:09 <zns> jasonpgignac1: what are providers?
15:38:20 <samstav> thanks everyone. that helps. I think I've got enough to produce an implementation
15:38:22 <caleb_> jasonpgignac1: I propose that we think about writing rules and structure when we have three different modules.
15:38:51 <jasonpgignac1> caleb_: OK. I'm fine with that.
15:39:40 <zns> jasonpgignac1: OK with deferring this conversation then?
15:39:57 <samstav> zns I have unofficially been referring to our sys info plugins as sys info providers. that terminology could be debated
15:40:41 <samstav> https://wiki.openstack.org/wiki/Satori/glossary#SysInfo_Provider
15:40:42 <zns> samstav: thanks.
15:40:52 <jasonpgignac1> zns: Yes, I'm good.
15:40:58 <zns> jasonpgignac1: cool
15:41:08 <zns> Any pending comments/questions about ohai-solo?
15:41:18 <samstav> one comment
15:42:10 <samstav> just want to (again) say +1 to walker_ for the work on ohai-solo, and that all the support docs for our use in Satori I have linked to those repositories READMEs
15:42:28 <zns> +1 walker_ rocks
15:42:32 <walker_> :) thanks for the feels samstav
15:43:10 <samstav> 👏
15:43:33 <zns> We have about 15 minutes left. I'd like to propose a topic: terminology for "providers"...
15:43:45 <caleb_> lets do it
15:43:46 <zns> Any other topics to add?
15:43:50 <zns> OK.
15:43:59 <zns> #topic terminology for providers
15:44:18 <zns> To start, we have documented the Data Plane and Control Plane concepts.
15:44:43 <zns> We're going to have "things" that do Control Plane discovery - the nova code we have today is one.
15:45:09 <zns> The sys info plugins are "things" that do Data Plane discovery.
15:45:47 <zns> In the end, all those "things" are similar. jasonpgignac1 and samstav have called them providers. Any thoughts on that name or alternatives?
15:46:17 <jasonpgignac1> Are providers the individual plugins? I thoguht they were the shared frameworks by which data coudl be gathered.
15:46:20 <zns> I personally like "sensors". Mainly because it is unique within OpenStack...
15:46:22 <samstav> at first I just needed something to call them. So I started saying sys info providers. but the term "provider" is kinda already taken in the cloud world
15:46:30 <jasonpgignac1> So, like, 'Ohai' would be a provider.
15:46:52 <jasonpgignac1> But then we'd have a plugin that woudl use ohai to gather data about, say, php?
15:46:58 <walker_> zns: I can be onboard with sensors
15:47:00 <jasonpgignac1> But this may be my ignorance speaking again.
15:47:00 <samstav> so if we were to use provider we would need to explicitly say sys info provider or _____ provider
15:47:53 <samstav> I like sensor because of the word sensor. but I think it underestimates what these "things" do
15:48:17 <samstav> or underdefines
15:48:46 <zns> One place where I see this being exposed to the world is in our landing/hoe page for users. I think we should start listing the list "things" we discover. Somewhere there we would probably have a list of "sensors" and what their capabilities are.
15:48:55 <zns> "Gatherers" is another. Collectors also.
15:49:02 <samstav> Assessor ?
15:49:10 <zns> Tax Ausitor!
15:49:14 <samstav> yissss
15:49:16 <zns> Auditor...
15:49:28 <jasonpgignac1> analysts
15:49:35 <samstav> sleuth
15:49:37 <jasonpgignac1> Or inquisitors
15:49:58 <jasonpgignac1> I like Inquisitors. But, then, I have bad taste.
15:50:05 <zns> I propose we find a name associated with socially likable terms...
15:50:14 <samstav> agreed
15:50:21 <caleb_> TSA agents?
15:50:26 <samstav> and < 4 syllables unless two words
15:50:31 <jasonpgignac1> Oh, thinks are gettin' dangerous in here.
15:50:37 <zns> feelers
15:50:43 <samstav> +1 feelers
15:50:52 <samstav> no, seriously.
15:51:01 <caleb_> I don't have much to add in the way of naming. I'm good with whatever you folks settle on.
15:51:23 <samstav> so…. SysInfo Providers ?
15:51:37 <zns> boooooring..
15:51:51 <walker_> jasonpgignac1 will have a good name for them in about an hour
15:52:17 <walker_> I like collector, for what it is worth
15:52:59 <zns> I'll start a wiki page for suggestions and let's stew on it. We might have to live with the name for a long while...
15:53:09 <samstav> sounds good
15:53:19 <zns> #action zns Create wiki page for naming suggestions.
15:53:28 <jasonpgignac1> probes
15:53:32 <zns> Any other topics, parting thoughts?
15:53:33 <jasonpgignac1> Oh, too late
15:53:46 <zns> +/- 1 for probes...
15:53:58 <caleb_> zns: I think the implementations that we're doing now will get us close to a userlist announcement
15:54:03 <caleb_> and I'm excited about that
15:54:51 <samstav> ASCII multi-tier topologies before any announcements!
15:55:13 <zns> caleb_: agreed. Once these land the value we provide starts to show.
15:55:14 <samstav> jk.
15:55:14 <caleb_> samstav: :)
15:55:43 <zns> OK. Thank you all!
15:55:48 <zns> #endmeeting