16:00:41 <dims> #startmeeting oslo
16:00:42 <openstack> Meeting started Mon Jun 29 16:00:41 2015 UTC and is due to finish in 60 minutes.  The chair is dims. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:43 <jecarey> o/
16:00:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:45 <openstack> The meeting name has been set to 'oslo'
16:00:46 <bknudson> hi
16:00:48 <ozamiatin> o/
16:00:52 <jd__> o/
16:00:53 <kragniz> o/
16:01:06 <bknudson> hi
16:01:12 <harlowja_still_a> sup sup
16:01:30 <federico3> o/
16:01:40 <dims> let's get started
16:01:41 <dims> #topic Red flags for/from liaisons
16:01:49 <dims> #info initial (unstable-API) releases for oslo.cache, oslo.reports, oslo.service, automaton, futurist are in pypi
16:01:57 <bknudson> no red flags from keystone.
16:02:08 <dims> bknudson: yay thx
16:02:49 <jungleboyj> No red flags for Cinder.  Have a number of updates we have been making to get to the latest oslo libraries.  So, just working through those.
16:02:51 <stevemar> (though the keystone team would like a stable release of oslo.cache, get on that stevemar!)
16:03:15 <stevemar> bknudson: what about that change to oslo.service?
16:03:33 <bknudson> stevemar: seems to be going ok
16:03:38 <bknudson> wouldn't call it a red flag yet.
16:03:43 <dims> stevemar: let's use bugs for tracking items left to do for oslo.cache so we know when we will get to stable API?
16:03:43 <ihrachyshka> I only wonder whether there is a chance to get any resolution for https://review.openstack.org/#/c/176333/
16:03:51 <ihrachyshka> not a really red flag though
16:04:06 <bknudson> oslo.service is changing the API on us
16:04:19 <bknudson> but I guess they feel they can do that at this stage.
16:04:38 <dims> bknudson: 0.1.x are all really early - forklift then adjust API mode
16:04:39 <bknudson> if there's another release of oslo.service keystone will be broken since we're using the old interface
16:04:47 <ihrachyshka> speaking of oslo.cache, seems like we switched API very seriously, and it's not clear how to adopt it. so docs would help.
16:05:27 <bknudson> same thing will happen if we change keystone to use oslo.cache and then have to fix the api.
16:05:29 <dims> ihrachyshka: oslo.cache, you should see the spec. it's not the memorycache.py or cache.py from old oslo-incubator
16:05:40 <stevemar> ihrachyshka: there were no APIs, it was in keystone before
16:06:00 <ihrachyshka> stevemar, oh I thought it's the incubator code, but ok, I'll check the spec then
16:06:18 <dims> ihrachyshka: dogpile is the interface
16:06:35 <bknudson> keystone is going to break and since the changes aren't backwards-compat there's no way to not break
16:06:37 <ihrachyshka> dims, meaning, we should use it directly? no oslo.cache?
16:06:52 <bknudson> I pity the fool that does continuous delivery.
16:07:13 <dims> ihrachyshka: encourage you to see the spec :)
16:07:18 <ihrachyshka> ack
16:07:21 <bknudson> maybe we should do this in a feature branch or something
16:07:25 * bnemec pictures bknudson wearing dozens of gold chains
16:07:31 <dims> lol
16:08:27 <dims> on that topic
16:08:30 <dims> #topic Releases for this week
16:08:30 <dims> Releases for this week. Here are the unreleased changes
16:08:30 <dims> #link http://paste.openstack.org/show/324570/
16:08:45 <dims> please take a look at the link
16:09:14 <dims> i'll roll these out this afternoon my time (it's mid-day now for me)
16:09:46 <harlowja_still_a> seems ok to me :)
16:09:47 <harlowja_still_a> thx dims
16:10:22 <dims> if anyone has concerns that we will break someone, please ping me on #openstack-oslo
16:10:39 <dims> haypo and i pinged some nova folks for a possible oslo.db issue
16:10:45 <bknudson> oslo.service will break keystone
16:11:03 <dhellmann> bknudson: what changed in the API?
16:11:18 <bknudson> the service needs to be derived from a class...
16:11:44 <dims> and there's an enforcement check that it is indeed derived from a class
16:11:44 <bknudson> https://review.openstack.org/#/c/196183/
16:11:57 <bknudson> this was the change: https://review.openstack.org/#/c/194143/
16:12:08 <bknudson> Move service abstract base class check to launch_service methods
16:12:11 <stevemar> this is the fix: https://review.openstack.org/#/c/196175/
16:12:22 <bknudson> y, we have a fix it's just not merged yet.
16:12:36 <dhellmann> yeah, we should make that transition smoother
16:12:51 <bknudson> it's actually not bad at all since we can put in the current change now
16:12:53 <dhellmann> why are we enforcing the type there in the first place?
16:13:41 <dims> bknudson: looks like just one more keystone core is needed
16:13:54 <bknudson> dims: it is right on the brink of merging!
16:14:10 <bknudson> only a few more months and another core will look at it.
16:14:16 <dims> haha
16:14:59 <dstanek> ok, so if we going to live with the backward incompatibility i can +2 the keystone fix
16:15:09 <bknudson> some people are scared of dynamic languages and their crazy duck typing, so need to check interfaces with ABC.
16:15:11 <dhellmann> dims: it sounds like things will be fine for keystone if we wait a bit, but do we know about anyone else?
16:15:34 <dims> dhellmann: will check on nova before i release
16:15:34 <dstanek> bknudson: ++, it's very unfortunate
16:15:52 <dims> #topic New libraries and drivers - how is it going?
16:15:53 <dims> #link specs - http://specs.openstack.org/openstack/oslo-specs/
16:16:04 <harlowja_still_a> i fixed a case of it in cinder (for the service isinstance check); so they should be fine
16:16:05 <dims> docs, docs, docs is what i hear
16:16:18 <ozamiatin> dims: spec is ready for review https://review.openstack.org/#/c/187338/
16:16:31 <bknudson> dstanek: I abandoned the revert of the change to check the interface since it was getting lots of -1.
16:16:34 * harlowja_still_a docs have been made, its like brushing your teeth, do a little everynow and then and it pays off :-P
16:17:07 <ozamiatin> dims: need to merge this https://review.openstack.org/#/c/193502/ to proceed with driver
16:17:15 <kgiusti> devstack plugin has flushed what appears to be a bug in the proton packaging - I'm currently trying to work around/fix that
16:17:42 <dims> ozamiatin: ack, starred both for review later today
16:18:00 <ozamiatin> dims: thanks
16:18:03 <dims> kgiusti: thanks, is there a bug somewhere?
16:18:20 <stevemar> thanks dstanek and morganfainberg
16:18:25 <kgiusti> dims: I think it's in the upstream proton packaging
16:18:58 <kgiusti> dims: the packaged .so files are being put in the 'pure' library, not the platform path
16:19:17 <dims> kgiusti: ack, usually we just create one for our gate break so folks know there's a known failure
16:19:47 <kgiusti> dims: ok that makes sense - I'll do that.
16:20:05 <dims> #topic Ongoing work & Review priorities
16:20:05 <dims> #link https://etherpad.openstack.org/p/liberty-oslo-priorities-tracking
16:21:04 <dims> found a bunch of missing requirements in a few projects, added a tox target to find these, please look at
16:21:05 <dims> https://review.openstack.org/#/q/status:open+topic:pip-missing-reqs,n,z
16:21:38 <dims> i'll do the same exercise for adding tox target for bandit this week
16:21:49 <dims> if anyone wants to help, please let me know
16:22:27 <harlowja_still_a> i know the octavia folks want https://review.openstack.org/#/c/164922/ (once i rebase it)
16:22:33 <harlowja_still_a> if anyone wants to look over that, or ask questions...
16:22:59 <dims> dhellmann: how can we move this forward? https://review.openstack.org/#/c/176333/ (per ihrachyshka)
16:24:00 * dhellmann looks
16:24:54 <dhellmann> dims, ihrachyshka: my plan was to get all of the projects to adopt oslo.context, and then remove logging customization from devstack and make the default format in oslo.log useful
16:25:20 <harlowja_still_a> oh i guess i don't need to rebase https://review.openstack.org/#/c/164922/ (so ya, people look it over, ha)
16:25:46 <ihrachyshka> dhellmann, what are 'all the projects' and how do we detect those not there yet?
16:25:48 <dhellmann> dims, ihrachyshka : that particular change though is likely to break existing operators who are relying on the uuid
16:26:12 <dhellmann> ihrachyshka: that's a good question -- certainly anything participating in the coordinated release
16:26:19 <dims> dhellmann: added a line to https://etherpad.openstack.org/p/liberty-oslo-priorities-tracking - not sure which reviews we have for "get all of the projects to adopt oslo.context"
16:26:35 <dhellmann> dims: i haven't started with that, yet
16:26:46 <dims> dhellmann: ack will leave question marks there for now
16:26:47 <dhellmann> I'm hoping to get to it soon, when this namespace package work is closer to done
16:27:08 <dims> right, so do you need eyes on namespace reviews? which ones are left?
16:27:40 <dhellmann> we're getting oslo.db today?
16:28:02 <dims> dhellmann: still on the table, will check with haypo before cutting one
16:28:04 <dhellmann> that leaves config, messaging, serialization, and utils
16:28:05 <ihrachyshka> dhellmann, well, honestly, I could leave with devstack just not doing overwrite. if it's uuid that we end up with, fine. the main point is that all services should be consistent. I suppose that operators do not rely on devstack, so we can clean it up there maybe?
16:28:56 <ihrachyshka> the original problem was about devstack not putting some valuable info in logs (pids of workers), which is included in default format string
16:29:02 * harlowja_still_a hopes operators don't rely on devstack :-/
16:29:13 <dhellmann> ihrachyshka: I'm ok with adding variables, I guess, I just want to make sure we can actually get those values. Do we always know the project name, user name, etc?
16:29:57 <ihrachyshka> dhellmann, we should. keystone provides it. projects can obviously avoid using them...
16:30:18 <dhellmann> ihrachyshka: I think the commit message on https://review.openstack.org/#/c/176333/1 confused me into thinking you wanted these to be the default in the logs, but I think you just mean they should always be available and devstack might make them the default
16:30:30 <bknudson> keystone doesn't always have project name.
16:31:02 <ihrachyshka> dhellmann, yeah, but if a project does not override the default format string, then its log format is changed in terms of uuid -> name
16:31:05 <bknudson> you can do stuff with domain-scoped tokens
16:31:08 <dhellmann> ihrachyshka: we might want project_name, etc. to default to the uuid if they aren't provided
16:31:15 <ihrachyshka> there is still an easy way to fall back though
16:31:27 <bknudson> project names aren't unique, they're only unique within the domain
16:31:39 <dhellmann> ihrachyshka: devstack should eventually set one format string for all projects using oslo.log and oslo.context, but it can't do that right now because the contexts aren't all the same
16:31:45 <ihrachyshka> dhellmann, and that's what the patch does. if user_name is not specified, it uses 'user' (which is uuid)
16:32:07 <bknudson> user names are also only unique within the user's domain
16:32:12 <ihrachyshka> bknudson, what do you mean - domain? I probably miss things.
16:32:14 <dhellmann> ihrachyshka: ok, as I said, I think I was confused by the commit message talking about changing default behaviors
16:32:38 <bknudson> ihrachyshka: domain is a namespace for users, groups, and projects.
16:32:47 <dhellmann> bknudson: yeah, I think the goal here is to make devstack log names instead of uuids, so we should be ok as far as uniqueness
16:33:09 <bknudson> uuids are unique, names aren't
16:34:09 <dhellmann> ihrachyshka: you're changing the default for user to be name or uuid. I don't think that's what you should do. Instead, I think you should keep user the uuid and just make it possible to refer to user_name in the log format string. Then devstack and use user_name and the defaults can use uuid.
16:34:47 <dhellmann> ihrachyshka: I pointed out the backwards incompatible change in my comment on line 79
16:35:34 <dhellmann> bknudson: right, I think names are only going to be useful to devstack users
16:35:41 <dhellmann> or maybe private cloud users
16:36:13 <ihrachyshka> dhellmann, ack
16:36:39 <ihrachyshka> as I said, I'm fine with uuid as long as we get that devstack rewrite of the option killed
16:37:43 <dhellmann> ihrachyshka: do you have that link handy?
16:38:02 <ihrachyshka> dhellmann, which one? to devstack rewrite?
16:38:04 <dims> in the meantime, let me open up the topic
16:38:07 <dhellmann> ihrachyshka: yes
16:38:07 <dims> #topic Open discussion
16:38:07 <dims> Any stuck reviews? or specs?
16:38:21 <harlowja_still_a> hmmmm
16:38:38 <harlowja_still_a> when is sileht back?
16:38:48 <ihrachyshka> dhellmann, https://review.openstack.org/#/c/172508/
16:38:57 <harlowja_still_a> be nice to see if https://review.openstack.org/#/c/194880/ is ok with him and all that
16:39:37 <dims> harlowja_still_a: no, sileht is still on vacay
16:39:40 <harlowja_still_a> k
16:40:01 <harlowja_still_a> i think https://review.openstack.org/#/c/194880/ could merge, but really want to double check with him
16:40:11 <harlowja_still_a> it seems like someone could kick https://review.openstack.org/#/c/194880/ and it would go, (since the dependent merged)
16:41:28 <harlowja_still_a> ok it has been kicked :-P
16:41:38 <dhellmann> ihrachyshka: maybe we want a new option to oslo.log/oslo.context to replace user_idt_format in the context, and let devstack set that?
16:42:03 <dhellmann> ihrachyshka: probably in oslo.context
16:42:19 <dhellmann> well, except that doesn't know about oslo.config at all :-/
16:43:15 <ihrachyshka> dhellmann, meh. sounds like too much of a hassle. I was under impression that those names are unique, but if keystone devs say it's not the case, then I tend to rethink whether we should even try to apply such a change.
16:43:24 <dhellmann> ok
16:43:46 <bknudson> if you put the name in addition to the id that would be fine
16:44:00 <dhellmann> bknudson: does a devstack user need both?
16:44:11 <bknudson> I assume this is for usability
16:44:25 <dhellmann> yes, that's my understanding
16:44:25 <bknudson> I don't have every user's uuid memorized
16:44:41 <dhellmann> oh, I guess we have to pass uuids to some commands, don't we
16:44:48 <harlowja_still_a> u better get studying bknudson
16:46:33 <dims> looks like we are done for today. thanks everyone
16:46:38 <dims> #endmeeting