18:02:00 <SergeyLukjanov> #startmeeting sahara
18:02:01 <openstack> Meeting started Thu Dec 10 18:02:00 2015 UTC and is due to finish in 60 minutes.  The chair is SergeyLukjanov. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:04 <openstack> The meeting name has been set to 'sahara'
18:02:17 <SergeyLukjanov> #link https://wiki.openstack.org/wiki/Meetings/SaharaAgenda
18:02:23 <SergeyLukjanov> #topic sahara@horizon status (crobertsrh, vgridnev)
18:02:52 <SergeyLukjanov> folks, how is it going with horizon @ sahara-dashboard back to home :)
18:03:01 <vgridnev> it's going
18:03:18 <elmiko> going well from what i can see
18:03:22 <vgridnev> there is an integration job to project-config is pending
18:03:35 <vgridnev> #link https://review.openstack.org/#/c/255232/
18:03:37 <crobertsrh> Still need reviews :)
18:05:28 <vgridnev> next topic?
18:06:23 <NikitaKonovalov> vgridnev, have we got the installation of the devstack plugin fixed
18:07:03 <huichun> vgridnev: hi vgridnev , not sure how can I update scenario framework to allow replacement of self-defined var with some values
18:07:05 <NikitaKonovalov> I mean that the dashboard should be installed with -e flag so that pip does not copy it ti the dist-packages
18:07:20 <huichun> According to your review comments
18:07:29 <SergeyLukjanov> #topic
18:07:33 <SergeyLukjanov> #topic News / updates
18:07:51 <vgridnev> NikitaKonovalov, right know no, I did not uploaded fix for that yet
18:08:03 <NikitaKonovalov> vgridnev: thanks
18:08:05 <SergeyLukjanov> vgridnev, https://review.openstack.org/#/c/255232/3 -1'd by tsufiev
18:08:17 <elmiko> hey folks, i want to introduce Akanksha08, she is an intern working through the outreachy program on the sahara project
18:08:37 <Akanksha08> Hi guys
18:08:43 <huichun> Welcome
18:08:56 <tmckay> Akanksha08, hi!
18:09:01 <esikachev> hi!
18:09:01 <vgridnev> SergeyLukjanov, I think that right now there is no way to use scheme that Timur suggested, because we need different plugins enabled
18:09:18 <vgridnev> Akanksha08, welcome!
18:09:47 <elmiko> she will be working on improving the anti-affinity support we have, based around the wishlist bug https://bugs.launchpad.net/sahara/+bug/1426398
18:09:47 <openstack> Launchpad bug 1426398 in Sahara "Current anti-affinity only allows instances equals to number of hypervisors" [Wishlist,Triaged] - Assigned to Michael McCune (mimccune)
18:09:49 <Akanksha08> Thanks!
18:10:09 <elmiko> and, i need to switch that bug assignment to her ;)
18:10:35 <vgridnev> elmiko, do we need bug for that, or we need to have blueprint?
18:10:54 <elmiko> vgridnev: it was a bug registered by a user. we will most likely need to generate a bp
18:11:01 <huichun> vgridnev: do you have any related patches to let me see how to do this update on scenario framework? Confused on this
18:11:01 <Akanksha08> yes we wanted to discuss if need a bp or not
18:11:14 <elmiko> i think we'll need to discuss a solution, i know SergeyLukjanov had some nice ideas about this
18:12:04 <Akanksha08> SergeyLukjanov, can we discuss the ideas you have?
18:12:15 <huichun> https://bugs.launchpad.net/sahara/+bug/255173 vgridnev
18:12:15 <openstack> Launchpad bug 255173 in easytag-aac (Ubuntu) "easytag crashed with SIGSEGV in gtk_tree_selection_select_iter()" [Medium,New]
18:12:25 <vgridnev> huichun, hi. I will find some links for that
18:12:57 <vgridnev> huichun, strange bug
18:12:59 <huichun> vgridnev: thx, just put that link on under this patch
18:13:34 <huichun> vgridnev:  sorry wrong link
18:13:35 <vgridnev> huichun, you welcome to email me in case of questions
18:13:59 <elmiko> in other news, the castellan updates are all in place and the improved secret store patch is passing CI. also the apiv2 progress continues...
18:14:21 <huichun> vgridnev: https://review.openstack.org/#/c/255173
18:14:51 <elmiko> SergeyLukjanov: re: anti-affinity, we had talked once about the idea of creating additional server groups to allow more than 1:1 node:hypervisor, is this still the path we should follow?
18:15:03 <huichun> vgridnev:  you can put the link under this patch as review comments,  thx
18:15:38 <vgridnev> huichun, ok
18:16:00 <SergeyLukjanov> hm, I have no real ideas for a-a
18:17:23 <elmiko> hmm, ok. you had mentioned that before, i was thinking we could allow a config option to define the number of nodes per hypervisor, then create server groups to allow those numbers. does that make sense?
18:17:28 <huichun> SergeyLukjanov: since vanilla 2.6.0 is deprecated, should we remove these2.6.0 code ?  https://review.openstack.org/#/c/255111
18:17:29 <vgridnev> forgot something, I've updated tempest test with new plugins versions, need some reviews
18:17:31 <vgridnev> #https://review.openstack.org/#/c/255968/
18:17:47 <vgridnev> huichun, we need to update tempest tests first
18:17:52 <huichun> Ok
18:18:07 <tosky> huichun: you could put a Depends-On: to that tempest review in your review, maybe
18:18:09 <SergeyLukjanov> #topic elmiko, I think it make sense to be user-configurable when choosing services for a-a
18:18:22 <elmiko> hehe
18:18:43 <vgridnev> #link https://review.openstack.org/#/c/255968/
18:18:52 <huichun> vgridnev:  do we have patch to update tempest?
18:18:58 <huichun> tosky:  thx
18:18:59 <vgridnev> ^^
18:19:03 <elmiko> SergeyLukjanov: so, basically, when the user chooses services for a-a, they could define the ratio?
18:19:13 <vgridnev> huichun, see links above
18:19:25 <SergeyLukjanov> elmiko, I think so
18:19:26 <huichun> Ah see this
18:19:29 <tosky> huichun: not because of your change; we should have added the support to the new version before
18:19:45 <elmiko> ok, i can work with Akanksha08 on creating a spec for this
18:20:13 <SergeyLukjanov> cool
18:20:21 <Akanksha08> yes, I agree that the ratio should be user-configurable
18:20:22 <SergeyLukjanov> huichun, was it deprecated in Liberty?
18:20:45 <huichun> In this release? I think
18:21:04 <SergeyLukjanov> huichun, then it should be removed in the next release
18:21:22 <huichun> Ok
18:21:28 <SergeyLukjanov> re sahara-tests extraction, seems like we need more reviews on https://review.openstack.org/#/c/250419/ (shame on me :( )
18:21:28 <Akanksha08> elmiko, and using that ratio we can decide in which manner we want to distribute nodes
18:22:11 <elmiko> Akanksha08: yea, that makes sense
18:22:44 <elmiko> some of this will depend on our ability to instruct nova how to distribute nodes
18:23:18 <elmiko> otherwise, we might want to keep it simple and just create a number of server groups depending on the overload ratio requested.
18:23:30 <Akanksha08> yes I did not go through the nova code yet as in how it creates the server group
18:23:53 <elmiko> Akanksha08: i can point you at our code after the meeting
18:25:03 <Akanksha08> elmiko: yes we can do that way as well
18:25:33 <huichun> tmckay: currently, when we delete a cluster, there is no check on whether there are edp jobs running on this cluster? If not, should we have to add this check and refuse this operation?
18:26:22 <vgridnev> huichun, I've added link to your review with an example
18:26:29 <tmckay> huichun, hmm, I am unsure.  Those jobs could certainly be canceled
18:26:55 <tmckay> huichun, that is a good question, we should check if there is current code to handle it
18:27:05 <huichun> vgridnev:  thx VG
18:27:26 <huichun> tmckay:  there is no check on this
18:28:04 <vgridnev> huichun, about cluster I think that we should allow deletion of cluster in case of running job on top of it
18:28:21 <huichun> So if there are jobs running, I think we should reject this delete cluster operation?
18:28:33 <vgridnev> I think no
18:28:51 <tmckay> huichun, hmm, we probably need a spec to discuss it.  I lean with vgridnev, I think
18:28:56 <tmckay> but I can see both sides
18:29:31 <tmckay> we could add a "--force" type flag, potentially
18:29:40 <huichun> vgridnev:  if user are forgot there are jobs on cluster?
18:29:59 <huichun> Ok I will raise a spec on this topic for discuss
18:30:05 <huichun> tmckay:
18:30:15 <vgridnev> I most cases I think it's enough to add some kind of warnings in UI and CLI
18:30:41 <tmckay> vgridnev, right, but a warning is worthless unless it asks for confirmation
18:30:42 <egafford> +1 to vgridnev and tmckay: particularly in the case of stuck jobs, we should allow deletion during a job.
18:30:57 <tmckay> so, warn without disabling the action just lets the user know too late :)
18:31:08 <tmckay> WARNING: okay, I am nuking your jobs ....
18:31:14 <tmckay> stop!!!
18:31:16 <tmckay> too loate
18:31:25 <huichun> Yes waring is too late
18:31:40 <tmckay> that's why I suggest warn with --force
18:31:48 <egafford> --force is sensible for the CLI, yeah.
18:32:01 <tmckay> vgridnev, on the UI, you can do the whole "Are you sure?" thing
18:32:09 <tmckay> crobertsrh, ^^ :)
18:32:15 <tosky> --i-really-want-to-do-it
18:32:20 <tmckay> lol
18:32:22 <crobertsrh> tmckay can work on the "undo" operation :)
18:32:25 <huichun> +1 for --force
18:32:30 <vgridnev> I think we will need some confirmation like apt-get install vs apt-get install -y
18:32:40 <tmckay> undo cluster deletion with jobs, oh my head hurtws
18:32:43 <egafford> If you're making pure REST calls, do we just hope you know what you're doing, or do we push the force arg to the server layer to protect those who desperately hate all tools?
18:32:52 <egafford> (But love webservices).
18:32:57 <egafford> (They're complicated).
18:33:17 <elmiko> i'm not sure we want to enshrine the force option in the rest api
18:33:24 <egafford> elmiko: +1.
18:33:32 <egafford> Just seemed like the next question.
18:33:45 <huichun> tmckay:  I will raise a spec on this topic , I think-- force is better currently
18:33:54 <elmiko> yea, good question, but i think the rest interface should operate like you would expect a programattic api to work
18:34:06 <tmckay> huichun, thanks for bringing it up, good question
18:34:06 <egafford> I agree.
18:34:31 <pino|work> just fail if any of the conditions is not met
18:34:35 * tmckay it's "are you sure?" all the way down .... ;-)
18:34:39 <SergeyLukjanov> (I'm ok with any kind of --force + confirm on horizon side for user)
18:34:43 <pino|work> but otherwise, just go head doing the operation
18:35:18 * tmckay imagines "Are you sure?" at weddings ...
18:35:20 <elmiko> SergeyLukjanov: +1
18:35:48 <elmiko> tmckay: that may actually help things, but make for some odd wedding moments ;)
18:36:10 <pino|work> tmckay: hey, isn't there already a "speak out now, or shut up forever"?
18:36:23 <tmckay> pino|work, that's for the audience
18:36:24 <elmiko> pino|work: yea, but that's for the audience not the participants
18:36:33 <pino|work> ahh ok
18:36:35 <tmckay> jinx, by me some baremetal
18:36:40 <tmckay> buy, sorry
18:36:43 <pino|work> (see how much experience with that i have)
18:36:54 <elmiko> lol, sure baremetal ARM boxes XD
18:37:13 <elmiko> i vote we change the #topic
18:37:25 <tmckay> hey, are we on open topics yet, it seems like it
18:37:35 <tmckay> I have one ...
18:41:16 <elmiko> SergeyLukjanov: maybe a second chair?
18:41:51 <tmckay> elmiko, maybe we should try to change it ...
18:42:03 <elmiko> can't need to be a chair
18:42:08 <tmckay> doh
18:42:11 <elmiko> #topic tmckay is awesome
18:42:17 <elmiko> see
18:42:21 <tmckay> that is a very deep topic
18:42:28 <elmiko> hehe, i know right?
18:42:31 <tmckay> probably need a second meeting :)
18:42:38 * elmiko chuckles
18:43:00 <huichun> ^^
18:43:07 <tmckay> SergeyLukjanov, we want open discussion, or we will go on strike
18:43:39 <SergeyLukjanov> sorry folks, bad internet connection :(
18:43:44 <elmiko> no worries
18:43:45 <SergeyLukjanov> #topic Open discussion
18:43:50 <tmckay> thanks :)
18:43:50 <SergeyLukjanov> just reconnected to znc
18:43:58 <SergeyLukjanov> #chair tmckay
18:43:59 <openstack> Current chairs: SergeyLukjanov tmckay
18:44:01 <SergeyLukjanov> #chair elmiko
18:44:02 <openstack> Current chairs: SergeyLukjanov elmiko tmckay
18:44:09 <SergeyLukjanov> PTL HA mode enabled
18:44:13 <elmiko> hehe, thanks
18:44:26 <tmckay> heh. okay, so here is my question SergeyLukjanov and other ironic experienced folks ...
18:44:53 <tmckay> I have been spending much time with ironic since Paris, hence my scarcity on the channel, and reviews, and patches, etc
18:45:19 <tmckay> ironic/nova/neutron confluence can be difficult. But that's another story.  Anyway ...
18:45:42 <esikachev> guys, we are missed topic "Discuss sahara scenario tests extraction"
18:45:52 <esikachev> :(
18:45:55 <tmckay> it seems there is no good automated setup mechanism for access to the nova metadata service over 169.254.169.254 from baremetal ...
18:45:57 <egafford> :o
18:46:06 <SergeyLukjanov> do we have something to discuss re sahara-tests extraction right now?
18:46:25 <SergeyLukjanov> I think we still need more reviews on spec, folks, please
18:46:32 <elmiko> SergeyLukjanov: +1
18:46:58 <tosky> yep (sorry, I was a bit slow on the review)
18:47:27 <tmckay> SergeyLukjanov, so, I ended up using the "--config-drive" option for setting up cloud-init.  Is this what you did in your sahara/ironic experiments?
18:47:43 <tmckay> actually, I set "force_config_drive" in the nova.conf
18:48:08 <tmckay> SergeyLukjanov, or did you find some way of setting up access to 169.254 for the metadata service?
18:48:28 <SergeyLukjanov> tmckay, I'm not sure, you should chat with NikitaKonovalov and degorenko
18:48:33 <tmckay> sorry, not Paris, Tokyo ....
18:48:38 <SergeyLukjanov> probably esikachev knows something too
18:48:41 <huichun> Oh, just one important issue, do we have any plan to modify the current design to support the old Hadoop version for customer,  if we remove CDH 5.0 code, but the customer is using CDH 5.0, and we say:" sorry, we Sahara do not support CDH5.0 now" it's really strange
18:48:46 <huichun> SergeyLukjanov:
18:48:55 <huichun> tmckay:
18:48:58 <huichun> elmiko:
18:49:36 <tmckay> so we're talking about deprecation policy for plugins ...
18:49:43 <tmckay> we've discussed many times
18:49:54 <huichun> It's the point
18:50:03 <NikitaKonovalov> tmckay: as far as I remember the experiments were on nova network, and degorenko could somehow make cloud-init work
18:50:17 <elmiko> SergeyLukjanov had a great idea about the plugins and backward compat, but it is still an idea at this point
18:50:24 <elmiko> huichun: ^^
18:50:26 <tmckay> NikitaKonovalov, okay, thanks, I'll ask him
18:50:27 <huichun> Ok
18:50:57 <elmiko> huichun: for the time being though, there is not a good way to support older plugins from current server
18:51:05 <tmckay> I'm not even sure if we have a plugin deprecation policy doc in the official sahara docs, do we?  Maybe we should
18:51:14 <tosky> we should, I agree
18:51:20 <huichun> I think we should
18:51:37 <elmiko> yea, we had a whole session about deprecation policy, we definitely need to write that stuff down somewhere
18:51:37 <huichun> Customer need this, or it will be crazy
18:51:41 <elmiko> +1
18:53:25 <SergeyLukjanov> with a plugin separation - it's still not clear how to implement it
18:54:17 <SergeyLukjanov> the best working solution from UX PoV will be overcomplicated and non-supportable
18:56:37 <elmiko> ah, that's too bad
18:56:53 <SergeyLukjanov> I'm still evaluating the options...
18:57:03 <SergeyLukjanov> probably we'll find some balance
18:57:24 <elmiko> cool, i thought it was a great idea
18:58:26 <elmiko> before we finish, quick reminder. the api v2 spec has been updated again, please take a look sometime
18:58:30 <elmiko> #link https://review.openstack.org/212172
18:59:05 <SergeyLukjanov> thx!
18:59:07 <tmckay> thanks elmiko. You are the V2 hero
18:59:19 <SergeyLukjanov> 1 min left, any last second updates?
18:59:45 <elmiko> tmckay: not a hero, just a man with a dream ;)
18:59:58 <tmckay> heh. So was Batman :)
19:00:02 <elmiko> lol!
19:00:08 <SergeyLukjanov> #endmeeting