Re: vsphere support

2017-10-04 Thread Serge E. Hallyn 
Quoting Dmitrii Shcherbakov (dmitrii.shcherba...@canonical.com):
> Hi Serge,
> 
> >From my perspective Juju will continue getting more support for vSphere
> provider as VMware is used by some customers that do not want to go with a
> full-blown bare-metal deployment and just have spare VMs.

Ok, that's encouraging.

> I personally had to do a deployment of K8s on ESX (don't remember which
> version they had) but I had to use the manual provider because a custom
> provisioning method and IPAM was used on-site without DHCP so there was no
> way to use the proper vSphere provider.

I've got a DNS server, but it's separate from the juju server right now.
Hopefully that is ok.

> >From the commercial perspective VMware is listed in a (fresh) datasheet
> below and we do have that demand.
> 
> https://assets.ubuntu.com/v1/b35eca50-Enterprise-Kubernetes-datasheet.pdf?_ga=2.138877683.1310562253.1507133746-467575700.1507133746
> 
> Best Regards,
> Dmitrii Shcherbakov
> 
> Field Software Engineer
> IRC (freenode): Dmitrii-Sh

Thanks,
-serge

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

Re: vsphere support

2017-10-04 Thread christian . setzer 

 Hi

I have a openstack charm installation and kubernetes cluster running  
currently.
I  remember trying vsphere support as well but it didnt work. sorry  
but that just came to my mind. so i was bound to use maas in order to  
use vsphere and juju.


BR

  

 Christian

Quoting "Serge E. Hallyn" :

Well if using MAAS would be easier, I'm happy to do that.  I  
actually just hadn't

considered it a possibility, but I see at
https://askubuntu.com/questions/870624/configuring-maas-with-vmware-esxi-nodes-and-virsh
that it may be :)

I wonder what would be the difference in range of charms that I can  
actually use

if I use MAAS vs directly use juju vsphere support.

-serge

Quoting christian.set...@freies-franken.org  
(christian.set...@freies-franken.org):

Hi

Thats typical me. I implied that you use maas and have trouble
setting it up with juju as a cloud. Pardon me. Thats how i work ;-)

BR

 

Christian

Quoting "Serge E. Hallyn" :

Quoting christian.set...@freies-franken.org
(christian.set...@freies-franken.org):
Hi

6.0 should work. It does for me and even 6.5.

Ok - like I say I only have the one 6.0 so not ideal, but a starting
point.

I already have offered the devs that they can use my environment to
sort out all the open bugs. But so far nobody was willing to do so.

...

What i did maybe helpful do you...

#!/bin/bash
maas - machines add-chassis chassis_type='vmware'
username='\' password=''
protocol='https+unverified' hostname=
prefix_filter= domain=

Pardon my ignorance - but I don't know what I'm looking at :)  Do
you run that on the juju server then target juju at that maas
instance?

Without the https+unverified i couldnt get it to work adding a
chassis because in the GUI the protocol field is missing.

BR

Christian

thanks,-serge


pub  2048R/DF0339A2 2017-09-10 Christian Setzer  


sub  2048R/68E412B2 2017-09-10


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


binOPBg1iQWxH.bin
Description: PGP Public Key
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: vsphere support

2017-10-04 Thread Marco Ceppi 
There really shouldn't be any difference in the charms that are deploy-able
on MAAS vs vSphere. The Juju team has made a lot of strides in 2.2 and the
upcoming 2.3 release to support vSphere directly. MAAS management of
vSphere is slightly different than Juju if I recall correctly, but
shouldn't impact charm compatibility.

Marco

On Wed, Oct 4, 2017 at 1:28 PM Serge E. Hallyn  wrote:

> Well if using MAAS would be easier, I'm happy to do that.  I actually just
> hadn't
> considered it a possibility, but I see at
>
> https://askubuntu.com/questions/870624/configuring-maas-with-vmware-esxi-nodes-and-virsh
> that it may be :)
>
> I wonder what would be the difference in range of charms that I can
> actually use
> if I use MAAS vs directly use juju vsphere support.
>
> -serge
>
> Quoting christian.set...@freies-franken.org (
> christian.set...@freies-franken.org):
> >  Hi
> >
> > Thats typical me. I implied that you use maas and have trouble
> > setting it up with juju as a cloud. Pardon me. Thats how i work ;-)
> >
> > BR
> >
> >
> >
> >  Christian
> >
> > Quoting "Serge E. Hallyn" :
> >
> > >Quoting christian.set...@freies-franken.org
> > >(christian.set...@freies-franken.org):
> > >>Hi
> > >>
> > >>6.0 should work. It does for me and even 6.5.
> > >
> > >Ok - like I say I only have the one 6.0 so not ideal, but a starting
> > >point.
> > >
> > >>I already have offered the devs that they can use my environment to
> > >>sort out all the open bugs. But so far nobody was willing to do so.
> > >
> > >...
> > >
> > >>What i did maybe helpful do you...
> > >>
> > >>#!/bin/bash
> > >>maas - machines add-chassis chassis_type='vmware'
> > >>username='\' password=''
> > >>protocol='https+unverified' hostname=
> > >>prefix_filter= domain=
> > >
> > >Pardon my ignorance - but I don't know what I'm looking at :)  Do
> > >you run that on the juju server then target juju at that maas
> > >instance?
> > >
> > >>Without the https+unverified i couldnt get it to work adding a
> > >>chassis because in the GUI the protocol field is missing.
> > >>
> > >>BR
> > >>
> > >>Christian
> > >
> > >thanks,-serge
>
> > pub  2048R/DF0339A2 2017-09-10 Christian Setzer <
> christian.set...@freies-franken.org>
> > sub  2048R/68E412B2 2017-09-10
>
>
> --
> 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: vsphere support

2017-10-04 Thread Serge E. Hallyn 
Well if using MAAS would be easier, I'm happy to do that.  I actually just 
hadn't
considered it a possibility, but I see at
https://askubuntu.com/questions/870624/configuring-maas-with-vmware-esxi-nodes-and-virsh
that it may be :)

I wonder what would be the difference in range of charms that I can actually use
if I use MAAS vs directly use juju vsphere support.

-serge

Quoting christian.set...@freies-franken.org 
(christian.set...@freies-franken.org):
>  Hi
> 
> Thats typical me. I implied that you use maas and have trouble
> setting it up with juju as a cloud. Pardon me. Thats how i work ;-)
> 
> BR
> 
>   
> 
>  Christian
> 
> Quoting "Serge E. Hallyn" :
> 
> >Quoting christian.set...@freies-franken.org
> >(christian.set...@freies-franken.org):
> >>Hi
> >>
> >>6.0 should work. It does for me and even 6.5.
> >
> >Ok - like I say I only have the one 6.0 so not ideal, but a starting
> >point.
> >
> >>I already have offered the devs that they can use my environment to
> >>sort out all the open bugs. But so far nobody was willing to do so.
> >
> >...
> >
> >>What i did maybe helpful do you...
> >>
> >>#!/bin/bash
> >>maas - machines add-chassis chassis_type='vmware'
> >>username='\' password=''
> >>protocol='https+unverified' hostname=
> >>prefix_filter= domain=
> >
> >Pardon my ignorance - but I don't know what I'm looking at :)  Do
> >you run that on the juju server then target juju at that maas
> >instance?
> >
> >>Without the https+unverified i couldnt get it to work adding a
> >>chassis because in the GUI the protocol field is missing.
> >>
> >>BR
> >>
> >>Christian
> >
> >thanks,-serge

> pub  2048R/DF0339A2 2017-09-10 Christian Setzer 
> 
> sub  2048R/68E412B2 2017-09-10


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

Re: vsphere support

2017-10-04 Thread christian . setzer 

 Hi

Thats typical me. I implied that you use maas and have trouble setting  
it up with juju as a cloud. Pardon me. Thats how i work ;-)


BR

  

 Christian

Quoting "Serge E. Hallyn" :

Quoting christian.set...@freies-franken.org  
(christian.set...@freies-franken.org):

Hi

6.0 should work. It does for me and even 6.5.


Ok - like I say I only have the one 6.0 so not ideal, but a starting
point.


I already have offered the devs that they can use my environment to
sort out all the open bugs. But so far nobody was willing to do so.


...


What i did maybe helpful do you...

#!/bin/bash
maas - machines add-chassis chassis_type='vmware'
username='\' password=''
protocol='https+unverified' hostname=
prefix_filter= domain=


Pardon my ignorance - but I don't know what I'm looking at :)  Do
you run that on the juju server then target juju at that maas
instance?


Without the https+unverified i couldnt get it to work adding a
chassis because in the GUI the protocol field is missing.

BR

Christian


thanks,-serge


bins1Cqe7aYAn.bin
Description: PGP Public Key
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: vsphere support

2017-10-04 Thread Serge E. Hallyn 
Quoting christian.set...@freies-franken.org 
(christian.set...@freies-franken.org):
>  Hi
> 
> 6.0 should work. It does for me and even 6.5.

Ok - like I say I only have the one 6.0 so not ideal, but a starting
point.

> I already have offered the devs that they can use my environment to
> sort out all the open bugs. But so far nobody was willing to do so.

...

> What i did maybe helpful do you...
> 
> #!/bin/bash
>  maas - machines add-chassis chassis_type='vmware'
> username='\' password=''
> protocol='https+unverified' hostname=
> prefix_filter= domain=

Pardon my ignorance - but I don't know what I'm looking at :)  Do
you run that on the juju server then target juju at that maas
instance?

> Without the https+unverified i couldnt get it to work adding a
> chassis because in the GUI the protocol field is missing.
> 
> BR
> 
> Christian

thanks,
-serge

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

Re: vsphere support

2017-10-04 Thread Dmitrii Shcherbakov 
Hi Serge,

>From my perspective Juju will continue getting more support for vSphere
provider as VMware is used by some customers that do not want to go with a
full-blown bare-metal deployment and just have spare VMs.

I personally had to do a deployment of K8s on ESX (don't remember which
version they had) but I had to use the manual provider because a custom
provisioning method and IPAM was used on-site without DHCP so there was no
way to use the proper vSphere provider.

>From the commercial perspective VMware is listed in a (fresh) datasheet
below and we do have that demand.

https://assets.ubuntu.com/v1/b35eca50-Enterprise-Kubernetes-datasheet.pdf?_ga=2.138877683.1310562253.1507133746-467575700.1507133746

Best Regards,
Dmitrii Shcherbakov

Field Software Engineer
IRC (freenode): Dmitrii-Sh

On Wed, Oct 4, 2017 at 12:08 PM, Serge E. Hallyn  wrote:

> Hi,
>
> I've inherited a few vsphere machines where I was hoping to use juju
> to fire off openstack etc.  I've been trying to use the vsphere
> provider (which I was excited to see existed), but am seeing a few
> inconsistencies, so had a few questions.
>
> The first blunt question - is this going to be a maintained driver,
> or am I in 6 months likely to find the vsphere driver dropped?
>
> The second is motivating the first - when I looked at
> https://jujucharms.com/docs/2.1/help-vmware it says hardware version
> 8 (ESX 5.0) should be sufficient.  But in fact juju has a ubuntu.ovf
> hardcoded in it that specifies 'vmx-10', which is ESX 5.5..  I currently
> have 5 ESX 5.1 machines and one 6.0.
>
> Even with a custom DC using only the 6.0 host, I have some (probably
> proxy) issues bootstrapping, which I'm sure are surmountable - but the
> answer to Q1 will decide whether it's worth pursuing that further, or
> whether I should spend my time elsewhere :)
>
> thanks,
> -serge
>
> --
> 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: vsphere support

2017-10-04 Thread christian . setzer 

 Hi

6.0 should work. It does for me and even 6.5.

I already have offered the devs that they can use my environment to  
sort out all the open bugs. But so far nobody was willing to do so.


What i did maybe helpful do you...

#!/bin/bash
 maas - machines add-chassis chassis_type='vmware'  
username='\' password=''  
protocol='https+unverified' hostname=  
prefix_filter= domain=


Without the https+unverified i couldnt get it to work adding a chassis  
because in the GUI the protocol field is missing.


BR

Christian
  


Quoting "Serge E. Hallyn" :


Hi,

I've inherited a few vsphere machines where I was hoping to use juju
to fire off openstack etc.  I've been trying to use the vsphere
provider (which I was excited to see existed), but am seeing a few
inconsistencies, so had a few questions.

The first blunt question - is this going to be a maintained driver,
or am I in 6 months likely to find the vsphere driver dropped?

The second is motivating the first - when I looked at
https://jujucharms.com/docs/2.1/help-vmware it says hardware version
8 (ESX 5.0) should be sufficient.  But in fact juju has a ubuntu.ovf
hardcoded in it that specifies 'vmx-10', which is ESX 5.5..  I currently
have 5 ESX 5.1 machines and one 6.0.

Even with a custom DC using only the 6.0 host, I have some (probably
proxy) issues bootstrapping, which I'm sure are surmountable - but the
answer to Q1 will decide whether it's worth pursuing that further, or
whether I should spend my time elsewhere :)

thanks,
-serge

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


binoDYal2_104.bin
Description: PGP Public Key
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

vsphere support

2017-10-04 Thread Serge E. Hallyn 
Hi,

I've inherited a few vsphere machines where I was hoping to use juju
to fire off openstack etc.  I've been trying to use the vsphere
provider (which I was excited to see existed), but am seeing a few
inconsistencies, so had a few questions.

The first blunt question - is this going to be a maintained driver,
or am I in 6 months likely to find the vsphere driver dropped?

The second is motivating the first - when I looked at
https://jujucharms.com/docs/2.1/help-vmware it says hardware version
8 (ESX 5.0) should be sufficient.  But in fact juju has a ubuntu.ovf
hardcoded in it that specifies 'vmx-10', which is ESX 5.5..  I currently
have 5 ESX 5.1 machines and one 6.0.

Even with a custom DC using only the 6.0 host, I have some (probably
proxy) issues bootstrapping, which I'm sure are surmountable - but the
answer to Q1 will decide whether it's worth pursuing that further, or
whether I should spend my time elsewhere :)

thanks,
-serge

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

Re: set_state not setting the state immediately

2017-10-04 Thread Mike Wilson 
These sound like good steps to me. I would just encourage us to look at the
worst examples of charms people have written or questions that are common
and attempt to defend against that sort of thing. People invent things out
of perceived necessity and if we can find those and provide solutions I
think we'll have a better product in the end.

On Wed, Oct 4, 2017 at 9:00 AM Marco Ceppi 
wrote:

> So, I've not actually checked the logs in a while, but if visibility is an
> issue, it seems reasonable that the reactive framework should print in the
> log that X flags are being reset due to hook failure. Things like
> set_flag_immediate has farther reaching consequences than simply stating
> that flags only get set on success of a hook run.
>
> I know there are further reaching initiatives to alleviate this by
> decoupling the reactive state engine from the juju hooks system. In this
> case each successive loop of the reactive runtime could better snapshot
> state and make failures more granular.
>
> * state is being renamed to flag in the next major version of reactive.
>
> On Wed, Oct 4, 2017 at 8:52 AM Mike Wilson 
> wrote:
>
>> So as a new charm writer coming to Juju I would first do this:
>>
>> def get_ready():
>> func0()
>> func1_fails()
>>
>> Then I would, hopefully, test and notice issues. I would investigate and
>> see that I needed to be idempotent. My next attempt would be to wrap those
>> functions inside state checks with sets after they complete. This would
>> also fail and now the charm creator is left with nothing in the api that
>> can help. They are now off to their own devices to start doing random
>> things to attempt to make this work the way they want it to work.
>> Hopefully, the solution is as straight-forward as touching random files,
>> but we just never know.
>>
>> I would expect the name of set_state to be something like
>> set_state_on_success and I would further expect some sort of immediate
>> state thing like set_state or set_state_immediate. This would give the user
>> the tools we know that they need in order to create bug-free charms.
>>
>> Now to compound that confusion, we have the issue of a hook can call
>> multiple functions inside the charm code and if any of those functions have
>> something that fails the whole thing is unwrapped. I understand from a Juju
>> perspective why this is the case, but as a user, I would be completely
>> taken by surprise here. The only real fix here is documentation so that we
>> can set expectations, but people will most likely look at examples instead
>> of documentation. This means that we need to make sure to call out any
>> potential issues like this in the example charms we release.
>>
>>
>> On Wed, Oct 4, 2017 at 6:34 AM Stuart Bishop 
>> wrote:
>>
>>> On 4 October 2017 at 00:51, Mike Wilson 
>>> wrote:
>>> > So the best practice here is to touch a file and test for the
>>> existence of
>>> > that file before running must_be_called_exactly_once()?
>>> >
>>> > I think part of the issue here is that without knowing the extent of
>>> the
>>> > hook it is hard to enforce idempotency as a charm writer. It's easy to
>>> look
>>> > at the code above and say that is it idempotent since the init
>>> function is
>>> > wrapped in a when_not and the initialized state is set at the bottom of
>>> > init.
>>>
>>> Individual handlers should be idempotent, so it doesn't matter about
>>> the extent of the hook, or even if the chained handlers being triggers
>>> are running in the same hook. Assume your handlers get called multiple
>>> times, because they may be. Yes, it looks idempotent but it isn't. An
>>> assumption is being made that the state changes get committed
>>> immediately, but these changes are actually transactional and
>>> following the same transactional behaviour as the Juju hook
>>> environment [1]. I think this can certainly be explained better in the
>>> docs, but I can't think of a way to stop this being an easy error to
>>> make.
>>>
>>> [1] spot the DBA
>>>
>>> --
>>> Stuart Bishop 
>>>
>> --
>
>
>> 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: set_state not setting the state immediately

2017-10-04 Thread Marco Ceppi 
So, I've not actually checked the logs in a while, but if visibility is an
issue, it seems reasonable that the reactive framework should print in the
log that X flags are being reset due to hook failure. Things like
set_flag_immediate has farther reaching consequences than simply stating
that flags only get set on success of a hook run.

I know there are further reaching initiatives to alleviate this by
decoupling the reactive state engine from the juju hooks system. In this
case each successive loop of the reactive runtime could better snapshot
state and make failures more granular.

* state is being renamed to flag in the next major version of reactive.

On Wed, Oct 4, 2017 at 8:52 AM Mike Wilson 
wrote:

> So as a new charm writer coming to Juju I would first do this:
>
> def get_ready():
> func0()
> func1_fails()
>
> Then I would, hopefully, test and notice issues. I would investigate and
> see that I needed to be idempotent. My next attempt would be to wrap those
> functions inside state checks with sets after they complete. This would
> also fail and now the charm creator is left with nothing in the api that
> can help. They are now off to their own devices to start doing random
> things to attempt to make this work the way they want it to work.
> Hopefully, the solution is as straight-forward as touching random files,
> but we just never know.
>
> I would expect the name of set_state to be something like
> set_state_on_success and I would further expect some sort of immediate
> state thing like set_state or set_state_immediate. This would give the user
> the tools we know that they need in order to create bug-free charms.
>
> Now to compound that confusion, we have the issue of a hook can call
> multiple functions inside the charm code and if any of those functions have
> something that fails the whole thing is unwrapped. I understand from a Juju
> perspective why this is the case, but as a user, I would be completely
> taken by surprise here. The only real fix here is documentation so that we
> can set expectations, but people will most likely look at examples instead
> of documentation. This means that we need to make sure to call out any
> potential issues like this in the example charms we release.
>
>
> On Wed, Oct 4, 2017 at 6:34 AM Stuart Bishop 
> wrote:
>
>> On 4 October 2017 at 00:51, Mike Wilson 
>> wrote:
>> > So the best practice here is to touch a file and test for the existence
>> of
>> > that file before running must_be_called_exactly_once()?
>> >
>> > I think part of the issue here is that without knowing the extent of the
>> > hook it is hard to enforce idempotency as a charm writer. It's easy to
>> look
>> > at the code above and say that is it idempotent since the init function
>> is
>> > wrapped in a when_not and the initialized state is set at the bottom of
>> > init.
>>
>> Individual handlers should be idempotent, so it doesn't matter about
>> the extent of the hook, or even if the chained handlers being triggers
>> are running in the same hook. Assume your handlers get called multiple
>> times, because they may be. Yes, it looks idempotent but it isn't. An
>> assumption is being made that the state changes get committed
>> immediately, but these changes are actually transactional and
>> following the same transactional behaviour as the Juju hook
>> environment [1]. I think this can certainly be explained better in the
>> docs, but I can't think of a way to stop this being an easy error to
>> make.
>>
>> [1] spot the DBA
>>
>> --
>> Stuart Bishop 
>>
> --
> 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: set_state not setting the state immediately

2017-10-04 Thread Mike Wilson 
So as a new charm writer coming to Juju I would first do this:

def get_ready():
func0()
func1_fails()

Then I would, hopefully, test and notice issues. I would investigate and
see that I needed to be idempotent. My next attempt would be to wrap those
functions inside state checks with sets after they complete. This would
also fail and now the charm creator is left with nothing in the api that
can help. They are now off to their own devices to start doing random
things to attempt to make this work the way they want it to work.
Hopefully, the solution is as straight-forward as touching random files,
but we just never know.

I would expect the name of set_state to be something like
set_state_on_success and I would further expect some sort of immediate
state thing like set_state or set_state_immediate. This would give the user
the tools we know that they need in order to create bug-free charms.

Now to compound that confusion, we have the issue of a hook can call
multiple functions inside the charm code and if any of those functions have
something that fails the whole thing is unwrapped. I understand from a Juju
perspective why this is the case, but as a user, I would be completely
taken by surprise here. The only real fix here is documentation so that we
can set expectations, but people will most likely look at examples instead
of documentation. This means that we need to make sure to call out any
potential issues like this in the example charms we release.


On Wed, Oct 4, 2017 at 6:34 AM Stuart Bishop 
wrote:

> On 4 October 2017 at 00:51, Mike Wilson  wrote:
> > So the best practice here is to touch a file and test for the existence
> of
> > that file before running must_be_called_exactly_once()?
> >
> > I think part of the issue here is that without knowing the extent of the
> > hook it is hard to enforce idempotency as a charm writer. It's easy to
> look
> > at the code above and say that is it idempotent since the init function
> is
> > wrapped in a when_not and the initialized state is set at the bottom of
> > init.
>
> Individual handlers should be idempotent, so it doesn't matter about
> the extent of the hook, or even if the chained handlers being triggers
> are running in the same hook. Assume your handlers get called multiple
> times, because they may be. Yes, it looks idempotent but it isn't. An
> assumption is being made that the state changes get committed
> immediately, but these changes are actually transactional and
> following the same transactional behaviour as the Juju hook
> environment [1]. I think this can certainly be explained better in the
> docs, but I can't think of a way to stop this being an easy error to
> make.
>
> [1] spot the DBA
>
> --
> Stuart Bishop 
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Private Icons for a charm.

2017-10-04 Thread Michael Van Der Beek 
Hi All,

I've created custom icons.svg for charms but in the juju gui it doesn't show up.
The url for the icon when I inspect the webpage looks like this.
https://user-admin@local:password@10.60.1.20:17070/model/f7872e93-5cbf-46dd-814b-2c63031686cd/charms?url=local:centos7/radius-27=1

If use this url in a browser it works it brings up the icon. But in the juju 
webgui it shows up a generic icon.
Is there a fix for this?

I am currently starting the charm like this
juju  deploy /home/ubuntu/charms/radius --constraints mem=4G

Regards,

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

Re: set_state not setting the state immediately

2017-10-04 Thread Stuart Bishop 
On 4 October 2017 at 00:51, Mike Wilson  wrote:
> So the best practice here is to touch a file and test for the existence of
> that file before running must_be_called_exactly_once()?
>
> I think part of the issue here is that without knowing the extent of the
> hook it is hard to enforce idempotency as a charm writer. It's easy to look
> at the code above and say that is it idempotent since the init function is
> wrapped in a when_not and the initialized state is set at the bottom of
> init.

Individual handlers should be idempotent, so it doesn't matter about
the extent of the hook, or even if the chained handlers being triggers
are running in the same hook. Assume your handlers get called multiple
times, because they may be. Yes, it looks idempotent but it isn't. An
assumption is being made that the state changes get committed
immediately, but these changes are actually transactional and
following the same transactional behaviour as the Juju hook
environment [1]. I think this can certainly be explained better in the
docs, but I can't think of a way to stop this being an easy error to
make.

[1] spot the DBA

-- 
Stuart Bishop 

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