17:05:14 <dwalleck> #startmeeting
17:05:15 <openstack> Meeting started Thu Apr  5 17:05:14 2012 UTC.  The chair is dwalleck. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:05:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:05:32 <dwalleck> #topic Current Reviews
17:06:17 <dwalleck> So the only thing under review that is of any contention is https://review.openstack.org/#change,6227
17:06:46 <dwalleck> Which really boils down to how to we want to configure/execute authorization tests, correct?
17:07:02 <rohit-k> dwalleck: yes
17:07:21 <rohit-k> and also probably structure them
17:08:31 <rohit-k> Personally, I was more comfortable with the older design of the manager init
17:08:46 <dwalleck> So the issue that came up last week was concern over the number of changes made to the config file
17:08:56 <rohit-k> okay
17:09:47 <dwalleck> I personally like it too. I think the only thing that might raise some concern is the moving of the admin credentials back into the main compute config
17:10:09 <dwalleck> dprince might throw something heavy at me :)
17:10:19 <davidkranz_> What was the motivation for moving them out in the first place?
17:11:02 <rohit-k> dwalleck: so is it not ok to be able to set admin credentials in tempest.conf?
17:11:09 <jaypipes> crap, sorry guys, got caught up in a review...
17:11:14 <dwalleck> I think the idea was to keep the compute section as stable and basic as possible, and if people wanted additional configs, they would be seperate
17:11:14 <openstack> jaypipes: Error: Can't start another meeting, one is in progress.
17:11:15 <dprince> dwalleck: its all good sir.
17:11:21 <rohit-k> dwalleck: aah, got it
17:11:22 <jaypipes> oh, poop... sorry about that
17:11:23 * dprince dprince likes stable config files
17:11:36 <rohit-k> hello, jay
17:11:37 <rohit-k> !
17:11:40 <jaypipes> hi :)
17:11:44 <dwalleck> Yup, that's the key
17:12:41 <dwalleck> So are we in agreement that being able to create an instance of a manager with whatever configs you want is fine, that it's just where that data comes from is what we need to solve?
17:12:52 <dwalleck> I'm on cold meds, so I hope that made sense :)
17:12:56 <jaypipes> dwalleck: adding additional things into the config is much easier for dprince to deal with than changing existing config options :)
17:13:25 <jaypipes> dwalleck: yes, that makes sense to me above.
17:14:12 <rohit-k> dwalleck: trying to understand, are we saying move admin configs out of the main config file (tempest.conf) ??
17:14:21 <davidkranz_> dwalleck: I think so. Some tests might just want to instantiate a Manager in  different way. The stress tests do this.
17:14:51 <jaypipes> rohit-k: no, we're saying keep admin configs in a different section of the tempest.conf ([compute-admin], [image-admin], etc
17:15:14 <jaypipes> rohit-k: and not prefixing the username, password or tenant_name with "admin_"...
17:15:15 <rohit-k> jaypipes: aah, ok, I think I agree with that, contrary to my proposed changes in the patch
17:15:21 <dwalleck> rohit-k: No, not at all. The admin config was previously in the compute-admin section, and your change moved it into the compute section
17:15:38 <dwalleck> That's the part I want to sort out
17:15:39 <jaypipes> dwalleck: *back* into the compute section :)
17:16:06 <rohit-k> dwalleck, jaypipes: Yup, I am going to withdraw that change, I understand the reasons better
17:16:14 <jaypipes> dwalleck: or rather, didn't we have a nonadmin_user1 or something? that is now the alt_username in the main [compute] section
17:16:16 <dwalleck> yeah, what jay said lol
17:16:26 <rohit-k> however the manager object is what Im more interested in
17:16:33 <jaypipes> rohit-k: ok, sounds good. or just amend the commit... either way.
17:16:36 <davidkranz_> Can we agree that you should be able to create a Manager, that represents a (user, tenant), without having to use global config state?
17:16:55 <rohit-k> jaypipes: yes
17:17:08 <dwalleck> davidkranz_: ++
17:17:11 <jaypipes> davidkranz_: I'm not so sure. I think creating clients separately from the global config might be a better way to go.
17:17:33 <jaypipes> davidkranz_: as in what dwalleck recently did in the test_authorization patch
17:18:02 <rohit-k> The concern that I see is that we would be having many client objects within manager that would be uused
17:18:10 <dwalleck> jaypipes: The only thing that would concern me is having to create many clients for one user for more complex scenarios
17:18:10 <jaypipes> davidkranz_: but I could be persuaded otherwise if you guys want to return to the place where you have optional __init__ args to the Manager...
17:18:30 <rohit-k> dwalleck: +1
17:19:02 <jaypipes> dwalleck: sure, I understand you. What about, instead, passing in just an "alt=False" arg to the manager, then? that would load the clients using the alt_XXX confgs?
17:19:04 <davidkranz_> jaypipes: I think so. Otherwise you have to create all the clients. In Daryl's case only a server client was needed.
17:19:47 <jaypipes> davidkranz_: what would you think about the alt=False param?
17:19:59 <jaypipes> davidkranz_: instead of passing username, password, tenant?
17:20:11 <dwalleck> jaypipes: Hmm...I'm trying to think if there's a scenario where that wouldn't work. Really the most you need for authz tests would be 2 normal users and 1 admin user
17:20:19 <dwalleck> For basic tests at least
17:20:20 <rohit-k> jaypipes: I think the question is, would we want the tests to access config objects directly?
17:20:39 <jaypipes> rohit-k: well, they all currently do...
17:20:41 <davidkranz_> jaypipes: I was just thinking that there might be more complex scenarios that would find config files too much of a pain.
17:20:48 <jaypipes> rohit-k: via the manager.config...
17:20:52 <rohit-k> or let the manager do that
17:20:58 <jaypipes> davidkranz_: yeah, I hear ya..
17:21:01 <rohit-k> jaypipes: ok
17:21:22 <rohit-k> jaypipes: makes sense too
17:21:58 <davidkranz_> I don't have a strong opinion about where the admin user goes in the config file.
17:22:03 <rohit-k> I'm in a dilemma on this one :P
17:22:11 <jaypipes> davidkranz_: how about a compromise, then? start with the alt=False single parameter to openstack.Manager.__init__() and then, if we find that does not provide an appropriate level of configurability, we take another look at it?
17:22:36 <dwalleck> jaypipes: That sounds reasonable
17:22:44 <davidkranz_> jaypipes: We could do that. I just don't see the harm in providing keyword arguments for the others.
17:23:21 <jaypipes> davidkranz_: for the admin user, tests really shouldn't be run with them... unless it is an admin-only API (like flavor CRUD), which is why I separated out that into a separate config section [compute-admin], thinking that eventually we'd want to carve out a /tempest/tests/compute/admin/* set of tests
17:23:44 <davidkranz_> jaypipes: alt would be fine for now.
17:24:08 <dwalleck> jaypipes: ++ on admin tests. I'd love to find some docs on those to flesh out that area out
17:24:22 <jaypipes> davidkranz_: ok, thx. the advatage to alt=False is a) less verbose and b) enables the manager to control how it looks up alternate creds (instead of the caller having to remember...
17:24:33 <jaypipes> dwalleck: heh, you and me (and davidkranz_) both!
17:24:45 <jaypipes> dwalleck: it's a pain in the ass trying to find that kind of api docs :(
17:25:08 * dwalleck begins casting Retrieve Invisible Docs....
17:25:13 <jaypipes> OK, so who's going to tackle this? rohit-k, you want to do it on your existing changeset?
17:25:26 <jaypipes> rohit-k: clear on what the changes would be?
17:25:42 <rohit-k> jaypipes: alt=False is only to lookup the alt_credentials?
17:25:48 <jaypipes> rohit-k: correct.
17:26:01 <jaypipes> rohit-k: basically something like:
17:26:04 <jaypipes> if alt:
17:26:13 <jaypipes> username = config.compute.alt_username
17:26:16 <jaypipes> etc, etc
17:26:31 <jaypipes> where username gets passed to the client classes..
17:26:32 <rohit-k> jaypipes: how about using config.compute_admin.username?
17:26:50 <jaypipes> rohit-k: damn it. davidkranz_ is right.
17:26:53 <jaypipes> :)
17:26:55 <rohit-k> :)
17:26:59 <dwalleck> lol
17:27:24 <jaypipes> ok, back to the passing the creds in the __init__ of the Manager... I submit! I submit! Uncle!
17:27:34 <rohit-k> I need a manager object that can be used for admin ops, simple :)...lol
17:28:01 <jaypipes> rohit-k: hmm, well that's also a possibility too... hold on a sec. I have an idea... (uh oh!)
17:28:56 <rohit-k> scratching my head
17:29:16 <dwalleck> the only other thing I could think of would be to expand on Jay's idea and instead of making it bool, make it a role name: alt, admin, etc
17:29:45 <dwalleck> That would take magic in the backend to work it, but it might be cleaner
17:29:51 <rohit-k> dwalleck: works
17:30:32 <dwalleck> But magic can be bad as well....not sure if the ends justifies the means
17:31:39 <dwalleck> I'm interested in what Jay's cooking up. He's quiet :)
17:31:42 <jaypipes> http://pastie.org/3734203
17:31:59 <jaypipes> that would give us both brevity and configurability... :)
17:32:19 <jaypipes> thoughts?
17:32:30 <fattarsi> jaypipes: ++
17:32:39 <rohit-k> jaypipes: ++
17:32:39 <dwalleck> That is a much less hackish version of what I mentioned :) ++
17:32:41 <jaypipes> we could even have the AdminManager install additional clients that are admin-only ...
17:32:48 <jaypipes> davidkranz_: thoughts?
17:33:02 <davidkranz_> jaypipes: Works for me.
17:33:13 <jaypipes> davidkranz_: and if there WAS a need for even more configurability, we could just call Manager with args directly...
17:33:19 <dwalleck> Plus it may be good to have these users that we can almost refer to as avatars, so that when we talk about strange scenarios, we're all speaking the same language
17:33:21 <rohit-k> jaypipes: we still are having the args
17:33:34 <davidkranz_> jaypipes: Yes, that was my point before.
17:33:42 <jaypipes> rohit-k: right, but you only have to do: cls.manager = openstack.AdminManager()
17:33:48 <jaypipes> rohit-k: no need to pass args... :))
17:34:04 <jaypipes> davidkranz_: k, cool...
17:34:37 <davidkranz_> What about the issue I put in the ticket about whether admin-only is part of an api or could vary with implementation?
17:35:13 <davidkranz_> I think it should be part of the API but obviously others differ.
17:35:15 <jaypipes> davidkranz_: heh, that's a wholly separate issue, and I don't think it will be resolved until the Nova API has some level of discoverability/metadata about that kind of thing :(
17:35:47 <jaypipes> davidkranz_: otherwise, we're going to be stuck with a whole crap-ton of things like api_flavors_crud_admin_only = False in the config file! :(
17:35:53 <davidkranz_> jaypipes: So for now we will assume the defaults define which apis are admin?
17:36:11 <jaypipes> davidkranz_: yes, I believe that is the only thing we can feasibly do for now.
17:36:18 <jaypipes> davidkranz_: good topic for the design summit, though.
17:37:46 <jaypipes> OK, so back to my question.. who will do this work? rohit-k, are you comfortable incorporating these changes into your patch?
17:38:41 <rohit-k> jaypipes: yes, it looks good to me, just fear that the base class be misued with something like cls.manager = openstack.Manager(alt_credentials)
17:39:04 <jaypipes> rohit-k: sure, but that's for reviewers to catch ;)
17:39:09 <rohit-k> right
17:39:33 <rohit-k> jaypipes: Could you post that change?
17:39:49 <jaypipes> rohit-k: the one I just pasted?
17:39:56 <rohit-k> jaypipes: I think that looks great, that solves my problem
17:39:59 <rohit-k> yep
17:40:07 <jaypipes> rohit-k: ok, no worries. will do right after this meeting.
17:40:13 <rohit-k> jaypipes: thanks!
17:40:16 <jaypipes> np!
17:40:39 <jaypipes> dwalleck, fattarsi, davidkranz_, rohit-k: any other thoughts before we wrap up?
17:40:44 <davidkranz_> dwalleck: Daryl, do you have an ETA for your ssh-to-guests stuff. I would like to use it in the stress tests when it lands.
17:40:54 <rohit-k> i'd also like to discuss where we place the admin tests!
17:41:16 <rohit-k> jaypipes: like what was discussed in lp:97338
17:41:21 <rohit-k> lp:973338
17:41:28 <dwalleck> Just one comment with no good answer: so yesterday brought up the difficult question of how to handle tests when bugs are fixed :)
17:42:05 <dwalleck> I wish we could do something on the fly, but without a build number or something from OpenStack to tell if you should have this bug fixed in your environment, I don't see a good solution...
17:42:19 <jaypipes> rohit-k: I suggested /tempest/tests/compute/admin/. Wondering if others are cool with that?
17:42:51 <jaypipes> dwalleck: other than a config section like [bugs-fixed]? that lists fixed bugs? Not sure there's a good solution :(
17:43:04 <rohit-k> jaypipes: cool with me
17:43:28 <dwalleck> davidkranz_: That depends on which solution I use. If we're okay with (for now) manually setting which interface we ssh in over, by end of day tomorrow
17:44:02 <jaypipes> rohit-k: I say just use that directory...
17:44:11 <dwalleck> jaypipes: Yeah, I know...it bugs (no pun intended) me, so I'll keep thinking on it
17:44:12 <fattarsi> is anyone working on swift tests?
17:44:17 <davidkranz_> dwalleck: I thing that would be fine.
17:44:17 <jaypipes> rohit-k: if these guys don't like it, we can bring it up on review :)
17:44:30 <jaypipes> fattarsi: yes, Jose from RAX is.
17:44:38 <jaypipes> dwalleck: speakign of which :) any updates on that?
17:44:53 <rohit-k> jaypipes: sure :)
17:45:09 <dwalleck> Maybe instead of naming that group "broken tests", maybe it's a "it should be failing but if it does pass, great!"
17:45:39 <dwalleck> I was going to ping Jose and toss that to him, but he's not here....
17:45:48 <jaypipes> Also, please go voice support for my patch to devstack here: https://review.openstack.org/#change,6248,patchset=1  It gets the tempest config working again for our Jenkins job here: https://jenkins.openstack.org/view/Tempest/job/dev-gate-tempest-devstack-vm/
17:46:11 <davidkranz_> jaypipes: The nova bug I filed about that change in return code was never addressed so I guess the new value is what it is and we should fix and reenable the test.
17:46:33 <jaypipes> davidkranz_: sorry, which bug again?
17:46:41 <dwalleck> I need see what's going on there. I don't want to hold up work, but it would be really valuable to be able to port their tests in
17:47:12 <jaypipes> dwalleck: k. check with Jose... would indeed be great to demo Tempest Swift tests in design summit.
17:47:31 <davidkranz_> jaypipes: https://bugs.launchpad.net/nova/+bug/963248
17:47:33 <uvirtbot> Launchpad bug 963248 in nova "Return code for rebuild with non-existent image changed" [Undecided,New]
17:47:40 <jaypipes> aha!
17:47:45 <dwalleck> But on the ssh front, are folks okay with temporarily setting something like ssh_network and ssh_ip_version vars?
17:48:07 <jaypipes> davidkranz_: yeah, I will comment on the bug.
17:48:26 <jaypipes> dwalleck: in the [compute] config section? or ... somewhere else?
17:48:26 <dwalleck> I'm working on a clever way to just use the first reachable interface the tests can find, but I'm trying to take this slowly because if it doesn't work right, it can be very confusing
17:49:25 <dwalleck> jaypipes: it would probably go in the [compute] config section since it's only relevant to Nova. Or I could create a compute-network or compute-ssh config section as well
17:49:38 <davidkranz_> dwalleck: Well, we just 'ssh ip-address' to the guest usually so we could just use that as the default.
17:50:05 <dwalleck> davidkranz_: ? I don't follow
17:50:39 <dwalleck> How do you know if that IP address is reachable from your current network?
17:50:44 <davidkranz_> dwalleck: If the machine has a floating ip address and was created with an ssh key why can't we just ssh in like we would manually?
17:51:13 <davidkranz_> dwalleck: Of course this onlyh works in an encolsed test environment.
17:51:41 <dwalleck> davidkranz_: In a lot of the environments I work in, just because you have an assigned IP doesn't mean you can reach it
17:52:26 <dwalleck> Some of the IPs can even be fakes....so to make sure I can reach the instance, I manually set an interface per environment that I want to use SSH
17:52:27 <davidkranz_> dwalleck: But if the point is to have the test ssh to verify stuff you have to be able to get there, right?
17:52:28 <jaypipes> dwalleck: yeah, compute section is fine with me. was just curious...
17:52:50 <dwalleck> davidkranz_: it is! Actually, I can give you a real example....
17:53:31 <dwalleck> In one of my test environments, I have a public IPv4 address (which is fake), a public IPv6 address, and a private IPv4 address which is in a network I can't reach
17:53:56 <dwalleck> So ideally I'd want to use the public IPv6 address since it's the only one that would be accessible
17:54:17 <davidkranz_> dwalleck: I understand.
17:54:23 <dwalleck> In another environment I have publicly reachable IPv4 addresses but no IPv6 routing, so I need to use IPv4
17:55:59 <dwalleck> So I just want to make sure if we add this functionality, we can be explicit enough to make sure it's going to work
17:56:35 <dwalleck> And if it doesn't work, it's a failure. You have no idea the headache I went through the first time I hit that wall :)
17:57:28 <dwalleck> So what is the group think? Is manual okay for now or do you want auto config?
17:57:58 <davidkranz_> dwalleck: Manual today, auto tomorrow...
17:58:05 <jaypipes> sounds like a good compromise, yes.
17:58:14 <fattarsi> agreed
17:58:24 <jaypipes> I'd gladly pay today for an automation tomorrow ;)
17:58:29 <dwalleck> okay, good deal. I'll knock it out
17:58:39 <jaypipes> rock on.
17:58:53 <dwalleck> I'm excited :) This is where a lot of the work we've done is. We're doing some cool deep validation
17:58:53 <davidkranz_> jaypipes: But tomorrow is not Tuesday.
17:59:01 <dwalleck> Okay, I need to rush off to another meeting
17:59:01 <jaypipes> lol :)
17:59:17 <jaypipes> Keep an eye out for https://jenkins.openstack.org/view/Tempest/job/dev-gate-tempest-devstack-vm/, BTW. I'm going to work with jeblair to get that damn thing passing today!
17:59:21 <dwalleck> #endmeeting