Re: Juju Actions - Use Cases
There are a slew of opportunities for Actions to step in here, and I've got a few use cases listed below: - HDFS file system operations in Big-Data scenarios - dump/warm cache on proxy services like Varnish - Ingest data-sources with any database (ex: load twitter hash-tag data into ElasticSearch) - Rebuild indexes in MongoDB - Trigger deployment from source-control on framework based charms (Rails, NodeJS, CakePHP) - as an interesting aside, we are kind of brute forcing this with config... which it really appears that an action would be better suited to this task for things like, say, CI - Generating passwords post deployment for admin accounts instead of dumping a random pass in the logs or to /var/myservice/itsasecret.pwd - executing framework actions (eg: rake db:seed on rails) - Deploying additional demo assets in existing charms (see the demo.sh in the elasticsearch bundle) These are just a few to kick this conversation into gear as other's come into it and start brain bending around where their charm could benefit from an action. all the best, Charles On Wed, Sep 10, 2014 at 12:23 AM, Tim Penhey tim.pen...@canonical.com wrote: On 10/09/14 06:59, John Weldon wrote: Hi; We're looking for use cases for Juju Actions, mostly to make sure we expose the right API. I'm hoping for a few different use cases from the Juju Web UI folks, but I'd appreciate input from anyone wanting to use Juju Actions in their charms too. I've started a document with some example use cases to prime the pump: please contribute to this document and don't feel constrained to the style or layout I adopted for the examples. If you have any interest or investment in using or publishing Actions for Juju please review and contribute! Google Docs Link https://docs.google.com/document/d/1uYffkkGA1njQ1oego_h8BYBMrlGpmN_lwsnrOZFxE9Q/edit?usp=sharing I'd love to see explicit backup/restore actions for the postgresql charm. Tim -- 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: Juju Actions - Use Cases
On 10 September 2014 11:23, Tim Penhey tim.pen...@canonical.com wrote: On 10/09/14 06:59, John Weldon wrote: We're looking for use cases for Juju Actions, mostly to make sure we expose the right API. I'm hoping for a few different use cases from the Juju Web UI folks, but I'd appreciate input from anyone wanting to use Juju Actions in their charms too. I've started a document with some example use cases to prime the pump: please contribute to this document and don't feel constrained to the style or layout I adopted for the examples. If you have any interest or investment in using or publishing Actions for Juju please review and contribute! Google Docs Link https://docs.google.com/document/d/1uYffkkGA1njQ1oego_h8BYBMrlGpmN_lwsnrOZFxE9Q/edit?usp=sharing I'd love to see explicit backup/restore actions for the postgresql charm. For the PostgreSQL charm, off the top of my head: backup-start - May be a logical backup or filesystem level backup, so perhaps 2 actions - May take hours or days. - Scheduled in cron, in addition to on demand. - Should it return immediately, or emit status while the backup progresses? - Can backups be streamed back to the user? If not, the charm has to support many storage options. backup-cancel - Cancel a running backup - The charm might need to cancel a backup, eg. if failover has been triggered. backup-status - Status of running backups backup-recover - Destroy the master database, rebuilding using the backup - May take hours or days, multi-terrabyte databases are not uncommon. - Can the backup be streamed from the user? If not, the charm has to support many storage options. - If backup is filesystem level, optionally recover to a specific point in time. - Does not require location of backup, as default would be the automatic backups. - Only makes sense running on a unit in the master service if using cascading replica services - Recovery does not have to happen on the master unit in the master service. If recovery is done on a hot standby unit in the master service, that hot standby will be promoted to master when it completes. - Once recovery is complete, all hot standbys need to be rebuilt from the master failover - Promote a specific unit to be the master. rebuild - Rebuild a hot standby unit from the master unit. - This may rarely need to be done by an end user, eg. if a unit has desynchronized during an extended netsplit and the data required to catch up is no longer available. - More likely, this action will be invoked by the backup-recover action - Most likely, this action will be invoked by the peer-relation-joined and slave-relation-joined hooks, allowing the rebuild to be done asynchronously rather than the current situation where the hooks may take hours or days to complete. For the pgbouncer charm, matching the main pgbouncer actions: stop - Stop the pgbouncer daemon. - Big hammer if the 'disable, kill, pause, resume, enable' dance is not your style. start - Start the daemon. disable [db] - Disable new client connections to a given database kill [db] - Immediately drop all client and server connections on a given database. enable [db] - Reenable a database after a 'disable' pause [db] - Disconnect from a database, first waiting for queries to complete. resume [db] - Resume after a previous 'pause'. The storage and storage-subordinate charms could have some interesting use cases, although these might end up being swallowed by juju-core rather than become actions. At the moment the storage-subordinate informs the charm when the requested filesystem mount is ready, and it is the host charm's responsibility to shut down daemons, move datafiles to the new mount, and restart. If there were standard actions to stop and start the system, then the subordinate could do everything and the only burden placed on the host charm is advertising a patch that contains all of its data files. Perhaps these start/stop actions already exist in the form of the start/stop hooks. -- 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: Please don't use bash when there are syscalls available
Thanks for the clarification, I misunderstood what the code was doing. I'm glad to hear this code won't be needed for much longer, but I think we should backport your explicit check so that non-english users can use Juju. On Tue, Sep 9, 2014 at 6:56 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Wed, Sep 10, 2014 at 4:45 AM, Nate Finch nate.fi...@canonical.com wrote: A user just complained that he can't bootstrap because Juju is parsing stderr text from flock, and his server isn't in English, so the error message isn't matching. https://github.com/juju/juju/blob/master/environs/sshstorage/storage.go#L254 Now, I think we all know that parsing error text is a bad idea, but I think I understand why it was done - it looks like flock the application only returns 1 on this failure, so it's not exactly a unique error code. However, flock the system call returns several different error codes, which are quite unique and easy to handle in a way that is not dependent on the language of the machine. It also happens to be already implemented in the syscalls package: http://golang.org/pkg/syscall/#Flock So let's fix this, and try not to call out to bash unless there's absolutely no other way. This is running on a remote system before there is any code deployed. I won't say there's *no other way*, but you can't invoke syscalls from out of thin air. Finally, that error message check has nothing to do with flock. It's checking the result of I/O redirection to base64. Agreed that parsing the message is dumb. We can fix this with an explicit file existence check in the command executed ((test -e $path || echo blah2)||base64$path) or so. In the not too distant future, we will have no need for sshstorage at all (except in past, supported releases). -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
Re: Please don't use bash when there are syscalls available
On Wed, Sep 10, 2014 at 6:57 PM, Nate Finch nate.fi...@canonical.com wrote: Thanks for the clarification, I misunderstood what the code was doing. I'm glad to hear this code won't be needed for much longer, but I think we should backport your explicit check so that non-english users can use Juju. I have filed https://bugs.launchpad.net/juju-core/+bug/1367695, assigned to 1.20.8. On Tue, Sep 9, 2014 at 6:56 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Wed, Sep 10, 2014 at 4:45 AM, Nate Finch nate.fi...@canonical.com wrote: A user just complained that he can't bootstrap because Juju is parsing stderr text from flock, and his server isn't in English, so the error message isn't matching. https://github.com/juju/juju/blob/master/environs/sshstorage/storage.go#L254 Now, I think we all know that parsing error text is a bad idea, but I think I understand why it was done - it looks like flock the application only returns 1 on this failure, so it's not exactly a unique error code. However, flock the system call returns several different error codes, which are quite unique and easy to handle in a way that is not dependent on the language of the machine. It also happens to be already implemented in the syscalls package: http://golang.org/pkg/syscall/#Flock So let's fix this, and try not to call out to bash unless there's absolutely no other way. This is running on a remote system before there is any code deployed. I won't say there's *no other way*, but you can't invoke syscalls from out of thin air. Finally, that error message check has nothing to do with flock. It's checking the result of I/O redirection to base64. Agreed that parsing the message is dumb. We can fix this with an explicit file existence check in the command executed ((test -e $path || echo blah2)||base64$path) or so. In the not too distant future, we will have no need for sshstorage at all (except in past, supported releases). -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
Re: Juju Actions - Use Cases
On Tue, 09 Sep 2014, John Weldon wrote: Hi; We're looking for use cases for Juju Actions, mostly to make sure we expose the right API. I'm hoping for a few different use cases from the Juju Web UI folks, but I'd appreciate input from anyone wanting to use Juju Actions in their charms too. I've started a document with some example use cases to prime the pump: please contribute to this document and don't feel constrained to the style or layout I adopted for the examples. If you have any interest or investment in using or publishing Actions for Juju please review and contribute! Google Docs Link https://docs.google.com/document/d/1uYffkkGA1njQ1oego_h8BYBMrlGpmN_lwsnrOZFxE9Q/edit?usp=sharing I think most of the use cases presented so far line up with ours. One I want to call out as interesting and I hadn't thought about is killing a long running action in progress. The example of a database backup. I don't see anything along those lines in the current api doc. You can cancel something from the queue, but can you cancel something running. The matching side of that is getting feedback on the currently running action. Is there a way for scripts to provide any sort of data to help users checking the status know it's still moving forward and not stuck? Our list put together by Uros includes: - mongodb - backup start - backup cancel - backup status - backup restore - clean-old-backups - juju charmstore - elasticsearch sync - elasticsearch rebuild index - export blobs - clean blobstore (data integrity check) - long running healthcheck - elasticsearch - rebuild index - debug query pass through - jenkins - reset admin password - upgrade (apt-get upgrade from ppa) -- 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: Juju Actions - Use Cases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-09-10 02:56 AM, Charles Butler wrote: o as an interesting aside, we are kind of brute forcing this with config... which it really appears that an action would be better suited to this task for things like, say, CI We would never use actions for this. We want our sites to be reproducible, so we want the revision to be specified in the config. This would be especially true if we were using multiple units. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUEHVOAAoJEK84cMOcf+9h5ekH/juAFKg9G2JbySBqCMq0Gtzx GIOEN1rNa/LDWNqmwicYrudnCg/GPiiUmVAXxDqdpq0gidvO6TJBLU4XwUwFDxP6 gY5aWMmCunbknxtIaEEPnqCpJWaywZ1i17sS8qjk3q0v5cE8dU8My/zAfBFHU/Zk o66I+4fjxjiwIAlJJj3lQjmQOOUtgnAQR0EkT0AaO1wknjuH+dnVmhUNtxHzzBcb AcO/EcfCg2TguwONaC6GNLjs+fgwYc+WIE9KtaTkKbdCPPd29aWm1kF5CQDoY7UE WqlJb7lu6AlDWPfRzdkyN8OR7odHnJcIj83PkBwoRNqClIFxARHfJprN8xNiD+8= =blKd -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: Juju Actions - Use Cases
On 10 September 2014 19:49, Richard Harding rick.hard...@canonical.com wrote: I think most of the use cases presented so far line up with ours. One I want to call out as interesting and I hadn't thought about is killing a long running action in progress. The example of a database backup. I don't see anything along those lines in the current api doc. You can cancel something from the queue, but can you cancel something running. I don't think this one impacts the design. The cancel action can kill the process being run by the backup action easily enough, and that still meets my use case. Oh... I'll add one more to the list while I'm here reset-secrets - Causes all generated passwords and secrets to be regenerated. - Likely will cause a micro outage as clients will get disconnected, so it is on demand rather that done automatically every few hours. -- 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: Juju Actions - Use Cases
On Wed, 10 Sep 2014, Stuart Bishop wrote: On 10 September 2014 19:49, Richard Harding rick.hard...@canonical.com wrote: I think most of the use cases presented so far line up with ours. One I want to call out as interesting and I hadn't thought about is killing a long running action in progress. The example of a database backup. I don't see anything along those lines in the current api doc. You can cancel something from the queue, but can you cancel something running. I don't think this one impacts the design. The cancel action can kill the process being run by the backup action easily enough, and that still meets my use case. Right, but my understanding is that actions are a single queue. If you want to cancel something in progress you need to jump outside of the queue to do that. -- 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: Juju Actions - Use Cases
There's nothing that says the hook cannot call config to make it reproduce-able - but it also doesn't necessarily have to be forced through config either - these were pointed out as seed ideas i've heard and germinated in terms of uses for actions. But point acknowledge that it wouldn't work for your use case. On Wed, Sep 10, 2014 at 11:59 AM, Aaron Bentley aaron.bent...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-09-10 02:56 AM, Charles Butler wrote: o as an interesting aside, we are kind of brute forcing this with config... which it really appears that an action would be better suited to this task for things like, say, CI We would never use actions for this. We want our sites to be reproducible, so we want the revision to be specified in the config. This would be especially true if we were using multiple units. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUEHVOAAoJEK84cMOcf+9h5ekH/juAFKg9G2JbySBqCMq0Gtzx GIOEN1rNa/LDWNqmwicYrudnCg/GPiiUmVAXxDqdpq0gidvO6TJBLU4XwUwFDxP6 gY5aWMmCunbknxtIaEEPnqCpJWaywZ1i17sS8qjk3q0v5cE8dU8My/zAfBFHU/Zk o66I+4fjxjiwIAlJJj3lQjmQOOUtgnAQR0EkT0AaO1wknjuH+dnVmhUNtxHzzBcb AcO/EcfCg2TguwONaC6GNLjs+fgwYc+WIE9KtaTkKbdCPPd29aWm1kF5CQDoY7UE WqlJb7lu6AlDWPfRzdkyN8OR7odHnJcIj83PkBwoRNqClIFxARHfJprN8xNiD+8= =blKd -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: Juju Actions - Use Cases
On Wed, Sep 10, 2014 at 9:21 AM, Jeff Pihach jeff.pih...@canonical.com wrote: The interesting part of these interactions vs the ones I've seen mentioned is that they are client side actions. They would open a new tab or the browser to display the page in question vs simply executing some backend script. This does sound interesting - some way of coordinating activity on the client of the API and on the Unit while it's performing the Action. ISTM that features like this, for example OAuth token exchange, have historically required multi-phase steps, where the client initiates a request, the server responds with instructions to complete a third party step, the client performs the step and then submits another request with the resulting token, and maybe some other token to tie the second request to the first one? I'd love some ideas on how to best integrate this into an API for actions. Thanks! -- John Weldon -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Juju Actions - Use Cases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-09-10 01:29 PM, Charles Butler wrote: There's nothing that says the hook cannot call config to make it reproduce-able But if it's a config variable, then config-changed needs to be able to handle changes to it. If config-changed can handle it, then you don't need an action. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUEI0+AAoJEK84cMOcf+9hVIsH/0sFpC4hpnTEFMBfi20tMqaI JUgvhIUIczzb3tq8wYWhzJ4ivmiSWZPCP1VBrfjSOPIu01KjqHlnp64AGLP0xuXD tchUws3xhQxNkh8kP68aUMUUa2SWNwlPsb5HIvYmzztHvcd7nZ0oY51tU3K4vmNa US36fxbt9brNeNyf9rma8o0ftXsuuZ+6zVzVW03nmTxTikgInvr0jC5QegL+LKY+ HxDbpAvplha/RNgGXq2aRq0QMsmD7ea57n323ayQRs3dKqTCxxQ94dvGmLzYwEUG Ff2fhQoqO23EQNcYR643Ndi53AdyiHsWRgMxIoWeA+qSKkBjjBheeGUKStiDdEg= =8TV7 -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: Juju Actions - Use Cases
On Tue, Sep 9, 2014 at 11:59 AM, John Weldon johnweld...@gmail.com wrote: If you have any interest or investment in using or publishing Actions for Juju please review and contribute! I'm very thankful for all the discussion so far. I'll try to capture all of the suggestions here in the referenced doc, but feel free to update the doc yourselves too. Cheers -- John Weldon -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
juju charm-sync and Windows?
How much do we care about charm development on Windows (both windows charms and development on windows machines)? The reason I ask is that Horacio is starting on the charm-sync task from the pain points spreadsheet (syncing the charm files local - unit during charm development debugging). Obviously if we can just use scp, it's fairly trivial, but Windows servers don't ship with an SSH server enabled by default and Windows clients don't have scp. Go has a robust SSH server https://godoc.org/code.google.com/p/go.crypto/ssh that we could easily run on a Windows machine, but obviously that's more work than just using the built-in stuff on Linux. So, how much time and effort do we want to spend to support Windows? My ideal would be feature parity on Windows. I know in my years as a Windows developer, I always felt really annoyed that Windows was constantly a second class citizen. And I know there are a *ton *of enterprise customers that only deal with Windows, who would love to be able to deploy their stuff with the ease Juju provides. -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: ReviewBoard and our workflow
Thanks Eric! I've used Reviewboard at a previous job and I'm fairly sure that it aligns better with the way the Juju Core team likes to work than Github's review features. Two questions: 1. Is this what we're supposed to be doing from right now? 2. I'm pretty sure some configuration of the rbt tool is required so that it knows how to talk to the Reviewboard server. Is there a config file available? On 11 September 2014 03:58, Eric Snow eric.s...@canonical.com wrote: Steps for a review of a PR: 1. create pull request in github 2. run rbt post while at your branch to create a review request [1][2] 3. open the review request in your browser and publish it [3] 4. add a comment to the PR with a link to the review request 5. address reviews until you get a Ship It! 6. add a $$merge$$ comment to the PR Both github and ReviewBoard support various triggers/hooks and both have robust HTTP APIs. So we should be able to automate those steps (e.g. PR - review request, ship it - $$merge$$). However, I don't see that automation as a prerequisite for switching over to ReviewBoard. Updating an existing review request: 1. run rbt post -u (or the explicit rbt post -r #) 2. open the review request in your browser and publish it [3] FYI, Reviewboard supports chaining review requests. Run rbt post --parent parent branch. I'll be updating the contributing doc relative to ReviewBoard (i.e. with the above info) once we settle in with the new tool. -eric [1] Make sure your branch is based on upstream master. Otherwise this will not work right. [2] Reviewboard links revision IDs to review requests. So if you already have a review request for a particular revision (e.g. your branch), then rbt post will fail. Use rbt post -u or rbt post -r # instead. [3] rbt post has some options you should consider using: - automatically publish the review request: rbt post --publish (or -p) - open a browser window with the new review request: rbt post --open (or -o) -- 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: ReviewBoard and our workflow
On Wed, Sep 10, 2014 at 3:34 PM, Menno Smits menno.sm...@canonical.com wrote: Thanks Eric! I've used Reviewboard at a previous job and I'm fairly sure that it aligns better with the way the Juju Core team likes to work than Github's review features. Two questions: 1. Is this what we're supposed to be doing from right now? Nope. I'm hopeful that we will switch over to reviewboard in a week or two. Until then github is still our review tool. However, in the meantime feel free to try out the Reviewboard-oriented workflow as well. :) 2. I'm pretty sure some configuration of the rbt tool is required so that it knows how to talk to the Reviewboard server. Is there a config file available? The first time in a repo you run rbt setup-repo which generates a user-agnostic, repo-specific .reviewboardrc file. I expect that before long we will commit that file in each of our repos. Once that happens, no one will have to do anything special (e.g. run rbt setup-repo) any longer. See https://www.reviewboard.org/docs/rbtools/dev/rbt/configuration/ -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Juju Actions - Use Cases
On Thu, Sep 11, 2014 at 3:41 AM, Aaron Bentley aaron.bent...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-09-10 01:29 PM, Charles Butler wrote: There's nothing that says the hook cannot call config to make it reproduce-able But if it's a config variable, then config-changed needs to be able to handle changes to it. If config-changed can handle it, then you don't need an action. True that you don't need it, but it still may have a benefit. We have a config variable, build_label, which when set to r255 it will (1) download r255/my-tarball.tgz from a swift container, (2) extract it in right directory, (3) set the perms correctly, and then (4) finally switches the symlink and restarts. But we've also got a preload action that Simon recently added, which enables our charms to do 1, 2 and 3 on all the units, so that when the config is changed to build_label=r255, any unit which was already preloaded will just switch the symlink and restart. So it's reproducible (ie. will still work fine if you preload, then add 2 units, then set the build_label), but is a little faster and more importantly, allows us to reduce what's happening at the actual rollout time to symlink+restart. -Michael Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUEI0+AAoJEK84cMOcf+9hVIsH/0sFpC4hpnTEFMBfi20tMqaI JUgvhIUIczzb3tq8wYWhzJ4ivmiSWZPCP1VBrfjSOPIu01KjqHlnp64AGLP0xuXD tchUws3xhQxNkh8kP68aUMUUa2SWNwlPsb5HIvYmzztHvcd7nZ0oY51tU3K4vmNa US36fxbt9brNeNyf9rma8o0ftXsuuZ+6zVzVW03nmTxTikgInvr0jC5QegL+LKY+ HxDbpAvplha/RNgGXq2aRq0QMsmD7ea57n323ayQRs3dKqTCxxQ94dvGmLzYwEUG Ff2fhQoqO23EQNcYR643Ndi53AdyiHsWRgMxIoWeA+qSKkBjjBheeGUKStiDdEg= =8TV7 -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
All reviews should be on reviewboard as of now.
http://reviews.vapour.ws/ Check your email for eric's step by step directions. It's not hard. Existing pull requests should be finished up on github, but from now on, all new pull requests should have reviews done on reviewboard. -Nate Tim Ian -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: All reviews should be on reviewboard as of now.
Easy Tiger. Let's check that it's all properly set up first. EDIT: As I was typing this, just saw Eric's email. Let's get everything nailed down and aim for Monday next week. On 11/09/14 12:21, Nate Finch wrote: http://reviews.vapour.ws/ Check your email for eric's step by step directions. It's not hard. Existing pull requests should be finished up on github, but from now on, all new pull requests should have reviews done on reviewboard. -Nate Tim Ian -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Fixed reviewer schedule
Hi folks, Those of you who are reviewers should now have invites to your bi-weekly review time. This now occurs on the same day every two weeks. I have tried to have the mentors on the day after the mentees (or overlapping). Also tried to spread out the different timezones. It will never be perfect, but hopefully this is better now. Cheers, Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Testing api clients
Hi folks, I'd like to bring a small, recent addition to everyone's attention: https://github.com/juju/juju/blob/master/api/base/testing/patch.go PatchFacadeCaller can be used (and is used now in several places) to avoid calling through to a real API server in api tests. Ideally we'd just provide mock FacadeCallers to begin with, but this alleviates some of the pain between now and when we do that across all the existing tests. If you're writing tests for api clients, please consider using PatchFacadeCaller or a mock FacadeCaller, so we can improve test coverage and avoid slow tests. Cheers, Andrew -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: State should not depend on the API server
... I have thought for a while that, rather than writing more error-prone code (at 17k LOC, surely the API code is big enough as it is?), it would be good to create a tool that helps us with the underlying problem - incompatible changes made to marshaled types. This would not be too hard - the Go language already has such a tool (see http://golang.org/cmd/api/ ), although it is not currently generally applicable. This could make it possible to provide a much stronger assurance about compatibility, including compatibility between types not defined inside juju-core itself, while keeping the code natural and simple. cheers, rog. So that is interesting, and it might be fruitful to explore. I'll just note that it is actually a pretty small (and reasonably obvious) part of API compatibility. It *doesn't* tell you 1) If passing an empty string suddenly has a different meaning (see Client.ServiceSet where we used to treat as meaning reset-to-default vs Client.NewServiceSetForAPI where we wanted to actually treat as meaning set this value to the empty string.) 2) Returning a new value (Machine.Jobs(), we want to add new Jobs for new behaviors and don't want to confuse old agents until they have finished upgrading). So while something like the above could tell you has the shape of the API changed, and what I really like about it is that if it had a collapsed view (like a simple text representation), it is easy to keep that around in the source tree and use it for reference. However, you really do need tests for (1) and (2). (1) we actually broke accidentally because we changed the code inside of state/*, and then had to go back and retrofit the API to use a new code path to preserve compatibility. And if you need tests, you really still need 2 types to represent the different versions, and if you already need those types, then I would recommend having a regular structure for them. John =:- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
