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 <graham.as...@ca.ibm.com> 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 <geoff.macart...@cloudsoftcorp.com> > To: Brooklyn dev <dev@brooklyn.apache.org> > 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 <graham.as...@ca.ibm.com> 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:graham.as...@ca.ibm.com" > > 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
