20:03:42 <Rockyg> #startmeeting log_wg
20:03:42 <openstack> Meeting started Wed Oct 14 20:03:42 2015 UTC and is due to finish in 60 minutes.  The chair is Rockyg. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:46 <openstack> The meeting name has been set to 'log_wg'
20:03:53 <jokke_> i Rockyg
20:03:57 <Rockyg> Hi!
20:04:12 <jokke_> nice ... didn't want to kick off the meeting if I was only one ;)
20:04:24 <Rockyg> Well, likely short.
20:04:37 <jokke_> sounds fine to me
20:05:05 <Rockyg> #action Rocky is putting together spec for a logging doc:  "OpenStack Logging System"
20:05:23 <Rockyg> #link https://etherpad.openstack.org/p/Logging_doc
20:05:35 * jokke_ clicks
20:05:58 <Rockyg> Link is where to modify TOC and add reference, info links to make this happen faster
20:06:27 <Rockyg> #info We'll get Ops folks to sign up for chapters or sections at the summit and from the Ops ML
20:06:49 <Rockyg> Docs will help with editing, formatting, etc
20:07:04 <jokke_> nifty
20:07:05 <Rockyg> bknudson, you around?
20:07:13 <bknudson> Rockyg: yep
20:07:24 <Rockyg> Yup.  Finally getting organized for the summit
20:07:49 <Rockyg> So, are both of you aware of global config settings vs project specific config settings?
20:08:01 <jokke_> nope
20:08:06 <Rockyg> Kewl!
20:08:37 <bknudson> I didn't think there was any documented way to do global config settings.
20:08:38 <Rockyg> Neither are many in Docs.  They're in /etc/openstack (don't know whether there are any caps in it)
20:09:16 <Rockyg> They are the default and the project configs overwrite.
20:09:39 <jokke_> well I know how I do it on service level and I've heard that there is some global stuff, but haven't really looked into it
20:10:09 <bknudson> everybody should be using ansible or something anyways.
20:10:10 <Rockyg> bknudson, I think Oslo changed some of that, nbut you might still need to generate the file through the openstack magic stuff
20:10:53 <Rockyg> small sites and poc sites won't have ansible setup.
20:11:07 <Rockyg> Just like not all sites aggregate the logs.
20:11:38 <Rockyg> OK, so getting more info on global stuff would help *everyone* in the community, I suspect.
20:11:42 <bknudson> they'll wish they did.
20:12:12 * jokke_ fails to see how ansible/chef/puppet is related to global vs. service configurability
20:12:15 <Rockyg> I know logs default to some global stuff
20:12:53 <Rockyg> and I know they can be changed on a global level
20:13:29 <Rockyg> So, this is cool.  This is the sort of "finding holes" I enjoy.  Now, on to filling them.
20:13:45 <jokke_> yeah documenting that would be helpful
20:14:17 <bknudson> there's a global config file /etc/openstack?
20:14:26 <Rockyg> So, guys, if you would please, review the etherpad at your leisure and if you have additions/removals/mods, please do so.  Especially pointers to information
20:14:53 <Rockyg> bknudson, supposedly.  Looking at some of the docs, it pointed to that location
20:15:51 <bknudson> Rockyg: which docs?
20:16:03 <Rockyg> trying to find it again, now...
20:16:46 <bknudson> oslo.config has some code to search for the config file: http://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/cfg.py#n542
20:17:03 <bknudson> which lists some directories it searches in
20:18:13 <Rockyg> Maybe that's it.....
20:18:42 <jokke_> it is DocString so most likely it's also included into some docs
20:19:53 <bknudson> http://docs.openstack.org/developer/oslo.config/helpers.html#oslo_config.cfg.find_config_files
20:20:16 <jokke_> #link http://docs.openstack.org/developer/oslo.config/helpers.html#oslo_config.cfg.find_config_files
20:20:22 <Rockyg> kewl.  But what does it return?
20:22:08 <jokke_> it really depends what you are asking from it ... would need to look where that function is actually called or is it something what projects should call within their config processing
20:22:29 <Rockyg> So, I know I found some references to yaml files and some other stuff.  I think maybe I was looking at install docs and tracking down source code to go with it.
20:23:22 <bknudson> all the projects will have to create a ConfigOpts and it gets called from there...
20:23:32 <bknudson> http://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/cfg.py#n1802
20:24:38 <Rockyg> So, then where are the default_conf_files located?  Since it uses the project ones if no default.
20:24:42 <bknudson> this isn't the most clearly written code ever.
20:25:02 <bknudson> especially for something that seems pretty simple.
20:25:31 <Rockyg> I think maybe it was CLI docs I found the reference, or the pointer that sent me to the oslo stuff
20:25:47 <jokke_> yeah ... it also looks like that it's not global config related, but rather just helper that looks for project specific confs for few places if config file locations are not provided
20:26:20 <bknudson> the application will do something like OPTS = ConfigOpts() and then register a bunch of options and then OPTS(project='keystone', default_config_files=[whatever])
20:26:35 <bknudson> so the application can override the default config files if it wants
20:29:10 <bknudson> http://git.openstack.org/cgit/openstack/keystone/tree/keystone/server/common.py#n35
20:29:19 <bknudson> keystone actually does pass in default_config_files :(
20:29:27 <Rockyg> I wish I could grep on the docs website
20:31:55 <jokke_> bknudson: defaulting None
20:32:11 <Rockyg> Hmm.
20:32:27 <bknudson> oh, keystone only passes default_config_files when there's a developer etc/keystone.conf file.
20:32:54 <bknudson> so in the normal situation we'd use the default search that oslo.config gives us
20:33:07 <jokke_> aha
20:33:36 <jokke_> smells like something to help gating
20:33:38 <bknudson> probably not worth it to keep that behavior, but it's left over from antediluvian times.
20:34:07 <Rockyg> hmmm
20:34:35 <bknudson> anyway, I think we can assume that all the projects let oslo.config find the config file
20:34:36 <jokke_> well if you don't keep that your tests will run against /etc/keystone.conf for example rather than the dev default conf file
20:34:53 <jokke_> bknudson: ++ or there is good reason not to
20:35:46 <bknudson> I thought by global config file that meant that you had all your configs in the same file, but the oslo.config search is specific to the project.
20:35:55 <bknudson> or even the executable name.
20:36:21 <jokke_> yup, that's what I said already earlier that this is not global across the projects config
20:36:24 <Rockyg> I know there's a place where you can list a bunch.  And oslo.log has defaults, but doesn't have a project directory, so....
20:36:29 <bknudson> isn't it well-known that you have /etc/keystone.conf and /etc/nova-api.conf?
20:36:45 <Rockyg> That part is very well known.
20:37:27 <bknudson> oh, it's /etc/keystone/keystone.conf
20:37:41 <bknudson> which is /etc/${project}/ from http://docs.openstack.org/developer/oslo.config/helpers.html#oslo_config.cfg.find_config_files
20:37:42 <Rockyg> http://git.openstack.org/cgit/openstack/os-client-config/tree/README.rst  read that one...
20:38:28 <bknudson> os-client-config is for configuring your clients (e.g., the openstack CLI)
20:38:34 <Rockyg> #link http://git.openstack.org/cgit/openstack/os-client-config/tree/README.rst
20:38:39 <bknudson> and it is really neat and maybe not as well known as it should be
20:38:51 <bknudson> since a lot of people still use an openrc file
20:39:39 <Rockyg> Yes.  But, it also pretty much sets up global config variables at the same time.  works for both client and server if it's envvar
20:39:52 <bknudson> I don't know if openstack CLI is actually using os-client-config
20:40:25 * jokke_ really dislikes openstack CLI
20:40:44 <bknudson> jokke_: why's that?
20:40:52 <bknudson> it can't be worse than the keystone CLI.
20:41:47 <bknudson> plus it supports clouds.yaml so that makes it easier to use
20:42:02 <bknudson> you can do openstack --os-cloud=rax user list
20:42:09 <bknudson> and then openstack --os-cloud=hp user list
20:42:20 <bknudson> not that you'd list users... maybe boot an instance would be a better example
20:42:29 <jokke_> bknudson: on glance discussions I referred it like deprecating all your filesystem tools and introducing command filesystemutils instead ... then if you want to list your files rather than ls you write something like `filesystem ReiserFS list-files-and-folders <path>`
20:42:35 <Rockyg> That's it, clouds.yaml.  That's pretty much the code used to generate the global config file....
20:43:44 <bknudson> having separate commands would be more unixy I guess.
20:44:12 <Rockyg> you're showing your age...;-)
20:44:24 <bknudson> yes, they should also be very obscure.
20:44:28 <jokke_> yeah ... the current trend is really driven by fans of windows powershell where everything is bundled as much as possible and uses 100 character long commands and options
20:44:31 <bknudson> 5 letters max
20:44:56 <bknudson> bi for boot instance
20:44:56 <Rockyg> powershell -- YUCK!
20:45:27 <bknudson> you can set up aliases I guess.
20:45:45 <jokke_> but I'm also one of those who thinks that removing short options for commonly used stuff was really moronic idea
20:46:18 <jokke_> bknudson: or you can have proper clients maintained by the projects that are made to do that one thing ;)
20:47:09 <jokke_> I would be all up for something like oslo_cli which would provide all the common bits in unified way to be consumed by clients
20:47:30 <Rockyg> +1000
20:47:43 <jokke_> like the auth options etc. that needs to be reimplemented by every single client now
20:48:06 <Rockyg> jokke_, write a spec for Oslo ;-)
20:48:18 <bknudson> well, not now, since we've got a library for auth options
20:48:24 <jokke_> Rockyg: I would if I had time to do it
20:48:38 <Rockyg> Write the spec, let others write the code.
20:48:43 <jokke_> bknudson: well that was just an example ... bad one as that problem got solved
20:48:49 <jokke_> Rockyg: like that would ever happen
20:48:55 <Rockyg> I bet I could find some folks to collaborate with you.
20:49:37 <jokke_> One thing I've learned so far is that unless you're willing/able to do it, don't even bother to dream about it
20:50:49 <jokke_> maybe one day I will have the time to jump in and do something meaningful like that :P
20:51:03 <bknudson> don't give up on your dreams.
20:51:09 <Rockyg> OK.  I'm gonna try and gather info off all the old ehterpads for logging and distill it.  If I make it by next week, I'll point you guys at it.
20:51:14 <bknudson> this is a support group.
20:51:39 <jokke_> peer support for broken dreams? :P
20:51:43 <Rockyg> Yeah, keep dreaming!  As others execute baby steps, one day, your dream can come true
20:52:41 <jokke_> but back to topic, did we have something else that would be actually logging related?
20:53:20 <Rockyg> I think that's it for today.  Maybe more next week.  I finally feel like I have a little time to work on this stuff.
20:53:34 <jokke_> and I'm assuming the time might be different but on the Summit week we will have f2f meeting, how about next week?
20:53:50 <Rockyg> by ignoring DefCore :P
20:54:29 <jokke_> Rockyg: _Don't_ ignore DefCore! You're my only hope that there will be some sanity
20:54:38 <Rockyg> Let's try for it.  I 'm hoping to have more stuff to review.  And reminder:  Review that etherpad and make comments, please?
20:55:14 <jokke_> yeah ... I'm ok having meeting next week after that the couple following ones might not work out that well
20:55:24 <Rockyg> I'm coming back to DefCore, but I think I need to take my husband's advice -- Let them fail so it's easier to get them on your page...
20:55:49 <Rockyg> We'll set a new time while we're at the summit...
20:56:02 <Rockyg> Thanks folks!
20:56:06 <Rockyg> #endmeeting