Can't use tempauth configuration without account_autocreate in proxy-server.conf

[Andrew Young]

I've been trying to use the default tempauth configuration to experiment with Swift without the overhead of running Keystone. However, I found the proxy-server.conf installed by the swift-proxy charm lacked the account_autocreate field. As a result, I could authenticate with the system:root user but I couldn't do anything else because the account wasn't created and, presumably because the system:root user lacks the reseller_admin role, I couldn't create the account.

I checked out the sources and realized the account_autocreate field is in the proxy-server.conf template, but is only present if keystone auth is used. I removed the {% if auth_type == 'keystone' %} conditional block and verified I can now use the system:root user.

I'm happy to commit my changes somewhere if you want though I am new to Launchpad and not sure how to do so.

[Billy Olsen (billy-olsen)]

Hi Andrew, thanks for taking the time to file a bug report and describe a bit of your scenario which is driving a difference in behavior. We'd be more than happy to consider any changes proposed to fix bugs or address specific user needs.

The swift-proxy charm is maintained by the openstack-charmers team. This team works a bit differently than most of the charms in the charm store by using separate branches for current development (/next branches) and stable releases (/trunk branches).

Code is currently maintained using the bzr source control. The general work flow for making a contribution would be as follows (note: my example is for the swift-proxy charm, for most other charms in the openstack ecosystem, replace swift-proxy with the charm of choice):

1. Get the current development branch of the charm and place it in a folder called swift-proxy
    bzr branch lp:~openstack-charmers/charms/trusty/swift-proxy/next swift-proxy

2. Make your local code changes, including unit tests. Verify that they pass unit test, amulet test, and lint tests (the Makefile has targets for each of these).

3. Commit your code
    bzr commit

4. Push your code to your own branch/copy on launchpad
    bzr push lp:~joven/charms/trusty/swift-proxy/my-awesome-contribution

5. Propose to merge your change into the charm's next branch.
     There are a couple of options to do this.

     a) bzr lp-propose-merge lp:~openstack-charmers/charms/trusty/swift-proxy/next

     b) Navigate to the launchpad web interface and propose the merge proposal. Your branches appear under https://code.launchpad.net/~joven. Once you have navigated to the branch, there is an option for 'Propose for merging'. Click on that and target it at lp:~openstack-charmers/charms/trusty/swift-proxy/next

At this point, the uosci testing bot will perform some automated validation to offer initial votes. Once osci is fully happy and an OpenStack charmer is also fully happy, your code can be merged into the /next branch. Once the next release of the OpenStack charms occurs (every 3 months), the code will be promoted to the /trunk branch and become generally available.

This is the general flow for any change to propose. If you have further questions, you can find me (wolsen) or someone else in the #juju channel on freenode.

As a note, please keep in mind security and practical use for your proposed change. Currently the account_autocreate is only enabled when keystone authorization is present due to the delegation of authentication against keystone. If you'd like to make this a general change, it should probably be a config option rather than the default.

[Andrew Young (joven)]

Hi Billy,

Thanks! I completely agree a config option would be a better choice.

When I run the bzr branch command from your email, I get the following
error. But if I branch from the released version (bzr branch
lp:charms/trusty/swift-proxy), it works fine... Any idea what I'm doing
wrong?

vagrant@vagrant-ubuntu-trusty-64:/charms$ bzr branch
lp:~openstack-charmers/charms/trusty/swift-proxy/next swift-proxy
bzr: ERROR: [Errno 71] Protocol error

I believe I am successfully logged into bar using my new Launchpad id.

Best,
Andy

On Mon, Sep 28, 2015 at 3:03 PM, Billy Olsen <email address hidden>
wrote:

> Hi Andrew, thanks for taking the time to file a bug report and describe
> a bit of your scenario which is driving a difference in behavior. We'd
> be more than happy to consider any changes proposed to fix bugs or
> address specific user needs.
>
> The swift-proxy charm is maintained by the openstack-charmers team. This
> team works a bit differently than most of the charms in the charm store
> by using separate branches for current development (/next branches) and
> stable releases (/trunk branches).
>
> Code is currently maintained using the bzr source control. The general
> work flow for making a contribution would be as follows (note: my
> example is for the swift-proxy charm, for most other charms in the
> openstack ecosystem, replace swift-proxy with the charm of choice):
>
> 1. Get the current development branch of the charm and place it in a
> folder called swift-proxy
> bzr branch lp:~openstack-charmers/charms/trusty/swift-proxy/next
> swift-proxy
>
> 2. Make your local code changes, including unit tests. Verify that they
> pass unit test, amulet test, and lint tests (the Makefile has targets
> for each of these).
>
> 3. Commit your code
> bzr commit
>
> 4. Push your code to your own branch/copy on launchpad
> bzr push lp:~joven/charms/trusty/swift-proxy/my-awesome-contribution
>
> 5. Propose to merge your change into the charm's next branch.
> There are a couple of options to do this.
>
> a) bzr lp-propose-merge lp:~openstack-charmers/charms/trusty/swift-
> proxy/next
>
> b) Navigate to the launchpad web interface and propose the merge
> proposal. Your branches appear under https://code.launchpad.net/~joven.
> Once you have navigated to the branch, there is an option for 'Propose
> for merging'. Click on that and target it at lp:~openstack-
> charmers/charms/trusty/swift-proxy/next
>
> At this point, the uosci testing bot will perform some automated
> validation to offer initial votes. Once osci is fully happy and an
> OpenStack charmer is also fully happy, your code can be merged into the
> /next branch. Once the next release of the OpenStack charms occurs
> (every 3 months), the code will be promoted to the /trunk branch and
> become generally available.
>
> This is the general flow for any change to propose. If you have further
> questions, you can find me (wolsen) or someone else in the #juju channel
> on freenode.
>
> As a note, please keep in mind security and practical use for your
> proposed change. Currently the account_autocreate is only enabled when
> keystone authorization is present d...

[Billy Olsen (billy-olsen)]

Andrew, let's take this discussion in another forum from the bug while we get you squared away and keep the conversation on this bug specific to this bug otherwise it gets a bit confusing.