Graham, A colleague just suggested that another way to accomplish this would be with a custom `MachineProvisioningLocation` implementation, that was configured with the location/credentials of the box with Ansible installed and the playbook target to execute, and when a location is `obtain()`-ed it would call the playbook and then determine the newly created VMs address etc and use that to generate an `SshMachineLocation` for use by other entities. Have a look at the code to see how it works:
- https://github.com/apache/brooklyn-server/blob/master/core/src/main/java/org/apache/brooklyn/location/byon/FixedListMachineProvisioningLocation.java - https://github.com/apache/brooklyn-server/blob/master/core/src/main/java/org/apache/brooklyn/location/byon/SingleMachineProvisioningLocation.java - https://github.com/apache/brooklyn-server/blob/master/core/src/main/java/org/apache/brooklyn/location/localhost/LocalhostMachineProvisioningLocation.java Hopefully this will give you some ideas. Andrew. On Fri, 19 May 2017 at 15:17 Andrew Kennedy < [email protected]> wrote: > Hi Graham. > > You could certainly create a BYON location that referenced the instance > created by Ansible, as described at > http://brooklyn.apache.org/v/latest/locations/index.html#byon you simple > export the host IP address and required credentials into a BOM file that > describes the new location, and deploy it using the `br deploy` CLI > command, or via the REST API and `curl` perhaps. > > You could also create an AnsibleEntity, which would then provision a VM > somewhere and run the `ansible-playbook` commands required on it, but this > may be a chicken-and-egg type of situation for you - it is more designed > for the use case where we provision a VM, install ansible on it and then > use a playbook to install something else on that machine. We are currently > developing a policy that can create locations from entities, which sounds > like it would also be useful, I will update this thread with the details > shortly, when the PR is available. > > Andrew. > > On Fri, 19 May 2017 at 14:17 Graham Ashby <[email protected]> wrote: > >> Well, after much talk over here, our OpenStack servers only support V3 >> authentication. We're using the Mitaka release. Older instances that >> support the v2.0 authentication API are all EOL. >> >> Which leads me to plan B. I have an Ansible playbook that provisions a >> new instance. Is there some way to hook that (using an AnsibleEntry) into >> a location? I imagine I'd need a way to somehow export the host name and >> external IP address into something that the Location could use. And I'd >> need a Location that could call an Entity to get whatever it needs. >> >> Is this possible? >> >> Thanks >> Graham >> >> >> >> From: Geoff Macartney <[email protected]> >> To: Brooklyn dev <[email protected]> >> Date: 05/03/2017 10:22 AM >> Subject: Re: Help with Openstack >> >> >> >> hi Graham >> >> as far as I understand you'll need to stick to the v2 API to use Apache >> Brooklyn, as that is what is currently supported by the underlying jclouds >> library. >> >> As it happens this was a topic of conversation this very morning on the >> jclouds mailing list [1], so there may be some progress on this in the >> near >> but not immediate future. >> >> [1] >> >> https://lists.apache.org/thread.html/b1162446800011a8343e67a7cda55a5033754881529c74fafa47109b@%3Cdev.jclouds.apache.org%3E >> >> >> regards >> Geoff >> >> >> >> On Wed, 3 May 2017 at 14:16 Graham Ashby <[email protected]> wrote: >> >> > I need some help with deploying to openstack... >> > >> > For some reason, our openstack-nova identity endpoint has to be the v3 >> > version: >> > endpoint: https://canhdc-controller.canlab.ibm.com:5000/v3 >> > >> > When I try to deploy, I get an exception: >> > org.jclouds.http.HttpResponseException: command: POST >> > https://canhdc-controller.canlab.ibm.com:5000/v3/tokens HTTP/1.1 failed >> > with response: HTTP/1.1 404 Not Found; content: [{"error": {"message": >> > "The resource could not be found.", "code": 404, "title": "Not Found"}} >> > >> > Do I need to somehow tell jclouds to use the v3 api? Or am I stuck >> > needing to use the v2.0 api? >> > >> > Also, our https endpoint is self signed, so I need to set OS_CACERT to >> > make the openstack CLI work. >> > >> > For reference, here's the appropriate bit of my yaml: >> > >> > jclouds:openstack-nova: >> > endpoint: https://canhdc-controller.canlab.ibm.com:5000/v3 >> > identity: "fa4c7f59767d487682a7798550b946bd:[email protected] >> " >> > credential: ******** >> > displayName: hdc-canada >> > >> > imageId: Lobby/e3b40a4f-4e82-41b3-857c-68799c4a9009 >> > hardwareId: Lobby/m1.small >> > keyPair: openstack-gsa-gen >> > keyPairName: openstack-gsa-gen >> > loginUser: cloudusr >> > loginUser.privateKeyFile: /home/cloudusr/.ssh/openstack-gsa-gen.pem >> > >> > jclouds.openstack-nova.cacert: /opt/brooklyn/ca-1/hdc.pem >> > jclouds.openstack-nova.openIptables: true >> > jclouds.openstack-nova.selinux.disabled: true >> > jclouds.openstack-nova.auto-create-floating-ips: true >> > jclouds.openstack-nova.auto-generate-keypairs: false >> > >> > >> >> >> >> >> -- > > Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft > -- Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
