Comment 1 for bug 1500278

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.