Unit number is increasing in latest juju version.

[Sunitha Radharapu]

Hi,

We have found in juju 1.25.0.1  version that each time service gets
deployed unit number is increased like below.
 "service-name/1, service-name/2,  service-name/n.."
Earlier juju versions everytime we would deploy  unit number would be same
as "service-name/0".

Due to this change our amulet tests are failing since we have hardcoded
unit name as  shown below;

def test_case(self):
self.assertTrue(self.d.deployed)
unit_manager_0 = self.d.sentry.unit['ibm-mobilefirst-server/0']
address = unit_manager_0.info['public-address']

 Can you please suggest a way to get dynamic unit name while running tests.

Thanks,
Sunitha.









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

Re: Unit number is increasing in latest juju version.

[Matthew Williams]

Hi Sunitha,

I believe you can do the following:

unit_manager_0 = self.d.sentry["ibm-mobilefirst-server"][0]

Does that resolve the problem?

Many thanks

Matty

On Fri, Nov 13, 2015 at 9:50 AM, Sunitha Radharapu 
wrote:

> Hi,
>
> We have found in juju *1.25.0.1* version that each time service gets
> deployed unit number is increased like below.
> "service-name/1, service-name/2, service-name/n.."
> Earlier juju versions everytime we would deploy unit number would be same
> as "service-name/0".
>
> Due to this change our amulet tests are failing since we have hardcoded
> unit name as shown below;
>
> def test_case(self):
> self.assertTrue(self.d.deployed)
> unit_manager_0 = self.d.sentry.unit['*ibm-mobilefirst-server/0*']
> address = unit_manager_0.info['public-address']
>
> Can you please suggest a way to get dynamic unit name while running tests.
>
> Thanks,
> Sunitha.
>
>
>
>
>
>
>
>
>
>
>
> --
> 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: Unit number is increasing in latest juju version.

[Mark Shuttleworth]

OK. So I suspect the tests were written to reuse the environment because
bootstrapping takes time.

The good news is, we'll shortly get instant environment creation, so a
clean environment will be cheap and fast.

:)

Mark

On 13/11/15 10:02, Matthew Williams wrote:
> Hi Mark, Sunitha,
>
> My apologies, I should have included the explanation in the original email.
>
> This was a change to address a long standing bug:
> https://bugs.launchpad.net/juju-core/+bug/1174610
>
> There's a discussion in the bug report, but the summary is that in most
> cases it's desirable to have the unit id be unique across the life of an
> environment. Otherwise you loose the identity of a unit across relations.
>
> We were already numbering the machines in the same way, so this change also
> gives us consistency between machine and unit numbering systems.
>
> Thanks
>
> Matty
>
> On Fri, Nov 13, 2015 at 1:50 PM, Mark Shuttleworth  wrote:
>
>> Thanks Sunitha. Matty, deeper question is - was this an intended change
>> in behaviour, and what's the rationale?
>>
>> Mark
>>


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

Re: Unit number is increasing in latest juju version.

[Matthew Williams]

Hi Sunitha,

The bug is closed, it was fixed and released in juju 1.25.

There are some docs at the below link that summarise the behaviour:

https://jujucharms.com/docs/1.25/reference-numbering

If you'd like to have a talk about this I'd be very happy to. I'm mattyw on
irc in #juju and #juju-dev (otherwise email is fine)

Thanks

Matty



On Fri, Nov 13, 2015 at 3:49 PM, Sunitha Radharapu <sradh...@in.ibm.com>
wrote:

> Hi Matt,
>
> I am a little bit confused here, bug description says it should be as
> unique id. If it is a bug and you are going to fix in future juju releases
> then we no need to change our amulet tests.
>
> If it is a new feature then we will change our upcoming charms
> accordingly,
>
> Thanks,
> Sunitha.
>
>
>
>
> [image: Inactive hide details for Matthew Williams ---13-11-2015
> 20:32:45---Hi Mark, Sunitha, My apologies, I should have included the]Matthew
> Williams ---13-11-2015 20:32:45---Hi Mark, Sunitha, My apologies, I should
> have included the explanation in the original email.
>
> From: Matthew Williams <matthew.willi...@canonical.com>
> To: Mark Shuttleworth <m...@ubuntu.com>
> Cc: Sunitha Radharapu/India/IBM@IBMIN, Juju email list <
> juju@lists.ubuntu.com>
> Date: 13-11-2015 20:32
> Subject: Re: Unit number is increasing in latest juju version.
> --
>
>
>
> Hi Mark, Sunitha,
>
> My apologies, I should have included the explanation in the original email.
>
> This was a change to address a long standing bug:
> *https://bugs.launchpad.net/juju-core/+bug/1174610*
> <https://bugs.launchpad.net/juju-core/+bug/1174610>
>
> There's a discussion in the bug report, but the summary is that in most
> cases it's desirable to have the unit id be unique across the life of an
> environment. Otherwise you loose the identity of a unit across relations.
>
> We were already numbering the machines in the same way, so this change
> also gives us consistency between machine and unit numbering systems.
>
> Thanks
>
> Matty
>
> On Fri, Nov 13, 2015 at 1:50 PM, Mark Shuttleworth <*m...@ubuntu.com*
> <m...@ubuntu.com>> wrote:
>
>
>Thanks Sunitha. Matty, deeper question is - was this an intended change
>in behaviour, and what's the rationale?
>
>Mark
>
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Unit number is increasing in latest juju version.

[José Antonio Rey]

This is something I raised with Marco, Matt and Chuck while in the Charmers
Summit. There are several mixed opinions with regards to this, some say
it's logical because each unit in an environment is unique, however it's
not how Juju used to behave, hence breaking most of the tests in the store,
which were designed to run considering the old unit naming scheme.

I don't disagree with it, and the fix is simple enough. But please let's
try and give a grace period before, so tests that have been already created
can adapt to the new scheme and don't give false positives, as well as for
people to adapt to the new naming scheme and understand why it's been
changed.

--
José Antonio Rey

On Fri, Nov 13, 2015, 10:10 Mark Shuttleworth  wrote:

>
> OK. So I suspect the tests were written to reuse the environment because
> bootstrapping takes time.
>
> The good news is, we'll shortly get instant environment creation, so a
> clean environment will be cheap and fast.
>
> :)
>
> Mark
>
> On 13/11/15 10:02, Matthew Williams wrote:
> > Hi Mark, Sunitha,
> >
> > My apologies, I should have included the explanation in the original
> email.
> >
> > This was a change to address a long standing bug:
> > https://bugs.launchpad.net/juju-core/+bug/1174610
> >
> > There's a discussion in the bug report, but the summary is that in most
> > cases it's desirable to have the unit id be unique across the life of an
> > environment. Otherwise you loose the identity of a unit across relations.
> >
> > We were already numbering the machines in the same way, so this change
> also
> > gives us consistency between machine and unit numbering systems.
> >
> > Thanks
> >
> > Matty
> >
> > On Fri, Nov 13, 2015 at 1:50 PM, Mark Shuttleworth 
> wrote:
> >
> >> Thanks Sunitha. Matty, deeper question is - was this an intended change
> >> in behaviour, and what's the rationale?
> >>
> >> 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: Unit number is increasing in latest juju version.

[Simon Davy]

On 13 November 2015 at 15:02, Matthew Williams
 wrote:
> Hi Mark, Sunitha,
>
> My apologies, I should have included the explanation in the original email.
>
> This was a change to address a long standing bug:
> https://bugs.launchpad.net/juju-core/+bug/1174610

Ah - I must have been remembering the older behaviour. I remember
being surprised that destroy-service didn;t reset unit numbering
previously - I hadn't realised it had been changed in the mean time.

> There's a discussion in the bug report, but the summary is that in most
> cases it's desirable to have the unit id be unique across the life of an
> environment. Otherwise you loose the identity of a unit across relations.

This makes sense to me.

Thanks

-- 
Simon

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

Re: Unit number is increasing in latest juju version.

[Matthew Williams]

Hi Mark, Sunitha,

My apologies, I should have included the explanation in the original email.

This was a change to address a long standing bug:
https://bugs.launchpad.net/juju-core/+bug/1174610

There's a discussion in the bug report, but the summary is that in most
cases it's desirable to have the unit id be unique across the life of an
environment. Otherwise you loose the identity of a unit across relations.

We were already numbering the machines in the same way, so this change also
gives us consistency between machine and unit numbering systems.

Thanks

Matty

On Fri, Nov 13, 2015 at 1:50 PM, Mark Shuttleworth  wrote:

>
> Thanks Sunitha. Matty, deeper question is - was this an intended change
> in behaviour, and what's the rationale?
>
> Mark
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Unit number is increasing in latest juju version.

[Sunitha Radharapu]

Hi Matt,

I am a little bit confused here, bug description says it should be as
unique id. If it is a bug and you are going to fix in future juju releases
then we no need to change our amulet tests.

If it is a new feature then we will change our upcoming charms accordingly,

Thanks,
Sunitha.






From:   Matthew Williams <matthew.willi...@canonical.com>
To: Mark Shuttleworth <m...@ubuntu.com>
Cc: Sunitha Radharapu/India/IBM@IBMIN, Juju email list
<juju@lists.ubuntu.com>
Date:   13-11-2015 20:32
Subject:    Re: Unit number is increasing in latest juju version.



Hi Mark, Sunitha,

My apologies, I should have included the explanation in the original email.

This was a change to address a long standing bug:
https://bugs.launchpad.net/juju-core/+bug/1174610

There's a discussion in the bug report, but the summary is that in most
cases it's desirable to have the unit id be unique across the life of an
environment. Otherwise you loose the identity of a unit across relations.

We were already numbering the machines in the same way, so this change also
gives us consistency between machine and unit numbering systems.

Thanks

Matty

On Fri, Nov 13, 2015 at 1:50 PM, Mark Shuttleworth <m...@ubuntu.com> wrote:

  Thanks Sunitha. Matty, deeper question is - was this an intended change
  in behaviour, and what's the rationale?

  Mark

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

Re: Unit number is increasing in latest juju version.

[Marco Ceppi]

Regardless of the outcome of the bug, the proper syntax for accessing units
is as follows:

self.d.sentry["ibm-mobilefirst-server"][0]

This is because, our new testing environment and soon to be normal testing
procedure for all charms while we wait for multi-model environments
recycles the environment and also incurs this increase. Either way,
hard-coded unit values tend to be fragile in general. This will do a look
up and always return the first unit. The previous hard-coded examples in
documentation are being updated to reflect this, I didn't realize how many
bad examples I'd produced over the years :)

Marco

On Fri, Nov 13, 2015 at 10:55 AM Matthew Williams <
matthew.willi...@canonical.com> wrote:

> Hi Sunitha,
>
> The bug is closed, it was fixed and released in juju 1.25.
>
> There are some docs at the below link that summarise the behaviour:
>
> https://jujucharms.com/docs/1.25/reference-numbering
>
> If you'd like to have a talk about this I'd be very happy to. I'm mattyw
> on irc in #juju and #juju-dev (otherwise email is fine)
>
> Thanks
>
> Matty
>
>
>
> On Fri, Nov 13, 2015 at 3:49 PM, Sunitha Radharapu <sradh...@in.ibm.com>
> wrote:
>
>> Hi Matt,
>>
>> I am a little bit confused here, bug description says it should be as
>> unique id. If it is a bug and you are going to fix in future juju releases
>> then we no need to change our amulet tests.
>>
>> If it is a new feature then we will change our upcoming charms
>> accordingly,
>>
>> Thanks,
>> Sunitha.
>>
>>
>>
>>
>> [image: Inactive hide details for Matthew Williams ---13-11-2015
>> 20:32:45---Hi Mark, Sunitha, My apologies, I should have included the]Matthew
>> Williams ---13-11-2015 20:32:45---Hi Mark, Sunitha, My apologies, I should
>> have included the explanation in the original email.
>>
>> From: Matthew Williams <matthew.willi...@canonical.com>
>> To: Mark Shuttleworth <m...@ubuntu.com>
>> Cc: Sunitha Radharapu/India/IBM@IBMIN, Juju email list <
>> juju@lists.ubuntu.com>
>> Date: 13-11-2015 20:32
>> Subject: Re: Unit number is increasing in latest juju version.
>> --
>>
> Hi Mark, Sunitha,
>>
>> My apologies, I should have included the explanation in the original
>> email.
>>
>> This was a change to address a long standing bug:
>> *https://bugs.launchpad.net/juju-core/+bug/1174610*
>> <https://bugs.launchpad.net/juju-core/+bug/1174610>
>>
>> There's a discussion in the bug report, but the summary is that in most
>> cases it's desirable to have the unit id be unique across the life of an
>> environment. Otherwise you loose the identity of a unit across relations.
>>
>> We were already numbering the machines in the same way, so this change
>> also gives us consistency between machine and unit numbering systems.
>>
>> Thanks
>>
>> Matty
>>
>> On Fri, Nov 13, 2015 at 1:50 PM, Mark Shuttleworth <*m...@ubuntu.com*
>> <m...@ubuntu.com>> wrote:
>>
>>
>>Thanks Sunitha. Matty, deeper question is - was this an intended
>>change
>>in behaviour, and what's the rationale?
>>
>>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