You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Tomek Janiszewski <ja...@gmail.com> on 2016/04/24 22:34:29 UTC
Looking for Shepherd for MESOS-5263
Hi,
Can anyone shepherd https://issues.apache.org/jira/browse/MESOS-5263?
It's similar to https://issues.apache.org/jira/browse/MESOS-5121 and could
be resolved in the same manner or it could be done in a way that'll support
other platforms as well.
Thanks
Tomek
Re: Looking for Shepherd for MESOS-5263
Posted by Benjamin Mahler <bm...@apache.org>.
Didn't see your email until now, but just to update the list this was
committed.
On Fri, May 6, 2016 at 9:14 AM, haosdent <ha...@gmail.com> wrote:
> ping @ben and @vinodkone, would you like to review this patch again?
>
> On Wed, Apr 27, 2016 at 7:22 PM, haosdent <ha...@gmail.com> wrote:
>
>> Already left my comments on it, thank you for your patch!
>>
>> On Wed, Apr 27, 2016 at 5:52 PM, Tomek Janiszewski <ja...@gmail.com>
>> wrote:
>>
>>> Hi
>>>
>>> I prepared cleanup https://reviews.apache.org/r/46730/
>>> @Haosdent can you check it?
>>>
>>> Best
>>> Tomek
>>>
>>> śr., 27.04.2016 o 04:03 użytkownik haosdent <ha...@gmail.com>
>>> napisał:
>>>
>>> > Hi, @bmahler, thank you so much for review it! As the email I sent
>>> > to @idownes and @chenzhiwei, we could drop that safely by adding
>>> >
>>> > ```
>>> > #include <linux/unistd.h>
>>> > ```
>>> >
>>> > from @RobinDong's patch.
>>> >
>>> > Because this header file comes from kernel headers and it include
>>> machine
>>> > specific syscall numbers no matter which CPU architecture used.
>>> >
>>> > On the other hand, we can not use
>>> >
>>> > ```
>>> > #include <unistd.h>
>>> > #include <sys/syscall.h>
>>> > ```
>>> >
>>> > as the source of the syscall numbers because these header files come
>>> from
>>> > glibc.
>>> >
>>> > ```
>>> > $ rpm -qf /usr/include/sys/syscall.h
>>> > glibc-headers-2.12-1.149.el6_6.5.x86_64
>>> > $ rpm -qf /usr/include/unistd.h
>>> > glibc-headers-2.12-1.149.el6_6.5.x86_64
>>> > ```
>>> >
>>> > If use them, would fall into the problem @idownes mentioned in
>>> > `linux/ns.hpp` (Old glibc library and new kernel)
>>> >
>>> > ```
>>> > #ifdef SYS_setns
>>> > int ret = ::syscall(SYS_setns, fd.get(), nstype.get());
>>> > #elif __x86_64__
>>> > // A workaround for those hosts that have an old glibc (older than
>>> > // 2.14) but have a new kernel. The magic number '308' here is the
>>> > // syscall number for 'setns' on x86_64 architecture.
>>> > int ret = ::syscall(308, fd.get(), nstype.get());
>>> > #else
>>> > #error "setns is not available"
>>> > #endif
>>> > ```
>>> >
>>> > I verify `#include <linux/unistd.h>` works on CentOS 6.5, CentOS 7.2
>>> Ubuntu
>>> > 14.04 with X86 and Debian jessie with ARM. In code level, I verify it
>>> works
>>> > on all architectures I know [
>>> > http://lxr.free-electrons.com/ident?v=3.8;i=__NR_pivot_root] .
>>> >
>>> > @BingLi would like to port Mesos works on System Z, and he blocked by
>>> > `__NR_pivot_root ` (https://issues.apache.org/jira/browse/MESOS-5242)
>>> as
>>> > well. As he commented in ticket, `#include <linux/unistd.h>` could
>>> solve
>>> > the problem as well.
>>> >
>>> >
>>> > Appendix[The verify program]:
>>> >
>>> > ```
>>> > #include <linux/unistd.h>
>>> > #include <iostream>
>>> >
>>> > int main(int argc, char const *argv[])
>>> > {
>>> > std::cout << __NR_pivot_root << std::endl;
>>> > return 0;
>>> > }
>>> > ```
>>> >
>>> >
>>> > On Wed, Apr 27, 2016 at 3:24 AM, Benjamin Mahler <bm...@apache.org>
>>> > wrote:
>>> >
>>> > > Looks like Vinod shipped MESOS-5121. I just shipped MESOS-5263
>>> following
>>> > > the same approach.
>>> > >
>>> > > Haosdent mentioned some cleanups are possible here so please keep us
>>> > > posted if the cleanups are available!
>>> > >
>>> > > On Sun, Apr 24, 2016 at 1:34 PM, Tomek Janiszewski <
>>> janiszt@gmail.com>
>>> > > wrote:
>>> > >
>>> > >> Hi,
>>> > >>
>>> > >> Can anyone shepherd
>>> https://issues.apache.org/jira/browse/MESOS-5263?
>>> > >> It's similar to https://issues.apache.org/jira/browse/MESOS-5121
>>> and
>>> > >> could
>>> > >> be resolved in the same manner or it could be done in a way that'll
>>> > >> support
>>> > >> other platforms as well.
>>> > >>
>>> > >> Thanks
>>> > >> Tomek
>>> > >>
>>> > >
>>> > >
>>> >
>>> >
>>> > --
>>> > Best Regards,
>>> > Haosdent Huang
>>> >
>>>
>>
>>
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>
Re: Looking for Shepherd for MESOS-5263
Posted by haosdent <ha...@gmail.com>.
ping @ben and @vinodkone, would you like to review this patch again?
On Wed, Apr 27, 2016 at 7:22 PM, haosdent <ha...@gmail.com> wrote:
> Already left my comments on it, thank you for your patch!
>
> On Wed, Apr 27, 2016 at 5:52 PM, Tomek Janiszewski <ja...@gmail.com>
> wrote:
>
>> Hi
>>
>> I prepared cleanup https://reviews.apache.org/r/46730/
>> @Haosdent can you check it?
>>
>> Best
>> Tomek
>>
>> śr., 27.04.2016 o 04:03 użytkownik haosdent <ha...@gmail.com> napisał:
>>
>> > Hi, @bmahler, thank you so much for review it! As the email I sent
>> > to @idownes and @chenzhiwei, we could drop that safely by adding
>> >
>> > ```
>> > #include <linux/unistd.h>
>> > ```
>> >
>> > from @RobinDong's patch.
>> >
>> > Because this header file comes from kernel headers and it include
>> machine
>> > specific syscall numbers no matter which CPU architecture used.
>> >
>> > On the other hand, we can not use
>> >
>> > ```
>> > #include <unistd.h>
>> > #include <sys/syscall.h>
>> > ```
>> >
>> > as the source of the syscall numbers because these header files come
>> from
>> > glibc.
>> >
>> > ```
>> > $ rpm -qf /usr/include/sys/syscall.h
>> > glibc-headers-2.12-1.149.el6_6.5.x86_64
>> > $ rpm -qf /usr/include/unistd.h
>> > glibc-headers-2.12-1.149.el6_6.5.x86_64
>> > ```
>> >
>> > If use them, would fall into the problem @idownes mentioned in
>> > `linux/ns.hpp` (Old glibc library and new kernel)
>> >
>> > ```
>> > #ifdef SYS_setns
>> > int ret = ::syscall(SYS_setns, fd.get(), nstype.get());
>> > #elif __x86_64__
>> > // A workaround for those hosts that have an old glibc (older than
>> > // 2.14) but have a new kernel. The magic number '308' here is the
>> > // syscall number for 'setns' on x86_64 architecture.
>> > int ret = ::syscall(308, fd.get(), nstype.get());
>> > #else
>> > #error "setns is not available"
>> > #endif
>> > ```
>> >
>> > I verify `#include <linux/unistd.h>` works on CentOS 6.5, CentOS 7.2
>> Ubuntu
>> > 14.04 with X86 and Debian jessie with ARM. In code level, I verify it
>> works
>> > on all architectures I know [
>> > http://lxr.free-electrons.com/ident?v=3.8;i=__NR_pivot_root] .
>> >
>> > @BingLi would like to port Mesos works on System Z, and he blocked by
>> > `__NR_pivot_root ` (https://issues.apache.org/jira/browse/MESOS-5242)
>> as
>> > well. As he commented in ticket, `#include <linux/unistd.h>` could solve
>> > the problem as well.
>> >
>> >
>> > Appendix[The verify program]:
>> >
>> > ```
>> > #include <linux/unistd.h>
>> > #include <iostream>
>> >
>> > int main(int argc, char const *argv[])
>> > {
>> > std::cout << __NR_pivot_root << std::endl;
>> > return 0;
>> > }
>> > ```
>> >
>> >
>> > On Wed, Apr 27, 2016 at 3:24 AM, Benjamin Mahler <bm...@apache.org>
>> > wrote:
>> >
>> > > Looks like Vinod shipped MESOS-5121. I just shipped MESOS-5263
>> following
>> > > the same approach.
>> > >
>> > > Haosdent mentioned some cleanups are possible here so please keep us
>> > > posted if the cleanups are available!
>> > >
>> > > On Sun, Apr 24, 2016 at 1:34 PM, Tomek Janiszewski <janiszt@gmail.com
>> >
>> > > wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> Can anyone shepherd https://issues.apache.org/jira/browse/MESOS-5263
>> ?
>> > >> It's similar to https://issues.apache.org/jira/browse/MESOS-5121 and
>> > >> could
>> > >> be resolved in the same manner or it could be done in a way that'll
>> > >> support
>> > >> other platforms as well.
>> > >>
>> > >> Thanks
>> > >> Tomek
>> > >>
>> > >
>> > >
>> >
>> >
>> > --
>> > Best Regards,
>> > Haosdent Huang
>> >
>>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>
--
Best Regards,
Haosdent Huang
Re: Looking for Shepherd for MESOS-5263
Posted by haosdent <ha...@gmail.com>.
Already left my comments on it, thank you for your patch!
On Wed, Apr 27, 2016 at 5:52 PM, Tomek Janiszewski <ja...@gmail.com>
wrote:
> Hi
>
> I prepared cleanup https://reviews.apache.org/r/46730/
> @Haosdent can you check it?
>
> Best
> Tomek
>
> śr., 27.04.2016 o 04:03 użytkownik haosdent <ha...@gmail.com> napisał:
>
> > Hi, @bmahler, thank you so much for review it! As the email I sent
> > to @idownes and @chenzhiwei, we could drop that safely by adding
> >
> > ```
> > #include <linux/unistd.h>
> > ```
> >
> > from @RobinDong's patch.
> >
> > Because this header file comes from kernel headers and it include machine
> > specific syscall numbers no matter which CPU architecture used.
> >
> > On the other hand, we can not use
> >
> > ```
> > #include <unistd.h>
> > #include <sys/syscall.h>
> > ```
> >
> > as the source of the syscall numbers because these header files come from
> > glibc.
> >
> > ```
> > $ rpm -qf /usr/include/sys/syscall.h
> > glibc-headers-2.12-1.149.el6_6.5.x86_64
> > $ rpm -qf /usr/include/unistd.h
> > glibc-headers-2.12-1.149.el6_6.5.x86_64
> > ```
> >
> > If use them, would fall into the problem @idownes mentioned in
> > `linux/ns.hpp` (Old glibc library and new kernel)
> >
> > ```
> > #ifdef SYS_setns
> > int ret = ::syscall(SYS_setns, fd.get(), nstype.get());
> > #elif __x86_64__
> > // A workaround for those hosts that have an old glibc (older than
> > // 2.14) but have a new kernel. The magic number '308' here is the
> > // syscall number for 'setns' on x86_64 architecture.
> > int ret = ::syscall(308, fd.get(), nstype.get());
> > #else
> > #error "setns is not available"
> > #endif
> > ```
> >
> > I verify `#include <linux/unistd.h>` works on CentOS 6.5, CentOS 7.2
> Ubuntu
> > 14.04 with X86 and Debian jessie with ARM. In code level, I verify it
> works
> > on all architectures I know [
> > http://lxr.free-electrons.com/ident?v=3.8;i=__NR_pivot_root] .
> >
> > @BingLi would like to port Mesos works on System Z, and he blocked by
> > `__NR_pivot_root ` (https://issues.apache.org/jira/browse/MESOS-5242) as
> > well. As he commented in ticket, `#include <linux/unistd.h>` could solve
> > the problem as well.
> >
> >
> > Appendix[The verify program]:
> >
> > ```
> > #include <linux/unistd.h>
> > #include <iostream>
> >
> > int main(int argc, char const *argv[])
> > {
> > std::cout << __NR_pivot_root << std::endl;
> > return 0;
> > }
> > ```
> >
> >
> > On Wed, Apr 27, 2016 at 3:24 AM, Benjamin Mahler <bm...@apache.org>
> > wrote:
> >
> > > Looks like Vinod shipped MESOS-5121. I just shipped MESOS-5263
> following
> > > the same approach.
> > >
> > > Haosdent mentioned some cleanups are possible here so please keep us
> > > posted if the cleanups are available!
> > >
> > > On Sun, Apr 24, 2016 at 1:34 PM, Tomek Janiszewski <ja...@gmail.com>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> Can anyone shepherd https://issues.apache.org/jira/browse/MESOS-5263?
> > >> It's similar to https://issues.apache.org/jira/browse/MESOS-5121 and
> > >> could
> > >> be resolved in the same manner or it could be done in a way that'll
> > >> support
> > >> other platforms as well.
> > >>
> > >> Thanks
> > >> Tomek
> > >>
> > >
> > >
> >
> >
> > --
> > Best Regards,
> > Haosdent Huang
> >
>
--
Best Regards,
Haosdent Huang
Re: Looking for Shepherd for MESOS-5263
Posted by Tomek Janiszewski <ja...@gmail.com>.
Hi
I prepared cleanup https://reviews.apache.org/r/46730/
@Haosdent can you check it?
Best
Tomek
śr., 27.04.2016 o 04:03 użytkownik haosdent <ha...@gmail.com> napisał:
> Hi, @bmahler, thank you so much for review it! As the email I sent
> to @idownes and @chenzhiwei, we could drop that safely by adding
>
> ```
> #include <linux/unistd.h>
> ```
>
> from @RobinDong's patch.
>
> Because this header file comes from kernel headers and it include machine
> specific syscall numbers no matter which CPU architecture used.
>
> On the other hand, we can not use
>
> ```
> #include <unistd.h>
> #include <sys/syscall.h>
> ```
>
> as the source of the syscall numbers because these header files come from
> glibc.
>
> ```
> $ rpm -qf /usr/include/sys/syscall.h
> glibc-headers-2.12-1.149.el6_6.5.x86_64
> $ rpm -qf /usr/include/unistd.h
> glibc-headers-2.12-1.149.el6_6.5.x86_64
> ```
>
> If use them, would fall into the problem @idownes mentioned in
> `linux/ns.hpp` (Old glibc library and new kernel)
>
> ```
> #ifdef SYS_setns
> int ret = ::syscall(SYS_setns, fd.get(), nstype.get());
> #elif __x86_64__
> // A workaround for those hosts that have an old glibc (older than
> // 2.14) but have a new kernel. The magic number '308' here is the
> // syscall number for 'setns' on x86_64 architecture.
> int ret = ::syscall(308, fd.get(), nstype.get());
> #else
> #error "setns is not available"
> #endif
> ```
>
> I verify `#include <linux/unistd.h>` works on CentOS 6.5, CentOS 7.2 Ubuntu
> 14.04 with X86 and Debian jessie with ARM. In code level, I verify it works
> on all architectures I know [
> http://lxr.free-electrons.com/ident?v=3.8;i=__NR_pivot_root] .
>
> @BingLi would like to port Mesos works on System Z, and he blocked by
> `__NR_pivot_root ` (https://issues.apache.org/jira/browse/MESOS-5242) as
> well. As he commented in ticket, `#include <linux/unistd.h>` could solve
> the problem as well.
>
>
> Appendix[The verify program]:
>
> ```
> #include <linux/unistd.h>
> #include <iostream>
>
> int main(int argc, char const *argv[])
> {
> std::cout << __NR_pivot_root << std::endl;
> return 0;
> }
> ```
>
>
> On Wed, Apr 27, 2016 at 3:24 AM, Benjamin Mahler <bm...@apache.org>
> wrote:
>
> > Looks like Vinod shipped MESOS-5121. I just shipped MESOS-5263 following
> > the same approach.
> >
> > Haosdent mentioned some cleanups are possible here so please keep us
> > posted if the cleanups are available!
> >
> > On Sun, Apr 24, 2016 at 1:34 PM, Tomek Janiszewski <ja...@gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> Can anyone shepherd https://issues.apache.org/jira/browse/MESOS-5263?
> >> It's similar to https://issues.apache.org/jira/browse/MESOS-5121 and
> >> could
> >> be resolved in the same manner or it could be done in a way that'll
> >> support
> >> other platforms as well.
> >>
> >> Thanks
> >> Tomek
> >>
> >
> >
>
>
> --
> Best Regards,
> Haosdent Huang
>
Re: Looking for Shepherd for MESOS-5263
Posted by haosdent <ha...@gmail.com>.
Hi, @bmahler, thank you so much for review it! As the email I sent
to @idownes and @chenzhiwei, we could drop that safely by adding
```
#include <linux/unistd.h>
```
from @RobinDong's patch.
Because this header file comes from kernel headers and it include machine
specific syscall numbers no matter which CPU architecture used.
On the other hand, we can not use
```
#include <unistd.h>
#include <sys/syscall.h>
```
as the source of the syscall numbers because these header files come from
glibc.
```
$ rpm -qf /usr/include/sys/syscall.h
glibc-headers-2.12-1.149.el6_6.5.x86_64
$ rpm -qf /usr/include/unistd.h
glibc-headers-2.12-1.149.el6_6.5.x86_64
```
If use them, would fall into the problem @idownes mentioned in
`linux/ns.hpp` (Old glibc library and new kernel)
```
#ifdef SYS_setns
int ret = ::syscall(SYS_setns, fd.get(), nstype.get());
#elif __x86_64__
// A workaround for those hosts that have an old glibc (older than
// 2.14) but have a new kernel. The magic number '308' here is the
// syscall number for 'setns' on x86_64 architecture.
int ret = ::syscall(308, fd.get(), nstype.get());
#else
#error "setns is not available"
#endif
```
I verify `#include <linux/unistd.h>` works on CentOS 6.5, CentOS 7.2 Ubuntu
14.04 with X86 and Debian jessie with ARM. In code level, I verify it works
on all architectures I know [
http://lxr.free-electrons.com/ident?v=3.8;i=__NR_pivot_root] .
@BingLi would like to port Mesos works on System Z, and he blocked by
`__NR_pivot_root ` (https://issues.apache.org/jira/browse/MESOS-5242) as
well. As he commented in ticket, `#include <linux/unistd.h>` could solve
the problem as well.
Appendix[The verify program]:
```
#include <linux/unistd.h>
#include <iostream>
int main(int argc, char const *argv[])
{
std::cout << __NR_pivot_root << std::endl;
return 0;
}
```
On Wed, Apr 27, 2016 at 3:24 AM, Benjamin Mahler <bm...@apache.org> wrote:
> Looks like Vinod shipped MESOS-5121. I just shipped MESOS-5263 following
> the same approach.
>
> Haosdent mentioned some cleanups are possible here so please keep us
> posted if the cleanups are available!
>
> On Sun, Apr 24, 2016 at 1:34 PM, Tomek Janiszewski <ja...@gmail.com>
> wrote:
>
>> Hi,
>>
>> Can anyone shepherd https://issues.apache.org/jira/browse/MESOS-5263?
>> It's similar to https://issues.apache.org/jira/browse/MESOS-5121 and
>> could
>> be resolved in the same manner or it could be done in a way that'll
>> support
>> other platforms as well.
>>
>> Thanks
>> Tomek
>>
>
>
--
Best Regards,
Haosdent Huang
Re: Looking for Shepherd for MESOS-5263
Posted by Benjamin Mahler <bm...@apache.org>.
Looks like Vinod shipped MESOS-5121. I just shipped MESOS-5263 following
the same approach.
Haosdent mentioned some cleanups are possible here so please keep us posted
if the cleanups are available!
On Sun, Apr 24, 2016 at 1:34 PM, Tomek Janiszewski <ja...@gmail.com>
wrote:
> Hi,
>
> Can anyone shepherd https://issues.apache.org/jira/browse/MESOS-5263?
> It's similar to https://issues.apache.org/jira/browse/MESOS-5121 and could
> be resolved in the same manner or it could be done in a way that'll support
> other platforms as well.
>
> Thanks
> Tomek
>