Re: Send Juju logs to different database?
On 7 May 2015 at 00:58, Charles Butler wrote: > > On Wed, May 6, 2015 at 3:53 AM, Stuart Bishop > wrote: > >> My own use case would be to make a more readable debug-logs, rather >> than attempting to parse the debug-logs output ;) Hmm... I may be able >> to do this already via the Juju API. >> > > Personally - i feel like this is a *great* use case for an opengrok filter > w/ logstash. Translate that structured data into something meaningful in > elasticsearch and search/aggregate/tail like a champ. > Agreed - that would be awesome. When we get to this we should aim to have Juju emit structured log data that could be used to feed things like logstash. If we do it right then hopefully grok won't be needed because the log data will already be structured. No promises about when this might happen though. At least the logging work currently being done provides a good basis to add logging to external systems. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Send Juju logs to different database?
On 6 May 2015 at 19:53, Stuart Bishop wrote: > On 6 May 2015 at 04:57, Menno Smits wrote: > > > It is more likely that Juju will grow the ability to send logs to > external > > log services using the syslog protocol (and perhaps others). You could > use > > this to log to your own log aggregator or database. This feature has been > > discussed but hasn't been planned in any detail yet (pull requests would > be > > most welcome!). > > syslog seems a bad fit, as the logs are now structured data and I'd > like to keep it that way. I guess people want it as an option, but I'd > consider it the legacy option here. > You're right. Structured logs would be much more useful. > My own use case would be to make a more readable debug-logs, rather > than attempting to parse the debug-logs output ;) Hmm... I may be able > to do this already via the Juju API. > Not yet. The API used by debug-log currently emits formatted log lines, not structured log data. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Fwd: juju 1.24.alpha1
Copying to juju-dev as this info is generally useful. Hey Thanks for the feedback. The status YAML output will *always* be available, but when Juju 2.0 ships, will no longer be the default. That will be tabular which is much more human readable. So as of Juju 2.0, whenever that ships, instead of "juju status" you type "juju status --format yaml" To aide people to transition their scripts before hand, you can enable the 2.0 CLI behaviour early: export JUJU_CLI_VERSION=2 juju status The 2.0 compatibility feature as of now just applies to status but we may adapt other commands to use it also as needed. The whole idea here is to retain backwards compatibility but allow improved features to be exposed to those folks who want to use them early. Note: even in the current Juju, with status you can start transitioning scripts. The "--format yaml" option works the same now as it will in 2.0 As well as the default format change, status in Juju 2.0 will omit the legacy status in favour of just printing the new improved workload and agent status. So I'd encourage using the 2.0 status output now to get the best benefit, assuming you have tweaked any scripts accordingly. On 07/05/15 02:00, Alexis Bruemmer wrote: > Hey Ian, Horacio, > > Wanted to make sure you guys saw Adam's comment on the 1.24 release (with > the service status feature). > > > -- Forwarded message -- > > Looks awesome! Though one thing that may cause a lot of problems: > > The 'status' command will use a table layout in the future > > There could possibly be a lot of people affected by this who pulling in the > yaml output in their applications rather than rely on the api. > > On Wed, May 6, 2015 at 5:31 PM, Curtis Hovey-Canonical > wrote: > >> Thank you for testing Juju. >> >> We have a new devel release that introduces new features that you >> might be interested in and fixes several bugs reported by >> stakeholders. Notable changes include: >> >> * Service status >> * storage (experimental) >> >> You can see the full release notes at. >> https://launchpad.net/juju-core/+milestone/1.24-alpha1 >> >> We are striving to release 2 betas every week this month to get fixes >> to stakholders quickly. >> >> >> >> -- >> 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
Juju 1.24-alpha1 is released for testing
# juju-core 1.24-alpha1 A new development release of Juju, juju-core 1.24-alpha1, is now available. ## Getting Juju juju-core 1.24-alpha1 is available for vivid and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/devel Windows and OS X users will find installers at: https://launchpad.net/juju-core/+milestone/1.24-alpha1 Development releases use the "devel" simple-streams. You must configure the `agent-stream` option in your environments.yaml to use the matching juju agents. Upgrading from stable releases to development releases is not supported. You can upgrade test environments to development releases to test new features and fixes, but it is not advised to upgrade production environments to 1.24-alpha1. ## Notable Changes * Service status * storage (experimental) ### Service status Juju provides new hooks for charm authors to report service status, and 'juju status' now includes the service status. This new functionality allows charms to explicitly inform Juju of their status, rather than Juju guessing. Charm authors have access to 2 new hook tools, and the status report includes more information. The 'status-set' hook tool allows a charm to report its status to Juju. This is known as the workload status and is meant to reflect the state of the software deployed by the chrm. Charm authors are responsible for setting the workload's status to "Active" when the charm is ready to run its workload, and "Blocked" when it needs user intervention to resolve a problem. status-set: status-set "message" The 'status-get' hook tool allows a charm to query the current workload status recorded in Juju. Without arguments, it just prints the workload status value eg maintenance. With '--include-data' specified, it prints YAML which contains the status value plus any data associated with the status. status-get: status-get [--include-data] Charms that do not make use of these hook tools will still work as before, but Juju will not provide details about the workload status. The 'juju status' command includes the 'workload-status' and 'service-status' in the report. for example: services: ... wordpress: charm: local:trusty/wordpress-93 exposed: false service-status:<-- new service status current: blocked message: Waiting for database since: 01 May 2015 17:39:38 AEST relations: loadbalancer: - wordpress units: wordpress/0: workload-status:<-- new workload status current: blocked message: Waiting for database since: 01 May 2015 17:39:38 AEST agent-status: <-- new agent status current: idle since: 01 May 2015 17:39:44 AEST version: 1.24-alpha1.1 agent-state: started<-- legacy Juju agent state agent-version: 1.24-alpha1.1 machine: "1" open-ports: - 80/tcp public-address: 23.20.250.14 Juju aggregates all the unit 'workload-status' values to represent the 'service-status'. The 'service-status' value is derived from the worst case status of all the units; eg, if any unit is in error, then the service is in error. The 'status' command will use a table layout in the future, and you can set the environmental variable 'JUJU_CLI_VERSION' to "2" to see it like so: export JUJU_CLI_VERSION=2 juju status NAME STATUS EXPOSED CHARM mysql unknown false local:trusty/mysql-326 wordpress blocked false local:trusty/wordpress-93 The legacy status values are omitted from output. You can use the '--yaml' option to see status in the Juju 1.x layout. Juju also records a history of status changes for a unit, and tracks the time when the status was last updated. The 'juju status-history' command allows you to inspect a charm's status changes over time juju status-history [options] [-n N] options: -e, --environment (= "") juju environment to operate in -n (= 20) size of logs backlog. --type (= "combined") type of statuses to be displayed [agent|workload|combined]. --utc (= false) display time as UTC in RFC3339 format This command will report the history of status changes for a given unit. The statuses for the unit workload and/or agent are available. -type supports: agent: will show statuses for the unit's agent workload: will show statuses for the unit's workload combined: will show agent and workload statuses combined and sorted by time of occurrence. For example, to see the history of the unit wordpress/0 juju status-history wordpress/0 TIME TYPE STATUS MESSAGE 01 May 2015 17:33:20 EST workload unknown Waiting for agent initialization
Re: Fix for LP: #1174610 landing (unit ids should be unique)
This has now landed - and at the moment only in master so it will be out in 1.25 On Mon, Apr 27, 2015 at 5:44 PM, Casey Marshall < casey.marsh...@canonical.com> wrote: > Just a friendly heads-up.. a fix for this longstanding bug will be > landing into master shortly: > > LP: #1174610, unit ids should be unique > > What this fix essentially does is assign each deployed workload a > distinct unit ID (incrementing sequentially) within the scope of an > environment. Example: > > 1. juju deploy mysql >Deployed workload gets an ID, mysql/0 > > 2. juju destroy-service mysql > > 3. juju deploy mysql >Deployed workload gets a distinct ID, mysql/1 > > I do not anticipate any negative impact to normal Juju usage from this > bugfix, but I'd like to raise awareness here proactively, in the event > that there is potential breakage in scripts that invoke juju with > hard-coded assumptions on how Juju assigns unit IDs -- instead of > retrieving actual assigned unit IDs from status. > > -Casey > > > -- > 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: Send Juju logs to different database?
On Wed, May 6, 2015 at 3:53 AM, Stuart Bishop wrote: > My own use case would be to make a more readable debug-logs, rather > than attempting to parse the debug-logs output ;) Hmm... I may be able > to do this already via the Juju API. > Personally - i feel like this is a *great* use case for an opengrok filter w/ logstash. Translate that structured data into something meaningful in elasticsearch and search/aggregate/tail like a champ. Charles Butler - Juju Charmer Come see the future of datacenter orchestration: http://jujucharms.com -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Send Juju logs to different database?
On 6 May 2015 at 04:57, Menno Smits wrote: > It is more likely that Juju will grow the ability to send logs to external > log services using the syslog protocol (and perhaps others). You could use > this to log to your own log aggregator or database. This feature has been > discussed but hasn't been planned in any detail yet (pull requests would be > most welcome!). syslog seems a bad fit, as the logs are now structured data and I'd like to keep it that way. I guess people want it as an option, but I'd consider it the legacy option here. My own use case would be to make a more readable debug-logs, rather than attempting to parse the debug-logs output ;) Hmm... I may be able to do this already via the Juju API. -- Stuart Bishop -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
