Re: Juju 1.26-alpha3 moving to 2.0-alpha1
Good Morning Alexis, Just out of curiosity have you guys considered offering nightly builds via PPA. I think nightly builds would be good to get testing of new features as well as existing functionality to ensure no regressions could have potentially been introduced. --- Regards, Jonathan Aquilina Founder On 2015-12-04 22:06, Alexis Bruemmer wrote: > Hi All, > > Juju 2.0 has been a long time coming and we will see it release in April 2016 > with Ubuntu 16.04! Among many other improvements, the 2.0 release will have > a better bootstrap experience that leverages all the great work done around > multi-model solutions. Juju 2.0 bootstrapping will automatically create a > controller (previously known as a Juju State Server) with a hosted model > (previously known as an environment); the new behavior automatically provides > the user with a usable model and a clear path for adding more models to the > bootstrapped controller. This improvement however, changes the expected > functionality of the current 1.X bootstrap command. Our commitment to Juju > users on LTS releases states clearly that we do not break backwards > compatibility on point releases (including changing base expected behavior). > For this reason we will be dropping the 1.26.0 release and turning the > current 1.26-alpha3 into 2.0-alpha1. > > This is an update to our current release plans > (https://github.com/juju/juju/wiki/Juju-Release-Schedule) which has a 1.26.0 > release scheduled for January. Although this means waiting a little longer > for features, moving to a 2.0 enables the development team to deliver a > strong and correct 2.0 user experience. The Juju team will continue to > release alphas and betas on a regular cadence so that new features will be > available in the devel ppa (ppa:juju/devel). The first 2.0-alpha1 is > scheduled to release the week of December 7th. > > If you have any questions please do not hesitate to ask. > > Thanks! > Alexis > -- > > Alexis Bruemmer > Juju Core Manager, Canonical Ltd. > (503) 686-5018 > alexis.bruem...@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: Is ReviewBoard a good thing?
Hey guys. Long time lurker with the occasional suggestion. I have an idea for something that might be beneficial to the project as a whole. Has it been considered about custom coding a review system that will interface with github hooks and provide what is needed to all juju dev's and keep things rather mainstream as well so as not to increase the entry level requirements fore new contributors? --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-19 10:14, Frank Mueller wrote: Right now I'm a bit undecided, the usage of ReviewBoard is too fresh. But Jesse made good points and in general Im always happy when we're using less instead of using more tools. I can live with the number of mails, GMail does grouping them fine. And I started to add my comments after a first pass through a PR. My greatest weakness so far has been the missing side-by-side diff, thankfully GitHub addressed this. So I'm with Jesse and will go with the team if we decide to use ReviewBoard, but I prefer returning to a GitHub based process as it is know in many other communities too. mue On Fri, Sep 19, 2014 at 9:20 AM, roger peppe roger.pe...@canonical.com [9] wrote: On 19 September 2014 01:32, David Cheney david.che...@canonical.com [1] wrote: There were three problem reviewboard was supposed to address, review comments are sent immediately, no side by side diffs, and no way to to chained proposals. I think that over the last few months we've all learnt to live with the first issue On the second, github now does nice side by side diffs. On the third, it appears reviewboard leaves you solidly to your own devices to implement chained proposals. I'm with Jesse, I vote to stop using reviewboard, I don't think it's paying it's way. The main thing I was hoping to get from reviewboard that's a constant pain to me in github was the ability to look at new changes in the context of old comments, to see where and how those comments have been addressed. So, assuming reviewboard did address that issue, I'm a bit sad but I think Jesse makes a very good point about keeping things mainstream. I guess there's the potential for some third party tool to address my issue above. So I agree that it might be better to cut losses here and embrace github, even if it is awkward in some ways. cheers, rog. On Fri, Sep 19, 2014 at 10:19 AM, Jesse Meek jesse.m...@canonical.com [2] wrote: We moved to GitHub in the hope of lowering the bar to contributors outside the team. GitHub is *the* platform and process for open source software. This was the logic behind the move. It was deemed to have the most mindshare and we sacrificed our prefered platform and process to be part of that mindshare. We are now leaving that 'main stream' process to something that suits the tastes of our team - ReviewBoard. This adds friction for new contributors (friction everyone has experienced this week). If we value our preferred methods of reviewing over keeping to a well known process for outside contributors, the best process was launchpad + rietveld. Shouldn't we simply return to that. Considering we have been successfully using GitHub for several months now, using reviewboard is not a necessity. Obviously, I will go with whatever the team decides, but I'm concerned that we have moved to reviewboard without considering that it undermines (as far as I can see) our primary reason for using GitHub. Jess -- Juju-dev mailing list Juju-dev@lists.ubuntu.com [3] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev [4] -- Juju-dev mailing list Juju-dev@lists.ubuntu.com [5] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev [6] -- Juju-dev mailing list Juju-dev@lists.ubuntu.com [7] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev [8] -- ** Frank Mueller frank.muel...@canonical.com [10] ** Software Engineer - Juju Development ** Canonical Links: -- [1] mailto:david.che...@canonical.com [2] mailto:jesse.m...@canonical.com [3] mailto:Juju-dev@lists.ubuntu.com [4] https://lists.ubuntu.com/mailman/listinfo/juju-dev [5] mailto:Juju-dev@lists.ubuntu.com [6] https://lists.ubuntu.com/mailman/listinfo/juju-dev [7] mailto:Juju-dev@lists.ubuntu.com [8] https://lists.ubuntu.com/mailman/listinfo/juju-dev [9] mailto:roger.pe...@canonical.com [10] mailto:frank.muel...@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: Is ReviewBoard a good thing?
Im more than willing to help improve the work flow for you guys. As well as fixup issues you giys feel rb has Sent from Samsung Mobile Original message From: Nate Finch nate.fi...@canonical.com Date: 19/09/2014 1:32 PM (GMT+01:00) To: Jonathan Aquilina jaquil...@eagleeyet.net Cc: juju-dev@lists.ubuntu.com Subject: Re: Is ReviewBoard a good thing? There's one thing that hasn't been mentioned - reviewboard gives us a unified review queue. On github you need to look in 8 places to see all the stuff up for review, and anything not in juju/juju tends to get lost. This is really important since that can have a big effect on our velocity. I think we should continue using reviewboard until we've had more time to adjust to it. Remember, we were ready to abandon github after the first week, too. I think tooling can solve most of our problems with complicated workflows. On Fri, Sep 19, 2014 at 4:41 AM, Jonathan Aquilina jaquil...@eagleeyet.net wrote: Hey guys. Long time lurker with the occasional suggestion. I have an idea for something that might be beneficial to the project as a whole. Has it been considered about custom coding a review system that will interface with github hooks and provide what is needed to all juju dev's and keep things rather mainstream as well so as not to increase the entry level requirements fore new contributors? --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-19 10:14, Frank Mueller wrote: Right now I'm a bit undecided, the usage of ReviewBoard is too fresh. But Jesse made good points and in general Im always happy when we're using less instead of using more tools. I can live with the number of mails, GMail does grouping them fine. And I started to add my comments after a first pass through a PR. My greatest weakness so far has been the missing side-by-side diff, thankfully GitHub addressed this. So I'm with Jesse and will go with the team if we decide to use ReviewBoard, but I prefer returning to a GitHub based process as it is know in many other communities too. mue On Fri, Sep 19, 2014 at 9:20 AM, roger peppe roger.pe...@canonical.com wrote: On 19 September 2014 01:32, David Cheney david.che...@canonical.com wrote: There were three problem reviewboard was supposed to address, review comments are sent immediately, no side by side diffs, and no way to to chained proposals. I think that over the last few months we've all learnt to live with the first issue On the second, github now does nice side by side diffs. On the third, it appears reviewboard leaves you solidly to your own devices to implement chained proposals. I'm with Jesse, I vote to stop using reviewboard, I don't think it's paying it's way. The main thing I was hoping to get from reviewboard that's a constant pain to me in github was the ability to look at new changes in the context of old comments, to see where and how those comments have been addressed. So, assuming reviewboard did address that issue, I'm a bit sad but I think Jesse makes a very good point about keeping things mainstream. I guess there's the potential for some third party tool to address my issue above. So I agree that it might be better to cut losses here and embrace github, even if it is awkward in some ways. cheers, rog. On Fri, Sep 19, 2014 at 10:19 AM, Jesse Meek jesse.m...@canonical.com wrote: We moved to GitHub in the hope of lowering the bar to contributors outside the team. GitHub is *the* platform and process for open source software. This was the logic behind the move. It was deemed to have the most mindshare and we sacrificed our prefered platform and process to be part of that mindshare. We are now leaving that 'main stream' process to something that suits the tastes of our team - ReviewBoard. This adds friction for new contributors (friction everyone has experienced this week). If we value our preferred methods of reviewing over keeping to a well known process for outside contributors, the best process was launchpad + rietveld. Shouldn't we simply return to that. Considering we have been successfully using GitHub for several months now, using reviewboard is not a necessity. Obviously, I will go with whatever the team decides, but I'm concerned that we have moved to reviewboard without considering that it undermines (as far as I can see) our primary reason for using GitHub. Jess -- 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 -- ** Frank Mueller frank.muel...@canonical.com ** Software Engineer - Juju Development ** Canonical -- Juju-dev mailing
Re: The Pros and Cons of ReviewBoard.
I am more than willing to help out wity those modifications Sent from Samsung Mobile Original message From: Eric Snow eric.s...@canonical.com Date: 19/09/2014 5:41 PM (GMT+01:00) To: juju-dev@lists.ubuntu.com Subject: Re: The Pros and Cons of ReviewBoard. On Fri, Sep 19, 2014 at 9:37 AM, Eric Snow eric.s...@canonical.com wrote: Given that I've in some part driven the switch to ReviewBoard, I want to make sure we are all on the same page and any decision on its future can be made objectively. This is an outgrowth of the current discussion on whether or not we should ditch reviewboard. Let's look at the pros and cons of using it (at least relative to github). Feel free to expand on any point here or add to them. -eric ReviewBoard Pros: * self-hosted (flexibility, ownership) * unified review queue with detailed info * reviews are composed of multiple comments, not just one * reviews have worklow-supporting metadata (ship-it, issues) * reviews can be edited as a whole before publishing * review comments are threaded (provides context) * customizable (3rd party and custom extensions) * extensive remote API * some github integration * supports chained branches (anti-pattern?) * allows you to look at new changes in context of old comments * allows you to look at changes between review request updates * does not require a PR to exist ReviewBoard Cons: * self-hosted (hosting, maintenance, etc.) * adds manual steps to our workflow * extra steps increase the barrier to contributing * not a part of the mainstream github workflow * requires adjusting to a new tool for most people * web UI has some usability issues (list?) * emails formatting is complicated (subjective) Solutions: * add integration between github and reviewboard (github webhooks) - addresses manual steps (i.e. barrier-to-entry/workflow concerns) * provide a git plugin that wraps rbt and better supports our workflow - addresses complex workflow concerns * (unlikely) Modify and add to the web UI (via an extension) - addresses web UI concerns * (unlikely) Modify and add to the email formatting (via an extension) - addresses email formatting concerns -- 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: The Pros and Cons of ReviewBoard.
Thats what im suggesting be it coding somethign from scratch or adapting RB to make it much easier to work with. --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-19 23:01, Matthew Williams wrote: At the risk of opening a can of worms: Reviewboard doesn't have to be a barrier to contributing. We could allow new contributors/ drive by fixes to use github. Matty On 19 Sep 2014 17:05, Eric Snow eric.s...@canonical.com [4] wrote: On Fri, Sep 19, 2014 at 9:48 AM, Jonathan Aquilina jaquil...@eagleeyet.net [1] wrote: I am more than willing to help out wity those modifications Cool. I'll get in touch. -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com [2] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev [3] Links: -- [1] mailto:jaquil...@eagleeyet.net [2] mailto:Juju-dev@lists.ubuntu.com [3] https://lists.ubuntu.com/mailman/listinfo/juju-dev [4] mailto:eric.s...@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: The Pros and Cons of ReviewBoard.
I also suggested in another part of the thread sending an email when a new request is submitted to all those invovled with the reviewing. --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-19 23:14, Nate Finch wrote: If we automate the creation of reviewboard reviews whenever a pull request is made, it would make it trivial even for outsiders. On Sep 19, 2014 5:01 PM, Matthew Williams matthew.willi...@canonical.com [7] wrote: At the risk of opening a can of worms: Reviewboard doesn't have to be a barrier to contributing. We could allow new contributors/ drive by fixes to use github. Matty On 19 Sep 2014 17:05, Eric Snow eric.s...@canonical.com [4] wrote: On Fri, Sep 19, 2014 at 9:48 AM, Jonathan Aquilina jaquil...@eagleeyet.net [1] wrote: I am more than willing to help out wity those modifications Cool. I'll get in touch. -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com [2] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev [3] -- Juju-dev mailing list Juju-dev@lists.ubuntu.com [5] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev [6] Links: -- [1] mailto:jaquil...@eagleeyet.net [2] mailto:Juju-dev@lists.ubuntu.com [3] https://lists.ubuntu.com/mailman/listinfo/juju-dev [4] mailto:eric.s...@canonical.com [5] mailto:Juju-dev@lists.ubuntu.com [6] https://lists.ubuntu.com/mailman/listinfo/juju-dev [7] mailto:matthew.willi...@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: ReviewBoard is now the official review tool for juju
If i am not mistaken if you have multiple commits in a branch git has something built in called git squash. This obviously eliminates the 5 step process into one merge and one push. --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-16 09:44, roger peppe wrote: On 15 September 2014 21:39, Ian Booth ian.bo...@canonical.com wrote: On 16/09/14 00:50, Eric Snow wrote: On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow eric.s...@canonical.com [1] wrote: Yeah, those steps are a lot, though keep in mind that effectively it's only 2 steps more than before if you use the -p flag to rbt post and were already keeping your local master up to date. Just to be clear, here are the steps again, slightly reformatted: (0). Rebase relative to upstream master. - if origin is different than upstream, sync and push it Before I create a new branch, I ensure my local and origin (forked copy) master branches are up to date. However, once the branch is created, thereafter I do not rebase because it has caused nothing but trouble, with lots of manual effort required to fix things up wrt conflicts etc. Here's a trick I use (I imagine it's a well known technique) that makes it easy to do a lightweight rebase without the conflicts that often come when rebase replays your commits: $ git fetch upstream $ git merge upstream/master $ git reset upstream/master $ git add any new files added in your branch $ git commit -am 'describe your branch' As far as I can make out, as long as you want to propose your branch with only a single commit added to the log, this makes it easy to use a merge-based flow and amounts to the same thing in the end. I use it a lot, and it's saved no end of this is the *third* time I've resolved these conflicts pain. cheers, rog. Links: -- [1] mailto:eric.s...@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: ReviewBoard is now the official review tool for juju
I dont think you have to rebase though. I think you can squash multiple commits together. --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-16 11:27, roger peppe wrote: On 16 September 2014 09:22, Jonathan Aquilina jaquil...@eagleeyet.net wrote: If i am not mistaken if you have multiple commits in a branch git has something built in called git squash. This obviously eliminates the 5 step process into one merge and one push. I don't see that command. Are you thinking of the squash functionality of rebase -i? FWIW, I never run those five steps in sequence together. Usually I just get to a situation where I know that I have all tests passing and I'm up to date with master (for example I've done a merge some time ago, probably before fixing a bunch of tests). Then it's just: $ git reset upstream/master $ git commit -am 'my commit message' which is usually quicker than running rebase -i, and much quicker if the rebase replay leads to conflicts. 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: ReviewBoard is now the official review tool for juju
That is it indeed :) --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-16 11:58, Dimiter Naydenov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.09.2014 12:32, Jonathan Aquilina wrote: I dont think you have to rebase though. I think you can squash multiple commits together. You're probably thinking about git commit --amend -m msg, which folds the current changeset into the one before it, effectively squashing the uncommitted changes onto the same revision ID, and changing the commit message. --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-16 11:27, roger peppe wrote: On 16 September 2014 09:22, Jonathan Aquilina jaquil...@eagleeyet.net [1]jaquil...@eagleeyet.net wrote: If i am not mistaken if you have multiple commits in a branch git has something built in called git squash. This obviously eliminates the 5 step process into one merge and one push. I don't see that command. Are you thinking of the squash functionality of rebase -i? FWIW, I never run those five steps in sequence together. Usually I just get to a situation where I know that I have all tests passing and I'm up to date with master (for example I've done a merge some time ago, probably before fixing a bunch of tests). Then it's just: $ git reset upstream/master $ git commit -am 'my commit message' which is usually quicker than running rebase -i, and much quicker if the rebase replay leads to conflicts. cheers, rog. - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUGAm+AAoJENzxV2TbLzHwH74IAIUUxdHCS2KTvTNPRRAZt9F1 r3/gLD/guBbicVuE/p7Ghj/DirmjuLDF8ZndmWO8EeIVye3ikw204lFklfpx4uSh Qik5Mp+JPrFZ1u78n8EKhvh7gX+FytKooFSdUHjPfkxPTVZ2Rxg/LyXJSsp3WlvJ G+wgx01gKztqaE37EhFQkYoE1+ULUm8phOTS6UhzVMiaRr+x7u4oL1M0i48+FHvC R6KHBq0zoxijLxRgN7jfKpavPEIrCPEjTB/zOBN9NONKhVABlIU3HWb5JtBA+vVV TbpmpKOSKdS7hNMnr2D/phKK62TxEpefHszmKWzuR/JWmq5cC7lEFwjUbUV8nFg= =vcVP -END PGP SIGNATURE- Links: -- [1] mailto:jaquil...@eagleeyet.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Unit Tests Integration Tests
With github I know continuous integration is possible. On another project I work on we use it. The perk with travis is that it works with a YAML file plus when a PR is filed it send the patch to be built and lets you know in the PR if the build was successful or not. I am not sure though how that would fit into the workflow for you guys. --- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-11 17:29, Matthew Williams wrote: Hi Folks, There seems to be a general push in the direction of having more mocking in unit tests. Obviously this is generally a good thing but there is still value in having integration tests that test a number of packages together. That's the subject of this mail - I'd like to start discussing how we want to do this. Some ideas to get the ball rolling: Having integration tests spread about the package and having environment variables that switch on/ off them being run $ JUJU_INTEGRATION go test ./... We could make use of build tags: $ go test -tags integration ./... We could put all the integration tests in a single package: $ go test github.com/juju/juju/integrationtests/. [1].. Thoughts? Matty Links: -- [1] http://github.com/juju/juju/integrationtests/. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Label: Ready For Review
On 2014-08-12 00:30, Nate Finch wrote: Hmm, thats a good point. This whole only owners can label stuff is annoying. I wonder if we should just make everyone owners. On Aug 11, 2014 5:59 PM, David Cheney david.che...@canonical.com [9] wrote: What if the review needs the author to rework ? On Tue, Aug 12, 2014 at 7:55 AM, Nate Finch nate.fi...@canonical.com [1] wrote: Merge it and itll get closed and out of the list of open PRs. I presume the submitter is paying enough attention to merge their own stuff. On Aug 11, 2014 5:44 PM, David Cheney david.che...@canonical.com [2] wrote: How can we remove the label once the review has been done ? On Tue, Aug 12, 2014 at 4:33 AM, Nate Finch nate.fi...@canonical.com [3] wrote: I made a label on github.com/juju/juju [4] (and coincidentally github.com/juju/utils [5]) called Ready For Review. The reason for the label is that it is often difficult to figure out what branches are actually ready to be reviewed and which ones are really WIP and therefore arent waiting to be reviewed. Its simple to filter by labels to see whats assigned to Ready For Review, so the on-call reviewers (or anyone else) can find stuff to review. I did this because some people had mentioned to me that they had branches that were waiting for reviews, but no one was reviewing them. Pinging people who are online works, but its hard to ping people who arent online so I figured this was easier and gives everyone somewhere to go to find what PRs are languishing. I know we have the WIP: prefix for branches that arent ready to be generally reviewed but thats opt-out, which means its easy to forget to put that on your branch and have people think its ready for review when its not which means people tend to err on the side of just not reviewing stuff. The Ready For Review label is opt-in, so theres no doubt that the submitter thinks its ready. It currently requires someone on this list to add the label (at least for github.com/juju/juju [6]), which is somewhat unfortunate, but its really only needed if you think your code wont get reviewed otherwise... and maybe just asking someone to add that label will encourage them to review your code. -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com [7] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev [8] Links: -- [1] mailto:nate.fi...@canonical.com [2] mailto:david.che...@canonical.com [3] mailto:nate.fi...@canonical.com [4] http://github.com/juju/juju [5] http://github.com/juju/utils [6] http://github.com/juju/juju [7] mailto:Juju-dev@lists.ubuntu.com [8] https://lists.ubuntu.com/mailman/listinfo/juju-dev [9] mailto:david.che...@canonical.com I know it is possible on the issue tracker to label things even pull requests. Not sure if that would be a good way too go or not? -- Regards, Jonathan Aquilina Founder Eagle Eye T -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Proposal: making apt-get upgrade optional
Why not use the auto update feature that is in Ubuntu. I use it and recoeve emails about the upgrades Sent from Samsung Mobile Original message From: Antonio Rosales antonio.rosa...@canonical.com Date: 01/07/2014 21:38 (GMT+01:00) To: Andrew Wilkins andrew.wilk...@canonical.com Cc: juju-dev@lists.ubuntu.com Subject: Re: Proposal: making apt-get upgrade optional Suggest we make an environments.yaml key value of say apt-get-update set to a boolean with the default being true. Existing charms are timing out[0] when apt-get update is turned off due to stale apt-get metadata. Users then can them make the choice, and we can make suggestions in the docs as to what this key value means and how it can improve performance especially in the developer scenario when the care more about fast iterative deploys. Thoughts? [0] https://bugs.launchpad.net/juju-core/+bug/1336353 -thanks, Antonio On Tue, Jul 1, 2014 at 4:43 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Tue, Jul 1, 2014 at 5:45 PM, John Meinel j...@arbash-meinel.com wrote: I would just caution that we'd really prefer behavior to be consistent across platforms and clouds, and if we can work with Microsoft to make 'apt-get update' faster in their cloud everyone wins who uses Ubuntu there, not just us. I was meaning to disable it across all providers. It would be ideal to improve upgrades for all Ubuntu users, but from what I can tell it's a case of Azure's OS disks being a tad slow. If you start going up the instance-type scale, then you do get more IOPS. I haven't measured how much of a difference it makes. Have we looked into why Upgrade is taking 3m+? Is it the time to download things, is it the time to install things? I've certainly heard things like disk ops is a bit poor on Azure (vs CPU is actually better than average). Given the variance of 6m+ to 3m20s with Eat my data, it would seem disk sync performance is at least a factor here. I just looked, and it is mostly not network related (I assume mostly I/O bound). On ec2 an upgrade fetches all the bits in 0s; on Azure it's taking 5s. Given I believe apt-get update is also disabled for local (it is run on the initial template, and then not run for the other instances copied from that), there is certainly precedence. I think a big concern is that we would probably still want to do apt-get update for security related updates. Though perhaps that is all of the updates we are applying anyway... If I read the aws.json file correctly, I see only 8 releases of the 'precise' image. 6 of 'trusty' and 32 total dates of released items. And some of the trusty releases are 2014-01-22.1 which means it is likely to be beta releases. Anyway, that means that they are actually averaging an update only 1/month, which is a fairly big window of updates to apply by the end of month (I would imagine). And while that does mean it takes longer to boot, it also means you would be open to more security holes without it. My contention is that if we don't *keep* it updated, we may as well just leave it to the user. When you create an instance in ec2 or Azure or whatever, it doesn't come fully up-to-date. You get the released image, and then you can update it if you want to. John =:- On Mon, Jun 30, 2014 at 5:05 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: Hi folks, I've been debugging a bootstrap bug [0] that was caused by ssh timing out (and the client not noticing), which was caused by apt-get upgrade taking an awfully long time (6 minutes on Azure). [0] https://bugs.launchpad.net/juju-core/+bug/1316185 I just filed https://bugs.launchpad.net/juju-core/+bug/1335822, and did a quick and dirty hack that brought the upgrade down to 3 minutes on Azure. I don't know the variance, so I can't be sure that it's all due to eatmydata, but smoser's results are similar. Even with eatmydata, a full bootstrap on Azure just took me 10 minutes. That's roughly broken down into: - apt-get update: 20s - apt-get upgrade: 3m20s - apt-get install various: 10s - Download tools (from shared Azure storage account): 5s - jujud bootstrap: 1m50s We could bring the 10m down to 6m40s. Still not brilliant, but considerably better IMO. I propose that we remove the apt-get upgrade altogether. Cloud images are regularly updated and tested, and I think we should be able to rely on that alone. If users want something more up-to-date, they can use the daily images which are not tested as a whole, but are composed of SRUs, which is effectively what users get today. Cheers, Andrew -- 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 -- Antonio Rosales Juju Ecosystem Canonical --
Re: Reviewing in progress work on Github
Not trying to hijack this thread, but a suggestion for reviewing and CI testing. I have a hunch you guys already have something in place, but there is TRAVIS CI which integrates nicely with github repos through a yaml file. When a pull request is submitted it performs a build and then on the pull requests lets you know if the build was successful with that change or not. Apologies if this derails the topic, but in terms of reviewing it might be helpful. You can keep updating a pull request as your work on a feature. Old diffs and comment are preserved. On nice feature is that old comments are hidden if the area of the code they reference is changed by a later diff. This link from the Github people themselves is light on detail but talks about how they use a pull request as a way of tracking work in progress right from the beginning of the development of a feature. https://github.com/blog/1124-how-we-use-pull-requests-to-build-github I guess this doesn't address the email spam problem but it does seem like it would work otherwise. People can individually opt out of notifications about a specific PR but that's not really ideal. On 5 June 2014 15:41, Ian Booth ian.bo...@canonical.com wrote: You can, but then you loose any previous comments and history on the previously work in progress pull request. With Launchpad, you could just flip the status on the merge proposal and all the comments would be retained. On 05/06/14 13:38, John Meinel wrote: Can't you just create a new Pull request when it is finally ready? John =:- On Thu, Jun 5, 2014 at 7:25 AM, Ian Booth ian.bo...@canonical.com wrote: One of the many things I miss now that we have moved to Github/git is the ability to put up a merge proposal with in-progress work, allowing collaboration on the implementation as it evolves etc. Launchpad supported this nicely, as it didn't spam people with emails for wip mps etc. I don't think Github supports this concept. Perhaps a way around it is to do a pull request against one's forked copy of the main Juju repo. That way, people can still easily see your work, but without the general spam. Sadly, it doesn't allow the pull request to then be re-targetted to the Juju repo when ready to be reviewed for real. Or does it? Does anyone have any better ideas how to do this? -- 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 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Reviewing in progress work on Github
In regards to this feature. Why not write a hook for github to have it interface with LP One of the many things I miss now that we have moved to Github/git is the ability to put up a merge proposal with in-progress work, allowing collaboration on the implementation as it evolves etc. Launchpad supported this nicely, as it didn't spam people with emails for wip mps etc. I don't think Github supports this concept. Perhaps a way around it is to do a pull request against one's forked copy of the main Juju repo. That way, people can still easily see your work, but without the general spam. Sadly, it doesn't allow the pull request to then be re-targetted to the Juju repo when ready to be reviewed for real. Or does it? Does anyone have any better ideas how to do this? -- 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-core on github
What can I do to help you guys out? The main problem with TravisCI is that it doesn't actually test what you woukd finally land if trunk gets ahead of your branch. (When you propose a branch it merges trunk at that time and then tells you the test results. But if you get more trunk revs, it doesn't re test.) We're used to a bot that controls trunk, so we know the test suite passed when a given revision lands on trunk. We could live with and make it work if it was the only option, but Juju-GUI has a different lander that works more how we would expect. (It requires more set up and hosting the stuff ourselves, but it works closer to how we would expect.) Gerrit might also be an option, but I'm hoping we can do pieces at a time. John =:- On Mar 14, 2014 10:33 PM, Jonathan Aquilina jaquil...@eagleeyet.net wrote: If you guys need help I have some experience with github and would love to help you guys out with setting up gerrit for code review as well as continuous integration as well provided by travis CI. My current understanding is that we are pushing hard towards a new stable release, and then towards a 2.0 release candidate in the next few weeks. We are likely to do the github switch right after that, so my estimation would be that the switch will be done mid-april. --Mark Ramm On Fri, Mar 14, 2014 at 1:19 PM, Jonathan Aquilina jaquil...@eagleeyet.netwrote: For code review there is gerrit https://code.google.com/p/gerrit/ I have seen this used by the libreoffice project, and its very successful as there can be multiple people reviewing patches which get submitted. it integrates with any git version control and already github has a hook available to integrate it easily with ones github repo It seems there has been some interest in moving juju-core from bazaar on launchpad to git on github? Also, it seems like the main sticking point is the need for a generally accepted code review tool/process. I'd like to see the code over on github; what can I do to help make it happen? Sounds like a good code review tool is a starting point? 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-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: Juju-core on github
For code review there is gerrit https://code.google.com/p/gerrit/ I have seen this used by the libreoffice project, and its very successful as there can be multiple people reviewing patches which get submitted. it integrates with any git version control and already github has a hook available to integrate it easily with ones github repo It seems there has been some interest in moving juju-core from bazaar on launchpad to git on github? Also, it seems like the main sticking point is the need for a generally accepted code review tool/process. I'd like to see the code over on github; what can I do to help make it happen? Sounds like a good code review tool is a starting point? 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-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
An interesting scenario
I have an interesting scenario which either is already catered for or should
be catered for.
I am currently using a local provider for testing and contribution purposes.
I bootstrapped an environment and deployed the juju-gui i then shut down the
computer and powered it on again this morning the bootstrapped environment
came up just fine yet the instance i created with the juju gui did not
jaquilina@jaquilina-Satellite-S75-A:~/.juju$ juju status
environment: local
machines:
0:
agent-state: started
agent-version: 1.16.5.1
dns-name: 10.0.3.1
instance-id: localhost
series: saucy
1:
agent-state: started
agent-version: 1.16.5.1
instance-id: jaquilina-local-machine-1
instance-state: missing
series: precise
services: {}
jaquilina@jaquilina-Satellite-S75-A:~/.juju$ sudo lxc-ls --fancy
NAME STATEIPV4 IPV6 AUTOSTART
--
jaquilina-local-machine-1 RUNNING 10.0.3.50 - YES
As can be seen the instance state is missing. I removed the entire
bootstrapped environment and recreated it again
machines:
0:
agent-state: started
agent-version: 1.16.5.1
dns-name: 10.0.3.1
instance-id: localhost
series: saucy
services: {}
Now the scenario is this. This is more for cloud providers as well as those
hosting private clouds. But what does one do if you have a server which fails
or power cycles itself for one reason or another. How will one bring back up
the instances that were running on it?
Regards
Jonathan
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
