Re: [charms] Barbican + Identity Standalone - AWS

[Mark Ramm-Christensen (Canonical.com)]

Very cool, thanks for sharing!

On Wed, Nov 30, 2016 at 10:36 AM, James Beedy  wrote:

> Another great day of Juju driven successes - deploying the barbican
> standalone stack for identity mgmt and secrets mgmt. For those that don't
> know, newton horizon brings support for identity only! This means you can
> (as I am) use the openstack-dashboard for mgmt of just users, projects, and
> domains, without a full Openstack! In previous Openstack releases, if you
> hooked up horizon and you didn't have the core Openstack services
> registered in your service catalogue, horizon would throw errors and would
> be unusable. This is a huge win for those wanting object storage and
> identity mgmt only, too!
>
> AWS Barbican Stack -> http://paste.ubuntu.com/23556001/
>
> LXD Barbican Bundle (with script to help get started setting secrets in
> barbican)-> https://github.com/jamesbeedy/juju-barbican-lxd-bundle
>
> Also, here's a utility function from barbican-client layer I've been using
> to make getting secrets from barbican containers easy for charms (WIP) ->
> https://github.com/jamesbeedy/juju-layer-barbican-client/
> blob/master/lib/charms/layer/barbican_client.py
>
> ~james
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: kill-controller, unregister, destroy-controller

[Mark Ramm-Christensen (Canonical.com)]

Exactly.

On Friday, September 2, 2016, Casey Marshall 
wrote:

> My main use case for killing controllers is development & testing. For
> this, I have a script that force deletes all the juju-* LXC containers, and
> then unregisters all controllers with cloud: lxd. It's *much* faster than
> waiting for each juju controller to tear itself down. It's also nothing I'd
> provide casually to end users.
>
> I think it should be possible, but not trivial, to destroy controllers and
> everything in them. It's not a bad thing to have to type a long command or
> flag name to do something so destructive -- or write a script to do
> precisely what I want. Feels like my use case for destroying controllers
> isn't really as a normal Juju user -- I'm (ab)using Juju with a developer &
> QA tester's mindset.
>
> -Casey
>
> On Fri, Sep 2, 2016 at 6:15 AM, roger peppe  > wrote:
>
>> It seems to me that this kind of thing is exactly what "blocks" are
>> designed for. An explicit unblock command seems better to me than either an
>> explicit flag or an extra prompt, both of which are vulnerable to typing
>> without thinking. Particularly if "throwaway" controllers created for
>> testing purposes are not blocked by default, so you don't get used to to
>> typing "unblock" all the time.
>>
>> On 1 Sep 2016 16:14, "Mark Ramm-Christensen (Canonical.com)" <
>> mark.ramm-christen...@canonical.com
>> >
>> wrote:
>>
>> I get the desire to remove friction everywhere we can, but unless
>> destroying controllers is a regular activity, I actually think SOME
>> friction is valuable here.
>>
>> If controllers are constantly getting into a wedged state where they must
>> be killed, that's likely a product of a fast moving set of betas, and
>> should be addressed *directly* rather than as they say "applying
>> lipstick to a pig"
>>
>> On Thu, Sep 1, 2016 at 4:04 PM, Marco Ceppi > > wrote:
>>
>>> On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) <
>>> mark.ramm-christen...@canonical.com
>>> >
>>> wrote:
>>>
>>>> I believe keeping the --destroy-all-models flag is helpful in keeping
>>>> you from accidentally destroying a controller that is hosting important
>>>> models for someone without thinking.
>>>>
>>>
>>> What happens if I destroy-controller without that flag? Do I have to go
>>> into my cloud portal to kill those instances? Is there any way to recover
>>> from that to get juju reconnected? If not, it's just a slower death.
>>>
>>>
>>>> On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi >>> > wrote:
>>>>
>>>>> Hey everyone,
>>>>>
>>>>> I know we've had discussions about this over the past few months, but
>>>>> it seems we have three commands that overlap pretty aggressively.
>>>>>
>>>>> Using Juju beta16, and trying to 'destroy' a controller it looks like
>>>>> this now:
>>>>>
>>>>> ```
>>>>> root@ubuntu:~# juju help destroy-controller
>>>>> Usage: juju destroy-controller [options] 
>>>>>
>>>>> ...
>>>>>
>>>>> Details:
>>>>> All models (initial model plus all workload/hosted) associated with the
>>>>> controller will first need to be destroyed, either in advance, or by
>>>>> specifying `--destroy-all-models`.
>>>>>
>>>>> Examples:
>>>>> juju destroy-controller --destroy-all-models mycontroller
>>>>>
>>>>> See also:
>>>>> kill-controller
>>>>> unregister
>>>>> ```
>>>>>
>>>>> When would you ever want to destroy-controller and not
>>>>> destroy-all-models? I have to specify that flag everytime, it seems it
>>>>> should just be the default behavior. Kill-controller seems to do what
>>>>> destroy-controller --destroy-all-models does but more aggressively?
>>>>>
>>>>> Finally, unregister and destroy-controller (without
>>>>> --destroy-all-models) does the same thing. Can we consider dropping the -
>>>>> very long winded almost always required - flag for destroy-controller?
>>>>>
>>>>> Finally, there used to be a pretty good amount of feedback during
>>>&

Re: kill-controller, unregister, destroy-controller

[Mark Ramm-Christensen (Canonical.com)]

I get the desire to remove friction everywhere we can, but unless
destroying controllers is a regular activity, I actually think SOME
friction is valuable here.

If controllers are constantly getting into a wedged state where they must
be killed, that's likely a product of a fast moving set of betas, and
should be addressed *directly* rather than as they say "applying lipstick
to a pig"

On Thu, Sep 1, 2016 at 4:04 PM, Marco Ceppi 
wrote:

> On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) <
> mark.ramm-christen...@canonical.com> wrote:
>
>> I believe keeping the --destroy-all-models flag is helpful in keeping
>> you from accidentally destroying a controller that is hosting important
>> models for someone without thinking.
>>
>
> What happens if I destroy-controller without that flag? Do I have to go
> into my cloud portal to kill those instances? Is there any way to recover
> from that to get juju reconnected? If not, it's just a slower death.
>
>
>> On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi 
>> wrote:
>>
>>> Hey everyone,
>>>
>>> I know we've had discussions about this over the past few months, but it
>>> seems we have three commands that overlap pretty aggressively.
>>>
>>> Using Juju beta16, and trying to 'destroy' a controller it looks like
>>> this now:
>>>
>>> ```
>>> root@ubuntu:~# juju help destroy-controller
>>> Usage: juju destroy-controller [options] 
>>>
>>> ...
>>>
>>> Details:
>>> All models (initial model plus all workload/hosted) associated with the
>>> controller will first need to be destroyed, either in advance, or by
>>> specifying `--destroy-all-models`.
>>>
>>> Examples:
>>> juju destroy-controller --destroy-all-models mycontroller
>>>
>>> See also:
>>> kill-controller
>>> unregister
>>> ```
>>>
>>> When would you ever want to destroy-controller and not
>>> destroy-all-models? I have to specify that flag everytime, it seems it
>>> should just be the default behavior. Kill-controller seems to do what
>>> destroy-controller --destroy-all-models does but more aggressively?
>>>
>>> Finally, unregister and destroy-controller (without
>>> --destroy-all-models) does the same thing. Can we consider dropping the -
>>> very long winded almost always required - flag for destroy-controller?
>>>
>>> Finally, there used to be a pretty good amount of feedback during
>>> destroy-controller, while it was rolling text, I at least knew what was
>>> happening. Now it's virtually silent. Given it runs for quite a long time,
>>> can we get some form of feedback to the user back into the command?
>>>
>>> ```
>>> root@ubuntu:~# juju destroy-controller --destroy-all-models cabs
>>> WARNING! This command will destroy the "cabs" controller.
>>> This includes all machines, applications, data and other resources.
>>>
>>> Continue? (y/N):y
>>> ERROR failed to destroy controller "cabs"
>>>
>>> If the controller is unusable, then you may run
>>>
>>> juju kill-controller
>>>
>>> to forcibly destroy the controller. Upon doing so, review
>>> your cloud provider console for any resources that need
>>> to be cleaned up.
>>>
>>> ERROR cannot connect to API: unable to connect to API: websocket.Dial
>>> wss://10.0.0.4:17070/api: dial tcp 10.0.0.4:17070: getsockopt: no route
>>> to host
>>> root@ubuntu:~# juju kill-controller cabs
>>> WARNING! This command will destroy the "cabs" controller.
>>> This includes all machines, applications, data and other resources.
>>>
>>> Continue? (y/N):y
>>> Unable to open API: open connection timed out
>>> Unable to connect to the API server. Destroying through provider.
>>> ERROR listing resource groups: azure.ServicePrincipalToken#Refresh:
>>> Failure sending request for Service Principal 
>>> 83d638b0-841c-4bd1-9e7c-868cae3393f4:
>>> StatusCode=0 -- Original Error: http: nil Request.URL
>>> root@ubuntu:~# juju bootstrap cabs azure
>>> ERROR controller "cabs" already exists
>>> ```
>>>
>>> Marco
>>>
>>> --
>>> Juju-dev mailing list
>>> juju-...@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>>> mailman/listinfo/juju-dev
>>>
>>>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: kill-controller, unregister, destroy-controller

[Mark Ramm-Christensen (Canonical.com)]

I believe keeping the --destroy-all-models flag is helpful in keeping you
from accidentally destroying a controller that is hosting important models
for someone without thinking.

On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi 
wrote:

> Hey everyone,
>
> I know we've had discussions about this over the past few months, but it
> seems we have three commands that overlap pretty aggressively.
>
> Using Juju beta16, and trying to 'destroy' a controller it looks like this
> now:
>
> ```
> root@ubuntu:~# juju help destroy-controller
> Usage: juju destroy-controller [options] 
>
> ...
>
> Details:
> All models (initial model plus all workload/hosted) associated with the
> controller will first need to be destroyed, either in advance, or by
> specifying `--destroy-all-models`.
>
> Examples:
> juju destroy-controller --destroy-all-models mycontroller
>
> See also:
> kill-controller
> unregister
> ```
>
> When would you ever want to destroy-controller and not destroy-all-models?
> I have to specify that flag everytime, it seems it should just be the
> default behavior. Kill-controller seems to do what destroy-controller
> --destroy-all-models does but more aggressively?
>
> Finally, unregister and destroy-controller (without --destroy-all-models)
> does the same thing. Can we consider dropping the - very long winded almost
> always required - flag for destroy-controller?
>
> Finally, there used to be a pretty good amount of feedback during
> destroy-controller, while it was rolling text, I at least knew what was
> happening. Now it's virtually silent. Given it runs for quite a long time,
> can we get some form of feedback to the user back into the command?
>
> ```
> root@ubuntu:~# juju destroy-controller --destroy-all-models cabs
> WARNING! This command will destroy the "cabs" controller.
> This includes all machines, applications, data and other resources.
>
> Continue? (y/N):y
> ERROR failed to destroy controller "cabs"
>
> If the controller is unusable, then you may run
>
> juju kill-controller
>
> to forcibly destroy the controller. Upon doing so, review
> your cloud provider console for any resources that need
> to be cleaned up.
>
> ERROR cannot connect to API: unable to connect to API: websocket.Dial
> wss://10.0.0.4:17070/api: dial tcp 10.0.0.4:17070: getsockopt: no route
> to host
> root@ubuntu:~# juju kill-controller cabs
> WARNING! This command will destroy the "cabs" controller.
> This includes all machines, applications, data and other resources.
>
> Continue? (y/N):y
> Unable to open API: open connection timed out
> Unable to connect to the API server. Destroying through provider.
> ERROR listing resource groups: azure.ServicePrincipalToken#Refresh:
> Failure sending request for Service Principal 
> 83d638b0-841c-4bd1-9e7c-868cae3393f4:
> StatusCode=0 -- Original Error: http: nil Request.URL
> root@ubuntu:~# juju bootstrap cabs azure
> ERROR controller "cabs" already exists
> ```
>
> Marco
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Use of Jujucharms to launch non-opensource code

[Mark Ramm-Christensen (Canonical.com)]

Thanks Marco!

On Tue, Feb 9, 2016 at 1:33 PM, Marco Ceppi 
wrote:

> This is actually a non-issue. The codebase was moved to LGPL over a year
> ago, there was just two places this was not updated. First LaunchPad and
> second was the setup.py file. I've corrected both.
>
> On Tue, Feb 9, 2016 at 7:09 AM Marco Ceppi 
> wrote:
>
>> I'll take a look into this. charm-helpers seems to suffer a bit from
>> license schizophrenia. LP lists it as GPLv3, the code has both GPL and LGPL
>> license in root and setup.py lists it as AGPL. I will investigate this a
>> bit more and email the list in a separate thread when this is resolved.
>>
>> On Tue, Feb 9, 2016 at 7:07 AM Mark Shuttleworth  wrote:
>>
>>>
>>> OK, let's explore moving that to LGPL which I think would be more
>>> appropriate for things like that and layers.
>>>
>>> Mark
>>>
>>> On 09/02/16 12:04, John Meinel wrote:
>>> > I agree, I was a bit surprised that charmhelpers was AGPL instead of
>>> LGPL.
>>> > I think it makes sense as you still would contribute back to the
>>> layers you
>>> > touch, but it doesn't turn your entire charm into GPL.
>>> >
>>> > John
>>> > =->
>>> >
>>> >
>>> > On Tue, Feb 9, 2016 at 3:38 PM, Mark Shuttleworth 
>>> wrote:
>>> >
>>> >> On 09/02/16 09:25, John Meinel wrote:
>>> >>> The more edge case is that charmhelpers itself is AGPL, so if your
>>> charm
>>> >>> imported charmhelpers, then that is more of a grey area. You likely
>>> need
>>> >> to
>>> >>> open source the actual charm, which sets up configuration, etc of the
>>> >>> program. However, you still don't have to give out the source to the
>>> >>> program you are configuring.
>>> >> For stuff that we publish as libraries, we tend to prefer LGPL, which
>>> >> doesn't force a license on the end product or codebase. So if we need
>>> to
>>> >> revisit the charmhelpers license we will do so.
>>> >>
>>> >> Mark
>>> >>
>>> >>
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju for Redhat linux

[Mark Ramm-Christensen (Canonical.com)]

>> Does Juju work on Redhat linux platform ?
> No, unfortunately not. The only supported OSs are Ubuntu and CentOS, and
I'm not aware of any work in progress towards Red Hat. I'm sorry!

Exactly RHEL isn't supported yet, but if CentOS is good enough for you the
work is already done.   If you want RHEL that is not a large technical
distance at all from CentOS -- and if there is a strong desire to go there
juju is completely open source, and patches are always welcome.   Also
given evidence of customer demand, I'm confident our product roadmap will
be adjusted accordingly.

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

Re: How to make Juju High Availability work properly?

[Mark Ramm-Christensen (Canonical.com)]

Thanks for following up!

We will take a look at the logs and get back to you soon.

--Mark Ramm

On Mon, Oct 26, 2015 at 4:41 AM, 曾建銘  wrote:

> Hi Mark & Marco,
>
> Really appreciate your help. I have already provide the logs to Marco.
>
> Hope it could help you to enhance the Juju HA feature.
>
> Sincerely yours,
> Leon
>
> On Sat, Oct 24, 2015 at 7:03 AM, Mark Shuttleworth 
> wrote:
>
>> On 23/10/15 00:54, 曾建銘 wrote:
>> > Was the juju doing something for fixing specific problem? I think that
>> > service on failed node should only become lost and not interfere
>> services
>> > on workings nodes. But it didn't act as I expected.
>> >
>> > By the way, I used Juju to deploy OpenStack, so I deployed a lot of
>> charms
>> > on it. Is that matter?
>>
>> No, the scale of the model you're managing should not affect HA in any
>> way.
>>
>> The team is trying to reproduce your situation by repeatedly causing
>> failover, but I'm told has not seen anything like your symptoms. Can you
>> provide copies of logs to Marco?
>>
>> Mark
>>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: What's the future of Juju?

[Mark Ramm-Christensen (Canonical.com)]

As promised partners making use of juju as part of the OpenStack
Interoperability Lab (OIL)  include:

   - IBM
   - Microsoft
   - Intel
   - AMD
   - HP
   - Juniper
   - Lenovo
   - Melanox
   - Metaswitch
   - OCP (Open Compute Project)
   - SanDisk
   - VMWare

There are actually quite a few more, but that should give you some
confidence that we are building traction with many infrastructure providers
of all kinds.


On Wed, Mar 25, 2015 at 4:33 PM, Mark Ramm-Christensen (Canonical.com) <
mark.ramm-christen...@canonical.com> wrote:

> Well, I can provide a few things off the top of my head that should help.
>
>- Canonical is fully committed to Juju as the way we deploy software
>internally, the way we deploy Open Stack clouds for our largest clients
>- Windows workloads are supported in the current beta version of Juju,
>and should after a bit of real-world testing be fully supported in one of
>the next (bi-monthly) production ready releases.
>- CentOS support is nearly feature complete, and should enter a beta
>release of Juju for testing within the next month.  Like windows it will
>flow to a production release after it's had some real-world tests.
>
> There are quite a few big companies working on juju charms.  IBM for
> example is delivering quite a few charms and has committed multiple full
> time development resources to working with juju.
>
> There are also quite a few other big names working on juju charms -- many
> of them in the OpenStack space.  I'll get a list of folks who are already
> public about being part of our juju based openstack integration labs for
> you as soon as I can.
>
> We also have some big plans for products built on top of juju.  The first
> of which is the OpenStack Autopilot which automates the deployment,
> scale-out, and management of OpenStack clouds.   But, we are also building
> more products on top of Juju right now, and it is core to our future plans
> in the cloud.
>
> So, to make a long story short, I think juju is gaining traction with some
> big enterprise players, Canonical is fully committed to Juju, and we are
> seeing momentum pick up in the marketplace.   So, I personally would
> definitely bet on a bright future for Juju.
>
> --Mark Ramm
>
>
>
>
>
> On Wed, Mar 25, 2015 at 4:01 PM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi
>>
>>
>> I'm interested in what the future of Juju is. From the small experience
>> I've had with it, it seems like a product with a lot of potential. It fills
>> a gap in our project that no other technology can fill. Its biggest
>> strength is how relations between services are managed. This is something
>> that, to my knowledge, does not exist in any tool today. It enables a very
>> modular approach and solves a lot of problems we would have with other
>> tools.
>>
>> However, I've also seen some things that worry me. Even after three
>> years, there are still a lot of bugs in the project. The documentation is
>> lacking, especially in the parts of Juju that are the most competitive. The
>> community is also very small. The fact that it can still only manage Ubuntu
>> servers worries me too. I could go more into detail here, but I don't think
>> it is relevant to this question.
>>
>> I'm considering starting a big long-term project on top of Juju. The
>> project would be very dependent on Juju, so I don't want to do this if
>> there is a chance that Juju will be abandoned in 5 years...
>>
>> What can you tell me about the future of Juju? Things I'm interested in:
>>
>> - Big companies building services on top of Juju
>>
>> - Statements of long-term commitment from Canonical
>>
>> - Usage statistics
>>
>> - Statements of commitment to support other distro's
>>
>> - .. or else, signs that Juju doesn't have a bright future.
>>
>>
>> Thanks
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: What's the future of Juju?

[Mark Ramm-Christensen (Canonical.com)]

Well, I can provide a few things off the top of my head that should help.

   - Canonical is fully committed to Juju as the way we deploy software
   internally, the way we deploy Open Stack clouds for our largest clients
   - Windows workloads are supported in the current beta version of Juju,
   and should after a bit of real-world testing be fully supported in one of
   the next (bi-monthly) production ready releases.
   - CentOS support is nearly feature complete, and should enter a beta
   release of Juju for testing within the next month.  Like windows it will
   flow to a production release after it's had some real-world tests.

There are quite a few big companies working on juju charms.  IBM for
example is delivering quite a few charms and has committed multiple full
time development resources to working with juju.

There are also quite a few other big names working on juju charms -- many
of them in the OpenStack space.  I'll get a list of folks who are already
public about being part of our juju based openstack integration labs for
you as soon as I can.

We also have some big plans for products built on top of juju.  The first
of which is the OpenStack Autopilot which automates the deployment,
scale-out, and management of OpenStack clouds.   But, we are also building
more products on top of Juju right now, and it is core to our future plans
in the cloud.

So, to make a long story short, I think juju is gaining traction with some
big enterprise players, Canonical is fully committed to Juju, and we are
seeing momentum pick up in the marketplace.   So, I personally would
definitely bet on a bright future for Juju.

--Mark Ramm





On Wed, Mar 25, 2015 at 4:01 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi
>
>
> I'm interested in what the future of Juju is. From the small experience
> I've had with it, it seems like a product with a lot of potential. It fills
> a gap in our project that no other technology can fill. Its biggest
> strength is how relations between services are managed. This is something
> that, to my knowledge, does not exist in any tool today. It enables a very
> modular approach and solves a lot of problems we would have with other
> tools.
>
> However, I've also seen some things that worry me. Even after three years,
> there are still a lot of bugs in the project. The documentation is lacking,
> especially in the parts of Juju that are the most competitive. The
> community is also very small. The fact that it can still only manage Ubuntu
> servers worries me too. I could go more into detail here, but I don't think
> it is relevant to this question.
>
> I'm considering starting a big long-term project on top of Juju. The
> project would be very dependent on Juju, so I don't want to do this if
> there is a chance that Juju will be abandoned in 5 years...
>
> What can you tell me about the future of Juju? Things I'm interested in:
>
> - Big companies building services on top of Juju
>
> - Statements of long-term commitment from Canonical
>
> - Usage statistics
>
> - Statements of commitment to support other distro's
>
> - .. or else, signs that Juju doesn't have a bright future.
>
>
> Thanks
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: disabling upgrades on new machines by default?

[Mark Ramm-Christensen (Canonical.com)]

In practice, it almost never happens.

I don't remember seeing anything actually from the archive break a charm on
update -- though the cloud tools pocket did have a breakage about 8 months
ago which did bad things.

--Mark Ramm

On Thu, Oct 2, 2014 at 10:14 AM, Matt Rae  wrote:

> Thanks Dave!
>
> A downside to disabling upgrades is that users may have a bad experience
> if broken packages get installed and their services don't work. Not sure
> how often this would happen.
>
> On Thu, Oct 2, 2014 at 6:19 AM, David Cheney 
> wrote:
>
>>
>>
>> On Thu, Oct 2, 2014 at 10:55 PM, Matt Rae  wrote:
>>
>>> I don't think the upgrade matters as much as speed. I feel like most
>>> users know to manage updates already, with their own policies, and that the
>>> fast user experience is important.
>>>
>>> Even if juju upgrades initially, users will still need to manage updates
>>> after, so I'm not sure how much the initial upgrade gains.
>>>
>>> "Juju is blazing fast!" is more exciting than "Juju makes sure I'm
>>> updated initially!"
>>>
>>> There is something to be said for having the exact same packages on
>>> every unit of a service rather than a few units having some versions, then
>>> units added later getting different versions.
>>>
>>
>> That happens anyway. Units added later may be built from later releases
>> of the cloud image.
>>
>>
>>>
>>>
>>> Matt
>>>
>>> On Thu, Oct 2, 2014 at 12:27 AM, Samuel Cozannet <
>>> samuel.cozan...@canonical.com> wrote:
>>>
 Why not put our perception to the test?

 Here
 
 is a spreadsheet where you can compile your variables. The top line
 summarizes the sum of values. The column that gets green is the one we
 should go for [assuming we are representative]

 Sam

 On Thu, Oct 2, 2014 at 7:45 AM, John Meinel 
 wrote:

> So there is the question of what is the "user experience", and people
> trying out Juju and it seems slow. Though if it is slow, doesn't that mean
> that images are out of date?
>
> I just bootstrapped a fresh Ubuntu from Amazon's web interface today,
> and I noticed that apt-get upgrade on there installed a new bash to fix 
> the
> newest major security hole. It seems like it is good to at least apply
> security updates, and I'm not sure if it is easy to only install those.
>
> John
> =:->
>
> On Thu, Oct 2, 2014 at 7:51 AM, José Antonio Rey 
> wrote:
>
>> I believe that, as Jorge mentioned, most users do value having
>> everything up to date by default, specially when they may go directly to
>> production environments. Devs may also want to use this switch, as it 
>> will
>> save time during the deployment for testing the charms they have 
>> developed.
>>
>> I believe that turning on upgrades as a default would be more valued
>> by end-users, but that's just a personal opinion.
>>
>> --
>> José Antonio Rey
>> On Oct 1, 2014 2:34 PM, "Jorge O. Castro"  wrote:
>>
>>> On Wed, Oct 1, 2014 at 3:26 PM, Kapil Thangavelu
>>>  wrote:
>>> > juju can save minutes per machine (especially against release
>>> images) if we
>>> > turn off upgrades by default.
>>>
>>> There are some updates coming to how we build cloud images that might
>>> be relevant to this discussion:
>>>
>>> http://blog.utlemming.org/2014/08/archive-triggered-cloud-image-builds.html
>>>
>>> IMO safer and slower makes sense for most people, those of us who
>>> need
>>> speed for demos/conferences will know about this switch.
>>>
>>> --
>>> Jorge Castro
>>> Canonical Ltd.
>>> http://juju.ubuntu.com/ - Automate your Cloud Infrastructure
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>


 --
 Samuel Cozannet
 Cloud, Big Data and IoT Strategy Team
 Strategic Program Manager
 Changing the Future of Cloud
 Ubuntu  / Canonical  UK LTD
 samuel.cozan...@canonical.com
 +33 616 702 389


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


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

Re: Juju is still too hard

[Mark Ramm-Christensen (Canonical.com)]

I think we need to make sure that we do the best error reporting we can, so
if Juju isn't working because of Azure issues, we should find some way to
let users know that so that they can try another cloud, contact microsoft,
or otherwise find another way forward.

--Mark Ramm

On Mon, Sep 22, 2014 at 9:16 AM, Michael Schwartz  wrote:

> Juju,
>
> The note I got from Nate on Azure is below (after wasting a day trying to
> get it working...)
>
> At OSCON, I worked with Jorge and even he couldn't get my local VM
> working, but I'm willing to give it a try again. I'd be willing to schedule
> a meeting (please email me off the list to schedule).
>
> But please note, its not just me. I am reflecting the consensus of
> customers and partners about Juju. And its hard for me to dismiss their
> concerns given my own experience.
>
> - Mike
>
>
>
>  Original Message 
> Subject: Re: Problems with Azure
> Date: 2014-08-28 11:35
> From: Nate Finch 
>
> Azure is in a bad state today.  Our tests won't run on Azure today
> either.  So, there's not much we can do except complain to Microsoft.
>
> -
> Michael Schwartz
> Gluu
> Founder / CEO
> m...@gluu.org
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: --constraints "root-disk=16384M" fails in EC2

[Mark Ramm-Christensen (Canonical.com)]

The link to the bug is here:

https://bugs.launchpad.net/juju-core/+bug/1324729


On Thu, May 29, 2014 at 7:26 PM, Ian Booth  wrote:

> Hi Stein
>
> This does appear to be a bug in Juju's constraints handling for EC2.
> I'd have to do an experiment to confirm, but certainly reading the code
> appears to show a problem.
>
> Given how EC2 works, in that Juju asks for the specified root disk size
> when starting an instance, I don't have a workaround that I can think
> of to share with you.
>
> The fix for this would be relatively simple to implement and so can be
> done in time for the next stable release (1.20) which is due in a few
> weeks. Alternatively, we hope to have a new development release out
> next week (1.19.3).  I'll try to get any fix done in time for that also.
>
> I've raised bug 1324729 for this issue.
>
> On Fri 30 May 2014 09:29:15 EST, GMail wrote:
> > Trying to deploy a charm with some extra root disk space. When using the
> root-disk constraint defined above I get the following error:
> >
> > '(error: no instance types in us-east-1 matching constraints
> "cpu-power=100 root-disk=16384M")'
> >
> > I’m deploying a bundle with the following constraints: constraints:
> "mem=4G arch=amd64”, but need more disk-space then the default provided.
> >
> > Any suggestions ?
> >
> >
> > Stein Myrseth
> > Bjørkesvingen 6J
> > 3408 Tranby
> > mob: +47 909 62 763
> > mailto:stein.myrs...@gmail.com
> >
> >
> >
> >
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju