You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Michael Browning <in...@gmail.com> on 2016/03/15 01:18:51 UTC
shepherd for MESOS-4735, and proposal
Hi all,
Looking for a shepherd for this task:
https://issues.apache.org/jira/browse/MESOS-4735
As Zhitao mentioned in the ticket, the frequently-encountered
inability to extract archives from webhdfs-fetched files due to the
inclusion of things like query params in the resulting filename is
kind of a blocker for us, and there seems to be interest from others
too, q.v.:
https://issues.apache.org/jira/browse/MESOS-4779
My proposed fix is basically that proposed by Erik in the ticket: add
an optional string `filename` field to the CommandInfo.URI protobuf --
when omitted, the old behavior will be retained, but when specified
the file will be saved to the sandbox with that filename. Any feedback
would be appreciated.
Thanks,
Michael
Re: shepherd for MESOS-4735, and proposal
Posted by Vinod Kone <vi...@apache.org>.
I'll be happy to shepherd.
On Wed, Mar 16, 2016 at 10:58 AM, Michael Browning <in...@gmail.com>
wrote:
> Bump. This should be a pretty small change, any takers?
>
> On Mon, Mar 14, 2016 at 6:39 PM, Shuai Lin <li...@gmail.com> wrote:
> > +1 for the new `filename` field for the URI. It would also be useful for
> > implementing base64:// or data:// scheme uri fetcher, so that the
> scheduler
> > can pass arbitary file blobs to the task directly without resorting to a
> > custom executor. (https://issues.apache.org/jira/browse/MESOS-4524)
> >
> > On Tue, Mar 15, 2016 at 8:18 AM, Michael Browning <
> invitapriore@gmail.com>
> > wrote:
> >
> >> Hi all,
> >>
> >> Looking for a shepherd for this task:
> >>
> >> https://issues.apache.org/jira/browse/MESOS-4735
> >>
> >> As Zhitao mentioned in the ticket, the frequently-encountered
> >> inability to extract archives from webhdfs-fetched files due to the
> >> inclusion of things like query params in the resulting filename is
> >> kind of a blocker for us, and there seems to be interest from others
> >> too, q.v.:
> >>
> >> https://issues.apache.org/jira/browse/MESOS-4779
> >>
> >> My proposed fix is basically that proposed by Erik in the ticket: add
> >> an optional string `filename` field to the CommandInfo.URI protobuf --
> >> when omitted, the old behavior will be retained, but when specified
> >> the file will be saved to the sandbox with that filename. Any feedback
> >> would be appreciated.
> >>
> >> Thanks,
> >> Michael
> >>
>
Re: shepherd for MESOS-4735, and proposal
Posted by Michael Browning <in...@gmail.com>.
Bump. This should be a pretty small change, any takers?
On Mon, Mar 14, 2016 at 6:39 PM, Shuai Lin <li...@gmail.com> wrote:
> +1 for the new `filename` field for the URI. It would also be useful for
> implementing base64:// or data:// scheme uri fetcher, so that the scheduler
> can pass arbitary file blobs to the task directly without resorting to a
> custom executor. (https://issues.apache.org/jira/browse/MESOS-4524)
>
> On Tue, Mar 15, 2016 at 8:18 AM, Michael Browning <in...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> Looking for a shepherd for this task:
>>
>> https://issues.apache.org/jira/browse/MESOS-4735
>>
>> As Zhitao mentioned in the ticket, the frequently-encountered
>> inability to extract archives from webhdfs-fetched files due to the
>> inclusion of things like query params in the resulting filename is
>> kind of a blocker for us, and there seems to be interest from others
>> too, q.v.:
>>
>> https://issues.apache.org/jira/browse/MESOS-4779
>>
>> My proposed fix is basically that proposed by Erik in the ticket: add
>> an optional string `filename` field to the CommandInfo.URI protobuf --
>> when omitted, the old behavior will be retained, but when specified
>> the file will be saved to the sandbox with that filename. Any feedback
>> would be appreciated.
>>
>> Thanks,
>> Michael
>>
Re: shepherd for MESOS-4735, and proposal
Posted by Shuai Lin <li...@gmail.com>.
+1 for the new `filename` field for the URI. It would also be useful for
implementing base64:// or data:// scheme uri fetcher, so that the scheduler
can pass arbitary file blobs to the task directly without resorting to a
custom executor. (https://issues.apache.org/jira/browse/MESOS-4524)
On Tue, Mar 15, 2016 at 8:18 AM, Michael Browning <in...@gmail.com>
wrote:
> Hi all,
>
> Looking for a shepherd for this task:
>
> https://issues.apache.org/jira/browse/MESOS-4735
>
> As Zhitao mentioned in the ticket, the frequently-encountered
> inability to extract archives from webhdfs-fetched files due to the
> inclusion of things like query params in the resulting filename is
> kind of a blocker for us, and there seems to be interest from others
> too, q.v.:
>
> https://issues.apache.org/jira/browse/MESOS-4779
>
> My proposed fix is basically that proposed by Erik in the ticket: add
> an optional string `filename` field to the CommandInfo.URI protobuf --
> when omitted, the old behavior will be retained, but when specified
> the file will be saved to the sandbox with that filename. Any feedback
> would be appreciated.
>
> Thanks,
> Michael
>