Juju state as code?

[Patrik Karisch]

Hi there,

one thing which mocks my head, when evaluating Juju is, the state is only
in the controller which gets deployed with commands. Which means I have
IMHO no docs/history of how my current state of machines and charms was
constructed?

As a side note: I'm used to Ansible and Puppet, which means I have all my
infrastructe in a Git repository which describes my whole infrastructure
and works always in a reproducable and idempotent way. How can I map this
concept to Juju? I fear a little bit to loose this automation concept while
using Juju.

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

Re: Any mentor for adding a new provider available?

[Patrik Karisch]

Hi Katherine,

already read those docs and also the source of other providers.

I need someone who says, start with writing and testing the eviron or the
config file first and stuff. And how I can verify all my steps in an actual
staging system on DigitalOcean.

Cheers,
Patrik

Katherine Cox-Buday <katherine.cox-bu...@canonical.com> schrieb am Mo., 1.
Aug. 2016 um 18:19 Uhr:

>
> Hey Patrik,
>
> Have a look at this[1] wiki page and see if it doesn't provide what you
> need.
>
> We'll make every effort to support you during development it, and we'll
> want to make sure that Wiki page is updated to fill in any gaps you might
> find.
>
> You might also find the document on contributing[2] helpful as well.
>
> Good luck, and welcome!
>
> [1] - https://github.com/juju/juju/wiki/Implementing-environment-providers
> [2] - https://github.com/juju/juju/blob/master/CONTRIBUTING.md
>
> Marco Ceppi <marco.ce...@canonical.com> writes:
>
> > Hi Patrik,
> >
> > This would be a great and welcomed addition. I'm adding the juju-dev
> > mailing list to this thread as that is where most the Juju Core
> > development happens.
> >
> > Marco
> >
> > On Mon, Aug 1, 2016, 6:23 AM Patrik Karisch <patrik.kari...@gmail.com>
> > wrote:
> >
> > Hi there,
> >
> >
> > I want to add DigitalOcean as a new provider to Juju, but as I'm
> > not Go experienced and new to the architecture of Juju, I'm
> > searching for a mentor who gives me directions on what to do
> > first/next and sometimes do code review. Anyone here? :)
> >
> >
> > Cheers
> > Patrik
> > --
> > Juju mailing list
> > Juju@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju
>
> --
> Katherine
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Any mentor for adding a new provider available?

[Patrik Karisch]

Hi there,

I want to add DigitalOcean as a new provider to Juju, but as I'm not Go
experienced and new to the architecture of Juju, I'm searching for a mentor
who gives me directions on what to do first/next and sometimes do code
review. Anyone here? :)

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

Semver instead of revisions for charms?

[Patrik Karisch]

Hi,

is there any plan to implement semantic versioning for charms and step away
from revisions which can't indicate major BC breaks compared to a major
release with semver?

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

Re: Deprecating charm config options: postgresql case

[Patrik Karisch]

Hi Andreas,

deprecated but do nothing is IMHO a BC break. A deprecation is only useful
if it does it's behavior (but overwritten by the new configuration) until
it is removed.

Sadly revisions are not a useful versioning scheme. Would be cool if juju
can adapt semantic versioning, so a charm can deprecate options, use it in
1.x versions and remove it in 2.x versions. Juju would not update a charm
over a major version until it is told so.

Andreas Hasenack  schrieb am Do., 14. Jan. 2016 um
20:01 Uhr:

> TL;DR
> Should charms a) remove deprecated options; b) accept them but do nothing
> (the case below); c) accept them for a while, log a warning, then remove;
> d) ?
>
> Hi,
>
> Recently the postgresql charm deprecated several config options. For
> example:
>
>   max_connections:
> default: 100
> type: int
> description: >
> DEPRECATED. Use extra_pg_conf.
> Maximum number of connections to allow to the PG database
>
> The option still exists and can be set, but does nothing. The service will
> get whatever is set in the new extra_pg_conf option, which happens to be
> 100.
>
> I believe the intent of this behaviour was to not break the deployment of
> the charm using existing configuration files. But instead it introduces a
> subtle breakage: my DB can now only handle 100 connections, whereas before
> it was (in my case) 500. The deployment works, but the system doesn't
> behave as before and eventually breaks under use. That lead to some
> debugging until this was found:
>
> psycopg2.OperationalError: FATAL:  remaining connection slots are reserved
> for non-replication superuser connections
>
> Other deprecated options have a more explicit warning:
>
>   performance_tuning:
> default: "Mixed"
> type: string
> description: >
> DEPRECATED AND IGNORED. The pgtune project has been abandoned
> and the packages dropped from Debian and Ubuntu. The charm
> still performs some basic tuning, which users can tweak using
> extra_pg_config.
>
> In this specific postgresql case, looks like all (I just tested two, btw)
> deprecated options should have been marked with the extra "... AND IGNORED"
> text. But then again, is it worth it to silently accept them and do
> nothing, thereby introducing subtle run-time failures?
>
>
> --
> 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

Charm for webapp with webserver or not?

[Patrik Karisch]

Hi all,

if I create a charm for my webapp, should it already install the webserver
or should it only provide a interface as subordinate for e.g. the apache2
charm? In the first case, each webapp must be run in separate containers as
a minimum.. But I think scaling up is much easier, because it provides the
server. What do you think?

Another unclear point for me. If I use the apache2 charm with
apache2-reverseproxy subordinate to proxy different webapps (everyone in
it's own LXC container) on the same host, is it easy to remove the
reverseproxy subordinate charm to deactivate the webapp easily?

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

Re: Charm for webapp with webserver or not?

[Patrik Karisch]

Hi Marco,

seems the best way to do so. Better supply my correct configuration of
nginx and php-fpm instead relying on another charm. Pro: My webapp charm
can specialize all config params.

I've read the charm layers already and they seem interesting to build
different webapps. Although I must read more how my charm can adapt config
stuff from the layer and create one a layer for my nginx/php needs. And I
have to research in which languages I can use the reactive pattern, because
I don't know Python :)

Thanks,
Patrik

Marco Ceppi <marco.ce...@canonical.com> schrieb am Mo., 4. Jan. 2016 um
15:13 Uhr:

> Hi Patrik,
>
> It's best to think of the charm as an entire solution for the
> application/component your deploying. So if you need a web server to make
> this solution complete, it's best to include it. There are some exceptions
> to this, but generally speaking it's the rule of thumb.
>
> If you're looking to avoid re-implementing logic for apache2, or other
> common components, then I'd suggesting taking a look at charm layers. Charm
> layers give the same concept of composition as juju does with services, but
> at the charm creation level.
> https://jujucharms.com/docs/stable/authors-charm-building these are some
> early docs and we'll have a fully rewritten author docs around charm layers
> up in a week or so.
>
> Marco
>
> On Mon, Jan 4, 2016 at 6:54 AM Patrik Karisch <patrik.kari...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> if I create a charm for my webapp, should it already install the
>> webserver or should it only provide a interface as subordinate for e.g. the
>> apache2 charm? In the first case, each webapp must be run in separate
>> containers as a minimum.. But I think scaling up is much easier, because it
>> provides the server. What do you think?
>>
>> Another unclear point for me. If I use the apache2 charm with
>> apache2-reverseproxy subordinate to proxy different webapps (everyone in
>> it's own LXC container) on the same host, is it easy to remove the
>> reverseproxy subordinate charm to deactivate the webapp easily?
>>
>> Best regards
>> Patrik
>>
> --
>> 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