Open Stack

On 06/07/2013 03:42 AM, Attila Fazekas wrote:
> I have several questions and concerns.
>
> 1. role based user creation
>   * As we discussed long time ago the user creation should be based on the roles.

That is precisely what is demonstrated below. 'non-admin' and 'admin' 
are roles.

>   * As I remember you wanted to distinguish the compute admin from the identity admin,
>     we could use even richer model, the rule based negative test are missing from tempest now.

I don't understand what this means. Could you elaborate please?

>   * The identity admin credentials does not necessarily be known (not my use case), AFAIK several user
>    wants to use tempest just with the predefined users.
>    (If this use case does not really exists, it can simplify lot of things)

Are you asking whether Tempest should not create users for use in its 
tests? As I've said previously, this was done for two reasons:

1) To get past many issues with quotas for a tenant
2) To provide the basis for parallel execution -- if you are running X 
compute tests in parallel with the exact same user, you are needlessly 
going to run into issues where calls to things like GET 
/<TENANT>/servers is going to return non-deterministic results between 
processes

What are you thinking will be simplified by removing Tempest's test 
tenant/user isolation?

> 2. keystone stress
>   * if we have all test cases to request multiple tokens
>     and create users and tenants and set the quota set,  it will be a lot of overhead.

The volume is the same on Keystone tokens regardless of number of 
Keystone users you use to run tests. In the default Keystone, every 
request to any endpoint is going to involve a token, and that token will 
need to be validated on each REST call. Makes no difference whether it's 
1 user or >1 user running the tests.

>   * token request if the token request math /test case is
>     number_of_used_users * number_of_used_clients * number_of_impersonate_switch,
>     is not too efficient.

That is incorrect. Number of token requests is number of requests made 
to any endpoint. Has nothing to do with number of users.

With PKI, the auth_token middlewares can cache a user's token and reduce 
the number of requests to the Keystone API server, true, and the number 
of users would affect the number of cached tokens the auth_token 
middleware would cache.  But, I believe that focusing on these 
micro-performance issues/optimizations is missing the point of using 
multiple users: to better isolate the test cases from the actions of 
other users.

>     The RSA signing is not cheap operation, the request/response latency is measurable side
>     effect anyway.
>     Does it scales well with multi-thread ?.
>     Keystone uses cPython and we just have 1 keystone process on the gate.

This is a deployment issue, frankly. We can change the gate to put 
Keystone in an Apache wsgi servlet container and multiplex Keystone API 
that way.

> 3. multiple client tool chain usage
>   * how will this model will be usable for multiple client usage /per test case ?

Not sure what you mean by this. Could you elaborate a bit more, perhaps 
with an example piece of code?

> 4. resource sharing
>   * several resource creation does not scales well for example the server creation.
>     The owner tenant members has more capabilities on given server resource,
>     if you want to combine the servers with another resources, the owner tenant is a more important fact.

You lost me on this one, Attila :) I don't understand what you mean by this.

Best,
-jay

> ----- Original Message -----
>> From: "Jay Pipes" <jaypipes at gmail.com>
>> To: openstack-qa at lists.openstack.org
>> Sent: Thursday, June 6, 2013 4:04:35 PM
>> Subject: Re: [openstack-qa] Tempest Architecture/Design brainstorming
>>
>> On 06/06/2013 01:57 AM, Attila Fazekas wrote:
>>> Hi All,
>>>
>>> I am looking for ideas for unifying the tempest "Object Model" and to
>>> enhance it's capabilities.
>>>
>>> Several interesting topic:
>>> - Plug-ability
>>> - Identity management ("impersonate the right person efficiently")
>>
>> I put together a proof of concept of this exact functionality using
>> fixtures.Fixture and a context manager called acting_as() [1] that was
>> extended by subclasses' do_as() method [2] to make it easy to write
>> clean impersonation code [3]:
>>
>> class TestFlavorsNonAdmin(base.ComputeApiTest):
>>
>>       def test_list_flavors(self):
>>           with self.do_as('non_admin') as client:
>>               flavors = client.flavors.list()
>>               self.assertTrue(len(flavors) > 0)
>>
>>       def test_unauthorized(self):
>>           with self.do_as('non_admin') as client:
>>               self.assertRaises(Exception, client.flavors.create,
>> 'flavorname')
>>
>>
>> class TestFlavorsAdmin(base.ComputeApiTest):
>>
>>       def test_list_flavors(self):
>>           with self.do_as('admin') as client:
>>               flavors = client.flavors.list()
>>               self.assertTrue(len(flavors) > 0)
>>
>>       def test_crud(self):
>>           with self.do_as('admin') as client:
>>               flavor_name = self.getUniqueString("flavor")
>>               flavor = client.flavors.create(flavor_name, 64, 1, 10)
>>               self.assertEqual(flavor_name, flavor.name)
>>               self.assertEqual(64, flavor.ram)
>>               self.assertEqual(1, flavor.vcpus)
>>               self.assertEqual(10, flavor.disk)
>>               flavors = client.flavors.list()
>>               flavor_ids = [x.id for x in flavors]
>>               self.assertIn(flavor.id, flavor_ids)
>>               flavor = client.flavors.find(name=flavor_name)
>>               self.assertEqual(flavor_name, flavor.name)
>>               self.assertEqual(64, flavor.ram)
>>               self.assertEqual(1, flavor.vcpus)
>>               self.assertEqual(10, flavor.disk)
>>               client.flavors.delete(flavor.id)
>>
>> Best,
>> -jay
>>
>> [1]
>> https://github.com/jaypipes/tempest/blob/api/tempest/tests/api/base.py#L89
>> [2]
>> https://github.com/jaypipes/tempest/blob/api/tempest/tests/api/compute/base.py#L27
>> [3]
>> https://github.com/jaypipes/tempest/blob/api/tempest/tests/api/compute/test_flavors.py
>>
>>
>>> - test case selection (based on supported feature, installed services..)
>>>
>>> An ideal proposal should answer the
>>> - What you would like to achieve.
>>> - Why do you want/need this.
>>> - How do you want to do it.
>>>
>>> Feel free to add incomplete idea as well.
>>>
>>> Best Regards,
>>> Attila
>>>
>>> PS.: python is not juts OOP language,
>>> we should use the imperative and functional programming styles as well.
>>>
>>> _______________________________________________
>>> openstack-qa mailing list
>>> openstack-qa at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa
>>>
>>
>>
>> _______________________________________________
>> openstack-qa mailing list
>> openstack-qa at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa
>>
>
> _______________________________________________
> openstack-qa mailing list
> openstack-qa at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa
>