Re: Critical regression on vsphere due to cloud-init
Hi Merlijn -- We are working on that bug actively. At its core, this is a mismatch between how a cloud functions (dhcp/dns is set up in advance and not mutable by the instance), and how vsphere operates. If you could put into the bug the reproduction steps you have taken, that would be very much appreciated. Especially needed are: 1) vsphere version 2) What dhcp server are you running and how is it configured? 3) How do you deploy CDK and where does the problem trigger? On Tue, Feb 20, 2018 at 2:53 AM, Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Hi all > > > I want to bring a critical regression on vsphere to your attention. DNS on > vsphere recently got broken, probably due to a regression in cloud-init. > Link to the bug report below. Because of this, we're unable to deploy many > bundles such as the big data bundles and the Kubernetes bundles. > > Is somebody working on a fix? The CDK issue mentions a workaround; does > anybode know what that workaround is? > > - Bug in cloud-init: https://bugs.launchpad.net/cloud-init/+bug/1746455 > - Bug in CDK: https://github.com/juju-solutions/bundle-canonical- > kubernetes/issues/480 > - Someone on askubuntu having the same issue: https://askubuntu.com/ > questions/994629/dhcp-lease-always-registered-with- > default-ubuntu-instead-of-actual-hostname-at > > > > Regards > Merlijn > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju-dev > > -- David Britton <david.brit...@canonical.com> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: PROPOSAL: stop recording 'executing update-status hook'
+1 from me: https://bugs.launchpad.net/juju/+bug/1530840 :) On Thu, May 18, 2017 at 8:13 PM, Tim Penhey <tim.pen...@canonical.com> wrote: > Hi folks, > > Currently juju will update the status of any hook execution for any unit > to show that it is busy doing things. This was all well and good until we > do things based on time. > > Every five minutes (or so) each unit will have the update-status hook > executed to allow the unit to set or update the workload status based on > what is currently going on with that unit. > > Since all hook executions are stored, this means that the show-status-log > will show the unit jumping from executing update-status to ready and back > every five minutes. > > The proposal is to special case the update-status hook and show in status > (or the status-log) that the hook is being executed. debug-log will > continue to show the hook executing if you are looking. > > This will reduce noise in the status-log, simplify some of our code around > dealing with status-log, and reduce load on controllers looking after > hundreds or thousands of units. > > Is anyone opposed to this change? > > Tim > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/juju-dev > -- David Britton <david.brit...@canonical.com> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: A (Very) Minimal Charm
On Fri, Dec 16, 2016 at 09:33:18AM -0600, Katherine Cox-Buday wrote: > Tim Penhey <tim.pen...@canonical.com> writes: > > > Make sure you also run on LXD with a decent delay to the APT > > archive. > > Open question: is there any reason we shouldn't expect charm authors > to take a hard-right towards charms with snaps embedded as resources? > I know one of our long-standing conceptual problems is consistency > across units which snaps solves nicely. For new projects we are working this way. We have not used resources yet, but instead are using "fat" charms and sideloading the snap. But, resources are the next logical progression. -- David Britton <david.brit...@canonical.com> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: debug hooks
On Thu, Oct 23, 2014 at 04:09:31PM +0400, Vasiliy Tolstov wrote: Hi =)! I have succeseful deployed wordpress on precreated lxc containers. After deploy to vps i have all services in error state with message about install hook failed. First, look on the unit in /var/log/juju: juju ssh unit ls -l /var/log/juju/unit-* The unit-* logs are the intersting ones if you have gotten as far as running hooks. If that is not revealing, you can step through hook execution, see the following link (thought this is typically not necessary to just see how something failed, it's more if you are developing a charm): https://juju.ubuntu.com/docs/authors-hook-debug.html HTH! -- David Britton david.brit...@canonical.com -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: getting rid of all-machines.log
On Fri, Aug 08, 2014 at 12:03:21PM -0400, Nate Finch wrote: [...] remote syslog and to the local file log, we wouldn't need to worry about log rotation of the local log screwing up what gets sent to the remote Do the standard rsyslog log rotation mechanisms not function well? On Windows, what about the event log (which has remote viewing/aggregation capabilities built in)? -- David Britton david.brit...@canonical.com -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Proposal: making apt-get upgrade optional
On Tue, Jul 1, 2014 at 1:53 PM, Matt Bruzek matthew.bru...@canonical.com wrote: Hello Andrew, I ran into a problem when Juju was no longer calling apt-get update. I filed bug: https://bugs.launchpad.net/juju-core/+bug/1336353 Agreed -- I've fixed this problem multiple times in charms by making the first step apt-get upgrade. Which always seemed a bit wasteful to me. :) It happens more on the local provider since those images are copied from templates which are not rebuilt until you remove them (do lxc-ls --fancy to see them). So, the templates package cache goes out of date, and your cloned machine also goes out of date. -- David Britton david.brit...@canonical.com -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: $ juju switch --format
-name, status, username] - all fields can be shown by using --all 6) juju info --list will output the list of environments in either yaml or json (or smart) Or perhaps just leave that to the juju switch command. cheers, rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- David Britton david.brit...@canonical.com -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: $ juju switch --format
Hi William, On Fri, Jun 06, 2014 at 07:40:47PM +0200, William Reade wrote: To restate your point, I think: you want to be able to keep seeing and reading simple names for the contexts you have available to work in. Yes. Agreed. Do the following use cases express your needs (even if you weren't hitherto aware that you were specifically manipulating environment *connections*)? Ah, ok, things are changing, got it. Making sure patterns like the following are still easily grok-able (even if it's a different command) is nice: juju destroy-environment $(juju env) Juju env used to print a lot of decoration around the environment name, IIRC it was like: $ juju env Current Environment: local (from JUJU_ENV) $ That was a lot to extract the name from. :) As a user, I want to be able to refer to particular environment connections by short simple names As a user, I want to be able to see what environment connections I have available As a user, I want to be able to see what environment connection is currently active I'd slightly modify to: As a user, I want to print without annotation the currently active environment connection If that even makes sense to do in the new world order. I'll leave that for you to judge. As a user, I want to be able to quickly activate a given environment connection As a user, I want to be able to see the details (env uuid, env name, state-servers, etc) of my environment connections Agreed with the rest. Thanks for writing those out. I see that there are changes coming, and I'm looking forward to what you have in store. Thanks to all for taking the time to consider the issues involved. Good to see you are taking seriously existing scripts, the burden of maintaining old ways of doing things going forward, progress, etc. -- David Britton david.brit...@canonical.com -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
