Re: [Openstack] Monitoring / Billing Architecture proposed
Hi, Although metering and billing always comes together for the deployment, for the sake of clarity, I also think metering should be a separate project from the billing, especially in openstack. (As you mentioned it, billing is complex and has too many different requirements per provider) Anyway, I am really interested in weekly meeting you mentioned in the email. How can I join the meeting? Is it irc-meeting?, mailing-list?, or else? -- Jaesuk Ahn, Ph.D. Team Leader | Cloud OS Dev. Team Cloud Infrastructure Department KT (Korea Telecom) T. +82-10-9888-0328 | F. +82-303-0993-5340 Active member on OpenStack Korea Community Apr 23, 2012, 4:09 PM, Nick Barcet 작성: Hello Luis, I presented a blueprint last week [1] which proposes to clearly differentiate metering from the overall billing process. It is my understanding that billing is too complex a beast to be solved for each requirement in a satisfactory way and have therefore proposed that we should first concentrate on collecting the informations necessary for billing systems to pull their information from. The blueprint, and the discussion we had at the summit last week, outlines a proposed architecture but has, so far, left open the component choices to implement it. It is our proposal to start a a weekly meeting from that week to start selecting the components to deliver this. You are more than welcome to join the project if you want. [1] http://wiki.openstack.org/EfficientMetering Best regards, Nick On 04/22/2012 08:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ mailto:luis.gerv...@gmail.comwoorea.es http://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Remote participation from Design Summit (and conference)
Does anyone know if there is an etherpad link for scalinng openstack session today? I cannot find on wiki or anywhere else. Thank you. Apr 17, 2012, 8:57 AM, Dan Wendlandt 작성: On Mon, Apr 16, 2012 at 3:59 PM, Piyanai Saowarattitada pns...@gmail.com wrote: http://etherpad.openstack.org/quantum-folsom = Quantum track especially - not listed on the main folsom summit etherpads wiki added it this morning... should be up there. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Jaesuk Ahn, Ph.D. Team Leader | Cloud OS Dev. Team Cloud Infrastructure Department KT (Korea Telecom) T. +82-10-9888-0328 | F. +82-303-0993-5340 Active member on OpenStack Korea Community ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Question on i8ln?
We have a small discussion at OpenStack Korea Community about logging in local language. Most of participants said that they prefers having logging message in English only. Reasons are: 1. Logging messages are searchable keywords. Having a single entry point for searching is important. 2. Keeping the exact translation for logging message is very important for the localization. It is not an easy task to do. Suggestions are: - It would be helpful if we can have a place (website) to look-up for the translation. - It would be good if each error message has corresponding error code, and a look-up website to search for localized translation with the error-code. - It is also possible that we can have an option to generate localized error message along with original English message. - Having an official website to put feedback, related information, possible cause of error message in various languages is more important than having translated logging message. This is just an opinion from small set of developers in Korea Community. We are happy to join a discussion on this subject at Folsom design summit, or we can try to gather much broader consensus on this subject within Korea Community. Cheers, -- Jaesuk Ahn, Ph.D. Team Leader | Cloud OS Dev. Team Cloud Infrastructure Department KT (Korea Telecom) T. +82-10-9888-0328 | F. +82-303-0993-5340 Active member on OpenStack Korea Community Feb 20, 2012, 7:39 PM, Thierry Carrez 작성: Diego Parrilla Santamaría wrote: Joshua, most of non-english speaking developers I know try to use english for class names, methods, fields, constants... English is the 'lingua franca' for code, so even developers with bad english level like me try to use english all the time... so internationalized logging messages do not make sense from my perspective. And sometimes translations are awful, or even hilarious. So +1 for english only logging messages in the code. Currently only Nova is set up for message translations (through Launchpad Rosetta [1]). We used to have 100% coverage in Japanese and French, and good Spanish coverage. Today the coverage dropped to 20%. I agree that it has value only if done properly and across the board. The original translations effort was pushed by the Japanese community to get Japanese errors in logs. We should definitely have a discussion at the Folsom design summit to get some consistency in core projects in that area. [1] https://translations.launchpad.net/nova -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
