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