cf-charmers team mailing list archive

[Alexander Lomov <lomov.as@xxxxxxxxx>]

This makes sense. I guess we will start to work on it today-tomorrow.
Thank you for answering, Kapil.


On 15 April 2014 02:04, Kapil Thangavelu <kapil.thangavelu@xxxxxxxxxxxxx>wrote:

>
>
>
> On Mon, Apr 14, 2014 at 4:42 PM, Alexander Lomov <lomov.as@xxxxxxxxx>wrote:
>
>> Hey, all.
>>
>> Since we need to implement deployment DEA to local environment and I'm
>> not sure that I see problem clearly, I'd like to start discussion of this
>> topic.
>>
>> 1. First question for me is:
>> Is it worth to try to deploy DEA into juju kvm local environment? I mean
>> something like approach described in this article:
>> http://astokes.org/juju-deploy-to-lxc-and-kvm-in-the-local-provider/.
>> Deploying to kvm can solve this issue.
>>
>
> yes, that article describes the technique to use for containers for most
> things, and kvm just for the dea, that's a good workflow and can be
> captured into a deployer config as well  (to: kvm:0)
>
> make sure to install uvtool package for the kvm support.
>
>
>> 2. Strategy to solve LXC/Warden problem:
>> We can perform following steps in order to solve this issue:
>>         a. create lxc container
>>         b. deploy Warden to it
>>         c .try to create Warden container using warden shell
>>         d. after that we will change configuration step by step depending
>> on errors we will get.
>>
>> It will require us to change default LXC settings, so we will need to
>> provide user of juju charms with list of changes to LXC settings.
>> Is it OK for now to make user change his defaults?
>> What do you think about strategy for solving this task?
>> What are your suggestions on this point?
>>
>>
> for now go with #1 (it works and can be captured to bundle), when local
> provider has app armor profiles configurable for lxc we can consider
> debugging #2.
>
> cheers,
>
> Kapil
>