16:00:13 <harlowja_at_home> #startmeeting oslo
16:00:14 <openstack> Meeting started Mon Jun 13 16:00:13 2016 UTC and is due to finish in 60 minutes.  The chair is harlowja_at_home. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:18 <openstack> The meeting name has been set to 'oslo'
16:00:20 <harlowja_at_home> ding ding
16:00:20 <harlowja_at_home> lol
16:00:27 <harlowja_at_home> courtesy ping for GheRivero, amotoki, amrith, bknudson, bnemec, dansmith, dhellmann, dims, dougwig, e0ne, flaper87, garyk, haypo,
16:00:27 <harlowja_at_home> courtesy ping for ihrachyshka, jd__, jecarey, johnsom, jungleboyj, kgiusti, kragniz, lifeless, lintan, ozamiatin, redrobot, rpodolyaka, spamaps
16:00:27 <harlowja_at_home> courtesy ping for sergmelikyan, sreshetnyak, sileht, sreshetnyak, stevemar, therve, thinrichs, toabctl, viktors, zhiyan, zzzeek, gcb, Nakato
16:00:30 <harlowja_at_home> ding ding ding
16:00:31 <amrith> hello
16:00:32 <harlowja_at_home> meeting time ding ding
16:00:33 <harlowja_at_home> lol
16:00:34 <dhellmann> o/
16:00:38 <ozamiatin> o/
16:00:40 <kgiusti> o/
16:00:48 <harlowja_at_home> ding ding a ling
16:01:04 <rbradfor> o/
16:01:09 <harlowja_at_home> \o/
16:01:12 <harlowja_at_home> |
16:01:19 <harlowja_at_home> /\
16:01:20 <amrith> harlowja_at_home, did you see my ping from earlier this morning?
16:01:27 <jecarey> 0/
16:01:30 <harlowja_at_home> amrith, probably at the other computer, so not yet :-P
16:01:47 <amrith> harlowja, at the OSLO meeting today I'd like to raise the issue of isotime() that I'd summarized in an email to the ML (http://markmail.org/message/xosf5h7gvhqdwtz7) and some code that is in https://review.openstack.org/#/c/326655/
16:01:58 <amrith> everyone's favorite subject :)
16:02:03 <harlowja_at_home> :-/ fun fun, ha
16:02:21 <ihrachys> o/
16:02:34 <harlowja_at_home> #topic Red flags for/from liaisons
16:03:03 <harlowja_at_home> anything to say is busted (besides isotime, ha)
16:03:35 <amrith> No red flags from trove excecpt for isotime :)
16:03:51 <harlowja_at_home> ;)
16:04:01 <oshykhkerimov> no red flags from murano
16:04:10 <harlowja_at_home> cool
16:04:27 <ihrachys> nothing on neutron side. we had octavia stable/liberty breakage due to taskflow changes, but that was solved by a backports.
16:05:07 <harlowja_at_home> yup yup, think octavia folks had that one also, bug that new taskflow change made visible (from my understanding)
16:05:16 <harlowja_at_home> (bug in neutron/octavia afaik)
16:05:27 <ihrachys> yeah
16:05:41 <ihrachys> I think it's octavia bug, just surfaced by taskflow
16:05:51 <harlowja_at_home> oh u said neutron octavia, not a different one, same bug, lol
16:05:53 <ihrachys> but since I did not know much about either, I reached to oslo :)
16:05:56 <harlowja_at_home> its early, i need more cofeee
16:06:26 <harlowja_at_home> ya, thx ihrachys hopefully all cleared up
16:07:43 <harlowja_at_home> #topic New periodic jobs
16:07:58 <harlowja_at_home> So a few new projects are now on   http://status.openstack.org/openstack-health/#/?groupKey=build_name&resolutionKey=hour&searchProject=-with-oslo
16:08:16 <harlowja_at_home> I was thinking that other projects that use oslo (murano oshykhkerimov might want to be in that?)
16:09:12 * ihrachys is confused by that website
16:09:14 <harlowja_at_home> if people feel its useful; https://review.openstack.org/#/c/320151/ is what
16:09:19 <harlowja_at_home> *is what's needed to do this
16:09:28 <amrith> so what does that project do?
16:09:33 <ihrachys> so neutron jobs are claimed to be 39% failing
16:09:38 <ihrachys> but when I drill down, it's all green
16:09:41 <harlowja_at_home> ihrachys, ya, click the link
16:10:02 <ihrachys> harlowja_at_home: which one?
16:10:03 <harlowja_at_home> the history i think just takes a while to clear
16:10:10 <harlowja_at_home> *never mind u drilled down
16:10:23 <harlowja_at_home> i think it keeps a history that isn't in the drill down
16:10:27 <ihrachys> so you mean it's all good now?
16:10:30 <harlowja_at_home> ya
16:10:30 <ihrachys> ok
16:10:40 <ihrachys> we also have the job on grafana dashboard we have for neutron
16:10:44 <ihrachys> pretty useful
16:10:46 <harlowja_at_home> cool
16:10:57 <ihrachys> the board: http://grafana.openstack.org/dashboard/db/neutron-failure-rate
16:11:01 <harlowja_at_home> amrith, so what it does is run the project using the master of oslo libraries
16:11:03 <ihrachys> it's in "Periodic Jobs" dash
16:11:43 <amrith> hmmm
16:11:45 <harlowja_at_home> typically amrith the master of oslo libraries are not as well tested in projects (there is gating on oslo lib commits, but its a little more limited in its 'finding all the problems')
16:12:08 <harlowja_at_home> so this periodic job set helps the oslo folks know about issues that may pop up before a oslo lib release happens
16:12:14 <harlowja_at_home> so we can fix that, or undo a commit or ..
16:12:17 <amrith> can third party CI's leverage this capability as well
16:12:27 <harlowja_at_home> unsure
16:12:46 * harlowja_at_home doesn't see a trove one on that dashboard, probably would be useful
16:12:55 <amrith> so is the beneficiary of this the project (trove) or oslo?
16:13:00 <amrith> yes, trove isn't there
16:13:01 <harlowja_at_home> both?
16:13:07 <harlowja_at_home> but more oslo i think amrith
16:13:38 <rbradfor> it would benefit projects like trove as it's being proactive on changes before they are officially released.
16:13:59 <oshykhkerimov> harlowja_at_home: if you are talking about adding murano periodic jobs - I can for sure discuss it with murano team
16:14:10 <amrith> but looking at the review you suggested, 320151, it looks like it will add another job to the project gate, yes?
16:14:52 <harlowja_at_home> not the project gate afaik, just this periodic one
16:15:09 <harlowja_at_home> there is some voodoo that happens under the covers that dims probably knows more that ensures its not in the projects own gate
16:15:23 <harlowja_at_home> we do like the voodoo here
16:15:24 <harlowja_at_home> lol
16:15:47 <amrith> yes, looking at some octavia commits, I don't see them running the jobs
16:15:52 <harlowja_at_home> right
16:16:26 <amrith> it must be something pushing a dummy change to the project and running jsut this test (maybe)
16:16:28 <amrith> neat
16:16:43 <harlowja_at_home> voodoo i tell u (only dims knows the voodoo, lol)
16:17:04 * harlowja_at_home i should learn the voodoo sometime
16:17:50 <harlowja_at_home> anyway, feel free to clone https://review.openstack.org/#/c/320151/ for trove and that will help detect any possible oslo libs doing things badly (or other)
16:18:14 <amrith> out of curiousity, why doesn't the oslo team just clone it for all projects that use oslo?
16:18:22 <amrith> it won't impact the projects gate/check jobs
16:18:33 <amrith> so it shouldn't be an issue for all projects, yes?
16:19:00 <harlowja_at_home> it's a good question and i should ask about that when i can get in contact with dims
16:19:21 <harlowja_at_home> unsure if it/why that wasn't done from the start
16:19:23 <amrith> sorry, dims is busy. he's attending the annual conference of voodoo practitioners.
16:19:38 <harlowja_at_home> ya, he's doing some exorcism or something
16:19:41 <harlowja_at_home> afaik
16:19:57 <bknudson> where to stick the pin in the voodoo doll
16:20:19 <harlowja_at_home> ya, i heard thats the seminar at the conference
16:20:56 <harlowja_at_home> amrith, i'll followup with u on those questions
16:21:08 <harlowja_at_home> #topic Newton releases
16:21:23 <harlowja_at_home> so anything in need of a critical release?
16:21:45 <harlowja_at_home> otherwise i'll just get a release-all-the-changes out today (or tommorow if i don't get around to it today)
16:22:13 <amrith> harlowja_at_home, please see https://review.openstack.org/#/c/329086/
16:22:22 <harlowja_at_home> amrith, thx
16:23:27 <harlowja_at_home> ok, assuming no critical releases needed then, or bug fixes or all that (which is fine)
16:24:14 <harlowja_at_home> #topic Exorcism of oslo-incubator
16:24:24 <harlowja_at_home> back on that exorcism topic
16:24:34 <harlowja_at_home> https://github.com/openstack/oslo-incubator is officially gone
16:25:06 <harlowja_at_home> <all clap>
16:25:06 <harlowja_at_home> lol
16:25:21 * harlowja_at_home why nobody clapping
16:25:41 <bknudson> great that it's finally gone.
16:25:41 * rbradfor claps
16:25:44 <amrith> it's an exorcism; no one claps at an exorcism
16:25:49 <harlowja_at_home> amrith, lol
16:25:55 <harlowja_at_home> i didn't take the seminar
16:26:05 <amrith> am I the only one who's actually been to an exorcism?
16:26:10 <harlowja_at_home> errrr
16:26:20 <harlowja_at_home> i think so?
16:26:26 <rbradfor> thanks for harlowja_at_home and gcb that +1 a number of incubator cleanups in projects that prompted them to getting merged
16:26:52 <harlowja_at_home> rbradfor, the shutdown of this should help, in fact i'll send out a mailing list note for this, whats your link again
16:27:02 <harlowja_at_home> i'll include that, now that its like dead-dead that might help get those changes in
16:27:18 <rbradfor> https://etherpad.openstack.org/p/oslo-libraries-adoption
16:27:20 <harlowja_at_home> thx
16:28:17 <harlowja_at_home> cool, i'll write that up shortly and get that out
16:28:47 <harlowja_at_home> #topic Time to talk about isotime
16:28:59 <amrith> hmm, who would want to do that?
16:29:02 <harlowja_at_home> amrith, sooooo, rolls the mic to amrith
16:29:11 <amrith> thanks harlowja_at_home :)
16:29:13 <amrith> #link http://openstack.markmail.org/thread/xosf5h7gvhqdwtz7
16:29:20 <amrith> I sent this email out to the ML some days ago
16:29:30 <amrith> in particular, I'd like to get the following (here)
16:29:44 <amrith> 1. reviews of https://review.openstack.org/#/c/326655/1/trove/common/timeutils.py by the folks here
16:30:00 <amrith> 2. some opinions on whether this code (which I've proposed for Trove) can't make it back into oslo
16:30:04 <harlowja_at_home> zulu time ?
16:30:08 <amrith> yes
16:30:09 <harlowja_at_home> interesting, lol
16:30:21 <amrith> so the issue(s) as I see them are this
16:30:22 <harlowja_at_home> http://i1-news.softpedia-static.com/images/news2/Zulu-the-Most-Fearsome-Black-Warriors-2.jpg ?
16:30:37 <amrith> isotime was intentionally naive or should I say willfully naive
16:30:49 <amrith> and that caused some problems for people who passed it aware timestamps
16:31:00 <harlowja_at_home> k
16:31:05 <amrith> however, just using datetime.datetime.isoformat() meant that projects would have issues
16:31:14 * dims casts a spell at harlowja_at_home and amrith
16:31:28 <harlowja_at_home> i have magic resistance level 10
16:31:29 <harlowja_at_home> lol
16:31:30 <amrith> because the perfectly valid UTC times with the Z suffix were replaced by also valid +00:00 suffixes
16:31:52 <amrith> so people started cloning the deprecated code instead of following the advice to use datetime.datetime.isoformat()
16:31:57 <amrith> so I've tried to split the difference
16:32:10 <amrith> effectively, I've implemented isoformat() which produces the Z suffix for UTC time.
16:32:26 * amrith takes a break
16:32:33 <bknudson> it's better to go with an existing standard than to make your own. So if isoformat isn't broken then use that.
16:32:58 <amrith> well, isoformat isn't broken, and nor is this. it is not a new standard
16:33:06 <amrith> it is a valid iso8601 date format to have a Z suffix
16:33:12 <amrith> just as it is to have a +00:00 suffix
16:33:22 <dhellmann> it sounds like maybe we should have kept isotime, or at least replaced it with something to be consistent
16:33:32 <amrith> dhellmann, I agree
16:33:40 <bknudson> I think we should have a TC decision to pick a timestamp format
16:33:51 <bknudson> this should be an easy one.
16:33:52 <amrith> even if we had isoformat() and replaced +00:00 with Z on a flag, that'd have been a legacy format
16:34:01 * dhellmann shows bknudson the door
16:34:04 <amrith> well, iso8601 is a timestamp format
16:34:20 <bknudson> iso8601 is not specific enough
16:34:20 <rbradfor> amrith, if Z is a valid suffix has this been proposed as a fix to python datetime itsself.
16:34:26 <amrith> and isoformat() and the proposed isotime() are consistent with it
16:34:41 <amrith> rbradfor, there's nothing broken with python datetime
16:34:45 <dhellmann> this seems like one of those cases where we thought removing something "trivial" would be easy, but we didn't realize the effect it would have
16:34:47 <bknudson> probably 99% of all strings are consistent with iso8601
16:34:48 <amrith> so what would I propose to fix?
16:34:52 <dhellmann> perhaps we should just put it back
16:35:42 <amrith> bknudson, I disagree. iso8601 is specific that there are just 4 time formats that are valid if you want to specify a timezone
16:35:42 <amrith> <time>Z <time>[+-]hh:mm <time>[+-]hhmm <time>[+-]hh
16:35:43 <dhellmann> and then document why such a trivial function is actually useful, so we don't forget and try to delete it again
16:35:57 <bknudson> https://www.w3.org/TR/NOTE-datetime
16:36:26 <amrith> exactly; well, I got a copy of iso8601 :)
16:36:34 <bknudson> https://www.ietf.org/rfc/rfc3339.txt
16:37:45 <bknudson> https://www.w3.org/TR/NOTE-datetime also allows both Z and +-HH:MM
16:37:47 <amrith> so harlowja_at_home how would you like to proceed? I would at least like some reviews of the code in trove but would like you to consider alternative 2 that I proposed.
16:38:22 <harlowja_at_home> amrith, i'd like to get some eyes on https://review.openstack.org/#/c/326655/1/trove/common/timeutils.py
16:38:27 <harlowja_at_home> just for sanity
16:39:01 <amrith> harlowja_at_home, yes. I'd very much appreciate that.
16:39:01 <harlowja_at_home> and then, if my understanding of it's correct (this code could be the new code in oslo.utils that we suggest to use, since it appears to work in both ways)
16:39:23 <harlowja_at_home> then people won't copy around code, and therefore oslo folks would have to compromise about this
16:39:33 <bknudson> I think part of the problem is that we never identified in the Identity spec what the timestamp format is.
16:39:56 <dhellmann> harlowja_at_home : I agree.
16:39:56 <harlowja_at_home> bknudson, agreed, that doesn't help either (there wasn't a pick one or the other, but support both)
16:40:15 <harlowja_at_home> and isoformat is one way, the old code is another way, soooo == crap at that point
16:40:44 <harlowja_at_home> i just gotta carefully figure out isotime(tm=None, subsecond=False) in that  amrith code
16:41:05 <amrith> ok
16:41:56 <amrith> harlowja_at_home, the change I submitted in trove also has some unit tests that may help with that
16:42:11 <harlowja_at_home> cool
16:42:11 <harlowja_at_home> thx
16:42:16 <amrith> and if you find that I should augment the unittests, that would be welcome feedback as well.
16:42:20 <amrith> actually, all feedback is welcome
16:42:24 <amrith> this would be more welcome :)
16:42:31 * harlowja_at_home unleash the hounds
16:42:32 <harlowja_at_home> lol
16:43:11 <bknudson> I'd be fine if isotime made a comeback and openstack standardized on that as the way to do date time.
16:43:12 <harlowja_at_home> it would though be interesting to know why the upstream python didn't go with this kind of dual-format (since both seem to be valid) routine
16:43:31 <bknudson> I think we could specify that all timestamps are Z and do not use the offset.
16:43:34 <amrith> I see your comment harlowja_at_home; I can add a legacy=True option if this code goes ot OSLO
16:43:48 <amrith> bknudson, that won't work for non UTC times
16:43:51 <harlowja_at_home> amrith, ya, although maybe not 'legacy=True' but a better name?
16:43:57 <amrith> which are valid in many cases.
16:43:59 <bknudson> convert to UTC.
16:44:21 <bknudson> I don't see a use case for non-UTC in keystone.
16:44:23 <amrith> easy to say but OSLO/libraries shouldn't prescribe what time zone the projects should store dates/times in
16:44:36 <amrith> for example, access lists for databases are often specified in local time
16:44:41 <harlowja_at_home> ya, thus the TC thing that bknudson was thinking about (afaik); maybe nice if the TC says UTC all-the-places
16:44:56 <amrith> well harlowja_at_home that would be a shortsighted decision (IMHO)
16:45:11 <harlowja_at_home> k
16:45:12 <amrith> there are many cases where applications (in our case, OpenStack) may want or NEED to have localtime
16:45:24 <harlowja_at_home> convert at time of giving info back to user?
16:45:26 <bknudson> whose local time?
16:45:32 <amrith> local time of the user at all time
16:45:42 <amrith> you can get into my office building from 9am to 5pm
16:45:45 <bknudson> users lie
16:45:57 * harlowja_at_home thought that usually when u do a REST response u usually convert UTC -> local at that time (if u so desire)
16:46:09 <amrith> and 9am and 5pm are local times
16:46:13 <amrith> all year round
16:46:20 <amrith> specifying it in UTC won't work
16:46:26 <amrith> as that is different at different times of the year
16:46:39 <bknudson> you can't specify that in the formats provided either, btw.
16:46:44 <amrith> yes you CAN
16:46:55 <bknudson> how? they always specify an offset
16:47:00 <harlowja_at_home> hmmm, from what i remember at yahoo, they used to have a users info and the users timezone was in that info-record, but everything else at that point was UTC 'Z' time
16:47:12 <amrith> if you specify time as YYYY-MM-DDTHH:MM:SS-04:00 that's valid
16:47:16 <harlowja_at_home> (just a point of reference)
16:47:32 <bknudson> that doesn't work when the locale has summer time.
16:47:45 <bknudson> since it'll be -0400 one day and -0500 the next
16:47:52 <amrith> this is why python makes it up to the application to decide whether it is naive or aware
16:48:11 <amrith> if an application decides that it wants to treat unspecified timezone as local time
16:48:13 <amrith> then so be it
16:48:20 <amrith> it can add the local time zone adjustment at the time
16:48:27 <bknudson> I don't think we can be that loose in openstack.
16:48:32 <amrith> by forcing the specification of the Z at the end , you would defaeat that
16:48:39 <amrith> bknudson, why not?
16:48:42 <amrith> why is that openstack's call?
16:48:55 <amrith> or to be more precise; the "global openstack" call?
16:49:15 <bknudson> it can be up to your application what to do with dates / times that are timestamps
16:49:23 <bknudson> aren't timestamps
16:49:39 <bknudson> can't we have a standard format for timestamps?
16:49:51 <amrith> we can have a standard format for timestamps
16:49:58 <amrith> why not just use any one that is iso8601?
16:50:04 <bknudson> and then if you need a date / time for something else (like saying what times your office is open) then use whatever you want?
16:50:04 <amrith> and use standard functions to convert?
16:50:33 <dhellmann> if we're sending these formatted timestamps out through REST APIs, the consumer may not be a python app with the same flexibility
16:50:36 <amrith> harlowja_at_home, time-check; i'm happy to continue to discuss this (and it is useful for me) if you have the time.
16:50:51 <amrith> dhellmann, but iso8601 is the standard
16:50:51 <harlowja_at_home> ya, let's maybe continue this one a little later ;)
16:51:02 <amrith> and it is the same formatting in any language
16:51:05 <amrith> programming language
16:51:08 <amrith> it is a string
16:51:12 * amrith sees what harlowja_at_home just said
16:51:15 <dhellmann> amrith : I don't care which format we use, my point was we should just pick one.
16:51:33 <harlowja_at_home> amrith, but later by my localtime
16:51:35 <harlowja_at_home> lol
16:51:40 <amrith> dhellmann, would you accept iso8601 as the format or do you want to outlaw "Z" and use +00:00 instead.
16:51:56 <amrith> or use Z for +00:00?
16:52:06 <amrith> I guess that's the nub of the matter
16:52:07 <dhellmann> amrith : don't care.
16:52:19 <amrith> dhellmann, but you want one and not both
16:52:20 <amrith> yes?
16:52:28 <dhellmann> I want us to emit one, and be able to parse both.
16:52:33 <amrith> understood thanks.
16:52:44 <harlowja_at_home> ok ding
16:52:46 <amrith> dhellmann, bknudson let's discuss on #openstack-oslo later
16:52:46 <harlowja_at_home> lol
16:52:48 <amrith> thanks harlowja_at_home
16:52:50 <harlowja_at_home> ;)
16:52:55 <dhellmann> ok
16:53:04 <harlowja_at_home> #topic Stuck reviews (and/or specs)
16:53:15 <harlowja_at_home> just want to make sure folks have some time to raise any stuck things
16:53:29 <harlowja_at_home> bring your stuck stuff and we will unstuck it
16:53:49 <harlowja_at_home> (no superglue though)
16:54:22 <kgiusti> I'm piling lots of stuff - both specs and patches - on the AMQP 1 feature branch.
16:54:33 <harlowja_at_home> uhoh
16:54:47 <kgiusti> Not many of us have exposure to that driver, and the spec is pretty long too.
16:55:06 <kgiusti> But I'll take any feedback I can - even nits!
16:55:09 <harlowja_at_home> kk
16:55:19 <harlowja_at_home> i will see if i can look over some of that :)
16:55:22 <harlowja_at_home> and give u some nits
16:55:23 <harlowja_at_home> lol
16:55:38 <kgiusti> thanks!  can't get enough nits.
16:56:13 <harlowja_at_home> :)
16:56:17 <harlowja_at_home> i will not let u down
16:56:18 <harlowja_at_home> ha
16:56:41 <harlowja_at_home> #topic Open discussion
16:56:46 <harlowja_at_home> anything else from folks
16:57:08 * amrith looks around the room
16:57:13 <harlowja_at_home> if not, then we can talk about isotime in #openstack-oslo (or anything else that people want to talk about)
16:57:36 <harlowja_at_home> ok dokie, assuming not :)
16:57:45 <amrith> qsy #openstack-oslo
16:58:05 <harlowja_at_home> thanks for coming folks, always a lively bunch, ha
16:58:24 <amrith> thx harlowja_at_home
16:58:26 <rbradfor> harlowja_at_home, thanks for keeping us in line
16:58:26 <harlowja_at_home> np
16:58:28 <harlowja_at_home> lol
16:58:45 <harlowja_at_home> #endmeeting