New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better openstack support #480

Closed
alop opened this Issue Sep 30, 2013 · 23 comments

Comments

Projects
None yet
@alop
Copy link

alop commented Sep 30, 2013

Currently, the openstack builder assumes that a user is on Rackspace. https://github.com/rackspace/gophercloud/blob/master/global_context.go#L15

The builder imports gophercloud, which has hardcoded AuthEndpoint to Rackspace's URLs.

Perhaps instead of having 'provider' be either 'rackspace-us/uk', the builder could require the AuthEndpoint directly, which any openstack user will already have.

@ghost ghost assigned markpeek Oct 1, 2013

@sykesm

This comment has been minimized.

Copy link

sykesm commented Oct 1, 2013

It looks like you can specify the auth url as the provider (rackspace/gophercloud@23f2a3a) but then things fall over with the packer references to 'cloudServersOpenStack'

https://github.com/mitchellh/packer/blob/master/builder/openstack/builder.go#L64

It would be nice if packer could be used for something other than rackspace but I don't know how to do it given the current code.

@mitchellh

This comment has been minimized.

Copy link
Member

mitchellh commented Oct 1, 2013

I'd like to see this as well, many people have been asking for it. I defer to @markpeek for now due to his knowledge on the subject, and tagged this as an enhancement.

@sihil

This comment has been minimized.

Copy link

sihil commented Nov 21, 2013

Would love to see this, trying to get packer working on our internal openstack cloud and hit this constraint.

@tdhite

This comment has been minimized.

Copy link
Contributor

tdhite commented Dec 3, 2013

I fixed this issue in my openstack-postprocessor (see #540 for info on that). I'll see about adding the same generic model of URL to the builder. Mitchell -- if you need a separate PR for both, let me know and I'll branch 'em, otherwise I can do it all (both the post processor for openstack uploads and this general URL support for the openstack builder) in the same PR.

@devcamcar

This comment has been minimized.

Copy link
Contributor

devcamcar commented Jan 6, 2014

We're close to getting a proper and cleaned up PR for this.

@rafaelmagu

This comment has been minimized.

Copy link

rafaelmagu commented Jul 30, 2014

Any updates on this? Or any documentation that can help in using Packer with private deployments?

@msabramo

This comment has been minimized.

Copy link
Contributor

msabramo commented Aug 11, 2014

Same here. Trying to use packer with a Metacloud instance (based off OpenStack Havana IIRC) and I keep getting this:

Build 'openstack' errored: Missing endpoint, or insufficient privileges to access endpoint

The docs at http://www.packer.io/docs/builders/openstack.html say to check the "region"; as far as I can tell we don't use "region" in our config, so I don't know what to use here.

@msabramo

This comment has been minimized.

Copy link
Contributor

msabramo commented Aug 12, 2014

I fixed the "Missing endpoint..." error above but discovering that we actually have a default region name of "RegionOne" with our Metacloud instance (discovered this by looking at output of nova endpoints). Now I am running into a different problem -- packer attempts to create a keypair and it fails because it does os-keypairs call to the Volume API on port 8776 instead of Nova (Compute) (I only discovered this by packet tracing with Wireshark). My hunch is that packer is calling gophercloud somehow incorrectly and the result is that it grabs the very first endpoint that it discovers and incorrectly assumes that it's the Compute API. I'm not super familiar with gophercloud or Go, but if folks give me some troubleshooting tips, I might be able to help with this.

This actually seems similar to #1142 in that it appears that packer or gophercloud is picking the wrong endpoint (probably the first one it discovers, as for me it's picking Volume, which happens to be the first in the list returned from nova endpoints). The difference is that bug was for Rackspace and I'm using a non-Rackspace private cloud. So I don't know if my config settings are incorrect or if the code can't deal with my private cloud yet.

I feel like the problem centers around what I should provide for openstack_provider in my packer config.

My packer config:

{
  "builders": [
    {
      "type": "openstack",
      "provider": "http://<redacted>.metacloud.net:5000/v2.0",
      "openstack_provider": "",
      "region": "RegionOne",
      "ssh_username": "monkey",
      "image_name": "ubuntu1404_packer_test_1",
      "source_image": "ubuntu1404_smbase3",
      "flavor": "2"
    }
  ]
}

The above config with openstack_provider" set to""` results in:

Build 'openstack' errored: Missing endpoint, or insufficient privileges to access endpoint

Ditto if I omit it or set it to "openstack" or "rackspace". If I set it to any other value (e.g.: "nova"), then I get a different error:

==> openstack: Error launching source server: Expected HTTP response code [202] when accessing URL(http://<redacted>.metacloud.net:8776/v1/a5920c8f7bf6441a9e2e96eb7b62d1d5/servers); got 404 instead with the following body:
==> openstack: 404 Not Found
==> openstack:
==> openstack: The resource could not be found.

Note that the URL it's attempting to use above and getting a 404 is the OpenStack Volume service:

$ nova endpoints
+----------------+--------------------------------------------------------------------------------+
| Volume Service | Value                                                                          |
+----------------+--------------------------------------------------------------------------------+
| adminURL       | http://<redacted>.metacloud.in:8776/v1/a5920c8f7bf6441a9e2e96eb7b62d1d5      |
| internalURL    | http://<redacted>.metacloud.in:8776/v1/a5920c8f7bf6441a9e2e96eb7b62d1d5      |
| publicURL      | http://<redacted>.metacloud.net:8776/v1/a5920c8f7bf6441a9e2e96eb7b62d1d5 |
| region         | RegionOne                                                                      |
+----------------+--------------------------------------------------------------------------------+

Is there some other value I should be providing for openstack_provider in my packer config so that gophercloud is able to query and get the nova endpoint correctly?

@devcamcar

This comment has been minimized.

Copy link
Contributor

devcamcar commented Aug 12, 2014

In my working Packer file, I use only this for my builder section:

"builders": [{
"type": "openstack",
"source_image": "{{ user source_image }}",
"flavor": "{{ user flavor }}",
"ssh_username": "{{ user ssh_username }}",
"image_name": "{{ user image_name }}"
}]

All the relevant parts are pulled from the OS_* environment variables provided by sourcing an openrc file. Can you try a more stripped down version?

Also @msabramo, I am confused about you saying that Packer is trying to hit the volume API on 8776. The nova endpoint list there shows everything on 8776 as well.

@msabramo

This comment has been minimized.

Copy link
Contributor

msabramo commented Aug 12, 2014

@devcamcar: Thanks for responding! What kind of cloud are you using? Rackspace, or something else? With your simple config, I get:

Build 'openstack' errored: Missing endpoint, or insufficient privileges to access endpoint

I think is because I didn't give it enough info to know what auth URL to use, so it's probably hitting Rackspace or something. I suspect that at the very least, I need this in my config:

"provider": "http://<redacted>.metacloud.net:5000/v2.0",

so that it can at least find my Keystone.

Does your nova endpoints output show multiple things on 8776? Mine doesn't (and maybe this is why things don't work for me -- perhaps some code is making assumptions about where stuff is and it doesn't hold in my environment). Here's what my nova endpoints looks like:

❯ nova endpoints
+----------------+--------------------------------------------------------------------------------+
| Volume Service | Value                                                                          |
+----------------+--------------------------------------------------------------------------------+
| adminURL       | http://<redacted>.pv.metacloud.in:8776/v1/a5920c8f7bf6441a9e2e96eb7b62d1d5      |
| internalURL    | http://<redacted>.pv.metacloud.in:8776/v1/a5920c8f7bf6441a9e2e96eb7b62d1d5      |
| publicURL      | http://<redacted>.client.metacloud.net:8776/v1/a5920c8f7bf6441a9e2e96eb7b62d1d5 |
| region         | RegionOne                                                                      |
+----------------+--------------------------------------------------------------------------------+
+---------------+-----------------------------------------------+
| Image Service | Value                                         |
+---------------+-----------------------------------------------+
| adminURL      | http://<redacted>.pv.metacloud.in:9292/v1      |
| internalURL   | http://<redacted>.pv.metacloud.in:9292/v1      |
| publicURL     | http://<redacted>.client.metacloud.net:9292/v1 |
| region        | RegionOne                                     |
+---------------+-----------------------------------------------+
+-----------------+--------------------------------------------------------------------------------+
| Compute Service | Value                                                                          |
+-----------------+--------------------------------------------------------------------------------+
| adminURL        | http://<redacted>.pv.metacloud.in:8774/v2/a5920c8f7bf6441a9e2e96eb7b62d1d5      |
| internalURL     | http://<redacted>.pv.metacloud.in:8774/v2/a5920c8f7bf6441a9e2e96eb7b62d1d5      |
| publicURL       | http://<redacted>.client.metacloud.net:8774/v2/a5920c8f7bf6441a9e2e96eb7b62d1d5 |
| region          | RegionOne                                                                      |
| serviceName     | Compute Service                                                                |
+-----------------+--------------------------------------------------------------------------------+
+-------------+-----------------------------------------------------------+
| EC2 Service | Value                                                     |
+-------------+-----------------------------------------------------------+
| adminURL    | http://<redacted>.pv.metacloud.in:8773/services/Admin      |
| internalURL | http://<redacted>.pv.metacloud.in:8773/services/Cloud      |
| publicURL   | http://<redacted>.client.metacloud.net:8773/services/Cloud |
| region      | RegionOne                                                 |
+-------------+-----------------------------------------------------------+
+------------------+--------------------------------------------------+
| Identity Service | Value                                            |
+------------------+--------------------------------------------------+
| adminURL         | http://<redacted>.client.metacloud.net:35357/v2.0 |
| internalURL      | http://<redacted>.pv.metacloud.in:5000/v2.0       |
| publicURL        | http://<redacted>.client.metacloud.net:5000/v2.0  |
| region           | RegionOne                                        |
+------------------+--------------------------------------------------+

Note that in my setup, Volume service is the first endpoint and it's running on 8776. Other things are running on other ports and notably, Compute is running on port 8774.

@devcamcar

This comment has been minimized.

Copy link
Contributor

devcamcar commented Aug 12, 2014

@msabramo By sourcing the openrc file, you are automatically and implicitly specifying the provider:

https://github.com/mitchellh/packer/blob/master/builder/openstack/access_config.go#L35

I just confirmed again that things are working (against a Grizzly based cloud). What build of packer are you using?

$ packer --version
Packer v0.6.1.dev (fe40db9)

@msabramo

This comment has been minimized.

Copy link
Contributor

msabramo commented Aug 12, 2014

I have:

$ PATH=bin bin/packer --version
Packer v0.6.2.dev (70cc5551337b2098e75b88dcf914cf30cb9ae810)

$ git log -n 1
commit 70cc5551337b2098e75b88dcf914cf30cb9ae810
Author: Ross Smith II <ross@smithii.com>
Date:   Tue Aug 12 09:19:20 2014 -0700

    Update CHANGELOG.md

msabramo added a commit to msabramo/packer that referenced this issue Aug 12, 2014

openstack builder api.Type = "compute"
so that it gets compute (nova) API and not some other incorrect API.
(e.g.: for me it was getting the Volume service API)

This fixes issue hashicorpGH-480 for me.
@msabramo

This comment has been minimized.

Copy link
Contributor

msabramo commented Aug 12, 2014

I found a fix for the issue I was having with tons of help from @jrperritt from the gophercloud team. 👏 See rackspace/gophercloud#176 and #1412

With that, I am able to get packer to create OpenStack keypairs and instances.

@msabramo

This comment has been minimized.

Copy link
Contributor

msabramo commented Aug 13, 2014

There is a PR to fix this in gophercloud: rackspace/gophercloud#179

@mitchellh

This comment has been minimized.

Copy link
Member

mitchellh commented Sep 4, 2014

With all the PRs I've been merging and upstream fixes, I believe its safe to say that we work with other OpenStack instances. Yes? If I'm wrong please update!

@mitchellh mitchellh closed this Sep 4, 2014

@msabramo

This comment has been minimized.

Copy link
Contributor

msabramo commented Sep 4, 2014

It's definitely working much better for me now with my Metacloud, except for #1415, but definitely progress and this might even turn out to be an issue with our config. Thanks!

@sysbot

This comment has been minimized.

Copy link

sysbot commented Sep 4, 2014

@msabramo any chance you can post the final working config template that work for you with Metacloud? Thanks a bunch.

@msabramo

This comment has been minimized.

Copy link
Contributor

msabramo commented Sep 5, 2014

Absolutely. Here's the template I'm using:

{
  "builders": [
    {
      "type": "openstack",
      "ssh_username": "monkey",
      "image_name": "ubuntu1404_packer_test_1",
      "source_image": "91d9c168-d1e5-49ca-a775-3bfdbb6c97f1",
      "flavor": "2"
    }
  ]
}

I'm using this with packer on GitHub master; not the release version. Because the release version requires you to specify a region and what not.

Running it looks like this:

❯ pwd
/Users/marca/go/src/github.com/mitchellh/packer

❯ cat openstack.json
{
  "builders": [
    {
      "type": "openstack",
      "ssh_username": "monkey",
      "image_name": "ubuntu1404_packer_test_1",
      "source_image": "91d9c168-d1e5-49ca-a775-3bfdbb6c97f1",
      "flavor": "2"
    }
  ]
}

❯ PATH=bin bin/packer build openstack.json
openstack output will be in this color.

==> openstack: Creating temporary keypair for this instance...
==> openstack: Waiting for server (8811694f-4f88-40e9-aa8c-d8d67a066434) to become ready...
==> openstack: Waiting for SSH to become available...
==> openstack: Connected to SSH!
==> openstack: Creating the image: ubuntu1404_packer_test_1
==> openstack: Image: 56d89c4a-cda4-47a6-a048-32c884256a61
==> openstack: Waiting for image to become ready...
==> openstack: Terminating the source server...
==> openstack: Deleting temporary keypair...
Build 'openstack' finished.

==> Builds finished. The artifacts of successful builds are:
--> openstack: An image was created: 56d89c4a-cda4-47a6-a048-32c884256a61
>>> elapsed time 3m17s

I do still have the problem in #1415 where most of the time, I actually end up with no image because the image seems to get deleted when the temporary instance that it's built from is terminated. But this is a separate issue and could even be something specific to my environment.

@msabramo

This comment has been minimized.

Copy link
Contributor

msabramo commented Sep 5, 2014

I also just created a PR that adds the above example config to the OpenStack builder doc page: #1459

@sysbot

This comment has been minimized.

Copy link

sysbot commented Sep 15, 2014

awesome! I will give this a try thanks for the pointers.

@vallard

This comment has been minimized.

Copy link

vallard commented Apr 3, 2015

I'm running on a Metacloud instance as well (well, now Cisco OpenStack Private Cloud). I can't seem to get pass the insufficient privileges problem like you did.

OS_TENANT_ID=12345....
OS_PASSWORD=secret
OS_AUTH_URL=http://<redacted>.metacloud.net:5000/v2.0
OS_USERNAME=user
OS_TENANT_NAME=TCO Application

Then packer file:

{
     "builders" : [{
       "type": "openstack",
       "ssh_username": "core",
       "image_name": "coreos-java",
       "source_image": "bc3c7ad4-33d5-4702-a01a-b4b65b5c14a3",
       "flavor": "5"
   }]
}

Running:

packer build coreos-jenkins3.json 
openstack output will be in this color.

Build 'openstack' errored: Missing endpoint, or insufficient privileges to access endpoint

==> Some builds didn't complete successfully and had errors:
--> openstack: Missing endpoint, or insufficient privileges to access endpoint

==> Builds finished but no artifacts were created.

My version is

$ packer version
Packer v0.7.5

Any hints of how I can troubleshoot?

@jrevote

This comment has been minimized.

Copy link

jrevote commented Apr 18, 2015

Same issue as vallard, same packer version, private OpenStack, still the same issue ....

@einarf

This comment has been minimized.

Copy link
Contributor

einarf commented Apr 18, 2015

I made a PR today (commit: 55c2ac4) with a new openstack builder using the new gophercloud API. That might lead to a more flexible openstack builder soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment