15:00:48 #startmeeting satori 15:00:49 Meeting started Mon Jul 14 15:00:48 2014 UTC and is due to finish in 60 minutes. The chair is samstav. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:50 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:52 The meeting name has been set to 'satori' 15:01:48 Hi, welcome to the satori meeting 15:01:53 #link https://wiki.openstack.org/wiki/Satori 15:05:27 Anyone here for satori? 15:05:29 o/ 15:05:49 Cool. 15:06:08 I'll go ahead and get started with action items, a few of which we declared last week 15:06:11 I see zns in here, but not sure if he is active 15:06:31 #topic action items 15:07:34 Speaking of zns, we can continue to carry this action item until he says otherwise 15:07:36 #action zns start ML discussion & blueprint for built-in python data plane discovery 15:07:53 haha 15:10:10 walker_ you had an item, for creating a blueprint regarding a configurable escalation prefix for running remote commands 15:10:34 Yes. We probably need to push that out to next week 15:10:42 ok, sounds good 15:10:51 here's the minutes from last week btw 15:10:52 I think there is still some work to be done around that 15:10:54 #link http://eavesdrop.openstack.org/meetings/satori/2014/satori.2014-07-07-15.01.html 15:11:18 ok, cool. anything you'd like to discuss during this meeting? 15:11:46 I mean, do you want to have a short discussion about the escalation stuff during this meeting? 15:11:57 Yes, I think we should 15:12:14 Basically, there is no assurance that a system will have sudo access 15:12:33 and it may still be desireable for people to login with an unprivileged account 15:13:05 so, there needs to be a way to tell Satori to use something other than 'sudo' to escalate privileges 15:13:55 What seems to work best is to allow the inclusion of root-password, that way Satori can login with an unpriviledged account and then use 'su' to assume the root account 15:14:19 #topic running escalated commands through satori 15:14:51 #info walker_: Basically, there is no assurance that a system will have sudo access. and it may still be desireable for people to login with an unprivileged account. so, there needs to be a way to tell Satori to use something other than 'sudo' to escalate privileges. What seems to work best is to allow the inclusion of root-password, that way Satori can login with an unpriviledged account and then use 'su' to assume the root account 15:15:34 So, basically 'root-password' is optional and if given satori will use 'username' and 'password' to login, then use 'root-password' to escalate 15:15:38 sound about right? 15:16:28 that sounds great for the SSH based class. n1ck-o isn't around to comment for the windows equivalent 15:16:53 good point, right now this is looking at Linux based hosts 15:17:40 Cool. I'll move us back to action items, and re-apply yours for creating a blueprint? 15:17:47 Yes please 15:17:51 #topic action items 15:18:04 #action walker_ Create a blueprint for choosing the escalation prefix ("sudo" OR "su -" OR ?) when running commands in ssh.py 15:18:55 Since n1ck-o isn't here, I'm going to push his action item forward as well 15:19:05 #action Address comments on submission 98383 15:19:17 though, based on the patch sets I saw this week, it looks like he made som 15:19:27 some good progress. 15:20:19 I had an action item regarding the failing unittests on 98383 15:20:26 #topic gates 15:22:58 While I'm still uncertain about the root of the problem, I did track it down, and it pointed to the python-whois lib we use. 15:23:08 This is regarding the unittests 15:23:15 Nice @samstav 15:23:27 er, minus the @ 15:23:58 Fixed our unit tests in test_dns.py for now, and submitted a patch upstream 15:24:00 #link https://github.com/joepie91/python-whois/pull/29 15:24:37 One of my only guesses it that a new version was released, and the old version was removed from pypi 15:24:53 Just a guess. 15:25:47 #link https://github.com/samstav/satori/commit/269da49c4a50572037ae84e3bfb8e7c3c97f32c6#diff-6 15:26:19 I moved on from there to see why the pep8 and other gates were failing, again, not really getting to the root cause but still solved the problem. 15:26:52 Made some updates to our requirements file 15:26:56 #link https://github.com/samstav/satori/commit/269da49c4a50572037ae84e3bfb8e7c3c97f32c6#diff-9 15:27:33 ( I'm linking to github instead of gerrit, I know. Sorry, but the interface is better. I promise that's exactly what's in my patch set. ) 15:27:40 Hi - I'm here, but might not contribute much yet as I'm trying to get up to speed. FYI 15:29:08 The empty files fix was integrated into the 1.5.7 release of pep8 15:29:10 https://pypi.python.org/pypi/pep8/1.5.7 15:30:15 👍 15:30:51 yay! 15:31:07 that was annoying 15:31:30 I then rebased our fork of hacking on hacking's latest release 15:31:48 To deal with the dependency VersionConflict 15:32:00 and tagged it @satori 15:32:09 #link https://github.com/samstav/hacking/tree/satori 15:32:22 oh good. I've been running into a lot of version conflict issues 15:32:25 thanks for doing that 15:32:39 That branch includes zns's commits 15:32:52 1. Detect egg-linked libraries as third-party 15:33:00 2. Better detection of stdlibs in virtualenvs 15:33:49 We will need to make those same changes for our other projects' requirements files. 15:35:09 Those fixes/updates, and a few others are included in my submission which is intended to extend the windows-support submission 15:35:11 #link https://review.openstack.org/#/c/106134/ 15:36:49 There is a python2.x/3.x related fix in utils.py in there, where I included a "universal" unicode() function 15:36:51 https://github.com/samstav/satori/commit/269da49c4a50572037ae84e3bfb8e7c3c97f32c6#diff-8 15:36:53 #link https://github.com/samstav/satori/commit/269da49c4a50572037ae84e3bfb8e7c3c97f32c6#diff-8 15:37:35 You will notice they have the same signatures 15:37:43 python 2.x 15:37:47 #link https://docs.python.org/2/library/functions.html#unicode 15:37:54 python 3.x 15:37:56 #link https://docs.python.org/3/library/stdtypes.html#str 15:39:24 That extension also moves posh_ohai.py into its own file, as its own independent provider. There is an exception pattern which raises when an unsupported platform tries to use the wrong provider 15:39:42 #link https://github.com/samstav/satori/commit/269da49c4a50572037ae84e3bfb8e7c3c97f32c6#diff-5 15:40:46 And lastly, in the gates topic, there is only the beginnings of python 3 support in eventlet 15:40:48 #link https://github.com/eventlet/eventlet/issues/6 15:41:21 This is the only thing keeping submission 106134 from passing all gates 15:42:02 #info submission 106134 depends_on/includes submission 98383 15:44:42 #action zns, samstav, n1ck-o talk_about/research either 1) ditching eventlet, 2) finding an alternative greenthread lib w/ python 3 support, 3) remove python3 gate 4) use python native threading support 15:45:39 #topic action items 15:46:18 I had one more item which was to create a blueprint for removing the subprocess calls from pse.py (renamed to smb.py) 15:47:08 It is minimal and I will expand it some 15:47:10 #link https://blueprints.launchpad.net/satori/+spec/no-subprocess 15:47:16 So that's done. 15:47:51 #topic général discussion 15:48:07 That's about it, unless anyone would like to discuss anything else? 15:49:46 thanks samstav, nothing more from me 15:50:04 cool. Thanks for your attendance. See y'all next week 15:50:08 #endmeeting