Open Stack

Hi Yaniv, Nayna,

Thank you for your comments.

On Wed, 27 Mar 2013 01:52:36 +0000
"Patel, Nayna (Cloud Services)" <nayna.patel at hp.com> wrote:
> +1 
> Topic we need to discuss at the conf.
> 
> Nayna
> 

I've suggested a session for this topic.
 http://summit.openstack.org/cfp/details/204


> 
> On Mar 26, 2013, at 6:31 PM, "Yaniv Kaul" <Ykaul at redhat.com> wrote:
> 
> > Without the ability to configure OpenStack,  it's not going to fly.  Configure means:
> > 0. Installation scenarios (installation of different components on different hosts) 
> > 1. Ini files manipulation (nova.conf and friends)  and restarting services
> > 2. JSON files manipulation (policy files)
> > 3. Configuration via the API (and/or nova-manage)
> > 
> > The above are basic blocks to any true scenario (and end to end) testing.
> > Y. 

Good point. Indeed there is necessity for the true scenario testing.
We can discuss the way to implement the above (by Tempest or something else).


> > 
> > Masayuki Igawa <igawa at mxs.nes.nec.co.jp> wrote:
> > 
> > Hi,
> > 
> > Here is a blueprint I've registered.
> >  https://blueprints.launchpad.net/tempest/+spec/add-scenario-tests
> > 
> > This blueprint proposes to add a new category "scenario tests" in Tempest.
> > Scenario tests are for testing across the components such as Nova, Keystone, Glance and so on.
> > By scenario tests, developers will be able to check whether a new code (bug-fixes or features) will cause a side effect to the other components.
> > We will be able to check OpenStack basic functions by common use case scenarios.
> > I'd like to propose a minimum basic scenario test that must work at any OpenStack environments.
> > 
> > Implementation
> > ===============
> > * add tempest/tests/scenario directory
> > * add scenario tests in the directory like following
> > 
> > """
> > Scenario-1: very small cloud, basic life-cycle scenario, single-flavor, single-image, single-tenant...
> > - for admin user
> > 1. Create a flavor
> > 2. Create a image
> > 3. Configure network settings
> > 4. Create & configure a member role, a project, a quota, a user
> > - for regular user
> > 5. Create a key-pair
> > 6. Boot a instance. List & show the instance
> > 7. Create a volume. List & show the volume
> > 8. Attach the volume
> > 9. Detach the volume
> > 10. Delete the instance
> > - for admin user
> > 11. Delete the user, the role, the network, the image, the tenant, and the flavor
> > """
> > 
> > We think that the scenario tests can raise the use case coverage that is important for user's viewpoint.
> > 
> > We'd like to discuss the following points, so any comments are welcome.
> > * Points of the implementation
> >   * How do we implement the scenario tests?
> >     * via CLI/RestClient/client library...
> >     * Where do we implement in the directory?
> >   * Points of Scenarios
> >     * scenario categories: Private cloud, Public cloud, VPC
> >     * the scale: # of tenants, users, networks, and so on
> >     * the way of verifying: RESTful APIs, ping, ssh, and so on
> > 
> > 
> > Thanks,
> > Masayuki Igawa
> > 
> > _______________________________________________
> > 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


-- 
ＮＥＣソフト ITシステム事業部 クラウドサービス基盤開発G
井川　征幸(IGAWA Masayuki)  igawa at mxs.nes.nec.co.jp
---------------------------------------------------------------------
 《本メールの取り扱い》・区分：秘密  ・開示：必要最小限で可
  ・制限条件：重要扱い ・持出：禁止  ・期限：無期限   ・用済後：廃棄