Done.
On Fri, Jul 24, 2015 at 3:43 PM, Mark Nelson <mnelson@xxxxxxxxxx> wrote:
> Hi Konstantin,
>
> It might be best to move this to the cbt mailing list for discussion so that
> we don't end up filling up ceph-devel. Would you mind re-posting there?
>
> Mark
>
>
> On 07/24/2015 07:21 AM, Konstantin Danilov wrote:
>>
>> Hi all,
>> This is BP/summary for changes in cbt, we discuss on previous week.
>> Do I need to register it somewhere?
>>
>> Functional Goals
>> ================
>>
>> Primary
>> -------
>>
>> * Allow to test any block-storage device with same code
>> * Add openstack and FUEL support
>> * Allow to iterate tests on any parameter from configuration
>> * Add graph reports and statistic result processing
>> * Improve UX : make a package, put on pypi, allow to be installed
>> with pip; make docker image, put into docker images storage
>>
>> Secondary
>> ---------
>>
>> * Allow to execute in non-transitive networks
>> (where node A can connect to node B,
>> node B can connect to node C,
>> but node A can't connect to node C). This is often in
>> production environments
>> * Allow to fio task files for load description interchangeably
>> with yaml description
>> * Give roles to all discovered nodes to selectively run a
>> tests and gather resource usage info
>> * Allow to split configuration on parts
>> * Add support for hight-level tests - TCP, SPC-1
>> * Gather cluster(s) hardware and software configuration
>> * Allow to override configuration settings from command-line
>> * Add fio based tester, which uses fio tasks (as not all
>> parameters can be passed with cmd line)
>>
>> Structural goals
>> ================
>>
>> * Make code more pep-8 complaint
>> * Make a package and change all local import relative
>> * Allow to execute tests without bare minimum of packages
>> * Replace print with logging
>> * Store all test results in results directory
>> * Add ssh key support on node login
>> * Remove lxml dependency (xml.etree have all requires functions)
>>
>> Changes
>> =======
>>
>> Split code on stages. Each stage is a class:
>>
>> class IStage(object):
>> def enter(self, context, config):
>> pass
>>
>> def next_iteration(self, context, old_config, new_config):
>> pass
>>
>> def exit(self, context, config):
>> pass
>>
>> Stages are executed in order one-by-one. Each stages has
>> a separated part in configuraion, named after stage class.
>>
>> There a way to mark value in a configuration as an array of
>> values for cycle. Stages manage logic analyze configuration
>> and executes stages, selecting values from configuration in cycle.
>>
>> Example:
>> In this example each stage get only it part of config,
>> but in real code it would gets entire config.
>> '__' - marks cycle in config file.
>>
>> Config file:
>>
>> Stage1:
>> val1: __, [1, 2]
>> Stage2:
>> val2: 7
>> Stage3:
>> val3: __, [11, 12]
>> val4: __, [21, 22]
>>
>> Execution order:
>>
>> Stage1.enter({val1:1})
>> Stage2.enter({val2:7})
>>
>> Stage3.enter({val3:11, val4:21})
>> Stage3.reenter({val3:11, val4:21}, {val3:11, val4:22})
>> Stage3.reenter({val3:11, val4:22}, {val3:12, val4:21})
>> Stage3.reenter({val3:12, val4:21}, {val3:12, val4:22})
>> Stage3.exit({val3:12, val4:22})
>>
>> Stage2.exit({val2:7})
>> Stage3.reenter({val1:1}, {val1:2})
>> Stage2.enter({val2:7})
>>
>> Stage3.enter({val3:11, val4:21})
>> Stage3.reenter({val3:11, val4:21}, {val3:11, val4:22})
>> Stage3.reenter({val3:11, val4:22}, {val3:12, val4:21})
>> Stage3.reenter({val3:12, val4:21}, {val3:12, val4:22})
>> Stage3.exit({val3:12, val4:22})
>>
>> Stage2.exit({val2:7})
>> Stage3.exit({val1:2})
>>
>>
>> Execution goes up and down on tree, and don't skip stages.
>> Special reenter method allows stage to optimize configuration update.
>> Cycles need to be specially marked to separate array as one
>> value from array as list of values. Cycles, embedded in arrays
>> aren't supported.
>>
>> The first parameter, passed to each stage method is a context object.
>> This is common storage for stage results, used to pass data between
>> stages.
>>
>>
>> Stage list:
>>
>> Discover hardware or explicit nodes
>> Discover FUEL nodes
>> Discover openstack nodes
>> Discover openstack VM's
>>
>> Deploy ceph
>>
>> Start vm on openstack
>> Start sensors - ????
>>
>> Run tests
>>
>> Result statistical processing
>> Text report
>> Graphical report
>> Sensor data report
>>
>>
>> Allow to execute in non-transitional networks
>> ---------------------------------------------
>>
>> This is very often situation in corporate networks. It can be solved
>> with ssh port-forwarding. Where ssh ports from all nodes, invisible
>> from main node are mapped on ports on some node, visible from main.
>>
>> Thanks
>>
>
--
Kostiantyn Danilov aka koder.ua
Principal software engineer, Mirantis
skype:koder.ua
http://koder-ua.blogspot.com/
http://mirantis.com
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
