16:01:13 <dims> #startmeeting oslo
16:01:13 <dims> courtesy ping for GheRivero, amotoki, amrith, bknudson, bnemec, dansmith, dhellmann, dougwig, e0ne, flaper87, garyk, harlowja, haypo,
16:01:14 <openstack> Meeting started Mon Feb  8 16:01:13 2016 UTC and is due to finish in 60 minutes.  The chair is dims. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:14 <dims> courtesy ping for ihrachyshka, jd__, jecarey, johnsom, jungleboyj, kgiusti, kragniz, lifeless, lintan, ozamiatin, redrobot, rpodolyaka, spamaps
16:01:14 <dims> courtesy ping for sergmelikyan, sreshetnyak, sileht, sreshetnyak, stevemar, therve, thinrichs, toabctl, viktors, zhiyan, zzzeek, gcb
16:01:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:16 <dims> courtesy ping for dukhlov, lxsli, rbradfor, mikal, nakato, tcammann1, browne,
16:01:18 <e0ne> hi
16:01:19 <openstack> The meeting name has been set to 'oslo'
16:01:20 <ozamiatin> o/
16:01:22 <johnsom> o/
16:01:23 <harlowja_at_home> yo yo
16:01:23 <stevemar> o/
16:01:28 <kgiusti> o/
16:01:28 <ihrachys> o/
16:01:31 <jecarey> o/
16:01:43 <rbradfor> o/
16:01:47 <rpodolyaka> o/
16:01:57 <dims> hi e0ne johnsom harlowja_at_home stevemar kgiusti ihrachys jecarey rbradfor rpodolyaka
16:02:06 <harlowja_at_home> howdy
16:02:06 <dhellmann> o/
16:02:10 <kgiusti> hey there!
16:02:29 <dims> let's get started :)
16:02:31 <toabctl> hi
16:02:36 <dims> #topic Red flags for/from liaisons
16:02:38 <dukhlov> hi
16:02:53 <johnsom> Nothing much.   We would like to get the taskflow version bumped: https://review.openstack.org/#/c/276549/2
16:03:13 <harlowja_at_home> +1 :)
16:03:22 <ihrachys> neutron here: we may need new oslo.versionedobjects library with a new registry fixture so that we can remove some code that accesses internal attributes from the library.
16:03:24 <dims> johnsom : ack
16:04:02 <ihrachys> also, we have a question on the library testing interface, but I guess we better leave it to open discussion
16:04:06 <dims> ihrachys : code is already in?
16:04:09 <ihrachys> dims: yes
16:04:10 <dims> ihrachys ok
16:04:18 <stevemar> dims: nothing from keystone (where's bknudson_?)
16:04:32 <dims> thanks stevemar
16:04:36 <dims> #topic Releases for Mitaka
16:04:38 <dims> #link https://review.openstack.org/#/c/277212/ - Mega Release
16:04:38 <dims> #link https://review.openstack.org/#/c/277203/ - Oslo privsep 1.0.0
16:04:40 <dims> #link https://review.openstack.org/#/c/274746/ - Oslo Config
16:04:46 <jungleboyj> o/
16:04:57 <dims> need reviews on those please. specifically look at the list-changes job
16:05:13 <dims> am holding back the oslo.db - https://review.openstack.org/#/c/277222/
16:05:30 <dims> as we saw some breaks with InvalidSortKey that rpodolyaka helped fix
16:05:31 <stevemar> \o/ for oslo.config release that has the generator fix
16:05:34 <harlowja_at_home> #link http://logs.openstack.org/12/277212/4/check/gate-releases-tox-list-changes/386a7b5/console.html
16:05:43 <jungleboyj> dims: No red flags from Cinder right now, btw.
16:06:02 <dims> stevemar : thanks for your patience, we were waiting on a bug that cropped up for that release
16:06:06 <dims> jungleboyj : thanks
16:06:24 <stevemar> dims: np, it wasn't super critical, just for the sample config
16:06:37 <jungleboyj> dims: Welcome.
16:06:37 <haypo> for oslo.db, the regression is fixed by https://review.openstack.org/#/c/277328/
16:06:45 <dims> stevemar : i pointed out the keystone proposed update setup to Nova, they may want to do the same
16:06:51 <haypo> dims: oh, you didn't approve the change?
16:06:58 <stevemar> dims: oh nice
16:07:03 <jungleboyj> stevemar: What was the generator fix?
16:07:03 <haypo> dims: i can approve it if you want (we know have a fix for heat)
16:07:07 <dims> haypo : done
16:07:34 <stevemar> dims: it acts funny sometimes, but it does the job
16:07:42 <stevemar> jungleboyj: options were out of order
16:07:52 <dims> so for others, the idea is that keystone team does check in their sample keystone.conf and they have a bot that generates a fresh keystone.conf and compares it and proposes reviews
16:08:04 <dims> nova does not have a sample config checked in
16:08:12 <jungleboyj> stevemar: Ah, good.
16:08:18 <dims> so the bot essentially goes berserk :)
16:08:48 <dims> with the new oslo.config hopefully it will not keep proposing updates because things go out of order
16:08:58 <dims> i'd recommend this setup for other projects as well
16:09:12 <rbradfor> dims, I second that
16:09:20 <dims> as it helps when libraries that you use change their config options
16:09:29 <dims> you get an immediate feedback
16:09:40 <stevemar> dims and others, there were a few reasons why we did it in the first place: 1) different ptaches would propose changes to the sample config and break each other, and 2) or they would forget and someone would eventually have to propose this patch (catch new oslo config options)
16:10:11 <dhellmann> stevemar : you could also use http://docs.openstack.org/developer/oslo.config/sphinxconfiggen.html to generate the sample as you build your docs
16:10:53 <dims> dhellmann : others, example proposal from bot - https://review.openstack.org/#/c/269479/
16:11:16 <dhellmann> yeah, the next release of the lib should fix the ordering issue for them, thanks to rbradfor's patch
16:11:31 <dims> thanks rbradfor
16:11:35 <stevemar> dims: yeah, that's the one that shows it all out of whack
16:11:38 <jungleboyj> dims: I have a team member that was hoping to talk about all the different ways that configs are being handled.
16:11:42 <stevemar> rbradfor: thanks! :D
16:11:55 <rbradfor> stevemar, np
16:11:59 <jungleboyj> dims: Hopefully in Austin and try to bring some sanity to everything.
16:12:21 <dims> jungleboyj : do we need to wait till austin? :)
16:12:38 <dims> i'd prefer to do prep work before if possible
16:12:56 <jungleboyj> dims: Well, don't have to but it would be nice to get together and talk about it.
16:13:08 <jungleboyj> speaking of the devil, here is diablo_rojo now.
16:13:27 <dhellmann> jungleboyj : is this the person who proposed a panel session for the summit on the ML a while back?
16:13:32 <dims> diablo_rojo : will you be around for open discussion in a few mins?
16:13:33 * dhellmann can't remember the name
16:13:43 <jungleboyj> dhellmann: Yes.
16:13:46 <harlowja_at_home> literally might be the devil, lol
16:14:03 <dhellmann> jungleboyj : ok, good, I was worried we had 2 sets of ideas floating around :-)
16:14:17 <dims> k let's hold on to that till open discussion :)
16:14:19 <dims> #topic Using our CI instead of travis
16:14:19 <dims> #link http://logs.openstack.org/74/277074/1/experimental/periodic-nova-py27-with-oslo-master/f291087/
16:14:20 <dims> #link https://review.openstack.org/#/c/277086/
16:14:22 <jungleboyj> dhellmann: No, diablo_rojo is Kendall Nelson on my team.  Can tlak later.
16:14:36 <dhellmann> jungleboyj : ++
16:14:57 <diablo_rojo> dims:  Yes I will be around
16:15:02 <dims> so the idea here is for me/us to stop using the https://travis-ci.org/dims/ setup for identifying py27/py34 unit tests breaks
16:15:17 <diablo_rojo> dhellmann: Yep thats me :)
16:15:18 <dims> turn those into periodic jobs which anyone can look at
16:15:31 <dims> if you see the links above, there are project-config reviews
16:15:32 <harlowja_at_home> ya!
16:15:45 <dhellmann> dims : where does the output of the jobs go?
16:15:47 <bknudson_> what are the options for jobs? Is periodic the only option?
16:15:50 <dims> anyone from neutron here? need your blessing on https://review.openstack.org/#/c/277086/
16:15:52 <dhellmann> how would I find the logs?
16:15:53 <bknudson_> maybe experimental job
16:15:56 <dims> dhellmann : we'll get emails
16:16:00 <dhellmann> ok
16:16:19 <dims> bknudson_ : currently they are setup as experimental so i can kick tires, but will be pure periodic jobs
16:16:42 <dims> bknudson_ : till next rev of gerrit API where a trigger will be available for periodic jobs
16:16:55 <bknudson_> ok
16:17:46 <dims> i've talked to jeblair, fungi and others about needing a way to run these especially to see if we fixed a problem after we identify one
16:18:19 <fungi> there are other systems which could benefit from using this as an example too
16:18:44 <dims> yes, thanks fungi
16:19:06 <fungi> i know we've been wanting for a while to be able to run equivalents of various projects' jobs for constraints update proposals, for example
16:19:08 <dims> any concerns here? on anteaya 's suggestion, i'll drop an email to -dev as well
16:19:28 <dhellmann> this is a huge improvement over running the tests by hand
16:19:30 <fungi> and teh challenge around that is basically the same
16:19:42 <bknudson_> maybe we could use it for keystone so we stop breaking things
16:20:00 * fungi loves it when people stop breaking things
16:20:11 <dhellmann> bknudson_ : yep, eventually it would be good to have this in all libraries
16:20:20 <dims> another problem here is where to go look for the results (aggregate), so will setup some logstash/grafana/graphite queries/links
16:20:27 <dims> fungi : right? ^^
16:20:30 <dhellmann> I thought we might want to look at triggering similar jobs when a release is requested
16:20:56 <dims> bknudson_ : https://review.openstack.org/#/c/277086/ has keystone listed
16:20:58 <bknudson_> we'd like to know before the release
16:21:14 <fungi> dims: yeah, you can use those various systems for short or long term trending depending on what you're looking for
16:21:15 <dhellmann> bknudson_ : right, they would run in the check queue for the release request patch
16:22:00 <dims> cool, anyone interested, please help me move this forward :)
16:22:08 <fungi> dims: though the discoverability issue we have is mostly on periodic and post jobs. for check/gate jobs we report onto gerrit changes
16:22:16 <dims> fungi : right
16:22:40 <dims> #topic ihrachys -  library testing interface
16:22:44 <dims> ihrachys : all yours
16:22:48 <dims> what's up?
16:23:40 <dims> ok let's open it up then :)
16:23:41 <dims> #topic Open discussion
16:23:48 <ihrachys> mm, sorry
16:24:07 <ihrachys> so in neutron, we started to implement some custom oslo.versionedobjects fields
16:24:22 <ihrachys> #link https://review.openstack.org/273517
16:24:28 <bknudson_> why not put them in oslo.versionedobjects?
16:24:34 <ihrachys> and obviously we want to test them
16:24:34 <ihrachys> bknudson_: it's neutron only
16:25:00 <dims> bknudson_ : hang on till we get a full problem statement :)
16:25:16 <ihrachys> initial version of the patch was basing the test class on test_fields from oslo library
16:25:18 <ihrachys> #link https://review.openstack.org/#/c/273517/2/neutron/tests/unit/objects/test_common_types.py
16:25:29 <ihrachys> but I expressed concern that the test class is not part of library interface
16:25:40 <dhellmann> yeah, the tests subpackage is not part of the API most of the time
16:25:41 <ihrachys> and hence we need to duplicate it in our tree
16:25:49 <bknudson_> move it to the public interface
16:25:53 <ihrachys> and that's what we have in latest version
16:25:59 <dhellmann> the usual thing to do is create a fixtures module that is part of the public API
16:26:07 <ihrachys> but we were wondering whether it may be useful to have some test class like that as public
16:26:14 <ihrachys> like oslo.db provides some test classes for projects
16:26:14 <dhellmann> so you'd update oslo.vo to use the fixtures, and then on the next release you could use them
16:26:22 <dims> dansmith, around?
16:26:34 <dims> +1 to dhellmann 's suggestion
16:26:36 <dhellmann> ihrachys : fixtures are ok, but not test base classes
16:26:49 <ihrachys> dhellmann: I think we are also interested in test cases from the class
16:27:00 <dhellmann> we have a policy for this: http://specs.openstack.org/openstack/oslo-specs/specs/policy/test-tools.html
16:27:28 <ihrachys> ok, in oslo.db we have that http://docs.openstack.org/developer/oslo.db/api/oslo_db.sqlalchemy.test_migrations.html
16:28:04 <dhellmann> yeah, I think that existed before the policy
16:28:28 <bknudson_> is there some concern about making functionality for tests part of the public api?
16:28:34 <ihrachys> ok, got it. we'll see whether there is anything worth a fixture beyond test cases then
16:28:39 <dhellmann> basically, it becomes extremely messy to debug multiple inheritance in test classes
16:28:53 <dhellmann> that's why fixtures work out better
16:29:06 <dhellmann> but if you can't convert what you have into a proper fixture, we should revisit
16:29:31 <bknudson_> what's the oslo code that's being made public?
16:29:31 <ihrachys> thanks. we'll take it from here.
16:29:31 <dhellmann> bknudson_ : I interpreted the question as "how should we handle this"
16:29:34 <dims> sounds like a good plan of action
16:29:53 <dims> bknudson_ : test_fields from o.vo
16:30:49 <dims> dhellmann : can you please remind us about the library freeze dates?
16:30:57 <harlowja_at_home> #link https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/tests/test_fields.py
16:31:09 <dhellmann> #link the schedule http://releases.openstack.org/mitaka/schedule.html
16:31:28 <dhellmann> final releases for non-client libraries is R-6, which is Feb 22-26
16:31:28 <dims> email http://markmail.org/message/3feg5oajsg3q6rmk
16:31:59 <dhellmann> speaking of, I have some enhancements and fixes for oslo.config's sphinx integration that I would like to get into the release: https://review.openstack.org/#/q/project:openstack/oslo.config+topic:unique-config-section-headers
16:32:33 <dims> so, please look at reviews in progress, global requirement minimums and upper constraints things you need
16:32:34 <dhellmann> some of those are needed for the glance docs
16:32:50 <dims> dhellmann : ack. will review
16:33:47 <dims> any other things to discuss from any one?
16:33:59 <dims> going once
16:34:11 <jungleboyj> diablo_rojo: ^^^
16:34:20 <dims> diablo_rojo : ping :)
16:34:35 <diablo_rojo> dims:  Hello :)
16:34:56 <dims> the floor is yours :)
16:34:57 <diablo_rojo> So I missed the first part of the conversation but jungleboyj filled me in a bit about options changes
16:34:59 <diablo_rojo> ?
16:35:41 <dims> diablo_rojo : y we were talking about how keystone maintains a keystone.conf.sample in its tree by using a bot
16:35:43 <jungleboyj> Sorry, also in another conference call.
16:35:50 <diablo_rojo> I just was wondering what that entailed and if that may be a good thing to add to the design summit talk about the generation of sample conf files for all projects.
16:36:25 <harlowja_at_home> seems like a good thing to ad
16:36:28 <harlowja_at_home> *add
16:36:29 <diablo_rojo> dims:  I had talked to Morgain Fainberg and he said he would talk a bit about keystones approach if my proposed session gets accepted.
16:36:30 <dims> diablo_rojo : just an entry in a project-config repo. quite easy, it's all setup. only project using it is keystone, so just need to enable for other projects
16:37:02 <dims> diablo_rojo : it will work just like the bot that proposes requirements changes
16:37:10 <diablo_rojo> dims: That sounds wonderful :)
16:37:13 <stevemar> dims: glad you like it :)
16:37:18 <dhellmann> dims : I guess that means we've given up on encouraging projects to generate those files rather than checking them in?
16:37:58 <diablo_rojo> dhellmann: checking them in was hard for Cinder with all the drivers in tree adding options and never updating the file :/
16:37:59 <jungleboyj> stevemar: So instead of failing check runs it just proposes updates ?
16:38:03 <dims> dhellmann : i think of it as keeping a well known blessed master version
16:38:10 <stevemar> dhellmann: the checked in versions are really handy to show people options :\
16:38:17 <stevemar> jungleboyj: yep, same as the requirements bot
16:38:29 <dims> jungleboyj : diablo_rojo : example https://review.openstack.org/#/c/269479/
16:38:35 <jungleboyj> stevemar: Interesting.
16:38:38 <diablo_rojo> dims: Thanks :)
16:38:53 <diablo_rojo> COOL
16:38:58 <dhellmann> stevemar : do you just want a link to a file to share? http://docs.openstack.org/developer/oslo.config/sphinxconfiggen.html
16:39:05 <diablo_rojo> jungleboyj: I think Cinder needs this :)
16:39:34 <stevemar> dhellmann: haven't looked into that yet, is it new?
16:39:43 <dims> diablo_rojo : jungleboyj : http://codesearch.openstack.org/?q=propose-config-updates
16:39:47 <dhellmann> stevemar : we added that for this purpose in liberty, and didn't advertise it well
16:39:47 <stevemar> dhellmann: what was the issue with having the sample checked in?
16:39:51 <jungleboyj> diablo_rojo: Interesting.  We will need to look at that and see what the rest of the team things.
16:39:55 <jungleboyj> *thinks
16:40:07 <dhellmann> stevemar : your "master" file is out of date as soon as anyone changes options in a library
16:40:09 <diablo_rojo> jungleboyj: I can put it on the weekly agenda if you'd like
16:40:18 <jungleboyj> diablo_rojo: ++
16:40:24 <dims> dhellmann : hence the daily update from the bot
16:40:49 <dims> so at least you know that the rug was pulled from under you
16:40:58 * dhellmann shrugs
16:40:59 <diablo_rojo> dhellmann: So a while back in the ML, you had made comments about the way Cinder was setting up entry_points? I put a patch up to try to address one of them and I was wondering if you could take a look?
16:41:03 <stevemar> dhellmann: that's why the proposal bot type job was created
16:41:07 <dhellmann> diablo_rojo : link?
16:41:18 <diablo_rojo> dhellmann: https://review.openstack.org/#/c/274810/
16:41:20 <dhellmann> stevemar : if you want to check compiled files into the repo, I can't stop you. I just think it's a bad idea.
16:41:36 <dhellmann> diablo_rojo : it's on my queue
16:41:50 <stevemar> dhellmann: i think we're trying to solve the problem?
16:42:03 <diablo_rojo> dhellmann: It just removes the keystonemiddleware endpoint we had in setup.cfg. Thanks.
16:42:41 <rbradfor> diablo_rojo, there are also some other inconsistencies in the entry points,  _ and . syntax in oslo's. I recall I had issues using these namespaces.
16:42:49 <dhellmann> stevemar : as long as you're not blocking other patches because a validator doesn't pass when the file is out of date, doing it won't make development more difficult. I just thought we all agreed to stop doing it entirely, so I'm surprised to learn about this new bot thing.
16:42:49 <stevemar> dhellmann: i'l look at sphinxconfgen soon, you've yet to steer me wrong :)
16:44:16 <rbradfor> stevemar, we have started to try and use both the config file to generate docs of all options on one page, and then also have a sample config in the docs to reference that matches
16:44:31 <diablo_rojo> rbradfor: Oh yeah? Everything seems to work currently- better than it did even than before when we used oslo-incubator for this stuff. I could be missing something though.
16:45:12 <stevemar> rbradfor: dhellmann is there a project that is currently using this?
16:45:38 <diablo_rojo> stevemar: Keystone is
16:45:41 <rbradfor> stevemar, glance I believe
16:45:59 <stevemar> diablo_rojo: i meant sphinxconfiggen
16:46:01 <dhellmann> stevemar : glance is using the other form of sphinx integration, with pretty output instead of a sample file
16:46:06 <dhellmann> http://docs.openstack.org/developer/glance/opts.html
16:46:12 <diablo_rojo> stevemar: Oh. My mistake. Sorry!
16:46:47 <stevemar> dhellmann: arright, i'll take a look, i'd prefer it in docs over checked in, didn't know this existed
16:46:59 <dhellmann> I have a patch up to improve on that, but it depends on some of the unreleased and unmerged changes I mentioned earlier: https://review.openstack.org/#/c/276931/
16:47:06 <dhellmann> I can update that to also use the sample file generator
16:47:16 <bknudson_> http://docs.openstack.org/developer/glance/opts.html belongs in end-user docs
16:47:25 <dhellmann> stevemar : yeah, like I said, we didn't do a great job of advertising it
16:47:34 <dhellmann> bknudson_ : it will, eventually
16:47:45 <dhellmann> I also need to talk to the docs team about using this for the config guide
16:47:58 <dims> cool. so we all have things to look over :)
16:48:00 <dhellmann> that build will be interesting, since the inputs come from source files in a lot of other projects
16:48:09 <dhellmann> at this point it's something for next cycle
16:48:10 <stevemar> dhellmann: alright, i'll poke around at this then
16:48:15 <bknudson_> http://docs.openstack.org/liberty/config-reference/content/keystone-configuration-file.html -- not pretty
16:48:36 <stevemar> bknudson_: yeah :\
16:48:39 <dhellmann> bknudson_ : yeah, now that they've converted the new guides to rst they'll be able to use these extensions
16:49:08 <bknudson_> great
16:49:13 <rbradfor> bknudson_, definitely not when also looking at for other projects in the same doc
16:49:22 * SpamapS is here now
16:49:28 <dims> Hey SpamapS
16:49:42 <SpamapS> sorry I've been so absent. How are the tooz drivers going?
16:49:59 <stevemar> dhellmann: looks like we were trying to solve the same issue, and didn't know each other mechanism existed :)
16:50:04 * dims pokes harlowja_at_home
16:50:09 <harlowja_at_home> pokes back
16:50:16 <stevemar> hmm, that definitely isn't openstack-like
16:50:31 <dims> jd__ : harlowja_at_home : what's up with tooz ( SpamapS is asking )
16:50:40 <dims> stevemar : haha
16:50:43 <harlowja_at_home> SpamapS, vilobh been busy with internal stuff, but consul almost there @ https://review.openstack.org/#/c/245362/
16:50:48 <jd__> it's cool!
16:51:10 <SpamapS> harlowja_at_home: sweet. We're using consul heavily in the cloud that has distracted me from tooz, and I was like "oh snap I want that driver now" ;-)
16:51:16 <harlowja_at_home> https://review.openstack.org/#/c/266015/ also makes etcd use compare-and-delete
16:51:30 <harlowja_at_home> SpamapS, i'll bug vilobh when i see him today :-P
16:51:41 <dhellmann> stevemar : yeah
16:52:01 <jd__> i'm working on test setup simplification with overtest too https://github.com/jd/overtest
16:52:10 <harlowja_at_home> SpamapS, what are u using consul heavily for?
16:52:23 <SpamapS> harlowja_at_home: service discovery
16:52:28 * dims we have 8 mins left - warning
16:52:40 <SpamapS> healthchecks -> DNS -> loadbalancer/mysql/rabbitmq
16:52:44 <harlowja_at_home> k
16:52:50 <SpamapS> It's quite nice for that.
16:52:54 <harlowja_at_home> right
16:53:29 <harlowja_at_home> IBM ok with all that go code?? ;)
16:53:39 <SpamapS> we're not writing it. ;)
16:54:13 <SpamapS> and I mean, I find any language decision hard to criticise whenever I see import eventlet ... ;)
16:54:30 <harlowja_at_home> but its green, green must be good, lol
16:54:35 <harlowja_at_home> *makes things green, lol
16:54:46 <dims> :)
16:54:55 <harlowja_at_home> eventlet_organics
16:54:58 <harlowja_at_home> ha
16:55:01 <dims> so let's wrap up for today then. thanks a lot everyone
16:55:06 <SpamapS> eventlet is definitely GMO threading
16:55:13 <harlowja_at_home> lol
16:55:20 <dims> haha
16:55:26 <SpamapS> harlowja_at_home: ty for the update
16:55:30 <harlowja_at_home> np
16:55:43 <dims> #endmeeting