Open Stack

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.
 * 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.
 * 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)

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.
 * 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.
   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.

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

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.

----- 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
>