18:01:03 <SergeyLukjanov> #startmeeting sahara
18:01:05 <openstack> Meeting started Thu Jan 21 18:01:03 2016 UTC and is due to finish in 60 minutes.  The chair is SergeyLukjanov. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:08 <openstack> The meeting name has been set to 'sahara'
18:01:08 <esikachev> hi
18:01:10 <AndreyPavlov> hi
18:01:13 <sreshetnyak> o/
18:01:17 <vgridnev> hi
18:01:24 <mionkin> hi
18:01:36 <egafford> o/
18:01:45 <tosky> o/
18:02:18 <pino|work> o/
18:02:34 <SergeyLukjanov> #topic News / updates
18:03:28 <vgridnev> I was working on health checks, spec is already available
18:03:32 <elmiko> i've been researching a security bug that i will publish soon, also doing more work on the initial commit for api v2 and the wiki, and more bandit investigations in sahara
18:03:59 <esikachev> i am working on ci for sahara-scenario repo. update sahara-ci
18:04:28 <SergeyLukjanov> I've been working on stable/liverty and mitaka 2 release, + client releases
18:04:36 <SergeyLukjanov> and we have Mitaka 2 successfully released
18:04:42 <egafford> Working on image validation for CDH5.4; almost got an active cluster but ran into troubles on sharelib upload then got pulled into company-internal stuff. Have some hope for review soon. Thanks for reviews, vgridnev. :)
18:05:45 <elmiko> SergeyLukjanov: +1 \o/
18:05:51 <SergeyLukjanov> (btw sahara-dashboard is now included into the M2 release)
18:05:57 <elmiko> great!
18:06:15 <egafford> SergeyLukjanov: Even more +1 \o/ for sahara-dashboard!
18:06:20 <vgridnev> SergeyLukjanov, is the plans in close mitaka-2 milestone at the LP?
18:06:21 <huichun> Hello
18:06:25 <egafford> All the +1 \o/.
18:06:33 <SergeyLukjanov> so, we need to test the installation of horizon + sahara-dashboard from pip
18:06:52 <SergeyLukjanov> vgridnev I'll check
18:07:28 <NikitaKonovalov> Im not sure that pip does install dashboard properly
18:07:40 <NikitaKonovalov> since it has to copy the _enabled files to horizon
18:07:58 <sreshetnyak> SergeyLukjanov: i tested, it works
18:08:07 <vgridnev> SergeyLukjanov, I also see that m-1 also available for targeting bugs
18:08:10 <SergeyLukjanov> sreshetnyak great
18:08:26 <SergeyLukjanov> vgridnev we no more closing lp milestones before actual release
18:08:41 <vgridnev> SergeyLukjanov, ok, thanks
18:09:05 <SergeyLukjanov> any other news or updates?
18:10:17 <SergeyLukjanov> #topic Liaisons review and ack
18:10:19 <SergeyLukjanov> #link https://wiki.openstack.org/wiki/CrossProjectLiaisons
18:10:30 <SergeyLukjanov> let's review the liaisons for sahara
18:10:34 <elmiko> +1
18:10:47 <SergeyLukjanov> and confirm all of them
18:10:51 <SergeyLukjanov> 1. Oslo - sreshetnyak
18:11:10 <SergeyLukjanov> sreshetnyak any comments? :)
18:11:30 <SergeyLukjanov> sreshetnyak are you doing tis work defined on the wiki?
18:11:58 <SergeyLukjanov> or do we need to find the new liaison?
18:12:20 <SergeyLukjanov> okay, lemme post all items
18:13:03 <sreshetnyak> i'm think need to find new liaison
18:14:06 <sreshetnyak> because i wasn't particitate in liaisons last 2-3 month
18:16:25 <SergeyLukjanov> 1. Oslo - sreshetnyak, need new liaison :(
18:16:25 <SergeyLukjanov> 2. Release management - SergeyLukjanov
18:16:25 <SergeyLukjanov> 3. QA - tosky
18:16:25 <SergeyLukjanov> 4. Documentation - crobertsrh
18:16:25 <SergeyLukjanov> 5. Stable Branch - SergeyLukjanov
18:16:26 <SergeyLukjanov> 6. Vulnerability management - elmiko or SergeyLukjanov
18:16:28 <SergeyLukjanov> 7. API Working Group -
18:16:29 <SergeyLukjanov> 8. Logging Working Group - NullPointerException :(
18:16:30 <SergeyLukjanov> 9. Infra - NullPointerExcpetion :(
18:16:31 <SergeyLukjanov> 10. Product Working Group - NullPointerException :(
18:16:32 <SergeyLukjanov> 11. Inter-project Liaisons - do we need some? Heat?
18:16:33 <SergeyLukjanov> 12. Cross-Project Spec Liaisons - elmiko
18:16:34 <SergeyLukjanov> ooh
18:16:36 <SergeyLukjanov> sorry about waiting ;)
18:16:41 <SergeyLukjanov> the list is big
18:16:56 <tosky> so, 3. QA is tosky and SergeyLukjanov, to be precise
18:16:58 <tosky> :)
18:16:59 <SergeyLukjanov> so, all existing liaisons please explicitly confirm that you're ok with it
18:17:04 <elmiko> i think we really need someone for the Product Working Group
18:17:11 <SergeyLukjanov> tosky let's keep only you
18:17:29 <elmiko> i'm definitely ok with VulnMgmt, API-WG, and Cross-Project
18:17:36 <SergeyLukjanov> and #7 is elmiko
18:17:38 <SergeyLukjanov> thx! elmiko
18:17:48 <tosky> from my side, no problem with being the contact, but I'm not the most active one on the QA side here ( esikachev did much more recently, for example, and there are others );
18:18:00 <SergeyLukjanov> elmiko agreed re Product WG
18:18:10 <egafford> I can volunteer for product WG liason.
18:18:13 <SergeyLukjanov> tosky do you probably want to move it to esikachev ?
18:18:30 <elmiko> egafford: +1, that would be awesome =)
18:18:32 <SergeyLukjanov> egafford, okay, let's put you on the list, thx!
18:18:44 * egafford ought to volunteer for something, really, and it intersects what I do pretty well.
18:18:47 <tosky> of course I'm following what happens upstream, so again, no problem for me to keep the role
18:18:57 <SergeyLukjanov> I'll be liaison for infra obviously
18:18:58 <tosky> but just in case :)
18:19:15 <SergeyLukjanov> tosky thx, so, let's keep it on you :)
18:19:18 <tosky> :)
18:19:32 <sreshetnyak> QA: The liaison should be a core reviewer for the project, but does not need to be the PTL.
18:19:49 <SergeyLukjanov> we need liaisons for logs, oslo
18:20:03 <SergeyLukjanov> and we need confirmation from croberts for docs
18:20:30 <vgridnev> If we will have inter-projects with heat, I can be liaison  in here
18:20:37 <SergeyLukjanov> anybody wants to be liaison for oslo and logs?
18:20:48 <SergeyLukjanov> vgridnev ack, let's spin it up
18:21:05 <SergeyLukjanov> vgridnev could you please work on it and find the responsible person from heat side?
18:21:14 <vgridnev> sure
18:21:27 <SergeyLukjanov> great
18:21:39 <SergeyLukjanov> so, we need someone for oslo for sure....
18:21:51 <elmiko> +1
18:22:44 <AndreyPavlov> SergeyLukjanov, it can be me, if nobody wants to :)
18:22:47 <AndreyPavlov> same for logs
18:22:49 <elmiko> \o/
18:23:30 <sreshetnyak> AndreyPavlov: congrats! :)
18:23:52 <SergeyLukjanov> ack, i'll put you in the list
18:24:00 <egafford> I'd like to spin up a liaison with Trove as well, since we're very frequently solving the same problems, and would like to volunteer for that.
18:24:05 <SergeyLukjanov> folks, please, ensure that all of you understands the liaison roles ;)
18:24:16 <SergeyLukjanov> egafford awesome, thx!
18:24:20 <egafford> (Unless someone deeply wants to represent Sahara to Trove and isn't me. :) )
18:24:24 <AndreyPavlov> sreshetnyak: haha thx :)
18:24:30 <elmiko> egafford: it's all you ;)
18:24:38 <SergeyLukjanov> egafford, please, work with trove folks to find the responsible person from trove side
18:25:22 <egafford> If croberts isn't feeling doc, I'd be happy to take that too, so we're covered in any event there, croberts-wise.
18:25:30 <SergeyLukjanov> anything else to discuss on this topic?
18:25:34 <SergeyLukjanov> egafford ack thx
18:28:47 <SergeyLukjanov> #topic Python-saharaclient release
18:29:03 <SergeyLukjanov> so, my question is for you guys - do we have any blockers for release?
18:29:04 <SergeyLukjanov> in master I mean
18:29:20 <SergeyLukjanov> (new major version with CLI plugin for openstack client)
18:29:29 <SergeyLukjanov> AndreyPavlov is it 100% ready?
18:29:32 <AndreyPavlov> there are two things I want to talk about before release
18:29:46 <AndreyPavlov> the first one is described in this bug
18:29:52 <AndreyPavlov> #link https://bugs.launchpad.net/python-saharaclient/+bug/1534050
18:29:53 <openstack> Launchpad bug 1534050 in Python client library for Sahara "Object's fields cannot be unset with update method" [Undecided,New]
18:30:19 <AndreyPavlov> do you guys think it should be fixed somehow (for example with some other sentinel value instead of None by default) before release?
18:31:05 <AndreyPavlov> or maybe it's not important and we can do it later
18:31:11 <elmiko> imo, from the rest standpoint, we should allow removing fields from the datastore by removing them from the json that is PUT
18:31:25 <elmiko> which would bubble up to the client as well
18:31:30 <tmckay> hmmm. I ran into this with default templates, iirc, and fixed up the schemas to allow nulls for optionals
18:31:44 <tmckay> so I believe the support is there, its just the client
18:31:52 <tmckay> elmiko, REST should work
18:32:03 <AndreyPavlov> tmckay, it's not a sahara problem, only client
18:32:14 <tmckay> right, just making sure we're on the same page
18:32:21 <AndreyPavlov> REST works fine :)
18:32:25 <tmckay> not being able to unset is a real pain
18:32:34 <tmckay> from the client, imho
18:32:51 <elmiko> so maybe we just need to allow removing fields from the client impl by having them not present in the json objects for update?
18:33:12 <tmckay> I think that would do it
18:33:28 <vgridnev> SergeyLukjanov, when the supposed time of final release of saharaclient?
18:33:39 <vgridnev> Is it last week before m-3?
18:33:40 <SergeyLukjanov> around M3
18:33:56 <SergeyLukjanov> non-client libs - week before M3
18:34:01 <NikitaKonovalov> elmiko: but that means we always need to send the full obejct for update request every time
18:34:04 <tmckay> elmiko, hmm, I forget exactly how it works
18:34:23 <egafford> Seems like the client needs to distinguish between a key with None in it and no key.
18:34:37 <tmckay> my opinion, it would be worth trying to fix, and if it doesn't make it in, oh well
18:34:45 <SergeyLukjanov> so, I wanna any concerns about release the client early next week / this week
18:34:47 <AndreyPavlov> elmiko: so, the behavior of updates with REST and with client will be different
18:34:48 <elmiko> NikitaKonovalov: i agree, but updating and staying restful are often a pain
18:35:07 <elmiko> maybe we should work this issue out on a reivew?
18:35:07 <NikitaKonovalov> I'd say we need to think about PUT vs PATCH types of requests
18:35:09 <elmiko> *review
18:35:13 <elmiko> NikitaKonovalov: +1
18:35:28 <crobertsrh> hello/  sorry for being tardy :)
18:35:34 <NikitaKonovalov> but that means changing the REST, and we've agree it works fine ))
18:35:35 <egafford> NikitaKonovalov: Yes, that seems to be the right eventual answer.
18:35:37 <elmiko> but still, we should discuss this on ML or over a review
18:35:42 <elmiko> NikitaKonovalov: right...
18:35:48 <elmiko> v2 api......
18:35:52 <elmiko> ;)
18:36:09 <NikitaKonovalov> yep, it solves everything
18:36:11 <NikitaKonovalov> eventually
18:36:21 <tmckay> crobertsrh, earlier question on whether or not you still will be the doc liasion
18:36:23 <elmiko> haha
18:36:28 <SergeyLukjanov> crobertsrh are you with being liaison for documents?
18:36:32 <SergeyLukjanov> documentation*
18:36:45 <crobertsrh> Totally fine with it, I welcome the position
18:37:03 <SergeyLukjanov> crobertsrh awesome thx
18:38:47 <AndreyPavlov> so, should we handle with updates issue before release?
18:38:59 <SergeyLukjanov> AndreyPavlov sounds like yes
18:39:12 <SergeyLukjanov> how much time we need to fix it?
18:39:16 <elmiko> i think we need to discuss it more though
18:39:26 <SergeyLukjanov> vgridnev do we have working gating now?
18:39:38 <SergeyLukjanov> let's discuss it on open discussion today
18:39:40 <NikitaKonovalov> getting back to fixing the client, is it possible to have a workaround, something like have an updated-unset call that handles only None value
18:39:53 <vgridnev> SergeyLukjanov, no
18:40:06 <SergeyLukjanov> vgridnev any ETA on fixing?
18:40:07 <vgridnev> We have two options
18:40:36 <vgridnev> 1. wait for actual gate fix: https://review.openstack.org/#/c/270077/
18:40:44 <elmiko> NikitaKonovalov: that may be our best short-term solution
18:40:50 <vgridnev> or just disable test
18:41:03 <vgridnev> Not sure what is the best choice
18:41:04 <SergeyLukjanov> I don;t like disabling tests
18:41:07 <egafford> NikitaKonovalov: Is it possible to have the client tell the difference (at least in JSON payloads) between "I've given you a key with a None in it; update this" and "I've not given you a key, leave it as it is on the server"?
18:41:12 <elmiko> SergeyLukjanov: +1
18:41:58 <SergeyLukjanov> okay, waiting for the fix on tempest side
18:41:59 <egafford> I'd think this is possible in many cases, and even in non-json-taking client methods, we can distinguish between None and a "nonexistent" sentinel object.
18:42:09 <vgridnev> so let's put extra votes to fix!
18:42:09 <vgridnev> so, more +1 votes on fix review
18:42:21 <vgridnev> argh, lags
18:42:22 <elmiko> i don't like putting magic values in the json, i think it's a bad path to pursue
18:42:33 <egafford> elmiko: No, no magic values.
18:42:36 <elmiko> k
18:42:37 <AndreyPavlov> elmiko, not in json
18:42:50 <AndreyPavlov> just to the update defaults
18:43:16 <AndreyPavlov> to separate None provided provided by user from default None
18:43:19 <elmiko> ok, i think i would need to see the proposed change
18:43:23 <egafford> AndreyPavlov: Right, exactly.
18:43:24 <elmiko> right
18:44:07 <egafford> elmiko: Any magic super-None values can be hidden from the user interface in all cases (and have to be); totally agreed.
18:44:33 <elmiko> egafford: agreed
18:44:57 <elmiko> i think at this point we should just get a review up and start fighting it out there, i'm having trouble following how this will be laid out in the client
18:45:04 <tmckay> +!
18:45:08 <egafford> elmiko: Sane and good. :)
18:45:40 <elmiko> да
18:45:46 <elmiko> =D
18:45:52 <tmckay> isn't sanity implicit in good?
18:46:01 <elmiko> sanity is over-rated ;)
18:46:02 <tmckay> but not vice versa
18:46:29 <elmiko> well, since good is not an absolute, i would think that neither implies the other
18:47:17 <SergeyLukjanov> #topic Open discussion
18:47:21 <SergeyLukjanov> I've moved the topic
18:47:25 <elmiko> yup
18:47:45 <AndreyPavlov> and actually another thing is idea for our cli
18:47:47 <elmiko> quick api v2 update, i've added more to the wiki and will soon have a POC for the v2 initial commit
18:47:48 <SergeyLukjanov> we have two q. to discuss if needed - API v2 progress and separated LP for sahara-dashboard
18:48:08 <elmiko> i would like to keep api v2 progress on the agenda please
18:48:22 <elmiko> also, please please please review the apiv2 spec again folks =)
18:48:45 <tmckay> what's an LP?
18:48:48 <elmiko> launchpad
18:48:53 <tmckay> ah
18:48:54 <crobertsrh> I'm getting close to ready for reviews on the chain that ends with https://review.openstack.org/#/c/270478/  It's reorganizing the UI into being more tab oriented rather than 10 panels.
18:49:10 <elmiko> crobertsrh: +1, that spec looked nice
18:49:24 <crobertsrh> also, the spec for it is up for reviews: https://review.openstack.org/#/c/266557/
18:49:33 <elmiko> vgridnev: did you want to talk about the health check stuff?
18:50:36 <SergeyLukjanov> egafford, elmiko, crobertsrh, AndreyPavlov, please check that I put your IRC handle and role correctly ;) https://wiki.openstack.org/wiki/CrossProjectLiaisons
18:50:44 <vgridnev> elmiko, let's return to health checks discussions. I think we don't need separate methods for getting verifications to have in same time cluster and verifications; and in case of VERIFY i think that we can use put method, but only when json have format {'status': VERIFY}
18:51:06 <egafford> SergeyLukjanov: Looks solid.
18:51:10 <elmiko> SergeyLukjanov: looks good, thanks
18:51:14 <crobertsrh> SergeyLukjanov:  +1 lgtm
18:51:16 <vgridnev> or something like that, elmiko
18:51:37 <SergeyLukjanov> great, thx
18:51:42 <SergeyLukjanov> vgridnev check it too please
18:51:46 <elmiko> vgridnev: yea, i'm ok with that style of PUT, i think it would be good for the api
18:51:54 <AndreyPavlov> SergeyLukjanov: everything fine
18:52:10 <elmiko> vgridnev: and sure, if we don't need the separate endpoints for individual verifications, i'm ok with leaving that out
18:52:37 <vgridnev> great, I will update specs shortly then
18:52:41 <elmiko> but i don't think need the verification as a param to cluster_id, just make a new endpoint to GET at, ..../<cluster_id>/verifications
18:52:45 <elmiko> vgridnev: thanks!
18:53:07 <vgridnev> Hm
18:53:33 <vgridnev> That also make sense
18:55:03 <AndreyPavlov> there's also was an idea about our cli feature
18:55:22 <AndreyPavlov> in a few words, it's something like import/export ability
18:55:23 <SergeyLukjanov> vgridnev do we have some cli sample in verifications spec?
18:55:32 <AndreyPavlov> to move templates across environments
18:55:41 <elmiko> AndreyPavlov: interesting idea
18:55:54 <AndreyPavlov> the problem is that  template cannot be imported as is
18:55:58 <SergeyLukjanov> I dream about it for about a year ;)
18:56:02 <AndreyPavlov> for example some IDs should be changed
18:56:04 <SergeyLukjanov> AndreyPavlov ^^
18:56:18 <AndreyPavlov> but importing large number of configs could be useful
18:56:20 <elmiko> maybe we should write this up as a spec and get some ideas out on it?
18:56:31 <vgridnev> SergeyLukjanov, what do you mean by "cli sample"?
18:56:32 <elmiko> yea, definitely. and it would fullfill SergeyLukjanov's dream ;)
18:56:36 <AndreyPavlov> SergeyLukjanov: yeah, i know :)
18:57:11 <AndreyPavlov> elmiko, sure
18:57:21 <elmiko> great!
18:57:29 <vgridnev> Retriggering and getting health checks from CLI? If yes, we of course will have that
18:58:05 <SergeyLukjanov> vgridnev yuo
18:58:29 <SergeyLukjanov> 2 mins left
18:58:42 <AndreyPavlov> but it will not be included in the next release, right?
18:58:57 <SergeyLukjanov> health checks or import / export?
18:58:58 <crobertsrh> I'll be out for a week or maybe longer starting next Thursday, I'll try to check patches/reviews when I have a chance
18:59:07 <SergeyLukjanov> health checks should be definetly done in Mitaka
18:59:23 <SergeyLukjanov> crobertsrh thx for the note!
18:59:41 <SergeyLukjanov> btw I'm in CA now for the next few months (PST time zone, yay!)
18:59:47 <SergeyLukjanov> #endmeeting