Re: Removing the single point of failure

2017-01-30 Thread Antonio Rosales 
On Fri, Jan 27, 2017 at 5:38 AM, Adam Stokes  wrote:
> Circling back around to this. Do we have an ETA or any updates on the
> progress of interfaces.juju.solutions being folded into jujucharms.com?

Indeed some work we would like to kick off and have scheduled for this
Ubuntu 17.04 cycle. Currently we are sprinting on Charm CI Developer
Workflow and Review Queue. Once we compete those milestones some ideas
we have for interfaces are:
- Mirroring content
- Show what charms layer is built in
- Better usage shown to users
- Better readme linking from repositories
With work to move this into *.jujucharms.com

Current webservice code is at
https://github.com/juju-solutions/juju-interface, and if any folks are
interested in contributing please feel free to reply here.

-thanks,
Antonio


ie https://github.com/apache/bigtop/tree/master/bigtop-packages/src
>
>
> On Sat, Nov 12, 2016, 11:20 AM Marco Ceppi 
> wrote:
>>
>> Hey everyone,
>>
>> We're aware of the outage and working to bring the service back online.
>> This is unfortunate, but we're in the process of getting the
>> interfaces.juju.solutions site, folded into the charm store properly. This
>> service has done it's job in providing the initial indexing but as we see
>> today it's become integral to the operation of charm authorship and should
>> be as robust as the charm store itself.
>>
>> To address concerns about "what if". Juju, the interfaces site, the charm
>> layers, are all open source projects. While some items aren't directly
>> configurable if we ever did enter a period where Canonical wasn't directly
>> maintaining infrastructure for Juju and Charms the community could uphold
>> these projects and elect to run them directly. Juju is a key platform to
>> Canonical just as it is to you all. While outages like this may occur, we
>> are iterating quickly to make sure projects like the interfaces site are
>> folded into jujucharms.com and served with the same level SLA and HA as
>> you've come to expect.
>>
>> Marco
>>
>> On Sat, Nov 12, 2016 at 10:44 AM Tom Barber  wrote:
>>>
>>> I don't really think Mark is going to do one, my point is that for
>>> platforms like this to survive if they depend on central services for
>>> build/running etc, the services shouldn't just be maintained by a single
>>> entity.
>>>
>>> HA sure will solve some issues but I also think that distributing
>>> ownership also mitigates risk.
>>>
>>>
>>> On 12 Nov 2016 16:39, "James Beedy"  wrote:

 Here's something thats been troubling me for a while, Canonical are the
 single point of failure with juju. For example, this morning
 interfaces.juju.solutions appears to be offline, thats not the end of
 the
 world but of course I can't download layers from it.

 I entirely second this. Interfaces.juju.solutions needs to have some
 kind of uptime guarantee, and probably need each component deployed in
 HA/federated to ensure the uptime.

 Companies/people are building infrastructure around the charm store,
 interfaces.juju.solutions, and juju itself, what happens when 100 entities
 realize that their CI (or any critical infrastructure) has been down for an
 amount of time? For many, this could stunt development and increase budget
 expenditures.


 Similarly, if Mark for whatever reason decided he couldn't be bothered
 with
 Juju any more and went and did something else, the users would be
 without
 resource that is vital to people building stuff.


 I have to disagree with you here. Mark is an amazing driver for these
 technologies and technology communities, but they exist outside of, and
 disparate of Mark and Canonical. While the world (as well as these
 technologies) would undoubtedly not be same if not for Mark's
 contribution(s), I think the idea here is that the majority of the software
 in Canonical stack has enough wind under it to survive in the wild.

 Does mirroring capabilities exist for other people to mirror
 interfaces.juju.solutions and can you tell juju to use another portal?
 That
 way, much like maven central, those of us with bandwidth could mirror
 resources that are vital for smooth running of Juju operations.

 True, mirroring would be huge, but shouldn't be a solution . We
 should deploy the site across multiple az/regions if you ask me :-)




 --
 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 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://l

Re: Request to join ~charmers

2017-01-30 Thread Pete Vander Giessen 
> +1 for Pete :)
>
> Welcome aboard my man!
>

Awesome. Thank you, everyone. I will try to use my powers for good :-)

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

Re: Request to join ~charmers

2017-01-30 Thread Antonio Rosales 
Congrats on your charmer-hood Pete!

-Antonio

On Mon, Jan 30, 2017 at 7:16 AM, Tom Barber  wrote:
> N not Pete, you'll take him away from being ultra useful and pool him
> with the rest of you lot! ;)
>
>
> On 30 Jan 2017 14:13, "Charles Butler"  wrote:
>>
>> +1 for Pete :)
>>
>> Welcome aboard my man!
>>
>>
>> Charles Butler  - Juju Charmer
>> Come see the future of modeling your datacenter: http://jujucharms.com
>> Conjure up Kubernetes: `conjure-up canonical-kubernetes` on any ubuntu
>> install with Conjure and Juju.
>>
>> On Thu, Jan 26, 2017 at 10:01 AM, Pete Vander Giessen
>>  wrote:
>>>
>>> Hi All,
>>>
>>> I've been working with the Big Data team since May 2016, and have written
>>> or contributed to our charms (see https://github.com/juju-solutions/bigtop),
>>> and layers (e.g.
>>> https://github.com/juju-solutions/layer-apache-bigtop-base), as well as to
>>> the matrix testing tool and cloud weather report. I also take a trip through
>>> the review queue with the team once a week, and would like to be able to
>>> finish up my positive reviews with a push to the charm store, when
>>> appropriate.
>>>
>>> Thank you for considering me,
>>> ~ PeteVG
>>>
>>>
>>>
>>> --
>>> 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 mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

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

Re: Request to join ~charmers

2017-01-30 Thread Tom Barber 
N not Pete, you'll take him away from being ultra useful and pool him
with the rest of you lot! ;)


On 30 Jan 2017 14:13, "Charles Butler"  wrote:

> +1 for Pete :)
>
> Welcome aboard my man!
>
>
> Charles Butler  - Juju Charmer
> Come see the future of modeling your datacenter: http://jujucharms.com
> Conjure up Kubernetes: `conjure-up canonical-kubernetes` on any ubuntu
> install with Conjure and Juju.
>
> On Thu, Jan 26, 2017 at 10:01 AM, Pete Vander Giessen <
> pete.vandergies...@canonical.com> wrote:
>
>> Hi All,
>>
>> I've been working with the Big Data team since May 2016, and have written
>> or contributed to our charms (see https://github.com/juju-s
>> olutions/bigtop), and layers (e.g. https://github.com/juju-
>> solutions/layer-apache-bigtop-base), as well as to the matrix testing
>> tool and cloud weather report. I also take a trip through the review queue
>> with the team once a week, and would like to be able to finish up my
>> positive reviews with a push to the charm store, when appropriate.
>>
>> Thank you for considering me,
>> ~ PeteVG
>>
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Request to join ~charmers

2017-01-30 Thread Charles Butler 
+1 for Pete :)

Welcome aboard my man!


Charles Butler  - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com
Conjure up Kubernetes: `conjure-up canonical-kubernetes` on any ubuntu
install with Conjure and Juju.

On Thu, Jan 26, 2017 at 10:01 AM, Pete Vander Giessen <
pete.vandergies...@canonical.com> wrote:

> Hi All,
>
> I've been working with the Big Data team since May 2016, and have written
> or contributed to our charms (see https://github.com/juju-solutions/bigtop),
> and layers (e.g. https://github.com/juju-solutions/layer-apache-bigtop-
> base), as well as to the matrix testing tool and cloud weather report. I
> also take a trip through the review queue with the team once a week, and
> would like to be able to finish up my positive reviews with a push to the
> charm store, when appropriate.
>
> Thank you for considering me,
> ~ PeteVG
>
>
>
> --
> 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: Peers vs Members vs Terminology vs Usability

2017-01-30 Thread Stuart Bishop 
On 30 January 2017 at 02:55, James Beedy  wrote:


> I've been using elasticsearch-base as a playground for developing this, as
> (for the moment) the units of the elasticsearch-base charm only need to
> know what units of an application exist when a unit joins or departs the
> relationship so it can update elasticsearch.yml and restart elasticsearch.
> I started out with a working implementation where all units of the
> application could know about eachother by updating the unitdata with their
> ip when they join, following which all units of the application grab the
> new unit data and update their configs. Where I am hitting contention is
> trying update the unitdata cache with the current data for all existing
> members when a unit departs the relationship. Basically a diff of what it
> was before. It sounds like what you've suggested, using
> context.Relations().peer might be the pre-existing functionality that
> you've written that I can use to derive the functionality I'm looking for.
>
> Heres what I've got going on now using the leader to do the coordinating
> to some degree... I feel like its becoming a hack fest though ... possibly
> you could take a look?
>
> https://github.com/jamesbeedy/juju-layer-elasticsearch-base/
> blob/use_master_for_member_add/reactive/elasticsearch_base.py#L126
> 
>

refresh_cache() is a worry.  Its a handler being run on the leader, but it
stores state locally. This state will be lost if the leader changes. The
only safe place for the leader to store state needed for leadership
decisions is leadership settings, because that is the only place it can be
found when a new leader is elected.




>
> I personally would not have found it useful, as when I've needed a peer
> relation I've needed a lot more than just knowing who the peers are and
> their addresses.
>
> - To this extent, possibly it would of made the path to what you were
> trying to accomplish a more pleasant experience if you had an api to access
> to the relational data for all of the units of its application type, and
> were able to just focus on what you were trying to do (looks like you have
> created context.Relations() specifically for this purpose)?
>

Yeah. The peer relation and the data on it is just the medium for the
protocol you are building (or some people prefer the term interface). The
context module was just my attempt at a Pythonic wrapper to the data
structure, so my implementation was more readable and maintainable.



>
> - This is very possibly exactly what I'm looking for. Does
> context.Relations().peer give you access to the relational data of your
> 'peer' in the context of Juju - such that a unit's only peer is the leader,
> and the leaders peers are all members that are not the leader? Or does this
> return relation data for all peers of the relation?
>

I don't think Juju has an idea of a unit's only peer being the leader and
the leader's peers being all the non-peer units. My understanding is that a
units peers are all the other units in the service/application, and it
doesn't matter if you are talking about the leader or not.

context.Relations().peer gives you access to the peer relation data of all
the other units in the application/service.



>
> and context.Relations().peer.local is a dictionary of the local peer
> relation data that you can update
>
> - Update with the information that context.Relations().peer returns? How
> is this different/better/worse then using leader to store the data, or unit
> data even? Because its data on the relation, which makes it fit the
> reactive model better/less cluttered?
>
> - I seem to be hitting an issue with layer leadership where only the
> leader is able to set data to the leader. Is this intended by design, or is
> this (what appears to be) a bug?
>

In Juju, only the leader can write to leadership settings by design.

If you want to use Juju leadership to coordinate operations over your units
(good idea - it works great), then the only reliable channel the leader has
to communicate with the other units is the leadership settings. If you try
to use the peer relation to communicate from the leader to the other units
then you will fail. This is because the leader can change, and the other
units have no way of knowing who is the leader (if they are not the leader,
the best they can tell is who *was* the leader - any information they get
about leadership may be out of date by the time they see it).

If your units need to communicate back to the leader or between each other,
the only channel they have to do so is the peer relation.

So, more practically using the leadership layer:

@when('leadership.is_leader')
@when_not('leadership.set.master')
def anoint_master():
leadership.leader_set(master=hookenv.local_unit())

@when('leadership.is_leader')
@when('leadership.set.master')
def maybe_failover():
master =

Re: Peers vs Members vs Terminology vs Usability

2017-01-30 Thread John Meinel 
>
> ...
>


> - Update with the information that context.Relations().peer returns? How
> is this different/better/worse then using leader to store the data, or unit
> data even? Because its data on the relation, which makes it fit the
> reactive model better/less cluttered?
>
> - I seem to be hitting an issue with layer leadership where only the
> leader is able to set data to the leader. Is this intended by design, or is
> this (what appears to be) a bug?
>

I don't know about the details of the leader, but I'd say that
"leader-data" is data set *by* the leader not *for* the leader.

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

Re: [charms] Incorrect Padding for SSL Cert/Key

2017-01-30 Thread Adam Collard 
On Sun, 29 Jan 2017 at 00:00 James Beedy  wrote:

> Ok, progress. I've encoded my cert and key to base64 strings and specified
> them in my haproxy config, and seem to be getting past the padding error.
> My issue now, is that I am not seeing the cert/key in /etc/ssl/private on
> the haproxy host once deployed. I'm thinking specifying the ssl cert/key
> will work for the Openstack charms now that I've got the encoding part
> squared away. Still stumped by haproxy though ... can't seem to get it
> provision the cert/key correctly for the life of me. Possibly there is
> something else I'm missing here ...
>

What version of the charm are you using? What Ubuntu series are you
deploying to?

I suspect you're missing the correct `services` config. There are tests for
the SSL termination feature of the charm in
`tests/12_deploy_{trusty,xenial}.py` perhaps these might shed some light on
the right invocation?


> On Sat, Jan 28, 2017 at 1:04 PM, James Beedy  wrote:
>
> I'm having issues with padding when trying to specify key/cert as config
> options for Haproxy, and have experienced the same issue in the past, when
> trying to specify key/cert for the Openstack charms. Could someone give an
> example of what the correct padding of a base64 encoded ssl cert might look
> like in the charm config yaml.
>
> My charm config looks like this -> http://paste.ubuntu.com/23882917/
>
> The error I'm getting is this -> http://paste.ubuntu.com/23882921/
>
> Thanks
>
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Request to join ~charmers

2017-01-30 Thread Konstantinos Tsakalozos 
+1. Welcome!

On Sat, Jan 28, 2017 at 4:56 PM, Cory Johns 
wrote:

> +1 from me as well
>
> On Jan 28, 2017 6:14 AM, "Merlijn Sebrechts" 
> wrote:
>
> An unofficial +1 from me, great work on the community!
>
>
> Op zaterdag 28 januari 2017 heeft Adam Israel 
> het volgende geschreven:
> > I am also a +1 for Pete joining ~charmers. He's put in consistent,
> thoughtful work towards making our community better.
> > On Sat, Jan 28, 2017 at 9:54 AM Marco Ceppi 
> wrote:
> >>
> >> I am a +1, I've reviewed a lot of Pete's work and he understands the
> core principals of charming and will make a fine addition.
> >> On Thu, Jan 26, 2017 at 11:01 AM Pete Vander Giessen <
> pete.vandergies...@canonical.com> wrote:
> >>>
> >>> Hi All,
> >>> I've been working with the Big Data team since May 2016, and have
> written or contributed to our charms (see https://github.com/juju-s
> olutions/bigtop), and layers (e.g. https://github.com/juju-
> solutions/layer-apache-bigtop-base), as well as to the matrix testing
> tool and cloud weather report. I also take a trip through the review queue
> with the team once a week, and would like to be able to finish up my
> positive reviews with a push to the charm store, when appropriate.
> >>> Thank you for considering me,
> >>> ~ PeteVG
> >>>
> >>> --
> >>> Juju mailing list
> >>> Juju@lists.ubuntu.com
> >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
> >>
> >> --
> >> Juju mailing list
> >> Juju@lists.ubuntu.com
> >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
> >
> > --
> > Adam Israel, Software Engineer
> > Canonical // Cloud DevOps // Juju // Ecosystem
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/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