Re: Can u supply an environment that joid had been deployed well

[Cory Johns]

Yuanyou,

If I'm understanding your question, you want to access a Juju environment
that another person bootstrapped and deployed?  You can get access to the
environment by being provided a copy of the .jenv file created when the
environment was bootstrapped.  See
https://askubuntu.com/questions/365807/whats-the-correct-way-to-share-a-juju-environment
for more information.

Note that the .jenv file will enable full control of the environment via
the Juju API (though not ssh access, as mentioned in the above link), and
it may contain cloud access credentials, so care should be taken when
sharing that file.

The next release of Juju will have a more formal system for sharing
environments, information about which can be found at
https://jujucharms.com/docs/devel/wip-systems  This can be enabled in the
current version of Juju as an experimental feature, but I believe that must
be done before the system is bootstrapped, and no assurances are made that
it will work without issue.


On Mon, Dec 21, 2015 at 2:25 AM, zhangyuanyou 
wrote:

> Hi Narinder Gupta, Artur Tyloch,
>
>I’m working on joid with the integration of onos.
>
> And I want to know can u supply an environment that joid had been deployed
> well to me?
>
> Then I can connect to the environment to do the work of integration so
> that I can avoid
>
> many install error or network-config problem.
>
>
>
> Thanks and Best wishes,
>
> Yuanyou
>
>
>
>
>
> --
> 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: Hook -relation-broken is broken with charms.reactive

[Cory Johns]

Thank you for that explanation.  I was completely misunderstanding the
-broken hook, thinking it would run for each unit like -departed and just
indicated that the unit was finally gone.  I didn't realize that it didn't
fire until there were no remaining units and the relation was torn down in
its entirety.

I think that you're right that we should do some automatic cleanup, because
if the charm author forgets to do so, it can lead to subtle and confusing
bugs.  I know, because I ran up against that already.  :)

On Sat, Dec 19, 2015 at 5:31 PM, Stuart Bishop 
wrote:

> On 20 December 2015 at 02:13, Cory Johns  wrote:
> > On Sat, Dec 19, 2015 at 3:45 AM, Stuart Bishop <
> stuart.bis...@canonical.com>
> > wrote:
> >>
> >> Which unit name would you use? -relation-departed gets run multiple
> >> times, once for each unit. -relation-broken gets run once, after all
> >> the -departed hooks have been run.
> >
> >
> > That can't be right.  Surely it must run at least once on each unit still
> > remaining in the relation.  Every relation consists of two end-points,
> and
>
> A relation consists of several end-points. A relation is between two
> services, which means it is between several units (several on the
> 'local' side, and several on the 'remote' side). It is not a
> conversation between two units, where two units are passing messages
> between each other, but a conference involving several units, where
> each unit is yelling at every other unit. I find the
> relations-are-conversations metaphor breaks down as soon as you have
> two or more units to a service.
>
> From the Juju docs:
>
> ""
> [name]-relation-broken indicates that the current relation is no
> longer valid, and that the charm's software must be configured as
> though the relation had never existed. It will only be called after
> every necessary -departed hook has been run; if it's being executed,
> you can be sure that no remote units are currently known locally. It
> is important to note that the -broken hook might run even if no other
> units have ever joined the relation. This is not a bug: even if no
> remote units have ever joined, the fact of the unit's participation
> can be detected in other hooks via the relation-ids tool, and the
> -broken hook needs to execute to give the charm an opportunity to
> clean up any optimistically-generated configuration.
> """
>
> A unit appears in the relation. For every unit in the remote service,
> the relation-joined and relation-changed hooks are triggered. If a new
> unit is added to the remote service, the relation-joined and
> relation-changed hooks are triggered. If a unit in the remote service
> departs, the relation-departed hook is triggered. If the relation is
> destroyed, the relation-departed hook is triggered once for each unit
> in the remote service and the relation-broken hook triggered a single
> time, after all the relation-departed hooks have been triggered.
>
>
> > even if the implementation of Juju means that it's difficult or
> impossible
> > for the agent to populate that variable, there's still an objectively
> > correct value to put there.  And it doesn't seem unreasonable to have
> > expected Juju to do so, like it does for every relation hook.
>
> > Also, as I referenced previously, I'm pretty sure that I could
> reconstruct
> > the expected value by saving the list of departing unit(s) in the charm
> and
> > comparing that to the list during the -broken hook.  But my point was
> that
>
> I don't think there is a correct value to put there. In the -broken
> hook, the there will be zero units in the remote service. At this
> point, there is no longer a remote service at all. The only thing you
> would be doing is setting $REMOTE_UNIT to the last unit to depart,
> which is arbitrary.
>
>
> > I'm not sure it's worth doing that because I'm not sure I see a use-case
> for
> > this hook that couldn't just as easily be done with the -departed hook
> > alone.
>
> relation-departed is when a remote *unit* has gone.
> relation-broken is when the remote *service* has gone (or never
> appeared in the first place)
>
> In theory, you can use it to clean up resources required by the remote
> service. For example, you could shut down daemons no longer required
> or destroy the database used by the remote service. In theory, you
> don't do this from the relation-departed hook, because the remote
> service still exists (even if it has no units) and new units could be
> added.
>
> In practice, I don't think I've ever seen this done and suspect
> relation-broken hooks are unnecessary atavisms like 'start' and 'stop'
> hooks. In particular, cleaning up for $SERVICE in relation-broken is
> tricky as Juju does not tell us what $SERVICE actually was - I think
> all you know is the former relation id and relation name.
>
>
>
> >> As far as the reactive framework is concerned, I don't think it fits
> >> as a handler on a RelationBase subclass. 

can’t visit the vm from the brower

[zhangyuanyou]

Hi Narinder Gupta,
Now I have excute ./deploy.sh –s odl  successfully.
But when I create the vm ,I still can’t visit the vm from the brower.
And I can’t connect the node-compute use “juju ssh 2”,but can ping compute.
So I created a jira in the joid and upload the all-machine.log,
  https://jira.opnfv.org/browse/JOID-37


thanks and best wishes
yuanyou



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