Jump to: navigation, search

Difference between revisions of "PolicyGuidedFulfillmentLibertyPlanning"

(Murano)
Line 19: Line 19:
 
=== Murano ===
 
=== Murano ===
  
* '''''Improving Murano API/core-model for better integration with Congress datasource'''''
+
* '''''Improving Murano API/core-model for better integration with Congress datasource'''''  
 
** Goal is to improve Murano Congress Datasource
 
** Goal is to improve Murano Congress Datasource
 
** API: listing of environments from all tenants, more topo/type info in responses  
 
** API: listing of environments from all tenants, more topo/type info in responses  
 
** Core topology model: provide more details on provisioned core components - e.g., server id and heat id in Instance,...
 
** Core topology model: provide more details on provisioned core components - e.g., server id and heat id in Instance,...
 +
* see [[PolicyGuidedFulfillmentLibertyPlanning_MuranoAPI]]
  
  

Revision as of 09:16, 12 May 2015

Policy Guided Fulfillment - Liberty Planning

Policy Guided Fulfillment Main Page

Completed work in Kilo

  • Murano - Congress integration
    • Murano updated to check with Congress policy as part of provisioning steps
      • predeployment enforcement
    • New Murano data source in Congress
    • Contributed to adding reactive policy enforcement using action execution in Congress
  • Murano - Mistral Integration
    • Added the option to invoke a Mistral workflow as part of Murano application model


Check topic PolicyGuidedFulfillmentDemo for demo of features.

Planning topics for Liberty

Murano

  • Improving Murano API/core-model for better integration with Congress datasource
    • Goal is to improve Murano Congress Datasource
    • API: listing of environments from all tenants, more topo/type info in responses
    • Core topology model: provide more details on provisioned core components - e.g., server id and heat id in Instance,...
  • see PolicyGuidedFulfillmentLibertyPlanning_MuranoAPI


  • Workflow embracement
    • Currently it is possible to use Mistral workflow in Murano component action. The next step is to create component completely from the Mistral workflow, so any component action will be implemented by an action. During embracement (i.e., process of component creation from workflows) it should be possible to specify a) dependencies of the component on other components (e.g., Instance); b) mapping of workflow's input and output from/to component properties.


  • Workflow based deployment
    • When all components in an environment will be built from workflows, it will be possible to create master workflow which orchestrate deployment of whole environment. Complete deployment execution on workflow engine will be scalable, reliable and robust.
    • To provide this, we need to have dual (supports both MuranoPL and Workflow components) or alternative implementation of core classes (e.g., Environment, Instance, Neutron network, ...).


  • Policy based monitoring enabling (Ceilometer/Monasca) during provisioning and subsequent monitoring and enforcement
    • Goal is to be able to simply control application scalability via Congress policies using telemetry (e.g., Ceilometer, Monasca) data.
    • There will be two phases
      • environment modification at predeploy time
        • prior predeploy_error evaluation, there will be policy monitoring evaluated (via simulation). It will contain rules which execute actions modifying environment in Murano by adding (via Murano REST) monitoring components. Such monitoring components are responsible for configuration of corresponding monitoring system (e.g., Ceilometer's alarms,....). User can create component for any monitoring system (e.g., watch dogs to check running Tomcat,DB,...)
      • public action invocation at runtime
        • it defines binding between monitoring system and Murano. If rule detects monitoring event, it executes corresponding action in Murano (e.g., invocation of public action "scaleOut" on scalable component, ...)

Example

component type - Ceilometer , its input parameters are 'relation to Instance', and  'alarm definition'. On deploy it creates alarm in Ceilometer.
Policy rules:
execute[ add-object-to-murano(envid, name, type, instance=instance-id, alarm_expression='cpu_util>50') ] :- murano:object(instance-id,parent-id,'Instance'), murano:connected(envid, instrance-id), murano:relationships(tomcat-id,instance-id, 'instance'), murano:objects(tomcat-id, parent-id2, 'Tomcat'),....
execute[murano-action(envid, scalableObject, 'scale-out' ) :- ceilometer:alarm(...instance-id,...), murano:object(instance-id,parent-id,'Instance'), murano:connected(env-id, instance-id),murano:relationships(tomcat-id,instance-id, 'instance'), murano:objects(tomcat-id, parent-id2, 'Tomcat')
  • Support any workflow engine in Murano //[avigail] seems that this already exist in Murano. we are currently verifying it.
    • [Radek] Avigail/Natasha will provide more info latter

Congress

  • Remediation via Mistral workflows
    • Congress' action execution feature will trigger Mistral workflow implementing remediation for given situation/breach. Mistral workflow can use Murano components action, any O~S API, ...
    • Example:
execute[murano:muranoaction(env-id, obj-id, 'restart')] :- watchdog:not-responding(server-uuid), murano:properties(vmid,'server',server-uuid), murano:objects(vmid, parent, 'Instance'), murano:connected(env-id, vm-id), murano:objects(env-id, p2, 'Environment')


  • Improve the basic action execution based on usage
    • see above remediation story.


  • Accelerate the Datalog Horizon UI work started in Kilo


  • Performance validation of Congress with large data sets


  • Follow the delegation PoC work and updates at summit demo


  • Add new Monasca data source driver


  • Evaluate/contribute to Heat data source driver