Open Stack

Xuhan, check the other thread - would 1500UTC suit?


On 19 December 2013 01:09, Xuhan Peng <pengxuhan at gmail.com> wrote:

> Shixiong and guys,
>
> The sub team meeting is too early for china IBM folks to join although we
> would like to participate the discussion very much. Any chance to rotate
> the time so we can comment?
>
> Thanks, Xuhan
>
>
> On Thursday, December 19, 2013, Shixiong Shang wrote:
>
>> Hi, Ian:
>>
>> I agree with you on the point that the way we implement it should be app
>> agnostic. In addition, it should cover both CLI and Dashboard, so the
>> system behavior should be consistent to end users.
>>
>> The keywords is just one of the many ways to implement the concept. It is
>> based on the reality that dnsmasq is the only driver available today to the
>> community. By the end of the day, the input from customer should be
>> translated to one of those mode keywords. It doesn't imply the same
>> constants have to be used as part of the CLI or Dashboard.
>>
>> Randy and I had lengthy discussion/debating about this topic today. We
>> have straw-man proposal and will share with the team tomorrow.
>>
>> That being said, what concerned me the most at this moment is, we are not
>> on the same page. I hope tomorrow during sub-team meeting, we can reach
>> consensus. If you can not make it, then please set up a separate meeting to
>> invite key placeholders so we have a chance to sort it out.
>>
>> Shixiong
>>
>>
>>
>>
>> On Dec 18, 2013, at 8:25 AM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:
>>
>> On 18 December 2013 14:10, Shixiong Shang <sparkofwisdom.cloud at gmail.com>wrote:
>>
>>> Hi, Ian:
>>>
>>> I won’t say the intent here is to replace dnsmasq-mode-keyword BP.
>>> Instead, I was trying to leverage and enhance those definitions so when
>>> dnsmasq is launched, it knows which mode it should run in.
>>>
>>> That being said, I see the value of your points and I also had lengthy
>>> discussion with Randy regarding this. We did realize that the keyword
>>> itself may not be sufficient to properly configure dnsmasq.
>>>
>>
>> I think the point is that the attribute on whatever object (subnet or
>> router) that defines the behaviour should define the behaviour, in
>> precisely the terms you're talking about, and then we should find the
>> dnsmasq options to suit.  Talking to Sean, he's good with this too, so
>> we're all working to the same ends and it's just a matter of getting code
>> in.
>>
>>
>>> Let us discuss that on Thursday’s IRC meeting.
>>>
>>
>> Not sure if I'll be available or not this Thursday, unfortunately.  I'll
>> try to attend but I can't make promises.
>>
>> Randy and I had a quick glance over your document. Much of it parallels
>>> the work we did on our POC last summer, and is now being addressed across
>>> multiple BP being implemented by ourselves or with Sean Collins and IBM
>>> team's work. I will take a closer look and provide my comments.
>>>
>>
>> That's great.  I'm not wedded to the details in there, I'm actually more
>> interested that we've covered everything.
>>
>> If you have blueprint references, add them as comments - the
>> ipv6-feature-parity BP could do with work and if we get the links together
>> in one place we can update it.
>> --
>> Ian.
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131220/e85bf50e/attachment.html>