Re: First customer pain point pull request - default-hook
On Wed, Aug 20, 2014 at 12:29 AM, Kapil Thangavelu < kapil.thangav...@canonical.com> wrote: > hmm.. there's three distinct threads here. > > default-hook -> charms that do so symlink 0-100% -> to one hook.. in > practice everything, sometimes minus install (as the hook infrastructure > needs pkgs).. and most typically implemented via dispatch table. > And AFAICS everybody agrees it's nice, and we seem to be approaching consensus re JUJU_HOOK_NAME. something-changed -> completely orthogonal to either the default-hook merge > request, and in practice full of exceptions, but useful as an optimization > of event collapsing around charms capable of event coalescence > Not *entirely* orthogonal -- they do similar *enough* jobs that you wouldn't want to implement both in the same charm -- but, yeah. I'm happy to discuss that further (new thread maybe?) but I don't think it's under immediate consideration anyway. periodic async framework invoked -> metrics and health checks. afaics best > practices around these would be not invoking default-hook which is > lifecycle event handler, while these are periodic poll, yes its possible > but it conflates different roles. > Not so sure about this. By "lifecycle events", do you mean "all the events we have hitherto communicated"? I'm not sure the distinction between old and new will be intuitively clear, and I don't think the consequences of triggering default-hook are serious -- on that front I reserve my concern for the introduction of hook contexts with surprising features, but again I think there's a happy path we can walk by requiring opt-in to such features. Cheers William -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: status of container support in Juju
So you're always welcome to do more testing :), but I'm sure that right now LXC containers only get host-local IP addresses, and are not bridged to the outside network anywhere but on MaaS. John =:-> On Tue, Aug 19, 2014 at 6:56 PM, Richard Harding wrote: > Thanks for the correction. You're right, in the testing we were checking > expose directly. We also did a test (not in this script) around two > services where one was on the root and one was in a container, but even > that's not a fair case of 'routable' as that might work while two units on > different machines would not. > > We'll update and do some more testing. > > On Tue, 19 Aug 2014, John Meinel wrote: > > > "expose" is different because it is about making the service available > > outside of the cloud. The issue with route able containers is that they > > aren't route able even within the cloud. > > At this point only MaaS has route able containers. > > > > John > > =:-> > > On Aug 19, 2014 4:56 PM, "Richard Harding" > > wrote: > > > > > On Tue, 19 Aug 2014, Richard Harding wrote: > > > > > > > Right now I'm hesitant to enable creating containers in Machine View > for > > > > anything but MAAS. > > > > > > Just to clarify, after having some more coffee we can warn users that > > > expose services that have units in containers in the GUI and it should > help > > > raise warning to users about the routing issues for now. It's after the > > > user has set things up, but it should allow us to allow containers in > most > > > providers. > > > > > > -- > > > > > > Rick > > > > > > > > > -- > > > 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
Re: First customer pain point pull request - default-hook
On Wed, Aug 20, 2014 at 3:07 AM, Aaron Bentley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > On 14-08-19 12:46 PM, Gustavo Niemeyer wrote: >> On Tue, Aug 19, 2014 at 1:10 PM, Aaron Bentley >> wrote: >>> True. At that point, the pattern is not a win, but it's not much >>> of a loss. Changing the web site relation is extremely uncommon, >>> but operations which do require server restarts are quite common. >>> So making an exception for the web site relation can be seen as >>> a micro-optimization. >> >> Restarting a process and killing all on-going activity is a big >> deal more often than not, for realistic services. > > Sure, if we *were* to optimize this, we'd want to restart only on > certain kinds of changes. But I'd argue that it's better to optimize > that in the application domain than based on hook names. > > For example, changing the cron interval does not require restarting > the web server, but changing the http port does. Both use the same > hook, config-changed. > > Instead of restarting the web server unconditionally, we could restart > it when the contents of its config file change. That would avoid a > restart when cron interval changes, and also when > webserver-relation-changed fires. +1, we do the same thing (well, ansible does it for us). For example, this simple task: https://pastebin.canonical.com/115614/ tells ansible to re-render the config file on config-changed and *-relation-changed, but it will only notify the 'Restart wsgi' handler if the config changes (in fact, the config file will only be touched if the template rendering results in a diff from the existing one). > > So I think it's a bigger win to focus on the application domain and > ignore the hook names. Hrm - so with the above task, I could instead ignore the hook names and have it run for any hook (or the new default-hook) - it would still only update the config file and restart when the file changes. But I've only got it running for those 3 hooks because I know that's when it needs to be checked (ie. I know that I don't need to run it on *-relation-joined, only -changed etc.). Perhaps it's only a small efficiency gain for a potential mistake on my part. > >> The point I was trying to convey is not that you can merge or >> ignore certain events. The system was designed so that this was >> possible in the first place. The point is rather that the existing >> event system is convenient and people rely on it, so I don't buy >> that a "something-changed" hook is what most people want at this >> point. > > Fair enough. More evidence would be needed to determine whether I'm > an outlier. I'm keen to try updating one of my charms to do this, but am not doing so currently. -Michael > > Aaron > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJT84RTAAoJEK84cMOcf+9hmXEIAIc74ywBWOMybk6tVZh0sT/r > 0GBt/AhDVRfzAt75rZGzuwlQLvu3tyAwY6yu0ROAdnW+dmJf5yGwJUAIDR3V0kcu > kO866sXDmTysPs8vmiku1xFhFnwbxaJEJWG67zcUOacsl8fHaxMDH0ufm8YoOGgR > fs6VtLp283wm1rYmeXwZ8FkZ7QRQZYwFZ9gNpXCjKHdSbW/yaT4o1HC7+MgeG3Cc > mwPLWl2qQGHXxB6Jc2Bb+ebBw8WTSRNvpS4UmrMSzbbdqvlaytuJuRP6ansYTVYi > X5I+CBWDbbImZBfEADCkQPYk1jX1GlinoQuInbnGrftViyQ/KTEXzzAEIJcRIGE= > =bqp0 > -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 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
hmm.. there's three distinct threads here. default-hook -> charms that do so symlink 0-100% -> to one hook.. in practice everything, sometimes minus install (as the hook infrastructure needs pkgs).. and most typically implemented via dispatch table. something-changed -> completely orthogonal to either the default-hook merge request, and in practice full of exceptions, but useful as an optimization of event collapsing around charms capable of event coalescence periodic async framework invoked -> metrics and health checks. afaics best practices around these would be not invoking default-hook which is lifecycle event handler, while these are periodic poll, yes its possible but it conflates different roles. cheers, Kapil also +1 to default-hook using JUJU_HOOK_NAME. On Tue, Aug 19, 2014 at 6:10 PM, Gustavo Niemeyer wrote: > On Tue, Aug 19, 2014 at 6:58 PM, Matthew Williams > wrote: > > Something to be mindful of is that we will shortly be implementing a new > > hook for metering (likely called collect-metrics). This hook differs > > slightly to the others in that it will be called periodically (e.g. once > > every hour) with the intention of sending metrics for that unit to the > state > > server. > > > > I'm not sure it changes any of the details in this feature or the pr - > but I > > thought you should be aware of it > > Yeah, that's a good point. I'm wonder how reliable the use of > default-hook will be, as it's supposed to run whenever any given hook > doesn't exist, so charms using that feature should expect _any_ hook > to be called there, even those they don't know about, or that don't > even exist yet. The charms that symlink into a single hook seem to be > symlinking a few things, not everything. It may well turn out that > default-hook will lead to brittle charms. > > > gustavo @ http://niemeyer.net > > -- > 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
Re: First customer pain point pull request - default-hook
On Tue, Aug 19, 2014 at 6:58 PM, Matthew Williams wrote: > Something to be mindful of is that we will shortly be implementing a new > hook for metering (likely called collect-metrics). This hook differs > slightly to the others in that it will be called periodically (e.g. once > every hour) with the intention of sending metrics for that unit to the state > server. > > I'm not sure it changes any of the details in this feature or the pr - but I > thought you should be aware of it Yeah, that's a good point. I'm wonder how reliable the use of default-hook will be, as it's supposed to run whenever any given hook doesn't exist, so charms using that feature should expect _any_ hook to be called there, even those they don't know about, or that don't even exist yet. The charms that symlink into a single hook seem to be symlinking a few things, not everything. It may well turn out that default-hook will lead to brittle charms. gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
Something to be mindful of is that we will shortly be implementing a new hook for metering (likely called collect-metrics). This hook differs slightly to the others in that it will be called periodically (e.g. once every hour) with the intention of sending metrics for that unit to the state server. I'm not sure it changes any of the details in this feature or the pr - but I thought you should be aware of it Matty On Tue, Aug 19, 2014 at 6:07 PM, Aaron Bentley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > On 14-08-19 12:46 PM, Gustavo Niemeyer wrote: > > On Tue, Aug 19, 2014 at 1:10 PM, Aaron Bentley > > wrote: > >> True. At that point, the pattern is not a win, but it's not much > >> of a loss. Changing the web site relation is extremely uncommon, > >> but operations which do require server restarts are quite common. > >> So making an exception for the web site relation can be seen as > >> a micro-optimization. > > > > Restarting a process and killing all on-going activity is a big > > deal more often than not, for realistic services. > > Sure, if we *were* to optimize this, we'd want to restart only on > certain kinds of changes. But I'd argue that it's better to optimize > that in the application domain than based on hook names. > > For example, changing the cron interval does not require restarting > the web server, but changing the http port does. Both use the same > hook, config-changed. > > Instead of restarting the web server unconditionally, we could restart > it when the contents of its config file change. That would avoid a > restart when cron interval changes, and also when > webserver-relation-changed fires. > > So I think it's a bigger win to focus on the application domain and > ignore the hook names. > > > The point I was trying to convey is not that you can merge or > > ignore certain events. The system was designed so that this was > > possible in the first place. The point is rather that the existing > > event system is convenient and people rely on it, so I don't buy > > that a "something-changed" hook is what most people want at this > > point. > > Fair enough. More evidence would be needed to determine whether I'm > an outlier. > > Aaron > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJT84RTAAoJEK84cMOcf+9hmXEIAIc74ywBWOMybk6tVZh0sT/r > 0GBt/AhDVRfzAt75rZGzuwlQLvu3tyAwY6yu0ROAdnW+dmJf5yGwJUAIDR3V0kcu > kO866sXDmTysPs8vmiku1xFhFnwbxaJEJWG67zcUOacsl8fHaxMDH0ufm8YoOGgR > fs6VtLp283wm1rYmeXwZ8FkZ7QRQZYwFZ9gNpXCjKHdSbW/yaT4o1HC7+MgeG3Cc > mwPLWl2qQGHXxB6Jc2Bb+ebBw8WTSRNvpS4UmrMSzbbdqvlaytuJuRP6ansYTVYi > X5I+CBWDbbImZBfEADCkQPYk1jX1GlinoQuInbnGrftViyQ/KTEXzzAEIJcRIGE= > =bqp0 > -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 > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-08-19 12:46 PM, Gustavo Niemeyer wrote: > On Tue, Aug 19, 2014 at 1:10 PM, Aaron Bentley > wrote: >> True. At that point, the pattern is not a win, but it's not much >> of a loss. Changing the web site relation is extremely uncommon, >> but operations which do require server restarts are quite common. >> So making an exception for the web site relation can be seen as >> a micro-optimization. > > Restarting a process and killing all on-going activity is a big > deal more often than not, for realistic services. Sure, if we *were* to optimize this, we'd want to restart only on certain kinds of changes. But I'd argue that it's better to optimize that in the application domain than based on hook names. For example, changing the cron interval does not require restarting the web server, but changing the http port does. Both use the same hook, config-changed. Instead of restarting the web server unconditionally, we could restart it when the contents of its config file change. That would avoid a restart when cron interval changes, and also when webserver-relation-changed fires. So I think it's a bigger win to focus on the application domain and ignore the hook names. > The point I was trying to convey is not that you can merge or > ignore certain events. The system was designed so that this was > possible in the first place. The point is rather that the existing > event system is convenient and people rely on it, so I don't buy > that a "something-changed" hook is what most people want at this > point. Fair enough. More evidence would be needed to determine whether I'm an outlier. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJT84RTAAoJEK84cMOcf+9hmXEIAIc74ywBWOMybk6tVZh0sT/r 0GBt/AhDVRfzAt75rZGzuwlQLvu3tyAwY6yu0ROAdnW+dmJf5yGwJUAIDR3V0kcu kO866sXDmTysPs8vmiku1xFhFnwbxaJEJWG67zcUOacsl8fHaxMDH0ufm8YoOGgR fs6VtLp283wm1rYmeXwZ8FkZ7QRQZYwFZ9gNpXCjKHdSbW/yaT4o1HC7+MgeG3Cc mwPLWl2qQGHXxB6Jc2Bb+ebBw8WTSRNvpS4UmrMSzbbdqvlaytuJuRP6ansYTVYi X5I+CBWDbbImZBfEADCkQPYk1jX1GlinoQuInbnGrftViyQ/KTEXzzAEIJcRIGE= =bqp0 -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: First customer pain point pull request - default-hook
On Tue, Aug 19, 2014 at 1:10 PM, Aaron Bentley wrote: > True. At that point, the pattern is not a win, but it's not much of a > loss. Changing the web site relation is extremely uncommon, but > operations which do require server restarts are quite common. So > making an exception for the web site relation can be seen as a > micro-optimization. Restarting a process and killing all on-going activity is a big deal more often than not, for realistic services. >>> True, I didn't call out the exceptions for the charmworld charm. >>> For completeness, the exceptions in charmworld are: >> >> Yeah, it definitely depends on knowing the events still. > > On the other hand, it doesn't depend on knowing the events for > database relation, search engine relation and configuration changes. The point I was trying to convey is not that you can merge or ignore certain events. The system was designed so that this was possible in the first place. The point is rather that the existing event system is convenient and people rely on it, so I don't buy that a "something-changed" hook is what most people want at this point. At the same time, that's not an argument _against_ it either. If you're happy with your design, and that'd help you, and William thinks this can be conveniently implemented, I'm all for making people's lives easier. gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-08-19 11:41 AM, Gustavo Niemeyer wrote: > On Tue, Aug 19, 2014 at 11:59 AM, Aaron Bentley > wrote: > At the same time, the strictness of redoing everything all the time > is not necessary, and a good example is still that > website-relation-changed hook for instance. There is not, in fact, > a need to rebuild your whole confguration, including stopping and > starting the service, because somebody wants to know what is your > address after joining that relation. True. At that point, the pattern is not a win, but it's not much of a loss. Changing the web site relation is extremely uncommon, but operations which do require server restarts are quite common. So making an exception for the web site relation can be seen as a micro-optimization. >> True, I didn't call out the exceptions for the charmworld charm. >> For completeness, the exceptions in charmworld are: > > Yeah, it definitely depends on knowing the events still. On the other hand, it doesn't depend on knowing the events for database relation, search engine relation and configuration changes. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJT83cIAAoJEK84cMOcf+9hyu0H/Rr2Qz9hPo+EYuhbhuZH1y4i yvoR389RepwA493v10EyfS/LX7Yoj4rk1fv0mnv//KdSV4TV8seIbc/ZyOoyDlqq jFZLKQwV8wX9o4tz0fqi99hsxAZRIs6SoB8lSQtDLaGypkxgdCA2Liz4uL+g//Ge L/AP874la/Du5G/XfQScoZjuPwIWPkkNDq8j5DWqe5qxmD9dxGSePEP+KjXpk0Hl ZGiaSOPX/YHY4J/Lov/rjrh334myOudyyjRafy+iBgAz+7Z8fpdkZ8Yl3pFrx4vR jTecJNkl0D1K6Hb/JXiPndKpvG7c/ZmBTb4D58W0yYCYSFpCuhjXCToOOMhOZLw= =Knf7 -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: First customer pain point pull request - default-hook
On Tue, Aug 19, 2014 at 5:43 PM, Gustavo Niemeyer < gustavo.nieme...@canonical.com> wrote: > On Tue, Aug 19, 2014 at 12:41 PM, William Reade > wrote: > > (out of interest, if started/stopped state were communicated to you any > > other way, would you still need these?) > > If you communicate events in a different way, you obviously won't need > your previous way of communicating events. > Sure -- but it's perhaps telling that (AFAIR) *all* the other state we expose via hook execution *is* accessible from any other hook via a hook tool. Was there a specific rationale for treating that particular bool differently? It seems that if we exposed that state, we'd have at least one more config-changed hook that acted as it's meant to ;p. Cheers William > > gustavo @ http://niemeyer.net > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-08-19 11:41 AM, William Reade wrote: > On Tue, Aug 19, 2014 at 4:59 PM, Aaron Bentley > mailto:aaron.bent...@canonical.com>> > wrote: > > reverseproxy-relation-joined start stop > > > (out of interest, if started/stopped state were communicated to you > any other way, would you still need these?) I don't think we'd need it. We would want charm proof updated suitably. In fact, I think we're not properly respecting stop/start as it stands; config-changed just starts if all resources are ready and stops when they're not. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJT83LbAAoJEK84cMOcf+9hLPwH/AyxUbvkDhnC9thVN9bhDr4F O5plYoOHb+yU3EC9h+V2EED7hm4oRaLw44JIssEkfQK6/MDYDIfBIZTwy7kK+ZNA DjJ35L/ELPVFLEEyU20FXpe3dJoP/cdDHn5G6KnALG4hPB39eG0VmUVmn7r/lNMh Zk1jA89K0liscdsdm7m8Fvn5/suq2u6j7s/9GJhv253R6Eb642whNHufMsBqyaGd uXSpHioLjV1po4JFPOSYbE6cfvbSlXHERE5ZxuBcMh3LKfbbQeV5YyHi6UhfStp8 JINIlDzhDc3XTyNI8RDp2YR0FvekoStaE6egxQIU1GtFLwSQGqPfGAbRh2wUFQk= =Q0pF -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: First customer pain point pull request - default-hook
On Tue, Aug 19, 2014 at 12:41 PM, William Reade wrote: > (out of interest, if started/stopped state were communicated to you any > other way, would you still need these?) If you communicate events in a different way, you obviously won't need your previous way of communicating events. gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
On Tue, Aug 19, 2014 at 11:59 AM, Aaron Bentley wrote: >> This is actually your website-relation-changed hook: >> >> http://paste.ubuntu.com/8089398/ > > No, it's not: > http://manage.jujucharms.com/~juju-qa/precise/juju-reports/hooks/website-relation-changed Sorry, I was looking at your own version which is perhaps outdated: https://jujucharms.com/~abentley/precise/juju-reports-0/?text=juju-reports#code Nevertheless, I can appreciate the underlying pattern you propose there. It's trying to build a charm that can work in a somewhat idempotent way. It will try to walk towards the same state independently from order of events or settings that come through configuration or relations. At the same time, the strictness of redoing everything all the time is not necessary, and a good example is still that website-relation-changed hook for instance. There is not, in fact, a need to rebuild your whole confguration, including stopping and starting the service, because somebody wants to know what is your address after joining that relation. >>> The charmworld charm is similar. >> >> This is reverseproxy-relation-joined there: >> >> http://paste.ubuntu.com/8089386/ > > True, I didn't call out the exceptions for the charmworld charm. For > completeness, the exceptions in charmworld are: Yeah, it definitely depends on knowing the events still. gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
On Tue, Aug 19, 2014 at 4:59 PM, Aaron Bentley wrote: > > True, I didn't call out the exceptions for the charmworld charm. For > completeness, the exceptions in charmworld are: > install > nrpe-external-master-relation-changed > restart > (this isn't actually a hook?) > reverseproxy-relation-joined > start > stop > (out of interest, if started/stopped state were communicated to you any other way, would you still need these?) > upgrade-charm > website-relation-changed > Cheers William -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
On Tue, Aug 19, 2014 at 4:00 PM, Aaron Bentley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 14-08-19 09:42 AM, Gustavo Niemeyer wrote: > > I have never seen myself a single charm that completely ignores > > all the action cues to simply re-read the whole state from the > > ground up, > > The cs:~juju-qa/precise/juju-reports charm follows this general > pattern, but there are some specialized hooks: install, start, stop > and upgrade-charm. > ...and in case it's not clear: defined hooks would still continue to run at the appropriate times, so exceptions can be accommodated. But I think it becomes valuable as soon as there's any subset of hooks (most likely, indeed, the relation ones) where the charm's put in a position of rescanning the world one change at a time -- in which case all such situations can be handled in batches at a more measured cadence. config-changed, database-relation-broken, database-relation-changed, > database-relation-departed, and website-relation-changed are all the > same code and read the state afresh every time without reference to > the script name. > > The charmworld charm is similar. > And I'd be most interested to hear from anyone else who is also finding this mode of interaction with juju to be convenient... Cheers William -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-08-19 10:36 AM, Gustavo Niemeyer wrote: > On Tue, Aug 19, 2014 at 11:00 AM, Aaron Bentley > wrote: >> On 14-08-19 09:42 AM, Gustavo Niemeyer wrote: >>> I have never seen myself a single charm that completely >>> ignores all the action cues to simply re-read the whole state >>> from the ground up, >> >> The cs:~juju-qa/precise/juju-reports charm follows this general >> pattern, but there are some specialized hooks: install, start, >> stop and upgrade-charm. >> >> config-changed, database-relation-broken, >> database-relation-changed, database-relation-departed, and >> website-relation-changed are all the same code and read the state >> afresh every time without reference to the script name. > > This is actually your website-relation-changed hook: > > http://paste.ubuntu.com/8089398/ No, it's not: http://manage.jujucharms.com/~juju-qa/precise/juju-reports/hooks/website-relation-changed >> The charmworld charm is similar. > > This is reverseproxy-relation-joined there: > > http://paste.ubuntu.com/8089386/ True, I didn't call out the exceptions for the charmworld charm. For completeness, the exceptions in charmworld are: install nrpe-external-master-relation-changed restart reverseproxy-relation-joined start stop upgrade-charm website-relation-changed Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJT82ZEAAoJEK84cMOcf+9hGOMH/iwSH3CIuMXWFwba7eAkfF6l jh8Bn7/XhAcIeESAdOjSOeEkWV3+1YA33J+2b7hThWlnWKMMtpfAfzlKEbB3h4VN sLfK3OHQtH23pfMVU4UZ6K55PbrhGxkUXJTDFJaqSm9vqFqQr+Z226QlkQGfDmVK EyzVY813j60T9dE1Mn0EQvyLDOwuASIw1fNQwoGI3PhsBau8LkmwikXjOxEzn6hy L9TFRD/w5OPByLjAWo9Ti+wEWH9/z/W3y0bYOkZRShwS9HyfeztzQz6X34v6kQhW SO+D6tlkwzx46UxfIBuhsqS1xF64eu7P5yx42cCiAPfWdOuX/BFALvtxYZKEAQw= =tBSZ -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: status of container support in Juju
Thanks for the correction. You're right, in the testing we were checking expose directly. We also did a test (not in this script) around two services where one was on the root and one was in a container, but even that's not a fair case of 'routable' as that might work while two units on different machines would not. We'll update and do some more testing. On Tue, 19 Aug 2014, John Meinel wrote: > "expose" is different because it is about making the service available > outside of the cloud. The issue with route able containers is that they > aren't route able even within the cloud. > At this point only MaaS has route able containers. > > John > =:-> > On Aug 19, 2014 4:56 PM, "Richard Harding" > wrote: > > > On Tue, 19 Aug 2014, Richard Harding wrote: > > > > > Right now I'm hesitant to enable creating containers in Machine View for > > > anything but MAAS. > > > > Just to clarify, after having some more coffee we can warn users that > > expose services that have units in containers in the GUI and it should help > > raise warning to users about the routing issues for now. It's after the > > user has set things up, but it should allow us to allow containers in most > > providers. > > > > -- > > > > Rick > > > > > > -- > > 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
Re: status of container support in Juju
"expose" is different because it is about making the service available outside of the cloud. The issue with route able containers is that they aren't route able even within the cloud. At this point only MaaS has route able containers. John =:-> On Aug 19, 2014 4:56 PM, "Richard Harding" wrote: > On Tue, 19 Aug 2014, Richard Harding wrote: > > > Right now I'm hesitant to enable creating containers in Machine View for > > anything but MAAS. > > Just to clarify, after having some more coffee we can warn users that > expose services that have units in containers in the GUI and it should help > raise warning to users about the routing issues for now. It's after the > user has set things up, but it should allow us to allow containers in most > providers. > > -- > > Rick > > > -- > 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
Re: First customer pain point pull request - default-hook
On Tue, Aug 19, 2014 at 11:00 AM, Aaron Bentley wrote: > On 14-08-19 09:42 AM, Gustavo Niemeyer wrote: >> I have never seen myself a single charm that completely ignores >> all the action cues to simply re-read the whole state from the >> ground up, > > The cs:~juju-qa/precise/juju-reports charm follows this general > pattern, but there are some specialized hooks: install, start, stop > and upgrade-charm. > > config-changed, database-relation-broken, database-relation-changed, > database-relation-departed, and website-relation-changed are all the > same code and read the state afresh every time without reference to > the script name. This is actually your website-relation-changed hook: http://paste.ubuntu.com/8089398/ > The charmworld charm is similar. This is reverseproxy-relation-joined there: http://paste.ubuntu.com/8089386/ gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-08-19 09:42 AM, Gustavo Niemeyer wrote: > I have never seen myself a single charm that completely ignores > all the action cues to simply re-read the whole state from the > ground up, The cs:~juju-qa/precise/juju-reports charm follows this general pattern, but there are some specialized hooks: install, start, stop and upgrade-charm. config-changed, database-relation-broken, database-relation-changed, database-relation-departed, and website-relation-changed are all the same code and read the state afresh every time without reference to the script name. The charmworld charm is similar. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJT81hrAAoJEK84cMOcf+9h8xkH/3wBuryErE0RV6TAnOY4Oi+A 3Oxxt0G0t8oVJEw8VkxV36UyzkOkBtfrcSE0GovVBocDMem2qiQcFPb6mc1N++Q2 tpQedW1bKBvH6iyA8lO/R/h/4ug/ubKFpuHROhfET4qFN2XDr7PYimEycHFD/Wbg k78P3YufZEezicnAYyzgMuALMP6K90zAXUG/I3+OvO3fcL1/QfwL9H0QflH8llzv 6LTVtkVX9RyJunLOV6P8SfxjKlttqE88j30F9DrXLTqb8fRsh4qet16/Yj4ib/Vl dnDW8468wt8HOqDIcV6lTIEKbsSEalsDFNHD5cdzUSBj65W01qwLSCwo/eC5uDc= =D2ZN -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: First customer pain point pull request - default-hook
On Tue, Aug 19, 2014 at 9:07 AM, William Reade
wrote:
> On Mon, Aug 18, 2014 at 9:33 PM, Gustavo Niemeyer
> wrote:
>>
>> I don't think I fully understand the proposal there. To have such a
>> "something-changed" hook, we ought to have a better mechanism to tell
>> *what* actually changed. In other words, we have a number of hooks
>> that imply a state transition or a specific notification ("install",
>> "start", "config-changed", "leader-elected" coming, etc). Simply
>> calling out the charm saying "stuff changed" feels like a bad
>> interface, both in performance terms (we *know* what changed) and in
>> user experience (how do people use that!?).
>
> The issue is that as charms increase in sophistication, they seem to find it
> harder and harder to meaningfully map specific changes onto specific
> actions. Whether or not to react to a change in one relation depends on the
> values of a bunch of other units in other relations, to the extent that any
> individual relation change can have arbitrarily far-reaching consequences,
> and it ends up being easier to simply write something that maps directly
> from complete-available-state to desired-config.
I have never seen myself a single charm that completely ignores all
the action cues to simply re-read the whole state from the ground up,
and we've just heard in this thread people claiming that even the
charms that use a single hook via symlinks still rely on a dispatching
table based on what action is happening, so I'm not ready to accept
that claim at face value without some actual data.
What percentage of the charms we have completely ignore the actions
that are taking place when making decisions?
> * leader-deposed will completely lack hook tools: we can't run a
> default-hook there unless we know for sure that the implementation doesn't
> depend on any hook tools (in general, this is unlikely).
Why? People can still run hook tools in leader-deposed, and they will
not work. The situation is no different with default-hook: they are
just two files in the same directory. Run one instead of the other.
gustavo @ http://niemeyer.net
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Landing bot restrictions
On Mon, Aug 18, 2014 at 5:15 PM, Menno Smits wrote: > Be aware that I've seen JFDI used at least a couple of times over recent > weeks on PRs that *were* related to fixing a CI blocker but the person was > in too much of a hurry to add the appropriate __fixes-N__ comment. That > accounts for at least some of the JFDI usage (but certainly not all of it). > > At any rate, we should surely be preferring the "fixes" comment over "JFDI" > whenever a PR is related to a CI blocker fix. I have seen this too. It didn't bother since it there was a battle going on between me, github and the mergebot about syntax. One day the merge will also update the bug status. At that point we will al care that the bug identifies the bug that we want marked fix-committed. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: status of container support in Juju
On Tue, 19 Aug 2014, Richard Harding wrote: > Right now I'm hesitant to enable creating containers in Machine View for > anything but MAAS. Just to clarify, after having some more coffee we can warn users that expose services that have units in containers in the GUI and it should help raise warning to users about the routing issues for now. It's after the user has set things up, but it should allow us to allow containers in most providers. -- Rick -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
status of container support in Juju
For our work on Machine View in the Juju GUI the team needs to help the user know what can and cannot be done with machines and containers. One of those things is determining if lxc or kvm containers work on various providers so the UX will not show users an option we know doesn't work. Jay wrote up a quick script [1] to test it out on each provider we support and I wanted to double check these results are expected. Provider | kvm | lxc | container is routable to client EC2 | no | yes | no Azure | no | no | - Azure w/o AS | no | yes | no HP Cloud | no | yes | no Joyent| no | yes | no Local (lxc) | no | no | - Local (kvm+aufs) | no | no | - Local (kvm-aufs) | no | yes | - I've not finished getting my MAAS setup going but I understand that it should work here. It'd be the only one that can currently create a container on a machine and then access it without needing to setup tunnels since it just grabs a DHCP address from the MAAS server. I understand that there's been work started on EC2 and routable lxc containers, but that it was put on hold to work on IPV6. So that path should be nicer in the near future. I also find a lot of references to LXC nesting [2][3] but it seems it does not work out of the box currently. If it's meant to work I can get Jay to file a bug and see if we can pull together any notes on that. Are there any plans to making lxc containers routeable in HP and Joyent? Does anyone know if lxc in lxc is meant to be supported in local out of the box? Right now I'm hesitant to enable creating containers in Machine View for anything but MAAS. I know that, in the providers that support lxc, as long as the service isn't exposed it's ok. I am worried about how to direct feedback to the user that they've deployed a scenario (mysql on the root while wordpress in a non-routable container) that we know can't work as users would expect. Please let me know if something should work that we're not seeing as working. 1: http://paste.ubuntu.com/8088459/ 2: http://s3hh.wordpress.com/2014/03/31/nested-lxc/ 3: https://www.stgraber.org/2012/05/04/lxc-in-ubuntu-12-04-lts/ -- Rick Harding Juju UI Engineering https://launchpad.net/~rharding @mitechie -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
On Mon, Aug 18, 2014 at 9:33 PM, Gustavo Niemeyer
wrote:
> I don't think I fully understand the proposal there. To have such a
> "something-changed" hook, we ought to have a better mechanism to tell
> *what* actually changed. In other words, we have a number of hooks
> that imply a state transition or a specific notification ("install",
> "start", "config-changed", "leader-elected" coming, etc). Simply
> calling out the charm saying "stuff changed" feels like a bad
> interface, both in performance terms (we *know* what changed) and in
> user experience (how do people use that!?).
>
The issue is that as charms increase in sophistication, they seem to find
it harder and harder to meaningfully map specific changes onto specific
actions. Whether or not to react to a change in one relation depends on the
values of a bunch of other units in other relations, to the extent that any
individual relation change can have arbitrarily far-reaching consequences,
and it ends up being easier to simply write something that maps directly
from complete-available-state to desired-config.
This situation seems to be leading more people to actually write (or depend
on) frameworks similar to the one Ben presented in Nuremberg (to, I
thought, a positive reception). Not all charms necessarily want or need to
be written this way -- perhaps the bulk of them shouldn't -- but those that
already *are* end up with really yucky execution patterns: they run the
same code *again and again*, potentially hundreds of times, quite probably
repeatedly bouncing the service -- and ofc spamming the state server with
flushes for every hook executed, and probably spamming other units with
multiple relation changes; and in general taking much longer to arrive at
the ideal state.
This style of charm evidently *works* right now, it's true, but it's both
yucky and unnecessary to run so many hooks to no purpose. And if some
reasonable subset of charmers are tending that way anyway, let's make sure
juju can take advantage of the situation and use those charms to full
effect.
I understand the underlying problem William is trying to solve but the
> current proposal doesn't seem like a complete solution on its own, and
> it also seems to change the existing understanding of the model
> completely. The proposed default-hooks is a trivial change to the
> existing well known workflow.
>
It's not *quite* so trivial when you consider unknown future hooks: we need
to be careful that we don't run it in situations where the charm may not be
prepared to deal with the specific features of the hook context. Off the
top of my head:
* relation-config-changed will have something that looks very much like a
normal relation context, but lacking JUJU_REMOTE_UNIT; the only other
context looking like that is relation-broken;
* leader-deposed will completely lack hook tools: we can't run a
default-hook there unless we know for sure that the implementation doesn't
depend on any hook tools (in general, this is unlikely).
But if the default substitution only happens for scheduled hooks (it does,
thanks Nate) and if we're careful not to expose new features to charms that
don't know them (which we shall have to be anyway, lest unpredictably ugly
consequences), then we'll be fine.
And FWIW, +100 to $JUJU_HOOK_NAME. The argv stuff is deeply opaque -- sure,
argv[0] is obvious, but argv[1] is not; and it won't even be there when
people invoke it directly via debug-hooks or run, so a clearly-named env
var is surely the right way to go. (Apart from anything else, the
environment is where we put most of the other data pertaining to a
particular context: $JUJU_RELATION_ID, $JUJU_REMOTE_UNIT, etc etc)
Cheers
William
On Sun, Aug 17, 2014 at 2:30 AM, John Meinel wrote:
> > I'd just like to point out that William has thought long and hard about
> this
> > problem, and what semantics make the most sense (does it get called for
> any
> > hook, does it always get called, does it only get called when the hook
> > doesn't exist, etc).
> > I feel like had some really good decisions on it:
> >
> https://docs.google.com/a/canonical.com/document/d/1V5G6v6WgSoNupCYcRmkPrFKvbfTGjd4DCUZkyUIpLcs/edit#
> >
> > default-hook sounds (IMO) like it may run into problems where we do logic
> > based on whether a hook exists or not. There are hooks being designed
> like
> > leader-election and address-changed that might have side effects, and
> > default-hook should (probably?) not get called for those.
> >
> > I'd just like us to make sure that we actually think about (and document)
> > what hooks will fall into this, and make sure that it always makes sense
> to
> > rebuild the world on every possible hook (which is how charm writers
> will be
> > implementing default-hook, IMO).
> >
> > John
> > =:->
> >
> >
> >
> > On Sat, Aug 16, 2014 at 1:02 AM, Aaron Bentley <
> aaron.bent...@canonical.com>
> > wrote:
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> On 14-08-15 04:36 PM,
