It is up to Sean to make the call, but I would love to see IBM team in the meeting.
On Dec 18, 2013, at 7:09 PM, Xuhan Peng <[email protected]> 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 <[email protected]> wrote: > >> On 18 December 2013 14:10, Shixiong Shang <[email protected]> >> 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 >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
