Re: shepherd for MESOS-4735, and proposal
Bump. This should be a pretty small change, any takers? On Mon, Mar 14, 2016 at 6:39 PM, Shuai Linwrote: > +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 > 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
I'll be happy to shepherd. On Wed, Mar 16, 2016 at 10:58 AM, Michael Browningwrote: > Bump. This should be a pretty small change, any takers? > > On Mon, Mar 14, 2016 at 6:39 PM, Shuai Lin 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 < > invitapri...@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
+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 Browningwrote: > 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 >
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