Dear Eoghan, Thanks for your comments. Although you are correct that rating, charging, and billing policies are commercially sensitive to the operators, still if an operator has an openstack installation, I do not see why the stack could not offer a service that supports ways for the operator to input desired policies, rules, etc to do charging and billing out of the box. These policies could still only be accessible to the operator.
Furthermore, one could envision that using heat together with some django magic, this could even be offered as a service for tenants of the operators who could be distributors or resellers in his client ecosystem, allowing them to set their own custom policies. I believe such stack based solution would be very much welcome by SMEs, new entrants, etc. I am planning to attend the Kilo summit in Paris, and I would be very glad to talk with you and others on this idea and on Cyclops :) Forking the codebase to stackforge is something which is definitely possible and thanks a lot for suggesting it. Looking forward to more constructive discussions on this with you and others. Kind regards, Piyush. _______________________________________ Dr. Piyush Harsh, Ph.D. Researcher, InIT Cloud Computing Lab Zurich University of Applied Sciences (ZHAW) [Site] http://piyush-harsh.info [Research Lab] http://www.cloudcomp.ch/ Fax: +41(0)58.935.7403 GPG Keyid: 9C5A8838 On Fri, Aug 8, 2014 at 12:01 AM, Eoghan Glynn <egl...@redhat.com> wrote: > > > > > Dear All, > > > > Let me use my first post to this list to introduce Cyclops and initiate a > > discussion towards possibility of this platform as a future incubated > > project in OpenStack. > > > > We at Zurich university of Applied Sciences have a python project in open > > source (Apache 2 Licensing) that aims to provide a platform to do > > rating-charging-billing over ceilometer. We call is Cyclops (A Charging > > platform for OPenStack CLouds). > > > > The initial proof of concept code can be accessed here: > > https://github.com/icclab/cyclops-web & > > https://github.com/icclab/cyclops-tmanager > > > > Disclaimer: This is not the best code out there, but will be refined and > > documented properly very soon! > > > > A demo video from really early days of the project is here: > > https://www.youtube.com/watch?v=ZIwwVxqCio0 and since this video was > made, > > several bug fixes and features were added. > > > > The idea presentation was done at Swiss Open Cloud Day at Bern and the > talk > > slides can be accessed here: > > http://piyush-harsh.info/content/ocd-bern2014.pdf , and more recently > the > > research paper on the idea was published in 2014 World Congress in > Computer > > Science (Las Vegas), which can be accessed here: > > http://piyush-harsh.info/content/GCA2014-rcb.pdf > > > > I was wondering, if our effort is something that OpenStack > > Ceilometer/Telemetry release team would be interested in? > > > > I do understand that initially rating-charging-billing service may have > been > > left out by choice as they would need to be tightly coupled with existing > > CRM/Billing systems, but Cyclops design (intended) is distributed, > service > > oriented architecture with each component allowing for possible > integration > > with external software via REST APIs. And therefore Cyclops by design is > > CRM/Billing platform agnostic. Although Cyclops PoC implementation does > > include a basic bill generation module. > > > > We in our team are committed to this development effort and we will have > > resources (interns, students, researchers) work on features and improve > the > > code-base for a foreseeable number of years to come. > > > > Do you see a chance if our efforts could make in as an incubated project > in > > OpenStack within Ceilometer? > > Hi Piyush, > > Thanks for bringing this up! > > I should preface my remarks by setting out a little OpenStack > history, in terms of the original decision not to include the > rating and billing stages of the pipeline under the ambit of > the ceilometer project. > > IIUC, the logic was that such rating/billing policies were very > likely to be: > > (a) commercially sensitive for competing cloud operators > > and: > > (b) already built-out via existing custom/proprietary systems > > The folks who were directly involved at the outset of ceilometer > can correct me if I've misrepresented the thinking that pertained > at the time. > > While that logic seems to still apply, I would be happy to learn > more about the work you've done already on this, and would be > open to hearing arguments for and against. Are you planning to > attend the Kilo summit in Paris (Nov 3-7)? If so, it would be a > good opportunity to discuss further in person. > > In the meantime, stackforge provides a low-bar-to-entry for > projects in the OpenStack ecosystem that may, or may not, end up > as incubated projects or as dependencies taken by graduated > projects. So you might consider moving your code there? > > Cheers, > Eoghan > > > > > I really would like to hear back from you, comments, suggestions, etc. > > > > Kind regards, > > Piyush. > > _______________________________________ > > Dr. Piyush Harsh, Ph.D. > > Researcher, InIT Cloud Computing Lab > > Zurich University of Applied Sciences (ZHAW) > > [Site] http://piyush-harsh.info > > [Research Lab] http://www.cloudcomp.ch/ > > Fax: +41(0)58.935.7403 GPG Keyid: 9C5A8838 > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStackemail@example.com > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev