Open Stack

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<javascript:_e({}, 'cvml', 'ijw.ubuntu at cack.org.uk');>>
> wrote:
>
> On 18 December 2013 14:10, Shixiong Shang <sparkofwisdom.cloud at gmail.com<javascript:_e({}, 'cvml', '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 <javascript:_e({}, 'cvml',
> '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/20131219/3aafadde/attachment.html>