Re: Feature flag for a provider?

2015-04-22 Thread Aaron Bentley
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-04-22 09:00 AM, Wayne Witzel wrote:
 I've been told to place cloudsigma provider behind a feature flag,
 but the result of that is that the provider is not registered
 unless the env variable for cloudsigma is set.
 
 So after wrapping the registration of the provider in the feature
 flag (see: 
 https://github.com/juju/juju/commit/0a2cf42dcf051fe43bd803ebb144358723b4af82),

 
the tests no longer pass, since there is no registered provider for
 cloudsigma. Manually calling s.SetFeatureFlag(feature.CloudSigma)
 from the Suite and/or Test setup methods doesn't help since by that
 point the init for each provider has already been run.
 
 Looking for suggestions? My thought is that the flag isn't needed
 since by nature providers are contained and their code is only
 called if you explicitly use the provider.

I think there's a potential quality issue.  I don't know anything
about the state of the cloud sigma provider code, but since it's being
kept behind a feature flag, I have to think
a) The code is not yet production quality or
b) The API isn't stable.

Say you're using Juju 2.5, in which the cloud sigma provider is fully
production quality.  You create an environment.  Then you go to a
machine that has Juju 2.4, where the provider was not
production-quality, and try to perform an operation on that
environment.  Does Juju break?  Does the environment?

Because you weren't paying attention to the Juju version number, you
may be surprised by poor behaviour.  Instead, it would be better if
Juju said: CloudSigma is not production-quality in this version of
Juju.  To enable it anyway, set JUJU_DEV_FEATURE_FLAGS to $FOO.

So to avoid surprising users, I think a feature flag makes sense.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVN6FkAAoJEK84cMOcf+9hXR8IAKoenxmb8797B7xaNB842ZkH
tlwwvsc/joO8Cy73OPFyNg1NQ14g4FVCUJJ6q0qgj51ubIrB1725a0XwilUYSme5
uQGqEebZx6o9Q1SCP7uxOAZ4SEH7KftjIiqKG7kTzV93ZSeJtyK3Y7K7IuKw18UL
VvOdhxrAie/dBnxhx16CqqbJcSj21RqLmd9osgL+gWTPtZ+UkAwV5nDqunAfaqt4
9DeoYloYVeqaFlQoTsyMB0hxd3Z63S+gHcjGWSRfAqdXCOZFjMntdbq8+dOMDMvB
FkL0GBKliC7tPio2/w7OF4UW8AGMxQvMGddJflOFFt+CNAGwaLtxf6mHuA9jRGw=
=VdEM
-END PGP SIGNATURE-

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Feature flag for a provider?

2015-04-22 Thread Wayne Witzel
I've been told to place cloudsigma provider behind a feature flag, but the
result of that is that the provider is not registered unless the env
variable for cloudsigma is set.

So after wrapping the registration of the provider in the feature flag
(see:
https://github.com/juju/juju/commit/0a2cf42dcf051fe43bd803ebb144358723b4af82),
the tests no longer pass, since there is no registered provider for
cloudsigma. Manually calling s.SetFeatureFlag(feature.CloudSigma) from the
Suite and/or Test setup methods doesn't help since by that point the init
for each provider has already been run.

Looking for suggestions? My thought is that the flag isn't needed since by
nature providers are contained and their code is only called if you
explicitly use the provider.

-- 
Wayne Witzel III
wayne.wit...@canonical.com
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Juju 1.23.1 is proposed for stable release

2015-04-22 Thread Curtis Hovey-Canonical
# juju-core 1.23.1

A new proposed stable release of Juju, juju-core 1.23.1, is now available.
This release may replace version 1.23.0 on Thursday April 23.


## Getting Juju

juju-core 1.23.1 is available for vivid and backported to earlier
series in the following PPA:

https://launchpad.net/~juju/+archive/proposed

Windows and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.23.1

Proposed releases use the proposed simple-streams. You must configure
the `agent-stream` option in your environments.yaml to use the matching
juju agents.


## Notable Changes since 1.23.0

### Experimental: Addressable LXC Containers and KVM Instances on AWS and MAAS

The Juju AWS and MAAS providers now support starting LXC containers. The
MAAS providers also supports networking on KVM. Containers and Virtual
Machines will be given statically allocated private IP addresses from
the same subnet as their host machine. For example on MAAS you can now:

juju deploy wordpress --to lxc:0
juju add-unit mysql --to kvm:1

This experimental feature can be enabled when the environment is
bootstrapped like so:

JUJU_DEV_FEATURE_FLAGS=address-allocation juju bootstrap

These two units can now talk directly on the private subnet.


## Resolved issues

  * Addressable containers cannot resolve non-fqdn in maas
Lp 1445063

  * Vivid bootstrap and destroy-environment intermittently fails
Lp 1446662


Finally

We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.

-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Need advice on my juju plugin

2015-04-22 Thread Aaron Bentley
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 Any insight on what I'm missing is appreciated. Another note is I'm
 not quite sure if there is an alternative to getting the current
 running environment other than doing a `juju switch local` then
 running the plugin pulling in envcmd.GetDefaultEnvironment, seen
 here:

`juju switch` (aka `juju env`) will tell you the current environment.
 Your plugin should accept -e/--environment to override it.

I wrote a g+ post about plugins recently:
https://plus.google.com/+AaronBentley/posts/45FA3LDkcv8

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVN7kcAAoJEK84cMOcf+9h6UoIAKa1o3TMqvbfJgWZUMmkP9EN
5EzFtQ3tOxHWETa2cctoJazR7sXTzYtkgLznmHxmnBaASkWZ9ro0wjOfPzzq7NEL
m75c6ypmRraqZ/gQQMrsiVMvTE3djAoVUVB/slJ0zXqAD8tMsQ/DjwWzcPfv5xWX
ZWEV9EOnobVaSss7eqsHj7Hc7BZ7QmnrCdX803qj/7Sh1S+sN1650u87j949gfw5
w93mIhdBLTyMjKMhJaybozlMJZ8HFsMGcnnmqstBKulJS3KMLaBEbwlXuU09YBrV
zBIdP9DWs6ZBYmRqrD923EVkkB4k+A49RhSt9Syv16ViZyVJA23zPCahFZVSqfc=
=tjm2
-END PGP SIGNATURE-

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


gocharm help

2015-04-22 Thread Vasiliy Tolstov
Hello, i'm try to investigate gocharm and i'm happy with it.
But i'm stuck ad this issues:
https://github.com/juju/gocharm/issues/44
can somebody helps me?

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
jabber: v...@selfip.ru

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Feature flag for a provider?

2015-04-22 Thread John Meinel
So if we want feature flagged providers I think the best option is to
change registration code path.
Probably my ideal would be to have
environs.RegisterFlaggedProvider(name, flag string, p EnvironProvider,
alias ...string)

and then we can track in environs/config.go that a given provider name is
flagged with a given feature flag, and have
environs.Provider() check if a given provider is flagged, and only return
it if the flag is set.


Thinking it through a bit more, I wonder if that is the best option.
Because if someone is already bootstrapped on CloudSigma you really don't
have any reason for it to not support CloudSigma. It is just broken if it
isn't working. (Imagine they used a version of juju that didn't have the
flag, and upgraded to a version that requires the flag, and suddenly
everything just breaks.)

What I'd rather see is that only juju bootstrap pays attention to whether
this is a supported provider. And everything else just treats it as a fully
recognized provider.


That might be easiest if we just change CloudSigma.Bootstrap() to check for
the flag? Does that work out ok for you? That still lets us install the
provider support, if you're using the provider it JustWorks, and we just
give you an Error when Bootstrap is called pointing you for how you can
enable this provider.

John
=:-


On Wed, Apr 22, 2015 at 6:19 PM, Wayne Witzel wayne.wit...@canonical.com
wrote:

 That sounds reasonable to me Aaron. Also Eric just suggested I put the set
 flag in export_test.go, he did something similar for GCE and it worked, so
 I will try that.

 Thanks.

 On Wed, Apr 22, 2015 at 9:25 AM, Aaron Bentley 
 aaron.bent...@canonical.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 2015-04-22 09:00 AM, Wayne Witzel wrote:
  I've been told to place cloudsigma provider behind a feature flag,
  but the result of that is that the provider is not registered
  unless the env variable for cloudsigma is set.
 
  So after wrapping the registration of the provider in the feature
  flag (see:
 
 https://github.com/juju/juju/commit/0a2cf42dcf051fe43bd803ebb144358723b4af82
 ),
 
 
 the tests no longer pass, since there is no registered provider for
  cloudsigma. Manually calling s.SetFeatureFlag(feature.CloudSigma)
  from the Suite and/or Test setup methods doesn't help since by that
  point the init for each provider has already been run.
 
  Looking for suggestions? My thought is that the flag isn't needed
  since by nature providers are contained and their code is only
  called if you explicitly use the provider.

 I think there's a potential quality issue.  I don't know anything
 about the state of the cloud sigma provider code, but since it's being
 kept behind a feature flag, I have to think
 a) The code is not yet production quality or
 b) The API isn't stable.

 Say you're using Juju 2.5, in which the cloud sigma provider is fully
 production quality.  You create an environment.  Then you go to a
 machine that has Juju 2.4, where the provider was not
 production-quality, and try to perform an operation on that
 environment.  Does Juju break?  Does the environment?

 Because you weren't paying attention to the Juju version number, you
 may be surprised by poor behaviour.  Instead, it would be better if
 Juju said: CloudSigma is not production-quality in this version of
 Juju.  To enable it anyway, set JUJU_DEV_FEATURE_FLAGS to $FOO.

 So to avoid surprising users, I think a feature flag makes sense.

 Aaron
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJVN6FkAAoJEK84cMOcf+9hXR8IAKoenxmb8797B7xaNB842ZkH
 tlwwvsc/joO8Cy73OPFyNg1NQ14g4FVCUJJ6q0qgj51ubIrB1725a0XwilUYSme5
 uQGqEebZx6o9Q1SCP7uxOAZ4SEH7KftjIiqKG7kTzV93ZSeJtyK3Y7K7IuKw18UL
 VvOdhxrAie/dBnxhx16CqqbJcSj21RqLmd9osgL+gWTPtZ+UkAwV5nDqunAfaqt4
 9DeoYloYVeqaFlQoTsyMB0hxd3Z63S+gHcjGWSRfAqdXCOZFjMntdbq8+dOMDMvB
 FkL0GBKliC7tPio2/w7OF4UW8AGMxQvMGddJflOFFt+CNAGwaLtxf6mHuA9jRGw=
 =VdEM
 -END PGP SIGNATURE-

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev




 --
 Wayne Witzel III
 wayne.wit...@canonical.com

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev