Re: juju bug (?) when allocating floating ips to machines
Dear Heather here you are: https://bugs.launchpad.net/juju/+bug/1707248 The external network check is not enough because, as said, the same network ip range may be allocated in other tenants. Regards Patrizio 2017-07-27 19:43 GMT+02:00 Heather Lanigan : > Hi Patrizio, > > Judging by the code in develop, we do not check the tenant_id when > choosing a FIP. There is an attempt to ensure the FIP is in the provided > external network, if specified. So that may be another work around. > > Please file a bug. I'm wondering if there are more places the provider > should be checking the tenant as well. > > -Heather > > > > On Thu, Jul 27, 2017 at 9:04 AM, Patrizio Bassi > wrote: > >> Hi all >> >> i'm using juju 2.1.2.1 (i didn't upgrade to 2.2 yet, that's why i didn't >> open a bug on launchpad) with openstack as cloud provider. >> >> When i use as credentials an Admin user (but a specific tenant) i have >> issues with floating ip assignment: the admin user can see all the floating >> ips in the openstack region. >> So, if another tenant allocates an IP without assigning to a VM (so, >> unused) juju tries to use it and attach to the VM it just deployed. >> >> i.e. >> >> user test1 is Admin and has primary project "tenant-one" >> user test2 is member of project "tenant-two" >> >> credentials given to juju are test1, test1_password, tenant-one and >> RegionOne. >> >> # source novarc_test1 >> >> # neutron floatingip-list >> +--+--+- >> +--+ >> | id | fixed_ip_address | >> floating_ip_address | port_id | >> +--+--+- >> +--+ >> | 03d1a8e8-fd55-4d6e-ab7e-b62061ea6206 | 192.168.0.10 | 10.1.2.19 >> | b6ac7caf-0c6e-4d81-b055-ecb8b4bdeebd | >> | 2b4e48ba-aad6-4d78-aff6-88b912f89bf5 | 192.168.0.20 | 10.1.2.9 >> | 17f69b3b-97d0-4cec-8208-e4d2ac2f1034 | >> | 3144b683-2cf5-43cf-bddd-b06cb5662430 | | 10.1.2.22 >> | | >> | 55145d85-58ea-4f15-8a0c-96a719c0fa8d | 192.168.0.22 | 10.1.2.4 >> | 6eeaa12b-0971-496c-bd38-89e9b9d71818 | >> +--+--+- >> +--+ >> >> the third line shows and ip address assigned to tenant-two by test2. >> >> User test1 has admin role so he has permission to see the ip. >> Using a command like "neutron floatingip-show >> 3144b683-2cf5-43cf-bddd-b06cb5662430" correctly shows the project_id >> uuid related to tenant-two and not tenant-one. >> >> juju model is configured with >> use-default-secgroup model true >> use-floating-ip model true >> >> When trying to deploy any application juju spawns a VM, but it never ends >> and logs: >> >> Unable to associate floating IP 10.1.2.22 to fixed IP 192.168.0.9 for >> instance 3d95283c-69f2-4cf1-8980-99462a5904a2. >> >> Removing the unused floating ip address or using a member-only (not admin >> user) bypass the problem: juju will allocate a new ip and associate with >> the new VM. >> >> I didn't try but i do think that if an user is member of two different >> tenants it may try to mis-use the addresses and mess with them, failing to >> deploy. >> >> Desiderata: juju should check if the allocated ip address is in the same >> tenant view of the given credentials. >> >> Regards >> >> Patrizio >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju >> >> > -- Patrizio Bassi www.patriziobassi.it http://piazzadelpopolo.patriziobassi.it -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Application of Membership for Charmers
Yuge +1! On 21/07/17 13:41, Billy Olsen wrote: Hello Charmers, My name is Billy Olsen and I've been a long time contributor to the OpenStack Charms, going back 3 years now. I'm currently a core member of the OpenStack charming community and have additionally made contributions of code and review effort to the charm-helpers library. I believe that I can provide a positive contribution in the overall charming ecosystem. Thanks, Billy -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
How do upgrades handle resources?
Hi all I'm not sure how resources and upgrades work together. I see that the kubernetes layers use resources, but you upgrade kubernetes using `juju upgrade-charm`. How does that work? Does each charm version have a "default resource" attached? The resources docs don't really explain this either.. https://jujucharms.com/docs/2.1/developer-resources Kind regards Merlijn -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Is a set state called multiple times?
Very helpful indeed! Thank you for the insight Alex.
The concern of "doing too much" is exactly what started conversation
when we are expecrimenting with charm, because in our design we are
using charm as a state-driven framework that interacts with external
resources. So it's the sanity of these external resources we want to guard.
On 07/28/2017 05:37 AM, Alex Kavanagh wrote:
Hi fengxia
As Cory says, it's much better to think of the set_state() and
remove_state() as binary flags; in fact in the upcoming version,
set_state becomes set_flag() and remove_state() becomes remove_flag()
-- although the existing functions will still exist for backwards
compatibility.
So a handler with a set of conditions built from flags (states) that
evaluates to 'true' will always run on EVERY invocation of the charm;
that's all of the charm hooks, plus relation hooks.
This can often lead to a charm 'doing too much' during a hook
invocation if you don't gate or otherwise detect that a charm doesn't
need to do something. I've had 'bugs' in the past where databases
were set up multiple times because I didn't gate (by using a
flag/state) the 'have I set up the database yet'. Just something to
watch for.
Also, the update-status hook is a bit redundant now. To get
equivalent functionality without having to use a
@hook('update-status') just use a @when_not("never-set-update-status")
and it will always run on every hook invocation; it also means you can
gate the 'update status' if certain other things haven't happened.
And yes, in your example, you can use flags to 'make progress' in the
charm life-cycle by using them to only run a bit of functionality
once. You can always do them in cycles too!
Finally, remember that states are NOT shared amongst units of the same
application; they are unique to each individual unit. Juju is not
aware that the charm is using reactive states.
Hope this helps
Cheers
Alex.
On Thu, Jul 27, 2017 at 9:09 PM, fengxia > wrote:
Now thinking of it, I just realized that this concept of True
state executing repeatedly is actually a good thing.
In many cases, there is a need to query external resource for its
status. This is often implemented as a polling loop. So in charm,
I can implement it as
@when("prep")
def prep():
# are we there yet?
is_ready = prep_test()
if is_ready:
remove_state("prep")
set_state("do.sth")
@when("do.sth")
def do_sth():
# do this
pass
# move on
remove_state("do.sth")
set_state("next")
On 07/27/2017 03:56 PM, Cory Johns wrote:
fengxia,
It's probably more enlightening to think of them as "flags"
rather than states. (Indeed, the next release of charms.reactive
will deprecate calling them states and will provide set_flag,
remove_flag, etc. functions instead.)
On Thu, Jul 27, 2017 at 3:29 PM, fengxia mailto:fx...@lenovo.com>> wrote:
Alex,
Thank you for the detailed explanations and examples.
After reading Tilman's and Cory's replies, I think the
confusion is at continuous evaluation (thus execution) of a
True state. So a pair of @when and @when_not will result in
one of them being executed over and over despite adding a
remove_state("myself") in the @when block.
I'm still trying to grasp the idea of this "state" instead of
treating it as an event handler.
So for states, I usually draw a state machine diagram. In
this case, it feels rather unnatural that all True states
will inherently loop to themselves.
But I don't what alternative is in charm's context.
On 07/27/2017 04:13 AM, Alex Kavanagh wrote:
Hi
On Thu, Jul 27, 2017 at 2:37 AM, fengxia mailto:fx...@lenovo.com>> wrote:
Hi Juju,
Once I set a state, set_state("here"), I want to make
sure its @when will only be executed ONCE (when "here"
from False->True).
So my thought is to remove_state("here") in its
@when("here") code block. If I don't, will this @when be
called multiple times if I don't reset this state?
What's the good practice here?
You have a couple of options here depending on the nature of
the handler.
1. If, in the lifetime of the unit's existence, the handler
only has to execute ONCE. (and I mean EVER), then there
is a @only_once decorator that can be used. It can be
used in combination with other decorators to set up a
condition, but it guarantees that the handler will only
be called once. However, what you probably want is ...
2. Use a @when_not('flag') and then set it the 'flag' in
the body of the handler.
The first would lo
Re: Is a set state called multiple times?
Hi fengxia
As Cory says, it's much better to think of the set_state() and
remove_state() as binary flags; in fact in the upcoming version, set_state
becomes set_flag() and remove_state() becomes remove_flag() -- although
the existing functions will still exist for backwards compatibility.
So a handler with a set of conditions built from flags (states) that
evaluates to 'true' will always run on EVERY invocation of the charm;
that's all of the charm hooks, plus relation hooks.
This can often lead to a charm 'doing too much' during a hook invocation if
you don't gate or otherwise detect that a charm doesn't need to do
something. I've had 'bugs' in the past where databases were set up
multiple times because I didn't gate (by using a flag/state) the 'have I
set up the database yet'. Just something to watch for.
Also, the update-status hook is a bit redundant now. To get equivalent
functionality without having to use a @hook('update-status') just use a
@when_not("never-set-update-status") and it will always run on every hook
invocation; it also means you can gate the 'update status' if certain other
things haven't happened.
And yes, in your example, you can use flags to 'make progress' in the charm
life-cycle by using them to only run a bit of functionality once. You can
always do them in cycles too!
Finally, remember that states are NOT shared amongst units of the same
application; they are unique to each individual unit. Juju is not aware
that the charm is using reactive states.
Hope this helps
Cheers
Alex.
On Thu, Jul 27, 2017 at 9:09 PM, fengxia wrote:
> Now thinking of it, I just realized that this concept of True state
> executing repeatedly is actually a good thing.
>
>
> In many cases, there is a need to query external resource for its status.
> This is often implemented as a polling loop. So in charm, I can implement
> it as
>
>
> @when("prep")
>
> def prep():
>
> # are we there yet?
>
> is_ready = prep_test()
>
> if is_ready:
>
> remove_state("prep")
>
> set_state("do.sth")
>
> @when("do.sth")
>
> def do_sth():
>
> # do this
>
> pass
>
>
> # move on
>
> remove_state("do.sth")
>
> set_state("next")
>
> On 07/27/2017 03:56 PM, Cory Johns wrote:
>
> fengxia,
>
> It's probably more enlightening to think of them as "flags" rather than
> states. (Indeed, the next release of charms.reactive will deprecate
> calling them states and will provide set_flag, remove_flag, etc. functions
> instead.)
>
> On Thu, Jul 27, 2017 at 3:29 PM, fengxia wrote:
>
>> Alex,
>>
>> Thank you for the detailed explanations and examples.
>>
>> After reading Tilman's and Cory's replies, I think the confusion is at
>> continuous evaluation (thus execution) of a True state. So a pair of @when
>> and @when_not will result in one of them being executed over and over
>> despite adding a remove_state("myself") in the @when block.
>>
>> I'm still trying to grasp the idea of this "state" instead of treating it
>> as an event handler.
>>
>> So for states, I usually draw a state machine diagram. In this case, it
>> feels rather unnatural that all True states will inherently loop to
>> themselves.
>>
>> But I don't what alternative is in charm's context.
>>
>> On 07/27/2017 04:13 AM, Alex Kavanagh wrote:
>>
>> Hi
>>
>> On Thu, Jul 27, 2017 at 2:37 AM, fengxia wrote:
>>
>>> Hi Juju,
>>>
>>> Once I set a state, set_state("here"), I want to make sure its @when
>>> will only be executed ONCE (when "here" from False->True).
>>>
>>> So my thought is to remove_state("here") in its @when("here") code
>>> block. If I don't, will this @when be called multiple times if I don't
>>> reset this state? What's the good practice here?
>>
>>
>> You have a couple of options here depending on the nature of the handler.
>>
>>
>>1. If, in the lifetime of the unit's existence, the handler only has
>>to execute ONCE. (and I mean EVER), then there is a @only_once decorator
>>that can be used. It can be used in combination with other decorators to
>>set up a condition, but it guarantees that the handler will only be called
>>once. However, what you probably want is ...
>>2. Use a @when_not('flag') and then set it the 'flag' in the body of
>>the handler.
>>
>> The first would look something like:
>>
>> @when('some-condition-flag')
>> @only_once
>> def do_something_only_once_when_some_condition_flag_is_set_for_
>> the_first_time():
>> ... do something once ...
>>
>> The second treats a flag as a 'have I done this yet' condition, and
>> allows you to reset the flag at some other point in the charm's life cycle
>> so that you can do it again. 'installed' is a good example of this:
>>
>> @when_not('installed-something')
>> def do_install_of_something():
>> ... do the installation ...
>> # when it is fully successful, set the installed-something flag.
>> Don't set it early as
>> # if it errors, a future handler invocation may be able to continue
>> the installa
