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 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.
>
> ** Changed in: swift-proxy (Juju Charms Collection)
>        Status: New => Triaged
>
> ** Changed in: swift-proxy (Juju Charms Collection)
>    Importance: Undecided => Wishlist
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1500278
>
> Title:
>   Can't use tempauth configuration without account_autocreate in proxy-
>   server.conf
>
> Status in swift-proxy package in Juju Charms Collection:
>   Triaged
>
> Bug description:
>   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.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/charms/+source/swift-proxy/+bug/1500278/+subscriptions
>