Name: solar
Owner: Mirantis Inc.
Description: This repo is OUTDATED!!! We moved to OpenStack
Created: 2015-07-01 14:12:04.0
Updated: 2017-07-12 08:54:41.0
Pushed: 2015-12-14 18:33:14.0
Homepage: https://github.com/openstack/solar
Size: 2993
Language: Python
GitHub Committers
User | Most Recent Commit | # Commits |
---|
Other Committers
User | Most Recent Commit | # Commits |
---|
Linux or MacOS
VirtualBox: 5.x
Vagrant: 1.7.x
Note: Make sure that Vagrant VirtualBox Guest plugin is installed vagrant plugin install vagrant-vbguest
Note: If you are using VirtualBox 5.0 it's worth uncommenting paravirtprovider setting in vagrant-settings.yaml
for speed improvements:
virtprovider: kvm
For details see Customizing vagrant-settings.yaml
section.
Setup environment:
olar
ant up
Login into vm, the code is available in /vagrant directory
ant ssh
r --help
Get ssh details for running slave nodes (vagrant/vagrant):
ant ssh-config
You can make/restore snapshots of boxes (this is way faster than reprovisioning them)
with the snapshotter.py
script:
apshotter.py take -n my-snapshot
apshotter.py show
apshotter.py restore -n my-snapshot
snapshoter.py
to run requires python module click
.
sudo aptitude install python-click-cli
,sudo dnf install python-click
,pip install click
,sudo pip install click
.pip
then install it and then execute command step 4.For now all commands should be executed from solar-dev
machine from /vagrant
directory.
Basic flow is:
examples/openstack/openstack.py
) and connect
them between each other, and place them on nodes.solar changes stage
(this stages the changes)solar changes process
(this prepares orchestrator graph, returning
change UUID)solar orch run-once <change-uuid>
(or solar orch run-once last
to run the lastly created graph)watch 'solar orch report <change-uuid>'
(or watch 'solar orch report last'
).Some very simple cluster setup:
vagrant
r resource create nodes templates/nodes.yaml '{"count": 2}'
r resource create mariadb_service resources/mariadb_service '{"image": "mariadb", "root_password": "mariadb", "port": 3306}'
r resource create keystone_db resources/mariadb_db/ '{"db_name": "keystone_db", "login_user": "root"}'
r resource create keystone_db_user resources/mariadb_user/ user_name=keystone user_password=keystone # another valid format
r connect node1 mariadb_service
r connect node1 keystone_db
r connect mariadb_service keystone_db '{"root_password": "login_password", "port": "login_port", "ip": "db_host"}'
lar connect mariadb_service keystone_db_user 'root_password->login_password port->login_port' # another valid format
r connect keystone_db keystone_db_user
r changes stage
r changes process
id>
r orch run-once <uid> # or solar orch run-once last
h 'solar orch report <uid>' # or solar orch report last
You can fiddle with the above configuration like this:
r resource update keystone_db_user '{"user_password": "new_keystone_password"}'
r resource update keystone_db_user user_password=new_keystone_password # another valid format
r changes stage
r changes process
>
r orch run-once <uid>
To get data for the resource bar
(raw and pretty-JSON):
r resource show --tag 'resources/bar'
r resource show --json --tag 'resources/bar' | jq .
r resource show --name 'resource_name'
r resource show --name 'resource_name' --json | jq .
To clear all resources/connections:
r resource clear_all
Show the connections/graph:
r connections show
r connections graph
You can also limit graph to show only specific resources:
r connections graph --start-with mariadb_service --end-with keystone_db
You can make sure that all input values are correct and mapped without duplicating your values with this command:
r resource validate
Disconnect
r disconnect mariadb_service node1
Tag a resource:
r resource tag node1 test-tags # Remove tags
r resource tag node1 test-tag --delete
Creating resources:
solar.core.resource import virtual_resource as vr
1 = vr.create('node1', 'resources/ro_node/', 'rs/', {'ip':'10.0.0.3', 'ssh_key' : '/vagrant/tmp/keys/ssh_private', 'ssh_user':'vagrant'})[0]
2 = vr.create('node2', 'resources/ro_node/', 'rs/', {'ip':'10.0.0.4', 'ssh_key' : '/vagrant/tmp/keys/ssh_private', 'ssh_user':'vagrant'})[0]
tone_db_data = vr.create('mariadb_keystone_data', 'resources/data_container/', 'rs/', {'image' : 'mariadb', 'export_volumes' : ['/var/lib/mysql'], 'ip': '', 'ssh_user': '', 'ssh_key': ''}, connections={'ip' : 'node2.ip', 'ssh_key':'node2.ssh_key', 'ssh_user':'node2.ssh_user'})[0]
_db_data = vr.create('mariadb_nova_data', 'resources/data_container/', 'rs/', {'image' : 'mariadb', 'export_volumes' : ['/var/lib/mysql'], 'ip': '', 'ssh_user': '', 'ssh_key': ''}, connections={'ip' : 'node1.ip', 'ssh_key':'node1.ssh_key', 'ssh_user':'node1.ssh_user'})[0]
To make connection after resource is created use signal.connect
.
To test notifications:
tone_db_data.args # displays node2 IP
2.update({'ip': '10.0.0.5'})
tone_db_data.args # updated IP
If you close the Python shell you can load the resources like this:
solar.core import resource
1 = resource.load('rs/node1')
2 = resource.load('rs/node2')
tone_db_data = resource.load('rs/mariadb_keystone_data')
_db_data = resource.load('rs/mariadb_nova_data')
Connections are loaded automatically.
You can also load all resources at once:
solar.core import resource
resources = resource.load_all('rs')
Solar CLI has possibility to show dry run of actions to be performed. To see what will happen when you run Puppet action, for example, try this:
r resource action keystone_puppet run -d
This should print out something like this:
UTED:
cb1cf7f6cdd38d04dd2d0a0729f8: (0, 'SSH RUN', ('sudo cat /tmp/puppet-modules/Puppetfile',), {})
d7773ce74187d5108ace0717ef29: (1, 'SSH SUDO', ('mv "1038cb062449340bdc4832138dca18cba75caaf8" "/tmp/puppet-modules/Puppetfile"',), {})
d2455fe2b02ba46b4b7727eff01a: (2, 'SSH RUN', ('sudo librarian-puppet install',), {})
64fa257ed3159d1788f73c755f44: (3, 'SSH SUDO', ('puppet apply -vd /tmp/action.pp',), {})
By default every mocked command returns an empty string. If you want it to return something else (to check how would dry run behave in different situation) you provide a mapping (in JSON format), something along the lines of:
r resource action keystone_puppet run -d -m "{\"73c\": \"mod 'openstack-keystone'\n\"}"
The above means the return string of first command (with hash 73c6c...
) will be
as specified in the mapping. Notice that in mapping you don't have to specify the
whole hash, just it's unique beginning. Also, you don't have to specify the whole
return string in mapping. Dry run executor can read file and return it's contents
instead, just use the >
operator when specifying hash:
r resource action keystone_puppet run -d -m "{\"73c>\": \"./Puppetlabs-file\"}"
You can compile all meta.yaml
definitions into Python code with classes that
derive from Resource
. To do this run
r resource compile_all
This generates file resources_compiled.py
in the main directory (do not commit
this file into the repo). Then you can import classes from that file, create
their instances and assign values just like these were normal properties.
If your editor supports Python static checking, you will have autocompletion
there too. An example on how to create a node with this:
rt resources_compiled
1 = resources_compiled.RoNodeResource('node1', None, {})
1.ip = '10.0.0.3'
1.ssh_key = '/vagrant/.vagrant/machines/solar-dev1/virtualbox/private_key'
1.ssh_user = 'vagrant'
There's also a higher-level API that allows to write resource instances in more
functional way, and in particular avoid for
loops. Here's an example:
solar import template
s = template.nodes_from('templates/riak_nodes.yaml')
_services = nodes.on_each(
'resources/riak_node',
{
'riak_self_name': 'riak{num}',
'riak_hostname': 'riak_server{num}.solar',
'riak_name': 'riak{num}@riak_server{num}.solar',
}
_master_service = riak_services.take(0)
_slave_services = riak_services.tail()
_master_service.connect_list(
riak_slave_services,
{
'riak_name': 'join_to',
}
For full Riak example, please look at examples/riak/riaks-template.py
.
Full documentation of individual functions is found in the solar/template.py
file.
Solar is shipped with sane defaults in vagrant-setting.yaml_defaults
. If you need to adjust them for your needs, e.g. changing resource allocation for VirtualBox machines, you should just compy the file to vagrant-setting.yaml
and make your modifications.
vagrant-setting.yaml_defaults
or vagrant-settings.yaml
file uncomment preprovisioned: false
line.vagrant up
, it will take some time because it builds image for bootstrap and IBP images./vagrant/examples/provisioning/provision.sh