15:00:04 <zns> #startmeeting satori
15:00:05 <openstack> Meeting started Mon Feb 24 15:00:04 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:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:08 <openstack> The meeting name has been set to 'satori'
15:00:16 <zns> Welcome to the first Satori Team Meeting.
15:00:26 <zns> My email to the dev list announcing this meeting bounced back, so I think turnout might be limited to us already working on the project.
15:00:34 <zns> #topic rollcall
15:00:42 <zns> Who is here?
15:00:49 <caleb_> o/
15:01:11 <gondoi> o/
15:01:13 <jasonpgignac> o/
15:01:33 <gusmaskowitz> o/
15:01:54 <zns> Cool. Welcome. The agenda is on the wiki page. Reminder that anyone can add items to it.
15:01:59 <zns> #topic Project kick-off
15:02:19 <zns> For the record, and to report progress, We’ve started working on a proof-of-concept. We’ve implemented three blueprints:
15:02:29 <zns> Command-line parsing
15:02:29 <zns> #link: https://blueprints.launchpad.net/satori/+spec/poc-commandline-parsing
15:02:29 <zns> DNS detection, which finds which nova server the URL you are discovering is hosted on a nova server
15:02:29 <zns> #link https://blueprints.launchpad.net/satori/+spec/poc-dns-detection
15:02:29 <zns> Nova instance detectin
15:02:29 <zns> #link https://blueprints.launchpad.net/satori/+spec/nova-instance-detection
15:03:02 <zns> We also have some blueprints approved and pending.
15:03:24 <caleb_> I'm still working on getting https://blueprints.launchpad.net/satori/+spec/poc-resource-opinions outlined.
15:03:37 <zns> We also pushed v0.1.3 to pypi, so you can  pip install satori and try it out already.
15:03:56 <caleb_> If people would like to help with the wiki doc I'd appreciate it
15:04:01 <caleb_> #link https://wiki.openstack.org/wiki/Satori/OpinionsProposal
15:04:35 <zns> I had a question about that. Should we include a base set of opinions in satori?
15:05:09 <gondoi> seems reasonable to me
15:05:22 <samstav> gondoi: seconded
15:05:23 <jasonpgignac> We'd just need to make sure they are sufficiently 'generic'
15:05:29 <jasonpgignac> Or, marked as examples.
15:05:30 <caleb_> zns: I think so. So long as they're only loaded when asked.
15:05:31 <gondoi> there should be some amount of data that is generic enough that we can keep opionions in the base code
15:05:33 <zns> Agreed.
15:05:35 <caleb_> jasonpgignac: agreed
15:05:51 <zns> #agreed  include a base set of generic opinions in satori
15:06:02 <caleb_> I'll add that to the spec
15:06:07 <zns> thanks
15:06:09 <zns> #topic Pushed 0.1.3
15:06:15 <caleb_> can you #action that?
15:06:21 <zns> Skipping through this topic, unless anyone has questions?
15:06:27 <caleb_> not sure if a non-chair can do that.
15:07:04 <zns> #action cgroom  include a base set of generic opinions to spec
15:07:44 <caleb_> zns: What's the cadence that we'll use to push to pypi?
15:07:45 <zns> I've also put in a request to add satori to stack forge. #link https://review.openstack.org/#/c/73667/
15:08:07 <caleb_> every merge? date interval? "big" blueprint implementations?
15:08:37 <zns> caleb_: Once we get on an openstack cadence, we'll probably follow that. For now, I'm thinking whenever there is a new feature (i.e. value) we can push a version out. Any thoughts or opinions about that?
15:09:15 <jasonpgignac> Is QC around said version pushes included in the Openstack standards already?
15:09:21 <jasonpgignac> Or is that somethign we'd have to discuss?
15:09:50 <caleb_> re: stackforge. We may have somebody on the infra team that we can poke to speed that along.
15:10:07 <zns> jasonpgignac: good question. We should be following all testing and QE processes from openstack. We'll need to get on stack forge to leverage the automation around it.
15:10:34 <zns> I don't know what our test coverage is now, but I'd like t o quickly get to 100% once we have a PoC out.
15:10:58 <jasonpgignac> *nods* That would be my main standard for 'push to PyPy' - the last thing we'd want to do is push untested code.
15:11:35 <zns> The review and jenkins process will enforce that. We should probably automate the push to pypi too.
15:11:38 <gondoi> #agreed
15:11:40 <caleb_> zns: Once we're in stackforge, will we follow the OpenStack "review" process or use the github workflow?
15:12:27 <zns> caleb_: Do we have a choice about that? If we want to be a "related" project?
15:13:05 <__walker> I personally prefer github workflow, but can adapt as necessary
15:13:06 <zns> I personally don't love the gerrit UI, but I do appreciate the value of the review and gating process.
15:13:09 <caleb_> zns: Related is a designation that you give yourself. It doesn't require any approval or standards of execution.
15:13:12 <caleb_> #link https://wiki.openstack.org/wiki/ProjectTypes
15:13:38 <gondoi> i like the gerritt workflow as well, with the +1 system and gating
15:13:49 <caleb_> being anything beyond related needs to be using Gerritt and other best practices.
15:13:55 <zns> OK... so once we're in stack forge, we can still follow a github process? What's the point of bing in stack forge then?
15:14:12 <caleb_> It also helps to get other openstack contributors if we're already using the process that they're familiar with.
15:14:43 <__walker> Sounds like the right choice then
15:14:50 <jasonpgignac> caleb_: Agreed, there. Its probably important that we maek it as easy as possible for new people to join in
15:14:55 <caleb_> zns: The stackforge org helps as an aggregation point for other related projects.
15:15:33 <caleb_> When I asked "Where is the ecosystem of related projects?" the answer was "Go look in stackforge."
15:15:40 <zns> So can we merge pull requests into the stack forge org?
15:15:55 <zns> Or do we have to follow gerrit to do that.
15:16:13 <caleb_> Yes, we could. It sounds like we have agreement to use Gerrit though. Am I correct is saying that?
15:16:29 <jasonpgignac> I agree with that.
15:16:38 <gondoi> agreed
15:16:41 <zns> OK.
15:17:04 <zns> #agreed we will use the gerrit workflow once in stack forge (not the github workflow)
15:17:17 <zns> Moving on...
15:17:18 <zns> #topic Upcoming blueprints
15:17:30 <zns> Main ones are system info and opinons:
15:17:36 <zns> #link https://blueprints.launchpad.net/satori/+spec/poc-system-info
15:17:36 <zns> #link https://blueprints.launchpad.net/satori/+spec/poc-resource-opinions
15:17:42 <zns> System info is about logging in to the servers (ex. nova compute instances) and reporting on what’s running/installed on them.
15:17:49 <zns> Opinions is about loading a library of best practices (or any rules) to provide opinions (good or bad) about the discovered configuration.
15:17:53 <gondoi> #info we will use gerritt workflow once in stackforge
15:18:18 <zns> I'd like to bring up the topic of how we should get data off of hosts; the first blueprint.
15:19:19 <zns> The question is what tool should we use (or build) to get data off of hosts?
15:19:32 <caleb_> SystemInfoProposal still needs further definition.
15:19:54 <caleb_> the idea of the blueprint is that we could use multiple tools.
15:19:59 <caleb_> creating a plugin for each one.
15:20:22 <caleb_> Based on our personal experience we would start by writing waldo/sysinfo/ohai.py
15:21:04 <zns> OK. I agree with that.
15:21:09 <caleb_> Sorry, I meant satori/sysinfo/ohai.py
15:21:10 <gondoi> I agree ohai is a good start
15:21:15 <jasonpgignac> Just to clarify, the blueprints will include data retrieval, but no data analysis/opinionation, correct?
15:21:23 <__walker> #agreed Due to the diversity of hosts and preferences for tools, this seems the best approach
15:21:25 <jasonpgignac> Blueprints being a separate task?
15:22:01 <jasonpgignac> #agreed on Ohai as a good first target
15:22:01 <caleb_> jasonpgignac: the opinion blueprint is separate. Opinions would review resources and its attributes.
15:22:18 <jasonpgignac> caleb_: Thank you for the clarification
15:22:32 <caleb_> the sysinfo blueprint specifies how resources include the additional info
15:22:44 <zns> jasonpgignac: a good way to think about that is that collection and analysis are separate steps. system info is about collecting data. opinions is about analyzing that data.
15:22:48 <caleb_> on the topic of the plugin structure....
15:22:54 <gondoi> do we need to call out a need for different system types to use different system info gathering tools?
15:23:06 <zns> Like windows?
15:23:12 <gondoi> for example, windows vs linux
15:23:13 <gondoi> yes
15:23:17 <gondoi> or bsd
15:23:26 <caleb_> I was originally thinking that a plugin would need to define common functions like: install_tool/upgrade_tool/execute_command/filter_data, etc.
15:23:42 <__walker> What if that logic was in the plugin itself?
15:23:55 <caleb_> However, I think __walker has convinced me to just have one function in the plugin and let the plugin handle everything as it wants.
15:24:00 <jasonpgignac> I concur with _walker
15:24:05 <zns> caleb_: why not just get_system_info(address, credentials)
15:24:09 <gondoi> i think it depends on the plugin structure itself, correct?
15:24:28 <zns> And the plugin handles everything else... just to keep it simple?
15:24:30 <samstav> If multiple tools is the direction to go in, a prerequisite blueprint would be for a channel (e.g. ssh module)
15:24:34 <caleb_> zns: Yes, that was rwalker's suggestion.
15:24:42 <jasonpgignac> It raises the question of should we, perhaps, require that plugins handle unexpected OS types?
15:24:44 <caleb_> samstav: Agreed.
15:24:55 <jasonpgignac> So that if a plugin is written that will work only with inux, it will fail gracefully.
15:24:56 <jasonpgignac> Etc.
15:25:33 <zns> samstav: should establishing an ssh chanel be outside the modules? What about if a plugin doesn't use ssh? (Windows and WMI for example)
15:25:46 <caleb_> jasonpgignac: Perhaps this is me being lazy but I'd like to assume recent mainstream Linux distros initially and define greater details after the first implementation.
15:25:49 <__walker> jasongignac: yes, i believe a plugin would need to do that. Not all discovery tools support all os's (ansible for example).
15:26:25 <jasonpgignac> calen_: I'm good with that, as long as we make that clear in the documentation of the app.
15:26:29 <samstav> zns: good question, and outside my domain.
15:27:09 <caleb_> zns: I would think there should be a utils module that provides common tools like making an SSH connection with our credentials structure.
15:27:23 <__walker> #agreed caleb_
15:27:29 <zns> How about we start with having the plugins own establishing the connection to start with, but we provide a built-in ssh module that they can use?
15:27:30 <jasonpgignac> zns: If anything, that is perhaps an argument for separating different OS families into altogetehr different tracks. The very basis of the mechanism for communicating and coordinating events would, then, be differet on a Windows box?
15:27:41 <caleb_> zns: Agreed.
15:28:00 <samstav> #agreed zns
15:28:11 <jasonpgignac> #agreed zns
15:28:17 <__walker> #agreed zns
15:28:41 <zns> jasonpgignac: what do you mean by different tracks? Different branches, projects,... ?
15:29:03 <zns> #agreed plugins own establishing the connection to start with, but we provide a built-in ssh module that they can use
15:29:11 <jasonpgignac> That's probably a very large architectural question, that I would want to do far more intelligent thinking on before making a suggestion
15:29:24 <caleb_> zns: Can you assign that action to somebody to update the blueprint?
15:29:28 <caleb_> notit
15:29:45 <zns> jasonpgignac: ok.
15:29:56 <zns> I'll take it.
15:30:11 <zns> #action ins implement plugins own establishing the connection to start with, but we provide a built-in ssh module that they can use
15:30:34 <caleb_> ins?
15:30:38 <jasonpgignac> If it is important that we begin to come up with an answer to the question of Windows track at this point, I can coordinate with some experts in the area to come up with some proposals. IF not, it is an understandable decision to leave this as a future feature
15:30:53 <zns> #action zns - that was autocorrect
15:31:28 <zns> jasonpgignac: I'd love to see a blueprint or PR for that to support windows.
15:31:47 <caleb_> #action zns implement plugins own establishing the connection to start with, but we provide a built-in ssh module that they can use
15:31:55 <zns> OK. Anything else on blueprints or specs?
15:32:23 <zns> I think we can touch on mor of that in the next topic too...
15:32:24 <samstav> yes
15:32:25 <zns> #topic What features should be implemented before we announce to the User List?
15:32:42 <zns> samstav: you had a question?
15:33:20 <caleb_> Re: User List. Our announcement to the Dev List was pretty flat. My opinion about that is that most Stackers are building core building blocks of a cloud rather than hacking on things that are closer to the userland.
15:33:29 <samstav> yes. at the beginning of previous topic, _caleb said "I was originally thinking that a plugin would need to define common functions like…" . What is the conclusion now, where are we leaving that what defines a plugin in that regard?
15:33:45 <samstav> caleb_
15:34:31 <zns> caleb_: do you feel strongly that we should break out those separate calls now, or can it wait until we have our first implementation?
15:34:38 <caleb_> I think we can generate greater interest by announcing our project to the User List. So, what things should we implement before we do that? Should we just announce in our current state?
15:35:16 <samstav> plugin -> a system information plugin
15:35:36 <gondoi> I am not up to date on what pip install satori's current state is?
15:35:37 <jasonpgignac> Perhaps a Tutorial of some sort? Our current documentation is not user-centric.
15:35:37 <gondoi> can it do an actual discovery?
15:35:37 <gondoi> if so, then yes
15:36:10 <zns> I'm assuming we want to provide value and a reliably functional app before announcing to users. So that would mean some more testing, better error reporting (no stack traces).
15:36:39 <caleb_> I think having the latest pushed to pypi is a hard requirement so that we can just instruct people to `pip install satori`
15:36:39 <caleb_> gondoi: Yes, it can do DNS and nova detection currently
15:36:43 <__walker> I think more work into sysinfo would make a greater impact to userlist
15:36:47 <zns> gondoi: You can see the functionality here https://pypi.python.org/pypi/satori
15:37:54 <zns> I agree with __walker  - we implement system info first.
15:38:18 <caleb_> zns: Re plugin structure: I think we should do a few implementations and then change the format as we find things that are similar between plugins. Pull out the common features, etc.
15:39:18 <zns> caleb_, samstav: So we build the first plugin or two with a simple (one call) interface and then evolve into a plugin interface as/when needed?
15:39:20 <walker_> caleb_ that seems reasonable
15:39:21 <caleb_> I think it would be cool to document how to use Satori inside of Python code too. An example of how to integrate discovery into your app could be nice.
15:39:27 <samstav> #agreed plugin structure
15:39:28 <samstav> thanks
15:39:40 <caleb_> http://satori.readthedocs.org/en/latest/ should probably also get some love.
15:39:50 <gondoi> i agree with system info discovery too
15:39:51 <zns> #agreed  first plugin or two with a simple (one call) interface and then evolve into a plugin interface as/when needed
15:40:00 <caleb_> That site is autogenerating as code merges but our docs are quite bare.
15:40:13 <samstav> a one-call plugin sounds pretty intelligent for a first iteration...
15:40:14 <jasonpgignac> caleb_ I agree - in general, it might do good to have some loving given to the docs, add some guide-style work to provide a compelling introduction
15:40:19 <zns> caleb_: how does that get published?
15:40:33 <caleb_> Who can get the docs in a better state?
15:41:09 <gondoi> i'll help wih docs
15:41:11 <zns> caleb_: who can get our current docs pushed onto readthedocs.org?
15:41:31 <jasonpgignac> I think we'd need to go beyond simply Python function docs, and write some hard narrative documentation if we're going to attract new users.
15:41:32 <jasonpgignac> I can help with that.
15:41:45 <zns> Is it automatic whenever we update our repo?
15:41:50 <gusmaskowitz> I can do that
15:41:57 <caleb_> zns: I setup an account on readthedocs. Its watching the repo and will auto update
15:42:02 <walker_> jasongignac: I think documenting how to use it should come before exposition
15:42:12 <caleb_> #action gusmaskowitz Update user documentation in satori/doc
15:42:15 <walker_> jasonpgignac ^
15:42:16 <zns> #action jasonpgignac will update docs for pypi and http://satori.readthedocs.org/en/latest/
15:42:19 <zns> Thanks jasonpgignac
15:42:41 <caleb_> oh, I didn't see jasonpgignac volunteer
15:42:50 <caleb_> and I didn't see gondoi either :\
15:42:52 <jasonpgignac> I did say I would help. I'm fine with that.
15:43:01 <gondoi> :D
15:43:05 <zns> gondoi actually volunteered first!
15:43:07 <jasonpgignac> Life of an English major. *hand to forehead dramatically*
15:43:37 <zns> Should I change the action to gondoi?
15:43:48 <zns> #action gondoi will update docs for pypi and http://satori.readthedocs.org/en/latest/
15:43:58 <gondoi> I think you can list all users in one #action
15:44:00 <samstav> re: "documenting how to use it should come before exposition"
15:44:09 <zns> #action gusmaskowitz  will update docs for pypi and http://satori.readthedocs.org/en/latest/
15:44:13 <samstav> should include tutorial through python api
15:44:35 <zns> There... I wonder what the bot output will look like at the end...
15:44:52 <zns> samstav: I thought we had that in the read me...
15:45:09 <zns> maybe not...
15:45:19 <jasonpgignac> I agree with samstav.
15:45:23 <samstav> maybe I should do what the filename is telling me to do
15:45:50 <zns> samstav, jasonpgignac : when you say tutorial, are you thinking of just a sample on the read me or something more involved? Like docker.io?!
15:46:19 <jasonpgignac> zns: Something along the lines of the guides one finds for Rails woudl be optimal in my mind.
15:46:23 <samstav> Sorry, no. Just a snippet or two
15:46:36 <zns> jasonpgignac: I'm not familiar with rails... sorry
15:46:50 <jasonpgignac> http://guides.rubyonrails.org
15:46:58 <zns> samstav: OK. That's what I'm thinking too.
15:47:06 <jasonpgignac> Not, of course, this MUCH documentation at start, just in style.
15:47:20 <jasonpgignac> API documentation is primarily useful for reference and task implementation.
15:47:34 <jasonpgignac> Narrative documentation aids in slef-training and communicating interest
15:47:49 <jasonpgignac> But that's just a proposal, of course, we don't have to.
15:47:51 <caleb_> Style? The OpenStack doc team already has common styles that we could leverage.
15:48:06 <caleb_> Also, the base theme for readthedocs looks pretty solid these days too.
15:48:18 <zns> But for the first user release, I think something pretty short (like what's on http://satori.readthedocs.org/en/latest/) is ideal.
15:48:38 <jasonpgignac> Alright
15:49:01 <zns> caleb_: I like http://satori.readthedocs.org/en/latest/ too. Looks simple and clean.
15:49:09 <samstav> I don't imagine there is enough code to exercise for something that extensive yet, anyhow. Just something in addition to CLI
15:49:10 <caleb_> Time check, we have 12 minutes left. There might be a meeting in this room at the top of the hour.
15:49:59 <zns> OK. So for the user release we're going to implement system_info and basic (one pager) docs. Agreed?
15:50:06 <zns> What about error handling?
15:50:24 <jasonpgignac> #agreed On sysinfo and basic docs
15:50:31 <zns> caleb_: thanks. We have one more topic, so I think we're good...
15:51:06 <jasonpgignac> Error Handling: Early adopters/experimenters are likely used to stack traces, and may appreciate the extra info.
15:51:07 <caleb_> zns: Agreed. Not sure that trapping all errors are needed.
15:51:13 <jasonpgignac> Unless we have known, true exceptions.
15:51:16 <caleb_> Some traces give decent feedback.
15:51:23 <zns> Error handling? Any volunteers for making sure the CLI doesn't stack trace?
15:51:43 <samstav> I'll take it, because I can break anything
15:52:01 <zns> caleb_: yes, but maybe in --debug mode? I don't know that a user should get a stack trace.
15:52:37 <caleb_> zns: I'm not opinionated on error handling. I'm cool either way.
15:52:59 <zns> #action samstav catch exceptions in CLI so we don't stack trace (consider --debug mode allowing exceptions through to allow for debugging)
15:53:22 <zns> OK. Next (and last) topic
15:53:24 <zns> #topic Keeping an eye on https://wiki.openstack.org/wiki/PythonOpenStackSDK
15:53:24 <caleb_> samstav: Can you write a blueprint for that, too?
15:53:25 <samstav> 👍
15:53:42 <jasonpgignac> I believe on principal in failing noisily, but I am fine if the consensus disagrees
15:53:44 <zns> caleb_: was that your topic?
15:54:00 <caleb_> zns: Yes. The SDK discussion is a few weeks old.
15:54:14 <caleb_> Jesse Noller is beating this drum in the community
15:54:30 <caleb_> the desire is to create one common lib that interacts with all projects.
15:54:51 <zns> I started implementing the nova instance detection with python-openstackclient, but it was not ready, so I switched back to python-novaclient.
15:55:10 <caleb_> Most projects don't talk to each other directly so python-<project>client projects work well. Satori will obviously need to talk to them all.
15:55:34 <caleb_> I think we should watch the unified project and switch to it should it gain acceptance.
15:55:48 <zns> I fear that python-openstackclient will be changing rapidly and we have a lot to get done. It feels like too much risk right now... MHO
15:55:48 <caleb_> However, relying on it right now is too risky.
15:56:01 <zns> caleb_: +1 :-)
15:56:35 <caleb_> I'm going to follow the wiki page and try to keep track of the project's progress.
15:56:45 <zns> 4 minutes remaining. If anyone has burning questions, start composing them?
15:56:48 <caleb_> That's it.
15:56:57 <zns> caleb_: cool. Thanks. No action item?
15:57:02 <caleb_> zns: Nope.
15:57:03 <jasonpgignac> #agreed monitor openstackclient and adopt as it grows in popularity
15:57:24 <zns> #agreed monitor openstackclient and adopt as it grows in popularity
15:57:57 <zns> OK. Thank you all! See you next week...
15:58:04 <zns> #endmeeting