Re: Charmers application
On Thu, Jun 4, 2015 at 3:29 PM, Edward Hope-Morley edward.hope-mor...@canonical.com wrote: Ahoy Charmers! Please consider my application for membership to http://launchpad.net/~charmers I looked again into the charmers team expecting to see your name , and I was surprised for not seeing you there. A solid +1 from my side. -- Jorge Niedbalski R. STS - Engineering Team GPG:0x3DA28544, irc: niedbalski -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Start/Stop machines
Hello, Does anybody is aware of a blueprint or WIP for implementing cross-provider machine start/stop operations ? This would be really useful for suspend/resuming environments. We are currently using this plugin (https://github.com/niedbalski/juju-suspend) but would be nice to have a proper implementation accessible through the API for all the providers. I found this bug ( https://bugs.launchpad.net/juju-core/+bug/1252781 ) associated with this but has been triaged since a while. Any ideas? -- Jorge Niedbalski R. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Feature Request: show running relations in 'juju status'
On Tue, Nov 18, 2014 at 3:19 AM, Kapil Thangavelu kapil.thangav...@canonical.com wrote: status per future impl helps, as does explicitly marking units.. but pending cluster count is a missing and important property to properly establish quorum in a peer rel from one to n that is only resolved by knowing recorded units count for a svc. cheers, Kapil I strongly agree with Kapil on the importance of have a cluster count for determining quorum in peer relations, also for leader election. We have experienced problems determining cluster quorum on different official charms ( i.e. mongodb, openstack charms ). There are a plenty amount of hacks for 'solving this' , getting the first deployed peer unit as the master based on the unit id, choosing a random one, or like the case of 'hacluster' charm ( which is the base for all our HA charms ) by using a prefixed parameter ( cluster_count ). The desired fix would be to have the number of how many peer relations the unit has globally , no matter of the state ( started, stop, building , etc) With that we can solve most of the initial quorum issues. -- Jorge Niedbalski R. Software Sustaining Engineer CTS - Engineering Team gpg:0x3DA28544, irc: niedbalski -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Rsyslog imtcp issue
Hello, On Thu, Sep 25, 2014 at 7:28 AM, Gabriel Samfira gsamf...@cloudbasesolutions.com wrote: FWIW, unit/machine agents no longer need rsyslog to stream logs to the state machine as of this merge: https://github.com/juju/juju/pull/499 Thank you for pointing out this. Removing rsyslog as a dependency should be safe I think... Does anybody else could confirm that removal of rsyslog is OK? On 25.09.2014 12:26, Stuart Bishop wrote: On 24 September 2014 23:25, Jorge Niedbalski jorge.niedbal...@canonical.com wrote: I know is not an option to abandon the usage of gTLS, but ideally, Thanks. -- Jorge Niedbalski R. Software Sustaining Engineer @ Canonical Canonical Technical Services. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Rsyslog imtcp issue
Hello, I am the maintainer of the rsyslog/forwarder charms. While i was working implementing an option to expose the protocol/port used by rsyslogd I noticed that enabling TCP on rsyslogd using imtcp ($InputTCPServerRun 514) was not possible on any machine deployed by Juju. The root cause is that /etc/rsyslog.d/26-juju-unit-primary-0.conf declares a DefaultNetStreamDriver to use gTLS, and apparently both plain tls sockets cannot live together on rsyslogd. After changing the $DefaultNetstreamDriver from gtls to ptcp it worked correctly, for both actions collecting logs via TCP 514 and forwarding logs to 10.0.3.1:6514;LongTagForwardFormat. I know is not an option to abandon the usage of gTLS, but ideally, Juju should have a separated service and configuration path that doesn't interrupts any other rsyslogd process running on the host. I think we can workaround/fix this by running 2 different rsyslogd services with different configurations (maybe a default path different for juju /etc/rsyslog.d/juju/ ?), Please any observation would be appreciated Cheers. -- Jorge Niedbalski R. Software Sustaining Engineer @ Canonical Canonical Technical Services Engineering Team # Email: jorge.niedbal...@canonical.com (GPG:0x3DA28544) -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Reproducing Jenkins
Hello, I am working in to reproduce some of the CI Jenkins jobs on my local Jenkins installation, but sometimes is a bit hard to replicate the exact job configuration. I am wondering if someone else is interested in to create a versionable configuration of the jenkins installation, so we can just replicate the CI Jenkins environments locally pretty easy. I have used the openstack-infra project: http://ci.openstack.org/jenkins-job-builder/ before , which has the benefit to bind all the Jenkins parameters and job-dependencies on a YAML file, so is a matter of POST this file in the new Jenkins installation and the environment gets automatically replicated. If someone wants to give it a try and/or thinks is useful for juju-core, i will be happy to help with this. Regards. -- Jorge Niedbalski R. Software Sustaining Engineer @ Canonical Canonical Technical Services Engineering Team # Email: jorge.niedbal...@canonical.com (GPG:0x3DA28544) # Phone: +56976670504 # Launchpad: ~niedbalski | IRC: niedbalski | gtalk: niedbalski -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Question about unprivileged lxc containers
Hello, While working on a bug assignment related to LXC templates, i noticed that the golxc driver is performing the following subprocess invocation on the Create method: ``` lxc-create -n juju-trusty-template -t ubuntu-cloud -f /var/lib/juju/containers/juju-trusty-template/lxc.conf -- --debug --userdata /var/lib/juju/containers/juju-trusty-template/cloud-init --hostid juju-trusty-template -r trusty ``` The problem with this command is that is forcing the usage of /var/lib/juju/containers/juju-trusty-template/lxc.conf as the default and this file doesn't includes any configuration directive regarding to id_maps , which is a requirement to run unprivileged containers, also using the (-f) flag has preference over my locally defined ~/.config/lxc/default.conf. Do we need to add id_maps options for unprivileged containers to golxc? Any other idea? (More information: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ ) -- Jorge Niedbalski R. Software Sustaining Engineer @ Canonical Canonical Technical Services Engineering Team -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Specific configuration on network-bridge interface
Hello,
I need some pointers regarding to provide a Fix for bug LP:
https://bugs.launchpad.net/juju-core/+bug/1341524 , as you can see a
user is experiencing problems to boot up a new environment cleanly
when some specific network configuration is used, on this case a
bonding setup configured using a preseed file on the same interface
declared for the network-bridge option.
Some clues points to the ('ifdown %s', network-bridge) command
performed on the cloud-init stage. So, i am wondering why this was
introduced in favor of the previous 'service networking restart' as
you can see performing a git diff -r 411dbff4^!
If somebody has a clue, would be very helpful.
--
Jorge Niedbalski R.
Software Sustaining Engineer @ Canonical
Canonical Technical Services Engineering Team
# Email: jorge.niedbal...@canonical.com (GPG:0x3DA28544)
# Phone: +56976670504
# Launchpad: ~niedbalski | IRC: niedbalski | gtalk: niedbalski
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
