Xuhan, check the other thread - would 1500UTC suit?
On 19 December 2013 01:09, Xuhan Peng <pengxu...@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.ubu...@cack.org.uk> wrote: >> >> On 18 December 2013 14:10, Shixiong Shang >> <sparkofwisdom.cl...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev