Re: Docker task for teuthology

Re: Docker task for teuthology

[Ivo Jimenez]

Re-sending in plain text (original HTML message bounced)

----- Original Message ----- 
From: "Ivo Jimenez" <ivo@redhat.com> 
To: "Loic Dachary" <ldachary@redhat.com> 
Cc: ceph-devel@vger.kernel.org 
Sent: Wednesday, July 1, 2015 4:36:05 PM 
Subject: Docker task for teuthology 


Hi Loïc,

I’m a summer intern working at Red Hat on a project to bring non-functional testing to Ceph [1]. Zack mentioned that you worked on having teuthology use containers to deploy ceph and run tests. I found your blog posts and corresponding branches. Would it be possible for you to share your experience and the reason why you stopped working on that? Also, if you have time, could you please take a look at the initial code additions [2] that I’m working on? Any feedback would me much appreciated.

thanks! 

[1]: http://tracker.ceph.com/projects/ceph/wiki/Testing_-_non-functional_tests
[2]: https://github.com/ceph/teuthology/pull/558 

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Docker task for teuthology

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 2882 bytes --]

Hi,

On 02/07/2015 01:39, Ivo Jimenez wrote:> Re-sending in plain text (original HTML message bounced)
> 
> ----- Original Message ----- 
> From: "Ivo Jimenez" <ivo@redhat.com> 
> To: "Loic Dachary" <ldachary@redhat.com> 
> Cc: ceph-devel@vger.kernel.org 
> Sent: Wednesday, July 1, 2015 4:36:05 PM 
> Subject: Docker task for teuthology 
> 
> 
> Hi Loïc,
> 
> I’m a summer intern working at Red Hat on a project to bring non-functional testing to Ceph [1]. Zack mentioned that you worked on having teuthology use containers to deploy ceph and run tests. I found your blog posts and corresponding branches. Would it be possible for you to share your experience and the reason why you stopped working on that? 

I did not stop working on it :-) It has been something I worked on the side as a proof of concept and also to learn the teuthology code base. I've recently spent more time on having the OpenStack backend working for real ( http://tracker.ceph.com/issues/6502 ) which leads to a series of changes that will eventually make it easier to implement the Docker backend. The reason for focusing on the OpenStack backend is that it scales where the Docker Backend can only run so many instances.

> Also, if you have time, could you please take a look at the initial code additions [2] that I’m working on? Any feedback would me much appreciated.

I did not know about https://github.com/signalfuse/maestro-ng, sound really interesting ! How is it different from https://github.com/GoogleCloudPlatform/kubernetes or https://github.com/projectatomic or https://coreos.com/ ? I've no experience in any of them. 

You're going in a direction I did not think about: adding a task instead of modifying teuthology itself. It's an interesting route and maybe better than the one I took which is to modify the lock/provision files, mostly, to create OpenStack machines instead of Downburst machines. I'm very interested to know if that works out. Modifying the internals of teuthology is more complicated and if your method works, it's likely to be simpler.

I see you wrote tests which is much needed. I found that having integration tests is better than any kind of unit / functional testing because, in the end, most of teuthology work is to properly assemble and run bits and pieces that are external to it. In other words, without integration tests you cover only a fraction of the behavior even if you cover 100% of the LOC.

Cheers

> thanks! 
> 
> [1]: http://tracker.ceph.com/projects/ceph/wiki/Testing_-_non-functional_tests
> [2]: https://github.com/ceph/teuthology/pull/558 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Docker task for teuthology

[Ivo Jimenez]

Sorry Loic, I thought I had replied to your message.
 
> I did not know about https://github.com/signalfuse/maestro-ng, sound really
> interesting ! How is it different from
> https://github.com/GoogleCloudPlatform/kubernetes or
> https://github.com/projectatomic or https://coreos.com/ ? I've no experience
> in any of them.

maestro is very lightweight compared to kubernetes. kubernetes has monitoring/dashboard features (among many others) and requires an agent to be installed alongside the docker hosts. maestro communicates directly with the docker daemon, so it doesn't require any external dependencies/configuration. Neither of the two have deployment features. maestro's codebase is much more smaller and it's written in python (vs. golang for kubernetes).

coreos and projectatomic are Linux distros that provide "just enough operating system" (JeOS) and assume that all applications run in containerized form. There are projects that combine coreos and kubernetes (plus more infra) to turn a cluster into a PaaS. Deis is an example (which uses Ceph as its storage backend).
 
> You're going in a direction I did not think about: adding a task instead of
> modifying teuthology itself. It's an interesting route and maybe better than
> the one I took which is to modify the lock/provision files, mostly, to
> create OpenStack machines instead of Downburst machines. I'm very interested
> to know if that works out. Modifying the internals of teuthology is more
> complicated and if your method works, it's likely to be simpler.

Yes, the plan is to combine ansible+maestro to make it easier to run integration tests. My goal is to make it possible to run teuthology on a laptop

> 
> I see you wrote tests which is much needed. I found that having integration
> tests is better than any kind of unit / functional testing because, in the
> end, most of teuthology work is to properly assemble and run bits and pieces
> that are external to it. In other words, without integration tests you cover
> only a fraction of the behavior even if you cover 100% of the LOC.
> 
> Cheers

thanks!

Re: Docker task for teuthology

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 2778 bytes --]



On 07/07/2015 21:35, Ivo Jimenez wrote:
> Sorry Loic, I thought I had replied to your message.
>  
>> I did not know about https://github.com/signalfuse/maestro-ng, sound really
>> interesting ! How is it different from
>> https://github.com/GoogleCloudPlatform/kubernetes or
>> https://github.com/projectatomic or https://coreos.com/ ? I've no experience
>> in any of them.
> 
> maestro is very lightweight compared to kubernetes. kubernetes has monitoring/dashboard features (among many others) and requires an agent to be installed alongside the docker hosts. maestro communicates directly with the docker daemon, so it doesn't require any external dependencies/configuration. Neither of the two have deployment features. maestro's codebase is much more smaller and it's written in python (vs. golang for kubernetes).
> 
> coreos and projectatomic are Linux distros that provide "just enough operating system" (JeOS) and assume that all applications run in containerized form. There are projects that combine coreos and kubernetes (plus more infra) to turn a cluster into a PaaS. Deis is an example (which uses Ceph as its storage backend).
>  

Thanks for educating me :-) I was under the impression (100% unverified) that projectatomic competes with kubernetes in the sense that it knows and handles multiple machines, not just one.

Do you see OpenStack with docker instances more of a Deis competitor or a kubernetes / maestro competitor ? 

>> You're going in a direction I did not think about: adding a task instead of
>> modifying teuthology itself. It's an interesting route and maybe better than
>> the one I took which is to modify the lock/provision files, mostly, to
>> create OpenStack machines instead of Downburst machines. I'm very interested
>> to know if that works out. Modifying the internals of teuthology is more
>> complicated and if your method works, it's likely to be simpler.
> 
> Yes, the plan is to combine ansible+maestro to make it easier to run integration tests. My goal is to make it possible to run teuthology on a laptop
> 
>>
>> I see you wrote tests which is much needed. I found that having integration
>> tests is better than any kind of unit / functional testing because, in the
>> end, most of teuthology work is to properly assemble and run bits and pieces
>> that are external to it. In other words, without integration tests you cover
>> only a fraction of the behavior even if you cover 100% of the LOC.
>>
>> Cheers
> 
> thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]