Re: gocharm help

[roger peppe]

On 23 April 2015 at 16:01, Vasiliy Tolstov  wrote:
> 2015-04-23 11:00 GMT+03:00 roger peppe :
>> Nice start!
>>
>> As far as I can see the issue is just that there's
>> a variant syntax of a relation that's allowed in the metadata
>> (I replied in the issue itself).
>>
>> I had a brief look at your hooks.go file. I'd suggest that
>> it's probably better to register the hooks individually,
>> rather than using the switch (that way gocharm does the
>> work).
>>
>> As it happens, the gocharm hook logic emits a log message
>> anyway when a hook starts and finishes, but if you
>> *do* want to wrap other generic logic around hooks, it's
>> probably better to use a "decorator" style than to
>> introduce the switch.
>>
>> e.g.
>>
>> func (n *mysql) registerHook(r *hook.Registry, name string, h
>> func() error) {
>>   r.RegisterHook(name, func() error {
>> n.ctxt.Logf("running %s", name)
>> return h()
>>   })
>>  }
>>
>>  ...
>>  n.registerHook(r, "install", n.install)
>>
>> Here's a paste of the code with a few suggested changes made:
>>
>> http://paste.ubuntu.com/10870074/
>>
>> Please let me know if you have any more issues (or, even better, if
>> it all just works ok for you :-] )
>
>
> Thanks for suggestions, i'm try to write simple wordpress charm and
> check relations =)
> Last question - what benefits of using simplerelation package or
> writing own relations packages?

simplerelation is intended as a base for writing any relation
that has a simple "providers sets attributes, requirers see
them" convention.

So if the relation you want to write fits that convention, simplerelation
is probably the thing to use (if you look in the charmbits directory,
you'll see that some of the other relations already layer on top of it)

simplerelation is not really intended for using directly in a charm - the
idea is that if you want to implement a relation interface, you'll
make a package containing Provider and Requirer types and use
simplerelation to implement them if appropriate.

> Also, why in case of registered relation gocharm does not create
> symlinks for this relation?

I don't understand this question. Are you saying that you include
a relation-implementor in your type and call Register on it
but that hooks are not generated? (FWIW gocharm never makes
symlinks - it makes stub shell scripts instead)

Perhaps you could provide an example that doesn't work for you
and say what you expect it to do?

Ah! After looking at your code, I think I might know what your
question means. Do you mean "If I call RegisterRelation, why
does gocharm not generate relation hooks for that relation?".
If so, the answer is that gocharm only generates a hook stub when
you've called RegisterHook for that hook (it can't know
*which* hooks you want to be called. RegisterRelation just
registers the relation; it doesn't say that you're interested in hook
invocations
for that relation. See charmbits/httprelation for an example
of how to implement a relation.

  cheers,
rog.

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

Re: gocharm help

[Vasiliy Tolstov]

2015-04-23 18:01 GMT+03:00 Vasiliy Tolstov :
> Thanks for suggestions, i'm try to write simple wordpress charm and
> check relations =)
> Last question - what benefits of using simplerelation package or
> writing own relations packages?


Also, why in case of registered relation gocharm does not create
symlinks for this relation?

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
jabber: v...@selfip.ru

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

Re: gocharm help

[Vasiliy Tolstov]

2015-04-23 11:00 GMT+03:00 roger peppe :
> Nice start!
>
> As far as I can see the issue is just that there's
> a variant syntax of a relation that's allowed in the metadata
> (I replied in the issue itself).
>
> I had a brief look at your hooks.go file. I'd suggest that
> it's probably better to register the hooks individually,
> rather than using the switch (that way gocharm does the
> work).
>
> As it happens, the gocharm hook logic emits a log message
> anyway when a hook starts and finishes, but if you
> *do* want to wrap other generic logic around hooks, it's
> probably better to use a "decorator" style than to
> introduce the switch.
>
> e.g.
>
> func (n *mysql) registerHook(r *hook.Registry, name string, h
> func() error) {
>   r.RegisterHook(name, func() error {
> n.ctxt.Logf("running %s", name)
> return h()
>   })
>  }
>
>  ...
>  n.registerHook(r, "install", n.install)
>
> Here's a paste of the code with a few suggested changes made:
>
> http://paste.ubuntu.com/10870074/
>
> Please let me know if you have any more issues (or, even better, if
> it all just works ok for you :-] )


Thanks for suggestions, i'm try to write simple wordpress charm and
check relations =)
Last question - what benefits of using simplerelation package or
writing own relations packages?

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
jabber: v...@selfip.ru

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

Graduated reviewer: Domas Monkus

[Casey Marshall]

Juju developers,
I would like to announce Domas Monkus is a fully graduated Juju core
reviewer. This announcement is really long overdue.. Domas is careful
and thoughtful in his reviews, his feedback is useful, actionable and
relevant, and he's landed several significant improvements that
demonstrate a deep understanding of Juju core design and internals.

So let's give praise, thanks (and reviews) to Domas, for a job well done!

-Casey



signature.asc
Description: OpenPGP digital signature
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Feature flag for a provider?

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-04-23 12:27 AM, John Meinel wrote:
> Thinking it through a bit more, I wonder if that is the best
> option. Because if someone is already bootstrapped on CloudSigma
> you really don't have any reason for it to not support CloudSigma.
> It is just broken if it isn't working.

In other words, if they are using a CloudSigma environment, they have
accepted the risk of using the 1.24 version of the provider.  That is
true currently, but it won't be true in the future, when 1.25 is out.
 Presumably 1.25 is production-ready.  If 1.24 isn't production ready,
then if they switch to a different juju (e.g. switch from a desktop to
a laptop or use a team-mate's machine) they could be surprised by a
not-production-ready experience.

Of course, if 1.24's version *is* production-ready, then there's no
reason to keep it behind a flag.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVOPzhAAoJEK84cMOcf+9hFCQIAJoy+WpBhXYUDrrfQcuMbJFQ
2WxGgW1+Nu5Ro1hTgON7Kfxs4ZxSZxlUOZ6TbLFWhXgLgGSyaDh3xc/Mevmn/niX
VS2Ig8W/oMYEpumZ+n4950curoTClgwjA6v3BqipefLyljHZNfz95STgPoYOa8Qy
ydUKehum5FziqVg3+jy/EJZgktXrzA6BhZ+pa4PHp7ZMzhPhTedgR50rXsc841vs
EDYkEb4BxbqWlIJbOZ6Ul9tZb9Ve2CoOE7IBh9ykWCUGWCscIh4axdLGqODn1Obz
USlp4jzk8fYurSKcnnB5z7DiFcKzhwbR2V0PyN1gEf50LFbYWkbd5mLbE8P6Pyk=
=5xZY
-END PGP SIGNATURE-

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

Re: Feature flag for a provider?

[Wayne Witzel]

I don't ever see us moving a provider back behind a feature flag after we
move it out from one, but I agree with the point. If a user was using a
devel version and in a release, we moved a provider behind a flag, they
would stop working and their bootstrapped environment would be stuck, and
that would be no good.

I like the idea of having juju just work and I think moving this in to the
providers Bootstrap call is good. I will make a up a card for that work.
Thanks John.


On Thu, Apr 23, 2015 at 12:27 AM, John Meinel 
wrote:

> So if we want feature flagged providers I think the best option is to
> change registration code path.
> Probably my ideal would be to have
> environs.RegisterFlaggedProvider(name, flag string, p EnvironProvider,
> alias ...string)
>
> and then we can track in environs/config.go that a given provider name is
> flagged with a given feature flag, and have
> environs.Provider() check if a given provider is flagged, and only return
> it if the flag is set.
>
>
> Thinking it through a bit more, I wonder if that is the best option.
> Because if someone is already bootstrapped on CloudSigma you really don't
> have any reason for it to not support CloudSigma. It is just broken if it
> isn't working. (Imagine they used a version of juju that didn't have the
> flag, and upgraded to a version that requires the flag, and suddenly
> everything just breaks.)
>
> What I'd rather see is that only "juju bootstrap" pays attention to
> whether this is a supported provider. And everything else just treats it as
> a fully recognized provider.
>
>
> That might be easiest if we just change CloudSigma.Bootstrap() to check
> for the flag? Does that work out ok for you? That still lets us install the
> provider support, if you're using the provider it JustWorks, and we just
> give you an Error when Bootstrap is called pointing you for how you can
> enable this provider.
>
> John
> =:->
>
>
> On Wed, Apr 22, 2015 at 6:19 PM, Wayne Witzel 
> wrote:
>
>> That sounds reasonable to me Aaron. Also Eric just suggested I put the
>> set flag in export_test.go, he did something similar for GCE and it worked,
>> so I will try that.
>>
>> Thanks.
>>
>> On Wed, Apr 22, 2015 at 9:25 AM, Aaron Bentley <
>> aaron.bent...@canonical.com> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> On 2015-04-22 09:00 AM, Wayne Witzel wrote:
>>> > I've been told to place cloudsigma provider behind a feature flag,
>>> > but the result of that is that the provider is not registered
>>> > unless the env variable for cloudsigma is set.
>>> >
>>> > So after wrapping the registration of the provider in the feature
>>> > flag (see:
>>> >
>>> https://github.com/juju/juju/commit/0a2cf42dcf051fe43bd803ebb144358723b4af82
>>> ),
>>> >
>>> >
>>> the tests no longer pass, since there is no registered provider for
>>> > cloudsigma. Manually calling s.SetFeatureFlag(feature.CloudSigma)
>>> > from the Suite and/or Test setup methods doesn't help since by that
>>> > point the "init" for each provider has already been run.
>>> >
>>> > Looking for suggestions? My thought is that the flag isn't needed
>>> > since by nature providers are contained and their code is only
>>> > called if you explicitly use the provider.
>>>
>>> I think there's a potential quality issue.  I don't know anything
>>> about the state of the cloud sigma provider code, but since it's being
>>> kept behind a feature flag, I have to think
>>> a) The code is not yet production quality or
>>> b) The API isn't stable.
>>>
>>> Say you're using Juju 2.5, in which the cloud sigma provider is fully
>>> production quality.  You create an environment.  Then you go to a
>>> machine that has Juju 2.4, where the provider was not
>>> production-quality, and try to perform an operation on that
>>> environment.  Does Juju break?  Does the environment?
>>>
>>> Because you weren't paying attention to the Juju version number, you
>>> may be surprised by poor behaviour.  Instead, it would be better if
>>> Juju said: "CloudSigma is not production-quality in this version of
>>> Juju.  To enable it anyway, set JUJU_DEV_FEATURE_FLAGS to $FOO."
>>>
>>> So to avoid surprising users, I think a feature flag makes sense.
>>>
>>> Aaron
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v1
>>>
>>> iQEcBAEBAgAGBQJVN6FkAAoJEK84cMOcf+9hXR8IAKoenxmb8797B7xaNB842ZkH
>>> tlwwvsc/joO8Cy73OPFyNg1NQ14g4FVCUJJ6q0qgj51ubIrB1725a0XwilUYSme5
>>> uQGqEebZx6o9Q1SCP7uxOAZ4SEH7KftjIiqKG7kTzV93ZSeJtyK3Y7K7IuKw18UL
>>> VvOdhxrAie/dBnxhx16CqqbJcSj21RqLmd9osgL+gWTPtZ+UkAwV5nDqunAfaqt4
>>> 9DeoYloYVeqaFlQoTsyMB0hxd3Z63S+gHcjGWSRfAqdXCOZFjMntdbq8+dOMDMvB
>>> FkL0GBKliC7tPio2/w7OF4UW8AGMxQvMGddJflOFFt+CNAGwaLtxf6mHuA9jRGw=
>>> =VdEM
>>> -END PGP SIGNATURE-
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>
>>
>>
>> --
>> Wayne Witzel III
>> wayne.wit...@canonical.com
>>
>> --
>> Juju-dev mai

Re: Test suite on windows now voting on trunk

[Martin Packman]

Well, mostly good news after Matty and I landed workarounds. There's a
single remaining failure that has manifested since:

TestLeadership fails on windows test slave


On 22/04/2015, John Meinel  wrote:
> That sounds like it could be a runtime problem rather than just a testing
> problem.  It sounds surprising that we would ever reference an environment
> variable with Title case.

It does seem to be, though whether it comes up in practice will I
guess depend on your base windows image. For now the hack in the test
runner seems effective.

Martin

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

Re: Vivid init system bug status

[Martin Packman]

On 17/04/2015, Martin Packman  wrote:
>
> I have put up a merge proposal making the error handling robust across
> go versions, and removing the map interation confusion:
>
> 
>
> This should be on the 1.23 branch shortly.

Well, this was all a bit of a disaster.

That fix resolves the case where upstart is not installed (a fresh
vivid system), but breaks the case where upstart is installed but not
enabled (an upgraded vivid system):



Eric has proposed a branch with a bunch more changes, but I'm not
really happy with unit tests that rely on the state of the underlying
system to cover all the cases we care about.

Martin

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

Re: gocharm help

[roger peppe]

Nice start!

As far as I can see the issue is just that there's
a variant syntax of a relation that's allowed in the metadata
(I replied in the issue itself).

I had a brief look at your hooks.go file. I'd suggest that
it's probably better to register the hooks individually,
rather than using the switch (that way gocharm does the
work).

As it happens, the gocharm hook logic emits a log message
anyway when a hook starts and finishes, but if you
*do* want to wrap other generic logic around hooks, it's
probably better to use a "decorator" style than to
introduce the switch.

e.g.

func (n *mysql) registerHook(r *hook.Registry, name string, h
func() error) {
  r.RegisterHook(name, func() error {
n.ctxt.Logf("running %s", name)
return h()
  })
 }

 ...
 n.registerHook(r, "install", n.install)

Here's a paste of the code with a few suggested changes made:

http://paste.ubuntu.com/10870074/

Please let me know if you have any more issues (or, even better, if
it all just works ok for you :-] )

  cheers,
rog.


On 23 April 2015 at 00:08, Vasiliy Tolstov  wrote:
> My first steps in github repo :
> https://github.com/vtolstov/charms/blob/master/mysql/runhook.go
>
> 2015-04-23 2:01 GMT+03:00 Vasiliy Tolstov :
>> Hello, i'm try to investigate gocharm and i'm happy with it.
>> But i'm stuck ad this issues:
>> https://github.com/juju/gocharm/issues/44
>> can somebody helps me?
>>
>> --
>> Vasiliy Tolstov,
>> e-mail: v.tols...@selfip.ru
>> jabber: v...@selfip.ru
>
>
>
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
> jabber: v...@selfip.ru
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju-dev

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