juju relation status
Hi, Does anyone knows how to determine when a relation is establish (when the relation joined or relation changed hooks ended) ? The goal would be to be able to synchronously run the juju add-relation command. Thanks, Tudor -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: juju relation status
On 22/08/14 13:35, Tudor Rogoz wrote: Does anyone knows how to determine when a relation is establish (when the relation joined or relation changed hooks ended) ? The goal would be to be able to synchronously run the juju add-relation command. Hi Tudor, we'll add an explicit feedback mechanism in the next major release of Juju that gives you this (the charm will tell Juju). For now, it's a bit of wait-and-try-and-wait. Mark -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: juju relation status
Charm-helpers uses a trick for this, which is to check if the private-address key was set on the relation. You can have a better look here: https://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/core/hookenv.py#L393 Hope this helps :) - Chris On Fri, Aug 22, 2014 at 3:35 PM, Tudor Rogoz ro...@adobe.com wrote: Hi, Does anyone knows how to determine when a relation is establish (when the relation joined or relation changed hooks ended) ? The goal would be to be able to synchronously run the “juju add-relation” command. Thanks, Tudor -- 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
We need a process to unpromulgate charms.
Hello, The Juju Ecosystem team is working on charm testing and it occurred to us that we need a process for unpromulgation of charms. Charles Butler came up with the process for when charms are broken or no longer supported. That document can be found here: https://docs.google.com/a/canonical.com/document/d/1k8IBaLmOTpgOJQHv54BAnRfQLiC4hQ35lAm_3prlHwA/edit What I would like to discuss here is: When a charm is no longer needed. For example the tomcat6 and tomcat7 charms are completely superseded by the new tomcat charm. We want to unpromulgate them so Juju users use the new tomcat charm. The question I bring to you today is: *What should the process be when we unpromulgate a charm?* I see a few options: 1) Unpromulgate the charm and keep it in the ~charmers branch in launchpad. 2) Unpromulgate the charm and move it to another personal name space (something like ~unmaintained). 3 Unpromulgate the charm and delete the branch? There are problems with each approach and therefore I wanted to present this to the community. The problem with #1 is that the ~charmers branch is our official branch and I am not sure we want to keep unmaintained charms in there when they are no longer maintained or the charm is no longer not recommended. Please let us know what your opinion and reasoning is for what to do with unpromulgated charms. Thank you for your time, - Matt Bruzek matthew.bru...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
[Review Queue] RSyslog, Rsyslog-Forwarder-HA, NRPE-External-Master, Transcode-Cluster
Today I reviewed a few charms: NRPE-External-master - which was a merge request to land some features against the charm relating to conntrack integration. I was a bit disappointed with the status of the documentation of the NRPE-External-Master charm as a whole and superimposed a blocker pending a doc update for the proposed feature. Otherwise the code quality was good and appears to have been deployed successfully - but I didn't know what to do with the new config options so validation was tough. https://code.launchpad.net/~chris-gondolin/charms/precise/nrpe-external-master/trunk/+merge/227530 Rsyslog - Rsyslog was a request for promotion to trusty from the precise series. As some of you may know that our policy has become stricter on ~charmer recommended charms in the trusty series with a focus on tests (which rsyslog has!). However the charm needs a bit of house keeping before it can be accepted but is very close to being ready for trusty inclusion. Lets give Jorge Niedbalski a quick hi5 for stepping up to take over this charms maintainership. https://bugs.launchpad.net/charms/+source/rsyslog/+bug/1355987 https://bugs.launchpad.net/charms/+source/rsyslog/+bug/1355987rsyslog-forwarder-ha Rsyslog-Forwarder-HA - see: rsyslog. The forwarder-ha charm has passed my trusty audit, and when the precise charm is forked as a trusty series and deployed - things work out of the box. I'm promoting this to trusty and the rsyslog charm will be following soon (niedbalski is a very responsive charmer) https://bugs.launchpad.net/charms/+source/rsyslog-forwarder-ha/+bug/1355988 Transcode-Cluster: This bundle works a treat - It has a reference to a personal namespace charm, which would need to be updated. However it does not pass bundle proof - and this may speak to an issue in our tooling as this supports MAAS tagging, but our linting tool does not: W: transcode: charm URL should include a revision W: transcode: charm URL should include a revision E: orange-box/nfs: unsupported constraints: tags E: orange-box/transcode: unsupported constraints: tags I'm leaving a comment about this, and referencing the charm should be updated for the store once it is promulgated and moving on a conversation with bug reported against charm-tools. https://bugs.launchpad.net/charm-tools/+bug/1360374 All the best, Charles -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: First customer pain point pull request - default-hook
On 22 August 2014 10:43, Marco Ceppi marco.ce...@canonical.com wrote: So there is already a JUJU_HOOK_NAME environment variable. So that is easy enough. I'm not sure what the issue is with having a default-hook file that is executed when juju can't find that hook name. I don't want to make it an all or nothing solution where you either have one file or hooks per file, there doesn't seem to be any real advantage to that. For example my default - hook might be written in a language not on the cloud image, now I need an install hook which installs that interpreter. Looking at the charms I am writing now, I have install, start, stop and do-everything-else. peer relation-broken is possibly the other one that will need to be special, to ensure a unit being destroyed doesn't stomp on active resources being used by the remaining peers. I'm a plus one to a fall back of default-hook when hook isn't found and a +1 to the already existent environment variable. I'm +0. The symlinks are a dead chicken that needs to be sacrificed, but it is all explicit. I can imagine problems with default-hook too, such as a typo causing your default-hook to be called instead of your desired hook. -- Stuart Bishop stuart.bis...@canonical.com -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: changing the simplestreams filename format
Hi Andrew,
The juju-metadata command generates simplestreams files to be used in private
clouds for example. Both:
juju-metadata generate-tools
and
juju-metadata generate-image
will output files containing :.
We also care during testing, when the tests use local storage to save the
metadata files. A quick snippet of a failing test bellow:
simplestreams_test.go:372:
s.assertWriteMetadata(c, false)
testing/testing.go:108:
c.Assert(err, gc.IsNil)
... value *os.LinkError = os.LinkError{Op:replace,
Old:C:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\1\\gocheck-89438594918
3117216\\0\\.tmp\\juju-filestorage-736520790,
New:C:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\1\\gocheck-894385949183117216
\\0\\tools\\streams\\v1\\com.ubuntu.juju:released:tools.json, Err:0x7b}
(replace C:\\Users\\ADMINI~1\\AppData\\Local\\Temp
\\1\\gocheck-894385949183117216\\0\\.tmp\\juju-filestorage-736520790
C:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\1\\gocheck-8
94385949183117216\\0\\tools\\streams\\v1\\com.ubuntu.juju:released:tools.json:
The filename, directory name, or volume label syntax is incorrect.)
Regards,
Gabriel
On 22.08.2014 04:54, Andrew Wilkins wrote:
On Fri, Aug 22, 2014 at 4:37 AM, Nate Finch
nate.fi...@canonical.commailto:nate.fi...@canonical.com wrote:
Simplestreams generates files with names like this:
http://maas.ubuntu.com/images/ephemeral-v2/daily/streams/v1/com.ubuntu.maas:daily:v2:download.sjson
Unfortunately, the colons in the filename are illegal on Windows, which
complicates getting tests running on Juju, and getting a fully-functional juju
on Windows.
Dumb question: when/where do we care? A URL is not a filesystem path, and we
don't store simplestreams metadata on disk other than in provider storage as
far as I'm aware. Provider storage is only on-disk for manual/local bootstrap
nodes (for now).
I brought this up with Scott Moser, and it sounds like it might not be the end
of the world to change the delimiter that is used to be something
Windows-friendly.
I wanted to bring this up on juju-dev in case there are juju-specific concerns
about the proposed change to the filenames.
I'm new to simplestreams, so I'm sure there are nuances I don't understand,
which is why I'm posting it here.
-Nate
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.commailto: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: changing the simplestreams filename format
On Fri, Aug 22, 2014 at 5:36 PM, Gabriel Samfira
gsamf...@cloudbasesolutions.com wrote:
Hi Andrew,
The juju-metadata command generates simplestreams files to be used in
private clouds for example. Both:
juju-metadata generate-tools
and
juju-metadata generate-image
will output files containing :.
Ah yes, I forgot about those tools.
We also care during testing, when the tests use local storage to save the
metadata files. A quick snippet of a failing test bellow:
simplestreams_test.go:372:
s.assertWriteMetadata(c, false)
testing/testing.go:108:
c.Assert(err, gc.IsNil)
... value *os.LinkError = os.LinkError{Op:replace,
Old:C:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\1\\gocheck-89438594918
3117216\\0\\.tmp\\juju-filestorage-736520790,
New:C:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\1\\gocheck-894385949183117216
\\0\\tools\\streams\\v1\\com.ubuntu.juju:released:tools.json, Err:0x7b}
(replace C:\\Users\\ADMINI~1\\AppData\\Local\\Temp
\\1\\gocheck-894385949183117216\\0\\.tmp\\juju-filestorage-736520790
C:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\1\\gocheck-8
94385949183117216\\0\\tools\\streams\\v1\\
*com.ubuntu.juju:released:tools.json*: *The filename, directory name, or
volume label** syntax is incorrect.*)
OK. Still, we control those filenames: they don't *have* to be the same as
what simplestreams specifies, though it may be a PITA to try to work around
it.
Regards,
Gabriel
On 22.08.2014 04:54, Andrew Wilkins wrote:
On Fri, Aug 22, 2014 at 4:37 AM, Nate Finch nate.fi...@canonical.com
wrote:
Simplestreams generates files with names like this:
http://maas.ubuntu.com/images/ephemeral-v2/daily/streams/v1/com.ubuntu.maas:daily:v2:download.sjson
Unfortunately, the colons in the filename are illegal on Windows, which
complicates getting tests running on Juju, and getting a fully-functional
juju on Windows.
Dumb question: when/where do we care? A URL is not a filesystem path,
and we don't store simplestreams metadata on disk other than in provider
storage as far as I'm aware. Provider storage is only on-disk for
manual/local bootstrap nodes (for now).
I brought this up with Scott Moser, and it sounds like it might not be
the end of the world to change the delimiter that is used to be something
Windows-friendly.
I wanted to bring this up on juju-dev in case there are juju-specific
concerns about the proposed change to the filenames.
I'm new to simplestreams, so I'm sure there are nuances I don't
understand, which is why I'm posting it here.
-Nate
--
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
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Triggering Server Restarts
On Fri, Aug 22, 2014 at 11:57 AM, John Meinel j...@arbash-meinel.com wrote: Horacio had an interesting question on IRC and I wanted to bring it up to more people to get input. Specifically, juju restore has some properties that are pretty similar to juju upgrade-juju in that we really want the API server to restart after the action has completed. In the case of upgrade-juju the command only schedules an upgrade, and the actual upgrade happens asynchronously. When it completes, the worker/Upgrader raises UpgradeReadyError which is special cased at the top level Runner to realize this is a die and restart sort of error. I think Horacio is desiging juju restore to be a bit more synchronous. So rather than have a worker/Restorer running in the background, noticing that a restore needs to be done and triggering it, he has the API call itself do the work. I think this is sensible for restore as it has been written. I think the problem is that to trigger a restart, the worker itself (in this case APIServer) should be raising the error, which isn't really accessible in the context of the API call. (you want the API call to return successfully, an 'error' in this context is handed to the user, not up the Worker stack.) And the state/apiserver/client.Client object just has a direct reference to State, it doesn't have a reference to state/apiserver.Server to be able to trigger that sort of error in the apiserver.Server.tomb object. Is there something wrong with giving Client a reference to the tomb? It needs *something*, so I don't see why not that, which would be the least amount of work. One possibility might be to have a worker/Restarter that watches for something (listens on a channel, something), and then triggers an exit with an error like UpgradeReadyError. My personal thought on how juju restore should work, is that it wouldn't actually be an API call, but instead of doing all the steps of juju bootstrap it would do all of them except the final jujud bootstrap-state, and substitute in a jujud restore-state. So we would still have everything running the restoration from server-side code, but we would be triggering it before we have created a running state server. This would have been more of a problem when we were triggering jujud bootstrap-state from cloud-init, but I'm pretty sure we are just directly sshing in and doing the work ourselves now. I guess it depends if this is an API we *ever* want to trigger at any other time than just at the beginning. Maybe we want to have the API so you call rollback even if it has been running for a while? John =:- -- 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
Is there a root cause to a cluster of certificate bugs?
We are seeing several reports of cannot validate certificate problem. Are some of these bugs duplicates? Are these bugs caused by a common issue we can fix? generate certificates with valid time one week in past https://bugs.launchpad.net/juju-core/+bug/1352944 bootstrap failed, x509: cannot validate certificate https://bugs.launchpad.net/juju-core/+bug/1360076 Error during bootstrap: TLS handshake failed: x509: certificate signed by unknown authority https://bugs.launchpad.net/juju-core/+bug/1355782 ERROR state: TLS handshake failed: x509: certificate signed by unknown authority https://bugs.launchpad.net/juju-core/+bug/1178312 This thread was interesting, though might be common knowledge for go developers https://github.com/elasticsearch/logstash-forwarder/issues/221 -- 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: changing the simplestreams filename format
The metadata file name is arbitrary, though it follows a convention published by other tools we do not control. Looking at https://streams.canonical.com/juju/tools/streams/v1/index.json The path is just a relative location on disk to load.The content of that file doesn't need to change.We have 100% control juju tool steams image stream is only under our control for private clouds created with our metadata plugin. We cannot change the names at http://cloud-images.ubuntu.com/releases/streams/v1/index.json because there are other users of this data. I think the sync-tools command is safe because it only works with tool. Anything syncing images on windows will need to recreate the metadaya...or we escape the colons on windows machines. Do we have some support for this already? I can see names are escaped in the env's control-bucket. -- 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
