> Agreed, testing options is good; and should likely be disjoint from the legal > questions around mongodb... > > Although if there is really only one viable & scalable option and that option > has legal usage questions surrounding it then it makes me wonder how much we > are kidding ourselves on there being anything optional about this... Not > something I can answer but someone likely should?.?. > > I guess it really depends on what the desired outcome of testing with mongodb > is, if the outcome is to satisfy a TC requirement for improved testing via > *any* backend then this would seem applicable. If instead it's around > testing a backend that isn't legally encumbered (and is also realistically > viable to use) then we are in a different area altogether...
Usual IANAL caveats, I just want to ensure that some code that's used in the wild to also be tested upstream :) So as stated in response to Devananda, I'm happy for this change to have more the character of an *expansion* in overall coverage, as opposed to an *exchange* of one type of coverage for another. Assuming of course that the QA/infra side of the house are willing to accommodate that, it would seem to satisfy both requirements? Not to open another hornet's nest, but note that there is actually a third opensource option for ceilometer storage, in the form of the hbase driver (Apache 2.0 being the applicable license for the backend in this case). In performance testing done by Ilya Tyaptin, this backend shows same-ballpark performance characteristics to mongodb. Cheers, Eoghan > Just my 2cents. > > Sent from my really tiny device... > > > On Aug 9, 2014, at 10:53 AM, "Eoghan Glynn" <egl...@redhat.com> wrote: > > > > > > > >> +2 from me, > >> > >> More mongodb adoption (as stated) when it's questionable legally doesn't > >> seem > >> like a good long term strategy (I know it will/does impact yahoo adopting > >> or > >> using ceilometer...). Is this another one of those tactical changes that > >> we > >> keep on making that ends up being yet another piece of technical debt that > >> someone will have to cleanup :-/ > >> > >> If we thought a little more about this strategically maybe we would end up > >> in > >> a better place short term *and* long term?? > > > > Hi Joshua, > > > > Since we currently do support mongodb as an *optional* storage driver, > > and some distros do recommend its usage, then surely we should test this > > driver fully in the upstream gate to support those users who take that > > option? > > > > (i.e. those users who accept MongoDB Inc's assurances[1] in regard to > > licensing of the client-side driver) > > > > Cheers, > > Eohgan > > > > [1] http://www.mongodb.org/about/licensing/ > > > > _______________________________________________ > > 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
