Skip to content
This repository has been archived by the owner on Jun 18, 2021. It is now read-only.

openstack playbooks #70

Merged
merged 32 commits into from
May 13, 2016
Merged

openstack playbooks #70

merged 32 commits into from
May 13, 2016

Conversation

joshmoore
Copy link
Member

@joshmoore joshmoore commented Apr 29, 2016

This removes the requirement on checking out a branch from @manics as well as the bootstrap script. This means the benefits described in the README are no longer possible, but with the introduction of the dynamic inventory I think this is balanced out. The general workflow is actually quite nice:

  • ansible-playbook ... os-create.yml
  • ansible-playbook ... os-omero.yml
  • ... any other playbooks ...
  • ... do your testing ...
  • ansible-playbook ... os-delete.yml

I'd even like to see this runnable by devspace in a "ci" tenancy.

Questions:

  • At this point should openstack/*.md moves to docs and openstack/examples/*.yml move to ansible?
  • With 41ecc02, can 00_openstack.sh be reduced/removed?
  • Remove omero usage from the os-*.yml files?

------------------------

You can take advantage of an [Ansible dynamic inventory script for OpenStack (`openstack.py`)](http://docs.ansible.com/ansible/intro_dynamic_inventory.html#example-openstack-external-inventory-script) instead of having to manage an inventory file when using Ansible to push out changes.
This direectory takes advantage of an
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

directory


ansible-playbook idr-os-playbook.yml -e "omero_vm_key_name='My Keypair'"
ansible-playbook os-create.yml -e omero_vm_name=FOO -e omero_vm_key_name=YOURKEY \
-e "omero_vm_flavour='My Keypair'"
Copy link
Member

@manics manics Apr 29, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

omero_vm_flavour='My Keypair': change the param value to an example flavour (m1.* are standard)

Copy link
Member Author

@joshmoore joshmoore Apr 29, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...ok, but this is from you! 😄

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope. I'm just wrong.

To delete the VM and related security group:

ansible-playbook idr-os-playbook-delete.yml
ansible-playbook os-delete.yml
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you're editing this doc, worth mentioning that deleting the security group will fail (and can be ignored) if anything else is using that group?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I looked into: "if unused" but didn't find anything. Will push.

@manics
Copy link
Member

manics commented Apr 29, 2016

👍, a few small comments inline.

FYI I was thinking of an all-in-one playbook for the IDR to spin up one or more VMs (e.g. separate postgres, I think this is needed to avoid future performance/debugging issues), and to run the required playbook roles- I think it's possible with the add_host. But that's for a future PR

@manics
Copy link
Member

manics commented Apr 29, 2016

One more, fix the playbook name at the at the top of os-delete.yml: # Delete VMs and security groups created by idr-os-playbook.yml

@joshmoore
Copy link
Member Author

Pushed a first round of fixes. Need to discuss groups first.

@joshmoore
Copy link
Member Author

Pushed better group names. Done unless you have suggestions.

@joshmoore
Copy link
Member Author

FYI I was thinking of an all-in-one playbook for the IDR to spin up one or more VMs ... I think it's possible with the add_host. But that's for a future PR

Same here. I was assuming with an include an add_host wouldn't be necessary, but isn't so bad if it is.

@joshmoore
Copy link
Member Author

add_host example in place, using files migrated from https://gist.github.com/manics/d37fef6dcb7d3f946fb177aedf79b3c2

@manics
Copy link
Member

manics commented May 3, 2016

~centos/idr-metadata git checkout is owned by root, but I can't see why.

@manics
Copy link
Member

manics commented May 3, 2016

Style fixes in joshmoore#1

Suggested minor changes to PR70
@manics
Copy link
Member

manics commented May 3, 2016

@joshmoore Are you planning anything else?

@joshmoore
Copy link
Member Author

I don't have anything in flight. My top hope was to get the volumes auto-mounted but I failed to cleanly get the device name from os_server_volume (i.e. whether it already exists or not). We could go for a map of device names to volume names, but I haven't started on that.

@manics
Copy link
Member

manics commented May 3, 2016

Another strange problem: limiting to -l localhost,FOO (so that it won't affect existing instances) doesn't work unless FOO already exists:

$ ANSIBLE_ROLES_PATH=../../ansible/roles ansible-playbook -i inventory uod-os-idr-omero.yml -vv -e omero_vm_name=FOO -e omero_vm_key_name=XXX --list-hosts -l localhost,FOO

No config file found; using defaults
ERROR! Specified --limit does not match any hosts

@joshmoore joshmoore mentioned this pull request May 11, 2016
@joshmoore
Copy link
Member Author

@manics : pushed my latest fixes and the proposed git mv structure from my description question.

@manics
Copy link
Member

manics commented May 11, 2016

One nit-picky comment: You've got a mix of long (multiline) and short form YAML in some playbooks. If it's easier I can fix it in my pending commits.

@manics manics closed this May 11, 2016
@manics manics reopened this May 11, 2016
@manics
Copy link
Member

manics commented May 11, 2016

(Sorry, accidentally clicked close instead of comment)

@manics
Copy link
Member

manics commented May 12, 2016

https://github.com/joshmoore/infrastructure/compare/os-playbooks...manics:pr70?expand=1

Main changes (you should be able to fast forward):

  • There are now three separate VMs (Postgres, OMERO, gateway/caching proxy).
  • Replaced omero_vm_name with vm_prefix which is used to prefix the names of all three VMs (-omero, -gateway, -database)
  • I've reverted 8013083 for now, but you can limit hosts using ansible's -l parameter, e.g. -l vm_prefix-*, -l vm_prefix-omero.
  • Added a wrapper script inventory/openstack-private.py. inventory/openstack.py only returns instances with floating IPs by default, you have to pass --private to see the private IPs which is necessary if you're running ansible via an ssh gateway host.
  • Modified postgresql role to allow non-local connections

Still more to come

@manics
Copy link
Member

manics commented May 12, 2016

Forgot to say so far I've mostly been testing with uod-os-idr-omero.yml. os-create.yml contains add_hosts tasks which means the openstack dynamic inventory isn't strictly needed if you're setting up the whole system from scratch, however it is required if you want to run os-omero.yml separately. Also be aware that os-create.yml automatically sets the ssh proxy variables to go via the gateway if single_floating_ip: True which is essentially what we have on Embassy. Change this to False to return to the previous behaviour of one floating IP and direct ssh connections for every instance. If you're just running os-omero.yml you'll need to configure those ssh proxy variables somewhere else.

E.g. ansible-playbook -i localhost uod-os-idr-omero.yml -e vm_prefix=test -e vm_key_name='"key name"'

@joshmoore
Copy link
Member Author

Merging this as is since things are getting complicated. Leaving @manics to figure out the next phase.

@joshmoore joshmoore merged commit de1d03a into ome:master May 13, 2016
@manics
Copy link
Member

manics commented May 13, 2016

Refactored my non-openstack changes into two separate PRs:

manics pushed a commit to manics-archive/ome-infrastructure that referenced this pull request Nov 24, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants