Re: [Openstack-doc-core] Welcome to doc-core Russell Bryant!
Welcome in Russell! :) Nuage Co - Razique Mahrouarazique.mahr...@gmail.com Le 30 avr. 2012 à 18:45, Lorin Hochstein a écrit :On Apr 30, 2012, at 11:23 AM, Anne Gentle wrote:Hi all -I've invited Russell Bryant to join our ranks and he has graciously accepted. Welcome Russell! Thanks for all you've done so far with reviews, markup conventions, and content additions. Warmly, Anne Welcome aboard!Take care,Lorin--Lorin HochsteinLead Architect - Cloud ServicesNimbis Services, Inc.www.nimbisservices.com-- Mailing list: https://launchpad.net/~openstack-doc-corePost to : openstack-doc-core@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstack-doc-coreMore help : https://help.launchpad.net/ListHelp-- Mailing list: https://launchpad.net/~openstack-doc-core Post to : openstack-doc-core@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-doc-core More help : https://help.launchpad.net/ListHelp
Re: [Openstack] i18n of log message
Hi 彭勇, On 01/05/12 03:38, 彭勇 wrote: the log messages of OpenStack are i18n now. i propose to use english only log messages: 1. if any one have problem, they can shared with others more easy. he can search english message, and send message to maillist. if the log message is i18n, a Chinese version message can't shared to Japanese. 2. if we have i18n log message, it's hard to update log message. we should update every localization version of message. This was all actually covered in the i18n talk at the developer's summit: http://etherpad.openstack.org/FolsomI18N The information in there says mailing list says no, feedback from session says yes (especially requested by operators in china) - need a vote? compare to apache projects... I do also remember a suggestion of translated error messages and a common error code (such as NOV1234 I guess?) to use in places such as a Google search (such as MySQL does). You could then search for the translated error message or the code if you feel your language skills are good enough to get multi-lingual results. Since we are going to be reworking i18n very soon I suspect feedback would be welcome. Kind Regards -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ ___ 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] i18n of log message
2012/5/1 Andrew Hutchings and...@linuxjedi.co.uk Hi 彭勇, On 01/05/12 03:38, 彭勇 wrote: the log messages of OpenStack are i18n now. i propose to use english only log messages: 1. if any one have problem, they can shared with others more easy. he can search english message, and send message to maillist. if the log message is i18n, a Chinese version message can't shared to Japanese. 2. if we have i18n log message, it's hard to update log message. we should update every localization version of message. This was all actually covered in the i18n talk at the developer's summit: http://etherpad.openstack.org/FolsomI18N The information in there says mailing list says no, feedback from session says yes (especially requested by operators in china) - need a vote? compare to apache projects... we are guys in China. we have a openstack group more than 500 members. we can promote a vote for this I do also remember a suggestion of translated error messages and a common error code (such as NOV1234 I guess?) to use in places such as a Google search (such as MySQL does). You could then search for the translated error message or the code if you feel your language skills are good enough to get multi-lingual results. Oracle handle error message this way, for example: ORA-01000: maximum open cursors exceeded it's hard to maintain multi-lingual log message for open source project. Since we are going to be reworking i18n very soon I suspect feedback would be welcome. Kind Regards -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- 彭勇 (Peng Yong) ___ 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] i18n of log message
I would also vote for an application prefix and error number for easy searching. It is also great when you have to write the problem determination guides. Tim -Original Message- From: openstack-bounces+tim.bell=cern...@lists.launchpad.net [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf Of ?? Sent: 01 May 2012 10:47 To: Andrew Hutchings Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] i18n of log message 2012/5/1 Andrew Hutchings and...@linuxjedi.co.uk Hi 彭勇, On 01/05/12 03:38, 彭勇 wrote: the log messages of OpenStack are i18n now. i propose to use english only log messages: 1. if any one have problem, they can shared with others more easy. he can search english message, and send message to maillist. if the log message is i18n, a Chinese version message can't shared to Japanese. 2. if we have i18n log message, it's hard to update log message. we should update every localization version of message. This was all actually covered in the i18n talk at the developer's summit: http://etherpad.openstack.org/FolsomI18N The information in there says mailing list says no, feedback from session says yes (especially requested by operators in china) - need a vote? compare to apache projects... we are guys in China. we have a openstack group more than 500 members. we can promote a vote for this I do also remember a suggestion of translated error messages and a common error code (such as NOV1234 I guess?) to use in places such as a Google search (such as MySQL does). You could then search for the translated error message or the code if you feel your language skills are good enough to get multi-lingual results. Oracle handle error message this way, for example: ORA-01000: maximum open cursors exceeded it's hard to maintain multi-lingual log message for open source project. Since we are going to be reworking i18n very soon I suspect feedback would be welcome. Kind Regards -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- 彭勇 (Peng Yong) ___ 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] [Metering] schema and counter definitions
On 04/30/2012 11:39 PM, Doug Hellmann wrote: On Mon, Apr 30, 2012 at 3:43 PM, Loic Dachary l...@enovance.com mailto:l...@enovance.com wrote: On 04/30/2012 08:03 PM, Doug Hellmann wrote: On Mon, Apr 30, 2012 at 11:43 AM, Loic Dachary l...@enovance.com mailto:l...@enovance.com wrote: On 04/30/2012 03:49 PM, Doug Hellmann wrote: On Mon, Apr 30, 2012 at 6:46 AM, Loic Dachary l...@enovance.com mailto:l...@enovance.com wrote: On 04/30/2012 12:15 PM, Loic Dachary wrote: We could start a discussion from the content of the following sections: http://wiki.openstack.org/EfficientMetering#Counters I think the rationale of the counter aggregation needs to be explained. My understanding is that the metering system will be able to deliver the following information: 10 floating IPv4 addresses were allocated to the tenant during three months and were leased from provider NNN. From this, the billing system could add a line to the invoice : 10 IPv4, $N each = $10xN because it has been configured to invoice each IPv4 leased from provider NNN for $N. It is not the purpose of the metering system to display each IPv4 used, therefore it only exposes the aggregated information. The counters define how the information should be aggregated. If the idea was to expose each resource usage individually, defining counters would be meaningless as they would duplicate the activity log from each OpenStack component. What do you think ? At DreamHost we are going to want to show each individual resource (the IPv4 address, the instance, etc.) along with the charge information. Having the metering system aggregate that data will make it difficult/impossible to present the bill summary and detail views that we want. It would be much more useful for us if it tracked the usage details for each resource, and let us aggregate the data ourselves. If other vendors want to show the data differently, perhaps we should provide separate APIs for retrieving the detailed and aggregate data. Doug Hi, For the record, here is the unfinished conversation we had on IRC (04:29:06 PM) dhellmann: dachary, did you see my reply about counter definitions on the list today? (04:39:05 PM) dachary: It means some counters must not be aggregated. Only the amount associated with it is but there is one counter per IP. (04:55:01 PM) dachary: dhellmann: what about this :the id of the ressource controls the agregation of all counters : if it is missing, all resources of the same kind and their measures are aggregated. Otherwise only the measures are agreggated. http://wiki.openstack.org/EfficientMetering?action=diffrev2=40rev1=39 http://wiki.openstack.org/EfficientMetering?action=diffrev2=40rev1=39 (04:55:58 PM) dachary: it makes me a little unconfortable to define such an ad-hoc grouping (04:56:53 PM) dachary: i.e. you actuall control the aggregation by chosing which value to put in the id column (04:58:43 PM) dachary: s/actuall/actually/ (05:05:38 PM) ***dachary reading http://www.ogf.org/documents/GFD.98.pdf (05:05:54 PM) dachary: I feel like we're trying to resolve a non problem here (05:08:42 PM) dachary: values need to be aggregated. The raw input is a full description of the resource and a value ( gauge ). The question is how to control the aggregation in a reasonably flexible way. (05:11:34 PM) dachary: The definition of a counter could probably be described as : the id of a resource and code to fill each column associated with it. I tried to append the following, but the wiki kept failing. Propose that the counters are defined by a function instead of being fixed. That helps addressing the issue of aggregating the bandwidth associated to a given IP into a single counter. Alternate idea : * a counter is defined by * a name ( o1, n2, etc. ) that uniquely identifies the nature of the measure ( outbound internet transit, amount of RAM, etc. ) * the component in which it can be found ( nova, swift etc.) * and by columns, each one is set with the result of aggregate(find(record),record) where * find() looks for the existing column as found by selecting with the unique key ( maybe the name and the resource id ) * record is a detailed description of the metering event to be aggregated ( http://wiki.openstack.org/SystemUsageData#compute.instance.exists: ) * the aggregate() function returns the updated row. By default it just += the counter value with the old row returned by find() Would we want aggregation to occur within the database where we are collecting events, or should that move somewhere else?
[Openstack] Reminder: OpenStack Project meeting - 21:00 UTC
Hello everyone, Our weekly project release status meeting will take place at 21:00 UTC this Tuesday in #openstack-meeting on IRC. PTLs who can't make it should name a substitute on [2]. We'll look into Folsom plans and more specifically folsom-1 targets, for projects that already defined objectives. You can doublecheck what 21:00 UTC means for your timezone at [1]: [1] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20120501T21 See the meeting agenda, edit the wiki to add new topics for discussion: [2] http://wiki.openstack.org/Meetings/ProjectMeeting Cheers, -- 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
Re: [Openstack] [Nova] RPC API Versioning Prototype
On 04/30/2012 08:11 PM, Vishvananda Ishaya wrote: Looking good. A few points: a) can we just do hasattr dispatch instead of isinstance. it seems more pythonic than forcing the use of the dispatcher base class Sounds good. b) it seems like we should make the dispatcher pick version 1.0 instead of failing if version is not passed in, that way a new dispatcher could handle unversioned messages. Or did i miss some other magic way this is happening. Good point. Otherwise, *all* messages from an Essex install would be rejected from a newer version using rpc versioning even if it could handle it properly. Thanks for the feedback! -- Russell Bryant ___ 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] URL Scheme for deploying Openstack in HTTPD
Can we get this on the Agenda for todays meeting, take an informal poll, and formalize it? If So, I'll write it up and post on the wiki. On 04/30/2012 05:29 PM, Dolph Mathews wrote: On Apr 30, 2012, at 3:20 PM, Daniel P. Berrangeberra...@redhat.com wrote: On Mon, Apr 30, 2012 at 01:58:24PM -0500, Dolph Mathews wrote: I very much like the idea that we should have a well documented recommendation on this topic. My only criticism is that the API/service names should be used in place of project names, e.g. https://hostname/identity, https://hostname/compute, etc. Why do you think that is better ? I've been switching back forth on this topic unable to figure out which is a better long term bet. Trying to think of downsides, I come up with the thought of what happens if we wwant to support multiple different compute or identity APIs on the same host. From a namespacing POV it seems better to use the names based off the openstack component name, rather than generic logical function which has higher potential for clashing. This lead me to prefer what Adam proposes below. Keystone and Horizon are the two best reasons why -- they're the most likely to be re-implemented by third parties, which means they'll naturally want to brand their endpoints accordingly (thus defeating the goal of the recommendation), e.g. http://hostname/specialsauth Sticking with /identity means people know where to go, and at least vaguely what to expect when they get there. Finally, OpenStack consumers shouldn't have to understand our project names prior to understanding our API. Regarding multiple different 'compute' or 'identity' API's on the same host ... Isn't that the same problem that multiple choice responses and versioned endpoints already solve? On Mon, Apr 30, 2012 at 11:34 AM, Adam Youngayo...@redhat.com wrote: A production configuration of Openstack should be able to run in HTTPD using SSL. I'd like to propose the following URL scheme for the web Apps so that the various pieces can be installed on a single machine without conflict. All pieces will be served on port 443 using the https protocol. I think this is tangential to the main point of the proposal. Even if every service was on its own plain HTTP port, I would still suggest that this namespace proposal be followed by them to give consistency. I've written these up to use the project names. Enough documentation and information around the projects has circulated such that replacing, say, Keystone with identity would cause more confusion than it would remove. #Web UI #If and only if this is installed, we should put in a forward from / to /dashboard for browser clients. https://hostname/dashboard #identity https://hostname/keystone/main https://hostname/keystone/admin #image https://hostname/glance/api https://hostname/glance/registry #compute. Not sure if all of these are required https://hostname/nova/api https://hostname/nova/crt https://hostname/nova/object https://hostname/nova/cpu https://hostname/nova/network https://hostname/nova/volume https://hostname/nova/schedule https://hostname/nova/novnc https://hostname/nova/vncx https://hostname/nova/cauth #network https://hostname/quantum/apihttps://hostname/quantum/service #if we had an API for the agent it would be https://hostname/quantum/agenthttps://hostname/quantum/service There was an attempt to make Swift also fit into this scheme. However, Swift URLs fall into a scheme of their own, and won't likely be colocated with the admin pieces outside of development. Here they are for completeness. #storage https://hostname/swift/account https://hostname/swift/object https://hostname/swift/container In general I think this proposal is sound. Having clearly distinct namespaces for each component's API(s) is general good practice, to allow arbitrary co-location of services on the same host/port. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ 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] [Metering] schema and counter definitions
On 05/01/2012 02:23 AM, Loic Dachary wrote: On 04/30/2012 11:39 PM, Doug Hellmann wrote: On Mon, Apr 30, 2012 at 3:43 PM, Loic Dachary l...@enovance.com mailto:l...@enovance.com wrote: On 04/30/2012 08:03 PM, Doug Hellmann wrote: On Mon, Apr 30, 2012 at 11:43 AM, Loic Dachary l...@enovance.com mailto:l...@enovance.com wrote: On 04/30/2012 03:49 PM, Doug Hellmann wrote: On Mon, Apr 30, 2012 at 6:46 AM, Loic Dachary l...@enovance.com mailto:l...@enovance.com wrote: On 04/30/2012 12:15 PM, Loic Dachary wrote: We could start a discussion from the content of the following sections: http://wiki.openstack.org/EfficientMetering#Counters I think the rationale of the counter aggregation needs to be explained. My understanding is that the metering system will be able to deliver the following information: 10 floating IPv4 addresses were allocated to the tenant during three months and were leased from provider NNN. From this, the billing system could add a line to the invoice : 10 IPv4, $N each = $10xN because it has been configured to invoice each IPv4 leased from provider NNN for $N. It is not the purpose of the metering system to display each IPv4 used, therefore it only exposes the aggregated information. The counters define how the information should be aggregated. If the idea was to expose each resource usage individually, defining counters would be meaningless as they would duplicate the activity log from each OpenStack component. What do you think ? At DreamHost we are going to want to show each individual resource (the IPv4 address, the instance, etc.) along with the charge information. Having the metering system aggregate that data will make it difficult/impossible to present the bill summary and detail views that we want. It would be much more useful for us if it tracked the usage details for each resource, and let us aggregate the data ourselves. If other vendors want to show the data differently, perhaps we should provide separate APIs for retrieving the detailed and aggregate data. Doug Hi, For the record, here is the unfinished conversation we had on IRC (04:29:06 PM) dhellmann: dachary, did you see my reply about counter definitions on the list today? (04:39:05 PM) dachary: It means some counters must not be aggregated. Only the amount associated with it is but there is one counter per IP. (04:55:01 PM) dachary: dhellmann: what about this :the id of the ressource controls the agregation of all counters : if it is missing, all resources of the same kind and their measures are aggregated. Otherwise only the measures are agreggated. http://wiki.openstack.org/EfficientMetering?action=diffrev2=40rev1=39 http://wiki.openstack.org/EfficientMetering?action=diffrev2=40rev1=39 (04:55:58 PM) dachary: it makes me a little unconfortable to define such an ad-hoc grouping (04:56:53 PM) dachary: i.e. you actuall control the aggregation by chosing which value to put in the id column (04:58:43 PM) dachary: s/actuall/actually/ (05:05:38 PM) ***dachary reading http://www.ogf.org/documents/GFD.98.pdf (05:05:54 PM) dachary: I feel like we're trying to resolve a non problem here (05:08:42 PM) dachary: values need to be aggregated. The raw input is a full description of the resource and a value ( gauge ). The question is how to control the aggregation in a reasonably flexible way. (05:11:34 PM) dachary: The definition of a counter could probably be described as : the id of a resource and code to fill each column associated with it. I tried to append the following, but the wiki kept failing. Propose that the counters are defined by a function instead of being fixed. That helps addressing the issue of aggregating the bandwidth associated to a given IP into a single counter. Alternate idea : * a counter is defined by * a name ( o1, n2, etc. ) that uniquely identifies the nature of the measure ( outbound internet transit, amount of RAM, etc. ) * the component in which it can be found ( nova, swift etc.) * and by columns, each one is set with the result of aggregate(find(record),record) where * find() looks for the existing column as found by selecting with the unique key ( maybe the
[Openstack] Documentation: pdf link missing
The pdf icon in this link is not working. http://docs.openstack.org/trunk/openstack-compute/admin/content/ Paras. ___ 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] Documentation: pdf link missing
Thanks Paras, this is a doc bug that keeps resurrecting itself. Opening https://bugs.launchpad.net/openstack-manuals/+bug/992652 Today I'm cutting an Essex release for the docs so I'll be sure to address this, thanks. Anne On Tue, May 1, 2012 at 9:51 AM, Paras pradhan pradhanpa...@gmail.comwrote: The pdf icon in this link is not working. http://docs.openstack.org/trunk/openstack-compute/admin/content/ Paras. ___ 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] Documentation: pdf link missing
Great Thanks. BTW are there another formats available? Like chm. Paras. On Tue, May 1, 2012 at 10:08 AM, Anne Gentle a...@openstack.org wrote: Thanks Paras, this is a doc bug that keeps resurrecting itself. Opening https://bugs.launchpad.net/openstack-manuals/+bug/992652 Today I'm cutting an Essex release for the docs so I'll be sure to address this, thanks. Anne On Tue, May 1, 2012 at 9:51 AM, Paras pradhan pradhanpa...@gmail.com wrote: The pdf icon in this link is not working. http://docs.openstack.org/trunk/openstack-compute/admin/content/ Paras. ___ 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] Documentation: pdf link missing
We have a somewhat working epub output, but CHM is not on the list in the future. It's deprecated by Microsoft. Is there an offline, compressed HTML need that you have? Let me hear more about your need. Here's the info about epub: http://www.openstack.org/blog/2011/11/hacking-on-ebooks/ We'll be hacking on epub and mobi again at Rackspace in May - all are welcome to work on the Cloud docs plugin at https://github.com/rackspace/clouddocs-maven-plugin to improve the output. Thanks, Anne On Tue, May 1, 2012 at 10:25 AM, Paras pradhan pradhanpa...@gmail.comwrote: Great Thanks. BTW are there another formats available? Like chm. Paras. On Tue, May 1, 2012 at 10:08 AM, Anne Gentle a...@openstack.org wrote: Thanks Paras, this is a doc bug that keeps resurrecting itself. Opening https://bugs.launchpad.net/openstack-manuals/+bug/992652 Today I'm cutting an Essex release for the docs so I'll be sure to address this, thanks. Anne On Tue, May 1, 2012 at 9:51 AM, Paras pradhan pradhanpa...@gmail.com wrote: The pdf icon in this link is not working. http://docs.openstack.org/trunk/openstack-compute/admin/content/ Paras. ___ 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] [Metering] schema and counter definitions
On 05/01/2012 04:38 PM, Nick Barcet wrote: On 05/01/2012 02:23 AM, Loic Dachary wrote: On 04/30/2012 11:39 PM, Doug Hellmann wrote: On Mon, Apr 30, 2012 at 3:43 PM, Loic Dachary l...@enovance.com mailto:l...@enovance.com wrote: On 04/30/2012 08:03 PM, Doug Hellmann wrote: On Mon, Apr 30, 2012 at 11:43 AM, Loic Dachary l...@enovance.com mailto:l...@enovance.com wrote: On 04/30/2012 03:49 PM, Doug Hellmann wrote: On Mon, Apr 30, 2012 at 6:46 AM, Loic Dachary l...@enovance.com mailto:l...@enovance.com wrote: On 04/30/2012 12:15 PM, Loic Dachary wrote: We could start a discussion from the content of the following sections: http://wiki.openstack.org/EfficientMetering#Counters I think the rationale of the counter aggregation needs to be explained. My understanding is that the metering system will be able to deliver the following information: 10 floating IPv4 addresses were allocated to the tenant during three months and were leased from provider NNN. From this, the billing system could add a line to the invoice : 10 IPv4, $N each = $10xN because it has been configured to invoice each IPv4 leased from provider NNN for $N. It is not the purpose of the metering system to display each IPv4 used, therefore it only exposes the aggregated information. The counters define how the information should be aggregated. If the idea was to expose each resource usage individually, defining counters would be meaningless as they would duplicate the activity log from each OpenStack component. What do you think ? At DreamHost we are going to want to show each individual resource (the IPv4 address, the instance, etc.) along with the charge information. Having the metering system aggregate that data will make it difficult/impossible to present the bill summary and detail views that we want. It would be much more useful for us if it tracked the usage details for each resource, and let us aggregate the data ourselves. If other vendors want to show the data differently, perhaps we should provide separate APIs for retrieving the detailed and aggregate data. Doug Hi, For the record, here is the unfinished conversation we had on IRC (04:29:06 PM) dhellmann: dachary, did you see my reply about counter definitions on the list today? (04:39:05 PM) dachary: It means some counters must not be aggregated. Only the amount associated with it is but there is one counter per IP. (04:55:01 PM) dachary: dhellmann: what about this :the id of the ressource controls the agregation of all counters : if it is missing, all resources of the same kind and their measures are aggregated. Otherwise only the measures are agreggated. http://wiki.openstack.org/EfficientMetering?action=diffrev2=40rev1=39 http://wiki.openstack.org/EfficientMetering?action=diffrev2=40rev1=39 (04:55:58 PM) dachary: it makes me a little unconfortable to define such an ad-hoc grouping (04:56:53 PM) dachary: i.e. you actuall control the aggregation by chosing which value to put in the id column (04:58:43 PM) dachary: s/actuall/actually/ (05:05:38 PM) ***dachary reading http://www.ogf.org/documents/GFD.98.pdf (05:05:54 PM) dachary: I feel like we're trying to resolve a non problem here (05:08:42 PM) dachary: values need to be aggregated. The raw input is a full description of the resource and a value ( gauge ). The question is how to control the aggregation in a reasonably flexible way. (05:11:34 PM) dachary: The definition of a counter could probably be described as : the id of a resource and code to fill each column associated with it. I tried to append the following, but the wiki kept failing. Propose that the counters are defined by a function instead of being fixed. That helps addressing the issue of aggregating the bandwidth associated to a given IP into a single counter. Alternate idea : * a counter is defined by * a name ( o1, n2, etc. ) that uniquely identifies the nature of the measure ( outbound internet transit, amount of RAM, etc. ) * the component in which it can be found ( nova, swift etc.) * and by columns, each one is set with the result of aggregate(find(record),record) where * find() looks for the existing column as found by
Re: [Openstack] [Metering] schema and counter definitions
On Tue, May 1, 2012 at 10:38 AM, Nick Barcet nick.bar...@canonical.comwrote: On 05/01/2012 02:23 AM, Loic Dachary wrote: On 04/30/2012 11:39 PM, Doug Hellmann wrote: On Mon, Apr 30, 2012 at 3:43 PM, Loic Dachary l...@enovance.com mailto:l...@enovance.com wrote: On 04/30/2012 08:03 PM, Doug Hellmann wrote: On Mon, Apr 30, 2012 at 11:43 AM, Loic Dachary l...@enovance.com mailto:l...@enovance.com wrote: On 04/30/2012 03:49 PM, Doug Hellmann wrote: On Mon, Apr 30, 2012 at 6:46 AM, Loic Dachary l...@enovance.com mailto:l...@enovance.com wrote: On 04/30/2012 12:15 PM, Loic Dachary wrote: We could start a discussion from the content of the following sections: http://wiki.openstack.org/EfficientMetering#Counters I think the rationale of the counter aggregation needs to be explained. My understanding is that the metering system will be able to deliver the following information: 10 floating IPv4 addresses were allocated to the tenant during three months and were leased from provider NNN. From this, the billing system could add a line to the invoice : 10 IPv4, $N each = $10xN because it has been configured to invoice each IPv4 leased from provider NNN for $N. It is not the purpose of the metering system to display each IPv4 used, therefore it only exposes the aggregated information. The counters define how the information should be aggregated. If the idea was to expose each resource usage individually, defining counters would be meaningless as they would duplicate the activity log from each OpenStack component. What do you think ? At DreamHost we are going to want to show each individual resource (the IPv4 address, the instance, etc.) along with the charge information. Having the metering system aggregate that data will make it difficult/impossible to present the bill summary and detail views that we want. It would be much more useful for us if it tracked the usage details for each resource, and let us aggregate the data ourselves. If other vendors want to show the data differently, perhaps we should provide separate APIs for retrieving the detailed and aggregate data. Doug Hi, For the record, here is the unfinished conversation we had on IRC (04:29:06 PM) dhellmann: dachary, did you see my reply about counter definitions on the list today? (04:39:05 PM) dachary: It means some counters must not be aggregated. Only the amount associated with it is but there is one counter per IP. (04:55:01 PM) dachary: dhellmann: what about this :the id of the ressource controls the agregation of all counters : if it is missing, all resources of the same kind and their measures are aggregated. Otherwise only the measures are agreggated. http://wiki.openstack.org/EfficientMetering?action=diffrev2=40rev1=39 http://wiki.openstack.org/EfficientMetering?action=diffrev2=40rev1=39 (04:55:58 PM) dachary: it makes me a little unconfortable to define such an ad-hoc grouping (04:56:53 PM) dachary: i.e. you actuall control the aggregation by chosing which value to put in the id column (04:58:43 PM) dachary: s/actuall/actually/ (05:05:38 PM) ***dachary reading http://www.ogf.org/documents/GFD.98.pdf (05:05:54 PM) dachary: I feel like we're trying to resolve a non problem here (05:08:42 PM) dachary: values need to be aggregated. The raw input is a full description of the resource and a value ( gauge ). The question is how to control the aggregation in a reasonably flexible way. (05:11:34 PM) dachary: The definition of a counter could probably be described as : the id of a resource and code to fill each column associated with it. I tried to append the following, but the wiki kept failing. Propose that the counters are defined by a function instead of being fixed. That helps addressing the issue of aggregating the bandwidth associated to a given IP into a single counter. Alternate idea : * a counter is defined by * a name ( o1, n2, etc. ) that uniquely identifies the nature of the measure ( outbound internet transit, amount of RAM, etc. ) * the component in which it can be found ( nova, swift etc.) * and by columns, each one is set with
Re: [Openstack] Documentation: pdf link missing
No specific requirements. epub is even better. Tested the epub format and looks great. Excited to hear about the May event. Thanks! Paras. On Tue, May 1, 2012 at 10:32 AM, Anne Gentle a...@openstack.org wrote: We have a somewhat working epub output, but CHM is not on the list in the future. It's deprecated by Microsoft. Is there an offline, compressed HTML need that you have? Let me hear more about your need. Here's the info about epub: http://www.openstack.org/blog/2011/11/hacking-on-ebooks/ We'll be hacking on epub and mobi again at Rackspace in May - all are welcome to work on the Cloud docs plugin at https://github.com/rackspace/clouddocs-maven-plugin to improve the output. Thanks, Anne On Tue, May 1, 2012 at 10:25 AM, Paras pradhan pradhanpa...@gmail.com wrote: Great Thanks. BTW are there another formats available? Like chm. Paras. On Tue, May 1, 2012 at 10:08 AM, Anne Gentle a...@openstack.org wrote: Thanks Paras, this is a doc bug that keeps resurrecting itself. Opening https://bugs.launchpad.net/openstack-manuals/+bug/992652 Today I'm cutting an Essex release for the docs so I'll be sure to address this, thanks. Anne On Tue, May 1, 2012 at 9:51 AM, Paras pradhan pradhanpa...@gmail.com wrote: The pdf icon in this link is not working. http://docs.openstack.org/trunk/openstack-compute/admin/content/ Paras. ___ 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] [Metering] schema and counter definitions
Hi Loic, On Mon, 2012-04-30 at 12:15 +0200, Loic Dachary wrote: To prepare for the next meeting ( thursday 3rd, may 2012 http://wiki.openstack.org/Meetings/MeteringAgenda ) I cleaned up and reorganized the Metering blueprint so that it ( hopefully ) incorporates all the information temporarily stored in the etherpad ( http://etherpad.openstack.org/EfficientMetering revision 67 in case it is vandalized ). I'm a bit late to the discussion, but some brief comments after reading up on what you guys have done so far: - big +1 on separating billing from metering; there's no need to conflate the two problems and doing it this way will allow for a bunch of different ideas to be tried around billing - I'd prefer to avoid adding a new node agents, so +1 on building on the notifications system - I agree that we don't want to go too far with aggregation and lose useful data like which instances have been running as opposed to just how many instance minutes a given tenant has consumed Another aspect of aggregation to think about is aggregation over time - e.g. I might like to see my hourly network usage has varied over the last week, or how my daily usage has varied over the last month, but I probably don't care so much about my hourly usage on a specific day 3 months ago oVirt's equivalent of a metering service does this kind of aggregation as follows: http://www.ovirt.org/wiki/Ovirt_DWH * Sample data is collected at the end of every minute and is kept for up to 48 hours. * Hourly level is aggregated every hour for the hour before last and is kept for 2 months. * Daily level is aggregated every day for the day before last and is kept for 5 years. - Lastly, bikeshed mode - since we're calling this metering and not counting, how about just using the term meters rather than counters? Cheers, Mark. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Instance IP assignment problem
Hi Guys, Can anyone provide any insight to the following question: https://answers.launchpad.net/nova/+question/195439 Thanks, Salman___ 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] Glance Architecture
Hi Brian, Thanks for circulating this -- it looks more efficient for both data and metadata. A couple of quick queries... 1) Caching If your image is located in swift you can choose to go directly to swift to fetch the image. Will this image also now be automatically cached on the glance server, so next time around when you query the server you will be given a local filesystem location? 2) Access control If the user can go directly to Swift to access an image does that mean they can bypass Glance and directly delete that image? (Putting meta-data/data out of sync.) Thanks, -Stuart On Mon, 30 Apr 2012, Brian Waldon wrote: I've been thinking about how we can optimize the architecture of Glance while providing more flexibility to the consumer of the API. Some of the goals I have are: 1) Minimize request overhead - It feels wasteful to duplicate requests from the glance-api to the glance-registry. 2) Divide responsibilities clearly - The glance-api server is responsible for talking to keystone, the glance-registry, and several backend stores, while the glance-registry server only talks to the database. This feels like we're overloading glance-api with extra responsibilities. 3) Allow a user to stream image data directly from the backend - if a user is trusted (such as Nova), Glance shouldn't require streaming images through its servers. Here's how Glance is currently set up: A typical deployment is comprised of one to many glance-api servers and one to many glance-registry servers. The glance-api servers accept HTTP requests directly from the client, authenticate/authorize them, then speak to image storage backends and glance-registry servers. The glance-registry servers listen for HTTP requests from the glance-api servers (not end-users) and in turn make requests to a database. And this is my proposed architecture: One to many glance-api servers authenticate (via Keystone) end-user requests and talk directly to the database. These servers farm out image streaming to a glance-stream server. The responsibility of a glance-stream server is to stream image data from backends while masking credentials and providing caching. Alternatively, a user should be able to stream directly from a backend (depending on trust level) using a link obtained from a glance-api request and bypass the glance-stream server altogether. Please send any thoughts my way! Brian ___ 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
[Openstack] Simple voting features added to OpenStack MeetBot
Simple voting features have been added to OpenStack's MeetBot. Once a meeting is started a meeting chair can start a vote with the #startvote command. Command format is '#startvote $question $choices' eg '#startvote should we stop this meeting? yes, no'. Meeting participants vote using the #vote command eg '#vote yes'. To check intermediate voting results you can use the #showvote command which takes no arguments. When done voting a meeting chair ends voting with the #endvote command (this will add a VOTE item to the meeting minutes). Currently there isn't a way to restrict voters. You may vote multiple times, but only your last vote counts. If no vote choices are given the defaults are 'Yes' and 'No'. Have fun with it and hopefully it doesn't break :) Clark Boylan ___ 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] Instance IP assignment problem
Im not really sure but you are using range for your environment 10.0.3.x and 10.0.0.x for fixed. Can you attach a nova network conf? Regards El 01/05/2012 18:56, Salman Malik salma...@live.com escribió: Hi Guys, Can anyone provide any insight to the following question: https://answers.launchpad.net/nova/+question/195439 Thanks, Salman ___ 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] Agreeing a common set of Image Properties
On Sat, Apr 07, 2012 at 08:53:12PM -0400, Nathanael Burton wrote: Better yet why not add support in Glance for automatically determining those things (distro, versions, etc)[1]. That way you don't have to rely on people doing the right thing. [Sorry I'm a little late to the party] Just a note of caution around using virt-inspector: You shouldn't rely on its output in the case where (a) you're using it against an untrusted guest image, and (b) billing or some other money-related event relies on the output. The reason is that virt-inspector parses files from the guest. For example it'll read /etc/debian_version or the Windows registry to get its results. These files can be easily altered by a user to simulate another guest for the purposes of billing. Having said that, running it on trusted images is no problem. Also, it is safe to run virt-inspector on any image, in as much as it won't crash and Bad Things won't happen. It's written to be robust against untrusted data -- just don't depend on the output for billing purposes. BTW, since OpenStack is a python program, you may prefer to use the python Inspection API directly. See: http://libguestfs.org/guestfs-python.3.html#example_2__inspect_a_virtual_machine_disk_image http://libguestfs.org/guestfs.3.html#inspection Best of luck and do ask me if you have questions. Rich. -- Richard Jones Red Hat ___ 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] Simple voting features added to OpenStack MeetBot
Great work! -jay On 05/01/2012 12:59 PM, Clark Boylan wrote: Simple voting features have been added to OpenStack's MeetBot. Once a meeting is started a meeting chair can start a vote with the #startvote command. Command format is '#startvote $question $choices' eg '#startvote should we stop this meeting? yes, no'. Meeting participants vote using the #vote command eg '#vote yes'. To check intermediate voting results you can use the #showvote command which takes no arguments. When done voting a meeting chair ends voting with the #endvote command (this will add a VOTE item to the meeting minutes). Currently there isn't a way to restrict voters. You may vote multiple times, but only your last vote counts. If no vote choices are given the defaults are 'Yes' and 'No'. Have fun with it and hopefully it doesn't break :) Clark Boylan ___ 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] Instance IP assignment problem
Hi Jorge, Thanks for looking into the post. I have made changes to the nova.conf file so that I only use 10.0.0.x network (but the problem is still the same). For this configuration, I assume that it will give out IPs to instances starting from 10.0.0.11. And just to inform you, my eth1 is configured to be 10.0.0.10 (which is a VM itself, and eth1 is configured as a host-only network with no DHCP) and this interface is plugged in the integration bridge used by quantum plugins. Thanks, Salman PS: Error log of a launched instance is also attached. Date: Tue, 1 May 2012 19:03:49 +0200 Subject: Re: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: salma...@live.com CC: openstack@lists.launchpad.net Im not really sure but you are using range for your environment 10.0.3.x and 10.0.0.x for fixed. Can you attach a nova network conf? Regards El 01/05/2012 18:56, Salman Malik salma...@live.com escribió: Hi Guys, Can anyone provide any insight to the following question: https://answers.launchpad.net/nova/+question/195439 Thanks, Salman ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Error_log Description: Binary data nova.conf Description: Binary data ___ 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] OpenStack Client Followup
Matt Joyce (m...@nycresistor.com) wrote: 3. I think it would be good if the HIG recommended that, at least when subcommands are permitted, single arguments '--help' and 'help' always generate identical output: https://bugs.launchpad.net/keystone/+bug/936399 https://review.openstack.org/#/c/6460/ Same for Version ( --version ) Good point! I've added some draft text to the wiki page for that, partially pinched from: http://www.gnu.org/prep/standards/standards.html#Command_002dLine-Interfaces As you can see, the GNU standards go into great detail regarding --version; I don't know if we want to be as stringent, particularly regarding copyright / license notices, but there's some good food for thought there. 5. I think it would be good if the HIG specified what sort of help text should be included alongside error messages of (say) the you didn't give the right number of arguments variety, and whether the error message should appear before or after that help text. My vote is after, because it's far easier for the human eye to locate the end of a command's output than the beginning, especially if the beginning has scrolled off the top of the terminal. I wonder if this event tracking is relevant to metering. At the very least it could be relevant to an audit log / revision history. Curious if that's outside the scope of the CLI. For one, I believe it would be worthwhile to be able to integrate with the APIs to provide a recall of past events and results. Agreed - while server-side auditing is a more important component than client-side, having both sounds potentially useful to me too. And while it's outside the scope of a CLI HIG discussion, it's nevertheless relevant to any work on a unified CLI. ___ 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] [client] OpenStack Client Followup
Doug Hellmann (doug.hellm...@dreamhost.com) wrote: On Mon, Apr 30, 2012 at 12:13 PM, Adam Spiers aspi...@suse.com wrote: Dean Troyer (dtro...@gmail.com) wrote: One of the first things to do is to find out who is interested in contributing to this project.and hopefully coordinating some of the work with the other emerging project-specific clients. Send me an email and I'll build a list to get the discussion started. Count me in - by 'build a list' do you mean a new mailing list? I've read http://wiki.openstack.org/UnifiedCLI/HumanInterfaceGuidelines (which looks like a great start on the topic!) and made some minor tweaks. Should we discuss the FIXMEs you marked here or elsewhere? I wanted to make a few suggestions before I forget - can always continue discussion elsewhere if appropriate: 1. Regarding The subject names are always specified in command in their singular form. This is contrary to natural language use. - I didn't understand the second sentence here, but shouldn't the HIG should allow for scenarios where the verb can operate both on individual objects and on multiple objects in batch? I read that as meaning the command to list instances available to a tenant should be list server not the more natural list servers. Ah I see - makes sense now, thanks. Can you give an example of a command that would work on multiple objects in batch? Things like openstack set hosts --name-matches='foo*' --maintenance enable # use with caution! would require confirmation prompt openstack delete images --name-matches='bar*' ? Running a cliff-based app without any arguments enters interactive mode (as of 0.4) which gives the user a new prompt and lets them run multiple commands before exiting. This is intended to be used as an optimization for commands to cache authentication credentials and clients and avoid logging in for every sub-command. I love it :-) I guess it has readline support and could also offer completion too? Forgive the newbie question, but does cliff have significantly different goals or scope to cement? I attended the Quantum CLI rewrite session at the summit: http://folsomdesignsummit2012.sched.org/event/b20c2743ac6ab35d4f33b4fcd1da4fa7 and IIRC they were going to move to using cement. The notes from that session start on line 224 of: http://etherpad.openstack.org/quantum-folsom In particular note: Need to do some cleanup before the One CLI to Rule Them All project is going to be far enough long to be usable for Quantum commands. I wasn't sure how the work with cement would dovetail with this project though. Since we're using argparse for the subcommands, the default behavior if a command is run without arguments depends on the subcommand. If the subcommand has no required arguments, it will do whatever it is meant to do. If it does require arguments and sees none, argparse prints an error message about whatever is missing Agreed, except ... (and possibly suggests that the user use --help to get instructions). One of my pet peeves is commands which tell you that you screwed up but don't immediately offer help so you can take appropriate remedial action. In other words, bearing in mind Dean's section on User-Centered Design in the HIG, I'd prefer a command outputted usage text along with an error than one or two sentences forcing you to rerun the command with the --help option. ___ 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] Instance IP assignment problem
Hi, I have a similar problem when I create a network per project_id with Quantum. My VMs don't get IP and I can't understand why today. But when I create a private network for all projects, VMs get an IP and all is working well. Do you have the same problem ? Salman, I'm interesting about your nova.conf. I can see you are using Ryu ? Can you tell me more about your use case or architecture ? Thanks Le mardi 01 mai 2012 à 12:28 -0500, Salman Malik a écrit : Hi Jorge, Thanks for looking into the post. I have made changes to the nova.conf file so that I only use 10.0.0.x network (but the problem is still the same). For this configuration, I assume that it will give out IPs to instances starting from 10.0.0.11. And just to inform you, my eth1 is configured to be 10.0.0.10 (which is a VM itself, and eth1 is configured as a host-only network with no DHCP) and this interface is plugged in the integration bridge used by quantum plugins. Thanks, Salman PS: Error log of a launched instance is also attached. __ Date: Tue, 1 May 2012 19:03:49 +0200 Subject: Re: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: salma...@live.com CC: openstack@lists.launchpad.net Im not really sure but you are using range for your environment 10.0.3.x and 10.0.0.x for fixed. Can you attach a nova network conf? Regards El 01/05/2012 18:56, Salman Malik salma...@live.com escribió: Hi Guys, Can anyone provide any insight to the following question: https://answers.launchpad.net/nova/+question/195439 Thanks, Salman ___ 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] Instance IP assignment problem
Hi Emilien and Salman, Please, could you upload all the files, errors and conf in pastebin or something like that? I have troubles to open in phone :) Thank you El 01/05/2012 20:39, Emilien Macchi emilien.openst...@gmail.com escribió: ** Hi, I have a similar problem when I create a network per project_id with Quantum. My VMs don't get IP and I can't understand why today. But when I create a private network for all projects, VMs get an IP and all is working well. Do you have the same problem ? Salman, I'm interesting about your nova.conf. I can see you are using Ryu ? Can you tell me more about your use case or architecture ? Thanks Le mardi 01 mai 2012 à 12:28 -0500, Salman Malik a écrit : Hi Jorge, Thanks for looking into the post. I have made changes to the nova.conf file so that I only use 10.0.0.x network (but the problem is still the same). For this configuration, I assume that it will give out IPs to instances starting from 10.0.0.11. And just to inform you, my eth1 is configured to be 10.0.0.10 (which is a VM itself, and eth1 is configured as a host-only network with no DHCP) and this interface is plugged in the integration bridge used by quantum plugins. Thanks, Salman PS: Error log of a launched instance is also attached. -- Date: Tue, 1 May 2012 19:03:49 +0200 Subject: Re: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: salma...@live.com CC: openstack@lists.launchpad.net Im not really sure but you are using range for your environment 10.0.3.x and 10.0.0.x for fixed. Can you attach a nova network conf? Regards El 01/05/2012 18:56, Salman Malik salma...@live.com escribió: Hi Guys, Can anyone provide any insight to the following question: https://answers.launchpad.net/nova/+question/195439 Thanks, Salman ___ 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] OpenStack Client Followup
On Tue, May 1, 2012 at 12:54 PM, Adam Spiers aspi...@suse.com wrote: Agreed - while server-side auditing is a more important component than client-side, having both sounds potentially useful to me too. And while it's outside the scope of a CLI HIG discussion, it's nevertheless relevant to any work on a unified CLI. Sounds like a blueprint waiting to be written... ;) dt -- Dean Troyer dtro...@gmail.com ___ 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] [client] OpenStack Client Followup
Doug Hellmann (doug.hellm...@dreamhost.com) wrote: On Mon, Apr 30, 2012 at 2:56 PM, Dean Troyer dtro...@gmail.com wrote: On Mon, Apr 30, 2012 at 1:18 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Do we need to specify this beyond saying that all subcommands must use argparse for argument parsing (the new framework depends on it anyway, and then they are all consistent)? We should document that, I had just assumed it until now. Agreed. Sorry, that made me think of another newbie question - is the intention that all actions (including user- / site- / vendor-specific extensions) *must* be implemented in Python using the client API modules? Or will it also be able to support extensions simply by dropping arbitrary openstack-ACTION executables on $PATH? I like the way git lets you do the latter, e.g. I have a bunch of shell scripts named git-something in my own ~/bin which help me extend git and automate my git workflows, and they can still be invoked via `git something'. In case you're curious, here they are ... https://github.com/aspiers/git-config#readme ___ 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] Instance IP assignment problem
Hi Salman, I'm thinking about a networking issue. Where is your L3 gateway in this architecture ? Maybe do you need an ip helper tool to redirect DHCP broadcast ? What do you think about my problem (follow up to my last e-mail) ? Thanks Emilien Le mardi 01 mai 2012 à 14:00 -0500, Salman Malik a écrit : Hi, Here is the error log: http://pastebin.com/KrNZDrvD and nova.conf: http://pastebin.com/Fvd6dSZs Emilien, I am trying to get an understanding of how different Quantum plugins work with OpenStack. Ryu plugin is particularly interesting as it uses an OpenFlow controller to configure Vswitches. The problem I am faced with is (I think ) that I already have a private network and Quantum should assign IP addresses to instances using DHCP. But instances send out discover message on laucnh but never find a DHCP server (although there are 2 dnsmasqs running). Any ideas? Thanks, Salman __ Date: Tue, 1 May 2012 20:43:44 +0200 Subject: Re: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: emilien.openst...@gmail.com CC: openstack@lists.launchpad.net; salma...@live.com Hi Emilien and Salman, Please, could you upload all the files, errors and conf in pastebin or something like that? I have troubles to open in phone :) Thank you El 01/05/2012 20:39, Emilien Macchi emilien.openst...@gmail.com escribió: Hi, I have a similar problem when I create a network per project_id with Quantum. My VMs don't get IP and I can't understand why today. But when I create a private network for all projects, VMs get an IP and all is working well. Do you have the same problem ? Salman, I'm interesting about your nova.conf. I can see you are using Ryu ? Can you tell me more about your use case or architecture ? Thanks Le mardi 01 mai 2012 à 12:28 -0500, Salman Malik a écrit : Hi Jorge, Thanks for looking into the post. I have made changes to the nova.conf file so that I only use 10.0.0.x network (but the problem is still the same). For this configuration, I assume that it will give out IPs to instances starting from 10.0.0.11. And just to inform you, my eth1 is configured to be 10.0.0.10 (which is a VM itself, and eth1 is configured as a host-only network with no DHCP) and this interface is plugged in the integration bridge used by quantum plugins. Thanks, Salman PS: Error log of a launched instance is also attached. __ Date: Tue, 1 May 2012 19:03:49 +0200 Subject: Re: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: salma...@live.com CC: openstack@lists.launchpad.net Im not really sure but you are using range for your environment 10.0.3.x and 10.0.0.x for fixed. Can you attach a nova network conf? Regards El 01/05/2012 18:56, Salman Malik salma...@live.com escribió: Hi Guys, Can anyone provide any insight to the following question: https://answers.launchpad.net/nova/+question/195439 Thanks, Salman ___ 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] [client] OpenStack Client Followup
On Tue, May 1, 2012 at 1:49 PM, Adam Spiers aspi...@suse.com wrote: Sorry, that made me think of another newbie question - is the intention that all actions (including user- / site- / vendor-specific extensions) *must* be implemented in Python using the client API modules? Or will it also be able to support extensions simply by dropping arbitrary openstack-ACTION executables on $PATH? I like the way git lets you do the latter, e.g. I have a bunch of shell scripts At this point we have only talked about extending the client via cliff-derived plugins. I'm trying to decide what the value add of arbitrary binaries being called is; the way I imagine it the binary would have to duplicate the token flow auth at a minimum, why not just call it directly? git has the advantage here of keeping its state in the filesystem. What little state we have is in memory. dt -- Dean Troyer dtro...@gmail.com ___ 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] OpenStack Client Followup
Dean Troyer (dtro...@gmail.com) wrote: On Mon, Apr 30, 2012 at 2:19 PM, Dolph Mathews dolph.math...@gmail.com wrote: I find this behavior really annoying... --help should be contextual (depending on whether a subcommand is present, and what it is). I hope not... +1 for argparse. Actually, argparse is one reason for this behaviour. It doesn't like duplicated options in subparsers, nor subsets of names like we found in keystone with --tenant and --tenant_id, etc. IIRC none of the existing clients do that, they all rely on 'help command' to get command-specific help. As of my recent patch, --help is contextual in nova: https://review.openstack.org/6460 and I have started work on some of the other commands too, so it would be helpful if we could reach a consensus on this soon ... although please let me know if I am wasting my time working on other commands due to any imminent rewrites using python-openstack! I agree with Dolph - there is a precedent from other well-known programs (git, hg, svn are the first ones I can think of) for --help to behave differently depending on whether or not it was preceded by a subcommand. So my vote is that we should definitely aim to adhere to this pattern. ___ 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] Instance IP assignment problem
Regarding L3 gateway, I believe its not necessary to have one (as the VM hasn't obtained an IP right now, so it can't talk to anything outside its net), but I am not sure. Regarding your problem, do you see any DHCP responses from the DHCP server ? I am asking this because I was having a similar problem earlier where I was getting assigned an IP address no in my desired fixed_network and I believe that was cause by another interfering DHCP server that was replying to discover messages before the nova-network could. Salman Subject: RE: [Openstack] Instance IP assignment problem From: emilien.openst...@gmail.com To: salma...@live.com CC: jorge.delac...@stackops.com; openstack@lists.launchpad.net Date: Tue, 1 May 2012 21:06:01 +0200 Hi Salman, I'm thinking about a networking issue. Where is your L3 gateway in this architecture ? Maybe do you need an ip helper tool to redirect DHCP broadcast ? What do you think about my problem (follow up to my last e-mail) ? Thanks Emilien Le mardi 01 mai 2012 à 14:00 -0500, Salman Malik a écrit : Hi, Here is the error log: http://pastebin.com/KrNZDrvD and nova.conf: http://pastebin.com/Fvd6dSZs Emilien, I am trying to get an understanding of how different Quantum plugins work with OpenStack. Ryu plugin is particularly interesting as it uses an OpenFlow controller to configure Vswitches. The problem I am faced with is (I think ) that I already have a private network and Quantum should assign IP addresses to instances using DHCP. But instances send out discover message on laucnh but never find a DHCP server (although there are 2 dnsmasqs running). Any ideas? Thanks, Salman Date: Tue, 1 May 2012 20:43:44 +0200 Subject: Re: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: emilien.openst...@gmail.com CC: openstack@lists.launchpad.net; salma...@live.com Hi Emilien and Salman, Please, could you upload all the files, errors and conf in pastebin or something like that? I have troubles to open in phone :) Thank you El 01/05/2012 20:39, Emilien Macchi emilien.openst...@gmail.com escribió: Hi, I have a similar problem when I create a network per project_id with Quantum. My VMs don't get IP and I can't understand why today. But when I create a private network for all projects, VMs get an IP and all is working well. Do you have the same problem ? Salman, I'm interesting about your nova.conf. I can see you are using Ryu ? Can you tell me more about your use case or architecture ? Thanks Le mardi 01 mai 2012 à 12:28 -0500, Salman Malik a écrit : Hi Jorge, Thanks for looking into the post. I have made changes to the nova.conf file so that I only use 10.0.0.x network (but the problem is still the same). For this configuration, I assume that it will give out IPs to instances starting from 10.0.0.11. And just to inform you, my eth1 is configured to be 10.0.0.10 (which is a VM itself, and eth1 is configured as a host-only network with no DHCP) and this interface is plugged in the integration bridge used by quantum plugins. Thanks, Salman PS: Error log of a launched instance is also attached. Date: Tue, 1 May 2012 19:03:49 +0200 Subject: Re: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: salma...@live.com CC: openstack@lists.launchpad.net Im not really sure but you are using range for your environment 10.0.3.x and 10.0.0.x for fixed. Can you attach a nova network conf? Regards El 01/05/2012 18:56, Salman Malik salma...@live.com escribió: Hi Guys, Can anyone provide any insight to the following question: https://answers.launchpad.net/nova/+question/195439 Thanks, Salman ___ 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 :
Re: [Openstack] OpenStack Client Followup
On Tue, May 1, 2012 at 1:54 PM, Adam Spiers aspi...@suse.com wrote: Matt Joyce (m...@nycresistor.com) wrote: 3. I think it would be good if the HIG recommended that, at least when subcommands are permitted, single arguments '--help' and 'help' always generate identical output: https://bugs.launchpad.net/keystone/+bug/936399 https://review.openstack.org/#/c/6460/ Same for Version ( --version ) Good point! I've added some draft text to the wiki page for that, partially pinched from: http://www.gnu.org/prep/standards/standards.html#Command_002dLine-Interfaces As you can see, the GNU standards go into great detail regarding --version; I don't know if we want to be as stringent, particularly regarding copyright / license notices, but there's some good food for thought there. The version flag is also handled by argparse automatically. We can set the version string to whatever we want, of course. 5. I think it would be good if the HIG specified what sort of help text should be included alongside error messages of (say) the you didn't give the right number of arguments variety, and whether the error message should appear before or after that help text. My vote is after, because it's far easier for the human eye to locate the end of a command's output than the beginning, especially if the beginning has scrolled off the top of the terminal. I wonder if this event tracking is relevant to metering. At the very least it could be relevant to an audit log / revision history. Curious if that's outside the scope of the CLI. For one, I believe it would be worthwhile to be able to integrate with the APIs to provide a recall of past events and results. Agreed - while server-side auditing is a more important component than client-side, having both sounds potentially useful to me too. And while it's outside the scope of a CLI HIG discussion, it's nevertheless relevant to any work on a unified CLI. ___ 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] Instance IP assignment problem
Le mardi 01 mai 2012 à 14:22 -0500, Salman Malik a écrit : Regarding L3 gateway, I believe its not necessary to have one (as the VM hasn't obtained an IP right now, so it can't talk to anything outside its net), but I am not sure. Regarding your problem, do you see any DHCP responses from the DHCP server ? I am asking this because I was having a similar problem earlier where I was getting assigned an IP address no in my desired fixed_network and I believe that was cause by another interfering DHCP server that was replying to discover messages before the nova-network could. Here my nova.conf and I don't have any interfering DHCP server : https://github.com/EmilienM/doc-openstack/blob/master/Configuration% 20Files/Essex-1/nova.conf Thanks Salman __ Subject: RE: [Openstack] Instance IP assignment problem From: emilien.openst...@gmail.com To: salma...@live.com CC: jorge.delac...@stackops.com; openstack@lists.launchpad.net Date: Tue, 1 May 2012 21:06:01 +0200 Hi Salman, I'm thinking about a networking issue. Where is your L3 gateway in this architecture ? Maybe do you need an ip helper tool to redirect DHCP broadcast ? What do you think about my problem (follow up to my last e-mail) ? Thanks Emilien Le mardi 01 mai 2012 à 14:00 -0500, Salman Malik a écrit : Hi, Here is the error log: http://pastebin.com/KrNZDrvD and nova.conf: http://pastebin.com/Fvd6dSZs Emilien, I am trying to get an understanding of how different Quantum plugins work with OpenStack. Ryu plugin is particularly interesting as it uses an OpenFlow controller to configure Vswitches. The problem I am faced with is (I think ) that I already have a private network and Quantum should assign IP addresses to instances using DHCP. But instances send out discover message on laucnh but never find a DHCP server (although there are 2 dnsmasqs running). Any ideas? Thanks, Salman __ Date: Tue, 1 May 2012 20:43:44 +0200 Subject: Re: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: emilien.openst...@gmail.com CC: openstack@lists.launchpad.net; salma...@live.com Hi Emilien and Salman, Please, could you upload all the files, errors and conf in pastebin or something like that? I have troubles to open in phone :) Thank you El 01/05/2012 20:39, Emilien Macchi emilien.openst...@gmail.com escribió: Hi, I have a similar problem when I create a network per project_id with Quantum. My VMs don't get IP and I can't understand why today. But when I create a private network for all projects, VMs get an IP and all is working well. Do you have the same problem ? Salman, I'm interesting about your nova.conf. I can see you are using Ryu ? Can you tell me more about your use case or architecture ? Thanks Le mardi 01 mai 2012 à 12:28 -0500, Salman Malik a écrit : Hi Jorge, Thanks for looking into the post. I have made changes to the nova.conf file so that I only use 10.0.0.x network (but the problem is still the same). For this configuration, I assume that it will give out IPs to instances starting from 10.0.0.11. And just to inform you, my eth1 is configured to be 10.0.0.10 (which is a VM itself, and eth1 is configured as a host-only network with no DHCP) and this interface is plugged in the integration bridge used by quantum plugins. Thanks, Salman PS: Error log of a launched instance is also attached.
Re: [Openstack] OpenStack Client Followup
On Tue, May 1, 2012 at 2:11 PM, Adam Spiers aspi...@suse.com wrote: As of my recent patch, --help is contextual in nova: I hadn't seen that yet... and I have started work on some of the other commands too, so it would be helpful if we could reach a consensus on this soon ... although please let me know if I am wasting my time working on other commands due to any imminent rewrites using python-openstack! The continued existence of the project-specific commands is really up to the projects themselves. I think it would be great to converge them on things like this, but trying to get them all to work the same is what led us to openstackclient due to backward compatibility and all. My guess would be that the existing client binaries would live through the 'G' release even if we decided to deprecate them now. I agree with Dolph - there is a precedent from other well-known programs (git, hg, svn are the first ones I can think of) for --help to behave differently depending on whether or not it was preceded by a subcommand. So my vote is that we should definitely aim to adhere to this pattern. How about detailing it in the HIG and once we get a command or two implemented with argument parsing we give it a shot? dt -- Dean Troyer dtro...@gmail.com ___ 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] Instance IP assignment problem
Hi, In your conf Dalman I dont see a routing_sourceip and in Emilien's cong yes. Try with this parameter. El 01/05/2012 21:00, Salman Malik salma...@live.com escribió: Hi, Here is the error log: http://pastebin.com/KrNZDrvD and nova.conf: http://pastebin.com/Fvd6dSZs Emilien, I am trying to get an understanding of how different Quantum plugins work with OpenStack. Ryu plugin is particularly interesting as it uses an OpenFlow controller to configure Vswitches. The problem I am faced with is (I think ) that I already have a private network and Quantum should assign IP addresses to instances using DHCP. But instances send out discover message on laucnh but never find a DHCP server (although there are 2 dnsmasqs running). Any ideas? Thanks, Salman -- Date: Tue, 1 May 2012 20:43:44 +0200 Subject: Re: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: emilien.openst...@gmail.com CC: openstack@lists.launchpad.net; salma...@live.com Hi Emilien and Salman, Please, could you upload all the files, errors and conf in pastebin or something like that? I have troubles to open in phone :) Thank you El 01/05/2012 20:39, Emilien Macchi emilien.openst...@gmail.com escribió: ** Hi, I have a similar problem when I create a network per project_id with Quantum. My VMs don't get IP and I can't understand why today. But when I create a private network for all projects, VMs get an IP and all is working well. Do you have the same problem ? Salman, I'm interesting about your nova.conf. I can see you are using Ryu ? Can you tell me more about your use case or architecture ? Thanks Le mardi 01 mai 2012 à 12:28 -0500, Salman Malik a écrit : Hi Jorge, Thanks for looking into the post. I have made changes to the nova.conf file so that I only use 10.0.0.x network (but the problem is still the same). For this configuration, I assume that it will give out IPs to instances starting from 10.0.0.11. And just to inform you, my eth1 is configured to be 10.0.0.10 (which is a VM itself, and eth1 is configured as a host-only network with no DHCP) and this interface is plugged in the integration bridge used by quantum plugins. Thanks, Salman PS: Error log of a launched instance is also attached. -- Date: Tue, 1 May 2012 19:03:49 +0200 Subject: Re: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: salma...@live.com CC: openstack@lists.launchpad.net Im not really sure but you are using range for your environment 10.0.3.x and 10.0.0.x for fixed. Can you attach a nova network conf? Regards El 01/05/2012 18:56, Salman Malik salma...@live.com escribió: Hi Guys, Can anyone provide any insight to the following question: https://answers.launchpad.net/nova/+question/195439 Thanks, Salman ___ 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] Instance IP assignment problem
It may help if you can share the log of your launched instance as well. There is a possibility that we both are having the same issue. Netstack developers can give a definitive answer to this, but it would be interesting to learn what goes wrong with a launched instance. Salman Subject: RE: [Openstack] Instance IP assignment problem From: emilien.openst...@gmail.com To: salma...@live.com CC: jorge.delac...@stackops.com; openstack@lists.launchpad.net Date: Tue, 1 May 2012 21:26:26 +0200 Le mardi 01 mai 2012 à 14:22 -0500, Salman Malik a écrit : Regarding L3 gateway, I believe its not necessary to have one (as the VM hasn't obtained an IP right now, so it can't talk to anything outside its net), but I am not sure. Regarding your problem, do you see any DHCP responses from the DHCP server ? I am asking this because I was having a similar problem earlier where I was getting assigned an IP address no in my desired fixed_network and I believe that was cause by another interfering DHCP server that was replying to discover messages before the nova-network could. Here my nova.conf and I don't have any interfering DHCP server : https://github.com/EmilienM/doc-openstack/blob/master/Configuration%20Files/Essex-1/nova.conf Thanks Salman Subject: RE: [Openstack] Instance IP assignment problem From: emilien.openst...@gmail.com To: salma...@live.com CC: jorge.delac...@stackops.com; openstack@lists.launchpad.net Date: Tue, 1 May 2012 21:06:01 +0200 Hi Salman, I'm thinking about a networking issue. Where is your L3 gateway in this architecture ? Maybe do you need an ip helper tool to redirect DHCP broadcast ? What do you think about my problem (follow up to my last e-mail) ? Thanks Emilien Le mardi 01 mai 2012 à 14:00 -0500, Salman Malik a écrit : Hi, Here is the error log: http://pastebin.com/KrNZDrvD and nova.conf: http://pastebin.com/Fvd6dSZs Emilien, I am trying to get an understanding of how different Quantum plugins work with OpenStack. Ryu plugin is particularly interesting as it uses an OpenFlow controller to configure Vswitches. The problem I am faced with is (I think ) that I already have a private network and Quantum should assign IP addresses to instances using DHCP. But instances send out discover message on laucnh but never find a DHCP server (although there are 2 dnsmasqs running). Any ideas? Thanks, Salman Date: Tue, 1 May 2012 20:43:44 +0200 Subject: Re: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: emilien.openst...@gmail.com CC: openstack@lists.launchpad.net; salma...@live.com Hi Emilien and Salman, Please, could you upload all the files, errors and conf in pastebin or something like that? I have troubles to open in phone :) Thank you El 01/05/2012 20:39, Emilien Macchi emilien.openst...@gmail.com escribió: Hi, I have a similar problem when I create a network per project_id with Quantum. My VMs don't get IP and I can't understand why today. But when I create a private network for all projects, VMs get an IP and all is working well. Do you have the same problem ? Salman, I'm interesting about your nova.conf. I can see you are using Ryu ? Can you tell me more about your use case or architecture ? Thanks Le mardi 01 mai 2012 à 12:28 -0500, Salman Malik a écrit : Hi Jorge, Thanks for looking into the post. I have made changes to the nova.conf file so that I only use 10.0.0.x network (but the problem is still the same). For this configuration, I assume that it will give out IPs to instances starting from 10.0.0.11. And just to inform you, my eth1 is configured to be 10.0.0.10 (which is a VM itself, and eth1 is configured as a host-only network with no DHCP) and this interface is plugged in the integration bridge used by quantum plugins. Thanks, Salman PS: Error log of a launched instance is also attached. Date: Tue, 1 May 2012 19:03:49 +0200 Subject: Re: [Openstack] Instance IP assignment problem
Re: [Openstack] [client] OpenStack Client Followup
On Tue, May 1, 2012 at 11:49 AM, Adam Spiers aspi...@suse.com wrote: Doug Hellmann (doug.hellm...@dreamhost.com) wrote: On Mon, Apr 30, 2012 at 2:56 PM, Dean Troyer dtro...@gmail.com wrote: On Mon, Apr 30, 2012 at 1:18 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Do we need to specify this beyond saying that all subcommands must use argparse for argument parsing (the new framework depends on it anyway, and then they are all consistent)? We should document that, I had just assumed it until now. Agreed. Sorry, that made me think of another newbie question - is the intention that all actions (including user- / site- / vendor-specific extensions) *must* be implemented in Python using the client API modules? Or will it also be able to support extensions simply by dropping arbitrary openstack-ACTION executables on $PATH? I like the way git lets you do the latter, e.g. I have a bunch of shell scripts named git-something in my own ~/bin which help me extend git and automate my git workflows, and they can still be invoked via `git something'. In case you're curious, here they are ... That made me think of something. Is the intention for the client to be portable? Defining portable as : Easily deployed to a host Minimal dependency set Cross operating system portability ( pipe dream but python is solid at it ) Strikes me that having the package end up being portable would be a huge boon to openstack. -Matt ___ 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] Instance IP assignment problem
Hi Jorge, I tried the parameter but to no avail. Also this post (https://answers.launchpad.net/nova/+question/148445) says that it defaults to my_ip if not specified. Any other thoughts are much appreciated. Thanks, Salman Date: Tue, 1 May 2012 21:34:48 +0200 Subject: RE: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: salma...@live.com CC: openstack@lists.launchpad.net; emilien.openst...@gmail.com Hi, In your conf Dalman I dont see a routing_sourceip and in Emilien's cong yes. Try with this parameter. El 01/05/2012 21:00, Salman Malik salma...@live.com escribió: Hi, Here is the error log: http://pastebin.com/KrNZDrvD and nova.conf: http://pastebin.com/Fvd6dSZs Emilien, I am trying to get an understanding of how different Quantum plugins work with OpenStack. Ryu plugin is particularly interesting as it uses an OpenFlow controller to configure Vswitches. The problem I am faced with is (I think ) that I already have a private network and Quantum should assign IP addresses to instances using DHCP. But instances send out discover message on laucnh but never find a DHCP server (although there are 2 dnsmasqs running). Any ideas? Thanks, Salman Date: Tue, 1 May 2012 20:43:44 +0200 Subject: Re: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: emilien.openst...@gmail.com CC: openstack@lists.launchpad.net; salma...@live.com Hi Emilien and Salman, Please, could you upload all the files, errors and conf in pastebin or something like that? I have troubles to open in phone :) Thank you El 01/05/2012 20:39, Emilien Macchi emilien.openst...@gmail.com escribió: Hi, I have a similar problem when I create a network per project_id with Quantum. My VMs don't get IP and I can't understand why today. But when I create a private network for all projects, VMs get an IP and all is working well. Do you have the same problem ? Salman, I'm interesting about your nova.conf. I can see you are using Ryu ? Can you tell me more about your use case or architecture ? Thanks Le mardi 01 mai 2012 à 12:28 -0500, Salman Malik a écrit : Hi Jorge, Thanks for looking into the post. I have made changes to the nova.conf file so that I only use 10.0.0.x network (but the problem is still the same). For this configuration, I assume that it will give out IPs to instances starting from 10.0.0.11. And just to inform you, my eth1 is configured to be 10.0.0.10 (which is a VM itself, and eth1 is configured as a host-only network with no DHCP) and this interface is plugged in the integration bridge used by quantum plugins. Thanks, Salman PS: Error log of a launched instance is also attached. Date: Tue, 1 May 2012 19:03:49 +0200 Subject: Re: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: salma...@live.com CC: openstack@lists.launchpad.net Im not really sure but you are using range for your environment 10.0.3.x and 10.0.0.x for fixed. Can you attach a nova network conf? Regards El 01/05/2012 18:56, Salman Malik salma...@live.com escribió: Hi Guys, Can anyone provide any insight to the following question: https://answers.launchpad.net/nova/+question/195439 Thanks, Salman ___ 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] [Metering] schema and counter definitions
I'm glad to see people championing the effort to implement metering. Is there someway to refocus the enthusiasm for solving the metering problem into engineering a general solution in OpenStack? I'm just going to apologize in advance, but I don't think this project is headed in the right direction. I believe metering should be a first class concern of OpenStack and the way this project is starting is almost exactly backwards from what I think a solution to metering should look like. The last thing I want to see right now is a blessed OpenStack metering project adding more agents, coupled to a particular db and making policy decisions about what is quantifiable. I think there are really three problems that need to be solved to do metering, what data to get, getting the data and doing things with the data. From my perspective, a lot if not all of the data events should be coming out of the services themselves. There is already a service that should know when an instance gets started by what tenant. A cross cutting system for publishing those events and a service definition for collecting them seems like a reasonable place to start. To me that should look awful lot like a message queue or centralized logging. Once the first two problems are solved well, if you are so inclined to collect the data into a relational model, the schema will be obvious. If the first two problems are solved well, then I could be persuaded that a service that provides some of the aggregation functionality is a great idea and a reference implementation on a relational database isn't the worst thing in the world. Without a general solution for the first two problems, I believe the primary focus on a schema and db is premature and sub-optimal. I also believe the current approach likely results in a project that is generally unusable. Does anyone else share my perspective? Maybe I'm the crazy one... Andrew ___ 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] [client] OpenStack Client Followup
On Tue, May 1, 2012 at 2:35 PM, Adam Spiers aspi...@suse.com wrote: Doug Hellmann (doug.hellm...@dreamhost.com) wrote: On Mon, Apr 30, 2012 at 12:13 PM, Adam Spiers aspi...@suse.com wrote: Dean Troyer (dtro...@gmail.com) wrote: One of the first things to do is to find out who is interested in contributing to this project.and hopefully coordinating some of the work with the other emerging project-specific clients. Send me an email and I'll build a list to get the discussion started. Count me in - by 'build a list' do you mean a new mailing list? I've read http://wiki.openstack.org/UnifiedCLI/HumanInterfaceGuidelines (which looks like a great start on the topic!) and made some minor tweaks. Should we discuss the FIXMEs you marked here or elsewhere? I wanted to make a few suggestions before I forget - can always continue discussion elsewhere if appropriate: 1. Regarding The subject names are always specified in command in their singular form. This is contrary to natural language use. - I didn't understand the second sentence here, but shouldn't the HIG should allow for scenarios where the verb can operate both on individual objects and on multiple objects in batch? I read that as meaning the command to list instances available to a tenant should be list server not the more natural list servers. Ah I see - makes sense now, thanks. Can you give an example of a command that would work on multiple objects in batch? Things like openstack set hosts --name-matches='foo*' --maintenance enable # use with caution! would require confirmation prompt openstack delete images --name-matches='bar*' ? Running a cliff-based app without any arguments enters interactive mode (as of 0.4) which gives the user a new prompt and lets them run multiple commands before exiting. This is intended to be used as an optimization for commands to cache authentication credentials and clients and avoid logging in for every sub-command. I love it :-) I guess it has readline support and could also offer completion too? Yes, it uses cmd2 for the interaction, so readline is supported, where available. Forgive the newbie question, but does cliff have significantly different goals or scope to cement? I attended the Quantum CLI rewrite session at the summit: http://folsomdesignsummit2012.sched.org/event/b20c2743ac6ab35d4f33b4fcd1da4fa7 and IIRC they were going to move to using cement. The notes from that session start on line 224 of: http://etherpad.openstack.org/quantum-folsom In particular note: Need to do some cleanup before the One CLI to Rule Them All project is going to be far enough long to be usable for Quantum commands. I wasn't sure how the work with cement would dovetail with this project though. Dean and I looked at cement and didn't feel it was a good fit (also, it looked like it would be cumbersome to use). cliff is a new framework that more directly meets the requirements we have, especially giving extensions the ability to load new commands dynamically. Since we're using argparse for the subcommands, the default behavior if a command is run without arguments depends on the subcommand. If the subcommand has no required arguments, it will do whatever it is meant to do. If it does require arguments and sees none, argparse prints an error message about whatever is missing Agreed, except ... (and possibly suggests that the user use --help to get instructions). One of my pet peeves is commands which tell you that you screwed up but don't immediately offer help so you can take appropriate remedial action. In other words, bearing in mind Dean's section on User-Centered Design in the HIG, I'd prefer a command outputted usage text along with an error than one or two sentences forcing you to rerun the command with the --help option. We can probably make them print help by default. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Swift][Keystone] Swift Quotas
Hi All, I led the session [1] on Swift Quotas at the Summit and I'd appreciate some feedback on the updated spec [2] and blueprint [3]. I also have a couple of design level questions. 1. Should we store the Swift quota data in Keystone? One of the ideas that came out of the session was that we could store the Swift quota data in Keystone. I took a look at Keystone and it appears the best place for this would be in the metada table but it appears to me that it's only accessible via the User Metadata Extension API in Keystone. Is it feasible to store the Swift quota data in Keystone this way? Should we? On a related note, during the Pluggable Tenant Data session [4] led by Phil Day something similar was being discussed for moving Nova quotas to Keystone. 2. Where should the code for Swift quotas live? It was suggested during the session that this code could live in a middleware for Swift. Seems like a reasonable approach to me. I've taken a look at some of the code in /swift/common/middleware and it looks relatively straight-forward. Any thoughts or suggestions on implementing this as middleware? Regards, Everett [1] http://etherpad.openstack.org/SwiftQuotas [2] http://wiki.openstack.org/SwiftQuotas [3] https://blueprints.launchpad.net/swift/+spec/storage-quotas [4] http://etherpad.openstack.org/FolsomPluggableTenantData ___ 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] [client] OpenStack Client Followup
On Tue, May 1, 2012 at 3:36 PM, Matt Joyce m...@nycresistor.com wrote: On Tue, May 1, 2012 at 11:49 AM, Adam Spiers aspi...@suse.com wrote: Doug Hellmann (doug.hellm...@dreamhost.com) wrote: On Mon, Apr 30, 2012 at 2:56 PM, Dean Troyer dtro...@gmail.com wrote: On Mon, Apr 30, 2012 at 1:18 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Do we need to specify this beyond saying that all subcommands must use argparse for argument parsing (the new framework depends on it anyway, and then they are all consistent)? We should document that, I had just assumed it until now. Agreed. Sorry, that made me think of another newbie question - is the intention that all actions (including user- / site- / vendor-specific extensions) *must* be implemented in Python using the client API modules? Or will it also be able to support extensions simply by dropping arbitrary openstack-ACTION executables on $PATH? I like the way git lets you do the latter, e.g. I have a bunch of shell scripts named git-something in my own ~/bin which help me extend git and automate my git workflows, and they can still be invoked via `git something'. In case you're curious, here they are ... That made me think of something. Is the intention for the client to be portable? Defining portable as : Easily deployed to a host Minimal dependency set We're going to have dependencies, in order to achieve our desired feature set. For one thing, you'll need client packages for all of the various services. cliff also includes a few dependencies itself for formatting output, handling interaction, etc. Cross operating system portability ( pipe dream but python is solid at it ) I don't think we're using any OS-specific tools at this point. I don't see any reason to believe that will change. We (I?) also have as a goal to make the tool work with Python 3 as well as Python 2. Strikes me that having the package end up being portable would be a huge boon to openstack. -Matt ___ 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] Mailing-list split
On 04/27/2012 11:33 PM, Matt Joyce wrote: Makes sense to me. To me as well. cheers, Jan ___ 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] [client] OpenStack Client Followup
On Tue, May 1, 2012 at 2:36 PM, Matt Joyce m...@nycresistor.com wrote: That made me think of something. Is the intention for the client to be portable? Due to the dependencies it'll be about as portable than the existing OpenStack clients. Regarding installation, pip is^H^Hwill be your friend. I'd expect the distros to pick it up at some point, too. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Nova volume service and the nova client command
I've configured the nova_volume service using the the Ubuntu 12.04LTS packages,
and am able to create/delete volumes using the euca2ools package. However,
dashboard is not able to retrieve volume info or perform volume operations with
the nova client. If I issue the 'nova volume-list' command, I receive a 400
error response. For example
root@essex1:/etc/nova# nova --debug volume-list
connect: (essex1, 5000)
send: 'POST /v2.0/tokens HTTP/1.1\r\nHost: essex1:5000\r\nContent-Length:
100\r\ncontent-type: application/json\r\naccept-encoding: gzip,
deflate\r\naccept: application/json\r\nuser-agent:
python-novaclient\r\n\r\n{auth: {tenantName: admin,
passwordCredentials: {username: admin, password: admin}}}'
reply: 'HTTP/1.1 200 OK\r\n'
header: Content-Type: application/json
header: Vary: X-Auth-Token
header: Date: Tue, 01 May 2012 20:06:39 GMT
header: Transfer-Encoding: chunked
connect: (essex4, 8776)
connect fail: (u'essex4', 8776)
DEBUG (shell:416) n/a (HTTP 400)
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 413, in main
OpenStackComputeShell().main(sys.argv[1:])
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 364, in main
args.func(self.cs, args)
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/shell.py, line 858,
in do_volume_list
volumes = cs.volumes.list()
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/volumes.py, line 79,
in list
return self._list(/volumes/detail, volumes)
File /usr/lib/python2.7/dist-packages/novaclient/base.py, line 71, in _list
resp, body = self.api.client.get(url)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 136, in get
return self._cs_request(url, 'GET', **kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 124, in
_cs_request
**kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 107, in
request
raise exceptions.from_response(resp, body)
BadRequest: n/a (HTTP 400)
ERROR: n/a (HTTP 400)
root@essex1:/etc/nova#
Node essex1 is the cloud controller. essex4 is the volume controller. To
verify the connection failure, if I try to telnet to port 8776 I also get a
connect refused. My nova-volume endpoint is specified in keystone as
'http://essex4:8776/v1/$(tenant_id)s'. With the above connection failure,
nothing is written to the nova-volume.log (which makes sense if the server
isn't listening to port 8776). Obviously, none of the other nova volume
commands work.
Anything obvious that I'm missing? Thanks in advance
Regards,
Ross
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
[Openstack] python-quantum client essex branch
Hello Folks, I was trying to get the essex branch for the Quantum Client but it seems that is not in github. Does anyone could indicate how to get it? I am trying to get all services based on essex release and not the current trunk. Thanks, Edgar ___ 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] [Metering] schema and counter definitions
On 05/01/2012 05:49 PM, Doug Hellmann wrote: On Tue, May 1, 2012 at 10:38 AM, Nick Barcet nick.bar...@canonical.com mailto:nick.bar...@canonical.com wrote: On 05/01/2012 02:23 AM, Loic Dachary wrote: On 04/30/2012 11:39 PM, Doug Hellmann wrote: On Mon, Apr 30, 2012 at 3:43 PM, Loic Dachary l...@enovance.com mailto:l...@enovance.com mailto:l...@enovance.com mailto:l...@enovance.com wrote: On 04/30/2012 08:03 PM, Doug Hellmann wrote: On Mon, Apr 30, 2012 at 11:43 AM, Loic Dachary l...@enovance.com mailto:l...@enovance.com mailto:l...@enovance.com mailto:l...@enovance.com wrote: On 04/30/2012 03:49 PM, Doug Hellmann wrote: On Mon, Apr 30, 2012 at 6:46 AM, Loic Dachary l...@enovance.com mailto:l...@enovance.com mailto:l...@enovance.com mailto:l...@enovance.com wrote: On 04/30/2012 12:15 PM, Loic Dachary wrote: We could start a discussion from the content of the following sections: http://wiki.openstack.org/EfficientMetering#Counters I think the rationale of the counter aggregation needs to be explained. My understanding is that the metering system will be able to deliver the following information: 10 floating IPv4 addresses were allocated to the tenant during three months and were leased from provider NNN. From this, the billing system could add a line to the invoice : 10 IPv4, $N each = $10xN because it has been configured to invoice each IPv4 leased from provider NNN for $N. It is not the purpose of the metering system to display each IPv4 used, therefore it only exposes the aggregated information. The counters define how the information should be aggregated. If the idea was to expose each resource usage individually, defining counters would be meaningless as they would duplicate the activity log from each OpenStack component. What do you think ? At DreamHost we are going to want to show each individual resource (the IPv4 address, the instance, etc.) along with the charge information. Having the metering system aggregate that data will make it difficult/impossible to present the bill summary and detail views that we want. It would be much more useful for us if it tracked the usage details for each resource, and let us aggregate the data ourselves. If other vendors want to show the data differently, perhaps we should provide separate APIs for retrieving the detailed and aggregate data. Doug Hi, For the record, here is the unfinished conversation we had on IRC (04:29:06 PM) dhellmann: dachary, did you see my reply about counter definitions on the list today? (04:39:05 PM) dachary: It means some counters must not be aggregated. Only the amount associated with it is but there is one counter per IP. (04:55:01 PM) dachary: dhellmann: what about this :the id of the ressource controls the agregation of all counters : if it is missing, all resources of the same kind and their measures are aggregated. Otherwise only the measures are agreggated. http://wiki.openstack.org/EfficientMetering?action=diffrev2=40rev1=39 http://wiki.openstack.org/EfficientMetering?action=diffrev2=40rev1=39 http://wiki.openstack.org/EfficientMetering?action=diffrev2=40rev1=39 http://wiki.openstack.org/EfficientMetering?action=diffrev2=40rev1=39 (04:55:58 PM) dachary: it makes me a little unconfortable to define such an ad-hoc grouping (04:56:53 PM) dachary: i.e. you actuall control the aggregation by chosing which value to put in the id column (04:58:43 PM) dachary: s/actuall/actually/ (05:05:38 PM) ***dachary reading http://www.ogf.org/documents/GFD.98.pdf (05:05:54 PM) dachary: I feel like we're trying to resolve a non problem here (05:08:42 PM) dachary: values need to be aggregated. The raw input is a full description of the resource and a value ( gauge ). The question is how to control the aggregation in a reasonably flexible way. (05:11:34 PM) dachary: The definition of a counter could
[Openstack] [client] creating blueprints for the unified CLI project
I have started creating blueprints from my notes about activities we need to complete for the unified CLI. Please check the list at https://blueprints.launchpad.net/python-openstackclient/ and make sure I haven't missed anything that has been discussed so far, and open a blueprint if I have. Thanks, Doug ___ 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] OpenStack Client Followup
How does this blueprint play into this client. Is it a separate admin only client or just a subset of this guy? https://blueprints.launchpad.net/nova/+spec/admin-cli -matt On Tue, May 1, 2012 at 12:28 PM, Dean Troyer dtro...@gmail.com wrote: On Tue, May 1, 2012 at 2:11 PM, Adam Spiers aspi...@suse.com wrote: As of my recent patch, --help is contextual in nova: I hadn't seen that yet... and I have started work on some of the other commands too, so it would be helpful if we could reach a consensus on this soon ... although please let me know if I am wasting my time working on other commands due to any imminent rewrites using python-openstack! The continued existence of the project-specific commands is really up to the projects themselves. I think it would be great to converge them on things like this, but trying to get them all to work the same is what led us to openstackclient due to backward compatibility and all. My guess would be that the existing client binaries would live through the 'G' release even if we decided to deprecate them now. I agree with Dolph - there is a precedent from other well-known programs (git, hg, svn are the first ones I can think of) for --help to behave differently depending on whether or not it was preceded by a subcommand. So my vote is that we should definitely aim to adhere to this pattern. How about detailing it in the HIG and once we get a command or two implemented with argument parsing we give it a shot? dt -- Dean Troyer dtro...@gmail.com ___ 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] [Metering] schema and counter definitions
On 05/01/2012 06:13 PM, Mark McLoughlin wrote: Hi Loic, On Mon, 2012-04-30 at 12:15 +0200, Loic Dachary wrote: To prepare for the next meeting ( thursday 3rd, may 2012 http://wiki.openstack.org/Meetings/MeteringAgenda ) I cleaned up and reorganized the Metering blueprint so that it ( hopefully ) incorporates all the information temporarily stored in the etherpad ( http://etherpad.openstack.org/EfficientMetering revision 67 in case it is vandalized ). I'm a bit late to the discussion, but some brief comments after reading up on what you guys have done so far: - big +1 on separating billing from metering; there's no need to conflate the two problems and doing it this way will allow for a bunch of different ideas to be tried around billing - I'd prefer to avoid adding a new node agents, so +1 on building on the notifications system I would also prefer this option. I have a few concerns though: a) adding too many messages to the existing message queues b) not all core components provide notifications c) convincing all components to agree on a unified approach to metering Instead it might be more practical to implement node agents when necessary to complete a first implementation. That is, taking advice from core component developers and possibly run into problems as opposed to convincing core component developers to adopt an approach to metering that is not yet implemented anywhere. - I agree that we don't want to go too far with aggregation and lose useful data like which instances have been running as opposed to just how many instance minutes a given tenant has consumed Another aspect of aggregation to think about is aggregation over time - e.g. I might like to see my hourly network usage has varied over the last week, or how my daily usage has varied over the last month, but I probably don't care so much about my hourly usage on a specific day 3 months ago oVirt's equivalent of a metering service does this kind of aggregation as follows: http://www.ovirt.org/wiki/Ovirt_DWH * Sample data is collected at the end of every minute and is kept for up to 48 hours. * Hourly level is aggregated every hour for the hour before last and is kept for 2 months. * Daily level is aggregated every day for the day before last and is kept for 5 years. Where can I read a description of the corresponding database ? - Lastly, bikeshed mode - since we're calling this metering and not counting, how about just using the term meters rather than counters? +1 ;-) Cheers -- Loïc Dachary Chief Research Officer // eNovance labs http://labs.enovance.com // ✉ l...@enovance.com ☎ +33 1 49 70 99 82 ___ 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] OpenStack Client Followup
On Tue, May 1, 2012 at 3:59 PM, Matt Joyce m...@nycresistor.com wrote: How does this blueprint play into this client. Is it a separate admin only client or just a subset of this guy? https://blueprints.launchpad.net/nova/+spec/admin-cli Since we are consumers of the python-novaclient API libraries we need to track the movement of the admin stuff. That particular blueprint has not been targeted yet so we don't know if it will be implemented in folsom. As far as whether we support admin-only commands, I think we should. If they have their own client libs then we'll split them up too. I actually kind of liked the side effect of the old nova-manage in that it was self-enforcing for admin-ness since you needed to run it on the node itself. dt -- Dean Troyer dtro...@gmail.com ___ 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] Instance IP assignment problem
On Tue, May 1, 2012 at 12:00 PM, Salman Malik salma...@live.com wrote: Hi, Here is the error log: http://pastebin.com/KrNZDrvD and nova.conf: http://pastebin.com/Fvd6dSZs Emilien, I am trying to get an understanding of how different Quantum plugins work with OpenStack. Ryu plugin is particularly interesting as it uses an OpenFlow controller to configure Vswitches. The problem I am faced with is (I think ) that I already have a private network and Quantum should assign IP addresses to instances using DHCP. But instances send out discover message on laucnh but never find a DHCP server (although there are 2 dnsmasqs running). I would first try this out with something like the OVS plugin (which incidentally uses OpenFlow as wel). This is a pretty commonly used configuration, and will help determine if the problem is in your configuration, or the Ryu plugin in particular. I would also try and see if dnsmasq is actually getting the request and sending a reply. You should be able to tcpdump on the linux device that dnsmasq is bound to (should start with gw-*). Alternately, you could look in /var/log/syslog (i think?) to see if dnsmasq if logging that is correctly receiving the DHCP requests. Dan Any ideas? Thanks, Salman -- Date: Tue, 1 May 2012 20:43:44 +0200 Subject: Re: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: emilien.openst...@gmail.com CC: openstack@lists.launchpad.net; salma...@live.com Hi Emilien and Salman, Please, could you upload all the files, errors and conf in pastebin or something like that? I have troubles to open in phone :) Thank you El 01/05/2012 20:39, Emilien Macchi emilien.openst...@gmail.com escribió: ** Hi, I have a similar problem when I create a network per project_id with Quantum. My VMs don't get IP and I can't understand why today. But when I create a private network for all projects, VMs get an IP and all is working well. Do you have the same problem ? Salman, I'm interesting about your nova.conf. I can see you are using Ryu ? Can you tell me more about your use case or architecture ? Thanks Le mardi 01 mai 2012 à 12:28 -0500, Salman Malik a écrit : Hi Jorge, Thanks for looking into the post. I have made changes to the nova.conf file so that I only use 10.0.0.x network (but the problem is still the same). For this configuration, I assume that it will give out IPs to instances starting from 10.0.0.11. And just to inform you, my eth1 is configured to be 10.0.0.10 (which is a VM itself, and eth1 is configured as a host-only network with no DHCP) and this interface is plugged in the integration bridge used by quantum plugins. Thanks, Salman PS: Error log of a launched instance is also attached. -- Date: Tue, 1 May 2012 19:03:49 +0200 Subject: Re: [Openstack] Instance IP assignment problem From: jorge.delac...@stackops.com To: salma...@live.com CC: openstack@lists.launchpad.net Im not really sure but you are using range for your environment 10.0.3.x and 10.0.0.x for fixed. Can you attach a nova network conf? Regards El 01/05/2012 18:56, Salman Malik salma...@live.com escribió: Hi Guys, Can anyone provide any insight to the following question: https://answers.launchpad.net/nova/+question/195439 Thanks, Salman ___ 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 -- ~~~ 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
Re: [Openstack] OpenStack Client Followup
As far as whether we support admin-only commands, I think we should. If they have their own client libs then we'll split them up too. I actually kind of liked the side effect of the old nova-manage in that it was self-enforcing for admin-ness since you needed to run it on the node itself. I think federation may drive us away from that sort of isolation. And, eventually drive us right back to it in some other container. -Matt ___ 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] Nova volume service and the nova client command
OK, I'm an idiot.
If I understand correctly, nova-volume provides the 'backend' service. So to
run nova-volume on a separate node, I apparently have to also install the
nova-api (and associated python-keystone modules)? Is this correct? Or will
the backend messaging (rabbitmq) allow the nova-api service running on one node
to correctly control the nova-volume backend on another node?
Thanks in advance!
Ross
On May 1, 2012, at 3:15 PM, Lillie Ross-CDSR11 wrote:
I've configured the nova_volume service using the the Ubuntu 12.04LTS
packages, and am able to create/delete volumes using the euca2ools package.
However, dashboard is not able to retrieve volume info or perform volume
operations with the nova client. If I issue the 'nova volume-list' command,
I receive a 400 error response. For example
root@essex1:/etc/nova# nova --debug volume-list
connect: (essex1, 5000)
send: 'POST /v2.0/tokens HTTP/1.1\r\nHost: essex1:5000\r\nContent-Length:
100\r\ncontent-type: application/json\r\naccept-encoding: gzip,
deflate\r\naccept: application/json\r\nuser-agent:
python-novaclient\r\n\r\n{auth: {tenantName: admin,
passwordCredentials: {username: admin, password: admin}}}'
reply: 'HTTP/1.1 200 OK\r\n'
header: Content-Type: application/json
header: Vary: X-Auth-Token
header: Date: Tue, 01 May 2012 20:06:39 GMT
header: Transfer-Encoding: chunked
connect: (essex4, 8776)
connect fail: (u'essex4', 8776)
DEBUG (shell:416) n/a (HTTP 400)
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 413, in
main
OpenStackComputeShell().main(sys.argv[1:])
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 364, in
main
args.func(self.cs, args)
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/shell.py, line 858,
in do_volume_list
volumes = cs.volumes.list()
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/volumes.py, line 79,
in list
return self._list(/volumes/detail, volumes)
File /usr/lib/python2.7/dist-packages/novaclient/base.py, line 71, in _list
resp, body = self.api.client.get(url)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 136, in
get
return self._cs_request(url, 'GET', **kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 124, in
_cs_request
**kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 107, in
request
raise exceptions.from_response(resp, body)
BadRequest: n/a (HTTP 400)
ERROR: n/a (HTTP 400)
root@essex1:/etc/nova#
Node essex1 is the cloud controller. essex4 is the volume controller. To
verify the connection failure, if I try to telnet to port 8776 I also get a
connect refused. My nova-volume endpoint is specified in keystone as
'http://essex4:8776/v1/$(tenant_id)s'. With the above connection failure,
nothing is written to the nova-volume.log (which makes sense if the server
isn't listening to port 8776). Obviously, none of the other nova volume
commands work.
Anything obvious that I'm missing? Thanks in advance
Regards,
Ross
___
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] Instance IP assignment problem
Hi Dan, Thank you so much for the reply. Instances were getting IP addresses when I used the fake plugin (I haven't tried it with OVS plugin i think). Anyway, I did dig into the problem. It seems that the Ryu is dropping the DHCP requests. Here is the output that I got by ovs-ofctl snoop br-int: OFPT_FLOW_MOD (xid=0x463fc2e): ADD in_port=1,dl_src=08:00:27:00:08:0e,dl_dst=01:00:5e:7f:ff:fa flags:0x1 actions=drop OFPT_PACKET_OUT (xid=0x463fc2f): in_port=1 actions_len=0 actions=drop buffer=0x0b61 OFPT_ECHO_REQUEST (xid=0x0): 0 bytes of payload OFPT_ECHO_REPLY (xid=0x0): 0 bytes of payload OFPT_PACKET_IN (xid=0x0): total_len=90 in_port=33 data_len=90 buffer=0x0b62 tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2-33:33:00:00:00:16 type86dd proto58 tos0 ipv6::-ff02::16 port143-0 fa:16:3e:6f:5f:c2 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: :: ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 OFPT_PACKET_OUT (xid=0x463fc30): in_port=33 actions_len=0 actions=drop buffer=0x0b62 OFPT_PACKET_IN (xid=0x0): total_len=322 in_port=33 data_len=128 buffer=0x0b63 tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2-ff:ff:ff:ff:ff:ff type0800 proto17 tos0 ip0.0.0.0-255.255.255.255 port68-67 fa:16:3e:6f:5f:c2 ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 128: truncated-ip - 194 bytes missing! 0.0.0.0.68 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:6f:5f:c2, length 280 OFPT_PACKET_OUT (xid=0x463fc31): in_port=33 actions_len=0 actions=drop buffer=0x0b63 OFPT_PACKET_IN (xid=0x0): total_len=78 in_port=33 data_len=78 buffer=0x0b64 tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2-33:33:ff:6f:5f:c2 type86dd proto58 tos0 ipv6::-ff02::1:ff6f:5fc2 port135-0 fa:16:3e:6f:5f:c2 33:33:ff:6f:5f:c2, ethertype IPv6 (0x86dd), length 78: :: ff02::1:ff6f:5fc2: ICMP6, neighbor solicitation, who has fe80::f816:3eff:fe6f:5fc2, length 24 OFPT_PACKET_OUT (xid=0x463fc32): in_port=33 actions_len=0 actions=drop buffer=0x0b64 OFPT_PACKET_IN (xid=0x0): total_len=70 in_port=33 data_len=70 buffer=0x0b65 tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2-33:33:00:00:00:02 type86dd proto58 tos0 ipv6fe80::f816:3eff:fe6f:5fc2-ff02::2 port133-0 fa:16:3e:6f:5f:c2 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::f816:3eff:fe6f:5fc2 ff02::2: ICMP6, router solicitation, length 16 OFPT_PACKET_OUT (xid=0x463fc33): in_port=33 actions_len=0 actions=drop buffer=0x0b65 OFPT_PACKET_IN (xid=0x0): total_len=322 in_port=33 data_len=128 buffer=0x0b66 tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2-ff:ff:ff:ff:ff:ff type0800 proto17 tos0 ip0.0.0.0-255.255.255.255 port68-67 fa:16:3e:6f:5f:c2 ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 128: truncated-ip - 194 bytes missing! 0.0.0.0.68 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:6f:5f:c2, length 280 OFPT_PACKET_OUT (xid=0x463fc34): in_port=33 actions_len=0 actions=drop buffer=0x0b66 OFPT_PACKET_IN (xid=0x0): total_len=90 in_port=33 data_len=90 buffer=0x0b67 tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2-33:33:00:00:00:16 type86dd proto58 tos0 ipv6fe80::f816:3eff:fe6f:5fc2-ff02::16 port143-0 fa:16:3e:6f:5f:c2 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: fe80::f816:3eff:fe6f:5fc2 ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 OFPT_PACKET_OUT (xid=0x463fc35): in_port=33 actions_len=0 actions=drop buffer=0x0b67 OFPT_PACKET_IN (xid=0x0): total_len=70 in_port=33 data_len=70 buffer=0x0b68 tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2-33:33:00:00:00:02 type86dd proto58 tos0 ipv6fe80::f816:3eff:fe6f:5fc2-ff02::2 port133-0 fa:16:3e:6f:5f:c2 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::f816:3eff:fe6f:5fc2 ff02::2: ICMP6, router solicitation, length 16 OFPT_PACKET_OUT (xid=0x463fc36): in_port=33 actions_len=0 actions=drop buffer=0x0b68 Here is the output of brctl show br-int: === OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:08002716d509 n_tables:1, n_buffers:256 features: capabilities:0x87, actions:0xfff 1(eth1): addr:08:00:27:16:d5:09 config: 0 state: 0 current:1GB-FD COPPER AUTO_NEG advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG supported: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG 2(gw-f3eda887-fd): addr:fa:16:3e:28:e2:1b config: 0 state: 0 33(tap66377ec5-bb): addr:96:3e:0d:2d:68:23 config: 0 state: 0 current:10MB-FD COPPER LOCAL(br-int): addr:08:00:27:16:d5:09 config: PORT_DOWN state: LINK_DOWN OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0 === and yes, I was unable to get messages on gw-* interface. How can I resolve this problem ?
Re: [Openstack] Nova volume service and the nova client command
Once again, I think I'm answering my own question.
Nova_volume works in conjunction with nova-api to talk to any number of iscsi
targets that you might have configured in your cloud. Each target runs an
instance of nova-volume. The URL for the volume service should point at the
host(s) running the nova-api front end. Nova-volume listens to the appropriate
AMQP channel to perform the necessary LVM commands.
Am I missing anything?
Sorry for all questions. I just needed to think things through a bit more…
/ross
On May 1, 2012, at 3:15 PM, Lillie Ross-CDSR11 wrote:
I've configured the nova_volume service using the the Ubuntu 12.04LTS
packages, and am able to create/delete volumes using the euca2ools package.
However, dashboard is not able to retrieve volume info or perform volume
operations with the nova client. If I issue the 'nova volume-list' command,
I receive a 400 error response. For example
root@essex1:/etc/nova# nova --debug volume-list
connect: (essex1, 5000)
send: 'POST /v2.0/tokens HTTP/1.1\r\nHost: essex1:5000\r\nContent-Length:
100\r\ncontent-type: application/json\r\naccept-encoding: gzip,
deflate\r\naccept: application/json\r\nuser-agent:
python-novaclient\r\n\r\n{auth: {tenantName: admin,
passwordCredentials: {username: admin, password: admin}}}'
reply: 'HTTP/1.1 200 OK\r\n'
header: Content-Type: application/json
header: Vary: X-Auth-Token
header: Date: Tue, 01 May 2012 20:06:39 GMT
header: Transfer-Encoding: chunked
connect: (essex4, 8776)
connect fail: (u'essex4', 8776)
DEBUG (shell:416) n/a (HTTP 400)
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 413, in
main
OpenStackComputeShell().main(sys.argv[1:])
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 364, in
main
args.func(self.cs, args)
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/shell.py, line 858,
in do_volume_list
volumes = cs.volumes.list()
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/volumes.py, line 79,
in list
return self._list(/volumes/detail, volumes)
File /usr/lib/python2.7/dist-packages/novaclient/base.py, line 71, in _list
resp, body = self.api.client.get(url)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 136, in
get
return self._cs_request(url, 'GET', **kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 124, in
_cs_request
**kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 107, in
request
raise exceptions.from_response(resp, body)
BadRequest: n/a (HTTP 400)
ERROR: n/a (HTTP 400)
root@essex1:/etc/nova#
Node essex1 is the cloud controller. essex4 is the volume controller. To
verify the connection failure, if I try to telnet to port 8776 I also get a
connect refused. My nova-volume endpoint is specified in keystone as
'http://essex4:8776/v1/$(tenant_id)s'. With the above connection failure,
nothing is written to the nova-volume.log (which makes sense if the server
isn't listening to port 8776). Obviously, none of the other nova volume
commands work.
Anything obvious that I'm missing? Thanks in advance
Regards,
Ross
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
[Openstack] [Cinder] Status updates and proposals
All, For those folks that have expressed an interest in contributing to the Cinder project we've made some minor progress. We've grabbed the wiki page: http://wiki.openstack.org/Cinder Note that currently we're keeping track of updates and what folks are working on via etherpad: http://etherpad.openstack.org/cinder-worksheet Please check it out, and feel free to jump in. John ___ 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] [Metering] how should it be done ? ( Was: schema and counter definitions)
On 05/01/2012 09:57 PM, Andrew Clay Shafer wrote: I'm glad to see people championing the effort to implement metering. Is there someway to refocus the enthusiasm for solving the metering problem into engineering a general solution in OpenStack? I'm just going to apologize in advance, but I don't think this project is headed in the right direction. I believe metering should be a first class concern of OpenStack and the way this project is starting is almost exactly backwards from what I think a solution to metering should look like. The last thing I want to see right now is a blessed OpenStack metering project adding more agents, coupled to a particular db and making policy decisions about what is quantifiable. I think there are really three problems that need to be solved to do metering, what data to get, getting the data and doing things with the data. From my perspective, a lot if not all of the data events should be coming out of the services themselves. There is already a service that should know when an instance gets started by what tenant. A cross cutting system for publishing those events and a service definition for collecting them seems like a reasonable place to start. To me that should look awful lot like a message queue or centralized logging. Once the first two problems are solved well, if you are so inclined to collect the data into a relational model, the schema will be obvious. If the first two problems are solved well, then I could be persuaded that a service that provides some of the aggregation functionality is a great idea and a reference implementation on a relational database isn't the worst thing in the world. Without a general solution for the first two problems, I believe the primary focus on a schema and db is premature and sub-optimal. I also believe the current approach likely results in a project that is generally unusable. Does anyone else share my perspective? It would be better if all OpenStack core components agreed on unified interfaces / messages for metering that would be easy to harvest without installing agents on nodes. This is also true for many services outside of the OpenStack eco-system. However, much in the same way munin and nagios plugins are developped outside of the project for which they provide graphing and monitoring (for instance we recently published swift munin plugins in the repository where ops usually look for them : https://github.com/munin-monitoring/contrib/tree/master/plugins/swift and there is no glance plugin or up-to-date nova plugins yet ), metering agents will be developed separately, most of the time. As I wrote in a previous mail, once we manage to provide an implementation that proves useful, we will be in a position to approach the core OpenStack components. Integrating the metering agents as part of the core component, much in the same way it's currently done in nova. That will reduce the overall complexity of deploying OpenStack with metering (which must not be mandatory). However, there is very little chance that all components developed around OpenStack are convinced and there will always be a need for a metering that is external to the component. Therefore, even if metering eventually manages to become a first class concern for the core OpenStack components, the proposed architecture of the metering project ( per node agents when necessary and a collector harvesting them into a storage ) will keep being used for other components. Do you think I'm wrong ? We're at a very early stage and now is the time to question everything :-) ___ 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] Instance IP assignment problem
On Tue, May 1, 2012 at 2:55 PM, Salman Malik salma...@live.com wrote: Hi Dan, Thank you so much for the reply. Instances were getting IP addresses when I used the fake plugin (I haven't tried it with OVS plugin i think). Anyway, I did dig into the problem. It seems that the Ryu is dropping the DHCP requests. Here is the output that I got by ovs-ofctl snoop br-int: Ok, I've never actually used the Ryu plugin. Hopefully the ryu plugin developer is on the list and can help you investigate this. dan OFPT_FLOW_MOD (xid=0x463fc2e): ADD in_port=1,dl_src=08:00:27:00:08:0e,dl_dst=01:00:5e:7f:ff:fa flags:0x1 actions=drop OFPT_PACKET_OUT (xid=0x463fc2f): in_port=1 actions_len=0 actions=drop buffer=0x0b61 OFPT_ECHO_REQUEST (xid=0x0): 0 bytes of payload OFPT_ECHO_REPLY (xid=0x0): 0 bytes of payload OFPT_PACKET_IN (xid=0x0): total_len=90 in_port=33 data_len=90 buffer=0x0b62 tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2-33:33:00:00:00:16 type86dd proto58 tos0 ipv6::-ff02::16 port143-0 fa:16:3e:6f:5f:c2 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: :: ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 OFPT_PACKET_OUT (xid=0x463fc30): in_port=33 actions_len=0 actions=drop buffer=0x0b62 OFPT_PACKET_IN (xid=0x0): total_len=322 in_port=33 data_len=128 buffer=0x0b63 tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2-ff:ff:ff:ff:ff:ff type0800 proto17 tos0 ip0.0.0.0-255.255.255.255 port68-67 fa:16:3e:6f:5f:c2 ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 128: truncated-ip - 194 bytes missing! 0.0.0.0.68 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:6f:5f:c2, length 280 OFPT_PACKET_OUT (xid=0x463fc31): in_port=33 actions_len=0 actions=drop buffer=0x0b63 OFPT_PACKET_IN (xid=0x0): total_len=78 in_port=33 data_len=78 buffer=0x0b64 tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2-33:33:ff:6f:5f:c2 type86dd proto58 tos0 ipv6::-ff02::1:ff6f:5fc2 port135-0 fa:16:3e:6f:5f:c2 33:33:ff:6f:5f:c2, ethertype IPv6 (0x86dd), length 78: :: ff02::1:ff6f:5fc2: ICMP6, neighbor solicitation, who has fe80::f816:3eff:fe6f:5fc2, length 24 OFPT_PACKET_OUT (xid=0x463fc32): in_port=33 actions_len=0 actions=drop buffer=0x0b64 OFPT_PACKET_IN (xid=0x0): total_len=70 in_port=33 data_len=70 buffer=0x0b65 tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2-33:33:00:00:00:02 type86dd proto58 tos0 ipv6fe80::f816:3eff:fe6f:5fc2-ff02::2 port133-0 fa:16:3e:6f:5f:c2 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::f816:3eff:fe6f:5fc2 ff02::2: ICMP6, router solicitation, length 16 OFPT_PACKET_OUT (xid=0x463fc33): in_port=33 actions_len=0 actions=drop buffer=0x0b65 OFPT_PACKET_IN (xid=0x0): total_len=322 in_port=33 data_len=128 buffer=0x0b66 tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2-ff:ff:ff:ff:ff:ff type0800 proto17 tos0 ip0.0.0.0-255.255.255.255 port68-67 fa:16:3e:6f:5f:c2 ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 128: truncated-ip - 194 bytes missing! 0.0.0.0.68 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:6f:5f:c2, length 280 OFPT_PACKET_OUT (xid=0x463fc34): in_port=33 actions_len=0 actions=drop buffer=0x0b66 OFPT_PACKET_IN (xid=0x0): total_len=90 in_port=33 data_len=90 buffer=0x0b67 tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2-33:33:00:00:00:16 type86dd proto58 tos0 ipv6fe80::f816:3eff:fe6f:5fc2-ff02::16 port143-0 fa:16:3e:6f:5f:c2 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: fe80::f816:3eff:fe6f:5fc2 ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 OFPT_PACKET_OUT (xid=0x463fc35): in_port=33 actions_len=0 actions=drop buffer=0x0b67 OFPT_PACKET_IN (xid=0x0): total_len=70 in_port=33 data_len=70 buffer=0x0b68 tunnel0:in_port0021:tci(0) macfa:16:3e:6f:5f:c2-33:33:00:00:00:02 type86dd proto58 tos0 ipv6fe80::f816:3eff:fe6f:5fc2-ff02::2 port133-0 fa:16:3e:6f:5f:c2 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::f816:3eff:fe6f:5fc2 ff02::2: ICMP6, router solicitation, length 16 OFPT_PACKET_OUT (xid=0x463fc36): in_port=33 actions_len=0 actions=drop buffer=0x0b68 Here is the output of brctl show br-int: === OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:08002716d509 n_tables:1, n_buffers:256 features: capabilities:0x87, actions:0xfff 1(eth1): addr:08:00:27:16:d5:09 config: 0 state: 0 current:1GB-FD COPPER AUTO_NEG advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG supported: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG 2(gw-f3eda887-fd): addr:fa:16:3e:28:e2:1b config: 0 state: 0 33(tap66377ec5-bb): addr:96:3e:0d:2d:68:23 config: 0 state: 0 current:10MB-FD COPPER LOCAL(br-int): addr:08:00:27:16:d5:09 config:
Re: [Openstack] python-quantum client essex branch
Hi Edgar, Looks like that branch was never updated from milestone-proposed for Essex-RC2 to essex final. I'll take a look into why. In the mean time, you can just use the milestone-proposed tag: https://github.com/openstack/python-quantumclient/commits/milestone-proposed Dan On Tue, May 1, 2012 at 1:22 PM, Edgar Magana (eperdomo) eperd...@cisco.comwrote: Hello Folks, I was trying to get the essex branch for the Quantum Client but it seems that is not in github. Does anyone could indicate how to get it? I am trying to get all services based on essex release and not the current trunk. Thanks, Edgar ___ 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
Re: [Openstack] [client] OpenStack Client Followup
Dean Troyer (dtro...@gmail.com) wrote: On Mon, Apr 30, 2012 at 11:13 AM, Adam Spiers aspi...@suse.com wrote: Count me in - by 'build a list' do you mean a new mailing list? You're in! For now that's just a list I'm keeping. OK, great :) tweaks. Should we discuss the FIXMEs you marked here or elsewhere? I wanted to make a few suggestions before I forget - can always continue discussion elsewhere if appropriate: This is it for now except for what we may do in the wiki itself while writing the doc. OK - I boldified the existing FIXMEs and added some new stuff. There is activity going on that may shift traffic on the lists. One of the things that will happen is the addition of prefixes in the subject so we can start by using [client]. Yup I saw Thierry's announcement so [client] is a good idea - have done. 1. Regarding The subject names are always specified in command in their singular form. This is contrary to natural language use. - I didn't understand the second sentence here, but shouldn't the HIG should allow for scenarios where the verb can operate both on individual objects and on multiple objects in batch? I was referring to 'list server' vs 'list servers'. It would be nice to accept either where plural is natural, but that is a lower priority thing to solve. Right. (Grammatical nitpick: if the verb is acting on the noun, then the HIG should refer to the noun as object rather than subject.) That was a deliberate choice based on how overloaded the word 'object' is in programming. My HS English teacher is preparing a detention for me I'm sure... Hahah, good point :) 2. I think it would be good if the HIG gave guidelines on how the command should behave when run with no arguments. For some commands that is totally valid, for some that is an error condition. True, so I should have said: I think it would be good if the HIG gave guidelines on how commands which require arguments should behave when run with no arguments. ... and in this case I would suggest that the command behaves as if it was run with the '--help' argument; as I have said elsewhere on this thread, I find commands like svn which do not do this to be needlessly unhelpful: $ svn Type 'svn help' for usage. Why does it insist on making the user type more? Reminds me of parts of this conversation: http://www.youtube.com/watch?v=sr1IXB194aE 3. I think it would be good if the HIG recommended that, at least when subcommands are permitted, single arguments '--help' and 'help' always generate identical output: The intent is for '-h' and '--help' to provide global options and how to get specific command help. A 'help' command should list the available commands based on installed modules (and ultimately on permissions?) and 'help command' should display detailed help on 'command'. I see. Personally I'm not too keen on that, because users are likely to forget which of '--help' and 'help' lists the available commands, or accidentally type the wrong one, and in either case they'd end up having to type two commands rather than one. So why not make both output all the information they need? https://bugs.launchpad.net/keystone/+bug/936399 Heh. My past catches up with me. I've changed my mind here due to the potentially long list of commands involved. Simple, obvious, concise. Pick two. ;) I'll pick all three by taking a leaf out of git's book :-) $ git --help usage: git [--version] [--exec-path[=path]] [--html-path] [--man-path] [--info-path] [-p|--paginate|--no-pager] [--no-replace-objects] [--bare] [--git-dir=path] [--work-tree=path] [--namespace=name] [-c name=value] [--help] command [args] The most commonly used git commands are: addAdd file contents to the index bisect Find by binary search the change that introduced a bug [snipped] status Show the working tree status tagCreate, list, delete or verify a tag object signed with GPG See 'git help command' for more information on a specific command. Presumably the most commonly used commands could be marked out using decorators. BTW exactly the same output as above is generated by running git with no arguments. Another output format worth remembering is the column-based one: $ git help -a usage: git [--version] [--exec-path[=path]] [--html-path] [--man-path] [--info-path] [-p|--paginate|--no-pager] [--no-replace-objects] [--bare] [--git-dir=path] [--work-tree=path] [--namespace=name] [-c name=value] [--help] command [args] available git commands in '/usr/lib/git' add hash-object remote-ext add--interactive help remote-fd [snipped] git commands
Re: [Openstack] [Metering] schema and counter definitions
Hey, On Tue, 2012-05-01 at 23:05 +0200, Loic Dachary wrote: On 05/01/2012 06:13 PM, Mark McLoughlin wrote: Hi Loic, On Mon, 2012-04-30 at 12:15 +0200, Loic Dachary wrote: - I agree that we don't want to go too far with aggregation and lose useful data like which instances have been running as opposed to just how many instance minutes a given tenant has consumed Another aspect of aggregation to think about is aggregation over time - e.g. I might like to see my hourly network usage has varied over the last week, or how my daily usage has varied over the last month, but I probably don't care so much about my hourly usage on a specific day 3 months ago oVirt's equivalent of a metering service does this kind of aggregation as follows: http://www.ovirt.org/wiki/Ovirt_DWH * Sample data is collected at the end of every minute and is kept for up to 48 hours. * Hourly level is aggregated every hour for the hour before last and is kept for 2 months. * Daily level is aggregated every day for the day before last and is kept for 5 years. Where can I read a description of the corresponding database ? Here FWIW: http://goo.gl/3Bqct Cheers, Mark. ___ 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] [Metering] schema and counter definitions
On Tue, 2012-05-01 at 23:05 +0200, Loic Dachary wrote: On 05/01/2012 06:13 PM, Mark McLoughlin wrote: Hi Loic, On Mon, 2012-04-30 at 12:15 +0200, Loic Dachary wrote: To prepare for the next meeting ( thursday 3rd, may 2012 http://wiki.openstack.org/Meetings/MeteringAgenda ) I cleaned up and reorganized the Metering blueprint so that it ( hopefully ) incorporates all the information temporarily stored in the etherpad ( http://etherpad.openstack.org/EfficientMetering revision 67 in case it is vandalized ). I'm a bit late to the discussion, but some brief comments after reading up on what you guys have done so far: - big +1 on separating billing from metering; there's no need to conflate the two problems and doing it this way will allow for a bunch of different ideas to be tried around billing - I'd prefer to avoid adding a new node agents, so +1 on building on the notifications system I would also prefer this option. I have a few concerns though: a) adding too many messages to the existing message queues b) not all core components provide notifications c) convincing all components to agree on a unified approach to metering Instead it might be more practical to implement node agents when necessary to complete a first implementation. That is, taking advice from core component developers and possibly run into problems as opposed to convincing core component developers to adopt an approach to metering that is not yet implemented anywhere. I'd start with metering using the notifications which are already there. I think that will get us a long way. My impression is that the notifications system is intended to cover all billable usage in at least Nova and Glance. Cheers, Mark. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] launching instance failed since of nova-network quantum
Hi, all
I use quantum and OVS in ubuntu 12.04 ,when I lanuch an instance, it return
networking error.
This is nova-network log:
2012-05-02 13:26:38 DEBUG nova.utils
[req-3c1ab45e-7ea3-4e83-a899-ab1a8dbde09d a372a6b75d254b15b83cc203518a8a45
5567b78b1a3f4bc68421fe74e044f4e3] Attempting to grab semaphore
quantum-enable-dhcp for method enable_dhcp... from (pid=31609) inner
/usr/lib/python2.7/dist-packages/nova/utils.py:927
2012-05-02 13:26:38 DEBUG nova.utils
[req-3c1ab45e-7ea3-4e83-a899-ab1a8dbde09d a372a6b75d254b15b83cc203518a8a45
5567b78b1a3f4bc68421fe74e044f4e3] Got semaphore quantum-enable-dhcp for
method enable_dhcp... from (pid=31609) inner
/usr/lib/python2.7/dist-packages/nova/utils.py:931
2012-05-02 13:26:38 INFO nova.network.quantum.manager
[req-3c1ab45e-7ea3-4e83-a899-ab1a8dbde09d a372a6b75d254b15b83cc203518a8a45
5567b78b1a3f4bc68421fe74e044f4e3] Using DHCP for network: test-1
2012-05-02 13:26:38 DEBUG nova.network.quantum.quantum_connection
[req-3c1ab45e-7ea3-4e83-a899-ab1a8dbde09d a372a6b75d254b15b83cc203518a8a45
5567b78b1a3f4bc68421fe74e044f4e3] Quantum Client Request: GET
/v1.1/tenants/5567b78b1a3f4bc68421fe74e044f4e3/networks/b7eb78f2-b4c2-4106-99c0-0b99f58b2e1e/ports.json?attachment=gw-b7eb78f2-b4
from (pid=31609) do_request
/usr/lib/python2.7/dist-packages/nova/network/quantum/client.py:181
2012-05-02 13:26:38 DEBUG nova.network.quantum.quantum_connection
[req-3c1ab45e-7ea3-4e83-a899-ab1a8dbde09d a372a6b75d254b15b83cc203518a8a45
5567b78b1a3f4bc68421fe74e044f4e3] Quantum Client Reply (code = 200) :
{ports: []} from (pid=31609) do_request
/usr/lib/python2.7/dist-packages/nova/network/quantum/client.py:192
2012-05-02 13:26:38 DEBUG nova.utils
[req-3c1ab45e-7ea3-4e83-a899-ab1a8dbde09d a372a6b75d254b15b83cc203518a8a45
5567b78b1a3f4bc68421fe74e044f4e3] Running cmd (subprocess): ip link show
dev gw-b7eb78f2-b4 from (pid=31609) execute
/usr/lib/python2.7/dist-packages/nova/utils.py:219
2012-05-02 13:26:38 DEBUG nova.utils
[req-3c1ab45e-7ea3-4e83-a899-ab1a8dbde09d a372a6b75d254b15b83cc203518a8a45
5567b78b1a3f4bc68421fe74e044f4e3] Result was 1 from (pid=31609) execute
/usr/lib/python2.7/dist-packages/nova/utils.py:235
2012-05-02 13:26:38 DEBUG nova.utils
[req-3c1ab45e-7ea3-4e83-a899-ab1a8dbde09d a372a6b75d254b15b83cc203518a8a45
5567b78b1a3f4bc68421fe74e044f4e3] Running cmd (subprocess): sudo
nova-rootwrap ovs-vsctl -- --may-exist add-port br-int gw-b7eb78f2-b4 --
set Interface gw-b7eb78f2-b4 type=internal -- set Interface gw-b7eb78f2-b4
external-ids:iface-id=gw-b7eb78f2-b4 -- set Interface gw-b7eb78f2-b4
external-ids:iface-status=active -- set Interface gw-b7eb78f2-b4
external-ids:attached-mac=fa:16:3e:6f:b7:38 from (pid=31609) execute
/usr/lib/python2.7/dist-packages/nova/utils.py:219
2012-05-02 13:27:16 DEBUG nova.manager
[req-91974e5f-cea9-44a3-a4e3-ef5955aee599 None None] Running periodic task
QuantumManager._publish_service_capabilities from (pid=31609)
periodic_tasks /usr/lib/python2.7/dist-packages/nova/manager.py:152
2012-05-02 13:27:16 DEBUG nova.manager
[req-91974e5f-cea9-44a3-a4e3-ef5955aee599 None None] Running periodic task
QuantumManager._disassociate_stale_fixed_ips from (pid=31609)
periodic_tasks /usr/lib/python2.7/dist-packages/nova/manager.py:152
2012-05-02 13:27:23 DEBUG nova.rpc.amqp [-] received {u'_context_roles':
[u'admin'], u'_msg_id': u'7584dd267c8f47caa02927c88912383a',
u'_context_read_deleted': u'no', u'_context_request_id':
u'req-9e8a3e43-f55c-4a1e-8565-892708a85338', u'args': {u'instance_id': 2,
u'instance_uuid': u'dc18235c-977f-4fd2-8828-b98155ce2307', u'host':
u'cloud', u'project_id': u'5567b78b1a3f4bc68421fe74e044f4e3',
u'rxtx_factor': 1.0}, u'_context_auth_token': 'SANITIZED',
u'_context_is_admin': True, u'_context_project_id': None,
u'_context_timestamp': u'2012-05-02T05:27:22.702310', u'_context_user_id':
None, u'method': u'get_instance_nw_info', u'_context_remote_address': None}
from (pid=31609) _safe_log
/usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
2012-05-02 13:27:23 DEBUG nova.rpc.amqp
[req-9e8a3e43-f55c-4a1e-8565-892708a85338 None None] unpacked context:
{'user_id': None, 'roles': [u'admin'], 'timestamp':
'2012-05-02T05:27:22.702310', 'auth_token': 'SANITIZED',
'remote_address': None, 'is_admin': True, 'request_id':
u'req-9e8a3e43-f55c-4a1e-8565-892708a85338', 'project_id': None,
'read_deleted': u'no'} from (pid=31609) _safe_log
/usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
This is nova-compute log:
2012-05-02 13:27:23 DEBUG nova.virt.libvirt.connection
[req-9e8a3e43-f55c-4a1e-8565-892708a85338 None None] Connecting to libvirt:
qemu:///system from (pid=31711) _get_connection
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py:292
2012-05-02 13:27:23 DEBUG nova.virt.libvirt.connection
[req-9e8a3e43-f55c-4a1e-8565-892708a85338 None None] Updating host stats
from (pid=31711) update_status
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py:2467
2012-05-02 13:27:23 DEBUG nova.manager
Re: [Openstack-qa-team] Agenda for next meeting
On 04/30/2012 04:30 PM, David Kranz wrote: Does any one have any new items to add to the agenda for this week's meeting? So far we have: 1. Getting some consensus on what precisely a smoke test is and discussing some code Jay will have pushed that cleans up our smoke test abilities. Yep, I'll be pushing some code this morning and a mailing list post to spark the discussion. :) 2. Strategy for maintaining the stable/essex tempest branch: a) How much effort should we put into backports of new tempest tests? b) Should be we gating, or have jenkins jobs for, checkins to stable/essex code? I'd also like to add another agenda item: Can we come to a consensus on the subset of Tempest tests that we recommend to the core projects to get their trunks? Best, -jay -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
