Community Meeting Notes 01-07-2015
Judd Maltin
OpenCrowbar Community Meeting 01-07-2014
Agenda:
Services - a new feature of Crowbar
Review for the Newbies
Design depth
Rework of Overall Install
RPMs install script
Public Website updates to reflect changes
Services:
General Idea of a Service:
Help using OpenCrowbar in a Brownfield or non-green field situation. For example: If I already have a DNS server that I am managing that I want everyone to use, including Crowbar. Crowbar wouldn’t control it, but would be able to update it for the nodes it’s in control of.
Goal is to decouple the installation of the endpoint service and the management of that service. E.g. instead of ISC’s DNS (BIND), you’d rather use PowerDNS, or other with an API.
To set up a service: create a file that sets up teh service for Crowbar, and points crowbar to that Service.
To update a service: sometimes we need to update service configurations for the nodes.
The core becomes a compact, tight orchestration that makes sure that attributes and services are met in an ordered mechanism. Then the services can live outside crowbar (if desired) and managed cooperatively.
Current Work in Services:
POC work over the past two weeks: Create a DNS set of roles (barclamp) to create the service. Use the “noderole” model instead of creating a “service” model, so the orchestration can manage both. Side effect: “system nodes” or “phantom nodes” These nodes do not have a “real thing” behind it. Doesn’t have all the things that make a node a node, but you CAN apply noderoles to them. But the intervening Jig wouldn’t apply. “Role based Jig” allows us to say that the Role provides all the Jig functionality. It attaches to Consul and reports availability. Push services into Consul, and it’s propagated to all other nodes. Admin node no longer needs to have all the services in it - now can do HA more easily in Admin node. “Service Role” waits for service to become available. Records and puts attribute into system, and now downstream noderoles can operate on that service. Those “Service Roles” have a long term communication with crowbar - and if the service changes, then downstream noderoles can utilitze that refreshed data.
Management Service:
When a downstream noderole needs to change DNS information, it would be nice if there was an API endpoint that you could look up and effect the change. On DNS value changes, instead of the noderole graph changing, it is changed via API.
Blurry line in construction, operation and consumption of service. DNS clients don’t care about the configuration of the service they are calling, they just need the endpoint info. DNS servers need to be installed and have access credentials and minimal configuration. For some services, that’s enough. In between, in operations, we need tweaks, adds, and other changes. Some services already have APIs to do this. Consul has an API - has a configuration, management and consumption API. Three things are separated out - separation of concerns. We hope to create a set of API shims that know how to make the operational changes. Sibling level shim that managed BIND, *and* PowerDNS, etc.
SystemD:
Did an experiment - created a container in Centos7, but still doesn’t work for older Linuxes. Cent 6.x is the blocker.
Role system and its dependencies beginning to look similar to SystemD. We’re trying to do it remotely - “SystemD and FleetD” is a similarish idea. FleetD is using etcd, while crowbar is using Consul.
But NETWORKING! We depend on the admin network everywhere - but really what I want is “some” network. NodeRoles that are network presence aware.
Goals:
Optional pull request will be available soon for the Service Abstraction piece with empty shell roles. Then work on management services piece by building example API server shims sitting wherever, and crowbar and install/discover and manage them.
Security Focus:
Setup a PKI infra. Need more robust user model. Special users and credential management for system services. Need to move away from Devise (which assumes you’re a human on the Internet)
Installation Changes:
All work is in development branch. Not validated and tested to release branch. Camshaft.1 is baking.
Production.sh now calls 5 scripts in a row. For more deployment flexibility. As a result of the Services work… don’t have to have everything on one system.. so, several different scripts that can be run locally or on a separate server/container. You’d use these different scripts on different servers where appropriate. You can even omit some of the scripts if you have a service already running that you want to use in place of Crowbar’s version of the service.
Converts our base system to centos 6.6, fwiw.
RPMs - what’s cookin?
Master branch in Github/opencrowbar/core now has a set of RPM install scripts that you can use to take a centos 6.5 system and wget the install script, install repos, pull RPMs, tweak the node (network, firewalls, selinux.) After running the script, (choosing Hardware.rpm if you want, or Packstack.rpm from RackN, Inc, if you like) you can then run ./production.sh to get Crowbar up and running.
There’s now a “developement” set of RPMs that are generated on big development checkins (like the breakup of production ssh.) So, if you call the install script with ‘--develop’ it will install the “development” RPMs.
In RPM repo, earlier, there was a ruby rpm. That’s been split out and now in it’s own opencrowbar-ruby repo, so if we get to an OS update that supports ruby 2.x we will drop the unnecessary repo.
RHEL
We don’t have a license. I’ll ask for one.
--
T: 917-882-1270
| Of Life immense in passion, pulse, and power, | |
| Cheerful—for freest action form’d, under the laws divine, | |
| The Modern Man I sing. -Walt Whitman |