Nota: Estou executando isso em 3 VM confiáveis do Ubuntu no meu laptop OS X em vez do VMWare Fusion.
Eu sou um novato juju e tenho alguns problemas com a criação de jenkins-slave. Eu tenho uma máquina de bootstrap e 2 outras máquinas. Jenkins (master) é instalado com sucesso na máquina 1. Quando tento implantar o jenkins-salve, recebo a mensagem de erro:
juju deploy -n 1 jenkins-slave
cannot assign unit "jenkins-slave/0" to new machine: use "juju add-machine ssh:[user@]<host>" to provision machines
Eu também tentei:
juju remove-service jenkins-slave
juju deploy jenkins-slave --to 2
Added charm "cs:precise/jenkins-slave-7" to the environment.
ERROR cannot assign unit "jenkins-slave/0" to machine 2: series does not match
Não faz sentido, pois antes de tentar implantar jenkins, adicionei duas máquinas:
juju add-machine ssh:machine1
juju add-machine ssh:machine2
ambos terminados com sucesso. Aqui está minha saída de status
juju status
environment: manual
machines:
"0":
agent-state: started
agent-version: 1.20.14
dns-name: thebat
instance-id: 'manual:'
series: trusty
hardware: arch=amd64 cpu-cores=1 mem=979M
state-server-member-status: has-vote
"1":
agent-state: started
agent-version: 1.20.14
dns-name: elemental
instance-id: manual:elemental
series: trusty
hardware: arch=amd64 cpu-cores=1 mem=979M
"2":
agent-state: started
agent-version: 1.20.14
dns-name: terrifying
instance-id: manual:terrifying
series: trusty
hardware: arch=amd64 cpu-cores=1 mem=979M
services:
jenkins:
charm: cs:trusty/jenkins-2
exposed: false
units:
jenkins/0:
agent-state: started
agent-version: 1.20.14
machine: "1"
open-ports:
- 8080/tcp
public-address: elemental
jenkins-slave:
charm: cs:precise/jenkins-slave-7
exposed: false
units:
jenkins-slave/0:
agent-state: pending
A resposta é bem simples, mas muito improvável. O charme do jenkins-slave é um charme preciso, o que significa que ele pode ser instalado apenas em um Ubuntu VM preciso.
Embora isso pareça óbvio após um dia inteiro com o juju, acredito que seja um grande problema com essa ferramenta. Chef / Puppet, etc não são dependentes de sabor, então por que é a versão de sabor juju dependente. É uma grande falta de planejamento na minha opinião.
Você está usando o provedor manual, o que significa que precisa gerenciar e combinar manualmente a série de charadas com a série implantada na unidade. Se você usou, por exemplo, o provedor local (a documentação fornece uma imagem Vagrant predefinida que foi testada para trabalhar no OS X), Juju gerenciaria automaticamente a alocação de unidade - incluindo a série - para que você não se deparasse com esse problema.
A série definida para um charme é a versão do Ubuntu em que o charme foi testado e é conhecido por trabalhar com ele. É perfeitamente possível que o encanto funcione com uma série mais recente e, em muitos casos, o mesmo encanto seja enviado para ambas as séries. (Também tem havido alguma discussão sobre o suporte de encantos de várias séries, em que as séries suportadas são definidas no encadeamento metadata.yaml .)
Se você encontrar um encanto que esteja disponível apenas para uma série específica, mas realmente quiser executá-lo em uma série diferente (com a advertência de que ele pode não funcionar corretamente), você sempre pode ramificar o encanto do Launchpad em uma estrutura de diretório local de <series>/<charm-name> e implemente-o usando juju deploy local:<series>/<charm-name> . (Este é o mesmo processo que um autor de charme usaria para fazer o charme suportar uma nova série. Se você fizer isso, e conseguir que o charme funcione, certamente o mantenedor do charme provavelmente apreciaria o envio de suas alterações para permitir o charme para apoiar a nova série.)
Observe que a restrição de série somente se aplica à máquina na qual o encanto é implantado. Contanto que dois charms suportem a mesma interface, eles podem ser relacionados e trabalhar juntos, mesmo se estiverem sendo executados em séries diferentes.