Re: Bootstrap Constraints
On 10/19/2016 11:45 PM, James Beedy wrote: > Team, > > From what I can gather, Juju either allows or disallows you to bootstrap > to a specific network/subnet dependent on whether or not the provider > supports a network space bootstrap constraint. The EC2 provider just so > happens to be one of the providers which doesn't support controller > placement on bootstrap. This is a massive problem for me, seeing as I > have many subnets for things other than controller nodes. I just can't > seem to get the controller to land in a subnet (seems to be chosen at > some sort of random) that doesn't already have other things in it that I > don't want around my controller. To facilitate bootstrap network > constraints on the EC2 provider, I think a 'network' constraint is > needed, along with some filtering of the provided 'network' constraint > value to ensure the subnet exists, is in the current region and current > vpc - seems like it might do the trick until we have a flat model for > controller placement that works across all providers. > > Thoughts? > > Hey James, Sorry for the late reply! The EC2 provider does not support the tags= constraint, and it has limited support for the spaces= constraint - but not for the controller, as at bootstrap time no spaces are yet defined. So unfortunately you can't yet explicitly specify where a controller instance will end up on. To allow explicit placement for EC2 instances, including Juju controllers, we could (trivially) implement support for `--to subnet=` placement (like the existing - and supported - `--to zone=`). Then you could do `juju bootstrap ... --to subnet=172.31.5.0/24` (with or without --config vpc-id=vpc-xyz) to achieve what you want. Thoughts? Cheers, Dimiter -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> signature.asc Description: OpenPGP digital signature -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Github Reviews vs Reviewboard
+1, Nate said what I was thinking :) On 10/14/2016 05:34 PM, Nate Finch wrote: > +1 > > Keeping the PR and reviews together really makes it easier for me to > keep track of what's going on with a PR. It's also really nice not > having to context switch out of github for every single PR. > > Reviewboard and related infrastructure breaks like once couple weeks, > and I'm not convinced it'll get better, since we've been using it for > quite some time now. > > I have missed exactly zero of the features of reviewboard since using > github, and haven't really cared about the drawbacks of github. > > One point - you *can* minimize comments in the files view - there's a > checkbox per file that will hide the comments in that file. > > On Fri, Oct 14, 2016 at 8:22 AM roger peppe <rogpe...@gmail.com > <mailto:rogpe...@gmail.com>> wrote: > > On 14 October 2016 at 12:45, Adam Collard > <adam.coll...@canonical.com <mailto:adam.coll...@canonical.com>> wrote: > > Not sure I get a vote, but -1 > > > > You're running an old version of ReviewBoard (2.0.12 released in > January > > 2015) and many of the issues I think you've been hitting are fixed > in later > > revisions. Latest stable is 2.5.6.1, 3.0.x is under active > development and > > brings a chunk of new UI improvements. > > > > Release notes for 2.5 > > > > 3.0 demo site > > I'm still not convinced. > > Even 3.0 still deletes draft comments without so much as a by-your-leave > when you double-click somewhere else in the text. And because it > doesn't use > real text entry boxes, the Lazarus plugin, my usual saviour in such > cases, > doesn't work. I've lost far too much time to this in the past. > > Replying to a comment still involves a page reload and associated > lost context. > > I can't see anything in the 2.5 release notes about fixing behaviour > on file > move/rename, though I may well have missed it. > > And not being able to deal with really large PRs is a definite issue > too (not > that github is better there). > > cheers, > rog. > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> signature.asc Description: OpenPGP digital signature -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Specify lxd container bridge
Hey Corey, That specific error I haven't seen at that stage - allocating container addresses. Can you please paste the machine-0.log as well? Are you able to consistently reproduce this or it's intermittent? Cheers, Dimiter On 09/17/2016 12:17 AM, Corey Bryant wrote: > > > On Thu, Sep 1, 2016 at 4:25 AM, Dimiter Naydenov > <dimiter.nayde...@canonical.com <mailto:dimiter.nayde...@canonical.com>> > wrote: > > Hello! > > When using juju 2.0 on maas 1.9 or 2.0, you should get lxd containers > provisioned with as many interfaces as their host machine has, because > we're creating bridges on all configured host interfaces at initial boot > (e.g. eth0 becomes br-eth0, ens4.250 - br-ens4.250 and so on). Nothing > needs configuring to get this behaviour, but there's a caveat: > > In order for the above to work, there's a limitation currently being > addressed - all interfaces on the host machine in MAAS need to be linked > to a subnet and have an IP address configured - either as Static or > Auto, but not DHCP or Unconfigured. Otherwise the process of allocating > addresses for the container (represented as a MAAS Device, visible on > the host node's details page in MAAS UI under Containers and VMs) can > fail half way through and Juju will instead fall back to a the single > NIC LXD default profile, using lxdbr0 on a local subnet. You can tell > whether this happened, because there will be a WARNING in > /var/log/juju/machine-0.log on the bootstrap machine, like: `failed to > prepare container "0/lxd/0" network config: ...` describing the > underlying error encountered. > > Please note, the above limitation will be gone very soon - likely > beta18, not beta17 scheduled for release this week. In that upcoming > beta, unlinked or unconfigured host machine interfaces won't prevent the > multi-NIC container provisioning and address allocation - Juju will just > allocate addresses where it can, leaving the rest unconfigured, and not > falling back to using LXD default profile's lxdbr0. > > HTH, > Dimiter > > > Hey Dimiter, > > I'm hitting the same issue. I have all the interfaces linked to subnets > with auto but I still get the 'failed to prepare container "0/lxd/0"' > error message saying 'connection is shut down'. The containers are > still using lxdbr0 (see http://paste.ubuntu.com/23188824/ > <http://paste.ubuntu.com/23188824/>). The containers show up on the > nodes page with juju*-lxd-*.maas names. Do you have any other tips for > getting past this? > > Thanks, > Corey -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> signature.asc Description: OpenPGP digital signature -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Reviews on Github
As long as we can have draft reviews like on RB and not email-spam-per-comment, totally +1 On 09/14/2016 01:25 PM, Horacio Duran wrote: > Also +1 for that source not being review board > > On Wed, Sep 14, 2016 at 5:23 PM, Reed O'Brien <reed.obr...@canonical.com > <mailto:reed.obr...@canonical.com>> wrote: > > Also +1 for a single source of truth. > > On Wed, Sep 14, 2016 at 1:20 PM, Rick Harding > <rick.hard...@canonical.com <mailto:rick.hard...@canonical.com>> wrote: > > /me is always +1 on reducing the number of things we have to > maintain and keeping things simpler. > > On Wed, Sep 14, 2016 at 4:04 PM Nate Finch > <nate.fi...@canonical.com <mailto:nate.fi...@canonical.com>> wrote: > > In case you missed it, Github rolled out a new review > process. It basically works just like reviewboard does, > where you start a review, batch up comments, then post the > review as a whole, so you don't just write a bunch of > disconnected comments (and get one email per review, not per > comment). The only features reviewboard has is the edge > case stuff that we rarely use: like using rbt to post a > review from a random diff that is not connected directly to > a github PR. I think that is easy enough to give up in order > to get the benefit of not needing an entirely separate > system to handle reviews. > > I made a little test review on one PR here, and the UX was > almost exactly like working in > reviewboard: https://github.com/juju/juju/pull/6234 > <https://github.com/juju/juju/pull/6234> > > There may be important edge cases I'm missing, but I think > it's worth looking into. > > -Nate > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > <https://lists.ubuntu.com/mailman/listinfo/juju-dev> > > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > <https://lists.ubuntu.com/mailman/listinfo/juju-dev> > > > > > -- > Reed O'Brien > ✉ reed.obr...@canonical.com <mailto:reed.obr...@canonical.com> > ✆ 415-562-6797 > > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > <https://lists.ubuntu.com/mailman/listinfo/juju-dev> > > > > -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> signature.asc Description: OpenPGP digital signature -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Specify lxd container bridge
Hello! When using juju 2.0 on maas 1.9 or 2.0, you should get lxd containers provisioned with as many interfaces as their host machine has, because we're creating bridges on all configured host interfaces at initial boot (e.g. eth0 becomes br-eth0, ens4.250 - br-ens4.250 and so on). Nothing needs configuring to get this behaviour, but there's a caveat: In order for the above to work, there's a limitation currently being addressed - all interfaces on the host machine in MAAS need to be linked to a subnet and have an IP address configured - either as Static or Auto, but not DHCP or Unconfigured. Otherwise the process of allocating addresses for the container (represented as a MAAS Device, visible on the host node's details page in MAAS UI under Containers and VMs) can fail half way through and Juju will instead fall back to a the single NIC LXD default profile, using lxdbr0 on a local subnet. You can tell whether this happened, because there will be a WARNING in /var/log/juju/machine-0.log on the bootstrap machine, like: `failed to prepare container "0/lxd/0" network config: ...` describing the underlying error encountered. Please note, the above limitation will be gone very soon - likely beta18, not beta17 scheduled for release this week. In that upcoming beta, unlinked or unconfigured host machine interfaces won't prevent the multi-NIC container provisioning and address allocation - Juju will just allocate addresses where it can, leaving the rest unconfigured, and not falling back to using LXD default profile's lxdbr0. HTH, Dimiter On 08/31/2016 10:32 PM, Chance Ellis wrote: > Hello, > > > > I am running juju 2.0beta16 on trusty. I have a maas 2.0 rc4 cloud > bootstrapped. > > > > I am able to deploy services to lxd containers on xenial, but when I do > so, the container’s NIC is attached to lxdbr0 which seems to get some > arbitrary IP segment which in turn gives the container an IP from the > same segment. Is there a way I can instruct juju to specify the > bridge(s) I would like the container to use during deployment? > > > > Thanks! > Chance Ellis > > > > > > > -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> signature.asc Description: OpenPGP digital signature -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: network spaces - aws support
Hey James, Can you please also paste the full logs (scrubbed of secrets) of `juju bootstrap ... --debug` (with the vpc-id etc., but please also include `--config logging-config='=TRACE'`), and machine-0.log from /var/log/juju on the bootstrap node, once completed? That will help figuring out the issue. From what I can understand, you're trying to bootstrap on a non-default, possibly private VPC (accessed via its internal address over a VPN connection maybe?), and then add a model with the same VPC and credentials. If OTOH, the VPC used for add-model is different, the machines there won't be able to talk to the controller's VPC unless it has a public address (cross VPC communication currently relies on having that, fancier setups with VPN gateways is not yet supported). The error in status implies 2 separate VPCs are used (or a VPC and EC2-Classic - i.e. no VPC) for the controller and hosted model. Cheers, Dimiter On 08/02/2016 01:04 AM, James Beedy wrote: > Thanks, Marco. > > `juju status --format yaml` <- http://paste.ubuntu.com/21818491/ > > The messages for the machines show "Security group sg-9d6c8ce7 and > subnet subnet-930c61b8 belong to different networks. (InvalidParameter)'" > > This seems odd, as the subnet I've bootstrapped to is 'subnet-930c61b8' > > On Mon, Aug 1, 2016 at 2:53 PM, Marco Ceppi <marco.ce...@canonical.com > <mailto:marco.ce...@canonical.com>> wrote: > > What does `juju status --format yaml` produce? it should provide > more fruitful machine errors. > > Marco > > On Mon, Aug 1, 2016 at 5:46 PM James Beedy <jamesbe...@gmail.com > <mailto:jamesbe...@gmail.com>> wrote: > > I'm having some issues with deploying instances to network > spaces on aws. > > Problem: Instance errors on deploy > > I have successfully bootstrapped into my aws vpc with `juju > bootstrap mycloud aws --credential mycred --config > vpc-id=my-vpcid--config force-vpc-id='true' --upload-tools` and > subsequently created a model on my aws controller in the vpc > with `juju add-model my-new-model -credential mycred > --config vpc-id=my-vpcid --config force-vpc-id='true'`. > Following which, I add a network space, and then my subnet > -> http://paste.ubuntu.com/21814798/. Ok, everything looks great > so far then I go and launch an instance and it all falls > apart -> http://paste.ubuntu.com/21815678/ > > Any insight into what is going on here would be greatly > appreciated. Are these network spaces ops even supported on aws? > > ~thanks > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > > -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> signature.asc Description: OpenPGP digital signature -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: go test github.com/juju/juju/state takes > 10 minutes to run
Thanks Roger, I'll give your tool a try for sure! > localServerSuite.TestStopInstanceSecurityGroupNotDeleted 29.152 I've already filed a bug and a tech-debt kanban card for that slow test in provider/openstack, and it's indeed a low hanging fruit: https://bugs.launchpad.net/juju-core/+bug/1580626 Cheers, Dimiter On 05/20/2016 10:26 PM, roger peppe wrote: > A bit more info for those interested, I ran all the juju tests through > that tool: > > go test -p 1 -v -timeout 60m github.com/juju/juju/... -check.vv > 2>&1 | timestamp > > and this is what it said: > > total suites 1219 > total test time 49m10.093s > total suite time 1h18m9.061s > total setup test 14m27.71s > total teardown test 1m10.401s > total setup suite 35.9s > total teardown suite 28m41.037s > total fixture overhead 44m55.048s > longest test 5m1.207s ( serverSuite.TestNewServerDoesNotAccessState) > setup 276ms teardown 19ms > overall time 1h18m29.001s > > For the record, it produced just under 75 lines of output (61MB) > > The top 10 longest tests are these: > > serverSuite.TestNewServerDoesNotAccessState 301.207 > StatusHistorySuite.TestPruneStatusHistoryBySize 83.978 > UniterSuite.TestActionEvents 41.471 > localServerSuite.TestStopInstanceSecurityGroupNotDeleted 29.152 > UniterSuite.TestUniterRelations 21.693 > ShowOutputSuite.TestRun 18.056 > StatusSuite.TestStatusAllFormats 15.697 > oplogSuite.TestWithRealOplog 15.503 > kvmProvisionerSuite.TestContainerStartedAndStopped 15.465 > lxcProvisionerSuite.TestContainerStartedAndStopped 15.366 > > I suspect there's a bunch of low hanging fruit that can > be picked to speed up the tests. > > cheers, > rog. > > > > On 17 May 2016 at 03:52, David Cheney <david.che...@canonical.com> wrote: >> Testing this package takes 16 minutes on my machine*; it sure didn't >> use to take this long. >> >> What happened ? >> >> * yes, you have to raise the _10 minute_ timeout to make this test run. >> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev > -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> signature.asc Description: OpenPGP digital signature -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: openstack provider: hints about physical machines
On 05/13/2016 12:30 PM, Eddy Truyen wrote: > Hi, > > In openstack I often use the *--availability-zone nova: physical server>* option in the *nova boot* command to control the > placement of my openstack instances on physical machines of my openstack > cloud infrastructure > > Is it possible to specify this constraint as part of the *--constraint* > option in the *juju machine add command*? > > Best regards, > > Eddy > > Hey Eddy, Yes, you can use `juju add-machine zone=name` to place a machine within a zone. It's not a constraint, but a placement directive. See `juju help add-machine` for docs and examples. Cheers, -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> signature.asc Description: OpenPGP digital signature -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: compute-data network
On 05/04/2016 10:57 AM, Dimiter Naydenov wrote: > On 05/03/2016 10:07 PM, James Beedy wrote: >> Hello All, >> >> After reading Dimiter's >> post: >> https://insights.ubuntu.com/2015/11/08/deploying-openstack-on-maas-1-9-with-juju/, >> I have some questions regarding the network implementation. >> >> Can someone please link me to some docs describing the intrinsics of >> what a 'compute-data' network is? What services communicate on the >> 'compute-data' network? How is 'compute-data' network >> recognized/consumed by openstack charms and subsequent openstack services? >> >> Thanks! >> >> >> > Hey James, > > The compute-data network is used for guest VM traffic (instances started > by OpenStack) to other guest VMs or to OpenStack services. > If you have a look at the first post in the series, the architecture > diagram shows the different networks OpenStack uses (the ‘data’ network > there is called ‘compute-data’ in later posts, to distinguish it from > the ‘storage-data’ network). > > As for how the charms are configured to use those networks, I'm sure > some of the openstack charmers here can give you a more detailed answer. > > Cheers, > > > Sorry, I figured out you might be missing the link to that first article with the OpenStack diagram, so here it is: http://blog.naydenov.net/2015/11/deploying-openstack-on-maas-1-9-with-juju-network-setup/ -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> signature.asc Description: OpenPGP digital signature -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: compute-data network
On 05/03/2016 10:07 PM, James Beedy wrote: > Hello All, > > After reading Dimiter's > post: > https://insights.ubuntu.com/2015/11/08/deploying-openstack-on-maas-1-9-with-juju/, > I have some questions regarding the network implementation. > > Can someone please link me to some docs describing the intrinsics of > what a 'compute-data' network is? What services communicate on the > 'compute-data' network? How is 'compute-data' network > recognized/consumed by openstack charms and subsequent openstack services? > > Thanks! > > > Hey James, The compute-data network is used for guest VM traffic (instances started by OpenStack) to other guest VMs or to OpenStack services. If you have a look at the first post in the series, the architecture diagram shows the different networks OpenStack uses (the ‘data’ network there is called ‘compute-data’ in later posts, to distinguish it from the ‘storage-data’ network). As for how the charms are configured to use those networks, I'm sure some of the openstack charmers here can give you a more detailed answer. Cheers, -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> signature.asc Description: OpenPGP digital signature -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Extra Network Bindings for Charms
Just to confirm the implementation to support the extra bindings has started and should be available for early testing tomorrow, in the maas-spaces2 feature branch. Cheers, Dimiter On 1.03.2016 11:24, John Meinel wrote: > As we discussed how the Juju network model was going to map network > spaces into IP addresses for charms, the Openstack charmers noted that > it wasn't sufficient to just provide networking configuration for > existing relations. There were several places where the Openstack charms > needed a way to expose a workload onto the network, but whose > configuration information was already well handled by the existing > relations. They liked being able to move the mapping of subnets,etc from > being just config in a charm into being pieces that system operators > could map at deploy time. > > The best solution that we've come up with is to add a new section to > charm metadata.yaml. At a similar level to provides/requires/tags we'd > add a field for "extra-bindings". Entries in this list end up being > available for "juju deploy charm --bind =", but > don't have the same set of charm hooks that will be fired for their > lifecycle. > > We're pretty happy with what we've come up with after a fair amount of > trying out different possibilities. We'd like to open it up to a bit > wider discussion in case there are use cases that we didn't realize we > missed. (We certainly know about a few cases that we are intentionally > not supporting with this, in an effort to preserve compatibility and > simplicity.) > > If you're interested in this space, let us know what you think, > Juju Extra Network Bindings < > https://docs.google.com/document/d/1pKORpWSitOk7C_HMNBaO36-Ht1b3lT86bOWTy9jPMDQ/edit?usp=sharing> > > Thanks, > John > =:-> > > PS> For James Page and other's that have already looked at this > document, can you give it a once over. I pulled out some of the > alternatives to make it more focused, and want to make sure that I > haven't lost cohesion in the final draft. > > -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> signature.asc Description: OpenPGP digital signature -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: EC2 VPC firewall rules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18.02.2016 12:01, Tom Barber wrote: > Hello folks > > I'm not sure if my tinkering has broken something, the fact I'm > running trunk has broken something or I just don't understand > something. > > Until last week we've been running EC2 classic, but we have now > switched to EC2-VPC and have launched a few machines. > > juju ssh to these machines works fine and I've been configuring > them to suit our needs. > > Then I came to look at external access, `juju expose mysqldb` for > example, I would then expect to be able to access it from the > outside world, but can't unless go into my VPC settings and open > the port in one of the juju security groups, at which point > external access works fine. > > Am I missing something? > > Thanks > > Tom > > Hey Tom, What you're describing sounds like a bug, as "juju expose " should trigger the firewaller worker to open the ports the service has declared (with open-ports within the charm) using the security group assigned to the host machine for all units of that service. Have you changed the "firewall-mode" setting by any chance? Can you provide some logs from /var/log/juju/*.log on the bootstrap instance (machine 0)? Cheers, - -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJWxaAXAAoJENzxV2TbLzHwGgEIAIuj0sPzh7S/4jvTQ6aA/dwP i7WkSZ586JkNbEFeCBjDavO6oZFOwIAEW+EpGuy1C0O8BJr5Y2YJBMR96pdf3Rj/ Y6xS4Byt0HrwCWixt7ut6zu7BsT+nv6YFO7fNQvNYLyroufzpqUKaALJp5xwedkJ JIx1iyLnAZ4ZC1/0VkoBM/UjbZN7xQIteNvChBCZSSk8RvbqXCKhbXZKuUKMAw5g R+D3wIwLEyZHb5SATcSSdE6nidv4A0F2waac1/3lOvFebeOsnapnRKkIDp3Y9v19 /zDiDLWSJJvMDau8iIzSQ4STK/sLEmA78iRNkfDRWRifv0z1KkY6ppnhaS+jrj4= =kPA7 -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: juju-br0 vs lxcbr0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9.11.2015 04:23, Pshem Kowalczyk wrote: Hi Pshem, Any chance you've used JUJU_DEV_FEATURE_FLAGS=address-allocation during bootstrap? Can you have a look at /var/log/juju/machine-0.log? In the beginning there should be lines like: "address allocation feature disabled; using juju-br0 bridge for all containers" or alternatively: "address allocation feature enabled; using static IPs for containers: juju-br0" Cheers, Dimiter > Hi, > > I'm using MAAS and juju using lxc containers to spin up openstack > components. I regularly destroy my enviornments to try some new > settings. (juju 1.25, MAAS 1.8.2) > > Initially my setups would create a juju-br0 that contained eth0 and > then bridged all LXCs to it (this way I could use MAAS DHCP to give > IP addresses to containers). Somehow, between one test and the > other juju is not creating juju-br0 any more, and my LXC containers > end up living in lxcbr0 space with own DHCP server that gives them > 10.0.3.0/24 <http://10.0.3.0/24> IPs (which breaks connectivity > with anything outside of the machine) > > Clearly I must have changed something in my config, but my whole > definition of MAAS environment is quite simple: > > maas: type: maas maas-server: 'http://10.201.7.219/MAAS/' > maas-oauth: 'key here' bootstrap-timeout: 1800 lxc-default-mtu: > 9000 lxc-clone: true allow-lxc-loop-mounts: true > > and I don't recall modifying it. > > How can I get back to juju-br0 (that joins eth0 and assumes its IP > address)? > > kind regards Pshem > > > - -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWQEdiAAoJENzxV2TbLzHwdrcH/0WAQ0DVqK9PWVkHnpWsIUVQ kKGfpESiEpj/uR2OpZ5ijzKdIRBY/DRZyuvLEv2EUta4cx6irb8P9k0M66X3+7ub N3sXwK1m/b0I9H1u50dq269xwhUIS4Lu+pVdlIExZIbX8/9P0KxgARi3UXiBeAC7 5mawWFN7Pamxrnd0qZp6CGqExnC77q0vLLOqWXOewXkdBuIht6gEdq1+94e1ktVv 64rr7LI5sEY1j+v/HgeuZi8CPi44fNUTD3MEVtc6Ow2XSNU63b9xmrp40jE2iU55 islAdQU+VuUsyrcdp9hD1+6IiPcq/R82SIANumnPaNE7ONnRhHFOhhSxobZhYHo= =T2Fq -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju stable 1.25.0 is released
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30.10.2015 01:06, Pshem Kowalczyk wrote:
>
> Hi
>
> On Fri, 30 Oct 2015 at 08:03 Curtis Hovey-Canonical
> <cur...@canonical.com <mailto:cur...@canonical.com>> wrote:
>
> {cut}
>
> ### Support "devices" on MAAS 1.8+
>
> MAAS 1.8 introduced a new feature called "devices". This allows
> the association of a "device", that requires an IP address, with a
> parent machine managed by MAAS. There is a view in the MAAS UI
> showing all devices.
>
> With the "address-allocation" feature flag enabled, Juju will
> register LXC and KVM containers as devices on MAAS 1.8+. They are
> visible in the MAAS UI. If the environment is forcibly shut down,
> the IP addresses allocated to the containers will be released by
> MAAS.
>
> You can enable "address-allocation" is new Juju environments like
> so:
>
> JUJU_DEV_FEATURE_FLAG=address-allocation juju bootstrap
>
>
>
> Are they any other requirements in order to get the "devices"
> feature working? I've just built a brand new MAAS
> (1.8.2+bzr4041-0ubuntu1) and juju (1.25.0, from PPA) setup,
> bootstrapped a new environment using the syntax provided above, but
> the containers are not getting registered under 'MAAS devices'.
>
This is because recently MAAS web UI changed not to show devices as
before. However, juju should still be registering them for containers
and this can be verified by using the MAAS CLI:
$ maas devices list
Cheers,
Dimiter
> kind regards Pshem
>
>
>
- --
Dimiter Naydenov <dimiter.nayde...@canonical.com>
Juju Core Sapphire team <http://juju.ubuntu.com>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJWNx98AAoJENzxV2TbLzHwHaYIAKTrTftizH3fylyWSoOnbKJC
GcqofRaFd+g40bzvo2ZXMDHy3Tj2GhchrjKstP4pIfgDF3XnPKd6Q8g48+fyqXYJ
zIxmbrWr+RBjGdUPiW+uqaRB7E6i7EazOs4X0/XyJeMbx7TdrqD8d/0+i/Sv5Y/Y
EalgXIr8kciOhHw6IkNfBAMK6nxd2yAKxveWzPGD7z8wPBtDR5Y3PjmQHqevFf9Q
ofya8Z8TV0HFZHxb/ZAkkuLpxu9OXv69ReOux9Ai1MaGVEuEM2hMgv+MbC3RhlII
ZimTBotyzJckIi+IHL8UDOaOvsG6qAq9kA5FdUrlXhAfkPu66nEEK8bkTHVxuzk=
=foku
-END PGP SIGNATURE-
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: LXC container and DNS names
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29.10.2015 03:03, Pshem Kowalczyk wrote: > Hi, > > > I'm running a stable version of juju (1.24.7-trusty-amd64) and > maas (1.8.2+bzr4041-0ubuntu1 (trusty1)). I use maas to manage DHCP > and DNS on the 'bootstrap' network. > Yes, in fact registering containers in MAAS (along with their MACs, hostname, and parent instance) is what I'm working on currently. This will allow MAAS to release the resources allocated to containers (so far just IP addresses - static or DHCP-provided leases) when Juju destroys a container, its parent instance, or the whole environment (gracefully, i.e. without --force, or with --force, bypassing the usual shutdown Juju performs and relying on MAAS to do it instead). This will be the default behaviour starting from 1.24.8, and also will apply the upcoming 1.25.0 release, as well as all future releases. In order to be able to do that, for MAAS environments, Juju will require at least MAAS 1.8+. Containers will be registered as devices, and will have hostnames like "juju-machine-1-lxc-2.maas" (assuming regular instances get hostnames like "distinct-town.maas"). See bug https://bugs.launchpad.net/juju-core/+bug/1483879 for updates on when this feature will be available for early testing, or alternatively wait for the 1.24.8/1.25.0 releases. Regards, Dimiter > > I would like to know if it's possible to get juju to register the > DNS names for the containers it spins up. For example at this stage > I get: > > > > maascontroller:~$ juju status mysql > environment: maas machines: "0": agent-state: started > agent-version: 1.24.7 dns-name: controller.maas instance-id: > /MAAS/api/1.0/nodes/node-f2b1adb6-7603-11e5-a073-0050569a302e/ > series: trusty containers: 0/lxc/2: agent-state: started > agent-version: 1.24.7 dns-name: 10.0.0.148 instance-id: > juju-machine-0-lxc-2 series: trusty hardware: arch=amd64 hardware: > arch=amd64 cpu-cores=4 mem=65536M tags=4cpu > state-server-member-status: has-vote services: mysql: charm: > cs:trusty/mysql-29 exposed: false service-status: current: unknown > since: 29 Oct 2015 13:24:18+13:00 relations: cluster: - mysql > shared-db: - glance - keystone - neutron-api - neutron-gateway - > nova-cloud-controller - nova-compute units: mysql/0: > workload-status: current: unknown since: 29 Oct 2015 > 13:24:18+13:00 agent-status: current: idle since: 29 Oct 2015 > 13:34:53+13:00 version: 1.24.7 agent-state: started agent-version: > 1.24.7 machine: 0/lxc/2 public-address: 10.0.0.148 networks: > maas-eth1: provider-id: maas-eth1 cidr: 10.0.0.0/24 > <http://10.0.0.0/24> > > I would like juju to either create something like > juju-machine-0-lxc-2.maas (and preferably mysql-0.maas). Is this > possible? > > > kind regards > > Pshem > > > - -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWMhD1AAoJENzxV2TbLzHw4tgIAJKunUYnFq3GGQ3i5HbYT/mz AYD1RHpdL6vbph3egFJU7JJG1kIAapMz7ediOcU7XfGKlbIS4hjag3K042MQQyK/ TkFZOIzIVAhGIvvrGO5BpkSLQp6hOTjKKWPGppDsU9O7jUZo3rbHneVww3kNbTSl KDsLQHXZY1d1UCqX3OLsGQ/zUsgurcVQMjWVma+JygJkkNLJCKGkBdkQvqNJ/5jO 0T8gHJFpB3nrQfjQEt4Z2JJeX5OJLl0Zsil8vMxkPnVXjcNZQ7buPjsMght7eSOh OcnbNM8WOo2ANTdtw/FnjN0RNgzspTGRN1FLce+5LypvzOEjZbm4qC5DbsgJvRM= =b2W/ -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Awesome!! \o/ As a big fan of aliases (bash, git, etc.) I'd start using this right away with juju now! :) Thanks Tim! Dimiter On 23.10.2015 07:12, Tim Penhey wrote: > Hi folks, > > I scratched a personal itch yesterday and added the ability for > users to specify their own aliases for juju commands. > > There are two primary use cases that I was trying to address. > > Firstly, the ability to specify default flags for commands: status > = status --format=tabular > > I could never remember the right environment variable to set to > get tabular by default. > > The second was to allow quicker iteration around playing with new > CLI structure. As most people are aware, the 2.0 CLI is going to > be somewhat different to the current one, and I thought it would be > good to provide a way in which we could "test drive" the new CLI > with the existing codebase without having to actually code > anything. > > The aliases files lives in JUJU_HOME, and is a simple text file. > Each non blank line that doesn't start with a '#' is considered to > be an alias. The format is expected to be: > > = [...] > > So we can do things like: > > # stat is like two whole letters shorter... stat = status > --format=tabular > > # list tests list-environments = system environments list-users = > user list > > and so on. > > Tim > - -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWKeZDAAoJENzxV2TbLzHwOuMH/Rt5OqT29cGheVBNGraC0guR qYSyS8nqsSKb7gizmu9HrbJeQjpQfv+Dskc97yOXlxsQbhfBrFGHkkHl15jsKHBh XCx531/olNhs8Y9uqfI31SjMqRW4U0wylF4sVfMOpIsrTlJcuU7EQ8meYj0ObR7T RWv9Rg6pg6b6fQ5tylVV+8LjE6YyRUr+V+8rQp/PLwVrACJQqVyi+tL5UQKd53vj pgCqEbRJ/wN8fcQP7Pf6jh+FC84xecwmAd9Zc/toHXHh0ZYSKl022h0pPff/1XoB JQqGyH4SS7XAR3T6jiy6ub7wYCe0LgkPtl13nbcrWR1YYZK1pJxtH+kdkwfYaXk= =UrrP -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: state of networking?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Kapil, Sorry for not responding earlier. You raised some good points re non-default VPC support. My plan was to introduce the support for specifying a VPC ID to use, while also making sure initially Juju keeps the same behaviour and experience as if the VPC was a default VPC (hence the validation I mentioned). Once we have support for passing VPCID across the board in the EC2 provider, we can relax those requirements we're expecting the specified VPC to meet (e.g. just print / log a warning instead of refusing to use it). We do fully intend to support a VPC without public IPs etc. later this year, but first we need to solve the issue with API server nodes accessibility for all nodes in the environment (this requirement won't change as Juju agents need to be able to connect to the API server(s) regardless). As for the new features in coming up in 1.25, more documentation will be added in time for the release on how to use spaces etc. We're actively soliciting feedback on spaces support and their implementation. Only EC2 is supported for now and there are a few rough edges still (e.g. it's not *yet* working end-to-end, but it will be after I land a few fixes today in 1.25 and master). Cheers, Dimiter On 17.09.2015 15:09, Kapil Thangavelu wrote: > The network support listed in the 1.25 alpha release notes ( > https://lists.ubuntu.com/archives/juju-dev/2015-August/004721.html > ) looks pretty good, i'll give it a whirl. > > > On Tue, Sep 15, 2015 at 7:11 AM, Kapil Thangavelu > <kap...@gmail.com <mailto:kap...@gmail.com>> wrote: > > Its been hard to see much progress on this and i wanted to checkin > wrt to the current state. > > The requirement of public ip on for the subnets sort of defeats > the purpose of supporting non default vpcs. The use of vpc is > typically around network segmentation and isolation semantics, ie > db and app tier subnets don't have public ips by design. In fact at > larger orgs, its not typical that an app deployment team would even > have access to rearrange the network topology on demand. The > learned model of inform juju of the network topology for a given > env by defining/importing netspace/zone from extant subnets is more > typical. > > cheers, kapil > > > On Fri, Jul 24, 2015 at 3:44 PM, Dimiter Naydenov > <dimiter.nayde...@canonical.com > <mailto:dimiter.nayde...@canonical.com>> wrote: > > On 23.07.2015 22:57, Kapil Thangavelu wrote: >> I've talked to a few folk at some conferences, but i'm curious >> what's been happening in networking? > >> it feels like its been fairly long time w/ little visible >> progress on end user features. particularly i'm curious about aws >> (ie. the worlds biggest cloud :-).. more concretely - can i use >> existing (non default) vpcs? - can i create/use extant subnets >> across zones and specify them for services? - can i control >> routing between subnets or alternatively control/enforce iptables >> for a service based on extant relations (optional)? > >> afaics most of the network progress was in various client libs >> afaics over the last year (and a maas centric core network >> model)... are there any plans to switch out to the aws api sdk >> instead of maintaining a separate client lib? > >> thanks, > >> Kapil > > > > Hey Kapil, > > I can report some progress on the points you've asked about: 1) > non-default VPC support is mostly done - see bug > https://bugs.launchpad.net/juju-core/+bug/1321442, which I have > mostly finished fixing. In brief, there will be a "vpc-id" environ > setting that can be used to specify a non-default (but compatible) > VPC to use. By compatible at this stage I mean 2 things: at least > one subnet per AZ, all subnets in the VPC have MapPublicIPOnLaunch > set. 2) the AWS VPC support is ongoing in a feature branch, the > MVP proposal will include: add existing subnet to juju (make juju > aware of it); create a space including one or more subnets; deploy > a service within a space. 3) it's on the roadmap to do more > sophisticated routing/ACL/firewalling between spaces, but it won't > happen until the 16.04 time frame most likely. > > HTH, Dimiter > > -- Juju mailing list Juju@lists.ubuntu.com > <mailto:Juju@lists.ubuntu.com> Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > > > - -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJV+rgZAAoJENzxV2TbLzHw1mQIALgBwnhhcYoTgwyCU9shUpy2 I+YkbIeJ4wcpaEGAHjIWkKNYPfRiCK8MOyx+X9r0xI2enyztRBvoYwABLOwkMnP4
Re: Cheryl graduating
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1.09.2015 02:46, Tim Penhey wrote: > Hi folks, > > I have been very happy with the quality of Cheryl's reviews and the > time is right for her to be considered a fully graduated reviewer. > > Thanks for all the reviews Cheryl. > > Tim > Way to go, congrats Cheryl! :) - -- Dimiter Naydenov <dimiter.nayde...@canonical.com> Juju Core Sapphire team <http://juju.ubuntu.com> -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJV5XLGAAoJENzxV2TbLzHwyQIIAKdquqyMiquGsqr4l6Q/XF1s ksf7OpGPUQ4k+Ici3Sw0dUr5sQSwabNYHcKzKA75fD7kC/54TmXlygZinQz6npOf perZRWtclv6xU5XMwaauwrhefqy8Cb0v9qGYB+LZldI2lsbp6wg+JMw91C8Qjxho zuKQ1JESHzyXEfLqL1NvNvbh6amZvOviN8sWHVRnnivzt0FcFdspoUKfpf/H0zzG B1Rmb2OpYBREmZctCUzk0TCV05WL9h2khvAEUtvY3z/mmajl0visqF/jtmQVxCRW tpekxPzHadPSscF/TTCEwDMHPDiYM8NssiKfBDUNDjUOofVwy8D4hLr31i7b+BU= =sDmo -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: bootstrap constraints
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27.08.2015 07:29, Matt Rae wrote: Hi All, when using 'juju bootstrap --constraints' the constraint is used for bootstrap, but the constraint is also set on the environment for future machines. Is it helpful to set the additional environment constraint? So far I've frequently seen the bootstrap constraint used to choose which node to bootstrap to, for example 'juju bootstrap --constraints tags=juju'. In this case, normally the constraint set on the environment needs to be cleared after bootstrap to deploy to machines not tagged 'juju'. With bootstrap --constraints at least we can clear the constraint after bootstrap completes, but with quickstart --constraints, there doesn't appear to be way to clear the constraint before juju gui starts deploying the bundle using the environment constraint which I don't want to use for additional machines. So it appears to break the use case of using --constraints to bootstrap to a particular machine. Matt Hi Matt, When you're saying you're unable to clear the constraints set at bootstrap from the environment, do you mean tags specifically, or other constraints as well? If the former, but not the latter, read on. I've recently discovered there's *no* way to unset a bootstrap (or environment) constraint value of type list (e.g. tags=aa,bb,^cc,dd, mostly undocumented networks=... and since a few days - spaces=... with the same format). This issue appears to have been lurking for a long time - just try this: $ juju environment set-constraints tags=foo,^bar $ juju environment get-constraints tags=foo,^bar $ juju environment set-constraints tags= # expected: set to empty $ juju environment get-constraints tags=foo,^bar So, I fixed this on master a few days ago, and in 1.25 it *will* be possible to unset list-style constraints (note that, as before, you can still set them to different non-empty value). If your issue is like described above, you might want to give 1.25-alpha1 a try. Cheers, - -- Dimiter Naydenov dimiter.nayde...@canonical.com Juju Core Sapphire team http://juju.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJV3qx5AAoJENzxV2TbLzHwTlMIAJMdw42RU3BY8kvb1Yk4G+6h gGn0XEDPyJHmzgB/QLBjcrjW4FBXFGmJuN/vmbO/0uW6niZINBkHwTDT2m82aNan uOIBjaMQxM6GQiLcYXqWroWb1V2dKxgfMx9e+5F5ggmmy6fCtcSrGR4TzAfC62VL +GXwvv1sLCLudyjBFhAycu6JMLcONrmw9ZWdN0ZAuPwMYGPWqqY/E3WM4Z7FTWv1 r9Igt14ogoYwG4kzx2K3xzbLkZP4gfr7pJDGSSjaDUh12Y7jXMYklqLKPFrojcEU NPU+vLun0jPKVZOwC5QNYDBqFP+eppOdqNPeT+HKjkfgv5RP6C3sK7FXt14HmQI= =7Hyn -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Fwd: How to do network segregation with Juju deployment ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, We're in currently developing more comprehensive networking features in Juju, so soon you'll be able to configure this with Juju the way you like it. In the meantime, please ignore the --networks argument - it was implemented partially as a proof of concept and never officially supported or documented (it's only supported on MAAS and only for nodes, not LXC containers or KVM instances). If you want to get a node from MAAS on given networks, I'd suggest to add tags on the nodes (e.g. tag net_public, net_internal) and then use --constraints instead: $ juju deploy keystone --constraints tags=net_internal,^net_public Multiple tags can be specified in a comma-delimited list. If you prefix a tag with ^ it means not this tag (i.e. exclude nodes matching that tag before deciding which node to provision). I hope this helps, and stay tuned for the upcoming networking features in Juju! Cheers, Dimiter Naydenov On 7.08.2015 18:16, 曾建銘 wrote: Hi all, I want to deploy OpenStack by Juju with network segregation. I got 3 different subnets in my environment, and follow bellow steps to config: 1. Set interfaces information in MAAS clusters tab. 2. Set networks information in MAAS networks tab. 3. Edit the network detail and set connected interface cards. I got two screen shots to display my current settings. Then, I used below commands try to deploy keystone service in LXC with multiple networks: $ juju bootstrap $ juju deploy keystone --networks=net_public,net_admin,net_internal --config=config.yaml --to lxc:0 But it stuck for a long time with allocating status, so I checked the juju debug logs, then I found logs as below: ERROR juju.provisioner provisioner_task.go:630 cannot start instance for machine 0/lxc/1: starting lxc containers with networks is not supported yet Is there anything I missed? Why juju told me networks is not supported yet? I have stuck with this problem for several days. If anyone have one minute to give me some hints, I will be very appreciate. Best Regards, Leon - -- Dimiter Naydenov dimiter.nayde...@canonical.com Juju Core Sapphire team http://juju.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJVxNROAAoJENzxV2TbLzHw+qIIAJqX9LGyhzLT9geKxSJQaEcW oqtf5WGcgDECf5K/lFgqRtoQRm8m/BYvZx+kw2u4bzwlCtdf7XplO3Di53DDVMib sc/ox2S+zhqwMXav3CrCy0P66uVNh9zCgjeo+Wbs3V5KCCLf/FHNUfLdi3XCpF4x ZDyWVuBtICO0j/3OPglwE4iBSy0jUE7ZYaB0O2i4LgL6ednLgB4DOLmehjC6B2IO AUX7GPHdYCodsc92mySfjMasGTi7gomPGSggOhy/iF7GO3Anx12aCSIdZuVGXpNx Woltz3Id6TR8ZVnbdPQD4YpFF+l2iLw/YKTO6it1+izRBnEpksxJvThjoo05//o= =ifY7 -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: ppc64le timeouts cursing things
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17.07.2015 12:07, James Tunnicliffe wrote: /me opens can of worms Thanks for starting the discussion :) Having spent perhaps too long trying to parallelise the running of the unit test suite over multiple machines using various bat guano crazy ideas, I know too much about this but haven't got an easy fix. I do know the right fix is to re-write the very long tests that we have. If you want to find long running tests, go test -v ./... -check.v is the command to run at top level. You will get a lot of output, but it isn't difficult to find tests that take longer than 10 seconds with grep and I am sure I could dig the script out that I wrote that examines the output and tells you all tests over a certain runtime. When you run go test ./... at the top of juju/juju it runs suites in parallel. If you have multiple long tests in a suite then it has a significant impact on the total runtime. We have no way with the current tools to exclude single tests without modifying the tests themselves; How about GOMAXPROCS=1 go test ./... ? Won't that force the runtime to run all suites sequentially? if we did we could run all the tests that take less than a few seconds by maintaining a list of long tests, and run those long tests as a separate, parallel task. The real fix is to put some effort into making the long running tests more unit test and less full stack test. 30+ seconds is not what we want. The least worst idea I have is making a sub-suite for tests that take 10 seconds, one test per suite, so the standard tools will run them in parallel with everything else. Providing you have many CPUs there is a reasonable chance this will help. It is not remotely nice though. Using go tool pprof can also help figuring out why certain tests take a long time and/or memory. I'm planning to experiment with it and come up with some feedback. 0 ✓ dooferlad@homework2 ~/dev/go/src/github.com/juju/juju/worker/uniter $ go test -check.v Shorter tests deleted from this list. The longest are: PASS: uniter_test.go:1508: UniterSuite.TestActionEvents 39.711s PASS: uniter_test.go:1114: UniterSuite.TestUniterRelations 16.276s PASS: uniter_test.go:970: UniterSuite.TestUniterUpgradeGitConflicts 11.354s These are a worth a look: PASS: uniter_test.go:2053: UniterSuite.TestLeadership 5.146s PASS: util_unix_test.go:103: UniterSuite.TestRunCommand 6.946s PASS: uniter_test.go:2104: UniterSuite.TestStorage 4.593s PASS: uniter_test.go:1367: UniterSuite.TestUniterCollectMetrics 4.102s PASS: uniter_test.go:774: UniterSuite.TestUniterDeployerConversion 6.904s PASS: uniter_test.go:427: UniterSuite.TestUniterDyingReaction 5.772s PASS: uniter_test.go:393: UniterSuite.TestUniterHookSynchronisation 4.546s PASS: uniter_test.go:1274: UniterSuite.TestUniterRelationErrors 4.536s PASS: uniter_test.go:476: UniterSuite.TestUniterSteadyStateUpgrade 6.405s PASS: uniter_test.go:895: UniterSuite.TestUniterUpgradeConflicts 6.430s ok github.com/juju/juju/worker/uniter 175.014s James On 17 July 2015 at 04:59, Tim Penhey tim.pen...@canonical.com wrote: Hi Curtis, I have been looking at some of the recent cursings from ppc64le, and the last two included timeouts for the worker/uniter tests. On my machine, amd64, i7, 16 gig ram, I get the following: $ time go test 2015-07-17 03:53:03 WARNING juju.worker.uniter upgrade123.go:26 no uniter state file found for unit unit-mysql-0, skipping uniter upgrade step OK: 51 passed PASS ok github.com/juju/juju/worker/uniter 433.256s real7m24.270s user3m18.647s sys 1m2.472s Now lets ignore the the logging output that someone should fix, we can see how long it takes here. Given that gccgo on power is slower, we are going to do two things: 1) increase the timeouts for the uniter 2) change the uniter tests WRT to point 2, most of the uniter tests are actually fully functional end to end tests, and should not be run every time we land code. They should be moved into the featuretest package. Thanks, Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev - -- Dimiter Naydenov dimiter.nayde...@canonical.com Juju Core Sapphire team http://juju.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJVqPAiAAoJENzxV2TbLzHwIHYIAKLXI2F4V/Jp+3rFLqbOCrgx QHTnnnARC7yDE5nbz0nFC/Z6JdEIsG+Xc+JzsaYh+cpZiRTmRvwztSlOyFBq649a fpCyUttY7CvPGxf+ul58dkFD2JL7Pv/ZNOAR4vGS6X2IR5y/UohtJVntkh3i68xQ +zRNlhmrGs2pxYVTHMPjfO+X83Cv/UNHq/j7upk1jRKXrm4AjjqGS+vQkIvTUJDF Y2T8efxFXHnMP5u3qI6yyoE1C8/wjh2AHkNNcVPoAy8ClRVjowOo0UpSH8XV2k89 PRtA35ON7Xrgrv45SOehuDo7PyeZacop7wp2d+tNKLLV4xi75aKkt7EQUcfmNOk= =I+Ar -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Specify Amazon VPC/Subnet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mark, I'm not sure you've got my earlier reply to your question, please have a look at bug https://bugs.launchpad.net/juju-core/+bug/1321442 which I've started working on. My proposal is to allow specifying a vpc-id config setting - if set, it will be used if possible instead of the default VPC. Cheers, Dimiter On 14.07.2015 23:22, Mark Hannessen wrote: Anyone any idea if deploying inside an existing EC2 VPC/Subnet is possible? I found someone who proposed a patch for this a long time ago but haven't been able to find anything like this for a more recent version. https://bugs.launchpad.net/juju/+bug/1073133 Met vriendelijke groet, Mark Hannessen Senior System Administrator / Architect Tel: +31 50 5775822-9702 Mob: 06 414 10 181 E-mail: m.hannes...@youwe.nl - Oorspronkelijk bericht - Van: Mark Hannessen m.hannes...@youwe.nl Aan: juju juju@lists.ubuntu.com Verzonden: Maandag 13 juli 2015 10:21:03 Onderwerp: Specify Amazon VPC/Subnet Hi, For one of our customers we seek to deploy a juju setup inside of a Amazon VPC. I have already configured the VPC with an internal gateway and am able to boot machines inside of it as expected. Internet connectivity works as expected. Unfortunately juju bootstrap does not seem to deploy the bootstrap node inside the VPC by default. juju bootstrap --constraints cpu-cores=1 --upload-series trusty --upload-tools --to zone=eu-west-1a I suspect i need a parameter to specify the subnet of the VPC (subnet-06932f5f) but i couldn't find it on https://jujucharms.com/docs/devel/config-general You can see my current configuration below. default: amazon environments: amazon: type: ec2 region: eu-west-1 access-key: removed secret-key: removed image-stream: released default-series: trusty Anyone any idea as to how to make this work? Kind Regards, Mark - -- Dimiter Naydenov dimiter.nayde...@canonical.com Juju Core Sapphire team http://juju.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJVphXvAAoJENzxV2TbLzHwDSwH/1+4LVPvMYAJ0CHbvE7evJT7 7k55TxWwL9rLTnxPhHYl41wJQeM3K361Bycw+5ADxq/Og+gOANrNys/a7TNj4jcO apn5GUMV7Ss74y8kT/y70wiTCDte71CFVxsTcxdf9XP+8FwjVhuAfXcq+SBBWf6e IGQNyqPaGipt8EnVe/7WOmWRdqDEcj4YHYFKiG4UFBoJu45gj1QCXcWOgqzGVe85 9fZ83xuSGlk2I3RF5hug5M0cxmQdvc10Oh0PpM3yt1Kagf4wk1ww1HfC45qod+Ra 61RlVDaIzdLDBOfmRmlX41Tr933AxvotCJRcKbMq0U0KTKcYMSFCkOlCN7M73BE= =Sm2G -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Container Networking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Chuck, In 1.23.3 we landed an experimental addressable containers under a feature flag (address-allocation). It however still needs a MAAS that's able to give addresses over its API (maas profile ipaddresses reserve). It's not tested whether it will work if MAAS is not managing DHCP/DNS for its own nodes. I've added a comment on the bug to ask for more info from James. Cheers, Dimiter On 18.06.2015 23:22, Charles Butler wrote: Greetings, If you missed today's Juju Office Hours - James showed up and asked a great question with regard to LXC container networking on hosts. For clarity he is not working on the local provider, he's using juju deploy --to lxc:# on bare metal machines provisioned by MAAS. A bug filed for the issue can be found here: https://bugs.launchpad.net/juju-core/+bug/1466629 The MAAS region server (unmanaged) in his setup however, does not manage the network of the machines. This particular network had an existing DNS, and DHCP services - so it was not conclusive to let MAAS control the networking with its own services. As I understand it in the 1.23.x series of Juju, MAAS and AWS have landed support for full networking, including cross host networking of containers. This is not conclusive with what James has seen, can someone from the team working on this take a look into this, and give a brief status update as to where we are currently with supporting full container addressability as well as any fix, or work around? Also I'd like to take this time to ask, if you're using juju and containers in production, what good things, bad things have you ecountered? Thanks, and all the best Charles Butler charles.but...@canonical.com mailto:charles.but...@canonical.com - Juju Charmer Come see the future of datacenter orchestration: http://jujucharms.com - -- Dimiter Naydenov dimiter.nayde...@canonical.com Juju Core Sapphire team http://juju.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJViDJNAAoJENzxV2TbLzHwLVEH/Rdn21XZ4mWj0pshJBC/SayK abhLY524iwmt1G/K8zF8PEicYCLR2edOSJ0ee8gmUH3rOC6Cz8ufsAi0y3wevl+j yo17dvGeDb63MtN1AJnZ+ApRaranXE6A2Rqg4sHeOlVSN3X1epVMLeJuQdOQ+25I KFDGMBfaJcUoOO8Qh9apHN3s94hb/7AQSJswHYPIgE6Nh4UMraJyjzbJTt3IfbSm Rz35fsrLwFDjEUbiLKMRji+nb1WnV4UnN8tIKoGX0hslYdB9LXkY7MQo+uzikCY2 G6KVjn8qqvB5cvzYmXVxnJmPYFA3iL5sFdMqSbUVBcywmD3F8yqKHtKlVThfTNc= =aNbz -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Upcoming change in 1.24: tags in EC2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22.05.2015 11:07, Andrew Wilkins wrote: On Fri, May 22, 2015 at 3:47 PM, Dimiter Naydenov dimiter.nayde...@canonical.com mailto:dimiter.nayde...@canonical.com wrote: On 22.05.2015 08 tel:22.05.2015%2008:26, Andrew Wilkins wrote: Hi all, Just a small announcement, in case anyone cares. In the EC2 provider, from 1.24, we will start tagging instances and volumes with their Juju-internal names and the Juju environment UUID. Instances, for example, will have a name of machine-0, machine-1, etc., corresponding to the ID in juju status. There is not currently an upgrade step to tag existing resources, so only newly created resources will be tagged. The environment UUID can be used to identify all instances and volumes that are part of an environment. This could be used to for billing purposes; to charge the infrastructure costs for a Juju environment to a particular user/organisation. We will be looking at doing the same for OpenStack for 1.24 also. Cheers, Andrew I assume we won't tag instances with a Name tag if there already is one, right? Otherwise it's a bad UX. Not sure I follow. We're creating the instances; they have not had names up until now (in EC2). When we get to adding these tags to existing instances, I agree that we should not replace the existing name if it has one. Yes, of course - if we're creating them, that's fine. Sorry, I was thinking of tagging existing entities (e.g. Subnets as belonging to a space, without creating them). For OpenStack, we should use instance names the same way (and only if the name is not already set), as tags not supported widely yet. On OpenStack we will continue to set names as we did before. There we will just set additional metadata for the environment UUID. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com mailto:Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev - -- Dimiter Naydenov dimiter.nayde...@canonical.com Juju Core Sapphire team http://juju.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJVXuSBAAoJENzxV2TbLzHw4t8H/1+UZEHeY0BnvxPgZjxgc+g+ aKQSO86BvB1CQ8RDS9NYYp3Tj1Viy9R3nEEsRQCBEH7m7n9Hicem+1bJKmqm8PRI WSx4hw8C5vD6r1GDgnbTMyxu7YehZPa1I73olZg2csPCjG6bATGJaZnsXKjsyDp6 ZmHyX/On9zf4h6+u2EFX4zYtI3X9eLyHWiGKEukuh89IpsntmkMrKWcKO7xId2g5 YWMl5ZmyXtBNnNeid+4wc5ktsZg3QkG+GL6ID2qehAo2QLlWEDtOLw4oPq8ZxkQ8 FUekTVxzdYAA2c8Tx5s+8F2DF68oxsQwR+SKLVZAzqrujSEed95LLeJLhmN8OzQ= =nSUd -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: 1.23-beta1 needs features for release notes.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Curtis, I've added a couple of sections on container addressability and improved proxy support. Frank, please find some time to summarize the Actions feature for the release notes as well. Thanks, Dimiter On 13.03.2015 23:40, Curtis Hovey-Canonical wrote: Our release notes document is looking sparse. Thank you Anastasia for keeping me posted. https://docs.google.com/a/canonical.com/document/d/1V6AU2mEbTOXQygsn-9eZg-DHjxcVpMylyq017KS78mU/edit I was expecting these topics: juju charms list MESS (Shared State Server ??) GCE Provider Systemd Support Leader Elections Actions Container Addressability on AWS and MAAS Charm Annotations HA Improvements - HA using Containers You don't need to provide a final draft of the new features and notable changes. Just get a draft into this document so that we can collectively bring this document to a final state - -- Dimiter Naydenov dimiter.nayde...@canonical.com Juju Core Sapphire team http://juju.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVBDyKAAoJENzxV2TbLzHwie8H+wZP89uOvhE1hDjLwEqHRflt LSdAcsbaeeFEP3bp9RnZGrPeSsGCge7u7ht9+z4XWWaAhTPAn4q3vWISYLwLtyag lWH25yWOL8avRmMpWTGF/dw913xzL4sA4ju6y+BNPTzK3LBT7RkvV1WLkz0XUZLY MliKIdjptLmSHKmSS0oyyeoRi96BVemQOc9ykxv3K8Ztt8vkS6zaS+GOiyn78AzS 04L/9wmpgSp8IdIssmuIO2Md5FWI31qhm0CTryO2wyt3IClxteMe46D/8Y78fQ1B Day6lOrPZeWEo81woufwxN8rftnCsrCZeqbR+Pb8PgMDp1vd4e9huM96/19HG1A= =JJAG -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Merge gating for more juju subprojects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for doing this Martin! I can't wait to try it out next week :) Cheers, Dimiter On 14.03.2015 00:01, Martin Packman wrote: I've put up a gating job for goose on our jenkins slave for juju: http://juju-ci.vapour.ws/job/github-merge-goose/ It will likely need some more work, but I fake-landed Katherine's proposed branch and it passed. The switch over steps are disabling direct landing for most/all contributers and getting everyone using $$merge$$ as with juju. Many of the other juju subprojects are also suitable for sending through automated unit tests before landing, and I can easily make a whole bunch more jobs for whichever packages we want to gate landing on. There are a few caveats: * There isn't proper isolation with lxc yet, so test suites that do dodgy things are still an issue. * Most packages don't use dependencies.tsv so the deps are tied to the merge job currently. * Anything that needs a large external dependency like mongo isn't catered for at the moment. That said, if there are any packages you think we should *not* gate landings on their test suite passing yet, please say now. Thanks! Martin - -- Dimiter Naydenov dimiter.nayde...@canonical.com Juju Core Sapphire team http://juju.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVBDvUAAoJENzxV2TbLzHwSIAH/jmgSDXGPnW1xn+G3r0oox5h kKVdcJMDWWyA4HpSowPPPVD2gXM7XEGBb/9/kLfrcAx6g80XVE3S/O4R3wQ632ub 7K/hWdaH8On0mj/W931WGN4acAHqFUoyYBX2c/zyU07kdGTH3ztl37R3se6JO0rt ou1DlC0Sl1L5wTrN2j7f7Dmn7+SNHxn3YfZxHSaqY861sCuALBavQniLD3bFF2xe wwbit6RyimhEHPFqYrNF2+3oDQsMc+bCWULr7W4y14U8H6sA4fT9bRNnoVER74Vk OChNLJtcaShr51bAKRcUjz5pRe28u/TidHg/5+qqjburR5PrGOXvSysSVLdPg6g= =E1vJ -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: unit-get and ipv6 addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I've asked Jake to file a bug for this issue, as it will be easier to track it and collect all the information in one place. In the mean time I'll be analyzing the possible cause for this. Cheers, Dimiter On 4.03.2015 17:13, Jake Kugel wrote: Hi, we also got around it by disabling IPv6 on our hosts. I had tried sending additional logs Dimiter requested but the email was too large for mailing list server. For lack of better idea on how to deal with large attachments I had sent Dimiter logs directly (sorry Dimiter). Maybe pastebin next time? Thanks, Jake juju-boun...@lists.ubuntu.com wrote on 03/04/2015 04:03:09 AM: From: Thierry fa...@linux.vnet.ibm.com thie...@linux.vnet.ibm.com To: juju@lists.ubuntu.com Date: 03/04/2015 04:03 AM Subject: Re: unit-get and ipv6 addresses Sent by: juju-boun...@lists.ubuntu.com Hello, I got a similar issue and solved it by disabling IPv6 under main host so lxc containers could communicate through IPv4 and access to external world. I haven't yet understand the issue but it sounds like if the main host is IPv6 enabled, then system tries to communicat through IPv6 even though IPv4 addresses are the only one configured. If anyone get an idea let me know. If you think that needs a bug let Jake or me know (at least) as we get concerned with the issue Thanks Thierry On 03/02/2015 04:03 PM, Dimiter Naydenov wrote: Hi Jake, Thanks for the logs! However, I still can't find the reason this should be happening just from those logs. Can you also send us the unit logs from wordpress and mysql? A dump of ifconfig -a on each of the machines should also be useful. Regards, Dimiter On 28.02.2015 00:42, Jake Kugel wrote: Hi Dimiter, thanks, here are the files: Jake juju-boun...@lists.ubuntu.com wrote on 02/27/2015 02:58:01 PM: From: Dimiter Naydenov dimiter.nayde...@canonical.com To: juju@lists.ubuntu.com Date: 02/27/2015 02:58 PM Subject: Re: unit-get and ipv6 addresses Sent by: juju-boun...@lists.ubuntu.com Hi Jake, Can you provide some more information: - your environments.yaml file - machine-0.log, machine-1.log, and machine-2.log from /var/log/juju/ on each machine Before sending these, please make a quick check to remove any sensitive info from the files (e.g. access/secret keys, password, etc.) You can get the logs by using juju ssh 0 (or 1 and 2 for the other machines) to connect, run chown a+r /var/log/juju/machine*.log, then log back out and use juju scp 0:/var/log/juju/machine-0.log ~/ (again replace 0 with 1 or 2). Thanks! Dimiter On 27.02.2015 22:19, Jake Kugel wrote: Hi, I am using juju 1.21.1-trusty-i386 and deploying to a manual environment, and had a problem deploying wordpress following the getting started page here [1]. When I tried to view wordpress with a browser it gave me an Error establishing a database connection, and from a little bit of digging found that wordpress was configured with an ipv6 address for the mysql host. Switching this manually to the ipv4 address fixed the problem. Assuming for a minute that wordpress doesn't support ipv6, is there a way to avoid having it configured with an ipv6 address? I see that unit-get private-address is returning the ipv6 address for the mysql host, is that normal behavior? On the mysql host machine log, I see this: 2015-02-27 14:56:59 INFO juju.worker.machiner machiner.go:94 setting addresses for machine-2 to [local-machine:127.0.0.1 public:9.114.192.29 local-machine:::1 local-cloud:fd55:faaf:e1ab:38d:944a:7931:9b4c:c621 local-cloud:fd55:faaf:e1ab:38d:a8c0:f5da:7109:1e67 local-cloud:fd55:faaf:e1ab:38d:f816:3eff:fee2:f0fc] Thanks in advance for any advice, Jake Kugel [1] https://jujucharms.com/docs/getting-started -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/ listinfo/juju -- Thierry Fauck @ linux.vnet.ibm -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/ listinfo/juju - -- Dimiter Naydenov dimiter.nayde...@canonical.com Juju Core Sapphire team http://juju.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU9zVNAAoJENzxV2TbLzHwXRgH/1Xt/z3mTmWFQFYXDhjTTg3y 0eca32EeEOk9jDoJlB/aB4eMuEOQWq9kKlcElY/kPGS5DoQE9j9p4UXVHrPj33Gz uLJi1lWn5nZ7qCX+QwffYoo1rB7tgzL3WVS2/4xoIusC4g4KyjBdopupktfUdTED 2DpyuVTDDtpi7M0cniwcIBAKkJ1koraQnlRbhk4LAQdarwMRS4U/KPoA/+X3NP// MunxdRItB6kVz5fwUtcTV1QymIcE8H9ZXGS9kP/lM+PxbM6S2oxUl6WmAqWvxrln W6c7in0x9TIyk/dVmF4WqdtmAa984EI6jLclvQS84eTaPIy691OwFHQgeUbC9UE= =tNjn -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Trivial bugs hurting progress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4.03.2015 15:44, Martin Packman wrote: On 04/03/2015, Andrew Wilkins andrew.wilk...@canonical.com wrote: Hi all, Ian asked me to mail the list about a couple of bugs that managed to get past the bot; first so that we can all be mindful of these sorts of bugs, and second to highlight the fact that they could have been caught by the bot. The bugs were fixed in this branch: https://github.com/juju/juju/pull/1738 - random. iteration Map is This was being addressed as part of bug 1427149. https://bugs.launchpad.net/juju-core/+bug/1427149 http://reviews.vapour.ws/r/1048/ Your patch means that branch now needed updating. - invalid printf-style formatting will cause go vet to fail So, do we want to revisit making the bot fail on go vet errors? That's trivial flip. The bot is currently running (I think) Go 1.2. I'm running 1.4, Ian's running 1.3, and I'm sure Dave's running tip ;) Go 1.3+ made map iteration less deterministic, so these sorts of bugs are much more likely to occur after 1.2. It'd be good to either bump the compiler version to something more recent, unless we want to gate things on multiple compilers (maybe gc and gccgo, seeing as we currently use both). Curtis and I have talked about also doing a ppc64 test run as part of the gating job, that gets us the map ordering stuff as a newer go would, and other gccgo quirks covered as well. We don't want to bump the compiler version yet I think, as we want to be able to build with the trusty toolchain still, and not accidentally let in regressions by depending on newer gos. If it's about catching map ordering issues, let's use go 1.3+ as an extra step, rather than gccgo, which is buggy and slow and randomly segfaults. It's likely we'll slow down merge gating considerably. Just my 0.02c. Dimiter Martin - -- Dimiter Naydenov dimiter.nayde...@canonical.com Juju Core Sapphire team http://juju.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU9w5NAAoJENzxV2TbLzHw+lsH/jDFDXb+APntIyq1WUzIfRb2 cbg3vurBAqvIcT6qt6pMTW3uEf1Q9daksvqSRFhC8Nbz70bIeLJ3vLNHzn6gRy/d z9QiyJQIXQE8208bmQLYdOkbLZAfURzT8I6PTFzioI7HkL7qA3suWod1pnEwSvcQ L+bw3+H/gym9bUGqDG2zG1p6u+Z0JH4lxMBomcxsaU1WJyBFN0HVi0xinJN5IX7k YZoZokaD6C0pu30r756wMy1PigImm/+G/lxLqzlnpL32iZFZhQOnWPZMxMVOtfIM AGzSAJtdy149jcnfLHJqeb4yNugTKUxPrARrFVkBbYKau4I09eGOes7yKq7j8fA= =8QrH -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: unit-get and ipv6 addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jake, Can you provide some more information: - - your environments.yaml file - - machine-0.log, machine-1.log, and machine-2.log from /var/log/juju/ on each machine Before sending these, please make a quick check to remove any sensitive info from the files (e.g. access/secret keys, password, etc.) You can get the logs by using juju ssh 0 (or 1 and 2 for the other machines) to connect, run chown a+r /var/log/juju/machine*.log, then log back out and use juju scp 0:/var/log/juju/machine-0.log ~/ (again replace 0 with 1 or 2). Thanks! Dimiter On 27.02.2015 22:19, Jake Kugel wrote: Hi, I am using juju 1.21.1-trusty-i386 and deploying to a manual environment, and had a problem deploying wordpress following the getting started page here [1]. When I tried to view wordpress with a browser it gave me an Error establishing a database connection, and from a little bit of digging found that wordpress was configured with an ipv6 address for the mysql host. Switching this manually to the ipv4 address fixed the problem. Assuming for a minute that wordpress doesn't support ipv6, is there a way to avoid having it configured with an ipv6 address? I see that unit-get private-address is returning the ipv6 address for the mysql host, is that normal behavior? On the mysql host machine log, I see this: 2015-02-27 14:56:59 INFO juju.worker.machiner machiner.go:94 setting addresses for machine-2 to [local-machine:127.0.0.1 public:9.114.192.29 local-machine:::1 local-cloud:fd55:faaf:e1ab:38d:944a:7931:9b4c:c621 local-cloud:fd55:faaf:e1ab:38d:a8c0:f5da:7109:1e67 local-cloud:fd55:faaf:e1ab:38d:f816:3eff:fee2:f0fc] Thanks in advance for any advice, Jake Kugel [1] https://jujucharms.com/docs/getting-started - -- Dimiter Naydenov dimiter.nayde...@canonical.com Juju Core Sapphire team http://juju.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU8NpZAAoJENzxV2TbLzHw5NsH/1CB0KtyasUJaLaaDbumTGER qnaU6GJRvUtvFyt0RUorHdVVdnVrr120G/0Gf7gqmMdI37J5G6InBok2Zh1wl6We 2N6WH7uKDPSDINQJJqS2tXoSnp12924U4DCoC5ceRdkZuLhmHfMkWv3uj+nPOk9D YmwKEnKNRxiY4nCZwIDpO5wJUuy25dSQJH3OIBJZbu56VB18bQhDt8SVmk0ph/B+ guBkMq/i5+Fe+i9cRLk8Hq5HTOreYocOOwkFKmui5ZDmDSRvqtD3sg7DJvKrH5qx CmNkQJ8xzCY1SX+VzeXmxBXWEX+scdS5vLgKoJ3YcneYIQWFUag1bfmRA+qfcvA= =sId2 -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: A home for underappreciated errors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10.02.2015 11:57, roger peppe wrote: On 10 February 2015 at 08:55, Andrew Wilkins andrew.wilk...@canonical.com wrote: Hi all, Ian raised a good point in http://reviews.vapour.ws/r/885/ (caution advised, may cause eyebleed) about a change I made to errors: https://github.com/juju/errors/pull/17 The NotAssigned error, which previously was only raised by state.Unit.AssignedMachineId, is now also raised by state.Volume.StorageInstance. I removed the error from the state package so we didn't have apiserver/common poking its head in there, and moved it over to the juju/errors package. The issue Ian raised is that juju/errors should contain relatively generic error types, and we should keep domain-specific things elsewhere. Examples are NotAssigned, and NotProvisioned. We're thinking of moving these domain-specific error types into a new package, juju/juju/errors. What do you think about this? NotAssigned is more generic than NotProvisioned IMO, so if I were to decide which one to move to juju/errors, I'd move the former, not the latter. I agree with Ian here. Personally, I think that specific error types/values work well when defined in or close to the module that returns them, which is aligned to my general feeling that the set of possible returned errors is part of the contract of the method it was returned from. For example, the mgo package returns mgo.ErrNotFound when an item isn't found, and that's fine - we translate from that error to a more local not-found error when necessary. For errors that pass over an API, they can be considered a part of the API and defined along with the other API types. So, rather than a single package for juju-related errors, I would suggest that domain-specific errors are defined in packages close to the domain in question rather than in a single package used by everything. To my mind this is a more modular and scalable approach. +1 I like the idea of having state/errors for sharable-but-domain-specific errors (or network/errors, storage/errors, etc.) and leave generic errors useful it a lot more cases in juju/errors. It's also the standard Go idiom. cheers, rog. - -- Dimiter Naydenov dimiter.nayde...@canonical.com Juju Core Sapphire team http://juju.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU2d83AAoJENzxV2TbLzHwd20H/i22GBC5dADZnLFAfNhE+X0y E7tZc+UkrsKGUmcAHm1k5tEuv3r9Vk6vLxtEcRVXcWvXqoCCW72Cpsw7lLiAkKoH dYPwyBTVorp/N+Z1hxMN+P3LhctRlGNlz1IR9BLJ+3fM/Dlfp+YfVJ93BfqrcC7f uaUJY0iSdOHuedfs29CtTtamSDNb1s3l8uCo5X0Ihh2zc1SMOHPVFxrdWnLTERpN Vw8C6gv47GETUekTzwoviioiQrDxKijMqjkGB9khrKiXdlSLz0rQV2W+874ztPgo pkcdlSzLCJ89r7WB79kajGYWGrlXD1n6NsTSgywIW+M8teIprHjR/exWDxtyPKs= =dbEQ -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Reports artifact links added
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Awesome job, the new links look great and are very useful! Thank you Martin! :) On 9.02.2015 20:25, Martin Packman wrote: I have deployed code on juju-reports that directly links all build artifacts from the test detail page. For instance see one of the recent runs: http://reports.vapour.ws/releases/2312 In the Last build column darker shading indicates you can hover the cell to reveal more links, which can include: * Previous builds and their logs - a number of jobs may be run multiple times in order to get a pass, the earlier failures are now easy to access. * Juju logs from failed tests such as the machine and unit logs. * The binaries used in the tests for all platforms, in the build-* jobs. The direct link to the jenkins job pages is also back, note these will expire unlike the artifact links, so may lead nowhere for historic runs. I plan to make the gziped logs directly openable in the browser and tweak the css display a little more. I'm like to hear any more suggestions or feedback on what would be useful to see here. +1 I'd really appreciate this! Martin Cheers, - -- Dimiter Naydenov dimiter.nayde...@canonical.com Juju Core Sapphire team http://juju.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU2RR2AAoJENzxV2TbLzHwVAsH/jUGz2y0LRNIyh3Yxx0I7+ZY J8V+2R2qXSlhAGni8b+I5CM71h7a1jG5lKaOM03HKEZ1Z5/cLyjqLEnFpY9pYXCD 2EJ36enJAn4F59gRlGo52pSdztys7749ucX7rRlRipIG8GolmsrCPTqvLQVuh9+c jONqa+HJGlTkb8CJKurLqo5Dy55ukqG0+3DxMj+jRKPjkOQiUTOcXDFr0dOaDEyf y0aCfb0U4DkAsywk4Dy2kPGJO5ULFWb95SrBaXHwVQj2omXWXaNpM/WExj6XeRKG p0l3ACahY0K8v5VSIXpRC1OviRbB8Wxgo5UDxTZgDykiscUHcExzEJeP3/0P4cc= =b6XY -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: NETWORKER ALERT: network worker causing problems in 1.21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Tim, I'm sorry the networker is causing trouble for you guys. It was causing issues for us in MaaS and EC2 as well, there were several fixes to reduce the networker's impact and in fact it is now totally disabled on trunk. It will stay that way until we have time to fix it properly. However, the networker even in 1.21 is only causing issues when modifying /etc/network/interfaces inappropriately it *does not* decide what addresses a machine should use or modifies them in any way. That's done by the machiner. The networker just discovers the NICs on the machine and watches in-state NIC documents for changes. We can backport the fix that totally disables the networker to 1.22 and 1.21 as well, which will require a point release for 1.21. How does that sound? Cheers, Dimiter On 4.02.2015 22:17, Tim Penhey wrote: Hi folks, There is something I'd like you to talk about while you are together in Cape Town. The new networker worker was added in 1.21, and is causing many problems in the wild. The lxcbr0 IP address is erroneously being chosen as the best address for a machine. The worker enumerates all the NICs and gets the addresses. We need to work out how to avoid selecting internal only addresses, like 'lxcbr0' and 'virbr0' default addresses. There are likely to be issues with other things like additional other bridges or VLAN sub-interfaces. I'd like you folk who understand networking more to work out some heuristics that will at least get us unblocked. Cheers, Tim - -- Dimiter Naydenov dimiter.nayde...@canonical.com Juju Core Sapphire team http://juju.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU0yIvAAoJENzxV2TbLzHwnf8IAJlwovY09VnuxE/v1/+4J79M i78R3/q3GajfZtxFndWxNhWGWEHFOnH1EJO6mxCYlzq0wXGEhJ3b17HJLmBO+5Jo T2IVFSoO7rElg8GESIgGALz5HPmy36KuB6hzRpSOwZQn4OdnUlHvyxty9gmUopp4 2qof8JVLGs9E++pgHMl8YqFc1+us0kXII1LvaRhulTo5lp+95xrC4t0febNKRyEV q0+5PC64m44AYrO6lbOw3J2u6591mV1KsllLm5D4/SPZ4IqORRG7YQQYmbDVIijs uMb7+mf6URmETIaGkXe4KDXNzoUjnH1DRGCapUry/5+kZBeyHB09dt2HZVaPwdA= =Rdvh -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: About bootstrap server , size and dedicate or share it for applications or not
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 1.- I have been able to use a 613MB RAM server for a development environment, but a 1GB RAM server is recommended. You should also ensure the machine has enough disk space for the MongoDB database, which IIRC by default is configured to pre-allocate 48MB (for 32-bit architectures), 183MB (for 64-bit OS X), or 512MB (for Windows) as minimum oplog size, and up to 1GB (on Linux) as maximum oplog size. Additionally, if you store a lot of cached images (for LXC containers) or other binaries (juju tarballs, fat charms, etc.) the MongoDB database will grow. 2.- Yes, it is allowed but not recommended. You can deploy additional server to that machine specifying --to 0 when deploying. However, this is not recommended because the service will eat up RAM. Another option is to deploy services isolated in LXC containers, with - --to lxc:# where # is a juju machine ID (0 for the bootstrap node). 3.- You can, but only if you are using the local provider. If you are going to use a cloud environment, then the bootstrap node needs to be in that same environment. Alternatively, you could bootstrap a manual environment on the Ubuntu desktop machine, but then you'll have to add manually each additional machine to the environment, with add-machine ssh:user@hostname|IP address - e.g. $ juju add-machine myuser@192.168.1.123 - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUt9rSAAoJENzxV2TbLzHw5sMH/RPUJolTvImGI8zoY4Aleugq ESBMh4B6S3befBdo920Hw9k0QAxLdyAJiPRccmRYiecd5/djv14LlpUGRyxuxhoM GsVFgVAR/cFBsjAjxPX1EMKK5jvm0jSAp+zJbaWoJt9toolZ10Mi0sNx7wEvPy7M dkJI0jD2J2U16ch7R3YVngXBckQEGafxLo3aJHOGYZT2ENfs4yjo+fIHxh2xZJ/h uWlRKEb3vd23HPYLP43EFvZELCujg3uFyxCch0HVw/XFMc2G4DdZN4bANZhcnHud fsdsldnpHaf2O1UkYnzfJudFwML6BHVQxVmJQUPdyxTyRC0rdFMve5rJWOKfCsc= =k40X -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Question regarding --upload-tools and implications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 4) IIRC we use the version of the juju client when we upload, not the version of the jujud binary. Eg if you happen to have a 1.22 jujud on your system but you use a 1.23-beta2 client we'll upload it but call it 1.23.0.1-beta2. From there upgrades etc will be very confused. I suspect this is true. A development client can make surprising decisions when upgrading a stable environment. It is true because --upload-tools forces the built tarball to *lie* about its actual version. So even though you might actually have 1.20.x binaries inside the tarball (e.g. left in your $PATH from before) --upload-tool prepares, it will *appear* as they are x.y.z.1, where x.y.z is your juju client's version (or when you have the source - - the value of Current in version/version.go). Beware. - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUt9dVAAoJENzxV2TbLzHwjNUIAJQXyDeQCywDp4vCKLquTSLF ZAY/Z6GJ/yF0ptYyiECVPuBjnzIQXMKxXfPYAQmFBTyWeb+mOljnGS8oGr3Nem7N lIGuPHGUU0VNJLVRau+JjxTp89BEUR5eNKtQnmzPlU2ZyceSx5DuPnQ4H/uvmJsj Xrb/KzVpwNn5K4hlw+d0ZPzZOA0hCKUXJYK04gUT6+rnYiQP2Ek8ywxrbGs6sQ9J LznQ1ZxwlIcgF2Y0e6WycomiR52lOBL/LK8/IL4OHCXlIYai34LTLUDU2uH8CRF0 v6zYxyPuvsKZ/pLxPtTxxYs8HB7nOHZawQ7pI+qO94KS7fDi+O0ntFR66n8k4YY= =h2in -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
goamz status / going forward
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, FYI, I had a chat with Gustavo yesterday about goamz - workflow on github, reviews, maintenance, collaboration with the community, merging existing forks, etc. Here's a summary of the most important points and decisions: 0. The v2-dev branch will land tomorrow or on Monday at the latest, so both networking and storage work can be unblocked. 1. Most of the existing goamz contributors (rogpeppe, mgz, katco, wallyworld, axw) asked if they are willing to give a hand with reviews / maintenance initially. We aim to attract and involve more external users and community members which know EC2/AWS and care enough about goamz to become maintainers. 2. I'm preparing a CONTRIBUTING.md file with guidelines, and there will also be an AUTHORS.md listing all contributors. External contributors will need to sign the Canonical CLA. 3. Ensure all of the code is LGPLv3 licensed and make copyright headers consistent (Gustavo suggested removing his name from Written by ..). 4. Bug tracking will happen on Github only - existing relevant bugs from LP will be migrated as GH issues and the wiki page / docs updated to reflect this. 5. We'll use semantic versioning for branches (v1, v2, etc.) and releases (tags like v2.1.0) and following Go and gopkg.in guidelines to decide when to bump the version. 6. In general the workflow for contributing will be the same as juju-core (one +1 and no -1 from an official maintainer to merge), but reviews will happen on Github's Pull Requests, not reviewboard. 7. When integrating code from other forks, we need to ensure (as reviewers/maintainers) that what goes in is reasonable, consistent with the rest of the code, has tests and proper comments/docs. The suggestion to fast-forward the integration by pulling in code in exp/ or contrib/ initially (with the intent to clean it up / polish it later and promote it to a production-grade package) is not going to work and should be avoided (as for example the exiting exp/ package - it never got any serious attention or maintenance). - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUrtbLAAoJENzxV2TbLzHwUJgH/0MSzjf0siNc1G/w8z+HKRVp O5YujoXW9qGg7CmkZjlrdOFOh8WBnHXJ+AT0UjG2KifiM5i4ikcGtH+1QISOBWZ7 R2sxSxZZxYZz8lCAUI3lU98cuJcVZILs6pIgvJgDQbTKe4jnZUNt+bKonA3kPMtu IocX/bmmhJOtIeAm21yrmv5F3/Gk96fL0FpMwDOQdp0b/0Z4809cIlbmUWw4isNz DJVGXtE50hesOdyzqeCI2nSr+4CuhbQzXIur6qJtVLcGpK9c3HMtSPWev6K7TzZO l9kRkojEZEWWAAagtr4wPVqa1V19m3DXsIQBB274VXIo2OLE3YTXP53QgtgZg5A= =UXKM -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: GCE provider, successful bootstrap and deploy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8.01.2015 00:17, Wayne Witzel wrote: Eric Snow and myself have recently been working on the GCE provider. As of today, we have officially bootstrapped and deployed and setup a Wordpress instance and related MySQL instance. We are still manually working around some issues with GCE images and cloud-init. The issue is fixed and merged, we are just waiting for that to be SRU'd in to trusty and utopic. We are now working on getting better test coverage in place and addressing remaining TODOs that we left as we were writing code. Our branch is at: https://github.com/wwitzel3/juju/tree/ww3-gce -- Wayne Witzel III wayne.wit...@canonical.com mailto:wayne.wit...@canonical.com Awesome news! Great job guys! /me now has a reason to get a GCE account :) - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUrjTyAAoJENzxV2TbLzHwZhIH/jL6/k6QHIhnJ6Vo2tDysSks 7lXDZq09I+5gwJXyrUjxZ4usU3sVD2qlk1nYea27kYDgojJaNbL2BTL5F11v+gzJ zMBjVFSTX0/u0Yp9zryUL+LI6sEdOTWSQsCVS6JHZpNMfDRaNF9pcoRN6JagGF2q xZbmDXOOPrXNXdeabc92xGUIY5ybDQoIaIdC5KBhSss/2Rx1JNv2bAAHPlUbc1rG 50K5zlG27l0SN9HpSm0//bT4WwNTGNuccwb1Sqc40bNMc3OIb7uoO6Q2142IHpGg qhOpRT283JA4pWwW8aSiuT9+2sEcijafZjESw9rQCMW3X6PKBRCXs86Oy4AT3p0= =2rj/ -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: separating out golang juju client from
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think having a separate juju/api repo containing the api client as a reusable library will definitely improve collaboration/integration with external projects. It will require some refactoring to make it easier to reuse, but that's also a good thing. We should split the agent api and client api so the latter can move in a separate repo, but leave the former in juju-core. The apiserver should remain in juju/juju as it's closely tied with the state package and it does not make sense to have it separately (as long as state is also in juju-core). However, this should not be done at the expense of more complicated workflow: juju/api should be treated the same way as juju/juju - CI gated merges, bot running integration / upgrade tests, RB integration. Happy holidays ;) Dimiter On 19.12.2014 15:43, 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 - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUlC8pAAoJENzxV2TbLzHweucH/39/0D1WQt9pNT2yFrFb+Bt8 JNO0shKqC1Spyblqn7WKI32H7unWVcI4qF2PMYdm3wYA84Xx+ySbislIRv5fJbPo 9ex90IfKJxeEvE6Oq8guavQz6FR7Ks9BzZDnuQUt+gVeZP2QyPwu3v4963ZGIch2 vVOPwR+B9hr+eah00o8HSX2qx7ycdAxuB+yEL0Yg5gBpEcHSACcChBKiF/WAk4wc rhEAbHDH5DdjbBmE6pJtaGavd5bs/FEsh5OgdFh5YEOSth5B9aRg9DhyzbouYr8Y RhVu7LiewnQxpq0kyiAjl4Mjzk4m6pT7/uzzoUqPgX7Q0A6OS/bj9fXghDs7Gpo= =PWBM -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Automatic multi-environment collection handling
this is necessary. Please use these sparingly. *Performance* * * With the extra work being done to implement automatic multi-environment support, the performance impact was a concern. I have compared multiple runs of the state package unit tests, with and without these changes and the difference is lost in the noise. If you see any problems or have any questions, please let me know. - Menno - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUkwixAAoJENzxV2TbLzHwgCEIAMihgys62djSGdmaVYTgsYVM YoJ3SNXZlfn6X5hBz9RrYtfC0K3vkW1t8jJMQtaShwH9pakMmIeUQXBWTNIZUqmf WQyboYW65RtnjWfR/oSQKHXr02wz7Trxeh0oM9TqINPEnllq5jubHrYscmCkZfQj BmaAXTNozYm/KKDN6ros0AbCWZdd1nn/PvG38XbMtBw1N/wK0qAZV92nl8DW+o3j coaoQ9KdGdhAdnMcub4u6UVMUp4V/2IiiPE379ATn8Yo6qdysd5yEnqWad0ajPnV WFsfjqZrY1qc9IxqaFjfRhszkaQgM7392dEejW+TVU69qzvlrUZHIQLv9hl52Ss= =ugvU -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Automatic multi-environment collection handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thank you for the quick response! On 19.12.2014 06:43, Menno Smits wrote: Just following up. This was fixed earlier on today and the various CI upgrade jobs are now passing. I've marked the ticket as Fix Released so that this issue no longer blocks merges. On 19 December 2014 at 09:40, Menno Smits menno.sm...@canonical.com mailto:menno.sm...@canonical.com wrote: On 19 December 2014 at 06:02, Dimiter Naydenov dimiter.nayde...@canonical.com mailto:dimiter.nayde...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All this is great work! Thanks for the write-up as well. I think I discovered an issue with it - take a look at this bug http://pad.lv/1403738. It seems machine.SetAgentVersion() should be handled specially by the multi-env transaction runner, as only after calling it the upgrade actually starts and the steps to add env-uuids to state collections are executed. Sorry - I neglected to do a manual upgrade test before pushing this change. Ensuring that code that runs before database migrations have occurred still works as it should has been pain point for us while doing the multi-environment work. I will get this sorted. Thanks for saving me some time by doing the initial analysis. - Menno - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUk9YYAAoJENzxV2TbLzHwUjEIAIpketDU8EPg6V3fV9DD24w5 u4G2Il9k8dhfScBZLTVcP5neLPYwQsOh3DHea3CVxyQDZnbfDWqtVVjnffTo/o0C hvohN1CBXxyL/jlm1YcfTEAPb0GqUgjJJPMcJD/I7qWzdj4qpHR806RCcfQlPpj/ Rk2CCEYFbL3le2v0uIVEDSq4MbaWsTjX/JBNej9kqkNtmjo02YD4Vq/QQVbOLoYy d1x1VQ8mEjd8kl6Yjg6paxEiZejD0ikta+5MS3MNSYgQ4MMZIZ9IQUV9BwWCnCjV XcKVWaHK7twptNUigq+p6AGVnznmES1gXvjS708bSBv1drk3qGx45QC2owDEe6Q= =Vi/f -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Blocking and unblocking merges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18.12.2014 04:20, John George wrote: On Wed, Dec 17, 2014 at 4:26 PM, Menno Smits menno.sm...@canonical.com mailto:menno.sm...@canonical.com wrote: There seems to be some confusion as to how merges gets blocked and unblocked. Specifically: 1. How do merges get blocked? Juju-core bugs with the following criteria will block merges: a. status: 'Triaged', 'In Progress' or 'Fix Committed' b. importance: 'Critical' c. tags: 'regression' and 'ci' 2. Who/what decides to unblock merges? The Jenkins github-merge-juju job (http://juju-ci.vapour.ws:8080/job/github-merge-juju) is configured to call the check_blockers.py script, maintained by the Juju-QA team. check_blockers.py queries Launchpad for bugs with the above criteria. master example: https://api.launchpad.net/devel/juju-core?ws.op=searchTasksstatus%3Alist=Triagedstatus%3Alist=In+Progressstatus%3Alist=Fix+Committedimportance%3Alist=Criticaltags%3Alist=regressiontags%3Alist=citags_combinator=All 1.20 example: https://api.launchpad.net/devel/juju-core/1.20?ws.op=searchTasksstatus%3Alist=Triagedstatus%3Alist=In+Progressstatus%3Alist=Fix+Committedimportance%3Alist=Criticaltags%3Alist=regressiontags%3Alist=citags_combinator=All Most often the Juju QA team will open these bugs and set the tags, when a test failure demonstrates a regression. If the pull request body includes fixes-BUG NUMBER, where BUG NUMBER is in the blocking list, the merge will go through. 3. How do merges get unblocked? Merges are unblocked when no bugs are returned with the above criteria. The bugs should be updated only after the committed fix has successfully passed the CI tests which discovered the regression. This will most often mean setting the status to 'Fix Released' when the solution involves code changes or removing the regression and/or CI tag, if the issue is discovered to be a test or CI issue. 4, If the unblock process involves manual steps, whose responsibility is it to perform those steps? The person or team that marked the bug as a regression is responsible for updating the bug, once they are satisfied with the fix. Most often this will be the Juju-QA team but if others discover a regression they too should have the power to block merges. The problem often is nobody from QA is around to ask for help in certain times during the day. So there should be at least a person in each team knowing how (and having permissions as well, if needed) to re-run jobs that are stuck, mark the bug as Fix Released once the CI job passes after the fix lands. Another REALLY NEEDED feature is to re-queue PRs set for merging but bounced due to a CI block. This wastes days sometimes, or at the very least hours. Based on experience and observation, I think I know how at least some of this works but could we please have some authoritative answers? Thanks, Menno -- Juju-dev mailing list Juju-dev@lists.ubuntu.com mailto:Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUkkBzAAoJENzxV2TbLzHwflIH+wQM8s8oV2i7b1PzsDzh9Zyu DhfkyIhxFQxTJGsV8RamcTDkjWeDhRZKB49UPzMdqNJr0XG/KvVy1SyqICxJ5qoz uWnnrdumzUhF0k/hjsUEnOpNDBOnubUIoGHBVyyx6UEMRgW+G0pFTIhUQGqEPhhU 7YMqn/r3GpiSnkmnknB/U4yk9TEYViDBRuPzSmhJiSwBGqkpOW+ISkWstUgbqYO+ o9KzxREWcvEDQ0+v0RLpaF2HsUWwktn7HL2BuoemhU4hoS5/ohD0VR5AemXwUyky ISEiqu4atjPcCxJts5UpPhhznBSVHFlOm4ROkH1ku+x671WZEZZXoUt4CjWbxvo= =l5mJ -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Joyent networking issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.12.2014 21:18, Curtis Hovey-Canonical wrote: On Fri, Dec 12, 2014 at 2:17 PM, John Meinel j...@arbash-meinel.com wrote: Is that after Dimiter's patch to disable Networker on Joyent ? yes. Apparently disabling the networker was needed, but it's just part of what's messed. Menno had done some further analysis and it turns out joyent sometimes provisions machines with different local subnets (i.e. 10.x.y.z vs 10.t.u.v) probably in different AZs/regions(?) which makes those machine (e.g. on 10.x.y.z) unable to talk to the API server (on 10.t.u.v). It was suggested in some forums as Menno discovered, to add a static route 10.0.0.0 to the API server's local IP, which fixes the connectivity issues, but it's unknown what's the impact of that fix otherwise. - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUjUmaAAoJENzxV2TbLzHwZWIH/jWWSAe5U9SkOEbi+lgvV9WN lWcj7G+2q/TGo1Ec8e8DphzyaC5iJWNweQ8hd8lWfBWNmPWBgE5Ma8tnVg7P47DD Mr1DaILe40AJ/UOEcEsX2LJldGWATKElCCq+Beo4klB0f6cVSv/Wohx6xnssT8gN cFnfDekHcn/dtqF/dEV6icUEMiv3AK1YgyyedgRZ8zPSRakjkOaTVFlYg+gBJNMj 5cngFtISNCnVjZ7/1nU6Fxge83S3v0cMUoSt+rx9/jfIua/65AjisON4DpCc2h9r lafB7d7U/qLRJL1Jrm12j8Gd9JDfgq+i+oVVwth8MD9k3xOEW/u1uvDrdILliaA= =LHpR -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Goamz Migrated to GitHub!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, There was an ongoing discussion to migrate https://launchpad.net/goamz to GitHub. I'm happy to announce this has happened today - please find the new repository at: https://github.com/go-amz/amz Import paths have changed to use the http://gopkg.in/ format: Before it used to be: import launchpad.net/goamz/ec2 Now it becomes: import gopkg.in/amz.v1/ec2 Bug reporting will remain on Launchpad, as well as an archive of the old source code. The migration was performed with full history preservation. The goamz users group (https://groups.google.com/forum/#!forum/goamz) was also notified of the change. Check out the repository page for links and more information. Have a nice weekend and enjoy! :) - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUiya7AAoJENzxV2TbLzHwvQ4IAMSeXIfR+rlS2Z3Otu1JrMOX Aehdj3clf3/qkl3k77io/hhOGKhMWT96y3O4HxolAzXCJGg9umSBUIVh5Yj9z6B3 YFBtG5+UH4KY/z1rd6KZFjw2IEOsDS3uCCRbA7yrtvDMcOnpIo/AjyUyC4NYZ+si OKpJ/L6nAFK+kkKu7WwRXuRJwCQ2tGELYB8UXBft274NwCwXj6a+ejI9tjsxkm4S JJw5Va0TXheM6MNRcWG6SW7rdmOOG+TwN/duffBh8XAxHdmu0mTjxxW2pY+W1HGD CUjMmiMARuyTuMfeeN4MfjLF4uEnUctpOcVe6XdE43m8rktKf/HYwo5V0rArHXo= =nTL8 -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Goamz Migrated to GitHub!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, There was an ongoing discussion to migrate https://launchpad.net/goamz to GitHub. I'm happy to announce this has happened today - please find the new repository at: https://github.com/go-amz/amz Import paths have changed to use the http://gopkg.in/ format: Before it used to be: import launchpad.net/goamz/ec2 Now it becomes: import gopkg.in/amz.v1/ec2 Bug reporting will remain on Launchpad, as well as an archive of the old source code. The migration was performed with full history preservation. The goamz users group (https://groups.google.com/forum/#!forum/goamz) was also notified of the change. Check out the repository page for links and more information. Have a nice weekend and enjoy! :) - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUiya7AAoJENzxV2TbLzHwvQ4IAMSeXIfR+rlS2Z3Otu1JrMOX Aehdj3clf3/qkl3k77io/hhOGKhMWT96y3O4HxolAzXCJGg9umSBUIVh5Yj9z6B3 YFBtG5+UH4KY/z1rd6KZFjw2IEOsDS3uCCRbA7yrtvDMcOnpIo/AjyUyC4NYZ+si OKpJ/L6nAFK+kkKu7WwRXuRJwCQ2tGELYB8UXBft274NwCwXj6a+ejI9tjsxkm4S JJw5Va0TXheM6MNRcWG6SW7rdmOOG+TwN/duffBh8XAxHdmu0mTjxxW2pY+W1HGD CUjMmiMARuyTuMfeeN4MfjLF4uEnUctpOcVe6XdE43m8rktKf/HYwo5V0rArHXo= =nTL8 -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Too space, or not two space
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.11.2014 02:10, Jesse Meek wrote: I'm coming across double spaces after a full stop in comments. Some consider this an error, others an intentional style that makes the comment cleaner to read. Yes, it's a minor point but in the name of consistency and avoiding future review ping pong on the issue, I'm calling for a vote: Should we have a single space after full stops in comments? http://xkcd.com/1285/ Please reply +1 for yes to one space, -1 for no to one space. I'll tally up votes on Friday and update our style guide accordingly. My vote: +1 - -1, come on isn't this just for typewriters? - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUbELWAAoJENzxV2TbLzHwkrwIAMp1N27Uzfb8+bJ3ZUTJB3wC Pue8uqjeB9YxYbppymxhqmpN3HSGMLfZpdTSQXHCRBvf0iDdqxaBGvP0Vfb1sZ6K FiXGKgypGgKhdgT8bT/YvIiK6AhdKec3xIh0MjJK9hlZAAnorP9PF0zIrQx7CAwx 29z/gMjJ6Sc+Y6pcsg9zCD1WhZ7NlsfpBnnks+VWcZv7NJeQxDMvIp/FywPV8OJg FQ4JxBpuej9UWpUZ40RMVz5dxszqhYhy0BuhPjiMIiCIiAAkhceuIc6VgvWjfEei jgVFtG8P2pQFk4gNRZDqnzC+PO4CxDGjnD/Nfe7QF9VdLxxtckVLcXtM/jms0/o= =RyFp -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: reviewboard update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15.11.2014 07:07, Eric Snow wrote: FYI, I was able to solve 3 reviewboard-github integration issues today: 1. pull requests for branches other than master now work (e.g. 1.21 backports) 2. no more hitting rate limits (5000 requests/hour limit instead of 60) 3. pull request bodies now get updated with a link to the new review request If you have any trouble with any of these please let me know. Thanks! -eric Great job Eric! I can confirm RB diffs for backports to 1.21 get generated correctly now, and the PR description is updated to include a link to the RB diff. There's one issue however -- the link in the PR is https://reviews.vapour.ws/r/id, rather than http://..;, which cause some problems: 1. The browser displays The site's security certificate is not trusted, so I need to either add an exception or change the URL to use http instead. 2. If you do add an exception try to review and click Ship It!, it's not taking effect (Michael had that issue with one of my reviews). So you *need* to use the http URL for the Ship It! to work. It would be nice to fix this :) Thanks, - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUaeWaAAoJENzxV2TbLzHw2kcH/iddKLRScZFgBue9RqcEr5DU XrsSin07R1SrrD7xK/PH9z8ONGCVcXeZyAG+hkZiIu7cmL69pFs/ooOuLPZRHuSs ZmEGi27WMX9Aem4RkJpgjet1xMW1eOAeSYgSHeaqPIzSPWwArl6HedUw0V40/etW 3MJJPQw0FpCl6iEqqJtq85s+Ngs8n58Dk0dAQt7yVKQ1xovoognWwdGrTcio2NIZ y5dDM1c+1OJfkRkZDMUAQpJBq45uit29kDc9XAgHUlWZf/1tXD8SLslLb9Wiz7Us b+fQaP+2L+JjnVdN1gObkhMUF67rJceX1Y5djiEubAp6/RTKaMsHuEZT5O2zERM= =kGql -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: supplement open--port/close-port with ensure-these-and-only-these-ports?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey, Sorry for not announcing the changes to open-port, close-port, and the introduction of opened-ports. This was due to the discussions around the networking model, i.e. things were changing rapidly and I wasn't even sure it's worth announcing it until the ports model is more or less agreed upon. Dimiter On 3.11.2014 17:20, Curtis Hovey-Canonical wrote: On Sat, Nov 1, 2014 at 2:08 PM, Kapil Thangavelu kapil.thangav...@canonical.com wrote: On Sat, Nov 1, 2014 at 12:58 PM, John Meinel j...@arbash-meinel.com wrote: I believe there is already opened-ports to tell you what ports Juju is currently tracking. That's cool and news to me, it looks like it landed in trunk earlier on october 2nd (ie 1.21) and hasn't made release notes or docs yet. Especially for charm environment changes we really need corresponding docs as charm env changes are not easily discover-able otherwise. Really great to see that land as its been a common issue for charms and one that previously forced them into state management. :( How will anything get into the release notes if engineers don't announce the new feature when it merges? It is not the not release note because engineers haven't described it. Asking questions to this list to discover new features isn't very efficient. - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUV6VCAAoJENzxV2TbLzHwF5UIAIBTgqf9N3796XTXAVv+EyR+ 1rXUOyw+wfKWnkwm6v5M6tBV4pmpUN0bPqgkuqKShT4aRdcoi3Q4LP9ElSFnGbX7 yq0zz2TlBfzNb4xZzQofUKRA5qYpapt93Bimh773wax2cvCby87IvPyN2CTv7J1x 8XOTTH1TRsPrIzGYcH1Zc+xT2cVdGh3XVC3oHLC8z6ZYLtjWnoV+CWkfrwO50exn BwAJ3tolAaqnkRo1hsWVBOZIZx2e3Eh6HNWxc9QDIjBvujSKjix/wksaVEkTY1vw L+hHWll/1wp8JOlxGWriJL4TxehijZIHGjnoIaKDrr70MLHB15AGHLubCqjIxe4= =j5oT -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Menno's reviewer graduation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30.10.2014 03:13, Tim Penhey wrote: Hey there fellow Juju developers, I'd like to announce Menno's reviewer graduation. I have been very happy with the quality and understanding shown in Menno's reviews. Congratulations. Tim Yay, way to go Menno! :) I think this should encourage other mentored reviewers to heed the call and graduate. Cheers, - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUUgcPAAoJENzxV2TbLzHwGmEIAIh6Flv+HKF9UGTCUY6dezGU LhoqeCbhSdJB4dyazITcHN+akdYXuR9OEBmbr1rzripAFiwWRiLz1O6SPGRpL4de 4Gq4Gzpd4RooLIBncnQOCWX6eGv01AVohxdBC06xaX2Ne94dm/vxdVcJ3JR1NY9O aPHa5cu/6+CNo9A9lULl5Vm2tS+IrMWSd/gfNxCXektz0Kv2RApOC1gNdfB3uvnT uNcOyOATntBkr02ewzd0SgqOK57vVjbtuUv5+PVw4bFt3wC3+pB+wHROjxOuPAjM gjVTn+MVotCJHuGT0FPmYfcP9jcR6qho1MXTSbj4R5Fdm/X8XiWDUGL3ehgNjJY= =hpNO -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: how to update dependencies.tsv
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1, in fact there is already a godeps target in the Makefile, but I never managed to get it working. It's looking for $(GOPATH)/bin/godeps binary and I have it right there on my machine, but make still claims File `godeps' does not exist. (when running $ make -d godeps). Somebody with better make-fu knowledge should probably give a hand with this :) On 29.10.2014 05:58, John Meinel wrote: can we please just have make dependencies.tsv do the right thing so we don't have to remember which set of flags and env vars we need to use this time? I'm also not 100% sure that we'll have even downloaded all the windows dependencies if they are a strict superset given that you are running go get on a Linux machine to start with. John =:- On Tue, Oct 28, 2014 at 11:41 PM, Nate Finch nate.fi...@canonical.com mailto:nate.fi...@canonical.com wrote: We have a few windows dependencies that are not (and in some cases can not be) imported for the linux build. Luckily, the windows dependencies are a strict super set of the linux dependencies, so we can still use godeps to create dependencies.tsv, just by setting GOOS first, thusly (from the root of github.com/juju/juju http://github.com/juju/juju): GOOS=windows godeps -t ./... dependencies.tsv Please use this command line when updating dependencies.tsv so that is keeps a standard format which will minimize conflicts in the file. -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com mailto:Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUUJlIAAoJENzxV2TbLzHwND0IAMS3c79LeWwTDnf6sEyMwTcm HdvBxaxEeJLNqv8Sq+mK4jWyMAtmoQ/9Azup7g9DZmb1aJXD94n25nf19NNdBkxi wzLBMqq3iEkKY+09js8r5S4ScRMOErBrhL7wd4+PDFTL1y5SeDAacBDCzZQKeQlY IRkIfOXjfSpQuALONZNUlToMAuTQzC80gf914QX7DOpKMFhsiS6cMIb2nYlAScEZ UFjJwRrTEgjiGoouq/KnmahhYK4i4dsdQDy9a44lTgIb+igoAi6OBzTJ8ktqac+G +e+sS25SHJ+T2R+iPtlJnExW3raa9vHxIJQBazB8C/QjLDqrOtzt1XSe5WxlQxs= =akp+ -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: how to update dependencies.tsv
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29.10.2014 09:46, David Cheney wrote: Does your $GOPATH include more than one entry ? No, it only has a single path. The make target should probably just expect godeps to be in your $PATH. That's a good point. I did some experiments adding: GODEPS := $(shell which godeps) at the beginning and then trying to use it. I found out what the problem was - apparently the Makefile was written with the idea that godeps shouldn't be called unless JUJU_MAKE_GODEPS is set to true. With the following patch, I can now run make godeps and related targets without an issue: diff --git a/Makefile b/Makefile index 3b6f2ec..4fe7611 100644 - --- a/Makefile +++ b/Makefile @@ -37,13 +37,9 @@ ifeq ($(CURDIR),$(PROJECT_DIR)) ifeq ($(JUJU_MAKE_GODEPS),true) $(GOPATH)/bin/godeps: go get launchpad.net/godeps - - +endif godeps: $(GOPATH)/bin/godeps $(GOPATH)/bin/godeps -u dependencies.tsv - -else - -godeps: - - @echo skipping godeps - -endif build: godeps go build $(PROJECT)/... Somebody else might find this useful. As for the update godeps target John suggested, I still think it's the easiest way to do it correctly. E.g. it could be a new target: + +updeps: godeps + GOOS=windows $(GOPATH)/bin/godeps -t ./... dependencies.tsv On Wed, Oct 29, 2014 at 6:37 PM, Dimiter Naydenov dimiter.nayde...@canonical.com mailto:dimiter.nayde...@canonical.com wrote: +1, in fact there is already a godeps target in the Makefile, but I never managed to get it working. It's looking for $(GOPATH)/bin/godeps binary and I have it right there on my machine, but make still claims File `godeps' does not exist. (when running $ make -d godeps). Somebody with better make-fu knowledge should probably give a hand with this :) On 29.10.2014 05:58, John Meinel wrote: can we please just have make dependencies.tsv do the right thing so we don't have to remember which set of flags and env vars we need to use this time? I'm also not 100% sure that we'll have even downloaded all the windows dependencies if they are a strict superset given that you are running go get on a Linux machine to start with. John =:- On Tue, Oct 28, 2014 at 11:41 PM, Nate Finch nate.fi...@canonical.com mailto:nate.fi...@canonical.com mailto:nate.fi...@canonical.com mailto:nate.fi...@canonical.com wrote: We have a few windows dependencies that are not (and in some cases can not be) imported for the linux build. Luckily, the windows dependencies are a strict super set of the linux dependencies, so we can still use godeps to create dependencies.tsv, just by setting GOOS first, thusly (from the root of github.com/juju/juju http://github.com/juju/juju http://github.com/juju/juju): GOOS=windows godeps -t ./... dependencies.tsv Please use this command line when updating dependencies.tsv so that is keeps a standard format which will minimize conflicts in the file. -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com mailto:Juju-dev@lists.ubuntu.com mailto:Juju-dev@lists.ubuntu.com mailto: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 mailto:Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUUJ/XAAoJENzxV2TbLzHwEEwIAJcohbpcUZ6wVG30bhoMsDRa NkJaNeMErfEZIHa0kA9iqACXKhLMngS7M/Dbmryuat/X9NFPOkElLLBZnyydhmqv DcQXU5Sc6s1K1T5UxXH13jJ80JHQgKo5hg0LO/5gnd81R/iz4mQ7ns54uD8hnNfE D70FcxBIt+kiMXAU0WB/r8kC0++2afrNQQGpvAp8RntGtCNSH501AAkDq0WmtLw/ iq/8uhLD8lixU/uPHG1PxaxAWaDZ3nkkievl+0t9cgYZAe6xQBOYs9DA+pPMSTxS Oo+dgsakCKeCqv+7zI4D/h754VzaWyvLYsX0ldWpn+12jywWJHZwoznh5Fm6xYA= =FwVZ -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Multiple networks with JUJU and 3rd party Cinder integration.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25.10.2014 03:13, Mark Shuttleworth wrote: On 24/10/14 15:28, Nate dell wrote: I'll look at binding specific cdrs to the openstack charms. It sounds like your suggesting using a configuration management system like salt, ansible, puppet, or chef in conjunction with juju. Ansible is setup at the client so will look to integrate the two, was reluctant to do that out of fears they would step on each other. The IRC channel has been very helpful in providing suggestions on how to proceed on the cinder side. Hey Nate, Thanks for considering Juju for your scenario! The different systems can easily be made to be polite to one another :) In a little while you'll be able to specify a charm to put on every machine, or groups of machine, and that will probably be a cleaner way to handle the baseline machine setup. Mark In the mean-time, until Juju starts to provide this feature, you can consider a workaround. It looks like all openstack charms can have a subordinate unit (on the same machine) via the hacluster relation. If you write a shared subordinate charm, deploy it, and relate it to the openstack services you need to configure, you can have the same code executing on each machine. I hope this helps, - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUS909AAoJENzxV2TbLzHw7qoH/3T1fxB1ugJ5cJUTGvlPIF6p BPq0xe3VwS82aCFDEbZZMwOsWhb8IlWtcuDTc0kS0zJRm5ZVwq0CZq5tIIYC30+V pDmKBqGup8O6W8WyqWv80vssUOFt1gfMhL8OrRNJO/pklXD7J4i9qDiIx/Y3dYBu vQBh8RbHZ0V/mESQ7yMgrJ1k9KdbvTLxpnUk5m+J2EfBAGfGbWZEdSeakGPb6DSo yebmR1ThI0AP+srxx1mlDUo6p0MbNXe4VXlDu2oG8nOJg7A6sYKuCyYICO4lgq3p gomxILNLHARCPY0O8tjNqQAiykW+OxdzxE1v0pb96xVnIrjpe1h50Ba3qrDwvX4= =dhJp -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: reviewboard-github integration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Eric, Today I tried proposing a PR and the RB issue (#202) was created, but it didn't have Reviewers field set (as described below), it wasn't published (due to the former), but MOST importantly didn't have a diff uploaded. After fiddling around with rbt I managed to do: $ rbt diff ~/patch (while on the proposed feature branch) And then went to the RB issue page and manually uploaded the generated diff and published it. So most definitely the hook generating RB issues have to upload the diff as well :) It's coming together, keep up the good work! Cheers, Dimiter On 20.10.2014 16:53, Eric Snow wrote: On Mon, Oct 20, 2014 at 6:06 AM, Ian Booth ian.bo...@canonical.com wrote: Hey Eric This is awesome, thank you. I did run into a gotcha - I created a PR and then looked at the Incoming review queue and there was nothing new there. I then clicked on All in the Outgoing review queue and saw that the review was unpublished. I then went to publish it and it complained at least one reviewer was needed. So I had to fill in juju-team and all was good. 1. Can we make it so that the review is published automatically? 2. Can we pre-fill juju-team as the reviewer? Good catch. The two are actually related. The review is published, but that fails because no reviewer got set. I'll get that fixed. -eric - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJURSrnAAoJENzxV2TbLzHw0BQH/16P4qPDI28kkGs398qRKY5s eUtcHBpYs+JuLV2ZA0LjCpTds89RBDW6cKsxcfXxaAmawIb0KHh920VzKb1Wl2OT z/iMOF2q91LnV58dqPf7mZjHaT1LPRdSRxg6aAZW/mjexwVRtRDT4Asd5w6JpKrH 9Tkqfy86OilJ70X8qNbegvjJrBAttwoLLI4jwJq4dNWUbWCBbuumryh0k6+GlmNH NiKbpi45pPy/RIFVA7ewbLIOpUXleHm5NIGlA/liZOMHpz0w5QHK3FYGLuGMNzQC fq4qW6rfb1ITdr7XWsA3gooV6FUndw3mbNsod3QgSv82RDA6GGECHeYimGG94/g= =POJ4 -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: API Versioning for compatible changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Just to let you all know, the Uniter API facade is now versioned: - V0 - all existing methods except GetOwnerTag - V1 - a few new methods related to port ranges support added (AssignedMachine, AllMachinePorts, and ServiceOwner to replace the deprecated GetOwnerTag). At the apiserver side, each version is in its own file (e.g. uniter_v0.go, uniter_v1.go, with uniter_base.go containing common code for both versions), and the same is true for the unit tests (e.g. uniter_v0_test.go, uniter_v1_test.go, and uniter_base_test.go with common tests shared between versions). At the api (client) side, a BestAPIVersion method was added and used internally to check if a method is available and returning an errors.NotImplemented otherwise. So please, from now on add new methods in V1. If something needs to be removed or changed, and you're unsure how to implement it or test it properly, ask me, Frank, or John, and we'll be glad to help. I hope in the future more facades will get refactored like that, and we can make the code and tests maintenance easier, as well as design APIs with versioning and backwards-compatibility in mind. Cheers, Dimiter On 30.09.2014 14:16, John Meinel wrote: This came up recently in a discussion about the Uniter API, but I think it is a broader discussion that we should be having. If you are only adding a new method, it is possible to consider that this is a compatible change, and not bother to do the extra work to create a new version for that Facade and deal with multiple version compatibility. I would argue, however, that this is actually only half of the compatibility statement, and we actually make it harder for clients that want to use our API to do so properly. Consider if we have Client V1, and then we add a new method DoMagic(). If we create a V2 for it, then clients that want to use DoMagic can just do a do you have Client v2? and then decide right after Login what code path they want to use. Otherwise, they have to first check do you have V1 because that is the first version that might have DoMagic, and then do the DoMagic call, and check if they get an IsCodeNotImplemented error, and then fallback to compatibility code. I do realize that there is overhead in doing this work. Especially given our current code base (with no versioning) most of our tests are not easy to apply to 2 versions of a Facade. However, as soon as we have 2 versions, we'll need the code refactored and then the third version should be much easier to create. So I think it is just a cost that we need to just do. The other axis for discussion is whether we go through this effort for all of our API, for only Client apis (and leave Agent APIs to really only have 1 supported version). We did 1 supported version for Firewaller, because the new one can't get its job done with the old API. Thoughts? John =:- - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJULogSAAoJENzxV2TbLzHw8UYIALoqCSKAeDi/ticuMnMGfcwv SYLRs6noCNGh/5Z2sGN1/Da9/4uQXPd6d99vEypZvWIl97J5aCtiHD8NKFYqrkwX qTApprs0MEB9Ep1JJW6IZ7kGYL/3+HK7Bizv0CNmrkgvGSTnib2WC6RF4qduP+p3 2CiqBxBEwZ9bnCi21tX4Mbc4UFcbWHrILdE7KMOOQgpkjh/3TXHxfez968ZDuit1 JZ1lnudGwte6qqrPzJgyK4Mvc/MfpL9qxFJrwYzo5UNOwI9hg62EJMimHFmyUb0x lTJ0/9MLYZD7iS5xsB/RovSV6FNp7oC/C34nMjUIVgxcbXRVMYWMKe25POXbkLI= =f6gF -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: RFC: state entities, replace globalKey() with .Tag().String()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24.09.2014 06:53, Tim Penhey wrote: Hi folks, I have been going through much of the code in the state package looking at the work to migrate all the collection keys to handle multiple environments. In the long and distant past (earlier this year), the Tag() method returned a string. There is a second tag like thing in the state package called the globalKey. This is used as a collection independent key into annotations, presence, settings, networks and status. It seems that the only things we ever use for this are entities that have their own tag types. If we ignore actions (which I don't think should bother implementing globalKey), then we are talking about: machine, service, unit, and network. I propose that we replace all occurrences of the globalKey with a string representation of the Tag for that entity. Why? Global keys are a shorter than tags, and in several places we use fast regular expression searches using a prefix based on the global key. So instead of having m#0#n#juju-public as global key for a port ranges document, we'll have to use machine-0*network-juju-public, where * is some unambiguous separator. The same is valid for service settings - s#wordpress will become service-wordpress. I'd rather have a transparent transformation in place to convert global keys to tags, where needed (the only special case I can think of is relation tags relation-123, which cannot be converted back to relation names (e.g wordpress:db mysql:server) without a DB lookup). Also, what I didn't understand is how using tags as global keys will solve the case with multiple environments in the same DB? One good part of this, is that for any element of the other collections, we can use the existing state.FindEntity(tag names.Tag) function. Is anyone opposed to this change? Cheers, Tim - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUIl6FAAoJENzxV2TbLzHwTIEH/2UBuTZDZ+q/4cA+lobBkzlF USCuH2QWHh2IAjDqpTBgOyhqfBiN/eWXlxkoay6WfdPMeulUuZfcNG+E2rK/0Zs6 GE6W5MLLUEftgPm4cBCKyaaJozcpK4Yr7aQfLM9A0XcD3iQziyQPaceHZh5jB+Al bzuoCdAy1d8oC5D0Ir3SIBWN5scytDCUyhOfrkqJCa8euFxTkYwidgCcLXyer1wn I0MuoBP1yEfloJx2y7WAbVkmPU9vs8rjNMu5mLh+DyjwJWlF2s2q2kATccu/E9zu tx991nqkplmrfqIOqX/OREYt6vwrnkYQUsZDMARIhDwLA1JzgT7/mXzGuxOs5fc= =82Nr -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: RFC: state entities, replace globalKey() with .Tag().String()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24.09.2014 10:09, Tim Penhey wrote: Why? Global keys are a shorter than tags, and in several places we use fast regular expression searches using a prefix based on the global key. So instead of having m#0#n#juju-public as global key for a port ranges document, we'll have to use machine-0*network-juju-public, where * is some unambiguous separator. The same is valid for service settings - s#wordpress will become service-wordpress. Sorry, but this is terrible. The regex searches we have are needlessly complicated, and the documents should have real fields rather than disassembling the _id field. I think that having a slightly longer value stored in mongo is worth the code when it means we go from having two ways to identity an entity down to one. Using compound keys like that allows us to overcome some limitations of MongoDB/mgo with regards to ensuring integrity, which is otherwise either impossible or quite hard to do with transactions. If I use the port ranges document as an example again, the compound key including the machine id and network name gives us: - A way to get all docs for a given machine and any network, using a simple regex like m#42#n#.*. - No need to add unique indexes to guarantee only a single document per machine / network (and using unique indexes has other drawbacks - mgo returning nil and not inserting anything when there's an index violation, so this means additional checks and more complicated asserts) - Using the _id field gives us uniqueness and fast lookup by id, slightly slower regexp lookup, but still faster than other cases. A more complicated example is the proposed network interfaces document structure: https://docs.google.com/a/canonical.com/document/d/16SYAlZFc19YPXrB7BRwufZVoeLFpqGzBTAdo4EoQIHg/edit#heading=h.pwdo7b7njiz9 There, using an _id field like m#id#sha1-hash(network#mac-addr[#suffix]) gives us both a way to get all machine NICs easily, but also guarantees there won't be a chance to have a NIC with the same MAC on the same network and machine. The same is much harder or impossible to do with asserts on multiple fields and unique indexes, in a transaction. I'm not opposed to replacing global keys with tags in state, but using only simple _id fields in all collections is impractical in certain cases. - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUInUuAAoJENzxV2TbLzHww5MH/A0foVm/+dYfHWLNsEyi//DN 7QtkkJxmu79JYBzG15fCIrrBDa6Edx0VCIYeEvsQmRRnDJUH+H4IWtlvmssxaxw2 WWoOVuDgCn5oKbEE0NKSbYq3dbk2q4VUryPml+0n79KZxZQrI9Xry6W/o2pm0BQc LIEU5RjxgD1YXV/B+0cvp9zpKmwm9/Pi6VsXF5O8sewINh0INr0HEMOYPt+LLsec yIMcdd7ujIxL/hU1IOjtLkwBaPSXSxcbK5UUzO0aG2KNswfxCXO7X99kpFlg7z29 xqdoW7UCEkzoWrSCHWmkiTyCYa1zPApHEBd/tA/K34BV+XEDFMolFi9b8GmhliA= =sX4m -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: RFC: state entities, replace globalKey() with .Tag().String()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24.09.2014 10:46, Tim Penhey wrote: On 24/09/14 19:39, Dimiter Naydenov wrote: I'm not opposed to replacing global keys with tags in state, but using only simple _id fields in all collections is impractical in certain cases. Don't get me wrong, I'm not suggesting changing the _id fields to be more simple. I understand that they are needed for the watchers (at the moment). I fact, the _id fields are getting more complex as we prepend the environment uuid to it. However we are also adding a normal field for the EnvUUID so it can be easily queried against. Tim +1, this sounds good to me! - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUIngDAAoJENzxV2TbLzHwcwAH/iGJbsaVRQcF326W+R+1JIA/ Hlzo/srbTXulrI029aw8JYjIhXnzvlzvYpaOZvE9trdH1izr0lcSd/m3kcJIv4Bq bXCNZDJlSrudV6E3DQKqBSWyCM7HRUEUa498MGcNBkmPxgQwwdFddV62YCyqT4R7 T/pgU5/cNrh73QL6C0xoFJOy9NL5LXYHM8cURBB2RmhSuHj7I8QUk3+/DRxL/Tc5 cIjzjhj6t6Y5DOtvgsXJK4Hx3DsaOSw04lyW+hWvy5PfZPk6Lj4VJFYfhHx93SMG RF3ObX2ArF26m2insrv6S2du9adyoh2OGZA9CeCyDKE9BOtvy4zW7ljH25EvlJQ= =995A -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Is ReviewBoard a good thing?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.09.2014 03:32, David Cheney 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. +1, Due to all the steps you need (to automate) in order to post the review correctly, you're on your own w.r.t. chained diffs, finally the annoying web UI win non-obvious and ways of doing things; I'm a bit disappointed at what RB brings more than just using GitHub PRs. 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 - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUG+WLAAoJENzxV2TbLzHwbw8H/3a7LlCW4FUYsGklM2/P78+q 8KpjZkNrbSD4PY9CGuRIcOKrT40VCJXMuMlfsaXyIXPktD+zTQGjAjlFMAXaA5El LUmRIwL4vHJuioNerkTBlgyzWqsyl8KA0M1IKilga+GQk7hhEvPcmWLBQI+Qniz2 +GvjG4xUb+QSsFpL3TIbZC8vMu0vsFU3N73v5LTxhxh3udr0AM8dHBHIuVcMHXMF 1nAs4DbIBDSKoJ5e7vvnKn/h6XiBP2iJNwWZBwnjpKEwXW8fSX7vR16CQDOQd4Pd 3KiDTMc1qC32SqAfpvoOc9oEJad0r/+xFvV1phBAS9X5ry3AuBpOHmDiPB/EwCA= =n7u4 -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Is ReviewBoard a good thing?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.09.2014 16:44, Richard Harding wrote: 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. +1, In addition you can always check https://github.com/juju/juju/pulls to see what's in the queue. For sub-repositories it's the same, like https://github.com/juju/names/pulls. While I agree it's not all in one place, I tend to work on the main repo mostly, and alternatively you can check the Notifications page (https://github.com/notifications) to see all activity. Dimiter Rick - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUHDXWAAoJENzxV2TbLzHwV68H/1kJfNtOvaPSeKIc9DheDmUr ainEU/blIbY4CQe04lybX6vVoK+KZaFwddoeFa17rou7ReDckp3S4yBTZXcD0KO0 QvwYbuqnepWi9pKN3dcuJftknaEE9vLqslWzjTFyZmjS96RGXT3WlR/CrCCZnjUw Yr7K33ytjcr0oBo8bEk0G0wOkQvwVuvlnNLPPaZF681QyqvODRD+jmgs7SGeUuJu GS6vLzIppd6xJQiDy72slcLdAcMyPkqCm2jOTosy5ZSMDKHjxgIP0s9uaHmTIJO2 BdZxik0TZfsA7r+DRwhQndvKdmklmcLUQAxp5+oY/nPyGe0s5lZ9PC37p+BtrD8= =L6g5 -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: ReviewBoard is now the official review tool for juju
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.09.2014 10:44, roger peppe wrote: 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. Yes, using the merge workflow you quite often have to deal with resolving the same conflicts each time. And at the end you have a bunch of merge changesets, which is not very helpful for following the commit log later. Just two reasons I'm using the rebase workflow, each time I fetch master, I do an interactive rebase and usually leave only one commit (folding the others in it). One more thought re rebase considered evil/impolite - I only do that in my own branches, which is not a problem (even after the initial push, I still rebase, despite the branch going public). I guess this won't work well if you have to collaborate with other people on the same branch, but this is by far less common scenario. Cheers, - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUF+3+AAoJENzxV2TbLzHwLwEH/0VhdicdszrULpWma00mIYB0 G5xZnDEEXsB2Ud1EBhvLm84OIQeIfpuL/osbPEeb9xR1w8856Gll36nbNr8wuQle S+Wq/Gj3VT5jYo7TthUem6qG415/FLa9erPYmCXbyNynXHdBUA5Y8eTbRCZSUC0a kEdUot/vs5aPlZnFgvrxPtKZ2J7D37BslhZZujKQrDeMEoQHtZ9fgYKHDJovE3Yn 9TGcqX+d8mYxQrOD1GkBxcjEbt919ti3s3cqZDTzi/7zeGgXfCjMGoG4gEuPX5Jv O1IHjIqYxJRx0K5qkGimKtIMYe15WOEA4dCkd9p6pdLMh690lqwYwdp1MqVYlEo= =RS8e -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: ReviewBoard is now the official review tool for juju
-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 mailto: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- -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Eric, On 15.09.2014 21:18, Eric Snow wrote: On Mon, Sep 15, 2014 at 11:05 AM, Katherine Cox-Buday katherine.cox-bu...@canonical.com wrote: Let me preface this by saying I like the Reviewboard style of reviewing changes. It's somewhat concerning to me that our reviews are now disconnected from what will actually be landed into trunk. In Github, you were reviewing the actual diff which would be landed. In reviewboard, we're now reviewing a diff manually uploaded by the developer. There's a lot of room for error in terms of what diff we review vs. what diff we land. Any thoughts on how to couple these things once again? I'm working on integration between github and reviewboard such that creation of a PR creates a new review request automatically. The same goes for updating a PR. Not only will that address what you are talking about, it will remove the extra steps of creating/updating the review request yourself and of closing a review request as submitted. Ergo, rbt would not be needed for the typical workflow. You would still use it for pipedlined branches, though that could probably be automated as well. - From my meager experience with writing git plugins (any executable in $PATH with git- prefix), what are you describing can be easily achieved. If you write a git plugin, named e.g. git-rbpropose, using the GitHub CLI (https://github.com/github/hub) and rbt, you can automate the process: 1. Pushing the branch to origin (checking for uncommitted changes). 2. Creating a GitHub PR for the branch, which includes launching the default editor to fill-in the PR description (using hub). 3. Creating a RB review (using rbt). 4. Optionally opening the default browser with it. I have a couple of handy scripts that do this, which I've shared before: git-sync (), and git-propose (), along with a few aliases (). git-sync fits especially well with the RB workflow, because it pull upstream/master into your local repo's master, then pushes it back to origin/master, and finally (when you're on a branch other than master) rebases all branch commits over origin/master, interactively. What usually do is run git propose after the finaly git sync to create a PR - the only thing missing is the RB steps. There is the possibility of pushing info from ReviewBoard back to github (e.g. ship-it - LGTM comment), but I don't think it buys us enough to make it worth it (it's notably trickier). -eric Cheers and thanks for all the hard work around putting RB workflow in place, - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUFzXyAAoJENzxV2TbLzHwPT8H/jeke5kS/VoNxL/mmGaK4IWW 5+tS7VNH9DewaRj4ZPsLtKmQvHW5oXYf5aJFEXpC3LFD9vqkyyNJQwoOaoBOQnwh FkDmTOALgXYYBd7PPsXI3fjUhjfKdcug8y7SmLLyvS61APHV1yH5++hyJdsHUany 80kFVkTbkXoMRW7BtdHREgH/tDdnEaHgJpQzbUPEuk/+gd82+q4+lnbvfs8sR/00 x1OGXzdiyGjwKSgbeFyEfUD0+mIG8xI7IUx1oVTLoLYM82i6WGZOB6g3qnh3s/bK 0ylyy09q645SNyDgsuZp8Bt8VrG92K057M/O/O+QnkeDkSHuqb27hKS+wFO2Ekg= =mfDJ -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: ReviewBoard is now the official review tool for juju
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yeah, sorry I forgot the pastebin links to the scripts: git-sync: http://paste.ubuntu.com/8352455/ git-propose: http://paste.ubuntu.com/8352460/ git config -l | grep alias: http://paste.ubuntu.com/8352470/ (useful aliases I use) On 15.09.2014 21:54, Dimiter Naydenov wrote: Hi Eric, On 15.09.2014 21:18, Eric Snow wrote: On Mon, Sep 15, 2014 at 11:05 AM, Katherine Cox-Buday katherine.cox-bu...@canonical.com wrote: Let me preface this by saying I like the Reviewboard style of reviewing changes. It's somewhat concerning to me that our reviews are now disconnected from what will actually be landed into trunk. In Github, you were reviewing the actual diff which would be landed. In reviewboard, we're now reviewing a diff manually uploaded by the developer. There's a lot of room for error in terms of what diff we review vs. what diff we land. Any thoughts on how to couple these things once again? I'm working on integration between github and reviewboard such that creation of a PR creates a new review request automatically. The same goes for updating a PR. Not only will that address what you are talking about, it will remove the extra steps of creating/updating the review request yourself and of closing a review request as submitted. Ergo, rbt would not be needed for the typical workflow. You would still use it for pipedlined branches, though that could probably be automated as well. - From my meager experience with writing git plugins (any executable in $PATH with git- prefix), what are you describing can be easily achieved. If you write a git plugin, named e.g. git-rbpropose, using the GitHub CLI (https://github.com/github/hub) and rbt, you can automate the process: 1. Pushing the branch to origin (checking for uncommitted changes). 2. Creating a GitHub PR for the branch, which includes launching the default editor to fill-in the PR description (using hub). 3. Creating a RB review (using rbt). 4. Optionally opening the default browser with it. I have a couple of handy scripts that do this, which I've shared before: git-sync (), and git-propose (), along with a few aliases (). git-sync fits especially well with the RB workflow, because it pull upstream/master into your local repo's master, then pushes it back to origin/master, and finally (when you're on a branch other than master) rebases all branch commits over origin/master, interactively. What usually do is run git propose after the finaly git sync to create a PR - the only thing missing is the RB steps. There is the possibility of pushing info from ReviewBoard back to github (e.g. ship-it - LGTM comment), but I don't think it buys us enough to make it worth it (it's notably trickier). -eric Cheers and thanks for all the hard work around putting RB workflow in place, - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUFzccAAoJENzxV2TbLzHwKkgH/0f4/oc2uiuo/vgbvjVM0UWe /0cF7MshfJV1dVRFZjBJV8EKuKNM0Z3DIJ6ypljJTRqn+osd3pv7svheqTD5ZE+k JGjYZJ2HuZDgxeL/0yXLT+dWjKj/5dyZjTRKmQacASXMhO3siEoMVhK1kYoTDRNp 4lQtYWkxaLmlCxIobRWaGDQT2TwQ0ICIgicwXXYBqaAa197Gkbc/vbCOpVHJyxHM HvKut28qen1HlWat9lvUcyrnA0337398p+f7gXWam/5Co9WIWiqtAw+At5ay2AIk 5n/0orPB9sGRqQzV8sYXTDosxkNe3WLFyoLkW2iMy1tnXrGBV3xuKq2yGke6+1c= =bxal -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Fixed reviewer schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.09.2014 06:12, Tim Penhey wrote: Hi folks, Those of you who are reviewers should now have invites to your bi-weekly review time. This now occurs on the same day every two weeks. I have tried to have the mentors on the day after the mentees (or overlapping). Also tried to spread out the different timezones. It will never be perfect, but hopefully this is better now. Cheers, Tim Great job Tim! No more poking into spreadsheets :) - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUEVnWAAoJENzxV2TbLzHwxzMH/3cIDt9y4ESoXcm4Ige/9dB/ ty6pkPEjD6ZA6Yteopj/bzqbTrXTkQwKm0UZAw31uqx04DbAMwzemJkjHCc5dpQH qElnA6dilFmDStb+yghQur25ucf0gjgsvoA7ADzFfvIpHgDB4nkRVvJRCCyI4Wu7 7/THnCRvl+VrtrY6FvzMAINkuCTqKZJ9232+Q6FUJsT0bi2b3Q8JVaonFNmZa3Bm jSdcvyABFMg48uvbdnfvW0KVGIg5V43YH8IoT9HxcW6ezjWqeU1lVW34xWQ1i8al JCru1IC071f/dg89th6sZe+uMXyWrluFAwV29FwQd0+vzenPDlRC/y9eAHqReWw= =nmlo -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Copyright information in headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4.09.2014 00:54, David Cheney wrote: I think this is needless busy work, I vote that as long as there is a copyright header with _a_ year, that is sufficient. +100 Let's not do that please, it's pointless. On Thu, Sep 4, 2014 at 7:50 AM, Ian Booth ian.bo...@canonical.com wrote: Hi folks The question recently came up in reviews as to whether we should be updating the date in the copyright statement in the file header when we make a change to the code in that file. I sought clarification from Robie Basak, who previously had provided input on licensing issues and compliance for getting Juju included in trusty. Below is what he said. TL;DR; It doesn't really matter, we just need to agree on a policy. It is suggested though that we do update the date when we make a change. Agree? snip What's our policy for dates in copyright headers? // Copyright 2012, 2013 Canonical Ltd. // Licensed under the AGPLv3, see LICENCE file for details. From the point of view of acceptability for Ubuntu, it doesn't particularly matter, and I don't believe it'll cause any issue for us whatever you do here. I'll certainly be happy to upload whether or not you update the date. I'll try to explain my perspective on this, but I'm not entirely confident that there isn't something I'm missing for the broader picture, so note that I Am Not A Lawyer, etc. For the above, do we need to add 2014 if we modify the file this year? Or is the date just meant to be the year the file was first published? I think it's meant to be the sum of all the copyright claims on the file. So if you add some new code, you have a copyright claim on the new code in the newer year in which you made it. AIUI, the purpose of the date is that since copyright expires (theoretically, anyway), updating the date updates the copyright claim, which would give us more control in the (eventual) event that copyright expires. In practice, IMHO this is never going to matter since nobody is going to care about the copyright on a piece of software that is that old anyway. But I suppose laws could change, so the right thing to do would be to add a new year whenever you make a change in a new year on a per-file file basis. BTW, it's common to fold 2012, 2013, 2014 to just 2012-2014. But I don't particularly care for upload purposes. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUCAbIAAoJENzxV2TbLzHwNNoH/23/rP6+2B8BrGBnw1ap20cx X+JcDxfA8LToDthb5sauS52lpauDtZqqju9oEDnEeK5537LMMrUjZku8W75GA07D NrR5jJIwMnJEFmKom0hSVI6XeP7gorqlAdMCBJbwy9/q10jEllkhBxNie+ys4n+V uPNvKKXbm/2p+OPxo9Mp2a/DxIfpYhaOEcbFUM7kjR2jr6tD361yLt6tHqhbVBEn ej/ooV65eRE2kAzf3FaKv4HYBMENdXR56aQ9SJUhOved6bWlSHaEsKo5RjVXnrFT ZcCMGjmmZxnaB+l6WjAXETbwpjQOzStDsLsQ+ePyKu66CAcMLHvoInme0eHXasU= =Z0NL -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Copyright information in headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As we're on copyright headers topic, is there a clear policy what headers to use for contributed code, like the one Joyent did or CloudSigma ? Should it be: // Copyright 2014 Canonical Ltd. // Copyright 2014 CONTRIBUTOR-XYZ.. // Licensed under the AGPLv3, see LICENCE file for details. Or: // Copyright 2014 CONTRIBUTOR-XYZ.. // Licensed under the AGPLv3, see LICENCE file for details. Or even: // Copyright 2014 Canonical Ltd. // Licensed under the AGPLv3, see LICENCE file for details. That to me seems more important than should we update the year when we change the file. On 4.09.2014 03:04, Andrew Wilkins wrote: On Thu, Sep 4, 2014 at 5:50 AM, Ian Booth ian.bo...@canonical.com mailto:ian.bo...@canonical.com wrote: Hi folks The question recently came up in reviews as to whether we should be updating the date in the copyright statement in the file header when we make a change to the code in that file. I sought clarification from Robie Basak, who previously had provided input on licensing issues and compliance for getting Juju included in trusty. Below is what he said. TL;DR; It doesn't really matter, we just need to agree on a policy. It is suggested though that we do update the date when we make a change. Agree? snip What's our policy for dates in copyright headers? // Copyright 2012, 2013 Canonical Ltd. // Licensed under the AGPLv3, see LICENCE file for details. From the point of view of acceptability for Ubuntu, it doesn't particularly matter, and I don't believe it'll cause any issue for us whatever you do here. I'll certainly be happy to upload whether or not you update the date. I'll try to explain my perspective on this, but I'm not entirely confident that there isn't something I'm missing for the broader picture, so note that I Am Not A Lawyer, etc. For the above, do we need to add 2014 if we modify the file this year? Or is the date just meant to be the year the file was first published? I think it's meant to be the sum of all the copyright claims on the file. So if you add some new code, you have a copyright claim on the new code in the newer year in which you made it. AIUI, the purpose of the date is that since copyright expires (theoretically, anyway), updating the date updates the copyright claim, which would give us more control in the (eventual) event that copyright expires. In practice, IMHO this is never going to matter since nobody is going to care about the copyright on a piece of software that is that old anyway. But I suppose laws could change, so the right thing to do would be to add a new year whenever you make a change in a new year on a per-file file basis. BTW, it's common to fold 2012, 2013, 2014 to just 2012-2014. But I don't particularly care for upload purposes. Depending on the country, copyright notices require the first year of publication. I'm not aware of any that *require* the full range, but in some cases it is recommended to have it on ongoing works as a claim of authorship. As Gustavo says, we have this in revision control. We work in the open. Let's not get distracted with unnecessary work. - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUCAeJAAoJENzxV2TbLzHw9S4IAKn3xfbzaoIrGweWgtUE9jxS 0c6/Hwluwnekj4ERjkDvO6fN2zCGcMOi55Itq6IuBpR8zKnT5bhNORTJbi0KKIiF qh3gFpfDmju2u3fo3LFNxmRxSI7CWpeOf6fuRzcGk45P1v6RafrfQQjxKAorDtxe iNRZswvTY3RfYHZwGo92zxENGLsJm0oQ8BA3YBDa5mNVyBk/SFuI1jLJSNzvCSCQ pD+kzrWr2JMV/hHscba/OcZuZtvWPwYTWP1zeRRVJKiU9HPsDtKhfl2kCtF5olqO zl1gHIyetzwdNalJjfkHs1o5Trrvi0EkYpp++CXHRU8H5KZz22AhzRG5qULbIfs= =IotS -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: add-machine and add-unit to this machine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Juju CLI won't give you the machine ID in a script-friendly format, so you have 2 options: 1) Use juju-deployer, which supports complex, scripted deployments with juju and offers a lot of customization and tunning. Docs: http://pythonhosted.org/juju-deployer/ Source: https://launchpad.net/juju-deployer (you can apt-get install juju-deployer) 2) In you script, parse the output of juju add-machine to extract the machine ID from the created machine XXX string an use it. I hope this helps! On 6.08.2014 15:15, Ilisia Felane wrote: Yes, ok, I know do that manually. but for a script, I try to create a new machine and install over an entire service. Without having to know the number of the machine. This seems possible MaaS creating a machine with a tag, but not implemented for the Cloud. My question is how can I create a machine identified under a certain name and install it as a service you need via this identifier. 2014-08-06 13:34 GMT+02:00 John Meinel j...@arbash-meinel.com mailto:j...@arbash-meinel.com: When you do juju add-machine it should print out a line like: created machine 10 You should be able to then do: juju add-unit SERVICE --to 10 John =:- - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT4h7tAAoJENzxV2TbLzHwd2sH/RUR4XZLHZH6R8oXqzCMnixP zUSt5IrzLFfsSaNRpzlEP63JWEmGgJpSOVudBTF8mug/7DYhAmHGc+Usyn/JPMIg RR77x3nonB2OBRmLjKcaw1mWY6Tqxpdy9gdepE/bxygi4vY68mNd1hBQaVGAtsrE fDCgPFFHDhrMXXu5t5EUZdfJzgUlf/GYC9wJnKB3RyyKsgGRSXWu2Wq2bKtBdpr8 SdRLphOul4iE5KquRrnUb+bqoBolL/Sw94lITw6nTWYQRo9E6abvfNxPnUhVKxd9 gCxrKfIVlQJiZBWSOzZUl7GyP8y8Dp8C56UFFORVGuIk4UKXxRy9rn9y0fcTzl4= =JoBu -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: avoiding unnecessarily entering upgrade mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This SGTM as well, however (see below)... On 6.08.2014 04:10, Menno Smits wrote: Right now, a Juju machine agent is in upgrade mode from the moment it starts until the upgrade-steps worker is finished. During this period API logins are heavily restricted and most of the agent's workers don't start until upgrade mode stops. This happens even when there is no upgrade to perform. The upgrade-steps worker always runs at machine agent startup and upgrade mode is in force until it finishes. Upgrade mode is typically short-lived (say 10 seconds) but if something is wrong (e.g. mongo issues) the upgrade-steps worker may take longer or not finish resulting in the user seeing lots of upgrade in progress messages from the client and in the logs. This is particularly confusing when a user hasn't even requested an upgrade themselves. I would like to change the machine agent so that upgrade mode is only entered if the version in agent.conf is different from the running software version. This would mean that upgrade mode is only entered if there is an actual upgrade to perform. If you are referring to Upgraded-To version field in agent config, I think this is set after the upgrade completes, so it might be unavailable before that. The version in agent.conf is only updated after a successful upgrade so it is the right thing to use to determine if upgrade mode should be entered. The current behaviour means that the (idempotent) upgrade steps for the current version are always run each time the machine agent starts. If the change I'm proposing is implemented this will no longer happen. Does this seem like a problem to anyone? For instance, do we rely on the upgrade steps for the current version being run after bootstrap? The ticket for this work is at:https://bugs.launchpad.net/bugs/1350111 https://bugs.launchpad.net/bugs/1350111 Cheers, Menno - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT4dTFAAoJENzxV2TbLzHw67QH/i3n2oAsM4f2JZws1HZLQ+GL Q9aqMPdZUPZwbNcHvawgNrB8oWsY5PpaTjjgDSxhuDYZIsGSCzGIU/HSzTDhJPK4 4W/83TEXQQ7DoXVGI5Gbt4YToucunGtnyEB0xvd+sKjuTIq28fBeDqt0js/UNnCs a4A3FPPybvv8F6PjThWPmqTsSeArlJ+Qa8alNjl0oIqCihTf9OH5/0lgJ4M0Gs8d uM3M5UndMSzeoJQ7glBprqWmy1WRICEOEU/F4tuF5HgjPwulJbtItDHfK/Z54YBf W55ElyaOWZMGPIl2DiQru5KBjIgb1S5/YjRyqvyf4yxQseu58Z6fYtkpa6kzXP0= =aL8G -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: log spam related to /etc/network/interfaces
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've filed a bug for it and I'm working to fix it today: https://bugs.launchpad.net/juju-core/+bug/1343219 Thanks for the report! On 17.07.2014 12:46, John Meinel wrote: I think this is related to the recent introduction of the Networker. We need to consider whether we just exit cleanly or wait for the file to exist, or some other answer. Dimiter mentioned that he'll file a bug and start looking into this today. John =:- On Thu, Jul 17, 2014 at 9:16 AM, Menno Smits menno.sm...@canonical.com mailto:menno.sm...@canonical.com wrote: I've just noticed that Juju is currently repeating the following every 3 seconds on my dev machine when using the local provider: machine-0: 2014-07-17 05:12:32 ERROR juju.worker runner.go:218 exited networker: open /etc/network/interfaces: no such file or directory /etc/network/interfaces does indeed not exist on my laptop (NetworkManager takes care of networking). Seems like something needs to be changed to account for this case. Any ideas? - Menno -- Juju-dev mailing list Juju-dev@lists.ubuntu.com mailto:Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTx678AAoJENzxV2TbLzHwUsIH/3lZnEuYZHversCML5Rdpy8m LKea+tL5dadUcuQhL6DwcU98GeVWtVo6Ew8gFmc+7LyN3hQ0oXcYGUYcHey6VYYB PKpFeXagmihb4mms/6qZw6vknX3wva2nQOmjEA98hqdDY9CvqzWafWl+NMjDBSB6 zKPCbZsxz1BT4RfOZoLRtgMdiwHOCwITVpEA/Juu5RYcXPTxjNToVsUjJwMaKJrw uZ+HkHuV8rA+YoZLtux4SXKdSbvfP/f0iyLM0NUPfQtLOJgnLtk3nW9ktCXBZjac 9k4AvPJhjJNPkvN+d9ST1aNteTBH+VoIBi2WkJXVAxHbR/Jj3qPUAvTfPcnbRMs= =PMBw -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: New flakey juju tests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks Martin,
I'll take a look at both of these, since I approved the first and
landed the second. Sorry about the flakiness :/
On 10.07.2014 00:26, Martin Packman wrote:
We've done a lot of work recently improving the reliability of our
test suite. Unfortunately, feature work has been introducing new
tests that are intermittently failing.
http://juju-ci.vapour.ws:8080/job/github-merge-juju/1/console
FAIL: machine_test.go:1750: MachineSuite.TestWatchInterfaces ...
machine_test.go:1808: wc.AssertOneChange() testing/watcher.go:76:
c.Fatalf(watcher sent unexpected change: (_, %v), ok) ... Error:
watcher sent unexpected change: (_, true)
... FAIL github.com/juju/juju/state 123.265s
This test was added in pr 207.
https://github.com/juju/juju/pull/207
http://juju-ci.vapour.ws:8080/job/github-merge-juju/3/console
FAIL: server_test.go:96:
serverSuite.TestAPIServerCanListenOnBothIPv4AndIPv6 ...
server_test.go:104: c.Assert(err, gc.IsNil) ... value *net.OpError
= net.OpError{Op:listen, Net:tcp,
Addr:(*net.TCPAddr)(0xc2107e9f00),
Err:(*os.SyscallError)(0xc21027f560)} (listen tcp :54321: bind:
address already in use)
... FAIL github.com/juju/juju/state/apiserver30.369s
This test was added in pr 224.
https://github.com/juju/juju/pull/224
Can we have another look at these tests and fix them up to be
properly robust? I don't want to back out changes that have been in
trunk for a while, but we can't leave unreliable tests on trunk.
Thanks,
Martin
- --
Dimiter Naydenov dimiter.nayde...@canonical.com
juju-core team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTvjHsAAoJENzxV2TbLzHwXYoIALuFI2e0fKIkFwHTkhNeJjir
/9/v3GRqx8VyILUWvVKlzv3MuBvOPHJo9hfcE1h0n/LnIrZkwd/UmNqrScLJYbPn
sIRPlyrPiwrUb1d8AF+6KKghaAYGrV+HKNkvmra9z2aX+lsJ5RWBag2m7n3Qo62U
t+mnN90IE1c5GHCNdeN6VUwQ/Z9QFOOT/fJo6BwaXERQ9qortltpFzqt1sVLGBBJ
KXQtWhtPouu0q9mNOMq4gJUS4qMf4etM/jn+uLujLZ5Tq/qtcatyPGyxL3NuL/NM
XAbop0XlrtZNQ23ixosvB7R5uPp0HJ8scUGfkhFWSQ7rPEwSIzxuj7t1Nk7NZQM=
=hD+c
-END PGP SIGNATURE-
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: End Of Review marker
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit is just like Rietveld and supports github IIRC. http://gerrithub.io/ On 12.06.2014 13:48, David Cheney wrote: Rietveld also supports git On Thu, Jun 12, 2014 at 8:46 PM, Ian Booth ian.bo...@canonical.com 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 - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTmYbCAAoJENzxV2TbLzHwUeQH+wZ+TYSwpKf/K4wqijHm3s9q anmMdfZk8GM25h2S4lMQhlKk8tgjsRuLfySpERrcltxfB6QEqQbP7MCsbcVhrkdh TAcWKT1+Bh7bqSizkD4SFoTveixz+gWxslWkEaMsN77R9e2NIDbKtcKjPk5RYYka ULAwnoolTsliFNj280T4GViKbz2YBpJvKyy9re6aUYFkLNJ3BLktzHuld/mziEiQ DjUHOccMHNPJfYXOfWPZI0msI2AJ/jyikSMjE82/LJuwLwcB4e7cr9UDfFXIGn1g afepN/zxl5iYd4cLvle4H9LgN+bFy0PWiDzJ/Yzh6nxE7IVhaN1n/dbe1uD6ixU= =szp5 -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Reviewing in progress work on Github
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I spent some time yesterday researching various ways to be productive with git and GitHub. What you're talking about reminded me of this: https://github.com/github/hub It's a CLI for git that allows you to create pull requests on GitHub and lots more. In addition, you can do a feature branch and then run $ git compare master..feature This will bring up a browser with a permalink to a GitHub compare page, where you can solicit comments about a work in progress, and later convert it to a pull request. Check it out, might be just what we need. On 5.06.2014 06:25, Ian Booth 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? - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTkC2hAAoJENzxV2TbLzHwfM8IAKgzgNA8JcMNOZE4MzEe+4d9 k49ubzUL1GvAQ7iKS1svchWfGcbM6jCmxxHtTFEmoSj5mFSGQx05fDtbg5wSTc9d +8A8YqpLQXrxOQJHqwgMWTzB/XGt0E4GJI+YtKhM5MJukwgQ38ul/UDLs4UGs7AR htAeRqHFAx1EkdxKgTa+HM6/cn5rAcdRtc4rHUG1iqzsaAlm7/RLnWOJOk7EDKc/ 8cJgc7vQ97P20vvZAjYaMxEBPQDCYDiMDnhXQnpPmFS9rQdSoggW67nuUf9UfO/w yfckST0cPpzPfOdzOQtK7pF04kwRHISEVleQxZV7PffDU2Rpm6AFH0gExWpEa7Q= =GKGz -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Reviewing in progress work on Github
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Right, my bad - so it's just a diff of the branch changes, and it can be converted to a PR using the green button at the top, so you can add comments. I guess for such cases we can use it and tag the PR as WIP somehow (i.e. in the title or description). Once it's good to land, edit that tag out and proceed, or if it's rejected, just delete the PR. On 5.06.2014 12:03, Andrew Wilkins wrote: On Thu, Jun 5, 2014 at 4:43 PM, Dimiter Naydenov dimiter.nayde...@canonical.com mailto:dimiter.nayde...@canonical.com wrote: I spent some time yesterday researching various ways to be productive with git and GitHub. What you're talking about reminded me of this: https://github.com/github/hub It's a CLI for git that allows you to create pull requests on GitHub and lots more. In addition, you can do a feature branch and then run $ git compare master..feature This will bring up a browser with a permalink to a GitHub compare page, where you can solicit comments about a work in progress, and later convert it to a pull request. Check it out, might be just what we need. This tool looks very useful, thanks Dimiter. I don't see a way to create comments on a comparison page, though. Am I missing something? On 5.06.2014 06:25, Ian Booth 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 mailto:Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTkDdXAAoJENzxV2TbLzHwouIH/1qbXeicfJxx8UUZp2rrWxOA I9jUbOMufoCJtY3O9FvLhGRVfqko1IRaMvmGLqI3MaCFDi/Lspdytdpq9GQ9Qiu9 aHjr0r3jlnHNNPmuYJSnx7vl7i8YM6LD/vcY9ubauGAYEczrCiV7axl67oUHB2CO IrHSn51Prz90XpRaOcOL8+CQd+wg1Suqd1JFuXcys5WPv49WH+DVv//X9RZnl7Kc mqA17E+uxIGz6aG+8NRP9GOBi/CJCsh6kCquh9MmI22teH+EZB3kZ1MMbI8hTpdm klD7WrMpNb3PjHGBwIEJDLE1oamD5oE1k8ETjwutr/PxWAATc6vsQktB5AZeC5M= =+oAW -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Juju on Reddit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Matty, I'm dimitern on reddit, and I'll be glad to help with moderation or questions, etc., as I regularly visit AskUbuntu as well. Cheers, Dimiter On 20.05.2014 18:25, Matthew Williams wrote: - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTfFp2AAoJENzxV2TbLzHwRNwH/A2+I7vkI51AqEaYcExvwkLH CkD9oxiCnND0yNdKzaqn6uihsyU/WPcorvRP3DJKHIzRyP+10NIcooSjTboD9LrZ jshKIulT7gnysExzkn1BJxsNer12hqd9CEiillZeiwOtuFnuJvfvvEwXi1+TW5PQ lkmQNkrJh9y3ZWEAmXVEHXIDr808Hrsj9qsBqgkIDkuenwFB6mtf+ZecKTTjlNaP ZPRfA9SPkDN5TN7QNpEo2pooZxE3agxxPDy2xvRM0Uc2WdMW+7i1sju46XTonpjE OqscRwrpXqWyd/Y57TO8r2ugJ0pVIBjoY1S/9qr+aB+qqlbUwaNjWENCLv4flvc= =riTD -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Landing bot alive again
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This morning I found out the bot is stuck again (my MP approved yesterday didn't land for more than 6h). So I logged in and did the usual to clean things up: $ ps xa | grep mongodb (found out a mongod is stuck, so:) $ kill -9 mongod-pid $ sudo rm -fr /tmp/test-mgo* /tmp/gocheck-* /tmp/mongodb-*.sock (just in case it runs out of /tmp space again) Now it seems working again. On 7.03.2014 10:03, John Meinel wrote: Ian brought up the bot wasn't pushing back to launchpad. The issue is that we were using go get to grab the branches, but that gives a plain branch. And tarmac expects them to be checkouts (so that 'commit' pushes them back to LP, it doesn't do a separate push step). We've updated the charm config so that it properly binds the various branches, so that should be fixed. We also saw that a failed test left mongo running again (about 6 hours ago), so we killed that and the bot is landing stuff again (currently we have a queue of about 8). John =:- On Fri, Mar 7, 2014 at 12:34 AM, Ian Booth ian.bo...@canonical.com wrote: They were emailed out by John a while back. Everyone should have them :-) On 07/03/14 10:32, Tim Penhey wrote: On 07/03/14 07:59, Martin Packman wrote: At second attempt, the landing bot is now running again, moved over to lcy01. Feel free to mark any branches 'Approved' to land them. As part of the setup, several people's keys were added to the tarmac machine, but most management should be possible remotely by setting juju service config now. First source the credentials of the juju-tools-project user: $ source .gobotcreds You seem to have missed a key information step here. Where do you get the .gobotcreds? Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTG1CVAAoJENzxV2TbLzHweF0H/A5hp4JxuWXScPMKkVfs0sCZ scB2IgGyKXYX9cAz+PyrDzN3UqPtm0CMaDbs39tTtcSn9JCYTcYAbEzjgJAv9R1W EULaykMWf3qyxx6PHP3iSTPUpddZqrsqfg2qZIJRR7qkIh+rZHY7i6pJiYohegEL yMcgUM1E0TfHA44R/2jCjrNJDOekvmeqJKz0+365jfRMBLkBC09sI9lohOst4taa jRmpk7P+gXeQX3OvgW2MMWrIV/bQJiqDyOZvNud++1hJ0MupWt01AgV3t98giH21 5n9YZlSbkUxg1paIooJ9PxoxKmZ9rlVYG6W8zAWSiOoV1XIbRmc/Sesb8UTRKkw= =VRW3 -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Fwd: Re: Debug-Log CLI / API Changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fwd to juju-dev. Having --level is a good suggestion, I like it. - Original Message Subject: Re: Debug-Log CLI / API Changes Date: Wed, 19 Feb 2014 15:41:42 +0700 From: Stuart Bishop stuart.bis...@canonical.com To: Dimiter Naydenov dimiter.nayde...@canonical.com On 18 February 2014 23:01, Dimiter Naydenov dimiter.nayde...@canonical.com wrote: The API for debug-log will support internally a list of pairs name-regexp and an exclude flag. Only the name part is required. In CLI terms, we're proposing to express this as: juju debug-log name1[=regexp1] name2[=regexp2] ... --exclude name3[=regexp3] --exclude name4[=regexp4] ... Which is equivalent to the more explicit: juju debug-log --include name1[=regexp1] --include name2[=regexp2] ... - --exclude name3[=regexp3] --exclude name4[=regexp4] ... The full syntax for --include and --exclude is --include=name=regexp, where both the first = and the =regexp parts are optional. If no - --include arguments are specified, they are assumed. Examples: juju debug-log --include wordpress/0='.*config-changed.*' Filtering by regexp can be done easily enough with grep. I'm more interested it the juju debug-log filters being able to decode the stream and separate out messages from services, units, hooks, juju internals from the firehose. So 'juju debug-log --include foo/0' would reliably spit out the messages from foo/0. The scope would be unit, service or whole-environment. If I want to filter this, I'd be wanting to separate out: - All hook output (juju-log'd stdout/stderr). - Hook output and LOGLEVEL or above (hook output without a log level would be equivalent to DEBUG, or something like that). - Hooks fired, Hooks queued to run, Hook result (I'd have all of these or none of these, rather than 3 separate toggles) - relation-set details juju debug-log --exclude 0=started (show all except any lines from machine 0 containing started) juju debug-log environment=hook --exclude environment='.*committed.*hook' (show all lines containing hook but not .*committed.*hook) Using regexps for filtering ends up with false positives and negatives, as well as not being user friendly. Umm... maybe something like the following bikeshed: juju debug-log --level=ERROR # Everything ERROR and above in the whole environment juju debug-log --level=DEBUG --unit=foo/0 # Everything DEBUG and above on the foo/0 unit juju debug-log --service=foo --messages=hooks,output # Hook lifecycle and hook output, all units in the foo service. juju debug-log --unit=foo/0 --messages=hooks,relation-set # Hook lifecycle and relation-sets issued, foo/0 unit - -- Stuart Bishop stuart.bis...@canonical.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTBHA/AAoJENzxV2TbLzHwmDkIAMliumhLr+2utx6IBs9mKvKa qrFE0RqNm74sOP6tCqp/OARoFZTjU1OEXAPbf7tmd9EBsj3LjHtKN9Fb3LEZHKkF 6TtG0JadFUr1V2IiA/nlDgglMRvfqr8xdSb/Y1dhb+n6eiBrdsv+Lm5uyieeXONx 3YE8S+lqrKVHSYzSXFY5HbEsuFSB0qM3CqGWfTsyG3uRVusjUWzLMhx1AXfv2RBj HMXoZusW3om7As3NdaVR/cRuPevAd+iJWs1nIjtM5qytOauin3PKUiDokxFouxdq 7pPWOSiXclQcu2W0sqA8cHp0+of72CHCFsbKEnVamPJ2Hkrpofomu95OO6LNA9g= =MJU/ -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: API Changes to AllWatcher / Environment Tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18.02.2014 17:03, John Meinel wrote: Can we make the API /uuid/api ? That makes them all peer paths. Sure we can, I like that better in fact! Dimiter John =:- On Feb 18, 2014 7:43 PM, Dimiter Naydenov dimiter.nayde...@canonical.com mailto:dimiter.nayde...@canonical.com wrote: Hi all, This is an announcement / request for comments for upcoming juju-core API changes to the way AllWatcher works and also what URIs/paths the API server listens to. Very soon we'll make a few changes to the way AllWatcher work in the API, and also will add a different endpoint for the API server. 1) Annotations changes to the environment entity will no longer be returned with the environment tag as environment-uuid, but instead with just environment. This most likely affects the GUI/Landscape/CLI that use the API. It's a minor change, and it's needed because we are making all API connections specific to a single environment (see the related point 2). The code that depends on having an environment tag with UUID will need to change so that it accepts both environment and environment-uuid as valid. We'll change juju-core to send only UUID-less environment tags most likely before the next release (1.18), but not before juju API clients are notified. 2) Right now the API server's URIs for websocket and HTTPS connections are plain (/ for the API and /charms for HTTPS, soon to have /log for access to the consolidated debug logs). We'll change the API server to start accepting URIs in the form /uuid/ for the websocket API and /uuid/charms for HTTPS respectively. The UUID in the URL must match the environment that the client wants to connect to and will get a 404 if it does not match the one in state. The old URIs will still be usable, but deprecated and about to get removed in a future release (likely before 14.04). Thoughts, comments are welcome! Regards, juju-core team -- Juju-dev mailing list Juju-dev@lists.ubuntu.com mailto:Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTA4Y3AAoJENzxV2TbLzHwvD8IAKH0GLvSmCx6mBxuTuKiLUsK UlDogXv26jXIFm/rcoXVY1gM6hESbZPBkuFv95ruyvDmc8zQc2471zayD7k7ydaY pWam7GImq/X/QEW9gGkPXx+5RqaBIaimuqbyiASj2I8aUArwBANWAGBKVyZEiud0 c1y7XpkwsyOLzgQLY2LNh+OZwvlIgkl2NxWz8ptGipU17vsBYbcPjwbA9JYfHdnl egASETYLzLyQfP6o9gJeyuU4QtikO5l/JanQfogEgoIk5H/Mm4tUek6MZLYFaYOd K5PFm7ph5DjWwbEtadLb1rX45+mA4bD1ouYDTyAcA21p+Hmay8J+Z7D8je1G8yA= =Gq1Q -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
