Re: Upcoming change in 1.24: tags in EC2
On Tue, 26 May 2015, Andrew Wilkins wrote: On Tue, May 26, 2015 at 4:05 AM, Mark Shuttleworth m...@ubuntu.com wrote: On 25/05/15 18:57, Kapil Thangavelu wrote: That's super awesome, and very helpful for real world usage. A few suggestions, For users with multiple environments, seeing a bunch machine-0 in the ui, is rather confusing, i'd suggest prefixing with the env name. Potentially even more useful is actually naming the machines not for their pet names, but their cattle names (workload name), ie. name with the primary unit that caused the machine to exist, or was the first unit assigned to the machine (minus state servers). Agreed; for full chargeback we need environment uuid, for social debugging we need some sort of environment name, unit names and charm(s) deployed, including in containers on the machine. For EBS it would be the store name, uuid, and unit identity. Kapil, Mark, thanks for the suggestions. Sounds good, I'll look at doing that. A concern I have is that these resources can be reassigned (units added, volume assigned to different store) so those tags would then be misleading. That's the main reason why I avoided including information about the workload/store in the name. I suppose the benefit outweighs, and we could look at updating tags later on. Cheers, Andrew One suggestion is being careful about what tags might already exist on a machine that a user might have set through their own control UI. If Juju is tracking tags it sets we should make sure it never messed with ones it did not set. -- Rick Harding -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Do not land code on blocked branches
Thanks for the update. I've closed the bug for now and we'll reopen an issue to update to the latest api version once that's changed. On Sun, 03 May 2015, John Meinel wrote: Just to follow up one small point, Rick. The reason Juju has to fix the API and restore the old behavior is because even if Quickstart fixed itself, anyone running an older version is going to break with a newer Juju API, which is why we require API stability, and only changing things by bumping the version. :) John =:- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Do not land code on blocked branches
Thanks for the breakdown John. I've filed the bug on quickstart [1] and
I'll get our guys looking at it on Monday. For now, since the team has
diagnosed this is indeed an issue in quickstart relying on deprecated
behavior and not an unexpected API compatibility issue, I'd suggest that we
make the quickstart tests non-voting until we can provide an updated
quickstart version. This should help unblock core and give us time to get a
new release out.
1: https://bugs.launchpad.net/juju-quickstart/+bug/1451182
Rick
On Sun, 03 May 2015, John Meinel wrote:
Just going off the bits that Ian pointed to, the section of code was if you
called ServiceDeploy with a CharmStore URL (eg cs:mysql) but you had not
already called AddCharm.
The juju cli client already knows to call Client.AddCharm with the given
URL, whereas the internal api/client/client.go does a double check if it
gets called with a charm URL that isn't already in state.
Now, I don't know how Quickstart would be triggering
apiserver/client/client.go
The error here: in traceback looks like:
connecting to wss://
52.6.157.186:17070/environment/47724da5-9b38-4141-8f92-03d8f4225de9/api
environment type: ec2
bootstrap node series: trusty
charm URL: cs:trusty/juju-gui-27
requesting juju-gui deployment
juju-quickstart: error: bad API response: charm cs:trusty/juju-gui-27 not
found
2015-05-01 18:28:59 ERROR Command '('juju', '--show-log', 'quickstart',
'-e', 'aws-quickstart-bundle', '--constraints', 'mem=2G', '--no-browser',
'/var/lib/jenkins/repository/landscape-scalable.yaml')' returned non-zero
exit status 1
Traceback (most recent call last):
File /var/lib/jenkins/juju-ci-tools/quickstart_deploy.py, line 51, in
run
for step in self.iter_steps():
File /var/lib/jenkins/juju-ci-tools/quickstart_deploy.py, line 70, in
iter_steps
self.client.quickstart(self.bundle_path)
File /mnt/jenkinshome/juju-ci-tools/jujupy.py, line 335, in quickstart
self.juju('quickstart', args, self.env.needs_sudo())
File /mnt/jenkinshome/juju-ci-tools/jujupy.py, line 294, in juju
return subprocess.check_call(args, env=env)
File /usr/lib/python2.7/subprocess.py, line 511, in check_call
raise CalledProcessError(retcode, cmd)
So it would appear that we had code to allow users to call
Client.ServiceDeploy(cs:mysql) and the server would lookup the charm and
deploy it for the user, but we stopped doing that as a Juju CLI since 1.16.
However, I think this is *our* bad because this is a very important client
(quickstart and probably others) that has been relying on this behavior in
all our recent releases.
Compat with juju-cli != compatibility with Juju API users.
AFAIK we don't have a great way to respond to clients that behavior is
deprecated, but we can bump the Version of the API and change the behavior.
We definitely should have done that here rather than just remove the
behavior.
John
=:-
On Sun, May 3, 2015 at 3:59 PM, Richard Harding rick.hard...@canonical.com
wrote:
On Sun, 03 May 2015, Ian Booth wrote:
Curtis has filed three new bugs for these so far, and there appears to
be one or two more to come:
https://bugs.launchpad.net/juju-core/+bug/1450912
The issue here is that quickstart is relying on Juju 1.16 behaviour.
There was a
block of code with a comment:
// Remove this whole if block when 1.16 compatibility is dropped.
The code block was removed because 1.18 was our minimum compatibility
version.
But it seems we have to restore the 1.16 behaviour. Note that this is
not an
upgraded environment where we need to retain compatibility with older
deployments. It is a fresh 1.24 install which should be able to rely on
1.18 and
later behaviour only.
Ian, can you be more specific on the chunk of code that was removed or
branch I can look at for this? I'll happily file a bug and update
quickstart, we just need to know what's changed there. Having a branch in
hand or a bug will assist us in getting that updated as fast as possible.
In searching through the quickstart code there's no hard requirement or
notes on 1.16.
Thanks
--
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
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: previously valid amazon environment now invalid?
On Thu, 30 Apr 2015, Nate Finch wrote: If someone needs 1.18 CLI compatibility, they can use 1.18. It's that simple. We're maintaining API compatibility for just this reason. If they don't want the binary to change, they shouldn't update it (or should just rename it to juju-1.18 or something). We shouldn't break the CLI willy-nilly, but given sufficient reason, it can, and should change, IMO. This is something we should really think long/hard about. Users running trusty expect an LTS release to be safe to upgrade to. As long as Juju versions are backported to LTS releases Juju has the responsibility of being repeatable to those LTS users and their deployment and management scripts. It sucks, but it's the cost of getting the newer releases into the LTS product. That being said, the cli is an API. It's the user facing API. Users don't care about how the internals between the client and server work, as long as the client is working for them. APIs can have new endpoints added without issue as there's no risk to breakage of the API usage. I think if we look at the CLI as an API and treat backward incompatible changes as 'needs a version bump' then it'll help identity the points where we need to look at some sort of way to do 'compatibility mode' or such. Rick -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Alternative charm store location?
On Fri, 06 Mar 2015, John George wrote: To support testing of the latest charm store API, Juju needs to connect to api.jujucharms.com. However, BaseURL is set to https://store.juju.ubuntu.com in https://github.com/juju/charm/blob/v4/repo.go One approach might be to simply add an entry to /etc/hosts, on the system used for driving the tests, so that store.juju.ubuntu.com resolves to api.jujucharms.com. The problem here is that the certificate returned is from jujucharms.com and fails validation. For example: juju deploy -e local-trusty foo ERROR Get https://store.juju.ubuntu.com/charm-info?charms=cs%3Atrusty%2Ffoo: x509: certificate is valid for *.jujucharms.com, jujucharms.com, not store.juju.ubuntu.com 1. Is there a way to pass Juju an alternative store location and override what's set in repo.go? 2. Ask IS to expand the certificates X509v3 Subject Alternative Name list to include store.juju.ubuntu.com. 3. Ask IS to install the store.juju.ubuntu.com certificate on api.staging.jujucharms.com to support testing with the current Juju. The goal is to change the dns of store.juju.ubuntu.com to point to our new service. We're working with webops to get the ssl cert loaded so that it would pass successfully if you changed your /etc/hosts to think of it that way. We'll report back once that work is completed with webops. Rick -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: separating out golang juju client from
Any time there's an API I'd rather we help own and build the community by providing the client vs relying on others to manage and control the experience there. Can't +1 it enough. Rick On Sat, 20 Dec 2014, David Cheney wrote: There is no reason for the 130 (at last count) packages that constitute juju-core (not counting the dozens of other packages we bring in as dependencies) to live in the same repository. If licensing is the lever that we use to break up this monolithic repository, consider me +1 On Fri, Dec 19, 2014 at 11:05 PM, Kapil Thangavelu kapil.thangav...@canonical.com wrote: On Fri, Dec 19, 2014 at 7:02 AM, Nate Finch nate.fi...@canonical.com wrote: While I am generally for using more permissive licenses, I'm not sure how useful that might be... most significant changes require modifications to both the client and the server, or at least to libraries used by both. That sort of misses the point of building apps that use juju apis. Yes the two packages need to be updated together for new changes same as today. There's not that much code under cmd/juju compared to the whole rest of the repo. Again its not about that code, its about building other applications and facilitating integrations. cheers, Kapil On Fri, Dec 19, 2014 at 6:03 AM, Kapil Thangavelu kapil.thangav...@canonical.com wrote: one of the issues with having it in tree, means client usage falls under the AGPL. We want to have the client used widely under a more permissive license. I've already had contributions to other projects n'acked due to license on our libraries. I'd like to see it moved to a separate repo so that's possible. Thoughts? cheers, Kapil -- 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 -- 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: ACTION: if you have admin hardcoded in scripts, this is a warning that things will change soon(ish)
+1 here, the GUI is already making the other env calls to get state servers and the like. Adding another api call just means the GUI has to make 2, 3, etc api requests before it can function which has an overhead we have to pay in user experience. Making a single info endpoint, even if you have to specify the data you'd like via args is much more appealing to our point of view. Rick On Mon, 29 Sep 2014, John Meinel wrote: I think we want a simpler single-command to get everything you need to connect to the API. juju api-info or something like that, which essentially gives you the structured .jenv information that you would use (cert information, username, password, IP addresses, etc) John =:- On Mon, Sep 29, 2014 at 12:54 AM, Tim Penhey tim.pen...@canonical.com wrote: On 26/09/14 20:39, Bjorn Tillenius wrote: On Fri, Sep 26, 2014 at 04:57:17PM +1200, Tim Penhey wrote: Hi folks, All environments that exist so far have had an admin user being the main (and only) user that was created in the environment, and it was used for all client connections. Code has landed in master now that makes this initial username configurable. The juju client is yet to take advantage of this, but there is work due to be finished off soon that does exactly that. Soon, the 'juju bootstrap' command will use the name of the currently logged in user as the initial username to create [1]. What's the official way of getting the username in 1.20.8? I see 'juju api-endpoints' which returns the state servers, and 'juju get-environment' that returns a bunch of information, except the username. The only way I see is to get the .jenv file and parse it, but it feels a bit dirty. Is it guaranteed that the location and name of the file won't change, and that the format of it won't be changed in way that breaks backwards-compatibility? We don't have one yet, but one command that was proposed was juju whoami This would be pretty trivial to implement. There are a bunch of user commands that will be coming on-line soon. We won't land the change to change the admin user until there is an easy way to determine what that name it. The change will not change the user for any existing environment, only newly bootstrapped ones. 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 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: ACTION: if you have admin hardcoded in scripts, this is a warning that things will change soon(ish)
Doh, and I completely misread this in my early morning fog and none of this is an api call and in no way relates to anything so please ignore it and carry on. Rick On Mon, 29 Sep 2014, Richard Harding wrote: +1 here, the GUI is already making the other env calls to get state servers and the like. Adding another api call just means the GUI has to make 2, 3, etc api requests before it can function which has an overhead we have to pay in user experience. Making a single info endpoint, even if you have to specify the data you'd like via args is much more appealing to our point of view. Rick On Mon, 29 Sep 2014, John Meinel wrote: I think we want a simpler single-command to get everything you need to connect to the API. juju api-info or something like that, which essentially gives you the structured .jenv information that you would use (cert information, username, password, IP addresses, etc) John =:- On Mon, Sep 29, 2014 at 12:54 AM, Tim Penhey tim.pen...@canonical.com wrote: On 26/09/14 20:39, Bjorn Tillenius wrote: On Fri, Sep 26, 2014 at 04:57:17PM +1200, Tim Penhey wrote: Hi folks, All environments that exist so far have had an admin user being the main (and only) user that was created in the environment, and it was used for all client connections. Code has landed in master now that makes this initial username configurable. The juju client is yet to take advantage of this, but there is work due to be finished off soon that does exactly that. Soon, the 'juju bootstrap' command will use the name of the currently logged in user as the initial username to create [1]. What's the official way of getting the username in 1.20.8? I see 'juju api-endpoints' which returns the state servers, and 'juju get-environment' that returns a bunch of information, except the username. The only way I see is to get the .jenv file and parse it, but it feels a bit dirty. Is it guaranteed that the location and name of the file won't change, and that the format of it won't be changed in way that breaks backwards-compatibility? We don't have one yet, but one command that was proposed was juju whoami This would be pretty trivial to implement. There are a bunch of user commands that will be coming on-line soon. We won't land the change to change the admin user until there is an easy way to determine what that name it. The change will not change the user for any existing environment, only newly bootstrapped ones. 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 -- 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: Is ReviewBoard a good thing?
On Fri, 19 Sep 2014, Nate Finch wrote: There's one thing that hasn't been mentioned - reviewboard gives us a unified review queue. Can I ask how kanban doesn't do this job for you? I've heard this said a couple of times but I realized the way I find out what needs to be looked at is to go to kanban not github. I do that for the same reason. We've got teams working on 4 different github projects under two different orgs at the moment. Using the source control as a source seems pretty doomed. You already have a 3rd party tool to track that, kanban. Rick -- 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
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
status of container support in Juju
For our work on Machine View in the Juju GUI the team needs to help the user know what can and cannot be done with machines and containers. One of those things is determining if lxc or kvm containers work on various providers so the UX will not show users an option we know doesn't work. Jay wrote up a quick script [1] to test it out on each provider we support and I wanted to double check these results are expected. Provider | kvm | lxc | container is routable to client EC2 | no | yes | no Azure | no | no | - Azure w/o AS | no | yes | no HP Cloud | no | yes | no Joyent| no | yes | no Local (lxc) | no | no | - Local (kvm+aufs) | no | no | - Local (kvm-aufs) | no | yes | - I've not finished getting my MAAS setup going but I understand that it should work here. It'd be the only one that can currently create a container on a machine and then access it without needing to setup tunnels since it just grabs a DHCP address from the MAAS server. I understand that there's been work started on EC2 and routable lxc containers, but that it was put on hold to work on IPV6. So that path should be nicer in the near future. I also find a lot of references to LXC nesting [2][3] but it seems it does not work out of the box currently. If it's meant to work I can get Jay to file a bug and see if we can pull together any notes on that. Are there any plans to making lxc containers routeable in HP and Joyent? Does anyone know if lxc in lxc is meant to be supported in local out of the box? Right now I'm hesitant to enable creating containers in Machine View for anything but MAAS. I know that, in the providers that support lxc, as long as the service isn't exposed it's ok. I am worried about how to direct feedback to the user that they've deployed a scenario (mysql on the root while wordpress in a non-routable container) that we know can't work as users would expect. Please let me know if something should work that we're not seeing as working. 1: http://paste.ubuntu.com/8088459/ 2: http://s3hh.wordpress.com/2014/03/31/nested-lxc/ 3: https://www.stgraber.org/2012/05/04/lxc-in-ubuntu-12-04-lts/ -- 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: status of container support in Juju
On Tue, 19 Aug 2014, Richard Harding wrote: Right now I'm hesitant to enable creating containers in Machine View for anything but MAAS. Just to clarify, after having some more coffee we can warn users that expose services that have units in containers in the GUI and it should help raise warning to users about the routing issues for now. It's after the user has set things up, but it should allow us to allow containers in most providers. -- Rick -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: status of container support in Juju
Thanks for the correction. You're right, in the testing we were checking expose directly. We also did a test (not in this script) around two services where one was on the root and one was in a container, but even that's not a fair case of 'routable' as that might work while two units on different machines would not. We'll update and do some more testing. On Tue, 19 Aug 2014, John Meinel wrote: expose is different because it is about making the service available outside of the cloud. The issue with route able containers is that they aren't route able even within the cloud. At this point only MaaS has route able containers. John =:- On Aug 19, 2014 4:56 PM, Richard Harding rick.hard...@canonical.com wrote: On Tue, 19 Aug 2014, Richard Harding wrote: Right now I'm hesitant to enable creating containers in Machine View for anything but MAAS. Just to clarify, after having some more coffee we can warn users that expose services that have units in containers in the GUI and it should help raise warning to users about the routing issues for now. It's after the user has set things up, but it should allow us to allow containers in most providers. -- Rick -- 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: series-agnostic charm URLs
On Wed, 23 Jul 2014, Gustavo Niemeyer wrote: Going back to bundles, not having to update a bundle when a new, entirely different, release of Ubuntu comes out, is of course much more expressive, and people love expression, but carries with it a relevant semantic load. It also means neither we nor anybody else has any idea about what people actually get when they deploy a bundle, and whether the bundle will even work tomorrow once a new major upgrade is pushed to the repository. Our focus should not be to encourage that, but to help people express what they mean clearly and easily. If they want a new release of the bundle with a slightly different meaning, that should be trivial, but it should not be trivial to express lack of clarity. I think it's important to look at this from the viewpoint of the effort required to have the non-specific charm definition in a bundle. - If the user builds their bundle from the Juju GUI all charms are completely qualified. Series, name, and version are at a firm definition and the bundle is completely safe to redeploy and is repeatable. - If the user exports an existing live environment, the above is true as well. Everything is firmly qualified. - If the user hand constructs a bundles.yaml file they are able to type whatever they desire into that `charm:` field. I would argue that it's quite reasonable for the user to be able to copy/paste a command line target and expect it to work just as their `juju deploy` cli did. - If the user were to take a bundles.yaml from the GUI and proceeds to edit it to remove the series specifier, they're expressing their desire explicitly and it's something we know stakeholders require (ecosystem team). Give this, the vast majority of bundles are fully qualified. In the JAAS scenaraio, where users are building bundles through the webui and they're stored directly, we can encourage/enforce qualified names by controlling the UI interaction. However, we want to maintain the escape hatch for the stakeholders that require it. If we want to remove this support then we need to involve them in a process to come together, agree on the decision, and update our existing tools to not permit it. We also have to worry about historical usage as we've always supported the vague behaviour and many of the current of bundles take advantage of it. Yes, bundles were very organically developed. But I won't re-raise that rant. Ok, I'll let history be history. However, if you have any feedback on bundles I'd love to have a chance to hear your thoughts as our team is working on moving bundles and their definition to the charmstore and will bring up moving to being a first class juju-core entity in Nuremburg. -- Rick Harding -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Charm store API proposal, new version
On Tue, 15 Jul 2014, Aaron Bentley wrote: On 14-07-15 10:17 AM, roger peppe wrote: The most significant change is that all endpoints refer just to a single charm or bundle, rather than being bulk calls as they were before. That sounds like the opposite of what juju-reports wants. Does it really mean that we would need to make N requests to retrieve info on N charms? What was the reason for changing this? The change is because we went through the known clients and could not come up with use cases where some client had a known list of charm ids they wanted data for, but they knew those ids ahead of time. In the gui, cli, charmtools, etc, we perform queries by a single entity id. The only exception was search, which is a different animal all together and has its own api points for this use. Aaron, I'd like to see if we can get your full use case details and make sure we address them. You had requested an all charms/bundles api call in the last revision of the doc and we're looking at addresssing that through search results. The entity type is a direct filter attribute on a search call. You're also able to describe what metadata about a charm/bundle you'd like to see in a search result. So the thought was that we'd limit the complexity of the api to that known use case. Can you describe your exact use case as a client of the api and we'll look at how the spec/design can be improved to help your use case? -- 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: Charm store API proposal, new version
On Tue, 15 Jul 2014, Aaron Bentley wrote: I am surprised that juju-reports was not considered a known client. I certainly made many comments on the first draft of the original proposal. It is listed under known clients in the spec, and we mentioned your request down below. What we lack is your specific use cases as no one working on the spec is knowledgeable about how you're using the api. Our use case is we want to be able to synchronize public data from the charm store into our DB. We need to provide the statistics that show adoption rates to Mark Ramm and Mark Shuttleworth. We cannot forsee exactly which questions will be asked. We need to be able to add new statistics without friction, so we need our own copy of this data. One way to do this would be to have an API that accepts a timestamp and returns the metadata for all charm and bundle revisions created on or after that timestamp. Right now we do this instead: 1. Retrieve a list of all charms from charmworld 2. Determine the tip revisions of all charms from the charm store 3. Determine which revisions exist but we haven't seen (including non-tip revisions) 4. Determine the revision ids of all the new revisions 5. Use the revision-ids to determine the publication dates of all the new revisions Steps 2, 4, 5 use multiple-id queries. Right now, we're showing number of charms published here: http://reports.vapour.ws/scorecard We'll need to do the same for bundles. We've also been asked to display the number of running environments. What specific metadata do you need? I know we need the list of older revisions of charms for the juju-gui. I'm going to make sure that's listed as a potential metadata request in the api. (It's missing currently) Given that data, when you get the latest version of a charm, you'd get a list of previously published versions to facilitate the upgrade/downgrade UI. It seems this would help you with the publish counts? Most of the other data around revisions and bugs we'll do our best at, but will be sacrificed information so that users can publish a charm or bundle from any vcs. What other metadata should be make sure is addressed? You had requested an all charms/bundles api call in the last revision of the doc and we're looking at addresssing that through search results. The doc doesn't say that search can be used to list all charms and bundles. If you meant it to be used that way, please say so in the doc ;-) Sure thing, thanks for pointing it out. Search provides results for only the most recent revisions. It can stand in for step 1 2 of our algorithm, but in order to implement 4 and 5 efficiently, we'd need to do multi-id queries. With the previous rev metadata we're missing but also required by the juju-gui I think we can resolve this with the current api implementation. Let me know if there's more we need to address. Thanks for reviewing the doc and providing feedback. We're very much hoping to build out a strong consistent api we can use for a long time going forward. -- 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: Proposed new charm store API
Thanks Aaron, can you add the information and arguments you'd like to make to the doc. Perhaps add a Missing to the doc and provide the information you'd like to see returned and such there. Does this need both charms and bundles? As two calls, in one call, etc. Rick On Tue, 08 Jul 2014, Aaron Bentley wrote: I haven't gotten a response on this. juju-reports needs to generate statistics across all charms, like the published charm revisions shown here: http://reports.vapour.ws/scorecard How will it get data on all revisions of all charms? stats/counter/archive-upload:*?list=1by=week ? Aaron On 14-07-07 11:04 AM, Aaron Bentley wrote: Thanks. One thing juju-reports needs is a list of all the charms. I think the API spec doesn't include that. Aaron On 14-07-07 05:14 AM, roger peppe wrote: Francesco Banconi and I have produced a possible specification for the new charm store API, combining features from the existing charm store API and the charmworld API. Please take a look and see if it correlates reasonably with your own needs. https://docs.google.com/a/canonical.com/document/d/1ILHRpOe-qDlmjxHBbLUea7InDpehx5_roJ1ynZmcZDc -- 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: Proposed new charm store API
The idea is that the charm store is growing a lot since the original api was done. It's gaining a first class entity in bundles, it'll be growing identity support, search functionality, and other metadata. The api space is growing and needs to be able to be consistent with other tools as they're pulled together to provide a single JAAS api. Now is a good time to revisit how the api would look today if we knew then what we all know now and see coming. The work here is meant to bring together the apis of the store, charmworld, and future tasks. We appreciate feedback in making it the best and most clear api we can put together that can stand up to the next years of work. Rick On Wed, 09 Jul 2014, Gustavo Niemeyer wrote: Is there a reason to reinvent the API from the ground up, instead of extending what exists today? On Mon, Jul 7, 2014 at 6:14 AM, roger peppe rogpe...@gmail.com wrote: Francesco Banconi and I have produced a possible specification for the new charm store API, combining features from the existing charm store API and the charmworld API. Please take a look and see if it correlates reasonably with your own needs. https://docs.google.com/a/canonical.com/document/d/1ILHRpOe-qDlmjxHBbLUea7InDpehx5_roJ1ynZmcZDc -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Thoughts to keep in mind for Code Review
We've tried to encourage what we call 'reviewer comments' that are intended to be to help the reviewer follow the code. There are definitely two chunks of things that tend to get written. It's quite often to find a reviewer comment that the reviewer then suggests is put into the code itself. However, there's value in comments that help explain how the system works in the around the code touches. Not everyone is an expert on every section of the code, and seeing a review diff doesn't always give you enough context to really understand why the change helps. It's particularly useful in the case of drive-by fixes to help note This is a drive by, not part of the bug, etc. I'd argue it's very valuable but true that often some of the comments belong in the code. Rick On Wed, 25 Jun 2014, Ian Booth wrote: -1 on annotations. If you need to annotate to make it clearer then that should be done as code comments so the next poor soul who reads the code has a clue of what's been done On 25/06/14 14:20, John Meinel wrote: An interesting article from IBM: http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/ There is a pretty strong bias for we found these results and look at how our tool makes it easier to follow these guidelines, but the core results are actually pretty good. I certainly recommend reading it and keeping some of it in mind while you're both coding and reviewing. (Particularly how long should code review take, and how much code should be put up for review at a time.) Another trick that we haven't made much use of is to annotate the code we put up for review. We have the summary description, but you can certainly put some inline comments on your own proposal if you want to highlight areas more clearly. John =:- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Bundles proposal
On Fri, 20 Jun 2014, Cory Johns wrote: I think that is what Ben is talking about, that as we move bundles into the core as first-order entities, that is the correct time to address expanding their scope to include the additional functionality we have realized they should cover. This is a move into the Juju store, which is slightly different from juju-core. It's more about storage and the ability to juju publish a bundle and we'll have to look at some form of juju deploy of the bundle, though that creeps into the realm of replacing the deployer and is another chunk of work. I don't think that the scope of work at this time can look into the full featured stacks with tracking the changes/upgrades over time. What we've found that we need from a stack (ere bundle) is the ability to encapsulate the intelligence to handle upgrades that include modifications to the topology, providing logic to perform the transition on an existing system, while retaining the overall identity of the bundle. As a concrete example, with CF we are in the position that we expect an upgrade from one CF release to the next to potentially include splitting an existing service into two distinct services, or merging two existing services into a single new service. We can sometimes handle the former case by simply having the charm be responsible for both new services, but that isn't always ideal, and it still doesn't cover the second case. Yes, I think we agree that the feature set of full stacks would be useful, but that's beyond the current scope of work at this time. Thanks for checking out the proposal. -- 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: Bundles proposal
On Thu, 19 Jun 2014, Benjamin Saller wrote: Some of my recent work with charming Cloud Foundry has led us towards a slightly different understanding of bundles. In the case of something like cloud foundry the topology will change between releases of their code, in version 'b' they might add a new service that 'a' didn't have and in 'c' they might replace two existing components with a new one that subsumes them. In cases like this being able to preserve identity in the runtime is a very interesting feature of 1st class bundle support. Right now a bundle IsA topology but in our depiction it HasA topology. While I have no proof that service spanning identity that survives mutation is general enough to inform these requirements it really is something we want to deal with. Haven't we talked about this type of content as a different data type though than a bundle? Is this something we should work towards at this time? I also understand that in some world views a bundle would represent a supportable collection of services and this might imply the topology is fixed but any complex system that evolves is likely to have some topology mutation. While we can manage this without first class support it would be difficult to expect the GUI to the the 'right' thing for our project unless bundles include this idea. I'm not sure I completely follow here. The idea is to get a model for a topology definition. In the GUI we can allow users to deploy the toplogy in 'ghost' form and then mutate it before submitting it to the environment to construct it. If we move the idea of the uncommitted state down into juju core then the same idea could be possible via cli invocation of a bundle. I'm not sure why bundles have to include the idea of mutation itself. I'm nervous about things that make bundles not able to be reused as much as possible because they cannot stand alone. -- 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: End Of Review marker
We try to put a main comment on the review. Having inline comments does not complete the review. So after going through the diff, we go back to the main pull request and leave a comment there. This looks good but I had a few concerns about how it's tested. Please don't forget to update the docs as well. Looking forward to this change. It kind of wraps it up. The other thing we often do is ping in irc that the review is :+1: or 'comments sent'. https://github.com/juju/juju-gui/pull/328 is kind of an example conversation. Rick On Thu, 12 Jun 2014, Ian Booth wrote: It's also the same when you are responding to review comments. You want to mark them all as Done (or whatever) and have those go out in a batch to let the reviewer know they can come back and +1. Surely we're not the only people annoyed by this? I wonder what more experienced github users do. Or maybe people know that github sucks for code reviews and use gerrit or something else? On 12/06/14 20:38, Horacio Duran wrote: Hey, I don't know if this bugs everyone or just me but it happens very often that I am working while people are reviewing my code on gh. While people is reviewing and commenting on the code I keep getting mails and the diff page from the pr keeps changing. To know when its all done and I can finally try to answer/fix all the comments I usually wait until my phone stops ringing madly with mails but I think that we could do better. At the end of the diff page there is a comment box where you can add comments (where you usually add your $$merge$$ or LGTM) We could add something there, like Done just to let the author know we are done with the review and not just reading a big confusing chunk of code. What do you people think? -- 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
I've been wanting to get a few minutes of spare time to try out reviewboard. It's python based, has a charm (though it's outdated) and is supposed to be nice to use, though I've not used it in any anger yet. http://www.reviewboard.org/ Rick On Fri, 06 Jun 2014, Menno Smits wrote: If we're finding too many shortcomings with the GH code review system we could look at Gerrit or something else. It looks like people have already done Gerrit/Github integration before: http://gerrithub.io/ http://www.packtpub.com/article/using-gerrit-with-github On 6 June 2014 12:06, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Thu, Jun 5, 2014 at 9:26 PM, roger peppe rogpe...@gmail.com wrote: On 5 June 2014 14:22, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Thu, Jun 5, 2014 at 9:02 PM, roger peppe rogpe...@gmail.com wrote: On 5 June 2014 05:07, Menno Smits menno.sm...@canonical.com wrote: One nice feature is that old comments are hidden if the area of the code they reference is changed by a later diff. I consider this a serious shortcoming. I generally want to see all the conversation for a given code review. Is it possible to reveal the old comments somehow? See the comment history on: https://github.com/juju/juju/pull/8 - I proposed, and jam made some comments - I addressed the comments in a new commit, rebased and squashed it into the old, and did a git push -f There's now a jameinel commented on an outdated diff. Click on Show outdated diff to the right, and you can see the old comments. (I was under the impression that old comments got dropped altogether after rebase. Not sure if behaviour in GitHub changed at some point, or if it was always like this...) Ah, that's better than I thought, thanks. Is there a straightforward way of seeing the changes made in response to a particular I(outdated) comment? That's something I did almost every time in Rietveldt. Not AFAIK. I miss this too. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: store migration
On Tue, 20 May 2014, David Cheney wrote: A possible plan is as follow: 1) Migrate juju-core/thirdparty to juju/thirdparty (Github). Since there are no dependencies here, this seems to be a good first candidate. nac, these are out horrors. The code we forked should either be pushed back upstream, and/or captured by godeps. I think the whole thirdparty thing happened before we had godeps. Good to know, we can investigate. 4) Migrate juju-core/charm. This has some pre-requisites. Basically IIUC charm defines config and meta and those definitions are tangled with the underlaying Mongo documents. William suggested to decouple that, implementing separate data structures to be used to (de)serialize data. This way, changes to charm database structure can be detected earlier and core developers are able to react accordingly. Soon this could also involve actions data. I don't see the value in splitting off this repo unless you need it for the store. I think we'll want it as we'll be doing validation and such. This one will take the most care and investigation as what a charm is to the store should match what core expects from the charm. Thanks for the feedback. -- Rick Harding -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: github code reviews
On Mon, 10 Mar 2014, Jonathan Aquilina wrote: I have two suggestions that might help, but first let me tell you a bit about myself. I am project manager for LMMS (Linux Multimedia Studio) and we recently started using github for our version control hosting. With this we started using continuous integration provided free of charge by Travis CI. It is very easy to integrate into a github repo by just adding a YAML file if I am not mistaken. Once that is in place every commit triggers a build on the Travis CI build machines. It as well on the pull requests tells you if the build passes. If it does not it also alerts the committer that the build has failed so that it can quickly be fixed. We originally looked at this for the Juju GUI but we could not use it. Travis does not support the idea of a 'landing test run'. If your code review takes a few days, the trunk that you ran in Travis could be changed enough that your code no longer passes CI. This is why we went with Jenkins and wrote the lander [2] tool. It forces a final CI pass and automates the landing to the trunk branch. I did reach out to the Travis folks and their reply was that they did not think this idea of the post-review test/land work was part of their mission and were not interested in adding support for it. I'm not sure how they have that logic myself though. [2] https://github.com/juju/jenkins-github-lander Rick -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: github code reviews
On Fri, 07 Mar 2014, Nate Finch wrote: I like github. I don't like in-line diffs and one email per code review comment, which is all github provides. So I did a quick google, and this came up: https://review.gerrithub.io/#/c/2160/2/roles/packstack/rdo/tasks/main.yml it looks pretty good. http://gerrithub.io/ There's a chrome extension for enabling side by side diffs I've been using as well. https://chrome.google.com/webstore/detail/octosplit/mnkacicafjlllhcedhhphhpapmdgjfbb -- 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
