Re: The tests now run godeps
On 21 August 2014 03:47, Nate Finch nate.fi...@canonical.com wrote: We've figured out that using godeps to print dependencies fails if you've installed Go from the PPA rather than from source, so that's why we're getting different results (Tim Ian have the PPA, I have the source). I'm sorry this is the case. I have now pushed a change to godeps that should fix the problem. Please run go get -u launchpad.net/godeps to update. cheers, rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Fwd: The tests now run godeps
On 21 August 2014 03:47, Nate Finch nate.fi...@canonical.com wrote: We've figured out that using godeps to print dependencies fails if you've installed Go from the PPA rather than from source, so that's why we're getting different results (Tim Ian have the PPA, I have the source). I'm sorry this is the case. I have now pushed a change to godeps that should fix the problem. Please run go get -u launchpad.net/godeps to update. cheers, rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: The tests now run godeps
I have toyed with the idea of adding a git hook that runs godeps whenever I switch branches. I haven't gotten around to trying it out, but would that possibly be another helpful thing for developers to do? On Thu, Aug 21, 2014 at 5:14 AM, roger peppe roger.pe...@canonical.com wrote: On 21 August 2014 03:47, Nate Finch nate.fi...@canonical.com wrote: We've figured out that using godeps to print dependencies fails if you've installed Go from the PPA rather than from source, so that's why we're getting different results (Tim Ian have the PPA, I have the source). I'm sorry this is the case. I have now pushed a change to godeps that should fix the problem. Please run go get -u launchpad.net/godeps to update. cheers, rog. -- 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
changing the simplestreams filename format
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. 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
Re: changing the simplestreams filename format
Juju doesn't care whether there are colons or not. So any change made to what delimter is used can easily be accommodated. Juju would need to be modified to update its metadata generation plugins. Also, the internal content ids would need to remain the same (ie containing colons). On 22/08/14 06:37, Nate Finch 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. 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
Re: changing the simplestreams filename format
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
Triggering Server Restarts
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. 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
