Re: how to bind to the default space in a bundle

[Alberto Colla]

hi James,

try this:

mysql:
   ...
   bindings:
   "": default-space
   db: db-space
   db-admin: admin-space
   ...

I hope it helps,

cheers,

Alberto



Il 10/11/2017 07:01, James Beedy ha scritto:

Is it possible to accomplish the following using a bundle?

`juju deploy --bind "default-space db=db-space db-admin=admin-space" 
mysql`



thanks







--
 Alberto Colla
 
|GARR - The Italian Academic and Research Network|
|Via dei Tizii, 6 I-00185 Rome - Italy   |
|office: +39 06 4962 2301 mobile: +39 340 46 24 581  |
|Email: alberto.co...@garr.it http://www.garr.it |
 

-- 
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

[Konstantinos Tsakalozos]

Hi again,

This behaviour is not consistent between the python and bash reactive
implementation.

Seems the setting of states occurs at the end of each method
invocation in bash, and at the end of hook invocation in the python
implementation.

Even if it is not correct, the behaviour of the bash reactive is what
the naive ( :) ) developer expects. Can you give me a concrete example
of what can go wrong with the approach the bash reactive
implementation is taking? Stuart, you mention "changes made to the
Juju environment get rolled back on hook failure" could some of these
changes cause a bash reactive charm to misbehave, can you please give
me an example?

Thanks,
Konstantinos

On Tue, Oct 31, 2017 at 3:57 PM, Merlijn Sebrechts
 wrote:
>
> 2017-10-31 14:39 GMT+01:00 fengxia :
>
>> we have been using Ansible (called from charm) for executions.
>
>
> Would you recommend this approach to new users?
> Do you have examples of such Charms?
> Do you have docs detailing the ansible-Juju integration?
> What can we do to make this integration easier?
>
>
>>
>> But ppl fear things they don't understand. Config mgt tools are like
>> giving you a set of cooking utensils and a recipe book, you can follow the
>> book, or be an iron chef yourself, and surprisingly, many believe they have
>> that talent to be the iron chef, though over optimistically often ~~
>
>
> True! I think this one of the reasons why Juju is so successful for
> OpenStack. Normal config mgmt tools give you all the control, but it
> requires you to completely understand what the deployment scripts are doing.
> OpenStack is so complex that it's almost impossible to fully understand all
> components so few sysadmins have the knowledge required to deploy OpenStack
> with cfg mgmt tools..
>
>
>
>
>>
>>
>>
>>
>>
>>
>> On 10/30/2017 11:56 AM, Merlijn Sebrechts wrote:
>>
>> Hi all
>>
>>
>> Great discussion in this thread. I sense there are two issues here:
>>
>> 1. The transactional nature of charms.reactive and Juju needs to be
>> explained better. We can't change the transactional nature from the
>> charms.reactive side since this is a Juju core feature, but we can provide a
>> lot better docs and change function names to better match their actual
>> behavior. This is already discussed for relationships as part of the
>> Endpoint PR.
>> 2. Idempotency is hard, not commonly understood outside of config mgmt
>> community and charms.reactive isn't helping. Idempotency is a solved issue
>> in config mgmt tools. I don't think it's the job of Juju and charms.reactive
>> to provide ways to do this because we operate on a higher level (service
>> orchestration, not config mgmt). What we should to is make it easier to use
>> charms.reactive together with config mgmt tools like Puppet and Chef. This
>> will keep us from reinventing the wheel and will provide a number of
>> additional benefits (such as being able to leverage existing Puppet scripts
>> and quicker charms).
>>
>> Please create more issues if I've missed something, and add your comments
>> to the issues.
>>
>>
>>
>> Kind regards
>> Merlijn
>>
>> 2017-10-05 20:50 GMT+02:00 fengxia :
>>>
>>> " 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]."
>>>
>>> To chip in my experience as 6-month into learning charms and writing a
>>> few simple charms.
>>>
>>> 1. The "transactional" nature of Juju hook needs better explained. To be
>>> honest I have no idea what this means, and what implication it has to a
>>> charm writer. Any reference would be helpful.
>>>
>>> 2. I like Mike Wilson's approach to provide a list of "set_state_xxx"
>>> functions so new writer can better guess what this function will do.
>>> Further, a different name calls for further study why they are different,
>>> thus learning important concept of whatever Juju thinks charm writer needs
>>> to understand.
>>>
>>> Otherwise, I will expect "set_state" will set that state/flag asap. If
>>> there is a scanning cycle (which I heard there is some kind of 5-min cycle,
>>> which document has not sufficiently made it clear to a writer either), charm
>>> writer needs to have better doc to learn what it means for design. I came
>>> from embedded system world in which a timer loop is common. It calls for a
>>> different thinking than user space script user. I think such implication
>>> should be emphasized more.
>>>
>>> 3. idempotent
>>>
>>> Again, this is a concept me (or many new writer) will fail to grasp.
>>> Looking at "apt install" as example, my reaction was that the package
>>> manager is taking care of "doing nothing" if called multiple times. But how
>>> this translate to my system in which charm is expected to "do something"?
>>> Does it mean I need a gatekeeper like the package manager so to guard these
>>> "multiple calls"?
>>>
>>> Again, this feels like a work around because "set

Re: set_state not setting the state immediately

[Merlijn Sebrechts]

Afaik, `relation-set` and `open-port` gets "reset" by Juju if a hook fails.
This means that a bash charm might think it has opened a port and published
info on the relation based on the flags, but that hasn't actually happened.

Important to note here is that this only happens on a hook failure from
_Juju's standpoint_. You won't experience this if you're retrying a hook a
few times as part of a debug-hooks session, because that session is seen as
"one continuously running hook" from Juju's standpoint. Therefore, it
doesn't make sense for the reactive framework to reset everything in a
debug-hooks session, because Juju doesn't reset anything. As I said in the
bug report ,
a possible improvement is that `charms.reactive` somehow figures out if
it's in a `debug-hooks` session, and if so, doesn't reset flags. Thoughts?


PS: The structural issue is that Juju's "transactional" nature is
half-assed: all communication with outside gets reset, but the internal
state of the OS doesn't get reset. The ideal solution is that when Juju
resets, the actual OS gets reset too, removing the need for hooks to be
idempotent.. ZFS might be useful in achieving this, but I have no idea if
this is even on the roadmap for Juju..


PPS: It's correct that this behavior is not consistent between python and
non-python handlers, this is a bug.



2017-11-10 15:54 GMT+01:00 Konstantinos Tsakalozos <
kos.tsakalo...@canonical.com>:

> Hi again,
>
> This behaviour is not consistent between the python and bash reactive
> implementation.
>
> Seems the setting of states occurs at the end of each method
> invocation in bash, and at the end of hook invocation in the python
> implementation.
>
> Even if it is not correct, the behaviour of the bash reactive is what
> the naive ( :) ) developer expects. Can you give me a concrete example
> of what can go wrong with the approach the bash reactive
> implementation is taking? Stuart, you mention "changes made to the
> Juju environment get rolled back on hook failure" could some of these
> changes cause a bash reactive charm to misbehave, can you please give
> me an example?
>
> Thanks,
> Konstantinos
>
> On Tue, Oct 31, 2017 at 3:57 PM, Merlijn Sebrechts
>  wrote:
> >
> > 2017-10-31 14:39 GMT+01:00 fengxia :
> >
> >> we have been using Ansible (called from charm) for executions.
> >
> >
> > Would you recommend this approach to new users?
> > Do you have examples of such Charms?
> > Do you have docs detailing the ansible-Juju integration?
> > What can we do to make this integration easier?
> >
> >
> >>
> >> But ppl fear things they don't understand. Config mgt tools are like
> >> giving you a set of cooking utensils and a recipe book, you can follow
> the
> >> book, or be an iron chef yourself, and surprisingly, many believe they
> have
> >> that talent to be the iron chef, though over optimistically often ~~
> >
> >
> > True! I think this one of the reasons why Juju is so successful for
> > OpenStack. Normal config mgmt tools give you all the control, but it
> > requires you to completely understand what the deployment scripts are
> doing.
> > OpenStack is so complex that it's almost impossible to fully understand
> all
> > components so few sysadmins have the knowledge required to deploy
> OpenStack
> > with cfg mgmt tools..
> >
> >
> >
> >
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 10/30/2017 11:56 AM, Merlijn Sebrechts wrote:
> >>
> >> Hi all
> >>
> >>
> >> Great discussion in this thread. I sense there are two issues here:
> >>
> >> 1. The transactional nature of charms.reactive and Juju needs to be
> >> explained better. We can't change the transactional nature from the
> >> charms.reactive side since this is a Juju core feature, but we can
> provide a
> >> lot better docs and change function names to better match their actual
> >> behavior. This is already discussed for relationships as part of the
> >> Endpoint PR.
> >> 2. Idempotency is hard, not commonly understood outside of config mgmt
> >> community and charms.reactive isn't helping. Idempotency is a solved
> issue
> >> in config mgmt tools. I don't think it's the job of Juju and
> charms.reactive
> >> to provide ways to do this because we operate on a higher level (service
> >> orchestration, not config mgmt). What we should to is make it easier to
> use
> >> charms.reactive together with config mgmt tools like Puppet and Chef.
> This
> >> will keep us from reinventing the wheel and will provide a number of
> >> additional benefits (such as being able to leverage existing Puppet
> scripts
> >> and quicker charms).
> >>
> >> Please create more issues if I've missed something, and add your
> comments
> >> to the issues.
> >>
> >>
> >>
> >> Kind regards
> >> Merlijn
> >>
> >> 2017-10-05 20:50 GMT+02:00 fengxia :
> >>>
> >>> " An assumption is being made that the state changes get committed
> >>> immediately, but these changes are actually transactional and
> >>> following the same tr

Re: set_state not setting the state immediately

[Stuart Bishop]

On 10 November 2017 at 21:54, Konstantinos Tsakalozos
 wrote:

> Even if it is not correct, the behaviour of the bash reactive is what
> the naive ( :) ) developer expects. Can you give me a concrete example
> of what can go wrong with the approach the bash reactive
> implementation is taking? Stuart, you mention "changes made to the
> Juju environment get rolled back on hook failure" could some of these
> changes cause a bash reactive charm to misbehave, can you please give
> me an example?

Here is a trivial handler that informs the unit's peers that it is
available. If the hook fails, but the state persists, the peers are
never informed. Some information has persisted (the charms.reactive
state), and other information has been thrown away (the Juju
environment state).

@when('mycharm.configured')
@when_not('mycharm.joined')
def join():
for relid in relation_ids('cluster'):
relation_set(relid, active='true')
set_state('mycharm.joined')

Here is a common one you may have written yourself, where the
configured port  might never be opened:

@when('config.changed.port')
def open_port():
 prev_port = unitdata.kv().get('mycharm.port')
 new_port = config()['port']
 if prev_port is not None:
 close_port(prev_port)
 open_port(new_port)
 unitdata.kv().set('mycharm.port', new_port)

-- 
Stuart Bishop 

-- 
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

[Konstantinos Tsakalozos]

Thank you both. It is clear now.

On Fri, Nov 10, 2017 at 6:14 PM, Stuart Bishop
 wrote:
> On 10 November 2017 at 21:54, Konstantinos Tsakalozos
>  wrote:
>
>> Even if it is not correct, the behaviour of the bash reactive is what
>> the naive ( :) ) developer expects. Can you give me a concrete example
>> of what can go wrong with the approach the bash reactive
>> implementation is taking? Stuart, you mention "changes made to the
>> Juju environment get rolled back on hook failure" could some of these
>> changes cause a bash reactive charm to misbehave, can you please give
>> me an example?
>
> Here is a trivial handler that informs the unit's peers that it is
> available. If the hook fails, but the state persists, the peers are
> never informed. Some information has persisted (the charms.reactive
> state), and other information has been thrown away (the Juju
> environment state).
>
> @when('mycharm.configured')
> @when_not('mycharm.joined')
> def join():
> for relid in relation_ids('cluster'):
> relation_set(relid, active='true')
> set_state('mycharm.joined')
>
> Here is a common one you may have written yourself, where the
> configured port  might never be opened:
>
> @when('config.changed.port')
> def open_port():
>  prev_port = unitdata.kv().get('mycharm.port')
>  new_port = config()['port']
>  if prev_port is not None:
>  close_port(prev_port)
>  open_port(new_port)
>  unitdata.kv().set('mycharm.port', new_port)
>
> --
> Stuart Bishop 

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