Re: Is there a universal interface I can use?

2017-11-22 Thread John Meinel
I did start working on a Cassandra interface for something I was working
on. I don't know that it is complete but
https://github.com/jameinel/interface-cassandra

Was my attempt at it.

John
=:->

On Nov 23, 2017 02:26, "Haw Loeung"  wrote:

> Hi Tilman,
>
> On Wed, Nov 22, 2017 at 04:02:08PM +0100, Tilman Baumann wrote:
> > However, that doesn't seem to work. Juju complains the relation doesn't
> > exist.
> > $ juju add-relation cassandra-backup:database cassandra:database
> > ERROR no relations found
> >
> > So, is there a interface that I can (ab-)use in a similar way?
> >
> > I don't  want to build a full blown cassandra interface and at it to the
> > list.
>
> Not sure if you've seen this, but I did some work recently with
> something similar to backup Cassandra DBs:
>
> | https://jujucharms.com/u/hloeung/cassandra-backup/
>
> It's currently still experimental and uses the CQL COPY
> TO... commands. The Cassandra charm already ships out the required
> credentials so tools such as cqlsh should just work.
>
>
> Regards,
>
> Haw
>
> --
> 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: Is there a universal interface I can use?

2017-11-22 Thread Haw Loeung
Hi Tilman,

On Wed, Nov 22, 2017 at 04:02:08PM +0100, Tilman Baumann wrote:
> However, that doesn't seem to work. Juju complains the relation doesn't
> exist.
> $ juju add-relation cassandra-backup:database cassandra:database
> ERROR no relations found
>
> So, is there a interface that I can (ab-)use in a similar way?
>
> I don't  want to build a full blown cassandra interface and at it to the
> list.

Not sure if you've seen this, but I did some work recently with
something similar to backup Cassandra DBs:

| https://jujucharms.com/u/hloeung/cassandra-backup/

It's currently still experimental and uses the CQL COPY
TO... commands. The Cassandra charm already ships out the required
credentials so tools such as cqlsh should just work.


Regards,

Haw


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


Re: Is there a universal interface I can use?

2017-11-22 Thread Dmitrii Shcherbakov
Also:

"scope: global" vs "scope: container" in metadata.yaml are Juju-level
per-relation concepts.

Regardless of reactive or non-reactive charms, when you do

juju add-relation :
:

relation data will flow only between primary and subordinate units on a
given logical machine (machine or container). In that sense "scope:
container" means primary <-> subordinate on the same "logical machine"
(doesn't have to be an LXD container).

IoW:

scope: container
N relation "instances" between units, 2 * N relation lifecycles (one per
unit)
or a primary only talks to its subordinate over that relation.

scope: global
N * N relation "instances" between units, 2 * N^2  relation lifecycles (N
per unit)
a primary talks to a subordinate and any other same-app primary's
subordinate over that relation

Note that being primary or subordinate does not impact your ability to set
up "scope: global" relations - being a subordinate only affects your
placement and units you can observe over a "scope: container" relation.

Best Regards,
Dmitrii Shcherbakov

Field Software Engineer
IRC (freenode): Dmitrii-Sh

On Wed, Nov 22, 2017 at 8:51 PM, Cory Johns 
wrote:

> You can use the "juju-info" interface type for subordinates, but I'm not
> sure that this is the correct thing for your case.
>
> You're trying to attach the non-subordinate "database" endpoint (of
> interface protocol "juju-info") on your charm to the "database" endpoint
> (of interface protocol "cassandra") on the cassandra charm.  Because the
> interface protocols don't match, Juju will not establish the relation.
> Additionally, because you're not connecting to the subordinate endpoint
> (scope: container) and instead to the standard endpoint, even if the
> relation was established, you would never see an instance of your charm
> created because it has no host application.
>
> All charms have an implicit relation endpoint called "juju-info" of
> interface protocol "juju-info" that you can connect to, and as long as the
> interface protocol match and are unambiguous, you can omit them.  To
> connect your charm using the "juju-info" interface protocol, you would need
> to only define the "host-system" endpoint in your charm (as you currently
> have it), leave off the "database" endpoint, and omit the endpoint portion
> when adding the relation (or, if you want to be explicit about that, you
> can use "juju add-relation cassandra-backup:host-system
> cassandra:juju-info").  Then, for the reactive portion, you would use
> "@when('host-system.available')" as the decorator.
>
> However, I see that you also want to retrieve relation data that the
> cassandra charm provides using the "cassandra" interface protocol.  Here it
> becomes important to note that whether a relation is subordinate or not is
> independent of the interface protocol the relation uses.  Thus, you could
> mark the endpoint as "scope: container" and still use the "cassandra"
> interface protocol.  You would then want to drop the "host-system" endpoint
> from your charm, mark the "database" endpoint as "interface: cassandra",
> and connect as you were trying to do.  However, I seem to recall that
> Stuart (the maintainer of the cassandra charm) raised a possible issue with
> subordinates using relations that the other end doesn't expect to be
> subordinate, so there might be some concerns there.  I can't recall exactly
> what the issue was, and I can't seem to find the bug report now.  Perhaps
> Stuart can chime in.
>
> A final concern is that I don't see an interface layer for the "cassandra"
> interface protocol in the layer index (https://github.com/juju/
> layer-index#list-of-interface-layers), meaning it will be more difficult
> to use in a reactive charm.  Without the interface layer, you wouldn't get
> the flags set to react to and would need to manually inspect the relation
> data using charmhelpers.core.hookenv.  It looks like your use case is
> fairly simple, though, so we can probably get a very basic interface layer
> for it put together pretty quickly that Stuart could then expand upon.  I'm
> happy to help with that, but with the holidays in the US, I might be a few
> days before I can do so.
>
> On Wed, Nov 22, 2017 at 10:02 AM, Tilman Baumann <
> tilman.baum...@canonical.com> wrote:
>
>> I'm writing a reactive subordinate charm for cassandra.
>> I can not find a interface for cassandra. But that's ok, since I don't
>> really need a full blown database connection client.
>>
>> Easy I thought and just re-used the juju-info interface for fun and
>> profit.
>> requires:
>>   host-system:
>> interface: juju-info
>> scope: container
>>   database:
>> interface: juju-info
>>
>> And in the code
>> @when('database.available')
>> def db_changed(cassandra):
>> for conv in cassandra.conversations():
>> username = conv.get_remote('username')
>> password = conv.get_remote('password')
>> ...
>>
>> However, that doesn't seem to work. Juju complains the relation doesn't
>> exis

Re: Is there a universal interface I can use?

2017-11-22 Thread Cory Johns
You can use the "juju-info" interface type for subordinates, but I'm not
sure that this is the correct thing for your case.

You're trying to attach the non-subordinate "database" endpoint (of
interface protocol "juju-info") on your charm to the "database" endpoint
(of interface protocol "cassandra") on the cassandra charm.  Because the
interface protocols don't match, Juju will not establish the relation.
Additionally, because you're not connecting to the subordinate endpoint
(scope: container) and instead to the standard endpoint, even if the
relation was established, you would never see an instance of your charm
created because it has no host application.

All charms have an implicit relation endpoint called "juju-info" of
interface protocol "juju-info" that you can connect to, and as long as the
interface protocol match and are unambiguous, you can omit them.  To
connect your charm using the "juju-info" interface protocol, you would need
to only define the "host-system" endpoint in your charm (as you currently
have it), leave off the "database" endpoint, and omit the endpoint portion
when adding the relation (or, if you want to be explicit about that, you
can use "juju add-relation cassandra-backup:host-system
cassandra:juju-info").  Then, for the reactive portion, you would use
"@when('host-system.available')" as the decorator.

However, I see that you also want to retrieve relation data that the
cassandra charm provides using the "cassandra" interface protocol.  Here it
becomes important to note that whether a relation is subordinate or not is
independent of the interface protocol the relation uses.  Thus, you could
mark the endpoint as "scope: container" and still use the "cassandra"
interface protocol.  You would then want to drop the "host-system" endpoint
from your charm, mark the "database" endpoint as "interface: cassandra",
and connect as you were trying to do.  However, I seem to recall that
Stuart (the maintainer of the cassandra charm) raised a possible issue with
subordinates using relations that the other end doesn't expect to be
subordinate, so there might be some concerns there.  I can't recall exactly
what the issue was, and I can't seem to find the bug report now.  Perhaps
Stuart can chime in.

A final concern is that I don't see an interface layer for the "cassandra"
interface protocol in the layer index (
https://github.com/juju/layer-index#list-of-interface-layers), meaning it
will be more difficult to use in a reactive charm.  Without the interface
layer, you wouldn't get the flags set to react to and would need to
manually inspect the relation data using charmhelpers.core.hookenv.  It
looks like your use case is fairly simple, though, so we can probably get a
very basic interface layer for it put together pretty quickly that Stuart
could then expand upon.  I'm happy to help with that, but with the holidays
in the US, I might be a few days before I can do so.

On Wed, Nov 22, 2017 at 10:02 AM, Tilman Baumann <
tilman.baum...@canonical.com> wrote:

> I'm writing a reactive subordinate charm for cassandra.
> I can not find a interface for cassandra. But that's ok, since I don't
> really need a full blown database connection client.
>
> Easy I thought and just re-used the juju-info interface for fun and profit.
> requires:
>   host-system:
> interface: juju-info
> scope: container
>   database:
> interface: juju-info
>
> And in the code
> @when('database.available')
> def db_changed(cassandra):
> for conv in cassandra.conversations():
> username = conv.get_remote('username')
> password = conv.get_remote('password')
> ...
>
> However, that doesn't seem to work. Juju complains the relation doesn't
> exist.
> $ juju add-relation cassandra-backup:database cassandra:database
> ERROR no relations found
>
> So, is there a interface that I can (ab-)use in a similar way?
>
> I don't  want to build a full blown cassandra interface and at it to the
> list.
>
> Cheers and thanks
>  Tilman
>
> --
> 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: Juju patents

2017-11-22 Thread Merlijn Sebrechts
Hi Mark


The United States Patent Office has an online filing system where you can
submit prior art. 

I can help search for prior art, but I have no idea what's actually
required to be valid prior art. The patent application is very dense, and
it's not clear to me what they are claiming. Strangely, TOSCA is referred
to in the patent itself, even though that seems like prior art to me.. Is
anyone in Canonical more familiar with this?



Kind regards
Merlijn

2017-11-15 8:39 GMT+01:00 Mark Shuttleworth :

> On 11/13/2017 09:34 AM, Merlijn Sebrechts wrote:
> > Just got a scholar alert for three patents that seem to be describing
> > Juju/TOSCA.
> >
> > - "TOPOLOGY BASED MANAGEMENT WITH STAGE AND VERSION
> > POLICIES": http://www.freepatentsonline.com/y2017/0302532.html
> > - "TOPOLOGY BASED MANAGEMENT WITH COMPLIANCE
> > POLICIES": http://www.freepatentsonline.com/y2017/0302531.html
> > - TOPOLOGY BASED MANAGEMENT OF SECOND DAY OPERATIONS":
> > http://www.freepatentsonline.com/y2017/0302537.html
> >
> > These were filed in 2014 by HPE. Even with a grace period of one year,
> > it's still more than a year after the first release of Juju and TOSCA.
> > Is Canonical interested in fighting this?
> >
>
> Juju is covered by the Open Invention Network, so I wouldn't expect any
> problems from HPE in this regard. If it's straightforward to notify the
> patent office of prior art, then I'd be happy to facilitate that.
>
> Mark
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju


Is there a universal interface I can use?

2017-11-22 Thread Tilman Baumann
I'm writing a reactive subordinate charm for cassandra.
I can not find a interface for cassandra. But that's ok, since I don't
really need a full blown database connection client.

Easy I thought and just re-used the juju-info interface for fun and profit.
requires:
  host-system:
interface: juju-info
scope: container
  database:
interface: juju-info

And in the code
@when('database.available')
def db_changed(cassandra):
for conv in cassandra.conversations():
username = conv.get_remote('username')
password = conv.get_remote('password')
...

However, that doesn't seem to work. Juju complains the relation doesn't
exist.
$ juju add-relation cassandra-backup:database cassandra:database
ERROR no relations found

So, is there a interface that I can (ab-)use in a similar way?

I don't  want to build a full blown cassandra interface and at it to the
list.

Cheers and thanks
 Tilman

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


VMWare support in 2.3-rc1.1

2017-11-22 Thread Merlijn Sebrechts
Hi all


I've been trying out Juju 2.3-rc1.1 on VMware. Good work on this, we were
finally able to create a functional controller on our cluster!

There are however still a couple of issues I wanted to bring to your
attention. The most serious one is that LXD support seems to be broken
(more than on other non-maas clouds).

Our network setup is the following: We have two networks: a
`primary-network`, running a dhcp server with ddns, and a
`external-network` where users need to add an IP address manually. This is
because public ip's are very scarce in our organization and we can't just
give Juju an entire range.

Juju seems to handle this pretty well: when a VM is created, it is attached
to both networks, but it only gets an IP on the `primary-network`. That IP
is then also used as `public-address` for the VM. When a user manually adds
a public IP to the interface, Juju picks that up after a few minutes, and
uses that ip as `public-address`. This is exactly what we want, good job!

These are the issues we're still having:

   - LXD support is broken: with the current network setup, creating an LXD
   container on a VM makes the VM unreachable. If we remove the
   `external-network` from the setup, LXD containers never come up.:
   https://bugs.launchpad.net/juju/+bug/1733882


   - The default constraints VM's differs between EC2/VMware. Is this
   intentional? It causes some bundles to fail since they don't get enough RAM.


   - Firewaller doesn't work: https://bugs.launchpad.net/juju/+bug/1732665


   - cloud-init warns about the cloud being reported as "EC2":
   https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1731868


   - When you remove a VM with Juju, the vmdk disk image is deleted from
   _all_ datastores, instead of only the one where juju put the image. This
   might pose a problem if people use a datastore as a backup.
   https://bugs.launchpad.net/juju/+bug/1733885



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


Re: using the juju client from jenkins

2017-11-22 Thread Tom Barber

I'm not sure if this is of any use:

https://github.com/spiculedata/circleci-juju/blob/master/charmlogin

I use `expect` to process a charm login for me.


On 22/11/17 13:01, James Beedy wrote:

Konstantinos,

Thanks for that. I need to get CI/CD setup for my charms, that will be 
very helpful to me very soon.


Possibly I didn't illuminate the issue I'm having correctly though.

1) I have a pdl-api charm, that manages the pdl-api.snap.
2) My CI/CD pipeline for the pdl-api has two steps; build, deploy.
    - The build job tests the code and builds the snap, then passes 
the built artifact to the deploy step.
    - The deploy step basically takes the built snap and attaches it 
to the pdl-api charm https://imgur.com/a/UiIg7


The issue at hand, is that my jenkins user token expires and I end up 
with a failing deploy job http://paste.ubuntu.com/26019762/ .


To remedy this, I always have to `juju ssh jenkins/0; sudo -ui 
jenkins; juju login`


Is this more clear?

Thanks





On Wed, Nov 22, 2017 at 2:17 AM, Konstantinos Tsakalozos 
mailto:kos.tsakalo...@canonical.com>> 
wrote:


Hi James,

We build our charms, push them to the store on the edge channel, and
then our tests run against what is on edge. With this approach the
team can sync on a specific build revision instead of each one
separately trying to rebuild the charm locally and reproduce any
unexpected behaviour. As soon as we are happy with a build we just
promote it to the next channel (beta,candidate or stable). You can
find our work here:
https://github.com/juju-solutions/kubernetes-jenkins/tree/master/charms


Cheers,
Konstantinos

On Wed, Nov 22, 2017 at 2:21 AM, James Beedy mailto:jamesbe...@gmail.com>> wrote:
> I've a feeling that the majority of the CI/CD I've left in my
trails that
> attaches a resource from jenkins via juju bash cli are probably
not working.
> The latest CI/CD I've setup runs `juju attach` from jenkins, and
I have to
> login to the jenkins shell and su to the jenkins user and login
to be able
> to run my deploy step in jenkins.
>
> Is there a way that people are doing the jenkins<->juju dance
without
> lib-juju?
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju

>







--


Spicule Limited is registered in England & Wales. Company Number: 09954122. 
Registered office: First Floor, Telecom House, 125-135 Preston Road, 
Brighton, England, BN1 6AF. VAT No. 251478891.



All engagements are subject to Spicule Terms and Conditions of Business. 
This email and its contents are intended solely for the individual to whom 
it is addressed and may contain information that is confidential, 
privileged or otherwise protected from disclosure, distributing or copying. 
Any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of Spicule Limited. The 
company accepts no liability for any damage caused by any virus transmitted 
by this email. If you have received this message in error, please notify us 
immediately by reply email before deleting it from your system. Service of 
legal notice cannot be effected on Spicule Limited by email.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju


Re: using the juju client from jenkins

2017-11-22 Thread James Beedy
Konstantinos,

Thanks for that. I need to get CI/CD setup for my charms, that will be very
helpful to me very soon.

Possibly I didn't illuminate the issue I'm having correctly though.

1) I have a pdl-api charm, that manages the pdl-api.snap.
2) My CI/CD pipeline for the pdl-api has two steps; build, deploy.
- The build job tests the code and builds the snap, then passes the
built artifact to the deploy step.
- The deploy step basically takes the built snap and attaches it to the
pdl-api charm https://imgur.com/a/UiIg7

The issue at hand, is that my jenkins user token expires and I end up with
a failing deploy job http://paste.ubuntu.com/26019762/ .

To remedy this, I always have to `juju ssh jenkins/0; sudo -ui jenkins;
juju login`

Is this more clear?

Thanks






On Wed, Nov 22, 2017 at 2:17 AM, Konstantinos Tsakalozos <
kos.tsakalo...@canonical.com> wrote:

> Hi James,
>
> We build our charms, push them to the store on the edge channel, and
> then our tests run against what is on edge. With this approach the
> team can sync on a specific build revision instead of each one
> separately trying to rebuild the charm locally and reproduce any
> unexpected behaviour. As soon as we are happy with a build we just
> promote it to the next channel (beta,candidate or stable). You can
> find our work here:
> https://github.com/juju-solutions/kubernetes-jenkins/tree/master/charms
>
> Cheers,
> Konstantinos
>
> On Wed, Nov 22, 2017 at 2:21 AM, James Beedy  wrote:
> > I've a feeling that the majority of the CI/CD I've left in my trails that
> > attaches a resource from jenkins via juju bash cli are probably not
> working.
> > The latest CI/CD I've setup runs `juju attach` from jenkins, and I have
> to
> > login to the jenkins shell and su to the jenkins user and login to be
> able
> > to run my deploy step in jenkins.
> >
> > Is there a way that people are doing the jenkins<->juju dance without
> > lib-juju?
> >
> > --
> > 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: using the juju client from jenkins

2017-11-22 Thread Konstantinos Tsakalozos
Hi James,

We build our charms, push them to the store on the edge channel, and
then our tests run against what is on edge. With this approach the
team can sync on a specific build revision instead of each one
separately trying to rebuild the charm locally and reproduce any
unexpected behaviour. As soon as we are happy with a build we just
promote it to the next channel (beta,candidate or stable). You can
find our work here:
https://github.com/juju-solutions/kubernetes-jenkins/tree/master/charms

Cheers,
Konstantinos

On Wed, Nov 22, 2017 at 2:21 AM, James Beedy  wrote:
> I've a feeling that the majority of the CI/CD I've left in my trails that
> attaches a resource from jenkins via juju bash cli are probably not working.
> The latest CI/CD I've setup runs `juju attach` from jenkins, and I have to
> login to the jenkins shell and su to the jenkins user and login to be able
> to run my deploy step in jenkins.
>
> Is there a way that people are doing the jenkins<->juju dance without
> lib-juju?
>
> --
> 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