Re: Compiling juju on openSUSE

[Jorge O. Castro]

On Fri, Sep 18, 2015 at 1:35 PM, Herman Bergwerf
 wrote:
> Anyone who has experience compiling juju on openSUSE?

If you're looking for just running the client, the dockerized Juju box
is a good place to start:

https://github.com/juju-solutions/jujubox

That is much less complicated than compiling Juju and everything. In
the past we had community RPM builds, if you have experience with
using the OpenSUSE Build Service or something and want to help us sort
that, any contributions in that direction would be happily accepted!

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Compiling juju on openSUSE

[Nate Finch]

Compiling juju on any Linux is actually very straight forward... however
*running* Juju on any Linux except Ubuntu and Centos is not going to work
(due to some platform-specific code we have)... but if all you want to do
is compile, that's easy:

Install git, bzr, and mercurial (pretty sure mercurial is no longer
required at this point, though).
install go, version 1.2.1 or higher (1.2.1 is the officially supported
version for Juju... newer versions *should* work, but are not official yet).

export GOPATH=$HOME
this tells go where to store its code, you could pick a different
gopath if you want.

run these commands to compile juju's master branch:

go get github.com/juju/juju/...
this will download and compile juju, but there may be a couple compiler
errors... that's ok
go get launchpad.net/godeps
this will download and compile the godeps application, and copy it to
$GOPATH/bin
cd $GOPATH/src/github.com/juju/juju
$GOPATH/bin/godeps -u dependencies.tsv
this will update the various repos that juju uses to the correct
versions (and thus fix the compiler errors from above)
go install ./...
this will recompile with the newly updated juju code and copy the juju
and jujud binaries to $GOPATH/bin

You can, of course, use git to switch from the master juju branch to a
release branchand compile that instead.  Just do that in $GOPATH/src/
github.com/juju/juju before running godeps, and then follow the rest of the
steps.

-Nate

On Fri, Sep 18, 2015 at 1:35 PM Herman Bergwerf 
wrote:

> Anyone who has experience compiling juju on openSUSE?
> I'm an openSUSE users myself and I wanted to use the juju client on
> openSUSE. Everything worked out until I came to make install-dependencies
> because there are Ubuntu/Debian commands in the Makefile. Is it possible to
> compile juju on openSUSE and is there someone who could give me some leads
> for this?
> --
> 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

Re: Trying to remove and redeploy quantum-gateway on a different server

[Mike McCracken]

Hi Jeff!

On Fri, Sep 18, 2015 at 11:12 AM, Jeff McLamb  wrote:

> Hi all -
>
> * Sorry for the cross-post on openstack-installer, but I think this is
> more of a juju question than an openstack-installer issue*
>
> As I originally deployed my current test setup via openstack-installer, I
> am wondering how I am supposed to use it and/or juju directly for future
> changes/additions.
>

Yes, the openstack-installer is intended to be a first step and not a full
purpose juju front-end. For future changes of the sort you're describing,
you'll want to get familiar with using juju directly. Note that the
official Juju web GUI is one of the services that you can install via the
manual placement UI in the installer.

I am trying to understand neutron networking, investigating all of the OVS
> and Linux bridges, how traffic flows between them and the network node etc.
> In my initial deployment I co-located a compute node and the network node
> on bare metal via manual placement in openstack-installer.
>
> Now, in order to better see the separation of stuff (i.e. not conflate
> what the compute node is doing with the network node) I decided to `juju
> remove-service quantum-gateway` followed by a `juju add-service
> quantum-gateway —to lxc:3` in order to remove it from the original node and
> install it into its own container on the controller node that hosts lots of
> container-based services.
>
> I have received lots of errors in the process during which various hooks
> get stuck. I have been able to get around it by manually killing hooks and
> then issuing a `juju resolved quantum-gateway` until finally the service
> goes away. Not to mention the fact that a new deployment seems to be in a
> “blocked” state saying I should upgrade to neutron-gateway. I tried that
> with similar results.
>
> At this point I managed to get rid of everything — i.e. I do not have a
> quantum-gateway or a neutron-gateway as reported by juju.
>
> However, I have noticed that the original server (colocated compute and
> quantum-gateway) still has all of the neutron services running. Issuing a
> `neutron agent-list` shows everything connected and happy as it ever was.
> It seems as though my juju fiddling has basically been just manipulating
> the juju database without actually removing the underlying services. I have
> noticed that when removing services on an lxc container it does indeed kill
> the container (so obviously the service too)… however, maybe because this
> original service was deployed on bare metal with another service, it
> doesn’t bother to actually stop the services and remove their /etc/init
> files?
>

This does sound unexpected, hopefully someone more directly involved with
Juju can comment here.


> I have tried to redeploy via openstack-status, but it seems like it is
> useless for future deployment even though it has that nice curses-looking
> GUI from which I can deploy. It’s understanding of where everything is
> placed is completely broken, and it does not seem to honor any requests to
> place stuff in the first place.
>

I'll follow up with you about the openstack-status tool on the installer
list, to keep this thread juju-specific.


> Any ideas?
>
> Thanks,
>
> Jeff
>
> --
> 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

Re: Trying to remove and redeploy quantum-gateway on a different server

[Jeff McLamb]

Thanks for the info, Mike! I will provide a bit more detail as to what’s
going on in case any Juju experts have seen something similar.

Where I last left off, I had deleted all units of anything
{neutron,quantum}-gateway related from juju’s perspective. However, the
original bare metal node was still providing the neutron gateway (i.e.
network node) services, so I manually issued a stop on all of those (e.g.
stop neutron-dhcp, stop neutron-metadata-server, stop neutron-metering,
etc.) The only thing I left running on that server was openvswitch because
it is also a compute node, so it needs to have the openvswitch plugin
running, as I understand it.

I then issued a `juju deploy neutron-gateway —to lxc:3` in order to install
the gateway in an lxc container.

The lxc container is provisioned and everything seems to be going OK until
it gets stuck in agent status -> message: running config-changed hook

If I ssh into the container itself and look at processes, I can see it is
in a seemingly infinite loop where the neutron rootwrapper is constantly
issuing ovs-vsctl add-br br-int calls, along with adding and removing
flows. It’s as though it keeps trying to add and remove the br-int ovs, and
just sits there doing that forever.

I manually killed the config-changed hook and then issued a `juju
debug-hooks neutron-gateway/0 config-changed` followed by `juju resolved
neutron-gateway/0 —retry`, which has dumped me into a config-changed tmux
session where I manually issued ./hooks/config-changed.

There is not much other than the following output, after which it hangs:

root@juju-machine-3-lxc-11:/var/lib/juju/agents/unit-neutron-gateway-0/charm#
./hooks/config-changed
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
python-dbus is already the newest version.
The following packages were automatically installed and are no longer
required:
  libfreetype6 os-prober
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

At this point everything hangs. I have not yet Ctrl-C’d the process yet.

In the /var/log/juju/unit-neutron-gateway-0.log it looks pretty standard,
finishing all log output with Creating bridge br-int, Creating bridge
br-ex, Creating bridge br-tun.

At this point there is no more streaming log output either.

Has anyone else seen this or have an idea what might be going on?

Thanks,

Jeff

On Fri, Sep 18, 2015 at 2:22 PM, Mike McCracken <
mike.mccrac...@canonical.com> wrote:

> Hi Jeff!
>
> On Fri, Sep 18, 2015 at 11:12 AM, Jeff McLamb  wrote:
>
>> Hi all -
>>
>> * Sorry for the cross-post on openstack-installer, but I think this is
>> more of a juju question than an openstack-installer issue*
>>
>> As I originally deployed my current test setup via openstack-installer, I
>> am wondering how I am supposed to use it and/or juju directly for future
>> changes/additions.
>>
>
> Yes, the openstack-installer is intended to be a first step and not a full
> purpose juju front-end. For future changes of the sort you're describing,
> you'll want to get familiar with using juju directly. Note that the
> official Juju web GUI is one of the services that you can install via the
> manual placement UI in the installer.
>
> I am trying to understand neutron networking, investigating all of the OVS
>> and Linux bridges, how traffic flows between them and the network node etc.
>> In my initial deployment I co-located a compute node and the network node
>> on bare metal via manual placement in openstack-installer.
>>
>> Now, in order to better see the separation of stuff (i.e. not conflate
>> what the compute node is doing with the network node) I decided to `juju
>> remove-service quantum-gateway` followed by a `juju add-service
>> quantum-gateway —to lxc:3` in order to remove it from the original node and
>> install it into its own container on the controller node that hosts lots of
>> container-based services.
>>
>> I have received lots of errors in the process during which various hooks
>> get stuck. I have been able to get around it by manually killing hooks and
>> then issuing a `juju resolved quantum-gateway` until finally the service
>> goes away. Not to mention the fact that a new deployment seems to be in a
>> “blocked” state saying I should upgrade to neutron-gateway. I tried that
>> with similar results.
>>
>> At this point I managed to get rid of everything — i.e. I do not have a
>> quantum-gateway or a neutron-gateway as reported by juju.
>>
>> However, I have noticed that the original server (colocated compute and
>> quantum-gateway) still has all of the neutron services running. Issuing a
>> `neutron agent-list` shows everything connected and happy as it ever was.
>> It seems as though my juju fiddling has basically been 

Re: Juju on multiple public clouds

[Nate Finch]

It depends on what you mean.  If you mean "can I have some machines on AWS
talk to some other machines in Azure inside the same Juju environment" then
the answer is mostly no (you can use a machine's ssh info to "import" that
machine into an existing juju environment, but it's quite different than
full support of more than one cloud provider in the same environment...
like no ability to automatically spin up or destroy the manually added
machines).  To do the import, use juju add-machine ssh@ipaddress to add the
machine to the current environment.

That being said, as Jose said... if you just want to have a collection of
AWS machines talk to each other and a separate collection of Azure (or
whatever) machines talk to each other (without being able to talk Azure <->
AWS) then you can create them as separate environments and that works fine.

On Fri, Sep 18, 2015 at 1:06 PM José Antonio Rey  wrote:

> Yes. Just set up different environments in your environments.yaml file,
> and then you can switch between them using juju switch.
>
> On 09/18/2015 12:28 PM, Herman Bergwerf wrote:
> > Is it possible to run juju across multiple public (/private) clouds? For
> > example, you can run juju on AWS and select different regions but can
> > you also run juju on AWS and GCP?
> >
> >
>
> --
> José Antonio Rey
>
> --
> 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

Openstack charms - mellanox support

[Edward Bond]

Anyone have information around being able to use charms to have...

Neutron:
Mellanox ml2 plugin.
https://wiki.openstack.org/wiki/Mellanox-Neutron-ML2-Kilo
Ceph:
Cluster communication.
http://www.mellanox.com/related-docs/whitepapers/WP_Deploying_Ceph_over_High_Performance_Networks.pdf


We are trying to get a high speed backend going with our openstack
deployment.

Thanks!
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju on CloudStack

[Herman Bergwerf]

Hmm, ok. I'm quite surprised a pretty widely used virtualization stack such
as cloudstack is not implemented in juju at all. Are there maybe future
plans to do this?
By the way, wouldn't it be easier to write a provider directly inside the
juju code? I'm not sure if there is any documentation to do this.

Op vr 18 sep. 2015 om 18:14 schreef Nick Veitch :

> Unless anyone knows of any secret switches for the Amazon provider, I
> think manual provider is the easier option, though you do miss out on some
> of the joys of Juju that way.
>
> https://jujucharms.com/docs/stable/config-manual
>
>
> But don't let me dissuade you from writing a CloudStack provider! You
> might want to look at the DigitalOcean provider plugin, which uses the
> manual provider: https://github.com/kapilt/juju-digitalocean
>
>
> On 18 September 2015 at 16:55, Herman Bergwerf 
> wrote:
>
>> Ok, I suspected that. But I don't think it is already enabled so I'll
>> have to contact my hosting company to ask if they can enable it (I think
>> it's this:
>> http://cloudstack-installation.readthedocs.org/en/latest/optional_installation.html#enabling-the-ec2-and-s3-compatible-interface
>> )
>> Also, the docs (https://jujucharms.com/docs/stable/config-aws) do not
>> mention a way to use another ec2 endpoint in the current version of juju. I
>> read some stuff about specifying another ec2 endpoint for cloudstack but it
>> was all pretty old (2013 or something, I think juju was still in python
>> back then)
>>
>> Alternatively I could write a set of shell scripts to make it work with
>> manual provisioning. Or maybe I can compile my own version of juju and
>> write a cloudstack provider? (
>> https://github.com/juju/juju/tree/8da94246468a4da71e62894f7a8a1bbbce112697/provider/ec2,
>> it seems like a provider implementation is pretty extensive in juju, cloud
>> drivers in salt seemed more straightforward)
>>
>> Op vr 18 sep. 2015 om 17:44 schreef José Antonio Rey :
>>
>>> CloudStack as CloudStack is not supported. However, Jorge mentions that,
>>> if he recalls correctly, it works like if it was EC2. So he's suggesting
>>> setting CloudStack as an amazon or ec2 environment, even though it's
>>> CloudStack, because it may work this way. It's a workaround since we
>>> don't have official direct CloudStack support.
>>>
>>>
>>> On 09/18/2015 10:40 AM, Herman Bergwerf wrote:
>>> > Im not sure what you mean but I don't think I have access to the
>>> > cloudstack configuration (the interface is provided by the hosting
>>> > company I'm with)
>>> > Also, would that mean I can maybe already use the ec2 driver in juju by
>>> > pointing it to the cloudstack endpoint from my hosting provider?
>>> Because
>>> > the docs are not really clear about this...
>>> >
>>> >
>>> > On Fri, Sep 18, 2015, 17:21 Jorge O. Castro >> > > wrote:
>>> >
>>> > On Thu, Sep 17, 2015 at 9:47 AM, Herman Bergwerf
>>> > >
>>> wrote:
>>> >  > (how) can I run Juju on CloudStack?
>>> >
>>> > It's my understanding that CloudStack emulates an EC2 environment's
>>> > APIs, have you tried configuring it as an EC2 environment?
>>> >
>>> >
>>> >
>>>
>>> --
>>> José Antonio Rey
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
>
> --
> Nick Veitch
> nick.vei...@canonical.com
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

"Designing for Success: Juju and Charm architecture overview" - Juju Charm Summit

[Marco Ceppi]

Here are my slides from the first session on Thursday morning. It's a meant
to be an overview of the Juju and Charm architecture. I'm curious on
feedback as it's the first time I've run this style presentation.

https://docs.google.com/presentation/d/1_rTFq-aS_ESK2wabnCviZtDZ-nYOPI23MeLp-GLDyJY/edit

Thanks,
Marco Ceppi
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Compiling juju on openSUSE

[Curtis Hovey-Canonical]

On Fri, Sep 18, 2015 at 1:18 PM, Jorge O. Castro  wrote:
> On Fri, Sep 18, 2015 at 1:35 PM, Herman Bergwerf
>  wrote:
>> Anyone who has experience compiling juju on openSUSE?

As the juju is staticly compiled for most archs, and series/os-version
is irrelevant, you can use any Juju that matched your os and
architecture. eg. you can download a linux amd64 client and expect it
to work.

e.g. I downloaded the centos7 client from
https://launchpad.net/juju-core/+milestone/1.24.5  and ran it on
Ubuntu precise and Ubuntu wily.

You probably do need to hack and compile your own client though.
Juju's client thinks it needs to know the version of linux which is
bogus for the common case of bootstrapping and maintaining a server in
a cloud.
https://bugs.launchpad.net/juju-core/+bug/1465317

See version/osversion.go and version/supportedseries.go





-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju on multiple public clouds

[Herman Bergwerf]

Ok, I meant the first thing. I don't need it right now but I might need it
in the future to scale out my infrastructure. But I suppose I could also
just migrate my entire infrastructure to another provider (I'm not sure if
this is directly possible without downtime but I can also first build a new
cluster and then switch the DNS)

Op vr 18 sep. 2015 om 22:12 schreef Nate Finch :

> It depends on what you mean.  If you mean "can I have some machines on AWS
> talk to some other machines in Azure inside the same Juju environment" then
> the answer is mostly no (you can use a machine's ssh info to "import" that
> machine into an existing juju environment, but it's quite different than
> full support of more than one cloud provider in the same environment...
> like no ability to automatically spin up or destroy the manually added
> machines).  To do the import, use juju add-machine ssh@ipaddress to add
> the machine to the current environment.
>
> That being said, as Jose said... if you just want to have a collection of
> AWS machines talk to each other and a separate collection of Azure (or
> whatever) machines talk to each other (without being able to talk Azure <->
> AWS) then you can create them as separate environments and that works fine.
>
> On Fri, Sep 18, 2015 at 1:06 PM José Antonio Rey  wrote:
>
>> Yes. Just set up different environments in your environments.yaml file,
>> and then you can switch between them using juju switch.
>>
>> On 09/18/2015 12:28 PM, Herman Bergwerf wrote:
>> > Is it possible to run juju across multiple public (/private) clouds? For
>> > example, you can run juju on AWS and select different regions but can
>> > you also run juju on AWS and GCP?
>> >
>> >
>>
>> --
>> José Antonio Rey
>>
>> --
>> 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

Juju on multiple public clouds

[Herman Bergwerf]

Is it possible to run juju across multiple public (/private) clouds? For
example, you can run juju on AWS and select different regions but can you
also run juju on AWS and GCP?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju on CloudStack

[José Antonio Rey]

CloudStack as CloudStack is not supported. However, Jorge mentions that, 
if he recalls correctly, it works like if it was EC2. So he's suggesting 
setting CloudStack as an amazon or ec2 environment, even though it's 
CloudStack, because it may work this way. It's a workaround since we 
don't have official direct CloudStack support.



On 09/18/2015 10:40 AM, Herman Bergwerf wrote:

Im not sure what you mean but I don't think I have access to the
cloudstack configuration (the interface is provided by the hosting
company I'm with)
Also, would that mean I can maybe already use the ec2 driver in juju by
pointing it to the cloudstack endpoint from my hosting provider? Because
the docs are not really clear about this...


On Fri, Sep 18, 2015, 17:21 Jorge O. Castro > wrote:

On Thu, Sep 17, 2015 at 9:47 AM, Herman Bergwerf
> wrote:
 > (how) can I run Juju on CloudStack?

It's my understanding that CloudStack emulates an EC2 environment's
APIs, have you tried configuring it as an EC2 environment?





--
José Antonio Rey

--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Compiling juju on openSUSE

[Herman Bergwerf]

Anyone who has experience compiling juju on openSUSE?
I'm an openSUSE users myself and I wanted to use the juju client on
openSUSE. Everything worked out until I came to make install-dependencies
because there are Ubuntu/Debian commands in the Makefile. Is it possible to
compile juju on openSUSE and is there someone who could give me some leads
for this?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju