All, Great meeting today with LOTS of design detail about how the annealer works and what is "in band" and "out of band." We also talked about how/if you could use Crowbar with a Cloud API at the very end of the meeting.
Next meeting we will talk about roadmaps. http://pad.opencrowbar.org/p/community-design-meeting-2014-07-09 OpenCrowbar Design Meeting 2016-07-09 10am Central ============================================ Video: http://youtu.be/Fi4yk8PLyvI New Install Video > http://youtu.be/OmeiZrtqOfI # Design Meeting Agenda * Updates * Impact of WSMAN API * Chef Metal * RPM install maintenance * Use cases for power management * * how to handle VMs * Cloud API Jig * "As an operator, I want Crowbar to provision nodes in cloud infrastructure instead of needed physical gear. In those cases, I would create a node in Crowbar of "cloud" type and Crowbar would use the cloud's APIs to create a managed node that would be managed by the Crowbar orchestration. This allows me to run/test my deployment scripts against elastic workloads without needed physical infrastructure." * Wizards for Workloads (now that we have Ready State Wizard) * Extending Travis CI to workloads * Docs publishing HTML # Topics ## Updates WSMAN API integration can now manage the power via the Ruby bindings. (Rob has validated this is working against Victor's branch) ReadyState Wizard merged Travis CI nearly working on BDD Meshiest UI Changes > yes to alternating lines ## Impact of WSMAN API Future design to get more late binding > break disk node_roles into parts so that we can "late bound" down to the disk level Current design combines inventory & configuration into a single node_role. Design challenges * need to have a way that a single action could be in OR out of band * need to be able to manage nodes outside of context of "node roles" - things that are not states, but point configuration Definitions: out of band control path: run a command external to the node's operating system. * For example, changing the power from the BMC network * Could be actions take NOT by Crowbar * If a network port on the switch in band control path: run a command from the node's operating system. you are running on the node itself (in the node's OS) > Note: Node_Roles are about CLUSTER STATE Thinking ahead > disk roles will have an inventory of disks that are managed as parts. Would the same thing happen when we get to managing switches? Each port would be inventory. On Graph: Things we do to bring a cluster to an operational state. Off Graph: Monitoring data, or command and control for nodes themselves. Network config is in-band on OS. * Use cases for power management * * how to handle VMs * ## Chef Metal Rob to write use cases, further discussion at Planning ## RPM install maintenance Get working RPMs, local generation..."make RPM script" post to location TBD. ### Cloud API Jig * "As an operator, I want Crowbar to provision nodes in cloud infrastructure instead of needed physical gear. In those cases, I would create a node in Crowbar of "cloud" type and Crowbar would use the cloud's APIs to create a managed node that would be managed by the Crowbar orchestration. This allows me to run/test my deployment scripts against elastic workloads without needed physical infrastructure." * There are concerns if this is something Crowbar should do. ## Push to Next Design Meeting Agenda for Planning * Chef Metal * Ceph & Core Blocker Design * Wizards for Workloads (now that we have Ready State Wizard) * Extending Travis CI to workloads * Docs publishing HTML Rob ______________________________ Rob Hirschfeld blog robhirschfeld.com, twitter @zehicle Please note, I am based in the CENTRAL (-6) time zone
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
