14:00:34 <SergeyLukjanov> #startmeeting sahara
14:00:35 <openstack> Meeting started Thu Jan 28 14:00:34 2016 UTC and is due to finish in 60 minutes.  The chair is SergeyLukjanov. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:37 <NikitaKonovalov> o/
14:00:37 <egafford> o/
14:00:38 <SergeyLukjanov> #link https://wiki.openstack.org/wiki/Meetings/SaharaAgenda
14:00:39 <openstack> The meeting name has been set to 'sahara'
14:00:40 <tosky> hi
14:00:43 <AndreyPavlov> hi
14:00:46 <esikachev> hi
14:00:57 <SergeyLukjanov> elmiko saharaclient tests blocked by the patch to tempest that are fixing heat tests
14:00:59 <mionkin> hi
14:01:02 <huichun> hi
14:01:22 <SergeyLukjanov> sreshetnyak ping, could you please confirm?
14:01:33 <SergeyLukjanov> #topic News / updates
14:01:35 <elmiko> SergeyLukjanov: ack, i just saw the email (thanks tosky)
14:02:03 <SergeyLukjanov> sorry, just wake up, not yet read email
14:02:11 <tosky> maybe it's a different issue?
14:02:30 <tosky> the one I mentioned on the channel is about kilo branch
14:02:32 <elmiko> i've been doing a bunch of api v2 stuff, and working on releasing a security bug (have been researching the effects of the vulnerability), also looking at doing more bandit based cleanup.
14:02:34 <tosky> I put the item on the agenda
14:02:46 <AndreyPavlov> was working on bug with fields unset via client, on periodic tasks spec and cli import/export spec
14:02:47 <tmckay> I revived the discussion about substring searches on sahara objects ,,,
14:02:48 <elmiko> SergeyLukjanov: oh right, you meant about the patch i added yesterday for saharaclient?
14:03:09 <elmiko> tosky: saw that, thanks!
14:03:37 <esikachev> i am working on adding sahara-ci for stable releases of sahara in sahara-scenario repo
14:03:57 <egafford> Not much upstream progress on Sahara this week I fear; diving back in today.
14:04:13 <SergeyLukjanov> elmiko not sure, browser crashed and I lost all links ;)
14:04:27 <sreshetnyak> SergeyLukjanov: I think that tests blocked by problems with installing sahara
14:04:52 <SergeyLukjanov> sreshetnyak it's about stable branch I think, I'm talking about sahara client
14:05:11 <SergeyLukjanov> I've been unable to work on the summit proposals, will do it today for sure elmiko tmckay egafford
14:05:16 <vgridnev> I've been working on implementation of health checks, let's review the spec: https://review.openstack.org/#/c/270156/
14:05:21 <huichun> SergeyLukjanov:  has our scenario tests been ready?
14:05:32 <tmckay> SergeyLukjanov, ack, thanks
14:05:37 <elmiko> SergeyLukjanov: ok, for the sahara design sessions?
14:05:56 <SergeyLukjanov> esikachev is responsible for it, but I think that they a ready for the almost half year :)
14:06:07 <SergeyLukjanov> elmiko I mean main summit proposals
14:07:08 <elmiko> ah, gotcha
14:07:16 <NikitaKonovalov> I've been looking at the dashboard for possible minor improvements. Some changes on review
14:08:46 <egafford> SergeyLukjanov: I can write up an abstract for the general "state of Sahara" proposal. I'll post links to a draft for review later today.
14:09:18 <SergeyLukjanov> egafford okay, great
14:09:52 <SergeyLukjanov> I'll try to find prev. year proposals, if I'll be faster I'll share it with you :)
14:10:06 <SergeyLukjanov> #topic Separated launchpad for sahara-dashboard
14:10:24 <SergeyLukjanov> anything changed? any new objections or concerns?
14:10:46 <SergeyLukjanov> (current decision is to track them in sahara project)
14:11:20 <NikitaKonovalov> no changes that I've noticed
14:11:45 <elmiko> we did have a question in channel about where to log dashboard bugs, i just directed them towards the sahara launchpad and asked that they put "[UI]" in the subject
14:12:29 <tosky> elmiko: and a tag too
14:12:44 <tosky> elmiko: dashboard tag
14:12:46 <elmiko> tosky: ooh, good idea, i did not mention that
14:13:05 <tosky> it's not my idea, it has been like that forever :)
14:14:31 <elmiko> well, my bad for forgetting...
14:16:12 <SergeyLukjanov> I like both prefix and tag
14:16:46 <elmiko> agreed
14:16:48 <SergeyLukjanov> so seems like we're still ok with keeping dashboard issues in sahara project
14:16:58 <SergeyLukjanov> but with [UI] prefix and some tag
14:17:08 <SergeyLukjanov> not some, but "dashboard"
14:17:25 <SergeyLukjanov> if yes, I'll add dashboard to tags
14:17:39 <tosky> I thought it was already there, isn't it in use?
14:18:48 <SergeyLukjanov> there is a list of "project tags", that will be suggested by autocompletion
14:19:14 <tosky> oh, I see
14:20:18 <SergeyLukjanov> #topic API v2 progress
14:20:25 <elmiko> hey
14:20:35 <elmiko> so, i've got a couple things to note
14:20:47 <elmiko> #link https://review.openstack.org/#/c/212172/
14:20:53 <elmiko> still working to get the main spec review merged
14:21:00 <elmiko> #link https://review.openstack.org/#/c/273316/
14:21:11 <elmiko> that is an initial poc for the v2 endpoints, as described in the spec
14:21:24 <elmiko> and i'm curious if we can close this blueprint
14:21:29 <elmiko> https://blueprints.launchpad.net/sahara/+spec/v2-api-pecan-framework
14:22:11 <egafford> That does look pretty closeable at this point...
14:22:29 <tmckay> I am ++ for merging the v2 API spec, I think it's solid
14:22:30 <elmiko> that's what i thought, but i wanted to get some feedback before i went all crazy in the blueprints ;)
14:23:50 <elmiko> anyways, that's it for my api v2 update. any questions, comments, concerns?
14:24:40 <tmckay> we should merge the spec and move on to sub-specs for features :)
14:24:45 * tmckay my comment
14:25:00 <SergeyLukjanov> I'll close pecan bp
14:25:07 <elmiko> SergeyLukjanov: thanks
14:25:33 <tmckay> then we can each sign up for an endpoint, and have half a dozen or more done before Mitaka ends
14:26:16 <SergeyLukjanov> I'm very sorry for no reviews for the last period, I've very busy on internal stuff, but it should be much better starting next week
14:26:23 <elmiko> \o/
14:26:32 <SergeyLukjanov> great!
14:26:36 <elmiko> (and i hope the internal stuff has gone well)
14:26:44 <tmckay> SergeyLukjanov, that's what I've been saying ;-)
14:27:04 * egafford empathizes with SergeyLukjanov, and is glad that his internal stuff is starting to wrap up.
14:28:03 <SergeyLukjanov> thx, going well, was too time consuming, but should be more localized now ;)
14:28:08 <tmckay> egaffrod, elmiko, vgridnev, sreshetnyak, btw, thank you very, very much for keeping reviews going while SL and I were distracted :)
14:28:14 <SergeyLukjanov> #topic Open discussion
14:28:14 <tmckay> you all have done great work, imho
14:28:40 <SergeyLukjanov> yeah, that's correct
14:28:59 <SergeyLukjanov> and I'm really happy that we have no bottleneck on reviews
14:29:08 <egafford> I had a question about merging minor changes (that are too small to need a blueprint and/or bug, or otherwise inappropriate for blueprints and bugs).
14:29:46 <huichun> tmckay:  can we submit scenario patch into Sahara-scenario now?
14:30:05 <SergeyLukjanov> yup, it's ready to accept patches I think
14:30:11 <vgridnev> huichun, you are always can
14:30:13 <SergeyLukjanov> esikachev could you confirm?
14:30:22 <egafford> I'd like to propose that we have a 'MinorChange' tag, which we require in the commit message whenever we post a change that we think shouldn't need a bug, and have it be understood that review of whether we agree is part of the review in that case.
14:30:35 <esikachev> SergeyLukjanov: yes
14:31:02 <huichun> vgridnev: thx VG
14:31:07 <SergeyLukjanov> egafford I think that lack of bug or blueprint is equal to tagging by MinorChange :)
14:31:08 <egafford> I think it's probably good that we sometimes allow minor changes through with launchpad artifact, but I'd like there to be *some* process around doing it.
14:31:22 <elmiko> egafford: just to help signal to others not to ask for a bug?
14:31:40 <esikachev> in sahara-scenario now implemented ci for sahara from master
14:31:44 <SergeyLukjanov> I would say in the beast case there should be no such patches
14:31:49 <egafford> SergeyLukjanov, elmiko: I think the difference is that there's intention when someone puts a tag on.
14:31:49 <SergeyLukjanov> best*
14:32:20 <SergeyLukjanov> but someone anyway could disagree and say - hey, it should be a bug but not MinorChange tag
14:32:23 <egafford> Saying "I am thinking about it, and think we don't need a launchpad artifact" is different than "I may not have even thought about this at all".
14:32:32 <egafford> Right, that's part of the review.
14:32:58 <egafford> Right now it's implicit, I'm proposing we make it explicit, so at least we all know what we're thinking.
14:33:00 <elmiko> egafford: i get what you are saying, just thinking about it
14:33:37 <SergeyLukjanov> I'm not sure that it'll work as you want, but I'm ok if you want to try
14:33:47 <egafford> I don't think this is a terrifically important issue, but I think it'd help in those cases where there's active discussion of whether a bug/artifact is needed.
14:34:24 <tosky> did we have that in the past? I've mostly seen the sequence "bug opened->review posted" even for things which didn't require a bug
14:34:30 <elmiko> yea, i guess this is one of those issue where if someone puts a "-1 this needs a bug", you can answer by putting "MinorChange" in the commit message?
14:34:43 <tosky> the other way round (review opened for a bug when the bug was required) are not so common
14:35:10 <SergeyLukjanov> btw I'm working on the OpenStack deployment architecture in containers on top of Mesos / Marathon (in upstream, it's kolla + kolla-mesos)
14:35:15 <elmiko> tosky: we also get small patches to fix minor things (like spelling, or line arrangement, etc)
14:35:22 <egafford> elmiko: Or hopefully, you can put MinorChange in the commit message, and then people can know not to "-1 this needs a bug" unless they really think it's a big enough issue to need a bug (rather than just a point of protocol -1.)
14:35:22 <elmiko> SergeyLukjanov: ooh, neat!
14:35:31 <egafford> Sweet!
14:35:37 <tosky> elmiko: and code refactor, is that minorchange always which require a bug or blueprint? (the answer could be yes)
14:35:40 <elmiko> egafford: right, if you think about it ahead of time
14:35:49 <elmiko> tosky: yea, good question
14:35:57 <tmckay> egafford, ++. At the very least it indicates that it's not a mistake
14:36:16 <egafford> tmckay: Right, differentiating between mistake and intent is the whole case here.
14:36:45 <elmiko> i think the tough part is going to be if we start getting reviews with "MinorChange" in lieu of creating bugs...
14:37:05 <elmiko> (not sure if that would happen, just speculating)
14:37:25 <egafford> We don't have to decide now, certainly. It's the first time I've raised the notion to the team. elmiko: Yeah, it's possible that people would take it as license to be terrible at Launchpad; absolutely.
14:37:39 <tmckay> tosky, it depends how big the refactor is, I think
14:37:40 <elmiko> i would hope not ;)
14:38:02 <elmiko> tosky, tmckay, yea.. it's a case-by-case type of thing with refactors
14:38:59 <AndreyPavlov> folks, i want to know if  there are any concerns about this patch https://review.openstack.org/#/c/272503/ ? or should i make the same for all other resources?
14:40:51 <elmiko> AndreyPavlov: my only concern is that our saharaclient impl might start to drift from the rest api with respect to updates, but as long as we document how this works for the client i'm ok
14:42:33 <egafford> elmiko: Well, I think this is more of a difference in absence handling between rest and python than a drift between the rest API and the client. IMO this makes the client *more* like the REST API (in that now the client doesn't inject or omit values that the REST API wouldn't.)
14:43:30 <egafford> It's certainly a drift between client versions, though.
14:43:38 <SergeyLukjanov> AndreyPavlov, elmiko, should we probably keep __repr__ printing None? (crazy idea, need more coffee)
14:43:49 <elmiko> ok, fair. honestly, i'm having some trouble remembering how our rest api is accepting updates (probably been doing too much cross-project review)
14:44:15 <elmiko> updating resources is a pita anyways...
14:45:04 <egafford> SergeyLukjanov: That could make it impossible to determine whether a value in your dict is actually None on debug, or special None that isn't None.
14:45:16 <egafford> I like the __repr__ being different.
14:46:49 <elmiko> having the repr be NotUpdated is just helpful for the internal update
14:46:59 <tmckay> I think this looks good, strictly internal except for the __repr__. I agree with egafford for debug help
14:47:12 <elmiko> until we can change the way updates are handled through the rest, i think it makes sense *internally*
14:48:14 <SergeyLukjanov> egafford agree with None isn't None
14:48:23 <AndreyPavlov> i guess current __repr__ is fine, just to show that it's not None by default and that you can pass None and it will lead to different consequences
14:48:50 <elmiko> +1
14:48:51 <SergeyLukjanov> makes sense
14:49:15 <AndreyPavlov> will update the patch soon
14:49:39 <AndreyPavlov> and also, there are two specs on review, i would appreciate if you could take a look on them) thanks in advance)
14:49:44 <AndreyPavlov> #link https://review.openstack.org/#/c/273547/
14:49:50 <AndreyPavlov> #link https://review.openstack.org/#/c/272569/
14:51:46 <elmiko> SergeyLukjanov, NikitaKonovalov, did you guys want to talk about the summit presentation now or after the meeting?
14:52:09 <SergeyLukjanov> AndreyPavlov will it be possible to conf the default coordinator to not have coordinator at all?
14:52:10 <NikitaKonovalov> we can do that after the meeting
14:52:20 <elmiko> k
14:52:27 <AndreyPavlov> SergeyLukjanov: sure
14:52:34 <SergeyLukjanov> yeah, let's do in #openstack-sahara
14:56:19 <SergeyLukjanov> 3 mins left
14:56:51 <elmiko> i have a quick question about changing our version reponse
14:57:02 <elmiko> the body you get from a GET /
14:57:20 <elmiko> can we change this response without requiring a major version update?
14:57:39 <elmiko> or can we only change it once v2 is supported and v1.1 is deprecated?
14:57:58 <SergeyLukjanov> elmiko hm
14:58:09 <SergeyLukjanov> what are proposing to output?
14:58:47 <elmiko> there is a guideline working it's way through the api-wg now, and there is evidence to show that sahara is pretty far off from what other services respond with for their versions
14:59:01 <elmiko> look at this, #link https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Version_Responses
14:59:58 <elmiko> i'm hoping we can do something more informative in the future
15:00:24 <elmiko> anyways, food for thought ;)
15:00:28 <elmiko> times up
15:00:47 <elmiko> SergeyLukjanov... ;)
15:00:54 <SergeyLukjanov> #endmeeting