You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aurora.apache.org by Zhitao Li <zh...@gmail.com> on 2016/03/07 00:05:22 UTC
Populate DiscoveryInfo in Mesos
Hi,
It seems like Aurora does not populate the "discovery" field in either
TaskInfo or ExecutorInfo in mesos.proto
<https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438>
.
I'm considering adding this to support retrieving port map in Mesos
directly. This would enable us to discovery this information directly from
Mesos side, and also enables us to build one universal service discovery
solution for multiple frameworks including Aurora.
If no objection, I'll create a JIRA ticket for this task.
Thanks.
--
Cheers,
Zhitao Li
Re: Populate DiscoveryInfo in Mesos
Posted by Zhitao Li <zh...@gmail.com>.
On Wed, Mar 30, 2016 at 3:33 PM, Zhitao Li <zh...@gmail.com> wrote:
> Stephan,
>
> So I've managed to run the official Mesos DNS docker container
> <https://hub.docker.com/r/mesosphere/mesos-dns/> under the Aurora vagrant
> environment and get some SRV/A recorded pulled from Mesos master from
> Aurora.
>
Minor correction: I used custom build of v0.5.2 instead of the docker
container, which seems to be an older version.
>
> Because Mesos DNS uses 'name' field if set with some string manipulation,
> for the job 'vagrant/test/http_example_docker', my prototype generates
> these DNS records:
>
> A record: vagranttesthttp-exampled.twitterscheduler.mesos
> SRV record: _vagranttesthttp-exampled._tcp.twitterscheduler.mesos.
>
> If we want to make current prototype useful for Mesos DNS, I suggest we
> change the name field to job name, which would generate record like:
> A: http_example_docker.twitterscheduler.mesos
> SRV: _http_example_docker._tcp.twitterscheduler.slave.mesos
>
> I'll update my patch after getting some signal from you. Thanks.
>
> On Fri, Mar 25, 2016 at 1:49 PM, Zhitao Li <zh...@gmail.com> wrote:
>
>> Hi Stephan,
>>
>> Thanks for looking at that prototype patch.
>>
>> I'll update the patch with the review comments, and probably add a global
>> flag of "populate_discovery_info" to toggle this behavior.
>>
>> About the optional fields: I think it'll be hard to come up a good set of
>> rules applicable to all orgs using Aurora + Mesos, because cluster
>> management and service discovery stack could differ from org to org.
>>
>> In a recent Mesos work group, some experience folks (Jie Yu and Ben
>> Mahler) mentioned some ideas of *TaskInfoDecorator, *which is some
>> optional and configurable plugin on Aurora scheduler side to allow operator
>> to set additional fields before sending the message to Mesos. I like such
>> idea because it would enable Aurora users to experiment faster. Do you
>> think this is an interesting idea worth pursuing?
>>
>>
>> On Fri, Mar 25, 2016 at 1:42 PM, Erb, Stephan <
>> Stephan.Erb@blue-yonder.com> wrote:
>>
>>> I had a closer look at the Mesos documentation, and a design document
>>> might be unnecessary. Most of the values are optional. We can therefore
>>> leave them out until we have a proper usecase for them.
>>>
>>> I left a couple of comments in the review request.
>>> ________________________________________
>>> From: Zhitao Li <zh...@gmail.com>
>>> Sent: Tuesday, March 22, 2016 21:15
>>> To: dev@aurora.apache.org
>>> Subject: Re: Populate DiscoveryInfo in Mesos
>>>
>>> Hi Stephan,
>>>
>>> Sorry for the delay on follow up on this. I took a quick look at Aurora
>>> code, and it's actually quite easy to pipe this information to Mesos (see
>>> https://reviews.apache.org/r/45177/ for quick prototype).
>>>
>>> I'll take a stab to see how I can get Mesos-DNS to work with this
>>> prototype.
>>>
>>> IMO, if this is something the community is interested, the main questions
>>> would be 1) how various fields would be mapped in different Aurora
>>> usages,
>>> and 2) to which level should opt-in/opt-out configured for populating
>>> such
>>> information.
>>>
>>> I actually don't have too much insights on how these usage conventions
>>> would be set (through command line of scheduler or job configuration?)
>>>
>>> Do you think a design doc is the best action here, or a more involved
>>> questionnaire about which fields would be useful for community, or what
>>> value they should take?
>>>
>>> On Mon, Mar 7, 2016 at 1:00 AM, Erb, Stephan <
>>> Stephan.Erb@blue-yonder.com>
>>> wrote:
>>>
>>> > That sounds like a good idea! Great.
>>> >
>>> > If you go ahead with this, please be so kind and start by posting a
>>> short
>>> > design document here on mailinglist (similar to those here
>>> > https://github.com/apache/aurora/blob/master/docs/design-documents.md,
>>> > but probably shorter).
>>> >
>>> > This will allow us to split the discussion of the design from
>>> discussing
>>> > the actual implementation. I believe this is necessary, as the
>>> > DiscoveryInfo protocol is quite flexible (
>>> >
>>> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
>>> > ).
>>> >
>>> > Thanks,
>>> > Stephan
>>> >
>>> >
>>> > ________________________________________
>>> > From: Zhitao Li <zh...@gmail.com>
>>> > Sent: Monday, March 7, 2016 00:05
>>> > To: dev@aurora.apache.org
>>> > Subject: Populate DiscoveryInfo in Mesos
>>> >
>>> > Hi,
>>> >
>>> > It seems like Aurora does not populate the "discovery" field in either
>>> > TaskInfo or ExecutorInfo in mesos.proto
>>> > <
>>> >
>>> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438
>>> > >
>>> > .
>>> >
>>> > I'm considering adding this to support retrieving port map in Mesos
>>> > directly. This would enable us to discovery this information directly
>>> from
>>> > Mesos side, and also enables us to build one universal service
>>> discovery
>>> > solution for multiple frameworks including Aurora.
>>> >
>>> > If no objection, I'll create a JIRA ticket for this task.
>>> >
>>> > Thanks.
>>> > --
>>> > Cheers,
>>> >
>>> > Zhitao Li
>>> >
>>>
>>>
>>>
>>> --
>>> Cheers,
>>>
>>> Zhitao Li
>>>
>>
>>
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>>
>
>
>
> --
> Cheers,
>
> Zhitao Li
>
--
Cheers,
Zhitao Li
Re: Populate DiscoveryInfo in Mesos
Posted by Maxim Khutornenko <ma...@apache.org>.
Left a few comments in the RB. I am +1 on this change overall.
On Tue, Apr 5, 2016 at 10:51 AM, Zhitao Li <zh...@gmail.com> wrote:
> I just updated it one more time this morning and all previous comments have
> been addressed.
>
> Given that this is an opt-in experimental feature (no effect by default), I
> believe it's ready to be landed.
>
> Looking forward to more use cases from this :)
>
> On Tue, Apr 5, 2016 at 10:47 AM, Zameer Manji <zm...@apache.org> wrote:
>
>> I have no concerns, overall I like this change because users of Aurora can
>> use other tools available in the mesos ecosystem. It would be nice if it
>> could land before the RC planned for tomorrow.
>>
>> On Tue, Apr 5, 2016 at 6:49 AM, Erb, Stephan <St...@blue-yonder.com>
>> wrote:
>>
>> > There has been some promising progress on the review request:
>> > https://reviews.apache.org/r/45177/
>> >
>> > Has anyone else comments, or identified a blocking issue? Otherwise, this
>> > beta-feature is close to merging, probably even before the RC planned for
>> > tomorrow.
>> > ________________________________________
>> > From: Zhitao Li <zh...@gmail.com>
>> > Sent: Friday, April 1, 2016 03:10
>> > To: dev@aurora.apache.org
>> > Subject: Re: Populate DiscoveryInfo in Mesos
>> >
>> > Benjamin,
>> >
>> > You are exactly right. The problem is on Mesos DNS side because it has
>> its
>> > own rules of shortening names and replacing dots to other characters.
>> >
>> > IMO, relying one generating one "name" which would be useful for all
>> > systems may be idealistic. I like the "label" concept in recent
>> > Mesos/Docker systems, and probably Mesos DNS should take an optional
>> label
>> > to allow its user to customize the behavior, and Aurora could easily
>> adopt
>> > that: e.g. duplicate labels from TaskInfo to DiscoveryInfo.
>> >
>> > Right now, the only open sourced project using DiscoveryInfo is Mesos
>> DNS,
>> > so there is not real convention in the community yet.
>> >
>> >
>> > On Thu, Mar 31, 2016 at 5:39 PM, benley@gmail.com <be...@gmail.com>
>> > wrote:
>> >
>> > > FYI, Aurora already populates the "executor source" field (not sure
>> > exactly
>> > > what that corresponds to in mesos.proto) with exactly the data you
>> would
>> > > want to send to mesos-dns: rolename.environment.jobname.[tasknumber]
>> for
>> > > each task. Maybe you would need to invert the order of the fields, but
>> > > that's pretty much the right thing.
>> > >
>> > > On Thu, Mar 31, 2016 at 12:53 PM Zhitao Li <zh...@gmail.com>
>> > wrote:
>> > >
>> > > > Hi Stephan,
>> > > >
>> > > > I like your proposal, but I think they all require some changes on
>> > Mesos
>> > > > DNS to support this level of customization. I've filed a github issue
>> > to
>> > > > mesos-dns <https://github.com/mesosphere/mesos-dns/issues/414> to
>> > > describe
>> > > > what I want.
>> > > >
>> > > > I've updated my patch to include unit test and command flag switch,
>> and
>> > > > it's ready for review now.
>> > > >
>> > > > On Thu, Mar 31, 2016 at 2:32 AM, Erb, Stephan <
>> > > Stephan.Erb@blue-yonder.com
>> > > > >
>> > > > wrote:
>> > > >
>> > > > > If I understand your example correctly, the underling jobkey used
>> to
>> > > > > generate "vagranttesthttp-exampled.twitterscheduler.mesos" was
>> > > > > "vagrant/test/http-exampled" and what we actually put into the
>> > > > > DiscoveryInfo is "vagrant.test.http-exampled".
>> > > > >
>> > > > > So how about:
>> > > > > * we inject inverse names <jobname><environment><role>. So for
>> > example:
>> > > > > "http-exampled.test.vagrant"
>> > > > > * we teach mesos-DNS that it should not silently drop dots in our
>> > names
>> > > > >
>> > > > > That should provide us with hierarchical, collision free DNS names
>> > such
>> > > > as
>> > > > > "http-exampled.test.vagrant.twitterscheduler.mesos".
>> > > > >
>> > > > > Bonus points if we get "twitterscheduler" replaced by the actual
>> > > cluster
>> > > > > name.
>> > > > >
>> > > > > ________________________________________
>> > > > > From: Zhitao Li <zh...@gmail.com>
>> > > > > Sent: Thursday, March 31, 2016 01:08
>> > > > > To: dev@aurora.apache.org
>> > > > > Subject: Re: Populate DiscoveryInfo in Mesos
>> > > > >
>> > > > > On Wed, Mar 30, 2016 at 3:58 PM, Joshua Cohen <jc...@apache.org>
>> > > wrote:
>> > > > >
>> > > > > > Job names are not unique though, what would happen if multiple
>> jobs
>> > > had
>> > > > > the
>> > > > > > same name (either across roles or across environments in the same
>> > > > role)?
>> > > > > >
>> > > > >
>> > > > > Good point. They would conflict with each other, and I guess in
>> that
>> > > case
>> > > > > Mesos DNS should not be used with the cluster.
>> > > > >
>> > > > > An alternative is {role}-{job name}, although there are still ways
>> to
>> > > > > create conflict in such case (e.g. "role-dumy/test/job" and
>> > > > > "role/test/dummy-job" generates the same name).
>> > > > >
>> > > > > I think the correct long term approach is to allow some way to
>> > > configure
>> > > > > this information by task or job. I'm a bit hesitant to include new
>> > > thrift
>> > > > > structures for this experiment, and maybe the idea of
>> > > "TaskInfoDecorator"
>> > > > > (see my previous posts) would be more flexible?
>> > > > >
>> > > > >
>> > > > > >
>> > > > > > On Wed, Mar 30, 2016 at 5:33 PM, Zhitao Li <
>> zhitaoli.cs@gmail.com>
>> > > > > wrote:
>> > > > > >
>> > > > > > > Stephan,
>> > > > > > >
>> > > > > > > So I've managed to run the official Mesos DNS docker container
>> > > > > > > <https://hub.docker.com/r/mesosphere/mesos-dns/> under the
>> > Aurora
>> > > > > > vagrant
>> > > > > > > environment and get some SRV/A recorded pulled from Mesos
>> master
>> > > from
>> > > > > > > Aurora.
>> > > > > > >
>> > > > > > > Because Mesos DNS uses 'name' field if set with some string
>> > > > > manipulation,
>> > > > > > > for the job 'vagrant/test/http_example_docker', my prototype
>> > > > generates
>> > > > > > > these DNS records:
>> > > > > > >
>> > > > > > > A record: vagranttesthttp-exampled.twitterscheduler.mesos
>> > > > > > > SRV record:
>> > _vagranttesthttp-exampled._tcp.twitterscheduler.mesos.
>> > > > > > >
>> > > > > > > If we want to make current prototype useful for Mesos DNS, I
>> > > suggest
>> > > > we
>> > > > > > > change the name field to job name, which would generate record
>> > > like:
>> > > > > > > A: http_example_docker.twitterscheduler.mesos
>> > > > > > > SRV: _http_example_docker._tcp.twitterscheduler.slave.mesos
>> > > > > > >
>> > > > > > > I'll update my patch after getting some signal from you.
>> Thanks.
>> > > > > > >
>> > > > > > > On Fri, Mar 25, 2016 at 1:49 PM, Zhitao Li <
>> > zhitaoli.cs@gmail.com>
>> > > > > > wrote:
>> > > > > > >
>> > > > > > > > Hi Stephan,
>> > > > > > > >
>> > > > > > > > Thanks for looking at that prototype patch.
>> > > > > > > >
>> > > > > > > > I'll update the patch with the review comments, and probably
>> > add
>> > > a
>> > > > > > global
>> > > > > > > > flag of "populate_discovery_info" to toggle this behavior.
>> > > > > > > >
>> > > > > > > > About the optional fields: I think it'll be hard to come up a
>> > > good
>> > > > > set
>> > > > > > of
>> > > > > > > > rules applicable to all orgs using Aurora + Mesos, because
>> > > cluster
>> > > > > > > > management and service discovery stack could differ from org
>> to
>> > > > org.
>> > > > > > > >
>> > > > > > > > In a recent Mesos work group, some experience folks (Jie Yu
>> and
>> > > Ben
>> > > > > > > > Mahler) mentioned some ideas of *TaskInfoDecorator, *which is
>> > > some
>> > > > > > > > optional and configurable plugin on Aurora scheduler side to
>> > > allow
>> > > > > > > operator
>> > > > > > > > to set additional fields before sending the message to
>> Mesos. I
>> > > > like
>> > > > > > such
>> > > > > > > > idea because it would enable Aurora users to experiment
>> faster.
>> > > Do
>> > > > > you
>> > > > > > > > think this is an interesting idea worth pursuing?
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > On Fri, Mar 25, 2016 at 1:42 PM, Erb, Stephan <
>> > > > > > > Stephan.Erb@blue-yonder.com
>> > > > > > > > > wrote:
>> > > > > > > >
>> > > > > > > >> I had a closer look at the Mesos documentation, and a design
>> > > > > document
>> > > > > > > >> might be unnecessary. Most of the values are optional. We
>> can
>> > > > > > therefore
>> > > > > > > >> leave them out until we have a proper usecase for them.
>> > > > > > > >>
>> > > > > > > >> I left a couple of comments in the review request.
>> > > > > > > >> ________________________________________
>> > > > > > > >> From: Zhitao Li <zh...@gmail.com>
>> > > > > > > >> Sent: Tuesday, March 22, 2016 21:15
>> > > > > > > >> To: dev@aurora.apache.org
>> > > > > > > >> Subject: Re: Populate DiscoveryInfo in Mesos
>> > > > > > > >>
>> > > > > > > >> Hi Stephan,
>> > > > > > > >>
>> > > > > > > >> Sorry for the delay on follow up on this. I took a quick
>> look
>> > at
>> > > > > > Aurora
>> > > > > > > >> code, and it's actually quite easy to pipe this information
>> to
>> > > > Mesos
>> > > > > > > (see
>> > > > > > > >> https://reviews.apache.org/r/45177/ for quick prototype).
>> > > > > > > >>
>> > > > > > > >> I'll take a stab to see how I can get Mesos-DNS to work with
>> > > this
>> > > > > > > >> prototype.
>> > > > > > > >>
>> > > > > > > >> IMO, if this is something the community is interested, the
>> > main
>> > > > > > > questions
>> > > > > > > >> would be 1) how various fields would be mapped in different
>> > > Aurora
>> > > > > > > usages,
>> > > > > > > >> and 2) to which level should opt-in/opt-out configured for
>> > > > > populating
>> > > > > > > such
>> > > > > > > >> information.
>> > > > > > > >>
>> > > > > > > >> I actually don't have too much insights on how these usage
>> > > > > conventions
>> > > > > > > >> would be set (through command line of scheduler or job
>> > > > > configuration?)
>> > > > > > > >>
>> > > > > > > >> Do you think a design doc is the best action here, or a more
>> > > > > involved
>> > > > > > > >> questionnaire about which fields would be useful for
>> > community,
>> > > or
>> > > > > > what
>> > > > > > > >> value they should take?
>> > > > > > > >>
>> > > > > > > >> On Mon, Mar 7, 2016 at 1:00 AM, Erb, Stephan <
>> > > > > > > Stephan.Erb@blue-yonder.com
>> > > > > > > >> >
>> > > > > > > >> wrote:
>> > > > > > > >>
>> > > > > > > >> > That sounds like a good idea! Great.
>> > > > > > > >> >
>> > > > > > > >> > If you go ahead with this, please be so kind and start by
>> > > > posting
>> > > > > a
>> > > > > > > >> short
>> > > > > > > >> > design document here on mailinglist (similar to those here
>> > > > > > > >> >
>> > > > > >
>> > > https://github.com/apache/aurora/blob/master/docs/design-documents.md
>> > > > > > > ,
>> > > > > > > >> > but probably shorter).
>> > > > > > > >> >
>> > > > > > > >> > This will allow us to split the discussion of the design
>> > from
>> > > > > > > discussing
>> > > > > > > >> > the actual implementation. I believe this is necessary, as
>> > the
>> > > > > > > >> > DiscoveryInfo protocol is quite flexible (
>> > > > > > > >> >
>> > > > > > > >>
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
>> > > > > > > >> > ).
>> > > > > > > >> >
>> > > > > > > >> > Thanks,
>> > > > > > > >> > Stephan
>> > > > > > > >> >
>> > > > > > > >> >
>> > > > > > > >> > ________________________________________
>> > > > > > > >> > From: Zhitao Li <zh...@gmail.com>
>> > > > > > > >> > Sent: Monday, March 7, 2016 00:05
>> > > > > > > >> > To: dev@aurora.apache.org
>> > > > > > > >> > Subject: Populate DiscoveryInfo in Mesos
>> > > > > > > >> >
>> > > > > > > >> > Hi,
>> > > > > > > >> >
>> > > > > > > >> > It seems like Aurora does not populate the "discovery"
>> field
>> > > in
>> > > > > > either
>> > > > > > > >> > TaskInfo or ExecutorInfo in mesos.proto
>> > > > > > > >> > <
>> > > > > > > >> >
>> > > > > > > >>
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438
>> > > > > > > >> > >
>> > > > > > > >> > .
>> > > > > > > >> >
>> > > > > > > >> > I'm considering adding this to support retrieving port map
>> > in
>> > > > > Mesos
>> > > > > > > >> > directly. This would enable us to discovery this
>> information
>> > > > > > directly
>> > > > > > > >> from
>> > > > > > > >> > Mesos side, and also enables us to build one universal
>> > service
>> > > > > > > discovery
>> > > > > > > >> > solution for multiple frameworks including Aurora.
>> > > > > > > >> >
>> > > > > > > >> > If no objection, I'll create a JIRA ticket for this task.
>> > > > > > > >> >
>> > > > > > > >> > Thanks.
>> > > > > > > >> > --
>> > > > > > > >> > Cheers,
>> > > > > > > >> >
>> > > > > > > >> > Zhitao Li
>> > > > > > > >> >
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >> --
>> > > > > > > >> Cheers,
>> > > > > > > >>
>> > > > > > > >> Zhitao Li
>> > > > > > > >>
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > --
>> > > > > > > > Cheers,
>> > > > > > > >
>> > > > > > > > Zhitao Li
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Cheers,
>> > > > > > >
>> > > > > > > Zhitao Li
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Cheers,
>> > > > >
>> > > > > Zhitao Li
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Cheers,
>> > > >
>> > > > Zhitao Li
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Cheers,
>> >
>> > Zhitao Li
>> >
>> > --
>> > Zameer Manji
>> >
>> >
>>
>
>
>
> --
> Cheers,
>
> Zhitao Li
Re: Populate DiscoveryInfo in Mesos
Posted by Zhitao Li <zh...@gmail.com>.
I just updated it one more time this morning and all previous comments have
been addressed.
Given that this is an opt-in experimental feature (no effect by default), I
believe it's ready to be landed.
Looking forward to more use cases from this :)
On Tue, Apr 5, 2016 at 10:47 AM, Zameer Manji <zm...@apache.org> wrote:
> I have no concerns, overall I like this change because users of Aurora can
> use other tools available in the mesos ecosystem. It would be nice if it
> could land before the RC planned for tomorrow.
>
> On Tue, Apr 5, 2016 at 6:49 AM, Erb, Stephan <St...@blue-yonder.com>
> wrote:
>
> > There has been some promising progress on the review request:
> > https://reviews.apache.org/r/45177/
> >
> > Has anyone else comments, or identified a blocking issue? Otherwise, this
> > beta-feature is close to merging, probably even before the RC planned for
> > tomorrow.
> > ________________________________________
> > From: Zhitao Li <zh...@gmail.com>
> > Sent: Friday, April 1, 2016 03:10
> > To: dev@aurora.apache.org
> > Subject: Re: Populate DiscoveryInfo in Mesos
> >
> > Benjamin,
> >
> > You are exactly right. The problem is on Mesos DNS side because it has
> its
> > own rules of shortening names and replacing dots to other characters.
> >
> > IMO, relying one generating one "name" which would be useful for all
> > systems may be idealistic. I like the "label" concept in recent
> > Mesos/Docker systems, and probably Mesos DNS should take an optional
> label
> > to allow its user to customize the behavior, and Aurora could easily
> adopt
> > that: e.g. duplicate labels from TaskInfo to DiscoveryInfo.
> >
> > Right now, the only open sourced project using DiscoveryInfo is Mesos
> DNS,
> > so there is not real convention in the community yet.
> >
> >
> > On Thu, Mar 31, 2016 at 5:39 PM, benley@gmail.com <be...@gmail.com>
> > wrote:
> >
> > > FYI, Aurora already populates the "executor source" field (not sure
> > exactly
> > > what that corresponds to in mesos.proto) with exactly the data you
> would
> > > want to send to mesos-dns: rolename.environment.jobname.[tasknumber]
> for
> > > each task. Maybe you would need to invert the order of the fields, but
> > > that's pretty much the right thing.
> > >
> > > On Thu, Mar 31, 2016 at 12:53 PM Zhitao Li <zh...@gmail.com>
> > wrote:
> > >
> > > > Hi Stephan,
> > > >
> > > > I like your proposal, but I think they all require some changes on
> > Mesos
> > > > DNS to support this level of customization. I've filed a github issue
> > to
> > > > mesos-dns <https://github.com/mesosphere/mesos-dns/issues/414> to
> > > describe
> > > > what I want.
> > > >
> > > > I've updated my patch to include unit test and command flag switch,
> and
> > > > it's ready for review now.
> > > >
> > > > On Thu, Mar 31, 2016 at 2:32 AM, Erb, Stephan <
> > > Stephan.Erb@blue-yonder.com
> > > > >
> > > > wrote:
> > > >
> > > > > If I understand your example correctly, the underling jobkey used
> to
> > > > > generate "vagranttesthttp-exampled.twitterscheduler.mesos" was
> > > > > "vagrant/test/http-exampled" and what we actually put into the
> > > > > DiscoveryInfo is "vagrant.test.http-exampled".
> > > > >
> > > > > So how about:
> > > > > * we inject inverse names <jobname><environment><role>. So for
> > example:
> > > > > "http-exampled.test.vagrant"
> > > > > * we teach mesos-DNS that it should not silently drop dots in our
> > names
> > > > >
> > > > > That should provide us with hierarchical, collision free DNS names
> > such
> > > > as
> > > > > "http-exampled.test.vagrant.twitterscheduler.mesos".
> > > > >
> > > > > Bonus points if we get "twitterscheduler" replaced by the actual
> > > cluster
> > > > > name.
> > > > >
> > > > > ________________________________________
> > > > > From: Zhitao Li <zh...@gmail.com>
> > > > > Sent: Thursday, March 31, 2016 01:08
> > > > > To: dev@aurora.apache.org
> > > > > Subject: Re: Populate DiscoveryInfo in Mesos
> > > > >
> > > > > On Wed, Mar 30, 2016 at 3:58 PM, Joshua Cohen <jc...@apache.org>
> > > wrote:
> > > > >
> > > > > > Job names are not unique though, what would happen if multiple
> jobs
> > > had
> > > > > the
> > > > > > same name (either across roles or across environments in the same
> > > > role)?
> > > > > >
> > > > >
> > > > > Good point. They would conflict with each other, and I guess in
> that
> > > case
> > > > > Mesos DNS should not be used with the cluster.
> > > > >
> > > > > An alternative is {role}-{job name}, although there are still ways
> to
> > > > > create conflict in such case (e.g. "role-dumy/test/job" and
> > > > > "role/test/dummy-job" generates the same name).
> > > > >
> > > > > I think the correct long term approach is to allow some way to
> > > configure
> > > > > this information by task or job. I'm a bit hesitant to include new
> > > thrift
> > > > > structures for this experiment, and maybe the idea of
> > > "TaskInfoDecorator"
> > > > > (see my previous posts) would be more flexible?
> > > > >
> > > > >
> > > > > >
> > > > > > On Wed, Mar 30, 2016 at 5:33 PM, Zhitao Li <
> zhitaoli.cs@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Stephan,
> > > > > > >
> > > > > > > So I've managed to run the official Mesos DNS docker container
> > > > > > > <https://hub.docker.com/r/mesosphere/mesos-dns/> under the
> > Aurora
> > > > > > vagrant
> > > > > > > environment and get some SRV/A recorded pulled from Mesos
> master
> > > from
> > > > > > > Aurora.
> > > > > > >
> > > > > > > Because Mesos DNS uses 'name' field if set with some string
> > > > > manipulation,
> > > > > > > for the job 'vagrant/test/http_example_docker', my prototype
> > > > generates
> > > > > > > these DNS records:
> > > > > > >
> > > > > > > A record: vagranttesthttp-exampled.twitterscheduler.mesos
> > > > > > > SRV record:
> > _vagranttesthttp-exampled._tcp.twitterscheduler.mesos.
> > > > > > >
> > > > > > > If we want to make current prototype useful for Mesos DNS, I
> > > suggest
> > > > we
> > > > > > > change the name field to job name, which would generate record
> > > like:
> > > > > > > A: http_example_docker.twitterscheduler.mesos
> > > > > > > SRV: _http_example_docker._tcp.twitterscheduler.slave.mesos
> > > > > > >
> > > > > > > I'll update my patch after getting some signal from you.
> Thanks.
> > > > > > >
> > > > > > > On Fri, Mar 25, 2016 at 1:49 PM, Zhitao Li <
> > zhitaoli.cs@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Stephan,
> > > > > > > >
> > > > > > > > Thanks for looking at that prototype patch.
> > > > > > > >
> > > > > > > > I'll update the patch with the review comments, and probably
> > add
> > > a
> > > > > > global
> > > > > > > > flag of "populate_discovery_info" to toggle this behavior.
> > > > > > > >
> > > > > > > > About the optional fields: I think it'll be hard to come up a
> > > good
> > > > > set
> > > > > > of
> > > > > > > > rules applicable to all orgs using Aurora + Mesos, because
> > > cluster
> > > > > > > > management and service discovery stack could differ from org
> to
> > > > org.
> > > > > > > >
> > > > > > > > In a recent Mesos work group, some experience folks (Jie Yu
> and
> > > Ben
> > > > > > > > Mahler) mentioned some ideas of *TaskInfoDecorator, *which is
> > > some
> > > > > > > > optional and configurable plugin on Aurora scheduler side to
> > > allow
> > > > > > > operator
> > > > > > > > to set additional fields before sending the message to
> Mesos. I
> > > > like
> > > > > > such
> > > > > > > > idea because it would enable Aurora users to experiment
> faster.
> > > Do
> > > > > you
> > > > > > > > think this is an interesting idea worth pursuing?
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Mar 25, 2016 at 1:42 PM, Erb, Stephan <
> > > > > > > Stephan.Erb@blue-yonder.com
> > > > > > > > > wrote:
> > > > > > > >
> > > > > > > >> I had a closer look at the Mesos documentation, and a design
> > > > > document
> > > > > > > >> might be unnecessary. Most of the values are optional. We
> can
> > > > > > therefore
> > > > > > > >> leave them out until we have a proper usecase for them.
> > > > > > > >>
> > > > > > > >> I left a couple of comments in the review request.
> > > > > > > >> ________________________________________
> > > > > > > >> From: Zhitao Li <zh...@gmail.com>
> > > > > > > >> Sent: Tuesday, March 22, 2016 21:15
> > > > > > > >> To: dev@aurora.apache.org
> > > > > > > >> Subject: Re: Populate DiscoveryInfo in Mesos
> > > > > > > >>
> > > > > > > >> Hi Stephan,
> > > > > > > >>
> > > > > > > >> Sorry for the delay on follow up on this. I took a quick
> look
> > at
> > > > > > Aurora
> > > > > > > >> code, and it's actually quite easy to pipe this information
> to
> > > > Mesos
> > > > > > > (see
> > > > > > > >> https://reviews.apache.org/r/45177/ for quick prototype).
> > > > > > > >>
> > > > > > > >> I'll take a stab to see how I can get Mesos-DNS to work with
> > > this
> > > > > > > >> prototype.
> > > > > > > >>
> > > > > > > >> IMO, if this is something the community is interested, the
> > main
> > > > > > > questions
> > > > > > > >> would be 1) how various fields would be mapped in different
> > > Aurora
> > > > > > > usages,
> > > > > > > >> and 2) to which level should opt-in/opt-out configured for
> > > > > populating
> > > > > > > such
> > > > > > > >> information.
> > > > > > > >>
> > > > > > > >> I actually don't have too much insights on how these usage
> > > > > conventions
> > > > > > > >> would be set (through command line of scheduler or job
> > > > > configuration?)
> > > > > > > >>
> > > > > > > >> Do you think a design doc is the best action here, or a more
> > > > > involved
> > > > > > > >> questionnaire about which fields would be useful for
> > community,
> > > or
> > > > > > what
> > > > > > > >> value they should take?
> > > > > > > >>
> > > > > > > >> On Mon, Mar 7, 2016 at 1:00 AM, Erb, Stephan <
> > > > > > > Stephan.Erb@blue-yonder.com
> > > > > > > >> >
> > > > > > > >> wrote:
> > > > > > > >>
> > > > > > > >> > That sounds like a good idea! Great.
> > > > > > > >> >
> > > > > > > >> > If you go ahead with this, please be so kind and start by
> > > > posting
> > > > > a
> > > > > > > >> short
> > > > > > > >> > design document here on mailinglist (similar to those here
> > > > > > > >> >
> > > > > >
> > > https://github.com/apache/aurora/blob/master/docs/design-documents.md
> > > > > > > ,
> > > > > > > >> > but probably shorter).
> > > > > > > >> >
> > > > > > > >> > This will allow us to split the discussion of the design
> > from
> > > > > > > discussing
> > > > > > > >> > the actual implementation. I believe this is necessary, as
> > the
> > > > > > > >> > DiscoveryInfo protocol is quite flexible (
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
> > > > > > > >> > ).
> > > > > > > >> >
> > > > > > > >> > Thanks,
> > > > > > > >> > Stephan
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > ________________________________________
> > > > > > > >> > From: Zhitao Li <zh...@gmail.com>
> > > > > > > >> > Sent: Monday, March 7, 2016 00:05
> > > > > > > >> > To: dev@aurora.apache.org
> > > > > > > >> > Subject: Populate DiscoveryInfo in Mesos
> > > > > > > >> >
> > > > > > > >> > Hi,
> > > > > > > >> >
> > > > > > > >> > It seems like Aurora does not populate the "discovery"
> field
> > > in
> > > > > > either
> > > > > > > >> > TaskInfo or ExecutorInfo in mesos.proto
> > > > > > > >> > <
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438
> > > > > > > >> > >
> > > > > > > >> > .
> > > > > > > >> >
> > > > > > > >> > I'm considering adding this to support retrieving port map
> > in
> > > > > Mesos
> > > > > > > >> > directly. This would enable us to discovery this
> information
> > > > > > directly
> > > > > > > >> from
> > > > > > > >> > Mesos side, and also enables us to build one universal
> > service
> > > > > > > discovery
> > > > > > > >> > solution for multiple frameworks including Aurora.
> > > > > > > >> >
> > > > > > > >> > If no objection, I'll create a JIRA ticket for this task.
> > > > > > > >> >
> > > > > > > >> > Thanks.
> > > > > > > >> > --
> > > > > > > >> > Cheers,
> > > > > > > >> >
> > > > > > > >> > Zhitao Li
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> --
> > > > > > > >> Cheers,
> > > > > > > >>
> > > > > > > >> Zhitao Li
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Cheers,
> > > > > > > >
> > > > > > > > Zhitao Li
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Cheers,
> > > > > > >
> > > > > > > Zhitao Li
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers,
> > > > >
> > > > > Zhitao Li
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > >
> > > > Zhitao Li
> > > >
> > >
> >
> >
> >
> > --
> > Cheers,
> >
> > Zhitao Li
> >
> > --
> > Zameer Manji
> >
> >
>
--
Cheers,
Zhitao Li
Re: Populate DiscoveryInfo in Mesos
Posted by Zameer Manji <zm...@apache.org>.
I have no concerns, overall I like this change because users of Aurora can
use other tools available in the mesos ecosystem. It would be nice if it
could land before the RC planned for tomorrow.
On Tue, Apr 5, 2016 at 6:49 AM, Erb, Stephan <St...@blue-yonder.com>
wrote:
> There has been some promising progress on the review request:
> https://reviews.apache.org/r/45177/
>
> Has anyone else comments, or identified a blocking issue? Otherwise, this
> beta-feature is close to merging, probably even before the RC planned for
> tomorrow.
> ________________________________________
> From: Zhitao Li <zh...@gmail.com>
> Sent: Friday, April 1, 2016 03:10
> To: dev@aurora.apache.org
> Subject: Re: Populate DiscoveryInfo in Mesos
>
> Benjamin,
>
> You are exactly right. The problem is on Mesos DNS side because it has its
> own rules of shortening names and replacing dots to other characters.
>
> IMO, relying one generating one "name" which would be useful for all
> systems may be idealistic. I like the "label" concept in recent
> Mesos/Docker systems, and probably Mesos DNS should take an optional label
> to allow its user to customize the behavior, and Aurora could easily adopt
> that: e.g. duplicate labels from TaskInfo to DiscoveryInfo.
>
> Right now, the only open sourced project using DiscoveryInfo is Mesos DNS,
> so there is not real convention in the community yet.
>
>
> On Thu, Mar 31, 2016 at 5:39 PM, benley@gmail.com <be...@gmail.com>
> wrote:
>
> > FYI, Aurora already populates the "executor source" field (not sure
> exactly
> > what that corresponds to in mesos.proto) with exactly the data you would
> > want to send to mesos-dns: rolename.environment.jobname.[tasknumber] for
> > each task. Maybe you would need to invert the order of the fields, but
> > that's pretty much the right thing.
> >
> > On Thu, Mar 31, 2016 at 12:53 PM Zhitao Li <zh...@gmail.com>
> wrote:
> >
> > > Hi Stephan,
> > >
> > > I like your proposal, but I think they all require some changes on
> Mesos
> > > DNS to support this level of customization. I've filed a github issue
> to
> > > mesos-dns <https://github.com/mesosphere/mesos-dns/issues/414> to
> > describe
> > > what I want.
> > >
> > > I've updated my patch to include unit test and command flag switch, and
> > > it's ready for review now.
> > >
> > > On Thu, Mar 31, 2016 at 2:32 AM, Erb, Stephan <
> > Stephan.Erb@blue-yonder.com
> > > >
> > > wrote:
> > >
> > > > If I understand your example correctly, the underling jobkey used to
> > > > generate "vagranttesthttp-exampled.twitterscheduler.mesos" was
> > > > "vagrant/test/http-exampled" and what we actually put into the
> > > > DiscoveryInfo is "vagrant.test.http-exampled".
> > > >
> > > > So how about:
> > > > * we inject inverse names <jobname><environment><role>. So for
> example:
> > > > "http-exampled.test.vagrant"
> > > > * we teach mesos-DNS that it should not silently drop dots in our
> names
> > > >
> > > > That should provide us with hierarchical, collision free DNS names
> such
> > > as
> > > > "http-exampled.test.vagrant.twitterscheduler.mesos".
> > > >
> > > > Bonus points if we get "twitterscheduler" replaced by the actual
> > cluster
> > > > name.
> > > >
> > > > ________________________________________
> > > > From: Zhitao Li <zh...@gmail.com>
> > > > Sent: Thursday, March 31, 2016 01:08
> > > > To: dev@aurora.apache.org
> > > > Subject: Re: Populate DiscoveryInfo in Mesos
> > > >
> > > > On Wed, Mar 30, 2016 at 3:58 PM, Joshua Cohen <jc...@apache.org>
> > wrote:
> > > >
> > > > > Job names are not unique though, what would happen if multiple jobs
> > had
> > > > the
> > > > > same name (either across roles or across environments in the same
> > > role)?
> > > > >
> > > >
> > > > Good point. They would conflict with each other, and I guess in that
> > case
> > > > Mesos DNS should not be used with the cluster.
> > > >
> > > > An alternative is {role}-{job name}, although there are still ways to
> > > > create conflict in such case (e.g. "role-dumy/test/job" and
> > > > "role/test/dummy-job" generates the same name).
> > > >
> > > > I think the correct long term approach is to allow some way to
> > configure
> > > > this information by task or job. I'm a bit hesitant to include new
> > thrift
> > > > structures for this experiment, and maybe the idea of
> > "TaskInfoDecorator"
> > > > (see my previous posts) would be more flexible?
> > > >
> > > >
> > > > >
> > > > > On Wed, Mar 30, 2016 at 5:33 PM, Zhitao Li <zh...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > Stephan,
> > > > > >
> > > > > > So I've managed to run the official Mesos DNS docker container
> > > > > > <https://hub.docker.com/r/mesosphere/mesos-dns/> under the
> Aurora
> > > > > vagrant
> > > > > > environment and get some SRV/A recorded pulled from Mesos master
> > from
> > > > > > Aurora.
> > > > > >
> > > > > > Because Mesos DNS uses 'name' field if set with some string
> > > > manipulation,
> > > > > > for the job 'vagrant/test/http_example_docker', my prototype
> > > generates
> > > > > > these DNS records:
> > > > > >
> > > > > > A record: vagranttesthttp-exampled.twitterscheduler.mesos
> > > > > > SRV record:
> _vagranttesthttp-exampled._tcp.twitterscheduler.mesos.
> > > > > >
> > > > > > If we want to make current prototype useful for Mesos DNS, I
> > suggest
> > > we
> > > > > > change the name field to job name, which would generate record
> > like:
> > > > > > A: http_example_docker.twitterscheduler.mesos
> > > > > > SRV: _http_example_docker._tcp.twitterscheduler.slave.mesos
> > > > > >
> > > > > > I'll update my patch after getting some signal from you. Thanks.
> > > > > >
> > > > > > On Fri, Mar 25, 2016 at 1:49 PM, Zhitao Li <
> zhitaoli.cs@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Hi Stephan,
> > > > > > >
> > > > > > > Thanks for looking at that prototype patch.
> > > > > > >
> > > > > > > I'll update the patch with the review comments, and probably
> add
> > a
> > > > > global
> > > > > > > flag of "populate_discovery_info" to toggle this behavior.
> > > > > > >
> > > > > > > About the optional fields: I think it'll be hard to come up a
> > good
> > > > set
> > > > > of
> > > > > > > rules applicable to all orgs using Aurora + Mesos, because
> > cluster
> > > > > > > management and service discovery stack could differ from org to
> > > org.
> > > > > > >
> > > > > > > In a recent Mesos work group, some experience folks (Jie Yu and
> > Ben
> > > > > > > Mahler) mentioned some ideas of *TaskInfoDecorator, *which is
> > some
> > > > > > > optional and configurable plugin on Aurora scheduler side to
> > allow
> > > > > > operator
> > > > > > > to set additional fields before sending the message to Mesos. I
> > > like
> > > > > such
> > > > > > > idea because it would enable Aurora users to experiment faster.
> > Do
> > > > you
> > > > > > > think this is an interesting idea worth pursuing?
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Mar 25, 2016 at 1:42 PM, Erb, Stephan <
> > > > > > Stephan.Erb@blue-yonder.com
> > > > > > > > wrote:
> > > > > > >
> > > > > > >> I had a closer look at the Mesos documentation, and a design
> > > > document
> > > > > > >> might be unnecessary. Most of the values are optional. We can
> > > > > therefore
> > > > > > >> leave them out until we have a proper usecase for them.
> > > > > > >>
> > > > > > >> I left a couple of comments in the review request.
> > > > > > >> ________________________________________
> > > > > > >> From: Zhitao Li <zh...@gmail.com>
> > > > > > >> Sent: Tuesday, March 22, 2016 21:15
> > > > > > >> To: dev@aurora.apache.org
> > > > > > >> Subject: Re: Populate DiscoveryInfo in Mesos
> > > > > > >>
> > > > > > >> Hi Stephan,
> > > > > > >>
> > > > > > >> Sorry for the delay on follow up on this. I took a quick look
> at
> > > > > Aurora
> > > > > > >> code, and it's actually quite easy to pipe this information to
> > > Mesos
> > > > > > (see
> > > > > > >> https://reviews.apache.org/r/45177/ for quick prototype).
> > > > > > >>
> > > > > > >> I'll take a stab to see how I can get Mesos-DNS to work with
> > this
> > > > > > >> prototype.
> > > > > > >>
> > > > > > >> IMO, if this is something the community is interested, the
> main
> > > > > > questions
> > > > > > >> would be 1) how various fields would be mapped in different
> > Aurora
> > > > > > usages,
> > > > > > >> and 2) to which level should opt-in/opt-out configured for
> > > > populating
> > > > > > such
> > > > > > >> information.
> > > > > > >>
> > > > > > >> I actually don't have too much insights on how these usage
> > > > conventions
> > > > > > >> would be set (through command line of scheduler or job
> > > > configuration?)
> > > > > > >>
> > > > > > >> Do you think a design doc is the best action here, or a more
> > > > involved
> > > > > > >> questionnaire about which fields would be useful for
> community,
> > or
> > > > > what
> > > > > > >> value they should take?
> > > > > > >>
> > > > > > >> On Mon, Mar 7, 2016 at 1:00 AM, Erb, Stephan <
> > > > > > Stephan.Erb@blue-yonder.com
> > > > > > >> >
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> > That sounds like a good idea! Great.
> > > > > > >> >
> > > > > > >> > If you go ahead with this, please be so kind and start by
> > > posting
> > > > a
> > > > > > >> short
> > > > > > >> > design document here on mailinglist (similar to those here
> > > > > > >> >
> > > > >
> > https://github.com/apache/aurora/blob/master/docs/design-documents.md
> > > > > > ,
> > > > > > >> > but probably shorter).
> > > > > > >> >
> > > > > > >> > This will allow us to split the discussion of the design
> from
> > > > > > discussing
> > > > > > >> > the actual implementation. I believe this is necessary, as
> the
> > > > > > >> > DiscoveryInfo protocol is quite flexible (
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
> > > > > > >> > ).
> > > > > > >> >
> > > > > > >> > Thanks,
> > > > > > >> > Stephan
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > ________________________________________
> > > > > > >> > From: Zhitao Li <zh...@gmail.com>
> > > > > > >> > Sent: Monday, March 7, 2016 00:05
> > > > > > >> > To: dev@aurora.apache.org
> > > > > > >> > Subject: Populate DiscoveryInfo in Mesos
> > > > > > >> >
> > > > > > >> > Hi,
> > > > > > >> >
> > > > > > >> > It seems like Aurora does not populate the "discovery" field
> > in
> > > > > either
> > > > > > >> > TaskInfo or ExecutorInfo in mesos.proto
> > > > > > >> > <
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438
> > > > > > >> > >
> > > > > > >> > .
> > > > > > >> >
> > > > > > >> > I'm considering adding this to support retrieving port map
> in
> > > > Mesos
> > > > > > >> > directly. This would enable us to discovery this information
> > > > > directly
> > > > > > >> from
> > > > > > >> > Mesos side, and also enables us to build one universal
> service
> > > > > > discovery
> > > > > > >> > solution for multiple frameworks including Aurora.
> > > > > > >> >
> > > > > > >> > If no objection, I'll create a JIRA ticket for this task.
> > > > > > >> >
> > > > > > >> > Thanks.
> > > > > > >> > --
> > > > > > >> > Cheers,
> > > > > > >> >
> > > > > > >> > Zhitao Li
> > > > > > >> >
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> --
> > > > > > >> Cheers,
> > > > > > >>
> > > > > > >> Zhitao Li
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Cheers,
> > > > > > >
> > > > > > > Zhitao Li
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > >
> > > > > > Zhitao Li
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > >
> > > > Zhitao Li
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers,
> > >
> > > Zhitao Li
> > >
> >
>
>
>
> --
> Cheers,
>
> Zhitao Li
>
> --
> Zameer Manji
>
>
Re: Populate DiscoveryInfo in Mesos
Posted by "Erb, Stephan" <St...@blue-yonder.com>.
There has been some promising progress on the review request: https://reviews.apache.org/r/45177/
Has anyone else comments, or identified a blocking issue? Otherwise, this beta-feature is close to merging, probably even before the RC planned for tomorrow.
________________________________________
From: Zhitao Li <zh...@gmail.com>
Sent: Friday, April 1, 2016 03:10
To: dev@aurora.apache.org
Subject: Re: Populate DiscoveryInfo in Mesos
Benjamin,
You are exactly right. The problem is on Mesos DNS side because it has its
own rules of shortening names and replacing dots to other characters.
IMO, relying one generating one "name" which would be useful for all
systems may be idealistic. I like the "label" concept in recent
Mesos/Docker systems, and probably Mesos DNS should take an optional label
to allow its user to customize the behavior, and Aurora could easily adopt
that: e.g. duplicate labels from TaskInfo to DiscoveryInfo.
Right now, the only open sourced project using DiscoveryInfo is Mesos DNS,
so there is not real convention in the community yet.
On Thu, Mar 31, 2016 at 5:39 PM, benley@gmail.com <be...@gmail.com> wrote:
> FYI, Aurora already populates the "executor source" field (not sure exactly
> what that corresponds to in mesos.proto) with exactly the data you would
> want to send to mesos-dns: rolename.environment.jobname.[tasknumber] for
> each task. Maybe you would need to invert the order of the fields, but
> that's pretty much the right thing.
>
> On Thu, Mar 31, 2016 at 12:53 PM Zhitao Li <zh...@gmail.com> wrote:
>
> > Hi Stephan,
> >
> > I like your proposal, but I think they all require some changes on Mesos
> > DNS to support this level of customization. I've filed a github issue to
> > mesos-dns <https://github.com/mesosphere/mesos-dns/issues/414> to
> describe
> > what I want.
> >
> > I've updated my patch to include unit test and command flag switch, and
> > it's ready for review now.
> >
> > On Thu, Mar 31, 2016 at 2:32 AM, Erb, Stephan <
> Stephan.Erb@blue-yonder.com
> > >
> > wrote:
> >
> > > If I understand your example correctly, the underling jobkey used to
> > > generate "vagranttesthttp-exampled.twitterscheduler.mesos" was
> > > "vagrant/test/http-exampled" and what we actually put into the
> > > DiscoveryInfo is "vagrant.test.http-exampled".
> > >
> > > So how about:
> > > * we inject inverse names <jobname><environment><role>. So for example:
> > > "http-exampled.test.vagrant"
> > > * we teach mesos-DNS that it should not silently drop dots in our names
> > >
> > > That should provide us with hierarchical, collision free DNS names such
> > as
> > > "http-exampled.test.vagrant.twitterscheduler.mesos".
> > >
> > > Bonus points if we get "twitterscheduler" replaced by the actual
> cluster
> > > name.
> > >
> > > ________________________________________
> > > From: Zhitao Li <zh...@gmail.com>
> > > Sent: Thursday, March 31, 2016 01:08
> > > To: dev@aurora.apache.org
> > > Subject: Re: Populate DiscoveryInfo in Mesos
> > >
> > > On Wed, Mar 30, 2016 at 3:58 PM, Joshua Cohen <jc...@apache.org>
> wrote:
> > >
> > > > Job names are not unique though, what would happen if multiple jobs
> had
> > > the
> > > > same name (either across roles or across environments in the same
> > role)?
> > > >
> > >
> > > Good point. They would conflict with each other, and I guess in that
> case
> > > Mesos DNS should not be used with the cluster.
> > >
> > > An alternative is {role}-{job name}, although there are still ways to
> > > create conflict in such case (e.g. "role-dumy/test/job" and
> > > "role/test/dummy-job" generates the same name).
> > >
> > > I think the correct long term approach is to allow some way to
> configure
> > > this information by task or job. I'm a bit hesitant to include new
> thrift
> > > structures for this experiment, and maybe the idea of
> "TaskInfoDecorator"
> > > (see my previous posts) would be more flexible?
> > >
> > >
> > > >
> > > > On Wed, Mar 30, 2016 at 5:33 PM, Zhitao Li <zh...@gmail.com>
> > > wrote:
> > > >
> > > > > Stephan,
> > > > >
> > > > > So I've managed to run the official Mesos DNS docker container
> > > > > <https://hub.docker.com/r/mesosphere/mesos-dns/> under the Aurora
> > > > vagrant
> > > > > environment and get some SRV/A recorded pulled from Mesos master
> from
> > > > > Aurora.
> > > > >
> > > > > Because Mesos DNS uses 'name' field if set with some string
> > > manipulation,
> > > > > for the job 'vagrant/test/http_example_docker', my prototype
> > generates
> > > > > these DNS records:
> > > > >
> > > > > A record: vagranttesthttp-exampled.twitterscheduler.mesos
> > > > > SRV record: _vagranttesthttp-exampled._tcp.twitterscheduler.mesos.
> > > > >
> > > > > If we want to make current prototype useful for Mesos DNS, I
> suggest
> > we
> > > > > change the name field to job name, which would generate record
> like:
> > > > > A: http_example_docker.twitterscheduler.mesos
> > > > > SRV: _http_example_docker._tcp.twitterscheduler.slave.mesos
> > > > >
> > > > > I'll update my patch after getting some signal from you. Thanks.
> > > > >
> > > > > On Fri, Mar 25, 2016 at 1:49 PM, Zhitao Li <zh...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > Hi Stephan,
> > > > > >
> > > > > > Thanks for looking at that prototype patch.
> > > > > >
> > > > > > I'll update the patch with the review comments, and probably add
> a
> > > > global
> > > > > > flag of "populate_discovery_info" to toggle this behavior.
> > > > > >
> > > > > > About the optional fields: I think it'll be hard to come up a
> good
> > > set
> > > > of
> > > > > > rules applicable to all orgs using Aurora + Mesos, because
> cluster
> > > > > > management and service discovery stack could differ from org to
> > org.
> > > > > >
> > > > > > In a recent Mesos work group, some experience folks (Jie Yu and
> Ben
> > > > > > Mahler) mentioned some ideas of *TaskInfoDecorator, *which is
> some
> > > > > > optional and configurable plugin on Aurora scheduler side to
> allow
> > > > > operator
> > > > > > to set additional fields before sending the message to Mesos. I
> > like
> > > > such
> > > > > > idea because it would enable Aurora users to experiment faster.
> Do
> > > you
> > > > > > think this is an interesting idea worth pursuing?
> > > > > >
> > > > > >
> > > > > > On Fri, Mar 25, 2016 at 1:42 PM, Erb, Stephan <
> > > > > Stephan.Erb@blue-yonder.com
> > > > > > > wrote:
> > > > > >
> > > > > >> I had a closer look at the Mesos documentation, and a design
> > > document
> > > > > >> might be unnecessary. Most of the values are optional. We can
> > > > therefore
> > > > > >> leave them out until we have a proper usecase for them.
> > > > > >>
> > > > > >> I left a couple of comments in the review request.
> > > > > >> ________________________________________
> > > > > >> From: Zhitao Li <zh...@gmail.com>
> > > > > >> Sent: Tuesday, March 22, 2016 21:15
> > > > > >> To: dev@aurora.apache.org
> > > > > >> Subject: Re: Populate DiscoveryInfo in Mesos
> > > > > >>
> > > > > >> Hi Stephan,
> > > > > >>
> > > > > >> Sorry for the delay on follow up on this. I took a quick look at
> > > > Aurora
> > > > > >> code, and it's actually quite easy to pipe this information to
> > Mesos
> > > > > (see
> > > > > >> https://reviews.apache.org/r/45177/ for quick prototype).
> > > > > >>
> > > > > >> I'll take a stab to see how I can get Mesos-DNS to work with
> this
> > > > > >> prototype.
> > > > > >>
> > > > > >> IMO, if this is something the community is interested, the main
> > > > > questions
> > > > > >> would be 1) how various fields would be mapped in different
> Aurora
> > > > > usages,
> > > > > >> and 2) to which level should opt-in/opt-out configured for
> > > populating
> > > > > such
> > > > > >> information.
> > > > > >>
> > > > > >> I actually don't have too much insights on how these usage
> > > conventions
> > > > > >> would be set (through command line of scheduler or job
> > > configuration?)
> > > > > >>
> > > > > >> Do you think a design doc is the best action here, or a more
> > > involved
> > > > > >> questionnaire about which fields would be useful for community,
> or
> > > > what
> > > > > >> value they should take?
> > > > > >>
> > > > > >> On Mon, Mar 7, 2016 at 1:00 AM, Erb, Stephan <
> > > > > Stephan.Erb@blue-yonder.com
> > > > > >> >
> > > > > >> wrote:
> > > > > >>
> > > > > >> > That sounds like a good idea! Great.
> > > > > >> >
> > > > > >> > If you go ahead with this, please be so kind and start by
> > posting
> > > a
> > > > > >> short
> > > > > >> > design document here on mailinglist (similar to those here
> > > > > >> >
> > > >
> https://github.com/apache/aurora/blob/master/docs/design-documents.md
> > > > > ,
> > > > > >> > but probably shorter).
> > > > > >> >
> > > > > >> > This will allow us to split the discussion of the design from
> > > > > discussing
> > > > > >> > the actual implementation. I believe this is necessary, as the
> > > > > >> > DiscoveryInfo protocol is quite flexible (
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
> > > > > >> > ).
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> > Stephan
> > > > > >> >
> > > > > >> >
> > > > > >> > ________________________________________
> > > > > >> > From: Zhitao Li <zh...@gmail.com>
> > > > > >> > Sent: Monday, March 7, 2016 00:05
> > > > > >> > To: dev@aurora.apache.org
> > > > > >> > Subject: Populate DiscoveryInfo in Mesos
> > > > > >> >
> > > > > >> > Hi,
> > > > > >> >
> > > > > >> > It seems like Aurora does not populate the "discovery" field
> in
> > > > either
> > > > > >> > TaskInfo or ExecutorInfo in mesos.proto
> > > > > >> > <
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438
> > > > > >> > >
> > > > > >> > .
> > > > > >> >
> > > > > >> > I'm considering adding this to support retrieving port map in
> > > Mesos
> > > > > >> > directly. This would enable us to discovery this information
> > > > directly
> > > > > >> from
> > > > > >> > Mesos side, and also enables us to build one universal service
> > > > > discovery
> > > > > >> > solution for multiple frameworks including Aurora.
> > > > > >> >
> > > > > >> > If no objection, I'll create a JIRA ticket for this task.
> > > > > >> >
> > > > > >> > Thanks.
> > > > > >> > --
> > > > > >> > Cheers,
> > > > > >> >
> > > > > >> > Zhitao Li
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Cheers,
> > > > > >>
> > > > > >> Zhitao Li
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > >
> > > > > > Zhitao Li
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers,
> > > > >
> > > > > Zhitao Li
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers,
> > >
> > > Zhitao Li
> > >
> >
> >
> >
> > --
> > Cheers,
> >
> > Zhitao Li
> >
>
--
Cheers,
Zhitao Li
Re: Populate DiscoveryInfo in Mesos
Posted by Zhitao Li <zh...@gmail.com>.
Benjamin,
You are exactly right. The problem is on Mesos DNS side because it has its
own rules of shortening names and replacing dots to other characters.
IMO, relying one generating one "name" which would be useful for all
systems may be idealistic. I like the "label" concept in recent
Mesos/Docker systems, and probably Mesos DNS should take an optional label
to allow its user to customize the behavior, and Aurora could easily adopt
that: e.g. duplicate labels from TaskInfo to DiscoveryInfo.
Right now, the only open sourced project using DiscoveryInfo is Mesos DNS,
so there is not real convention in the community yet.
On Thu, Mar 31, 2016 at 5:39 PM, benley@gmail.com <be...@gmail.com> wrote:
> FYI, Aurora already populates the "executor source" field (not sure exactly
> what that corresponds to in mesos.proto) with exactly the data you would
> want to send to mesos-dns: rolename.environment.jobname.[tasknumber] for
> each task. Maybe you would need to invert the order of the fields, but
> that's pretty much the right thing.
>
> On Thu, Mar 31, 2016 at 12:53 PM Zhitao Li <zh...@gmail.com> wrote:
>
> > Hi Stephan,
> >
> > I like your proposal, but I think they all require some changes on Mesos
> > DNS to support this level of customization. I've filed a github issue to
> > mesos-dns <https://github.com/mesosphere/mesos-dns/issues/414> to
> describe
> > what I want.
> >
> > I've updated my patch to include unit test and command flag switch, and
> > it's ready for review now.
> >
> > On Thu, Mar 31, 2016 at 2:32 AM, Erb, Stephan <
> Stephan.Erb@blue-yonder.com
> > >
> > wrote:
> >
> > > If I understand your example correctly, the underling jobkey used to
> > > generate "vagranttesthttp-exampled.twitterscheduler.mesos" was
> > > "vagrant/test/http-exampled" and what we actually put into the
> > > DiscoveryInfo is "vagrant.test.http-exampled".
> > >
> > > So how about:
> > > * we inject inverse names <jobname><environment><role>. So for example:
> > > "http-exampled.test.vagrant"
> > > * we teach mesos-DNS that it should not silently drop dots in our names
> > >
> > > That should provide us with hierarchical, collision free DNS names such
> > as
> > > "http-exampled.test.vagrant.twitterscheduler.mesos".
> > >
> > > Bonus points if we get "twitterscheduler" replaced by the actual
> cluster
> > > name.
> > >
> > > ________________________________________
> > > From: Zhitao Li <zh...@gmail.com>
> > > Sent: Thursday, March 31, 2016 01:08
> > > To: dev@aurora.apache.org
> > > Subject: Re: Populate DiscoveryInfo in Mesos
> > >
> > > On Wed, Mar 30, 2016 at 3:58 PM, Joshua Cohen <jc...@apache.org>
> wrote:
> > >
> > > > Job names are not unique though, what would happen if multiple jobs
> had
> > > the
> > > > same name (either across roles or across environments in the same
> > role)?
> > > >
> > >
> > > Good point. They would conflict with each other, and I guess in that
> case
> > > Mesos DNS should not be used with the cluster.
> > >
> > > An alternative is {role}-{job name}, although there are still ways to
> > > create conflict in such case (e.g. "role-dumy/test/job" and
> > > "role/test/dummy-job" generates the same name).
> > >
> > > I think the correct long term approach is to allow some way to
> configure
> > > this information by task or job. I'm a bit hesitant to include new
> thrift
> > > structures for this experiment, and maybe the idea of
> "TaskInfoDecorator"
> > > (see my previous posts) would be more flexible?
> > >
> > >
> > > >
> > > > On Wed, Mar 30, 2016 at 5:33 PM, Zhitao Li <zh...@gmail.com>
> > > wrote:
> > > >
> > > > > Stephan,
> > > > >
> > > > > So I've managed to run the official Mesos DNS docker container
> > > > > <https://hub.docker.com/r/mesosphere/mesos-dns/> under the Aurora
> > > > vagrant
> > > > > environment and get some SRV/A recorded pulled from Mesos master
> from
> > > > > Aurora.
> > > > >
> > > > > Because Mesos DNS uses 'name' field if set with some string
> > > manipulation,
> > > > > for the job 'vagrant/test/http_example_docker', my prototype
> > generates
> > > > > these DNS records:
> > > > >
> > > > > A record: vagranttesthttp-exampled.twitterscheduler.mesos
> > > > > SRV record: _vagranttesthttp-exampled._tcp.twitterscheduler.mesos.
> > > > >
> > > > > If we want to make current prototype useful for Mesos DNS, I
> suggest
> > we
> > > > > change the name field to job name, which would generate record
> like:
> > > > > A: http_example_docker.twitterscheduler.mesos
> > > > > SRV: _http_example_docker._tcp.twitterscheduler.slave.mesos
> > > > >
> > > > > I'll update my patch after getting some signal from you. Thanks.
> > > > >
> > > > > On Fri, Mar 25, 2016 at 1:49 PM, Zhitao Li <zh...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > Hi Stephan,
> > > > > >
> > > > > > Thanks for looking at that prototype patch.
> > > > > >
> > > > > > I'll update the patch with the review comments, and probably add
> a
> > > > global
> > > > > > flag of "populate_discovery_info" to toggle this behavior.
> > > > > >
> > > > > > About the optional fields: I think it'll be hard to come up a
> good
> > > set
> > > > of
> > > > > > rules applicable to all orgs using Aurora + Mesos, because
> cluster
> > > > > > management and service discovery stack could differ from org to
> > org.
> > > > > >
> > > > > > In a recent Mesos work group, some experience folks (Jie Yu and
> Ben
> > > > > > Mahler) mentioned some ideas of *TaskInfoDecorator, *which is
> some
> > > > > > optional and configurable plugin on Aurora scheduler side to
> allow
> > > > > operator
> > > > > > to set additional fields before sending the message to Mesos. I
> > like
> > > > such
> > > > > > idea because it would enable Aurora users to experiment faster.
> Do
> > > you
> > > > > > think this is an interesting idea worth pursuing?
> > > > > >
> > > > > >
> > > > > > On Fri, Mar 25, 2016 at 1:42 PM, Erb, Stephan <
> > > > > Stephan.Erb@blue-yonder.com
> > > > > > > wrote:
> > > > > >
> > > > > >> I had a closer look at the Mesos documentation, and a design
> > > document
> > > > > >> might be unnecessary. Most of the values are optional. We can
> > > > therefore
> > > > > >> leave them out until we have a proper usecase for them.
> > > > > >>
> > > > > >> I left a couple of comments in the review request.
> > > > > >> ________________________________________
> > > > > >> From: Zhitao Li <zh...@gmail.com>
> > > > > >> Sent: Tuesday, March 22, 2016 21:15
> > > > > >> To: dev@aurora.apache.org
> > > > > >> Subject: Re: Populate DiscoveryInfo in Mesos
> > > > > >>
> > > > > >> Hi Stephan,
> > > > > >>
> > > > > >> Sorry for the delay on follow up on this. I took a quick look at
> > > > Aurora
> > > > > >> code, and it's actually quite easy to pipe this information to
> > Mesos
> > > > > (see
> > > > > >> https://reviews.apache.org/r/45177/ for quick prototype).
> > > > > >>
> > > > > >> I'll take a stab to see how I can get Mesos-DNS to work with
> this
> > > > > >> prototype.
> > > > > >>
> > > > > >> IMO, if this is something the community is interested, the main
> > > > > questions
> > > > > >> would be 1) how various fields would be mapped in different
> Aurora
> > > > > usages,
> > > > > >> and 2) to which level should opt-in/opt-out configured for
> > > populating
> > > > > such
> > > > > >> information.
> > > > > >>
> > > > > >> I actually don't have too much insights on how these usage
> > > conventions
> > > > > >> would be set (through command line of scheduler or job
> > > configuration?)
> > > > > >>
> > > > > >> Do you think a design doc is the best action here, or a more
> > > involved
> > > > > >> questionnaire about which fields would be useful for community,
> or
> > > > what
> > > > > >> value they should take?
> > > > > >>
> > > > > >> On Mon, Mar 7, 2016 at 1:00 AM, Erb, Stephan <
> > > > > Stephan.Erb@blue-yonder.com
> > > > > >> >
> > > > > >> wrote:
> > > > > >>
> > > > > >> > That sounds like a good idea! Great.
> > > > > >> >
> > > > > >> > If you go ahead with this, please be so kind and start by
> > posting
> > > a
> > > > > >> short
> > > > > >> > design document here on mailinglist (similar to those here
> > > > > >> >
> > > >
> https://github.com/apache/aurora/blob/master/docs/design-documents.md
> > > > > ,
> > > > > >> > but probably shorter).
> > > > > >> >
> > > > > >> > This will allow us to split the discussion of the design from
> > > > > discussing
> > > > > >> > the actual implementation. I believe this is necessary, as the
> > > > > >> > DiscoveryInfo protocol is quite flexible (
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
> > > > > >> > ).
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> > Stephan
> > > > > >> >
> > > > > >> >
> > > > > >> > ________________________________________
> > > > > >> > From: Zhitao Li <zh...@gmail.com>
> > > > > >> > Sent: Monday, March 7, 2016 00:05
> > > > > >> > To: dev@aurora.apache.org
> > > > > >> > Subject: Populate DiscoveryInfo in Mesos
> > > > > >> >
> > > > > >> > Hi,
> > > > > >> >
> > > > > >> > It seems like Aurora does not populate the "discovery" field
> in
> > > > either
> > > > > >> > TaskInfo or ExecutorInfo in mesos.proto
> > > > > >> > <
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438
> > > > > >> > >
> > > > > >> > .
> > > > > >> >
> > > > > >> > I'm considering adding this to support retrieving port map in
> > > Mesos
> > > > > >> > directly. This would enable us to discovery this information
> > > > directly
> > > > > >> from
> > > > > >> > Mesos side, and also enables us to build one universal service
> > > > > discovery
> > > > > >> > solution for multiple frameworks including Aurora.
> > > > > >> >
> > > > > >> > If no objection, I'll create a JIRA ticket for this task.
> > > > > >> >
> > > > > >> > Thanks.
> > > > > >> > --
> > > > > >> > Cheers,
> > > > > >> >
> > > > > >> > Zhitao Li
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Cheers,
> > > > > >>
> > > > > >> Zhitao Li
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > >
> > > > > > Zhitao Li
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers,
> > > > >
> > > > > Zhitao Li
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers,
> > >
> > > Zhitao Li
> > >
> >
> >
> >
> > --
> > Cheers,
> >
> > Zhitao Li
> >
>
--
Cheers,
Zhitao Li
Re: Populate DiscoveryInfo in Mesos
Posted by "benley@gmail.com" <be...@gmail.com>.
FYI, Aurora already populates the "executor source" field (not sure exactly
what that corresponds to in mesos.proto) with exactly the data you would
want to send to mesos-dns: rolename.environment.jobname.[tasknumber] for
each task. Maybe you would need to invert the order of the fields, but
that's pretty much the right thing.
On Thu, Mar 31, 2016 at 12:53 PM Zhitao Li <zh...@gmail.com> wrote:
> Hi Stephan,
>
> I like your proposal, but I think they all require some changes on Mesos
> DNS to support this level of customization. I've filed a github issue to
> mesos-dns <https://github.com/mesosphere/mesos-dns/issues/414> to describe
> what I want.
>
> I've updated my patch to include unit test and command flag switch, and
> it's ready for review now.
>
> On Thu, Mar 31, 2016 at 2:32 AM, Erb, Stephan <Stephan.Erb@blue-yonder.com
> >
> wrote:
>
> > If I understand your example correctly, the underling jobkey used to
> > generate "vagranttesthttp-exampled.twitterscheduler.mesos" was
> > "vagrant/test/http-exampled" and what we actually put into the
> > DiscoveryInfo is "vagrant.test.http-exampled".
> >
> > So how about:
> > * we inject inverse names <jobname><environment><role>. So for example:
> > "http-exampled.test.vagrant"
> > * we teach mesos-DNS that it should not silently drop dots in our names
> >
> > That should provide us with hierarchical, collision free DNS names such
> as
> > "http-exampled.test.vagrant.twitterscheduler.mesos".
> >
> > Bonus points if we get "twitterscheduler" replaced by the actual cluster
> > name.
> >
> > ________________________________________
> > From: Zhitao Li <zh...@gmail.com>
> > Sent: Thursday, March 31, 2016 01:08
> > To: dev@aurora.apache.org
> > Subject: Re: Populate DiscoveryInfo in Mesos
> >
> > On Wed, Mar 30, 2016 at 3:58 PM, Joshua Cohen <jc...@apache.org> wrote:
> >
> > > Job names are not unique though, what would happen if multiple jobs had
> > the
> > > same name (either across roles or across environments in the same
> role)?
> > >
> >
> > Good point. They would conflict with each other, and I guess in that case
> > Mesos DNS should not be used with the cluster.
> >
> > An alternative is {role}-{job name}, although there are still ways to
> > create conflict in such case (e.g. "role-dumy/test/job" and
> > "role/test/dummy-job" generates the same name).
> >
> > I think the correct long term approach is to allow some way to configure
> > this information by task or job. I'm a bit hesitant to include new thrift
> > structures for this experiment, and maybe the idea of "TaskInfoDecorator"
> > (see my previous posts) would be more flexible?
> >
> >
> > >
> > > On Wed, Mar 30, 2016 at 5:33 PM, Zhitao Li <zh...@gmail.com>
> > wrote:
> > >
> > > > Stephan,
> > > >
> > > > So I've managed to run the official Mesos DNS docker container
> > > > <https://hub.docker.com/r/mesosphere/mesos-dns/> under the Aurora
> > > vagrant
> > > > environment and get some SRV/A recorded pulled from Mesos master from
> > > > Aurora.
> > > >
> > > > Because Mesos DNS uses 'name' field if set with some string
> > manipulation,
> > > > for the job 'vagrant/test/http_example_docker', my prototype
> generates
> > > > these DNS records:
> > > >
> > > > A record: vagranttesthttp-exampled.twitterscheduler.mesos
> > > > SRV record: _vagranttesthttp-exampled._tcp.twitterscheduler.mesos.
> > > >
> > > > If we want to make current prototype useful for Mesos DNS, I suggest
> we
> > > > change the name field to job name, which would generate record like:
> > > > A: http_example_docker.twitterscheduler.mesos
> > > > SRV: _http_example_docker._tcp.twitterscheduler.slave.mesos
> > > >
> > > > I'll update my patch after getting some signal from you. Thanks.
> > > >
> > > > On Fri, Mar 25, 2016 at 1:49 PM, Zhitao Li <zh...@gmail.com>
> > > wrote:
> > > >
> > > > > Hi Stephan,
> > > > >
> > > > > Thanks for looking at that prototype patch.
> > > > >
> > > > > I'll update the patch with the review comments, and probably add a
> > > global
> > > > > flag of "populate_discovery_info" to toggle this behavior.
> > > > >
> > > > > About the optional fields: I think it'll be hard to come up a good
> > set
> > > of
> > > > > rules applicable to all orgs using Aurora + Mesos, because cluster
> > > > > management and service discovery stack could differ from org to
> org.
> > > > >
> > > > > In a recent Mesos work group, some experience folks (Jie Yu and Ben
> > > > > Mahler) mentioned some ideas of *TaskInfoDecorator, *which is some
> > > > > optional and configurable plugin on Aurora scheduler side to allow
> > > > operator
> > > > > to set additional fields before sending the message to Mesos. I
> like
> > > such
> > > > > idea because it would enable Aurora users to experiment faster. Do
> > you
> > > > > think this is an interesting idea worth pursuing?
> > > > >
> > > > >
> > > > > On Fri, Mar 25, 2016 at 1:42 PM, Erb, Stephan <
> > > > Stephan.Erb@blue-yonder.com
> > > > > > wrote:
> > > > >
> > > > >> I had a closer look at the Mesos documentation, and a design
> > document
> > > > >> might be unnecessary. Most of the values are optional. We can
> > > therefore
> > > > >> leave them out until we have a proper usecase for them.
> > > > >>
> > > > >> I left a couple of comments in the review request.
> > > > >> ________________________________________
> > > > >> From: Zhitao Li <zh...@gmail.com>
> > > > >> Sent: Tuesday, March 22, 2016 21:15
> > > > >> To: dev@aurora.apache.org
> > > > >> Subject: Re: Populate DiscoveryInfo in Mesos
> > > > >>
> > > > >> Hi Stephan,
> > > > >>
> > > > >> Sorry for the delay on follow up on this. I took a quick look at
> > > Aurora
> > > > >> code, and it's actually quite easy to pipe this information to
> Mesos
> > > > (see
> > > > >> https://reviews.apache.org/r/45177/ for quick prototype).
> > > > >>
> > > > >> I'll take a stab to see how I can get Mesos-DNS to work with this
> > > > >> prototype.
> > > > >>
> > > > >> IMO, if this is something the community is interested, the main
> > > > questions
> > > > >> would be 1) how various fields would be mapped in different Aurora
> > > > usages,
> > > > >> and 2) to which level should opt-in/opt-out configured for
> > populating
> > > > such
> > > > >> information.
> > > > >>
> > > > >> I actually don't have too much insights on how these usage
> > conventions
> > > > >> would be set (through command line of scheduler or job
> > configuration?)
> > > > >>
> > > > >> Do you think a design doc is the best action here, or a more
> > involved
> > > > >> questionnaire about which fields would be useful for community, or
> > > what
> > > > >> value they should take?
> > > > >>
> > > > >> On Mon, Mar 7, 2016 at 1:00 AM, Erb, Stephan <
> > > > Stephan.Erb@blue-yonder.com
> > > > >> >
> > > > >> wrote:
> > > > >>
> > > > >> > That sounds like a good idea! Great.
> > > > >> >
> > > > >> > If you go ahead with this, please be so kind and start by
> posting
> > a
> > > > >> short
> > > > >> > design document here on mailinglist (similar to those here
> > > > >> >
> > > https://github.com/apache/aurora/blob/master/docs/design-documents.md
> > > > ,
> > > > >> > but probably shorter).
> > > > >> >
> > > > >> > This will allow us to split the discussion of the design from
> > > > discussing
> > > > >> > the actual implementation. I believe this is necessary, as the
> > > > >> > DiscoveryInfo protocol is quite flexible (
> > > > >> >
> > > > >>
> > > >
> > >
> >
> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
> > > > >> > ).
> > > > >> >
> > > > >> > Thanks,
> > > > >> > Stephan
> > > > >> >
> > > > >> >
> > > > >> > ________________________________________
> > > > >> > From: Zhitao Li <zh...@gmail.com>
> > > > >> > Sent: Monday, March 7, 2016 00:05
> > > > >> > To: dev@aurora.apache.org
> > > > >> > Subject: Populate DiscoveryInfo in Mesos
> > > > >> >
> > > > >> > Hi,
> > > > >> >
> > > > >> > It seems like Aurora does not populate the "discovery" field in
> > > either
> > > > >> > TaskInfo or ExecutorInfo in mesos.proto
> > > > >> > <
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438
> > > > >> > >
> > > > >> > .
> > > > >> >
> > > > >> > I'm considering adding this to support retrieving port map in
> > Mesos
> > > > >> > directly. This would enable us to discovery this information
> > > directly
> > > > >> from
> > > > >> > Mesos side, and also enables us to build one universal service
> > > > discovery
> > > > >> > solution for multiple frameworks including Aurora.
> > > > >> >
> > > > >> > If no objection, I'll create a JIRA ticket for this task.
> > > > >> >
> > > > >> > Thanks.
> > > > >> > --
> > > > >> > Cheers,
> > > > >> >
> > > > >> > Zhitao Li
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Cheers,
> > > > >>
> > > > >> Zhitao Li
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers,
> > > > >
> > > > > Zhitao Li
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > >
> > > > Zhitao Li
> > > >
> > >
> >
> >
> >
> > --
> > Cheers,
> >
> > Zhitao Li
> >
>
>
>
> --
> Cheers,
>
> Zhitao Li
>
Re: Populate DiscoveryInfo in Mesos
Posted by Zhitao Li <zh...@gmail.com>.
Hi Stephan,
I like your proposal, but I think they all require some changes on Mesos
DNS to support this level of customization. I've filed a github issue to
mesos-dns <https://github.com/mesosphere/mesos-dns/issues/414> to describe
what I want.
I've updated my patch to include unit test and command flag switch, and
it's ready for review now.
On Thu, Mar 31, 2016 at 2:32 AM, Erb, Stephan <St...@blue-yonder.com>
wrote:
> If I understand your example correctly, the underling jobkey used to
> generate "vagranttesthttp-exampled.twitterscheduler.mesos" was
> "vagrant/test/http-exampled" and what we actually put into the
> DiscoveryInfo is "vagrant.test.http-exampled".
>
> So how about:
> * we inject inverse names <jobname><environment><role>. So for example:
> "http-exampled.test.vagrant"
> * we teach mesos-DNS that it should not silently drop dots in our names
>
> That should provide us with hierarchical, collision free DNS names such as
> "http-exampled.test.vagrant.twitterscheduler.mesos".
>
> Bonus points if we get "twitterscheduler" replaced by the actual cluster
> name.
>
> ________________________________________
> From: Zhitao Li <zh...@gmail.com>
> Sent: Thursday, March 31, 2016 01:08
> To: dev@aurora.apache.org
> Subject: Re: Populate DiscoveryInfo in Mesos
>
> On Wed, Mar 30, 2016 at 3:58 PM, Joshua Cohen <jc...@apache.org> wrote:
>
> > Job names are not unique though, what would happen if multiple jobs had
> the
> > same name (either across roles or across environments in the same role)?
> >
>
> Good point. They would conflict with each other, and I guess in that case
> Mesos DNS should not be used with the cluster.
>
> An alternative is {role}-{job name}, although there are still ways to
> create conflict in such case (e.g. "role-dumy/test/job" and
> "role/test/dummy-job" generates the same name).
>
> I think the correct long term approach is to allow some way to configure
> this information by task or job. I'm a bit hesitant to include new thrift
> structures for this experiment, and maybe the idea of "TaskInfoDecorator"
> (see my previous posts) would be more flexible?
>
>
> >
> > On Wed, Mar 30, 2016 at 5:33 PM, Zhitao Li <zh...@gmail.com>
> wrote:
> >
> > > Stephan,
> > >
> > > So I've managed to run the official Mesos DNS docker container
> > > <https://hub.docker.com/r/mesosphere/mesos-dns/> under the Aurora
> > vagrant
> > > environment and get some SRV/A recorded pulled from Mesos master from
> > > Aurora.
> > >
> > > Because Mesos DNS uses 'name' field if set with some string
> manipulation,
> > > for the job 'vagrant/test/http_example_docker', my prototype generates
> > > these DNS records:
> > >
> > > A record: vagranttesthttp-exampled.twitterscheduler.mesos
> > > SRV record: _vagranttesthttp-exampled._tcp.twitterscheduler.mesos.
> > >
> > > If we want to make current prototype useful for Mesos DNS, I suggest we
> > > change the name field to job name, which would generate record like:
> > > A: http_example_docker.twitterscheduler.mesos
> > > SRV: _http_example_docker._tcp.twitterscheduler.slave.mesos
> > >
> > > I'll update my patch after getting some signal from you. Thanks.
> > >
> > > On Fri, Mar 25, 2016 at 1:49 PM, Zhitao Li <zh...@gmail.com>
> > wrote:
> > >
> > > > Hi Stephan,
> > > >
> > > > Thanks for looking at that prototype patch.
> > > >
> > > > I'll update the patch with the review comments, and probably add a
> > global
> > > > flag of "populate_discovery_info" to toggle this behavior.
> > > >
> > > > About the optional fields: I think it'll be hard to come up a good
> set
> > of
> > > > rules applicable to all orgs using Aurora + Mesos, because cluster
> > > > management and service discovery stack could differ from org to org.
> > > >
> > > > In a recent Mesos work group, some experience folks (Jie Yu and Ben
> > > > Mahler) mentioned some ideas of *TaskInfoDecorator, *which is some
> > > > optional and configurable plugin on Aurora scheduler side to allow
> > > operator
> > > > to set additional fields before sending the message to Mesos. I like
> > such
> > > > idea because it would enable Aurora users to experiment faster. Do
> you
> > > > think this is an interesting idea worth pursuing?
> > > >
> > > >
> > > > On Fri, Mar 25, 2016 at 1:42 PM, Erb, Stephan <
> > > Stephan.Erb@blue-yonder.com
> > > > > wrote:
> > > >
> > > >> I had a closer look at the Mesos documentation, and a design
> document
> > > >> might be unnecessary. Most of the values are optional. We can
> > therefore
> > > >> leave them out until we have a proper usecase for them.
> > > >>
> > > >> I left a couple of comments in the review request.
> > > >> ________________________________________
> > > >> From: Zhitao Li <zh...@gmail.com>
> > > >> Sent: Tuesday, March 22, 2016 21:15
> > > >> To: dev@aurora.apache.org
> > > >> Subject: Re: Populate DiscoveryInfo in Mesos
> > > >>
> > > >> Hi Stephan,
> > > >>
> > > >> Sorry for the delay on follow up on this. I took a quick look at
> > Aurora
> > > >> code, and it's actually quite easy to pipe this information to Mesos
> > > (see
> > > >> https://reviews.apache.org/r/45177/ for quick prototype).
> > > >>
> > > >> I'll take a stab to see how I can get Mesos-DNS to work with this
> > > >> prototype.
> > > >>
> > > >> IMO, if this is something the community is interested, the main
> > > questions
> > > >> would be 1) how various fields would be mapped in different Aurora
> > > usages,
> > > >> and 2) to which level should opt-in/opt-out configured for
> populating
> > > such
> > > >> information.
> > > >>
> > > >> I actually don't have too much insights on how these usage
> conventions
> > > >> would be set (through command line of scheduler or job
> configuration?)
> > > >>
> > > >> Do you think a design doc is the best action here, or a more
> involved
> > > >> questionnaire about which fields would be useful for community, or
> > what
> > > >> value they should take?
> > > >>
> > > >> On Mon, Mar 7, 2016 at 1:00 AM, Erb, Stephan <
> > > Stephan.Erb@blue-yonder.com
> > > >> >
> > > >> wrote:
> > > >>
> > > >> > That sounds like a good idea! Great.
> > > >> >
> > > >> > If you go ahead with this, please be so kind and start by posting
> a
> > > >> short
> > > >> > design document here on mailinglist (similar to those here
> > > >> >
> > https://github.com/apache/aurora/blob/master/docs/design-documents.md
> > > ,
> > > >> > but probably shorter).
> > > >> >
> > > >> > This will allow us to split the discussion of the design from
> > > discussing
> > > >> > the actual implementation. I believe this is necessary, as the
> > > >> > DiscoveryInfo protocol is quite flexible (
> > > >> >
> > > >>
> > >
> >
> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
> > > >> > ).
> > > >> >
> > > >> > Thanks,
> > > >> > Stephan
> > > >> >
> > > >> >
> > > >> > ________________________________________
> > > >> > From: Zhitao Li <zh...@gmail.com>
> > > >> > Sent: Monday, March 7, 2016 00:05
> > > >> > To: dev@aurora.apache.org
> > > >> > Subject: Populate DiscoveryInfo in Mesos
> > > >> >
> > > >> > Hi,
> > > >> >
> > > >> > It seems like Aurora does not populate the "discovery" field in
> > either
> > > >> > TaskInfo or ExecutorInfo in mesos.proto
> > > >> > <
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438
> > > >> > >
> > > >> > .
> > > >> >
> > > >> > I'm considering adding this to support retrieving port map in
> Mesos
> > > >> > directly. This would enable us to discovery this information
> > directly
> > > >> from
> > > >> > Mesos side, and also enables us to build one universal service
> > > discovery
> > > >> > solution for multiple frameworks including Aurora.
> > > >> >
> > > >> > If no objection, I'll create a JIRA ticket for this task.
> > > >> >
> > > >> > Thanks.
> > > >> > --
> > > >> > Cheers,
> > > >> >
> > > >> > Zhitao Li
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Cheers,
> > > >>
> > > >> Zhitao Li
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > >
> > > > Zhitao Li
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers,
> > >
> > > Zhitao Li
> > >
> >
>
>
>
> --
> Cheers,
>
> Zhitao Li
>
--
Cheers,
Zhitao Li
Re: Populate DiscoveryInfo in Mesos
Posted by "Erb, Stephan" <St...@blue-yonder.com>.
If I understand your example correctly, the underling jobkey used to generate "vagranttesthttp-exampled.twitterscheduler.mesos" was "vagrant/test/http-exampled" and what we actually put into the DiscoveryInfo is "vagrant.test.http-exampled".
So how about:
* we inject inverse names <jobname><environment><role>. So for example: "http-exampled.test.vagrant"
* we teach mesos-DNS that it should not silently drop dots in our names
That should provide us with hierarchical, collision free DNS names such as "http-exampled.test.vagrant.twitterscheduler.mesos".
Bonus points if we get "twitterscheduler" replaced by the actual cluster name.
________________________________________
From: Zhitao Li <zh...@gmail.com>
Sent: Thursday, March 31, 2016 01:08
To: dev@aurora.apache.org
Subject: Re: Populate DiscoveryInfo in Mesos
On Wed, Mar 30, 2016 at 3:58 PM, Joshua Cohen <jc...@apache.org> wrote:
> Job names are not unique though, what would happen if multiple jobs had the
> same name (either across roles or across environments in the same role)?
>
Good point. They would conflict with each other, and I guess in that case
Mesos DNS should not be used with the cluster.
An alternative is {role}-{job name}, although there are still ways to
create conflict in such case (e.g. "role-dumy/test/job" and
"role/test/dummy-job" generates the same name).
I think the correct long term approach is to allow some way to configure
this information by task or job. I'm a bit hesitant to include new thrift
structures for this experiment, and maybe the idea of "TaskInfoDecorator"
(see my previous posts) would be more flexible?
>
> On Wed, Mar 30, 2016 at 5:33 PM, Zhitao Li <zh...@gmail.com> wrote:
>
> > Stephan,
> >
> > So I've managed to run the official Mesos DNS docker container
> > <https://hub.docker.com/r/mesosphere/mesos-dns/> under the Aurora
> vagrant
> > environment and get some SRV/A recorded pulled from Mesos master from
> > Aurora.
> >
> > Because Mesos DNS uses 'name' field if set with some string manipulation,
> > for the job 'vagrant/test/http_example_docker', my prototype generates
> > these DNS records:
> >
> > A record: vagranttesthttp-exampled.twitterscheduler.mesos
> > SRV record: _vagranttesthttp-exampled._tcp.twitterscheduler.mesos.
> >
> > If we want to make current prototype useful for Mesos DNS, I suggest we
> > change the name field to job name, which would generate record like:
> > A: http_example_docker.twitterscheduler.mesos
> > SRV: _http_example_docker._tcp.twitterscheduler.slave.mesos
> >
> > I'll update my patch after getting some signal from you. Thanks.
> >
> > On Fri, Mar 25, 2016 at 1:49 PM, Zhitao Li <zh...@gmail.com>
> wrote:
> >
> > > Hi Stephan,
> > >
> > > Thanks for looking at that prototype patch.
> > >
> > > I'll update the patch with the review comments, and probably add a
> global
> > > flag of "populate_discovery_info" to toggle this behavior.
> > >
> > > About the optional fields: I think it'll be hard to come up a good set
> of
> > > rules applicable to all orgs using Aurora + Mesos, because cluster
> > > management and service discovery stack could differ from org to org.
> > >
> > > In a recent Mesos work group, some experience folks (Jie Yu and Ben
> > > Mahler) mentioned some ideas of *TaskInfoDecorator, *which is some
> > > optional and configurable plugin on Aurora scheduler side to allow
> > operator
> > > to set additional fields before sending the message to Mesos. I like
> such
> > > idea because it would enable Aurora users to experiment faster. Do you
> > > think this is an interesting idea worth pursuing?
> > >
> > >
> > > On Fri, Mar 25, 2016 at 1:42 PM, Erb, Stephan <
> > Stephan.Erb@blue-yonder.com
> > > > wrote:
> > >
> > >> I had a closer look at the Mesos documentation, and a design document
> > >> might be unnecessary. Most of the values are optional. We can
> therefore
> > >> leave them out until we have a proper usecase for them.
> > >>
> > >> I left a couple of comments in the review request.
> > >> ________________________________________
> > >> From: Zhitao Li <zh...@gmail.com>
> > >> Sent: Tuesday, March 22, 2016 21:15
> > >> To: dev@aurora.apache.org
> > >> Subject: Re: Populate DiscoveryInfo in Mesos
> > >>
> > >> Hi Stephan,
> > >>
> > >> Sorry for the delay on follow up on this. I took a quick look at
> Aurora
> > >> code, and it's actually quite easy to pipe this information to Mesos
> > (see
> > >> https://reviews.apache.org/r/45177/ for quick prototype).
> > >>
> > >> I'll take a stab to see how I can get Mesos-DNS to work with this
> > >> prototype.
> > >>
> > >> IMO, if this is something the community is interested, the main
> > questions
> > >> would be 1) how various fields would be mapped in different Aurora
> > usages,
> > >> and 2) to which level should opt-in/opt-out configured for populating
> > such
> > >> information.
> > >>
> > >> I actually don't have too much insights on how these usage conventions
> > >> would be set (through command line of scheduler or job configuration?)
> > >>
> > >> Do you think a design doc is the best action here, or a more involved
> > >> questionnaire about which fields would be useful for community, or
> what
> > >> value they should take?
> > >>
> > >> On Mon, Mar 7, 2016 at 1:00 AM, Erb, Stephan <
> > Stephan.Erb@blue-yonder.com
> > >> >
> > >> wrote:
> > >>
> > >> > That sounds like a good idea! Great.
> > >> >
> > >> > If you go ahead with this, please be so kind and start by posting a
> > >> short
> > >> > design document here on mailinglist (similar to those here
> > >> >
> https://github.com/apache/aurora/blob/master/docs/design-documents.md
> > ,
> > >> > but probably shorter).
> > >> >
> > >> > This will allow us to split the discussion of the design from
> > discussing
> > >> > the actual implementation. I believe this is necessary, as the
> > >> > DiscoveryInfo protocol is quite flexible (
> > >> >
> > >>
> >
> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
> > >> > ).
> > >> >
> > >> > Thanks,
> > >> > Stephan
> > >> >
> > >> >
> > >> > ________________________________________
> > >> > From: Zhitao Li <zh...@gmail.com>
> > >> > Sent: Monday, March 7, 2016 00:05
> > >> > To: dev@aurora.apache.org
> > >> > Subject: Populate DiscoveryInfo in Mesos
> > >> >
> > >> > Hi,
> > >> >
> > >> > It seems like Aurora does not populate the "discovery" field in
> either
> > >> > TaskInfo or ExecutorInfo in mesos.proto
> > >> > <
> > >> >
> > >>
> >
> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438
> > >> > >
> > >> > .
> > >> >
> > >> > I'm considering adding this to support retrieving port map in Mesos
> > >> > directly. This would enable us to discovery this information
> directly
> > >> from
> > >> > Mesos side, and also enables us to build one universal service
> > discovery
> > >> > solution for multiple frameworks including Aurora.
> > >> >
> > >> > If no objection, I'll create a JIRA ticket for this task.
> > >> >
> > >> > Thanks.
> > >> > --
> > >> > Cheers,
> > >> >
> > >> > Zhitao Li
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Cheers,
> > >>
> > >> Zhitao Li
> > >>
> > >
> > >
> > >
> > > --
> > > Cheers,
> > >
> > > Zhitao Li
> > >
> >
> >
> >
> > --
> > Cheers,
> >
> > Zhitao Li
> >
>
--
Cheers,
Zhitao Li
Re: Populate DiscoveryInfo in Mesos
Posted by Zhitao Li <zh...@gmail.com>.
On Wed, Mar 30, 2016 at 3:58 PM, Joshua Cohen <jc...@apache.org> wrote:
> Job names are not unique though, what would happen if multiple jobs had the
> same name (either across roles or across environments in the same role)?
>
Good point. They would conflict with each other, and I guess in that case
Mesos DNS should not be used with the cluster.
An alternative is {role}-{job name}, although there are still ways to
create conflict in such case (e.g. "role-dumy/test/job" and
"role/test/dummy-job" generates the same name).
I think the correct long term approach is to allow some way to configure
this information by task or job. I'm a bit hesitant to include new thrift
structures for this experiment, and maybe the idea of "TaskInfoDecorator"
(see my previous posts) would be more flexible?
>
> On Wed, Mar 30, 2016 at 5:33 PM, Zhitao Li <zh...@gmail.com> wrote:
>
> > Stephan,
> >
> > So I've managed to run the official Mesos DNS docker container
> > <https://hub.docker.com/r/mesosphere/mesos-dns/> under the Aurora
> vagrant
> > environment and get some SRV/A recorded pulled from Mesos master from
> > Aurora.
> >
> > Because Mesos DNS uses 'name' field if set with some string manipulation,
> > for the job 'vagrant/test/http_example_docker', my prototype generates
> > these DNS records:
> >
> > A record: vagranttesthttp-exampled.twitterscheduler.mesos
> > SRV record: _vagranttesthttp-exampled._tcp.twitterscheduler.mesos.
> >
> > If we want to make current prototype useful for Mesos DNS, I suggest we
> > change the name field to job name, which would generate record like:
> > A: http_example_docker.twitterscheduler.mesos
> > SRV: _http_example_docker._tcp.twitterscheduler.slave.mesos
> >
> > I'll update my patch after getting some signal from you. Thanks.
> >
> > On Fri, Mar 25, 2016 at 1:49 PM, Zhitao Li <zh...@gmail.com>
> wrote:
> >
> > > Hi Stephan,
> > >
> > > Thanks for looking at that prototype patch.
> > >
> > > I'll update the patch with the review comments, and probably add a
> global
> > > flag of "populate_discovery_info" to toggle this behavior.
> > >
> > > About the optional fields: I think it'll be hard to come up a good set
> of
> > > rules applicable to all orgs using Aurora + Mesos, because cluster
> > > management and service discovery stack could differ from org to org.
> > >
> > > In a recent Mesos work group, some experience folks (Jie Yu and Ben
> > > Mahler) mentioned some ideas of *TaskInfoDecorator, *which is some
> > > optional and configurable plugin on Aurora scheduler side to allow
> > operator
> > > to set additional fields before sending the message to Mesos. I like
> such
> > > idea because it would enable Aurora users to experiment faster. Do you
> > > think this is an interesting idea worth pursuing?
> > >
> > >
> > > On Fri, Mar 25, 2016 at 1:42 PM, Erb, Stephan <
> > Stephan.Erb@blue-yonder.com
> > > > wrote:
> > >
> > >> I had a closer look at the Mesos documentation, and a design document
> > >> might be unnecessary. Most of the values are optional. We can
> therefore
> > >> leave them out until we have a proper usecase for them.
> > >>
> > >> I left a couple of comments in the review request.
> > >> ________________________________________
> > >> From: Zhitao Li <zh...@gmail.com>
> > >> Sent: Tuesday, March 22, 2016 21:15
> > >> To: dev@aurora.apache.org
> > >> Subject: Re: Populate DiscoveryInfo in Mesos
> > >>
> > >> Hi Stephan,
> > >>
> > >> Sorry for the delay on follow up on this. I took a quick look at
> Aurora
> > >> code, and it's actually quite easy to pipe this information to Mesos
> > (see
> > >> https://reviews.apache.org/r/45177/ for quick prototype).
> > >>
> > >> I'll take a stab to see how I can get Mesos-DNS to work with this
> > >> prototype.
> > >>
> > >> IMO, if this is something the community is interested, the main
> > questions
> > >> would be 1) how various fields would be mapped in different Aurora
> > usages,
> > >> and 2) to which level should opt-in/opt-out configured for populating
> > such
> > >> information.
> > >>
> > >> I actually don't have too much insights on how these usage conventions
> > >> would be set (through command line of scheduler or job configuration?)
> > >>
> > >> Do you think a design doc is the best action here, or a more involved
> > >> questionnaire about which fields would be useful for community, or
> what
> > >> value they should take?
> > >>
> > >> On Mon, Mar 7, 2016 at 1:00 AM, Erb, Stephan <
> > Stephan.Erb@blue-yonder.com
> > >> >
> > >> wrote:
> > >>
> > >> > That sounds like a good idea! Great.
> > >> >
> > >> > If you go ahead with this, please be so kind and start by posting a
> > >> short
> > >> > design document here on mailinglist (similar to those here
> > >> >
> https://github.com/apache/aurora/blob/master/docs/design-documents.md
> > ,
> > >> > but probably shorter).
> > >> >
> > >> > This will allow us to split the discussion of the design from
> > discussing
> > >> > the actual implementation. I believe this is necessary, as the
> > >> > DiscoveryInfo protocol is quite flexible (
> > >> >
> > >>
> >
> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
> > >> > ).
> > >> >
> > >> > Thanks,
> > >> > Stephan
> > >> >
> > >> >
> > >> > ________________________________________
> > >> > From: Zhitao Li <zh...@gmail.com>
> > >> > Sent: Monday, March 7, 2016 00:05
> > >> > To: dev@aurora.apache.org
> > >> > Subject: Populate DiscoveryInfo in Mesos
> > >> >
> > >> > Hi,
> > >> >
> > >> > It seems like Aurora does not populate the "discovery" field in
> either
> > >> > TaskInfo or ExecutorInfo in mesos.proto
> > >> > <
> > >> >
> > >>
> >
> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438
> > >> > >
> > >> > .
> > >> >
> > >> > I'm considering adding this to support retrieving port map in Mesos
> > >> > directly. This would enable us to discovery this information
> directly
> > >> from
> > >> > Mesos side, and also enables us to build one universal service
> > discovery
> > >> > solution for multiple frameworks including Aurora.
> > >> >
> > >> > If no objection, I'll create a JIRA ticket for this task.
> > >> >
> > >> > Thanks.
> > >> > --
> > >> > Cheers,
> > >> >
> > >> > Zhitao Li
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Cheers,
> > >>
> > >> Zhitao Li
> > >>
> > >
> > >
> > >
> > > --
> > > Cheers,
> > >
> > > Zhitao Li
> > >
> >
> >
> >
> > --
> > Cheers,
> >
> > Zhitao Li
> >
>
--
Cheers,
Zhitao Li
Re: Populate DiscoveryInfo in Mesos
Posted by Joshua Cohen <jc...@apache.org>.
Job names are not unique though, what would happen if multiple jobs had the
same name (either across roles or across environments in the same role)?
On Wed, Mar 30, 2016 at 5:33 PM, Zhitao Li <zh...@gmail.com> wrote:
> Stephan,
>
> So I've managed to run the official Mesos DNS docker container
> <https://hub.docker.com/r/mesosphere/mesos-dns/> under the Aurora vagrant
> environment and get some SRV/A recorded pulled from Mesos master from
> Aurora.
>
> Because Mesos DNS uses 'name' field if set with some string manipulation,
> for the job 'vagrant/test/http_example_docker', my prototype generates
> these DNS records:
>
> A record: vagranttesthttp-exampled.twitterscheduler.mesos
> SRV record: _vagranttesthttp-exampled._tcp.twitterscheduler.mesos.
>
> If we want to make current prototype useful for Mesos DNS, I suggest we
> change the name field to job name, which would generate record like:
> A: http_example_docker.twitterscheduler.mesos
> SRV: _http_example_docker._tcp.twitterscheduler.slave.mesos
>
> I'll update my patch after getting some signal from you. Thanks.
>
> On Fri, Mar 25, 2016 at 1:49 PM, Zhitao Li <zh...@gmail.com> wrote:
>
> > Hi Stephan,
> >
> > Thanks for looking at that prototype patch.
> >
> > I'll update the patch with the review comments, and probably add a global
> > flag of "populate_discovery_info" to toggle this behavior.
> >
> > About the optional fields: I think it'll be hard to come up a good set of
> > rules applicable to all orgs using Aurora + Mesos, because cluster
> > management and service discovery stack could differ from org to org.
> >
> > In a recent Mesos work group, some experience folks (Jie Yu and Ben
> > Mahler) mentioned some ideas of *TaskInfoDecorator, *which is some
> > optional and configurable plugin on Aurora scheduler side to allow
> operator
> > to set additional fields before sending the message to Mesos. I like such
> > idea because it would enable Aurora users to experiment faster. Do you
> > think this is an interesting idea worth pursuing?
> >
> >
> > On Fri, Mar 25, 2016 at 1:42 PM, Erb, Stephan <
> Stephan.Erb@blue-yonder.com
> > > wrote:
> >
> >> I had a closer look at the Mesos documentation, and a design document
> >> might be unnecessary. Most of the values are optional. We can therefore
> >> leave them out until we have a proper usecase for them.
> >>
> >> I left a couple of comments in the review request.
> >> ________________________________________
> >> From: Zhitao Li <zh...@gmail.com>
> >> Sent: Tuesday, March 22, 2016 21:15
> >> To: dev@aurora.apache.org
> >> Subject: Re: Populate DiscoveryInfo in Mesos
> >>
> >> Hi Stephan,
> >>
> >> Sorry for the delay on follow up on this. I took a quick look at Aurora
> >> code, and it's actually quite easy to pipe this information to Mesos
> (see
> >> https://reviews.apache.org/r/45177/ for quick prototype).
> >>
> >> I'll take a stab to see how I can get Mesos-DNS to work with this
> >> prototype.
> >>
> >> IMO, if this is something the community is interested, the main
> questions
> >> would be 1) how various fields would be mapped in different Aurora
> usages,
> >> and 2) to which level should opt-in/opt-out configured for populating
> such
> >> information.
> >>
> >> I actually don't have too much insights on how these usage conventions
> >> would be set (through command line of scheduler or job configuration?)
> >>
> >> Do you think a design doc is the best action here, or a more involved
> >> questionnaire about which fields would be useful for community, or what
> >> value they should take?
> >>
> >> On Mon, Mar 7, 2016 at 1:00 AM, Erb, Stephan <
> Stephan.Erb@blue-yonder.com
> >> >
> >> wrote:
> >>
> >> > That sounds like a good idea! Great.
> >> >
> >> > If you go ahead with this, please be so kind and start by posting a
> >> short
> >> > design document here on mailinglist (similar to those here
> >> > https://github.com/apache/aurora/blob/master/docs/design-documents.md
> ,
> >> > but probably shorter).
> >> >
> >> > This will allow us to split the discussion of the design from
> discussing
> >> > the actual implementation. I believe this is necessary, as the
> >> > DiscoveryInfo protocol is quite flexible (
> >> >
> >>
> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
> >> > ).
> >> >
> >> > Thanks,
> >> > Stephan
> >> >
> >> >
> >> > ________________________________________
> >> > From: Zhitao Li <zh...@gmail.com>
> >> > Sent: Monday, March 7, 2016 00:05
> >> > To: dev@aurora.apache.org
> >> > Subject: Populate DiscoveryInfo in Mesos
> >> >
> >> > Hi,
> >> >
> >> > It seems like Aurora does not populate the "discovery" field in either
> >> > TaskInfo or ExecutorInfo in mesos.proto
> >> > <
> >> >
> >>
> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438
> >> > >
> >> > .
> >> >
> >> > I'm considering adding this to support retrieving port map in Mesos
> >> > directly. This would enable us to discovery this information directly
> >> from
> >> > Mesos side, and also enables us to build one universal service
> discovery
> >> > solution for multiple frameworks including Aurora.
> >> >
> >> > If no objection, I'll create a JIRA ticket for this task.
> >> >
> >> > Thanks.
> >> > --
> >> > Cheers,
> >> >
> >> > Zhitao Li
> >> >
> >>
> >>
> >>
> >> --
> >> Cheers,
> >>
> >> Zhitao Li
> >>
> >
> >
> >
> > --
> > Cheers,
> >
> > Zhitao Li
> >
>
>
>
> --
> Cheers,
>
> Zhitao Li
>
Re: Populate DiscoveryInfo in Mesos
Posted by Zhitao Li <zh...@gmail.com>.
Stephan,
So I've managed to run the official Mesos DNS docker container
<https://hub.docker.com/r/mesosphere/mesos-dns/> under the Aurora vagrant
environment and get some SRV/A recorded pulled from Mesos master from
Aurora.
Because Mesos DNS uses 'name' field if set with some string manipulation,
for the job 'vagrant/test/http_example_docker', my prototype generates
these DNS records:
A record: vagranttesthttp-exampled.twitterscheduler.mesos
SRV record: _vagranttesthttp-exampled._tcp.twitterscheduler.mesos.
If we want to make current prototype useful for Mesos DNS, I suggest we
change the name field to job name, which would generate record like:
A: http_example_docker.twitterscheduler.mesos
SRV: _http_example_docker._tcp.twitterscheduler.slave.mesos
I'll update my patch after getting some signal from you. Thanks.
On Fri, Mar 25, 2016 at 1:49 PM, Zhitao Li <zh...@gmail.com> wrote:
> Hi Stephan,
>
> Thanks for looking at that prototype patch.
>
> I'll update the patch with the review comments, and probably add a global
> flag of "populate_discovery_info" to toggle this behavior.
>
> About the optional fields: I think it'll be hard to come up a good set of
> rules applicable to all orgs using Aurora + Mesos, because cluster
> management and service discovery stack could differ from org to org.
>
> In a recent Mesos work group, some experience folks (Jie Yu and Ben
> Mahler) mentioned some ideas of *TaskInfoDecorator, *which is some
> optional and configurable plugin on Aurora scheduler side to allow operator
> to set additional fields before sending the message to Mesos. I like such
> idea because it would enable Aurora users to experiment faster. Do you
> think this is an interesting idea worth pursuing?
>
>
> On Fri, Mar 25, 2016 at 1:42 PM, Erb, Stephan <Stephan.Erb@blue-yonder.com
> > wrote:
>
>> I had a closer look at the Mesos documentation, and a design document
>> might be unnecessary. Most of the values are optional. We can therefore
>> leave them out until we have a proper usecase for them.
>>
>> I left a couple of comments in the review request.
>> ________________________________________
>> From: Zhitao Li <zh...@gmail.com>
>> Sent: Tuesday, March 22, 2016 21:15
>> To: dev@aurora.apache.org
>> Subject: Re: Populate DiscoveryInfo in Mesos
>>
>> Hi Stephan,
>>
>> Sorry for the delay on follow up on this. I took a quick look at Aurora
>> code, and it's actually quite easy to pipe this information to Mesos (see
>> https://reviews.apache.org/r/45177/ for quick prototype).
>>
>> I'll take a stab to see how I can get Mesos-DNS to work with this
>> prototype.
>>
>> IMO, if this is something the community is interested, the main questions
>> would be 1) how various fields would be mapped in different Aurora usages,
>> and 2) to which level should opt-in/opt-out configured for populating such
>> information.
>>
>> I actually don't have too much insights on how these usage conventions
>> would be set (through command line of scheduler or job configuration?)
>>
>> Do you think a design doc is the best action here, or a more involved
>> questionnaire about which fields would be useful for community, or what
>> value they should take?
>>
>> On Mon, Mar 7, 2016 at 1:00 AM, Erb, Stephan <Stephan.Erb@blue-yonder.com
>> >
>> wrote:
>>
>> > That sounds like a good idea! Great.
>> >
>> > If you go ahead with this, please be so kind and start by posting a
>> short
>> > design document here on mailinglist (similar to those here
>> > https://github.com/apache/aurora/blob/master/docs/design-documents.md,
>> > but probably shorter).
>> >
>> > This will allow us to split the discussion of the design from discussing
>> > the actual implementation. I believe this is necessary, as the
>> > DiscoveryInfo protocol is quite flexible (
>> >
>> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
>> > ).
>> >
>> > Thanks,
>> > Stephan
>> >
>> >
>> > ________________________________________
>> > From: Zhitao Li <zh...@gmail.com>
>> > Sent: Monday, March 7, 2016 00:05
>> > To: dev@aurora.apache.org
>> > Subject: Populate DiscoveryInfo in Mesos
>> >
>> > Hi,
>> >
>> > It seems like Aurora does not populate the "discovery" field in either
>> > TaskInfo or ExecutorInfo in mesos.proto
>> > <
>> >
>> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438
>> > >
>> > .
>> >
>> > I'm considering adding this to support retrieving port map in Mesos
>> > directly. This would enable us to discovery this information directly
>> from
>> > Mesos side, and also enables us to build one universal service discovery
>> > solution for multiple frameworks including Aurora.
>> >
>> > If no objection, I'll create a JIRA ticket for this task.
>> >
>> > Thanks.
>> > --
>> > Cheers,
>> >
>> > Zhitao Li
>> >
>>
>>
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>>
>
>
>
> --
> Cheers,
>
> Zhitao Li
>
--
Cheers,
Zhitao Li
Re: Populate DiscoveryInfo in Mesos
Posted by Zhitao Li <zh...@gmail.com>.
Hi Stephan,
Thanks for looking at that prototype patch.
I'll update the patch with the review comments, and probably add a global
flag of "populate_discovery_info" to toggle this behavior.
About the optional fields: I think it'll be hard to come up a good set of
rules applicable to all orgs using Aurora + Mesos, because cluster
management and service discovery stack could differ from org to org.
In a recent Mesos work group, some experience folks (Jie Yu and Ben Mahler)
mentioned some ideas of *TaskInfoDecorator, *which is some optional and
configurable plugin on Aurora scheduler side to allow operator to set
additional fields before sending the message to Mesos. I like such idea
because it would enable Aurora users to experiment faster. Do you think
this is an interesting idea worth pursuing?
On Fri, Mar 25, 2016 at 1:42 PM, Erb, Stephan <St...@blue-yonder.com>
wrote:
> I had a closer look at the Mesos documentation, and a design document
> might be unnecessary. Most of the values are optional. We can therefore
> leave them out until we have a proper usecase for them.
>
> I left a couple of comments in the review request.
> ________________________________________
> From: Zhitao Li <zh...@gmail.com>
> Sent: Tuesday, March 22, 2016 21:15
> To: dev@aurora.apache.org
> Subject: Re: Populate DiscoveryInfo in Mesos
>
> Hi Stephan,
>
> Sorry for the delay on follow up on this. I took a quick look at Aurora
> code, and it's actually quite easy to pipe this information to Mesos (see
> https://reviews.apache.org/r/45177/ for quick prototype).
>
> I'll take a stab to see how I can get Mesos-DNS to work with this
> prototype.
>
> IMO, if this is something the community is interested, the main questions
> would be 1) how various fields would be mapped in different Aurora usages,
> and 2) to which level should opt-in/opt-out configured for populating such
> information.
>
> I actually don't have too much insights on how these usage conventions
> would be set (through command line of scheduler or job configuration?)
>
> Do you think a design doc is the best action here, or a more involved
> questionnaire about which fields would be useful for community, or what
> value they should take?
>
> On Mon, Mar 7, 2016 at 1:00 AM, Erb, Stephan <St...@blue-yonder.com>
> wrote:
>
> > That sounds like a good idea! Great.
> >
> > If you go ahead with this, please be so kind and start by posting a short
> > design document here on mailinglist (similar to those here
> > https://github.com/apache/aurora/blob/master/docs/design-documents.md,
> > but probably shorter).
> >
> > This will allow us to split the discussion of the design from discussing
> > the actual implementation. I believe this is necessary, as the
> > DiscoveryInfo protocol is quite flexible (
> >
> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
> > ).
> >
> > Thanks,
> > Stephan
> >
> >
> > ________________________________________
> > From: Zhitao Li <zh...@gmail.com>
> > Sent: Monday, March 7, 2016 00:05
> > To: dev@aurora.apache.org
> > Subject: Populate DiscoveryInfo in Mesos
> >
> > Hi,
> >
> > It seems like Aurora does not populate the "discovery" field in either
> > TaskInfo or ExecutorInfo in mesos.proto
> > <
> >
> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438
> > >
> > .
> >
> > I'm considering adding this to support retrieving port map in Mesos
> > directly. This would enable us to discovery this information directly
> from
> > Mesos side, and also enables us to build one universal service discovery
> > solution for multiple frameworks including Aurora.
> >
> > If no objection, I'll create a JIRA ticket for this task.
> >
> > Thanks.
> > --
> > Cheers,
> >
> > Zhitao Li
> >
>
>
>
> --
> Cheers,
>
> Zhitao Li
>
--
Cheers,
Zhitao Li
Re: Populate DiscoveryInfo in Mesos
Posted by "Erb, Stephan" <St...@blue-yonder.com>.
I had a closer look at the Mesos documentation, and a design document might be unnecessary. Most of the values are optional. We can therefore leave them out until we have a proper usecase for them.
I left a couple of comments in the review request.
________________________________________
From: Zhitao Li <zh...@gmail.com>
Sent: Tuesday, March 22, 2016 21:15
To: dev@aurora.apache.org
Subject: Re: Populate DiscoveryInfo in Mesos
Hi Stephan,
Sorry for the delay on follow up on this. I took a quick look at Aurora
code, and it's actually quite easy to pipe this information to Mesos (see
https://reviews.apache.org/r/45177/ for quick prototype).
I'll take a stab to see how I can get Mesos-DNS to work with this prototype.
IMO, if this is something the community is interested, the main questions
would be 1) how various fields would be mapped in different Aurora usages,
and 2) to which level should opt-in/opt-out configured for populating such
information.
I actually don't have too much insights on how these usage conventions
would be set (through command line of scheduler or job configuration?)
Do you think a design doc is the best action here, or a more involved
questionnaire about which fields would be useful for community, or what
value they should take?
On Mon, Mar 7, 2016 at 1:00 AM, Erb, Stephan <St...@blue-yonder.com>
wrote:
> That sounds like a good idea! Great.
>
> If you go ahead with this, please be so kind and start by posting a short
> design document here on mailinglist (similar to those here
> https://github.com/apache/aurora/blob/master/docs/design-documents.md,
> but probably shorter).
>
> This will allow us to split the discussion of the design from discussing
> the actual implementation. I believe this is necessary, as the
> DiscoveryInfo protocol is quite flexible (
> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
> ).
>
> Thanks,
> Stephan
>
>
> ________________________________________
> From: Zhitao Li <zh...@gmail.com>
> Sent: Monday, March 7, 2016 00:05
> To: dev@aurora.apache.org
> Subject: Populate DiscoveryInfo in Mesos
>
> Hi,
>
> It seems like Aurora does not populate the "discovery" field in either
> TaskInfo or ExecutorInfo in mesos.proto
> <
> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438
> >
> .
>
> I'm considering adding this to support retrieving port map in Mesos
> directly. This would enable us to discovery this information directly from
> Mesos side, and also enables us to build one universal service discovery
> solution for multiple frameworks including Aurora.
>
> If no objection, I'll create a JIRA ticket for this task.
>
> Thanks.
> --
> Cheers,
>
> Zhitao Li
>
--
Cheers,
Zhitao Li
Re: Populate DiscoveryInfo in Mesos
Posted by Zhitao Li <zh...@gmail.com>.
Hi Stephan,
Sorry for the delay on follow up on this. I took a quick look at Aurora
code, and it's actually quite easy to pipe this information to Mesos (see
https://reviews.apache.org/r/45177/ for quick prototype).
I'll take a stab to see how I can get Mesos-DNS to work with this prototype.
IMO, if this is something the community is interested, the main questions
would be 1) how various fields would be mapped in different Aurora usages,
and 2) to which level should opt-in/opt-out configured for populating such
information.
I actually don't have too much insights on how these usage conventions
would be set (through command line of scheduler or job configuration?)
Do you think a design doc is the best action here, or a more involved
questionnaire about which fields would be useful for community, or what
value they should take?
On Mon, Mar 7, 2016 at 1:00 AM, Erb, Stephan <St...@blue-yonder.com>
wrote:
> That sounds like a good idea! Great.
>
> If you go ahead with this, please be so kind and start by posting a short
> design document here on mailinglist (similar to those here
> https://github.com/apache/aurora/blob/master/docs/design-documents.md,
> but probably shorter).
>
> This will allow us to split the discussion of the design from discussing
> the actual implementation. I believe this is necessary, as the
> DiscoveryInfo protocol is quite flexible (
> http://mesos.apache.org/documentation/latest/app-framework-development-guide/
> ).
>
> Thanks,
> Stephan
>
>
> ________________________________________
> From: Zhitao Li <zh...@gmail.com>
> Sent: Monday, March 7, 2016 00:05
> To: dev@aurora.apache.org
> Subject: Populate DiscoveryInfo in Mesos
>
> Hi,
>
> It seems like Aurora does not populate the "discovery" field in either
> TaskInfo or ExecutorInfo in mesos.proto
> <
> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438
> >
> .
>
> I'm considering adding this to support retrieving port map in Mesos
> directly. This would enable us to discovery this information directly from
> Mesos side, and also enables us to build one universal service discovery
> solution for multiple frameworks including Aurora.
>
> If no objection, I'll create a JIRA ticket for this task.
>
> Thanks.
> --
> Cheers,
>
> Zhitao Li
>
--
Cheers,
Zhitao Li
Re: Populate DiscoveryInfo in Mesos
Posted by "Erb, Stephan" <St...@blue-yonder.com>.
That sounds like a good idea! Great.
If you go ahead with this, please be so kind and start by posting a short design document here on mailinglist (similar to those here https://github.com/apache/aurora/blob/master/docs/design-documents.md, but probably shorter).
This will allow us to split the discussion of the design from discussing the actual implementation. I believe this is necessary, as the DiscoveryInfo protocol is quite flexible (http://mesos.apache.org/documentation/latest/app-framework-development-guide/).
Thanks,
Stephan
________________________________________
From: Zhitao Li <zh...@gmail.com>
Sent: Monday, March 7, 2016 00:05
To: dev@aurora.apache.org
Subject: Populate DiscoveryInfo in Mesos
Hi,
It seems like Aurora does not populate the "discovery" field in either
TaskInfo or ExecutorInfo in mesos.proto
<https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L438>
.
I'm considering adding this to support retrieving port map in Mesos
directly. This would enable us to discovery this information directly from
Mesos side, and also enables us to build one universal service discovery
solution for multiple frameworks including Aurora.
If no objection, I'll create a JIRA ticket for this task.
Thanks.
--
Cheers,
Zhitao Li