Re: Immutable configuration best practices for charms

[Mark Shuttleworth]

On 12/12/16 12:01, Sandor Zeestraten wrote:
> How are you all dealing with immutable configurations when charming?
> I know that the best practices[1] say that charm configurations should
> not be immutable, however not all applications are created equally
> (see for example [2]).
> Anyone have any thoughts or ideas on how to deal with these issues
> where you have to lock down something when deploying?
>
> [1]
> https://jujucharms.com/docs/2.0/authors-charm-best-practice#juju-best-practices-and-tips-from-canonical's-infrastructure-team
> 
> [2] https://bugs.launchpad.net/charms/+source/nova-compute/+bug/1623679
>

The thinking is that we should declaratively identify config elements
which are immutable (i.e. cannot be changed after deploy). At the
moment, we are digging into config patterns at the single-node level
with snaps, and then we want to bring that thinking back to Juju for
"config 2.0" on applications at the cluster level.

Mark

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

Immutable configuration best practices for charms

[Sandor Zeestraten]

Hey folks,

How are you all dealing with immutable configurations when charming?
I know that the best practices[1] say that charm configurations should not
be immutable, however not all applications are created equally (see for
example [2]).
Anyone have any thoughts or ideas on how to deal with these issues where
you have to lock down something when deploying?

[1]
https://jujucharms.com/docs/2.0/authors-charm-best-practice#juju-best-practices-and-tips-from-canonical's-infrastructure-team
[2] https://bugs.launchpad.net/charms/+source/nova-compute/+bug/1623679

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

Re: What's with all the test talk? (aka, give me CI already)

[Mark Shuttleworth]

On 12/12/16 05:20, Charles Butler wrote:
> I think it would be best to reserve "auto publishing" to the edge
> channel. That's exactly what edge is for, to receive the latest builds
> from whatever process you are automating with the least amount of
> impact to existing installations.  From there it's simple to promote
> the charm through the channels.

In the snap world, that's where we've come to as well.

Mark

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

Re: What's with all the test talk? (aka, give me CI already)

[Charles Butler]

I think it would be best to reserve "auto publishing" to the edge channel.
That's exactly what edge is for, to receive the latest builds from whatever
process you are automating with the least amount of impact to existing
installations.  From there it's simple to promote the charm through the
channels.

This leaves the "lever pulling" to a manual process of a human once the
application has been properly vetted and QA'd. You could reasonably set
this up so edge is always possibly broken, but if the tests pass, it goes
into Beta/RC appropriately. (If you're installing from edge, you agree to
file bugs and deal with the shenanigans right?) Examples below:


charm release cs:~wethecharmers/mything-404 --channel=beta
and so on..


and of course, only push to --stable once you've verified that both
forward-looking upgrades work as expected, and it's so stable it's boring.

charm release cs:~wethecharmers/mything-404 --channel=stable

My 2 cents. All the best.


Charles


Charles Butler  - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com

On Mon, Dec 12, 2016 at 6:38 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> I'm just not sure what the best approach would be. My idea is that our CI
> system will push directly to stable. However, I think it's best if the
> charms are only pushed to stable when both the Charm tests and bundle tests
> succeed. So maybe after charm tests, the charms are pushed to edge, and
> when the bundle tests succeed both the bundles and the charms are pushed to
> stable?
>
> 2016-12-12 11:17 GMT+01:00 Konstantinos Tsakalozos <
> kos.tsakalo...@canonical.com>:
>
>> This workflow sounds reasonable. One question, why are you using only the
>> edge channel?
>>
>> Thanks
>>
>> On Fri, Dec 9, 2016 at 10:13 PM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> The workflow that we'd like to have is very similar to what you do with
>>> the charms. The first steps are already possible with `bundle-cwr-ci`:
>>>
>>>- If a new charm version is committed, run the tests of that charm.
>>>- If the tests succeed, push the charm to edge.
>>>
>>> We save our bundles on Github with revision-less charm urls. A push of a
>>> charm to the edge channel should trigger a job that does the ci for the
>>> bundle:
>>>
>>>- Add the latest revision to all revision-less charm urls. (If they
>>>do have a revision specified, leave them be.)
>>>- Run bundletester on the resulting bundle.
>>>- If tests succeed, push the bundle to edge.
>>>
>>> What do you think of this workflow?
>>>
>>> Our workflow in the past was a lot more complex, but moving to MAAS
>>> allowed us to greatly simplify it.
>>>
>>>
>>>
>>> 2016-12-09 5:33 GMT-05:00 Konstantinos Tsakalozos <
>>> kos.tsakalo...@canonical.com>:
>>>
 Hi Merlijn,

 Building/testing/releasing bundles from the CI is in our future tasks.

 Some time ago you posted on this list a script to update bundles in
 light of charm updates. We will have to take a closer look in the way
 bundles are handled in your case. Any feedback is much appreciated.

 Thanks,
 Konstantinos

 On Fri, Dec 9, 2016 at 4:52 AM, Merlijn Sebrechts <
 merlijn.sebrec...@gmail.com> wrote:

> This is awesome!
>
> >  I have a nasty habit of committing straight to master, so bear with
> us as development is moving fast at the moment.
>
> If only you could have a CI system to test your bundles
> automatically... ;)
>
> 2016-12-08 19:36 GMT-05:00, Kevin Monroe :
> > Hi Juju!
> >
> > From Matrix [0] to Review Queue [1] to Amulet [2] to Charm Author
> Workflows
> > [3], you'd think December was the month we all remembered the
> importance of
> > software testing.  There are oodles of test tools for
> charms/bundles, and
> > if you know about all of them, you're probably putting out
> thoughtful,
> > well-tested charms (thanks stub!).
> >
> > One thing that we've found missing is a nice charm CI/CD system that
> > leverages these tools to automatically give developers confidence in
> their
> > code and handle the release cycle from a source repo to the charm
> store,
> > soup to nuts.  Wouldn't it be nice if you could commit a charm
> update to
> > github and automatically have Cloud Weather Report kick off Jenkins
> jobs on
> > all your clouds, which in turn called Bundletester to handle
> deployment,
> > which in turn called Amulet and Matrix to run specific tests?
> Taking it a
> > step further, it'd be nice if that system could automatically push
> > charms/bundles to your edge channel (if their tests pass), and if
> you tag
> > source with a release tag, build/test/release it to your stable
> channel.
> >
> > This kind of system is what the Big Software team has been working on
> > recently, and we're open to

Re: What's with all the test talk? (aka, give me CI already)

[Merlijn Sebrechts]

I'm just not sure what the best approach would be. My idea is that our CI
system will push directly to stable. However, I think it's best if the
charms are only pushed to stable when both the Charm tests and bundle tests
succeed. So maybe after charm tests, the charms are pushed to edge, and
when the bundle tests succeed both the bundles and the charms are pushed to
stable?

2016-12-12 11:17 GMT+01:00 Konstantinos Tsakalozos <
kos.tsakalo...@canonical.com>:

> This workflow sounds reasonable. One question, why are you using only the
> edge channel?
>
> Thanks
>
> On Fri, Dec 9, 2016 at 10:13 PM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> The workflow that we'd like to have is very similar to what you do with
>> the charms. The first steps are already possible with `bundle-cwr-ci`:
>>
>>- If a new charm version is committed, run the tests of that charm.
>>- If the tests succeed, push the charm to edge.
>>
>> We save our bundles on Github with revision-less charm urls. A push of a
>> charm to the edge channel should trigger a job that does the ci for the
>> bundle:
>>
>>- Add the latest revision to all revision-less charm urls. (If they
>>do have a revision specified, leave them be.)
>>- Run bundletester on the resulting bundle.
>>- If tests succeed, push the bundle to edge.
>>
>> What do you think of this workflow?
>>
>> Our workflow in the past was a lot more complex, but moving to MAAS
>> allowed us to greatly simplify it.
>>
>>
>>
>> 2016-12-09 5:33 GMT-05:00 Konstantinos Tsakalozos <
>> kos.tsakalo...@canonical.com>:
>>
>>> Hi Merlijn,
>>>
>>> Building/testing/releasing bundles from the CI is in our future tasks.
>>>
>>> Some time ago you posted on this list a script to update bundles in
>>> light of charm updates. We will have to take a closer look in the way
>>> bundles are handled in your case. Any feedback is much appreciated.
>>>
>>> Thanks,
>>> Konstantinos
>>>
>>> On Fri, Dec 9, 2016 at 4:52 AM, Merlijn Sebrechts <
>>> merlijn.sebrec...@gmail.com> wrote:
>>>
 This is awesome!

 >  I have a nasty habit of committing straight to master, so bear with
 us as development is moving fast at the moment.

 If only you could have a CI system to test your bundles
 automatically... ;)

 2016-12-08 19:36 GMT-05:00, Kevin Monroe :
 > Hi Juju!
 >
 > From Matrix [0] to Review Queue [1] to Amulet [2] to Charm Author
 Workflows
 > [3], you'd think December was the month we all remembered the
 importance of
 > software testing.  There are oodles of test tools for charms/bundles,
 and
 > if you know about all of them, you're probably putting out thoughtful,
 > well-tested charms (thanks stub!).
 >
 > One thing that we've found missing is a nice charm CI/CD system that
 > leverages these tools to automatically give developers confidence in
 their
 > code and handle the release cycle from a source repo to the charm
 store,
 > soup to nuts.  Wouldn't it be nice if you could commit a charm update
 to
 > github and automatically have Cloud Weather Report kick off Jenkins
 jobs on
 > all your clouds, which in turn called Bundletester to handle
 deployment,
 > which in turn called Amulet and Matrix to run specific tests?  Taking
 it a
 > step further, it'd be nice if that system could automatically push
 > charms/bundles to your edge channel (if their tests pass), and if you
 tag
 > source with a release tag, build/test/release it to your stable
 channel.
 >
 > This kind of system is what the Big Software team has been working on
 > recently, and we're open to feedback!  Our goal is to deliver a
 system (as
 > a bundle) that answers the question, "how should I do CI/CD for my
 charms
 > and bundles?"  We're also working on a variation that includes the
 Review
 > Queue -- it will eventually become the brains behind
 > https://review.jujucharms.com and will be available for anyone
 wanting a
 > CI/CD + Source Review system in-house.
 >
 > If you're interested, development is happening at
 > https://github.com/juju-solutions/bundle-cwr-ci.  Have a look at the
 readme
 > for more details and let us know what you think.  The bundle yaml
 files are
 > currently deployable, buy I have a nasty habit of committing straight
 to
 > master, so bear with us as development is moving fast at the moment.
 Watch
 > this space for updates on our progress.
 >
 > [0] - https://lists.ubuntu.com/archives/juju/2016-December/008260.
 html
 > [1] - https://lists.ubuntu.com/archives/juju/2016-December/008287.
 html
 > [2] - https://lists.ubuntu.com/archives/juju/2016-December/008288.
 html
 > [3] - https://lists.ubuntu.com/archives/juju/2016-December/008302.
 html
 >
 > Thanks!
 > --
 > Kevin Monroe
 >

>>

Re: What's with all the test talk? (aka, give me CI already)

[Konstantinos Tsakalozos]

This workflow sounds reasonable. One question, why are you using only the
edge channel?

Thanks

On Fri, Dec 9, 2016 at 10:13 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> The workflow that we'd like to have is very similar to what you do with
> the charms. The first steps are already possible with `bundle-cwr-ci`:
>
>- If a new charm version is committed, run the tests of that charm.
>- If the tests succeed, push the charm to edge.
>
> We save our bundles on Github with revision-less charm urls. A push of a
> charm to the edge channel should trigger a job that does the ci for the
> bundle:
>
>- Add the latest revision to all revision-less charm urls. (If they do
>have a revision specified, leave them be.)
>- Run bundletester on the resulting bundle.
>- If tests succeed, push the bundle to edge.
>
> What do you think of this workflow?
>
> Our workflow in the past was a lot more complex, but moving to MAAS
> allowed us to greatly simplify it.
>
>
>
> 2016-12-09 5:33 GMT-05:00 Konstantinos Tsakalozos <
> kos.tsakalo...@canonical.com>:
>
>> Hi Merlijn,
>>
>> Building/testing/releasing bundles from the CI is in our future tasks.
>>
>> Some time ago you posted on this list a script to update bundles in light
>> of charm updates. We will have to take a closer look in the way bundles are
>> handled in your case. Any feedback is much appreciated.
>>
>> Thanks,
>> Konstantinos
>>
>> On Fri, Dec 9, 2016 at 4:52 AM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> This is awesome!
>>>
>>> >  I have a nasty habit of committing straight to master, so bear with
>>> us as development is moving fast at the moment.
>>>
>>> If only you could have a CI system to test your bundles automatically...
>>> ;)
>>>
>>> 2016-12-08 19:36 GMT-05:00, Kevin Monroe :
>>> > Hi Juju!
>>> >
>>> > From Matrix [0] to Review Queue [1] to Amulet [2] to Charm Author
>>> Workflows
>>> > [3], you'd think December was the month we all remembered the
>>> importance of
>>> > software testing.  There are oodles of test tools for charms/bundles,
>>> and
>>> > if you know about all of them, you're probably putting out thoughtful,
>>> > well-tested charms (thanks stub!).
>>> >
>>> > One thing that we've found missing is a nice charm CI/CD system that
>>> > leverages these tools to automatically give developers confidence in
>>> their
>>> > code and handle the release cycle from a source repo to the charm
>>> store,
>>> > soup to nuts.  Wouldn't it be nice if you could commit a charm update
>>> to
>>> > github and automatically have Cloud Weather Report kick off Jenkins
>>> jobs on
>>> > all your clouds, which in turn called Bundletester to handle
>>> deployment,
>>> > which in turn called Amulet and Matrix to run specific tests?  Taking
>>> it a
>>> > step further, it'd be nice if that system could automatically push
>>> > charms/bundles to your edge channel (if their tests pass), and if you
>>> tag
>>> > source with a release tag, build/test/release it to your stable
>>> channel.
>>> >
>>> > This kind of system is what the Big Software team has been working on
>>> > recently, and we're open to feedback!  Our goal is to deliver a system
>>> (as
>>> > a bundle) that answers the question, "how should I do CI/CD for my
>>> charms
>>> > and bundles?"  We're also working on a variation that includes the
>>> Review
>>> > Queue -- it will eventually become the brains behind
>>> > https://review.jujucharms.com and will be available for anyone
>>> wanting a
>>> > CI/CD + Source Review system in-house.
>>> >
>>> > If you're interested, development is happening at
>>> > https://github.com/juju-solutions/bundle-cwr-ci.  Have a look at the
>>> readme
>>> > for more details and let us know what you think.  The bundle yaml
>>> files are
>>> > currently deployable, buy I have a nasty habit of committing straight
>>> to
>>> > master, so bear with us as development is moving fast at the moment.
>>> Watch
>>> > this space for updates on our progress.
>>> >
>>> > [0] - https://lists.ubuntu.com/archives/juju/2016-December/008260.html
>>> > [1] - https://lists.ubuntu.com/archives/juju/2016-December/008287.html
>>> > [2] - https://lists.ubuntu.com/archives/juju/2016-December/008288.html
>>> > [3] - https://lists.ubuntu.com/archives/juju/2016-December/008302.html
>>> >
>>> > Thanks!
>>> > --
>>> > Kevin Monroe
>>> >
>>>
>>> --
>>> 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