Re: Call for help for a juju plugin
On Wed, Mar 4, 2015 at 10:12 AM, Adam Collard adam.coll...@canonical.com wrote: Why not stick to the UNIX principle and compose a pipeline? That would also do the trick, as long as it's something that can capture what's going on in one snippet. -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com/ - Automate your Cloud Infrastructure -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Trivial bugs hurting progress
On Wed, Mar 4, 2015 at 8:44 AM, Martin Packman martin.pack...@canonical.com wrote: On 04/03/2015, Andrew Wilkins andrew.wilk...@canonical.com wrote: 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. I assume Core developers are like myself. I have run the test suite just like the lander. I know a failure to merge is probably a bad test. As CI is running more compilers, series, and archs, We could prevent regressions in master by using lesser combination that must pass. We could: - catch and fix map order bugs - skip tests that wont pass on an arch/compiler combinations - discover and fix real arch and series issues without ever breaking the build, never blocking other engineers from merging. We cannot achieve my ideal combination of precise, gcc-4.9+patches, and ppc64el or i386. Precise doesn't work with ppc64el, and it is hard to get a run 386 test quickly. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- 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 the Best Practices Guide
Hi, May I add two tips that can help 1. When you use the python template, the charmhelpers package download and use is done for you, but it then prevents your script to be run with as a simple python script since usually /usr/local/lib/python2.7/dist-packages is not a default. * Default path under juju is: sys.path= ['/var/lib/juju/agents/unit-kimchi-0/charm/hooks', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-powerpc64le-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PILcompat'] * log() functions found in hookenv.py is not available and will raise an error. 1. if you run under local environment and your LXC machine get unexpected network errors try to disable IPv6 on main host. That's all for now Thierry On 03/02/2015 06:18 PM, Charles Butler wrote: juju upgrade-charm --force, get that iterative action without a teardown/redeploy in an error state On Mon, Mar 2, 2015 at 11:51 AM, Nick Veitch nick.vei...@canonical.com mailto:nick.vei...@canonical.com wrote: Hi, I should clarify that the tips on this page are for charm authors - i.e. writing charms. If you have any tips for using Juju, we'd be happy to hear those too though! On 2 March 2015 at 16:30, Jorge O. Castro jo...@ubuntu.com mailto:jo...@ubuntu.com wrote: Hi everyone, We have a best practices guide in the docs, initially it was a brain dump of what Canonical IS was doing with Juju: https://jujucharms.com/docs/authors-charm-best-practice However if you look at the history of the page it hasn't been touched in a long time, and there are tons of new tips and tricks that we have neglected to put on this page. In many cases we've just added the tip to the corresponding page in the docs, so the question becomes, do any of you have any tips/tricks that can help this page be more useful to users? -- Juju mailing list Juju@lists.ubuntu.com mailto:Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Nick Veitch nick.vei...@canonical.com mailto:nick.vei...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com mailto:Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- 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 -- Thierry Fauck @ linux.vnet.ibm -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
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: Call for help for a juju plugin
On 4 March 2015 at 13:45, Jorge O. Castro jo...@ubuntu.com wrote: Hi everyone, Sometimes people deploy things like a complex bundle on a cloud and it doesn't work. Having to wrangle the person to find out which units broke, juju sshing in and manually digging around logs and refiring off hooks, etc. is time consuming. This is a great idea, and should be doable for shipping just juju logs/config, and possibly relation data. But if you'd want to include logs/config for the service, I think you'd need a way for charms to expose there logs (path[1], type) and configs somehow. This could maybe be part of the charm metadata, but paths are not necessarily fixed locations, as config can affect them[1]. So maybe a charm could publish this information in the juju status output, as part of service metadata? I think there was some discussion of custom status output at some point. This would be useful for the above scenario[2], but also in development of full stacks, and debugging in production. Some useful tools/plugins that this would enable: juju-tail-logs unit could use multitail to tail all logs on that unit simultaneously, as I send a test request to the unit and watch what happens. Bonus for a --filter regex argument :) juju-log-trace access|error could multitail all access|error on all units that publish them, so I can trace http requests coming though mutliple units of apache-haproxy-squid-haproxy-app servers (I do this manually sometimes now, but it's a pain, and I must know the location of every log file for each unit). Ditto for the --filter argument. juju-view-configs could open all the config files in a stack for viewing in $EDITOR, vastly simplify checking if the desired relations/config have produced the correct result you were looking for. I regularly do this manually, one by one, with stuff like juju ssh unit 'cat /etc/haproxy/haproxy.cfg', for example. Another use case would be to surface the logs and config in the GUI, which IMO would be a killer feature for GUI adoption in production environments. In fact, this simple change could expose a whole raft of system diagnosis tooling that would be real value-add to the base juju proposition, IMO. HTH [1] As recommended in our current best practice docs: https://jujucharms.com/docs/authors-charm-best-practice (Disclaimer: I am not convinced by all of those guidelines) [2] There's an issue here with sensitive information, like PID and secrets. I think the pastebinit plugin would need to be able to dump locally, to allow redaction prior to submitting, if it was every going to be able to be used in production systems. Some data (IPs, emails, etc) could be auto-redacted in the tool, perhaps. -- Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Joyent SSH key
There is a bug about us defaulting to uploading the user's private id_rsa ssh key to joyent as a part of bootstrapping a new server. This is obviously a bad thing. bug: https://bugs.launchpad.net/juju-core/+bug/1415671 However, the proposed solution (generate our own key and use that) doesn't work in practice, because we still need to authenticate with joyent to upload the key, which means hoping the user's default ssh key works (and assuming it's ok for us to just try it). My suggested solution is that we do what we do for all the rest of the providers, which is to make the user give us authentication credentials in the environments.yaml file, and we just use that, and not create anything ourselves. Thoughts welcome. -Nate -- 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 the Best Practices Guide
Developers using Windows can't download and hack on charms. There's really not need to create symlinks in hooks directories, you can achieve the same affect by stubbing hooks which import your hooks.py file and invoke the methods that are wrapped with the Hook decorator. Again, best practice, not policy. On Wed, Mar 4, 2015 at 11:44 AM Simon Davy bloodearn...@gmail.com wrote: On 2 March 2015 at 17:46, Marco Ceppi ma...@ondina.co wrote: # Charm Authors - Avoid symlinks in charm /me blinks I assume you don't mean symlinks in hooks/ dir? Anything documenting why this is a bad idea? -- Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
MAAS deploy failing
Since I haven't been able to find a listserv specifically for MAAS and this listserv is close to the subject and seems to provide good answers... I have a MAAS server that was last installed December 18, 2014 to test building an OpenStack cloud. When I first built it, it would discover, commission, and deploy physical machines just fine. Over time it starts loosing the ability to deploy machines. It will reboot them and pxe boot them with the installer, but something fails in the installer process and they end up in one of 2 states. 1. claim to be deployed, but the machine ends up powered down. The last node event is something like: Failed to query node's BMC — Node could not be queried node-27aac898-bec8-11e4-bb0d-180373b04ac9 (esxi06.maas) connection timeout or 2. fails the deploy, but finishes the install, but never configures the network interfaces and will not talk to the world (thus the failed deploy). The last node event for this one also looks like: Failed to query node's BMC — Node could not be queried node-4881df02-bec8-11e4-bcd7-180373b04ac9 (esxi05.maas) connection timeout I have restarted bind9 (fixed an earlier dns forwarder problem that caused juju to fail in deployments) and maas-dhcp. The machines seem to be getting a correct IP address when booting up, they just don't keep it to the end of their configuration process. I suspect that both problems are related but am not sure where to look to find the debug information on it. Any ideas or suggestions for a better place to ask? I have been having problem with MAAS and juju not being very reliable or stable in repeating operations. Any help is greatly appreciated. -- Daniel Bidwell drbidw...@gmail.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Making juju visible on your lan
Greetings Halimaton, I see you ran across my tutorial on exposing LXC containers on your network. There are a few things here that can cause the problem you are seeing about Containers failing to start. The networking on the local provider if faux DHCP, and doesn't seem to check for collisions, which is the usual culprit for this error. Without seeing your juju logs its difficult to diagnose. I know you hang in irc as halcyon, and I'll stick around this evening to try and help you debug this setup. Find me in #juju on irc.freenode.net as lazypower All the best, Charles On Wed, Mar 4, 2015 at 1:47 AM, Halimaton Saadiah halimatonsaadiah16...@gmail.com wrote: Hye everyone! I am doing installation regarding juju on local provider environment, yes I am able to expose the service deploy on my local machine. However, I am now destroy back the environment as I am following this tutorial http://blog.dasroot.net/making-juju-visible-on-your-lan.html to be able to make juju visible on my lan connection, but when I did this I cannot be able to start up the service as it mentioned that container failed to start when I run juju status. I am confident that this tutorial able to solve my problem for me to make juju-gui and other service to be able to view trough other desktop in my network. Would anybody suggest me other way or how should I move from here? I am currently stuck and appreciate your help. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- All the best, Charles Butler charles.but...@canonical.com - Juju Charmer Come see the future of datacenter orchestration: http://jujucharms.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Joyent SSH key
On 4 March 2015 at 17:23, Eric Snow eric.s...@canonical.com wrote: On Wed, Mar 4, 2015 at 10:04 AM, Nate Finch nate.fi...@canonical.com wrote: My suggested solution is that we do what we do for all the rest of the providers, which is to make the user give us authentication credentials in the environments.yaml file, and we just use that, and not create anything ourselves. That is currently the advice in the documentation - to generate a new key and explicitly provide it in the environments.yaml. I think if we removed the default action (using the default ssh key) that would be fine, as long as there was a suitable error message. It isn't as though users will have to configure it every day, it's a one-time inconvenience, but one that doesn't make any unnecessary assumptions. -- 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
Thanks again, opened following bug: https://bugs.launchpad.net/juju-core/+bug/1428345 Jake From: Dimiter Naydenov dimiter.nayde...@canonical.com To: juju@lists.ubuntu.com Date: 03/04/2015 10:39 AM Subject:Re: unit-get and ipv6 addresses Sent by:juju-boun...@lists.ubuntu.com -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
[Review Queue] mumble-server, python-moinmoin
mumble-server: Mostly cosmetic changes. +1 https://code.launchpad.net/~lazypower/charms/precise/mumble-server/metadata_cleanup/+merge/246058 python-moinmoin: These merge proposals fix issues in both the precise and trusty version of this charm, including refactored tests. +1 https://code.launchpad.net/~jose/charms/precise/python-moinmoin/refactor-tests/+merge/248330 https://code.launchpad.net/~jose/charms/trusty/python-moinmoin/refactor-tests/+merge/248331 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: [Review Queue] mumble-server, python-moinmoin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for the +1's Adam. I've taken action on the listed MP's based on your review and pushed them upstream. All the best On 03/04/2015 05:07 PM, Adam Israel wrote: mumble-server: Mostly cosmetic changes. +1 https://code.launchpad.net/~lazypower/charms/precise/mumble-server/metadata_cleanup/+merge/246058 python-moinmoin: These merge proposals fix issues in both the precise and trusty version of this charm, including refactored tests. +1 https://code.launchpad.net/~jose/charms/precise/python-moinmoin/refactor-tests/+merge/248330 https://code.launchpad.net/~jose/charms/trusty/python-moinmoin/refactor-tests/+merge/248331 - -- Charles Butler charles.but...@ubuntu.com Juju Charmer - http://jujucharms.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU94SkAAoJENooWinqgzR63ikIAI4wjJ/Cn6O+w7YvdUHs33sj TQ46H4GtRfxRxQHF2cCbJjuYg78ijAod21mui/+h2s5xjEyjrDdOdN6CRusCptyQ fbAlgYgcypeb0ziu/tfoQnn5sloqT5crhjwx3RdVsDS3uzygYSxRoHCBqIuDTYby rdUTM6s+YB3z3HV5s3E0VKZ7LumtR7QginHVQp5iOsJ+ozO1XSkNKhhAzn4ljsrT WDJ66RXSaGOtrz4sv4SbYnljFl/dZ2rwL4HmAX43eSW6E3Ror7wSLEY74e/8ZEXF ZLZ+T/DPgQ2+ejutuVCnNZfgTx2eZYdSxQCeg2Y1UuWg3aZz/ReWkxhbGEK6SGk= =/1lH -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
On 04/03/15 19:05, Andrew Wilkins wrote: The bugs were fixed in this branch: https://github.com/juju/juju/pull/1738 - invalid printf-style formatting will cause go vet to fail My bad. I had deleted the pre-push hook script some time ago when go vet failed continuously, and I hadn't reinstated it. I have done so now. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Joyent SSH key
On Thu, Mar 5, 2015 at 1:04 AM, Nate Finch nate.fi...@canonical.com wrote: There is a bug about us defaulting to uploading the user's private id_rsa ssh key to joyent as a part of bootstrapping a new server. This is obviously a bad thing. bug: https://bugs.launchpad.net/juju-core/+bug/1415671 However, the proposed solution (generate our own key and use that) doesn't work in practice, because we still need to authenticate with joyent to upload the key, which means hoping the user's default ssh key works (and assuming it's ok for us to just try it). My suggested solution is that we do what we do for all the rest of the providers, which is to make the user give us authentication credentials in the environments.yaml file, and we just use that, and not create anything ourselves. Thoughts welcome. SGTM There's code (verifyCredentials) in the joyent provider already that tells the user what to do if the SSH key or Manta username are invalid. It'd be ideal if that error message were output whether or not the key is supplied. -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Trivial bugs hurting progress
On Thu, Mar 5, 2015 at 10:24 AM, Tim Penhey tim.pen...@canonical.com wrote: On 04/03/15 19:05, Andrew Wilkins wrote: The bugs were fixed in this branch: https://github.com/juju/juju/pull/1738 - invalid printf-style formatting will cause go vet to fail My bad. I had deleted the pre-push hook script some time ago when go vet failed continuously, and I hadn't reinstated it. I have done so now. Thanks. FYI (and others' I), there's a couple of ways to temporarily disable hooks or just vet: git push --no-verify or IGNORE_VET_WARNINGS=1 git push (obviously to be used judiciously) -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Trivial bugs hurting progress
One option is to run the test suite with go 1.3 and just make sure that juju compiles with all the other compilers (1.2, gccgo, etc). That gives us a fast precommit check, which won't catch everything, but should catch most 1.2 compat bugs. And leave the full test suite runs as CI tests. John =:- On Thu, Mar 5, 2015 at 6:28 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Thu, Mar 5, 2015 at 10:24 AM, Tim Penhey tim.pen...@canonical.com wrote: On 04/03/15 19:05, Andrew Wilkins wrote: The bugs were fixed in this branch: https://github.com/juju/juju/pull/1738 - invalid printf-style formatting will cause go vet to fail My bad. I had deleted the pre-push hook script some time ago when go vet failed continuously, and I hadn't reinstated it. I have done so now. Thanks. FYI (and others' I), there's a couple of ways to temporarily disable hooks or just vet: git push --no-verify or IGNORE_VET_WARNINGS=1 git push (obviously to be used judiciously) -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: unit-get and ipv6 addresses
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: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 - -- Dimiter Naydenov dimiter.nayde...@canonical.com Juju Core Sapphire team http://juju.ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU9Hu9AAoJENzxV2TbLzHwha4H/0s+UUZr5Z2ov4TcjAIT93cb I/JqHcpo1ynvOyGCv5/VD801RHnwDi+tWpoKJtUmgQ6PTV8iW78U7C55MgcXsTmz PKh3Bl5O8IN2oVF3SbVD7jc8P70wtbucIVsml1lsb34TCgJFSA1rJ2R7SrnUMtiE EXNg455jS84aDiJW+Lw8glXHB1X3f+Kv7jnKN2Bksza+z4T8+hxa7HLc8qCdozD7 MoEVLoJO/75LYVjYCMhqZhkqCUb5T8gvdVcb2zdIOnhk63A+G0FQSPUrvTps3cfv iCmD1nXUyufFV5FB3ks9nwtlrGjpsAcbJJu0NCwJ9VCOQjxvGXjTYksJNUi8VbU= =lBiY -END PGP SIGNATURE- -- Thierry Fauck @ linux.vnet.ibm -- 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 2015-03-04 08:53 AM, Dimiter Naydenov wrote: 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. It's not just about map ordering issues. It's about complete compatibility with GCC Go. For example, there are issues with test doubles that have had to be worked around in the past. When a GCC Go incompatibility is landed, we sometimes spend days with an unreleasable Juju before it gets fixed. It has been 3 days since master was releasable. Even though GCC Go is slow, it's worth it to avoid three days of being unreleasable. My 2¢. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU9xieAAoJEK84cMOcf+9hDg0H/j6TYPNbI92arsWimT21bxve 1TOBvXtlGJCAwsiZOU//mEKwHXmChrm/a8F2YeWlMDAvk4+Uw4Wid5EViucZiNK9 +IhrpCqG835PMhyxVRbOVzSYoxsjrn1E1Kb5Q+tcOWqrjntoj4JrFMKeCIuANTVj yi56sl1jNNtOKV0SpmGnILuNNrFVXpy0i4P0Iz462V5sbQ5VtSXwtRc1rtK5OJA6 b47cv346z+DqPJahWNknG+yt2RaGQWzOfTST46B3kiU9CEKsH/U4P3nY9Ixx6hBz uH8FHpQpfHByK2FPTs9+thnViD30YUaPdFNUnT8FfRnEaNjpqaDEs4jgOafI8LE= =4tUi -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: Trivial bugs hurting progress
On Wed, Mar 4, 2015 at 1:05 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: 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). While we add our golang archive to all the slaves to ensure golang 1.2.1 is available, apt prefers to use the latest version. On Vivid, that is golang 1.3, and it very erratic success rate is probably because of tests aren't ready for a newish golang. Fixing the test suite will give allow us to make the vivid unit tests voting. Our test runner script accepts a PPA option. We have added newer golang and mongos to our experimental PPA, then setup a test to run with it to prove the Juju was ready for the newer versions. We can do this again. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Trivial bugs hurting progress
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. Martin -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Call for help for a juju plugin
Hi everyone, Sometimes people deploy things like a complex bundle on a cloud and it doesn't work. Having to wrangle the person to find out which units broke, juju sshing in and manually digging around logs and refiring off hooks, etc. is time consuming. Marco and I thought something like `juju pastebinit` would be a good idea. Just give me a dump of all the logs on the units so I can send that to the bundle/charm author. https://github.com/juju/plugins/issues/52 The eco team is gearing up for a sprint so our pattern is kind of full, so I'd thought I'd send this out to the list to see if anyone is looking for a quick plugin to bust out that would help people out in the field debug their problems faster. -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com/ - Automate your Cloud Infrastructure -- 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: Call for help for a juju plugin
Why not stick to the UNIX principle and compose a pipeline? With https://bugs.launchpad.net/juju-core/+bug/1390585 fixed it could be as simple as juju debug-log --no-stream --replay | pastebinit On 4 March 2015 at 13:45, Jorge O. Castro jo...@ubuntu.com wrote: Hi everyone, Sometimes people deploy things like a complex bundle on a cloud and it doesn't work. Having to wrangle the person to find out which units broke, juju sshing in and manually digging around logs and refiring off hooks, etc. is time consuming. Marco and I thought something like `juju pastebinit` would be a good idea. Just give me a dump of all the logs on the units so I can send that to the bundle/charm author. https://github.com/juju/plugins/issues/52 The eco team is gearing up for a sprint so our pattern is kind of full, so I'd thought I'd send this out to the list to see if anyone is looking for a quick plugin to bust out that would help people out in the field debug their problems faster. -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com/ - Automate your Cloud Infrastructure -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
