We did this for the test environment using a dictionary. the form of that dictionary is as follows:

DEFAULT_WBEM_SERVER_MOCK_DICT = {
    'dmtf_schema': {'version': DMTF_TEST_SCHEMA_VER,
                    'dir': TESTSUITE_SCHEMA_DIR},
    'class_names': ['CIM_Namespace',
                    'CIM_ObjectManager',
                    'CIM_RegisteredProfile',
                    'CIM_ElementConformsToProfile',
                    'CIM_ReferencedProfile',
                    'CIM_ComputerSystem'],
    'class-mof': ["class MCK_StorageComputerSystem : CIM_ComputerSystem{};", ],
    'system_name': 'Mock_WBEMServerTest',
    'object_manager': {'Name': 'FakeObjectManager',
                       'ElementName': 'Pegasus',
                       'Description': 'Pegasus CIM Server Version 2.15.0'
                                      ' Released', },
    'interop_namspace': 'interop',
    'other_namespaces': [],
    'registered_profiles': [('DMTF', 'Indications', '1.1.0'),
                            ('DMTF', 'Profile Registration', '1.0.0'),
                            ('SNIA', 'Server', '1.2.0'),
                            ('SNIA', 'Server', '1.1.0'),
                            ('SNIA', 'SMI-S', '1.2.0'),
                            ('SNIA', 'Array', '1.4.0'),
                            ('SNIA', 'Software', '1.4.0'),
                            ('DMTF', 'Component', '1.4.0'), ],

    'referenced_profiles': [
        (('SNIA', 'Server', '1.2.0'), ('DMTF', 'Indications', '1.1.0')),
        (('SNIA', 'Server', '1.2.0'), ('SNIA', 'Array', '1.4.0')),
        (('SNIA', 'Array', '1.4.0'), ('DMTF', 'Component', '1.4.0')),
        (('SNIA', 'Array', '1.4.0'), ('SNIA', 'Software', '1.4.0')),

1. Either yaml file or dictionary. We agreed that this should be yaml.

2. The idea of packaging each profile as a separate entity is logical.

3. The packages we could consider separately are the mock_server itself including parameters, interop namespace, etc, profile including their names, and all classes/instances, and user-providers (are there user-providers outside of profiles???).

We agreed that yaml is a logical format, it should have essentially the same characteristics as a python dictionary so that just about everything we could do with a python dictionary as the controlling structure we could do with yaml.

The goal: To package the requirements for installation of a defined profile as a single file so that it could be installed by a package like pywbemcli. NOTE: It is not clear that this is just a pywbemcli requirement but it is a good place to start.

Packaging a profile requirements:

1. Name and version of the profile.
2. Prerequisite profiles and providers. What must be installed before this profile can be installed.
3. Namespace for the profile installation. Since this installs the profile itself, the only connection to registrations is that a profile registration mechanism must have already been installed.. Thus a prerequisite would be a profile_registration profile. This means that since profile implementations are defined in a user namespace, the prerequisite is that the user namespace be defined.
4. Classes that are required for the profile. Note that this can be any of several ways of defining the classes including:
   a. dmtf schema and leaf class list (
   b. MOF with classes ( MOF file(s)
   c. CIM Objects to be installed (Python)
   3, Instances of classes for the profile including all associations.

Actions required of the install process:

1. Validate prerequisites. If we can get everything packaged then all that we would have to do is to validate previous mock component packages (ex. profiles) have been installed.

2. Determine that the user namespace exists or create it.

3. Install the required classes. Note that this is only the classes for this profile. Classes like RegisteredProfile, etc. are installed as part of their own package.

4. Install the instances of the profile.

5. Define the registration components (RegisteredProfile, Implements...). This should simply execute something defined by the package that defiles the profile registration components so that this should be a call to something else with just the scoping / central instances and the profile definition (name, org, version).

TODO: Expand this for component profiles.

Definition of the mock-server

1. creates conn.
2. defines interop namespace
3. defines dmtf schema (optional)
4. Defines user providers required outside of profiles.
5. Defines other namespaces (Optional)
6. Sets up any special requirements (verbosity statistics collection, etc.) that would be part of the mock.

RESULT: Conn created, interop namespace created, other namespaces created. installs any names user providers.

1. Allow definition of schema at the level of the profile. So that each profile could install install from a separate DMTF schema.

2. We are talking about an aggregator mechanism and references other components (mof files, etc.)

3. This should go into pywbem_mock so that the packaging concept and the methods that use the yaml are in pywbem mock but available from tools like pywbemcli.

Move to 0.9.0. Give ourselves time to consider based on work with caching.

DISCUSSION: Do we still need this given that we have mock scripts?

We decided to keep this one open and karl wants to come up with a more concrete proposal.

We agreed to explore those things that are difficult to do in the current scripts and see what can be simplified with new or modified function definitions.