16:00:48 <dhellmann> #startmeeting oslo
16:00:49 <dhellmann> #link https://wiki.openstack.org/wiki/Meetings/Oslo
16:00:49 <openstack> Meeting started Mon Mar  2 16:00:48 2015 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:50 <dhellmann> courtesy ping for jd__, dims, bnemec, flaper87, harlowja, viktors, rpodolyaka, zzzeek, sileht, kgiusti, dansmith
16:00:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:51 <dhellmann> courtesy ping for redrobot, jungleboyj, zhiyan, therve, amotoki, GheRivero, bknudson, ihrachyshka, jogo, dougwig, sreshetnyak, amrith
16:00:52 <openstack> The meeting name has been set to 'oslo'
16:00:56 <stevemar> o/
16:00:57 <jungleboyj> o?
16:00:57 <sileht> o/
16:00:58 <pleia2> o/
16:01:00 <dansmith> o/
16:01:01 <jungleboyj> o/
16:01:02 <bknudson> lol
16:01:04 <bnemec> \o
16:01:07 * jd__ back on business
16:01:07 <amrith> ./
16:01:20 <jecarey> o/
16:01:23 <dims> o/ - distracted but here :)
16:01:30 <GheRivero> o/
16:01:32 <harlowja_at_home> yo
16:01:38 <rpodolyaka> o/
16:01:42 <ozamiatin> o/
16:01:53 <e0ne> hi!
16:02:32 <dhellmann> hi, all
16:02:41 <dhellmann> #topic Review action items from previous meeting
16:02:48 <dhellmann> apparently we had none :-)
16:02:52 <dhellmann> #topic Red flags for/from liaisons
16:03:08 <dhellmann> liaisons, please report in even if you have no issues going now, so we know your status
16:03:19 <bknudson> none that I can think of for keystone.
16:03:30 <amrith> none that I know of from trove
16:03:34 <jungleboyj> dhellmann: I have two subjects to cover.
16:03:43 <GheRivero> none that I know of in ironic
16:03:57 <amrith> specifically, had kept an eye out based on recent graduations. nothing to report.
16:04:07 <bnemec> The Nova oslo.log thing, but I'm pretty sure you're already aware of that. :-)
16:04:16 <ihrachyshka> o/
16:04:18 <dhellmann> bnemec: yeah, dims is working on that
16:04:22 <GheRivero> o/
16:04:36 <viktors> are Nova liaisons around?
16:05:11 <jungleboyj> dhellmann: I opened this bug on Friday.  It is keeping me from updating the 'scheduler' module.  Hope to push up a patch in the next day or so: https://bugs.launchpad.net/oslo-incubator/+bug/1426437
16:05:13 <openstack> Launchpad bug 1426437 in oslo-incubator "The normalize function in scheduler/base_weight.py can't handle float(inf)" [Undecided,New]
16:05:48 <jungleboyj> dhellmann: Not sure who owns the scheduler code but would appreciate any input if there are concerns with what is proposed in the bug.
16:06:19 <dhellmann> jungleboyj: according to our MAINTAINERS file the scheduler code is orphaned right now
16:06:36 <jungleboyj> dhellmann: :-(  Poor little scheduler.
16:07:15 <jungleboyj> dhellmann: That was the change suggested by winston-d , our scheduler guy.  So, I will push up a patch and see what you all think.
16:07:18 <dhellmann> jungleboyj: indeed. I'll have to look at your proposed patch more closely than I have time for right now, but please go ahead and submit it so we can discuss it in the review
16:07:48 <jungleboyj> dhellmann: Cool.  Second item I wanted to cover was setting up a project to use the new oslo-config-generator
16:08:06 <dhellmann> ok
16:08:40 <jungleboyj> Cinder cores were split as to the best approach, putting the list of files in setup.cfg versus the alternative you proposed of creating a new file that would pull all the config options together.
16:08:55 <jungleboyj> Looks like all the other projects are just using setup.cfg .
16:09:09 <jungleboyj> Wonder if nova is planning to do the same thing.
16:09:59 <jungleboyj> It is an issue for Cinder as we have 70+ files with cfg items in them.
16:10:04 <dhellmann> jungleboyj: you'd have to ask jogo, unless dims or bnemec have been involved in that change
16:10:15 <dhellmann> jungleboyj: yeah, you probably don't want to have to list each of them separately
16:10:20 <bknudson> this is why keystone puts all its config options in the same file
16:10:26 <dhellmann> the benefit of doing that is to be able to generate sample files for different services
16:10:26 <bknudson> (or maybe it was just laziness)
16:10:31 <jungleboyj> bknudson: Yeah, I noticed that.
16:10:35 <ihrachyshka> in neutron, we also have lots of configs :)
16:10:39 <dhellmann> but the downside is 70 arguments to pass to the config generator
16:10:50 <dims> jungleboyj: i took a stab at it last week, but got sidetracked
16:11:02 <jungleboyj> ihrachyshka: Have you moved to using the new config generator?
16:11:05 <bknudson> I would make a single function that pulls in all the other options.
16:11:10 <dhellmann> so say if you wanted to generate a separate sample config for the api server and the conductor, you would want 2 entries
16:11:22 <jungleboyj> dims: Which approach were you taking?
16:11:22 <ihrachyshka> jungleboyj, nope, I don't know how to keep split files
16:11:46 <ihrachyshka> we have conf files per plugin, and we have lots of those..
16:12:01 <jungleboyj> ihrachyshka: Right, that is the same for Cinder.
16:12:17 <ihrachyshka> (though I don't believe it's actually a good thing, but the last time I checked, community said separate files are somehow a better approach)
16:12:50 <dims> jungleboyj: nova probably add list_opts() in various files and stick to one nova.conf so one sample file
16:13:10 <jungleboyj> So you can either create an etry per file in setup.cfg to send to the generator or you can create one config file that deep copies the options out of the other drivers.
16:13:43 <dhellmann> I'm not really sure why we started doing that deepcopy thing. If list_opts is only used by the generator, there's nothing to worry about changing.
16:13:48 <jungleboyj> dims: Ok, so not changing setup.cfg with the list of files with options?
16:14:06 <dims> jungleboyj: did not get that far
16:14:40 <jungleboyj> dhellmann: Can you expand that comment?
16:15:20 <dhellmann> jungleboyj: the config generator doesn't modify the config options, and list_opts() is only used by the config generator (not at runtime) so we shouldn't need to deepcopy the options lists to avoid changing them
16:15:25 <bknudson> there's a comment in the code says to do deepcopy.
16:15:34 <dhellmann> hrm
16:15:47 <bnemec> I suspect because list_opts is technically public.
16:15:56 <dims> y
16:16:03 <dims> thought so too
16:16:07 <bnemec> So anyone could be calling it and doing whatever they want with the return value.
16:16:20 <dhellmann> ah, well, ok
16:16:26 <bnemec> I mean, they shouldn't be, but that's never stopped anyone before. :-)
16:16:35 <dhellmann> seems a bit overprotective to me, but it's not *wrong*
16:16:40 <jungleboyj> jungleboyj: The heart of my question is whether you all feel that is a cleaner solution for those of us with many files?  To me it seems to be but it isn't consistent with the existing implementations.
16:17:23 <jungleboyj> thingee didn't want me going off and making us inconsistent if we were the only ones doing it.
16:17:30 <dhellmann> jungleboyj: the idea behind registering multiple names is to allow you to then call the config generator with those namespaces independently. So you only need to list multiple names in setup.cfg if you actually want to generate more than one type of sample config (for different services, for example)
16:18:00 <jungleboyj> dhellmann: Ahhh, ok.  Cinder doesn't need that.
16:18:01 <dhellmann> I'm not sure what approach has been taken in the other projects, or if they understood that distinction
16:19:04 <jungleboyj> dhellmann: That answer means that creating the single config file to create the list_opts() for everyone is the right answer then.
16:19:08 <dhellmann> jungleboyj: a case where cinder *might* want to do that is if you want to generate a config file for a specific driver. But if the driver options are all in unique sections of the file, you can just include them all in one file anyway
16:19:18 <dhellmann> jungleboyj: ok, cool
16:19:40 <jungleboyj> dhellmann: The drivers all need options from multiple locations.  I don't know of anyone who would do that.
16:19:51 <dhellmann> jungleboyj: ok
16:20:17 <dhellmann> jungleboyj: don't forget to include your oslo library namespaces, too (oslo.messaging, oslo.db, etc.) when you run the generator
16:20:39 <jungleboyj> dhellmann: So, I think I will go with adding cinder/options.py and use that for doing the generation.  Also going to write a hacking check to make sure that people update that when they add a file with cfg opts.
16:20:44 <jungleboyj> dhellmann: Done.
16:20:55 <jungleboyj> dhellmann: Got that code working already.  :-)
16:20:55 <dhellmann> jungleboyj: that sounds like a good approach
16:21:09 <dhellmann> are there any other issues from liaisons that we need to cover before moving on?
16:21:35 <jungleboyj> dhellmann: Excellent.  Thank you for your expertise.  ihrachyshka and dims I should have an example for you to work from in the next day or two.
16:22:00 <dhellmann> jungleboyj: that's why we're here :-)
16:22:02 <dims> jungleboyj: awesome
16:22:05 <ihrachyshka> jungleboyj, I'll keep an eye, I'm interested in checking it in L for neutron, keep me in loop
16:22:18 <dhellmann> #topic Introduce HP Helion mentee working on oslo.cache spec
16:22:19 <jungleboyj> Can do.
16:22:21 <dhellmann> #link http://specs.openstack.org/openstack/oslo-specs/specs/kilo/oslo-cache-using-dogpile.html
16:22:25 <dhellmann> pleia2, I'll turn the floor over to you
16:22:30 <pleia2> hello, I'm here with shelly___
16:22:35 <shelly__> hi
16:22:39 <dhellmann> hi, shelly__
16:22:40 <shelly__> I am shelly
16:22:47 <ihrachyshka> 'mentee' ?
16:22:59 <dhellmann> ihrachyshka: the person a mentor works with
16:23:17 <ihrachyshka> ah right. who's a mentee and who's a mentor then? :)
16:23:19 <jungleboyj> shelly__: Hi!  Welcome!
16:23:22 <dhellmann> pleia2 is shelly__'s mentor
16:23:22 <pleia2> we've worked to identify this spec for her to work on, so this is mostly an introduction and we hope to get an action item or two out of this
16:23:28 <ihrachyshka> thanks
16:23:58 <ihrachyshka> welcome and happy to see you onboard :)
16:24:02 <bknudson> hopefully you know morganfainberg
16:24:15 <pleia2> bknudson: yeah, he's the one who pointed us in the direction of this spec
16:24:30 <pleia2> so we'll follow up with him on some of the keystone-specific things
16:24:54 <dims> hi shelly__
16:25:08 <shelly__> hi :D
16:25:30 <bknudson> y, we want to use this in keystone.
16:25:35 <dhellmann> shelly__, pleia2 : a good first step would be to expand the existing spec a little bit with some ideas for what the library API might need to include (IIRC, it was a little sparse because morganfainberg was going to work that out when he started the library)
16:26:12 <dhellmann> it doesn't describe specific configuration options, for example
16:26:48 <dhellmann> and since it's meant to be the connection between oslo.config and dogpile, that seems like a key thing to work through :-)
16:26:55 * pleia2 nods
16:27:35 <bknudson> looks like keystonemiddleware can also use it.
16:27:36 <pleia2> I figure the best way to go about it is a [keystone] thread on list?
16:27:36 <dhellmann> another thing to think about is whether it makes sense to create the new library from scratch in a new repo, or try to use the incubator for the first few revisions
16:28:14 <dhellmann> pleia2, maybe both [keystone] and [oslo] to make sure both teams are involved
16:28:21 <pleia2> sounds good
16:29:02 <dhellmann> shelly__, thank you again for volunteering to work on this project
16:29:04 <pleia2> shelly___: we can collaborate on this email today and send it off
16:29:15 <shelly___> great :D
16:30:00 <shelly___> Thanks for all the helps ^ ^
16:30:29 <pleia2> I think that's enough to get us started, so we'll be in touch
16:30:49 <dhellmann> pleia2, shelly__: ok, sounds good -- thanks for coming to the meeting
16:31:06 <dhellmann> #topic Ongoing work & Review priorities
16:31:07 <dhellmann> #link https://launchpad.net/oslo/+milestone/next-kilo
16:31:07 <dhellmann> #link https://launchpad.net/oslo/+milestone/kilo-3
16:31:40 <dhellmann> shelly__: this is a recurring meeting topic where we catch up on blueprint work, so if you have things you need us to look at once you get started, this is a good place to raise them
16:31:57 <dhellmann> We hinted at work dims is doing on oslo.log for nova earlier. If there are any resulting patches in oslo, we'll be looking for reviewers in #openstack-oslo
16:32:05 <dhellmann> Is anyone blocked on work we prioritized for this release?
16:32:33 <dhellmann> or important bug fixes?
16:32:53 <ihrachyshka> dhellmann, https://review.openstack.org/#/c/159525/ ?
16:33:10 <ihrachyshka> I suppose it should go quickly before initial oslo.policy release
16:33:50 <dhellmann> hmm, that has 2 +2 but no workflow+1
16:33:59 <bknudson> probably because no unit test.
16:34:31 <ihrachyshka> bknudson, have you checked the patch? it's trivial
16:35:02 <dhellmann> ihrachyshka: it is, but because it modifies the public API of the library we need some sort of test to verify that we never break that
16:35:07 <bknudson> ihrachyshka: yes. "Trivial" changes are easy to lose.
16:35:33 <dhellmann> ihrachyshka: a simple test that imports and uses the symbols under their new names would be sufficient
16:35:40 <ihrachyshka> well ok, if you think it's worth it, I'll do it later
16:36:23 <bknudson> ihrachyshka: This is important to consumers, so let's make sure it's tested.
16:36:30 <ihrachyshka> bknudson, ack
16:36:41 <dhellmann> ihrachyshka: I think I left a comment just as you were leaving yours :-)
16:36:55 <bknudson> would be nice if there was a way to flag a test as "important to consumers"
16:37:09 <bknudson> "part of public API"
16:37:48 <dhellmann> bknudson: good idea
16:38:07 <dhellmann> stevemar, how are things looking with oslo.policy?
16:38:35 <stevemar> dhellmann, i am fine with it after ihrachyshka's patch lands
16:38:56 <dhellmann> stevemar: ok, cool
16:39:14 <dhellmann> stevemar: see https://review.openstack.org/160407 as well
16:39:17 <stevemar> dhellmann, there were some folks on the ML asking about it http://osdir.com/ml/openstack-dev/2015-03/msg00029.html
16:39:18 <ihrachyshka> I'll update the patch tomorrow
16:39:25 <dhellmann> since that's a config change, it would be good to include that in the first public release
16:40:01 <stevemar> dhellmann, ++
16:40:16 <stevemar> i'm not sure any project even leverages that option
16:40:33 * dhellmann hopes not
16:40:38 <dhellmann> we should check
16:40:54 <dhellmann> harlowja_at_home: it looks like https://blueprints.launchpad.net/oslo-incubator/+spec/adopt-debtcollector is blocked on a few infra-related changes?
16:41:35 <harlowja_at_home> yuppers one i think https://review.openstack.org/#/c/157566/ and then another is +2ed but waiting
16:41:39 <stevemar> dhellmann, looping back to the original question - i think the keystone team was happy with the current patch to replace the incubated code with oslo.policy https://review.openstack.org/#/c/148624/
16:41:51 <stevemar> bknudson, if you could take another look, that would be good ^
16:42:02 <dhellmann> harlowja_at_home: +2 on that one, we should see if we can get the other reviews wrapped up this week
16:42:10 <harlowja_at_home> agreed
16:42:12 <stevemar> bknudson, i cleaned up the tests in another patch, there was a lot of cruft
16:42:23 <bknudson> stevemar: that's an understatement.
16:42:48 <bnemec> \o/ Death to policy_dirs!
16:43:04 <dhellmann> stevemar: good, so other than the 2 symbols neutron was using we didn't have to change the API?
16:44:05 <dhellmann> dansmith: it looks like there are some infra tasks left on the work items list for https://blueprints.launchpad.net/oslo-incubator/+spec/adopt-oslo-versionedobjects as well, unless those are already done?
16:44:21 <dansmith> dhellmann: nope, I haven't done those yet, sorry
16:44:34 <dhellmann> dansmith: ok,  np, just making sure we're tracking properly
16:44:47 <dansmith> I haven't forgotten about them
16:45:06 <dhellmann> zzzeek requested reviews for https://blueprints.launchpad.net/oslo.db/+spec/make-enginefacade-a-facade, please include that in your rotation
16:45:22 <ihrachyshka> dhellmann, we actually closed some API that was public before
16:45:24 <dhellmann> and we have a few bugs in progress on https://launchpad.net/oslo/+milestone/next-kilo as well
16:45:27 <dhellmann> ihrachyshka: excellent
16:45:41 <ihrachyshka> dhellmann, well, not really. neutron can't move to oslo.policy due to that just now :D
16:45:53 <dhellmann> oh, sorry, I misunderstood -- yes, your patch fixes that
16:46:01 <ihrachyshka> dhellmann, nope, there are more
16:46:13 <ihrachyshka> dhellmann, we relied on AndCheck and RuleCheck and other symbols
16:46:18 <ihrachyshka> well, we still do
16:46:23 <ihrachyshka> but those won't be public anymore
16:46:30 <dhellmann> perhaps we should have a more comprehensive patch, then?
16:46:38 <ihrachyshka> so to migrate, we will need to implement missing features in oslo.policy in L cycle first
16:46:41 <dhellmann> should the _checks module be fully public?
16:47:00 <ihrachyshka> dhellmann, afaik no, stevemar was against it
16:47:18 <dhellmann> ihrachyshka: do you have a full list of the symbols you're using in neutron?
16:47:19 <ihrachyshka> dhellmann, I actually agree that we should move our neutron enhancement to the lib, it just will take some time
16:47:20 <stevemar> ihrachyshka, i am? :)
16:47:36 <ihrachyshka> stevemar, well, maybe not you but someone other from oslo.policy team?
16:47:38 <bknudson> what's the enhancement?
16:47:49 <ihrachyshka> bknudson, sub-attribute checks
16:47:52 <ihrachyshka> let me give you links
16:47:56 <stevemar> if it makes sense to expose it publicly then i'm okay with it
16:48:13 <ihrachyshka> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/policy.py#n150
16:48:15 <ihrachyshka> and below
16:48:40 <ihrachyshka> dhellmann, afaik it's AndCheck and RuleCheck only
16:48:43 <bknudson> interesting.
16:48:52 <dhellmann> ihrachyshka: ok
16:49:34 <ihrachyshka> bknudson, it looks like http://git.openstack.org/cgit/openstack/neutron/tree/etc/policy.json#n66
16:49:43 <dhellmann> ihrachyshka: encouraging projects to contribute features like these to the libraries is one reason we try to keep the public API so small :-)
16:50:16 <ihrachyshka> Dr. Evil at its best
16:50:33 <bknudson> policy.Check if that's not public.
16:50:36 <dhellmann> ihrachyshka: I prefer to think of it as Make Sharing Easier.
16:50:49 <bknudson> policy.RoleCheck
16:51:05 <ihrachyshka> bknudson, Check should be public, that one is in my 2 line patch
16:51:48 <dhellmann> we're getting close to the end of our time slot, and I'd like to go over the releases we have planned for this week
16:51:49 <dhellmann> #topic Releases for this week
16:51:50 <dhellmann> #link http://paste.openstack.org/show/185191/
16:51:56 <dhellmann> #info cliff has a couple of features needed by the OSC project
16:52:01 <dhellmann> #info oslo.config has a few bug fixes
16:52:05 <dhellmann> #info oslo.log has a bug-fix for nova
16:52:09 <dhellmann> #info oslo.policy has added a missing method as a bug fix
16:52:17 <dhellmann> #info oslosphinx's blueprint checker code has been sped up for some cases
16:52:35 <dhellmann> we may also have oslo.policy ready for a public release this week
16:52:48 <dhellmann> though no promises there :-)
16:53:33 <stevemar> dhellmann, heres to hoping that we do :)
16:53:41 <dhellmann> stevemar: ++
16:54:13 <dhellmann> harlowja_at_home there were several items in taskflow but I didn't have a chance to catch up with you before the meeting, do you have a release planned for this week?
16:54:29 <harlowja_at_home> i could
16:54:42 <harlowja_at_home> but lets see
16:55:18 <dhellmann> ok, sounds good
16:55:19 <dhellmann> #topic open discussion
16:55:34 <dhellmann> we have a few more minutes left, in case there is anything else we need to discuss?
16:55:44 <ihrachyshka> I have one! timeutils is not leap sec aware
16:55:44 <ihrachyshka> https://bugs.launchpad.net/oslo.utils/+bug/1427212
16:55:45 <openstack> Launchpad bug 1427212 in oslo.utils "timeutils is not leap second safe" [Undecided,New]
16:55:51 <ihrachyshka> and we have one in Juno
16:55:55 <ihrachyshka> June&
16:56:32 <ihrachyshka> though I suspect it means reimplementing the API not to rely on datetime :)
16:56:33 <dhellmann> oh, fun
16:56:58 <ihrachyshka> yeah, remember the last time we had a leap one? java crashing, ...
16:57:06 <ihrachyshka> we may now get into the party
16:57:08 <ihrachyshka> :)
16:57:39 <dhellmann> perhaps we should add a check for that particular value error as a special case to prevent it from propagating
16:58:24 <dhellmann> I had some questions about oslo.log migration today, so it would be nice to merge https://review.openstack.org/#/c/147312/ so we can refer folks to the documentation
16:58:29 <ihrachyshka> hm, interesting idea. but then what do you return?
16:59:03 <dhellmann> ihrachyshka: if the caller is expecting a datetime back, I'm not sure what we would do
16:59:21 <ihrachyshka> right, a new API would be needed
16:59:24 <dhellmann> wait until we can create a valid one, so the time stamp we give back is valid?
16:59:43 <ihrachyshka> we can close our eyes and live in happy ponny world with no leap secs and hope for the best :)
17:00:02 <ihrachyshka> dhellmann, unmarshell gets a value to convert, it can't adopt it (I guess)
17:00:03 <dhellmann> a new api seems like a hard sell to the users of the module -- is there a fix planned for python's stdlib?
17:00:13 * jungleboyj is picturing the perfect world from the Lego Movie.  :-)
17:00:22 <ihrachyshka> dhellmann, it's clearly stated in py docs datetime is not leap aware
17:00:34 <ihrachyshka> jungleboyj, EVERYTHING IS AWESOME, right
17:00:48 <dhellmann> our time is up
17:00:53 <dhellmann> thanks for another good meeting, team
17:00:54 <jungleboyj> Ahhhh ... Now it is stuck in my head!
17:00:58 <dhellmann> #endmeeting