19:02:40 #startmeeting OpenStackClient 19:02:40 Meeting started Thu Jul 2 19:02:40 2015 UTC and is due to finish in 60 minutes. The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:02:44 The meeting name has been set to 'openstackclient' 19:02:55 stevemar: np, I didn't write an agenda so it may be short anyway 19:03:12 We can do the usual stuff real quick though… 19:03:17 #topic bugs 19:03:26 any bugs that need attention from the group? 19:04:38 gorram reavers, i gotta go, sorry 19:04:57 theres a new bug filed today taht needs triaging 19:05:00 stevemar: np, talk to you soon 19:05:28 looks like https://bugs.launchpad.net/python-openstackclient/+bug/1470875 19:05:28 Launchpad bug 1470875 in python-openstackclient "Add support for showing aggregates in an hypervisor's properties" [Undecided,In progress] - Assigned to David Moreau Simard (dmsimard) 19:06:18 that looks to be a straightforward enhancement, if the python API for it is exposed 19:07:36 in general the bug list needs some grooming. maybe good stuff for during a late night staff meeting… ;) 19:08:01 it was working for me, but I have no aggregates on my devstack atm 19:08:11 it wasn’t blowing up is what I mean 19:08:46 good to know. maybe we should keep some local.conf files around for testing various configurations? 19:09:06 I don't know I've ever done an aggregate in devstack other than what the exercises do (did) 19:10:14 it might be nice to have gates with different local.confs or a couple local.confs checcked into the docs 19:11:36 I'm not sure how far we want to take that in our own jobs, it might explode. a growing part of osc gets exercised on every devstack run now so we'll at least have that coverage 19:12:13 fair enough 19:12:24 but not things like aggregates and cells 19:13:25 can we do any of that in our functional testing without adding jobs? ie, reconfigure a running devstack and still ahve a valid test setup? since we care about the client I'm thinking we might be able to do that 19:13:55 o/ 19:13:59 we don't have to answer that now 19:14:18 any more bugs to raise? 19:15:19 ok, moving on 19:15:34 #topic reviews 19:15:34 how about any reviews for attention? 19:16:33 I had a question on https://review.openstack.org/183324 19:17:07 it adds an update command, which we don't currently use. a) is save or set useable theere and b) do we even want this? 19:17:24 I’d really like to see cloud show and cloud list with that 19:17:31 or another patch with list and show 19:17:39 I have a slight aversion to mucking about with config files, especially ones we don't 'own' as it is potentially shared with other clients 19:17:59 terrylhowe: agreed those would be useful 19:18:05 well, show and list would be read only at least 19:18:43 OSC is in a good position to do updates since it supports the env and command line args 19:18:56 it would be handy to have a create that would just stuff whatever is in the current env 19:19:49 I suppose if OSC is the first thing to do that we'll 'de facto be the owners of it 19:20:17 is 'cluod' the right object name? should it be 'cloud config'? 19:20:23 err, 'cloud' 19:21:16 I'll add that to the review and we can go from there. the additional commands can be a follow-up 19:21:48 config might be better 19:22:07 that's how we've been describing it informally 19:22:40 ‘cloud config’ is fine though, not sure if there is going to be another type of config 19:23:22 there may not be, but I think cloud config is consistent with how the entire concept has been described 19:23:53 terrylhowe: is the only thing holding up that functional test chain a second +2? 19:24:29 no, I’ve been meaning to go through them and make sure they are all g2g 19:25:04 ok, np 19:25:09 on the functional tests for the SDK I had some problems when I merged a bunch at once and they interfered with one another 19:25:27 causing intermittent failures 19:26:33 https://review.openstack.org/#/c/185193/ 19:26:59 this interests me because it seems like there is limited access to some identity stuff on public urls that normally get admin urls 19:27:45 right. I think there are some changes wrt v3 that I'd like to make sure this isn't going to cause us back-compat pain down the road, otherwise it's in good shape 19:28:08 I'd like to get stevemar's blessing on it yet 19:28:22 I just added him as a reviewer 19:28:52 the changes to the make_client() functions caught my eye, but that'll all go away with the sdk so I can live with it 19:29:15 lots of variations 19:30:01 any other reviews? 19:30:27 nothing comes to mind 19:30:57 #topic open discussion 19:31:55 anything else? we may be getting close to another release, there s a nice list of new stuff to brag about 19:32:14 is David's QoS bits complete? 19:32:40 I think so 19:32:42 also, what's his nick? 19:32:57 be nice to have some basic functional tests for those 19:33:08 no idea on his nick 19:35:01 ok, the other thing I wanted to mention is that I'm sketching up a conference proposal for OSC, would like to talk about (and have at least a demo of) the sdk integration, among other things… 19:35:20 terrylhowe, briancurtin: are you guys planning a talk in Tokyo? 19:35:51 dtroyer: i'm not, at least not right now 19:36:24 ok. just wanted to make sure we didn't overlap too much if you were 19:36:28 SDK integration I will have space for soon. I’d like for us to cut a new SDK release first 19:37:20 terrylhowe: cool. I don't know yet if we should think about a feature branch for that or just pick it up when it's ready 19:37:27 I wanted to take a look at OSC plugins next week. I have been messing with SDK plugins this week. 19:37:57 so a project could handle both in their client package? 19:38:21 I think so 19:39:11 I did a very simple DNSaaS plugin 19:40:03 I think that would make like better for projects if we can make that work 19:42:10 ok, anything else? 19:42:26 nothing here 19:43:27 ok then, let's call it. 19:43:29 thanks everyone 19:43:35 #endmeeting