Re: [Openstack] Shutoff Status
Hi Anne :-)I think it only doesn't applies to- ESX- QEMU- LXCWhile it has been implemented on the other hypervisors technologies :http://wiki.openstack.org/HypervisorSupportMatrixMaybe some doc update needed around ?Later,Razique
Nuage Co - Razique Mahrouarazique.mahr...@gmail.com
Le 24 avr. 2012 à 05:02, Anne Gentle a écrit :Hi all -We just added descriptions of each of the statuses to this page, but "SUSPENDED" is not one of them:http://docs.openstack.org/api/openstack-compute/2/content/List_Servers-d1e2078.html
Who has more information about this server status? By grepping the code I get this additional info which may mean it only applies to bare metal deploy and/or xenapi?./nova/api/ec2/cloud.py: vm_states.SUSPENDED: inst_state.SUSPEND,
./nova/api/openstack/common.py: vm_states.SUSPENDED: {./nova/api/openstack/common.py: 'default': 'SUSPENDED',./nova/compute/api.py: @check_instance_state(vm_state=[vm_states.SUSPENDED])
./nova/compute/api.py: vm_state=vm_states.SUSPENDED,./nova/compute/manager.py: vm_state=vm_states.SUSPENDED,./nova/compute/power_state.py:SUSPENDED = 0x07./nova/compute/power_state.py: SUSPENDED: 'suspended',
./nova/compute/vm_states.py:SUSPENDED = 'suspended'./nova/tests/baremetal/test_proxy_bare_metal.py: dict(node_id=8, name='i-0008', status=power_state.SUSPENDED),./nova/tests/test_compute.py: {'vm_state': vm_states.SUSPENDED})
./nova/tests/test_compute.py: search_opts={'power_state': power_state.SUSPENDED})./nova/virt/baremetal/proxy.py: 'power_state': power_state.SUSPENDED})./nova/virt/xenapi/vm_utils.py: 'Suspended': power_state.SUSPENDED,
Thanks,AnneOn Mon, Apr 23, 2012 at 9:24 AM, Razique Mahroua razique.mahr...@gmail.com wrote:
Hello Alyssa, the status is the one reported when you suspend your instance
Nuage Co - Razique Mahroua
razique.mahr...@gmail.com
Le 16 avr. 2012 à 18:15, Alyssa Hurtgen a écrit :
Hi all,
I work at Rackspace and noticed a new Nova server status of "shutoff".
What does this status mean?How does the server get into this status?Should the user be able to perform any actions against the server?
Thanks,
Alyssa Hurtgen
___Mailing list: https://launchpad.net/~openstackPost to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstackMore 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] Installion guide for OpenStack Essex on Ubuntu 12.04
Hi Martin Now I have let the vnc working. install 3 package nova-consoleauth python-novnc novnc modify the nova.conf #novnc --novnc_enabled=true --novncproxy_base_url= http://10.42.0.6:6080/vnc_auto.html --vncserver_proxyclient_address=127.0.0.1 --vncserver_listen=127.0.0.1 restart service for a in libvirt-bin nova-network nova-compute nova-api nova-objectstore nova-scheduler novnc nova-volume nova-consoleauth; do service $a restart; done 2012/4/21 Shake Chen shake.c...@gmail.com Hi Martin Now the novnc bug seem have been fix. https://bugs.launchpad.net/ubuntu/+source/novnc/+bug/986258 On Tue, Apr 17, 2012 at 3:49 PM, Martin Gerhard Loschwitz martin.loschw...@hastexo.com wrote: Am 17.04.12 05:44, schrieb Shake Chen: Hi Martin Now the document seem have two problem. Hope you can fix and make it perfect. 1:glance Now the glance package have some change. for future upgrade reason, you have to manual create glance database table. https://bugs.launchpad.net/ubuntu/+source/glance/+bug/982787 you just need run # glance-manage version_control 0 # glance-manage db_sync then run glance index working as expect. 2:vnc problem. https://lists.launchpad.net/openstack/msg09707.html many friend have report working. Hi there and thanks for the feedback! I added the glance-manage part to the installation guide, but as for novnc, I will wait until fixed packages of it are available (I'm definetely not going to refer to packages hosted on dropbox in that howto, I was just so happy that we got rid of all manually exchange python files instructions in there :)) Best regards Martin -- Martin Gerhard Loschwitz Chief Brand Officer, Principal Consultant hastexo Professional Services CONFIDENTIALITY NOTICE: This e-mail and/or the accompanying documents are privileged and confidential under applicable law. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof. Should you have received this e-mail (or any copy thereof) in error, please let us know by telephone or e-mail without delay and delete the message from your system. Thank you. -- 陈沙克 手机：13661187180 msn：shake.c...@hotmail.com -- Shake Chen ___ 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] Sharing disk: OCFS2 or GFS2?
Hello everyone. My setup is simple. A volumen shared by iSCSI from our Netapp storage that I would like to use it for the instances running on our nova-compute nodes. Has anyone tried to use OCFS2 or GFS2 as FS via iSCSI mounted on the nova-computes as a sharing disk and running the instances into it? The plan b is to create a volumen by node and to format it as ext3 or ext4. Any recomendations? Thanks! Regards, Daniel ___ 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] New OpenStack Releases in Ubuntu 12.04LTS
Robbie Williamson wrote: For those of you who may have missed this announcement. Canonical has created the Ubuntu Cloud archive. Starting with the Folsum release, Folsom :) users will be able to elect to enable this archive, and install newer releases of OpenStack (and the dependencies) as they become available up through the next Ubuntu LTS release (presumably 14.04). There was a need for this: people kept asking the OpenStack PPA maintainers to provide a production-grade latest OpenStack on LTS repo. Great to see that the work has been picked up, as an officially-supported option, by the best team for the job ! -- 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
[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, if you can't make it, please name a substitute on [2]. We'll discuss the outcome of the design summit, and how to properly specify Folsom plans going forward. You can doublecheck what 21:00 UTC means for your timezone at [1]: [1] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20120424T21 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
[Openstack] wsgi code duplication
Hi Everyone, i've been looking through wsgi code, and i have found a lot of duplicated code between all the projects. Running a quick and dirty search, i get the following numbers (just focusing on glance horizon keystone nova openstack-common quantum swift projects): - There are 87 classes defined, but only 40 different. Rough numbers: (Number of times the class appears) 6 Request 5 Server 5 Router 5 Middleware 5 Debug 4 WritableLogger 3 XMLDictSerializer 3 XMLDeserializer 3 TextDeserializer 3 Resource 3 JSONDictSerializer 3 JSONDeserializer 3 DictSerializer 3 Application 3 ActionDispatcher 2 ResponseSerializer 2 RequestHeadersDeserializer 2 RequestDeserializer 2 Fault 2 Controller And some of them only defined and used once: (some are the same with different name like ResponseHeader*s*Serializer and ResponseHeaderSerializer) 1 WSGIContext 1 Serializer 1 ResponseObject 1 ResponseHeadersSerializer 1 ResponseHeaderSerializer 1 ResourceExceptionHandler 1 Resource 1 OverLimitFault 1 MetadataXMLDeserializer 1 Loader 1 JSONResponseSerializer 1 JSONRequestDeserializer 1 FilterFactory 1 ExtensionRouter 1 ControllerMetaclass 1 ComposingRouter 1 ComposableRouter 1 BasePasteFactory 1 BaseApplication 1 AppFactory Running a code analysis duplication tool like http://clonedigger.sourceforge.net/, the numbers and mostly the same: around 45% of the code is duplicated (A full output is available at http://debostack.org/paste/wsgi.html). I think there are a lot improvements we can get here using openstack-common as the base for all the wsgi code. (As Adam Young reported[1], services can be migrated to use HTTPD, but quantum[2] have some issues. Using the same code, the solution should be the same in all projects). I will open a blueprint for this and update the info as much as possible. [1] - http://adam.younglogic.com/2012/03/keystone-should-move-to-apache-httpd/ [2] - https://lists.launchpad.net/openstack/msg09966.html -- Ghe Rivero *OpenStack Distribution Engineer **www.stackops.com | * ghe.riv...@stackops.com diego.parri...@stackops.com ** | +34 625 63 45 23 | skype:ghe.rivero* * http://www.stackops.com/ * * ADVERTENCIA LEGAL Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley. * PRIVILEGED AND CONFIDENTIAL We hereby inform you, as addressee of this message, that e-mail and Internet do not guarantee the confidentiality, nor the completeness or proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does not assume any liability for those circumstances. Should you not agree to the use of e-mail or to communications via Internet, you are kindly requested to notify us immediately. This message is intended exclusively for the person to whom it is addressed and contains privileged and confidential information protected from disclosure by law. If you are not the addressee indicated in this message, you should immediately delete it and any attachments and notify the sender by reply e-mail. In such case, you are hereby notified that any dissemination, distribution, copying or use of this message or any attachments, for any purpose, is strictly prohibited by law. ___ 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] Monitoring / Billing Architecture proposed
On 04/23/2012 10:45 PM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com wrote: Doug, Do we mirror the table structure of nova, etc. and add created/modified columns? Or do we flatten into an instance event record with everything? I lean towards flattening the data as it is recorded and making a second pass during the bill calculation. You need to record instance modifications separately from the creation, especially if the modification changes the billing rate. So you might have records for: created instance, with UUID, name, size, timestamp, ownership information, etc. resized instance, with UUID, name, new size, timestamp, ownership information, etc. deleted instance, with UUID, name, size, timestamp, ownership information, etc. Maybe some of those values don't need to be reported in some cases, but if you record a complete picture of the state of the instance then the code that aggregates the event records to produce billing information can use it to make decisions about how to record the charges. There is also the case where an instance is still no longer running but nova thinks it is (or the reverse), so some sort of auditing sweep needs to be included (I think that's what Dough called the farmer but I don't have my notes in front of me). When I wrote [1], one of the things that I never assumed was how agents would collect their information. I imagined that the system should allow for multiple implementation of agents that would collect the same counters, assuming that 2 implementations for the same counter should never be running at once. That said, I am not sure an event based collection of what nova is notifying would satisfy the requirements I have heard from many cloud providers: - how do we ensure that event are not forged or lost in the current nova system? - how can I be sure that an instance has not simply crashed and never started? - how can I collect information which is not captured by nova events? Hence the proposal to use a dedicated event queue for billing, allowing for agents to collect and eventually validate data from different sources, including, but not necessarily limiting, collection from the nova events. Moreover, as soon as you generalize the problem to other components than just Nova (swift, glance, quantum, daas, ...) just using the nova event queue is not an option anymore. [1] http://wiki.openstack.org/EfficientMetering Nick signature.asc Description: OpenPGP digital signature ___ 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] Monitoring / Billing Architecture proposed
I think we have support for this currently in some fashion, Dragon? -S On 04/24/2012 12:55 AM, Loic Dachary wrote: Metering needs to account for the volume of data sent to external network destinations ( i.e. n4 in http://wiki.openstack.org/EfficientMetering ) or the disk I/O etc. This kind of resource is billable. The information described at http://wiki.openstack.org/SystemUsageData will be used by metering but other data sources need to be harvested as well. ___ 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] Canonical AWSOME
23. apr. 2012 17.15 skrev Justin Santa Barbara jus...@fathomdb.com: What's the advantage of replacing the native EC2 compatibility layer with AWSOME from a user / operator point of view? Although I wasn't able to attend the design summit session, right now we have two native APIs, which means we have two paths into the system. Yes. This is good. It keeps the layers of separation honest. Multiple consumers of internal API's helps in making it more obvious at which layer functionality belongs. Just like having multiple hypervisor drivers (at least supposedly) makes it more obvious what sort of stuff belongs in the drivers and what sort of stuff belongs in the compute manager. That is poor software engineering, because we must code and debug everything twice. I beg to differ. If we need to fix things twice, it's because we've violated the layers of separation somewhere. For the record, I'm fully prepared to believe that we've done so. I also fully believe that the fact that we haven't done so *more* is because we have two API's to consider. Eric Day went through all the calls from the frontends into the various backend managers a long time ago, ensuring this separation was clear. I'm convinced that the result was a massive improvement. Some developers will naturally favor one API over the other, and so disparities happen. Today, both APIs are effectively using an undocumented private API, which is problematic. Yes. This is a problem. However, as I understand it, there was a session at the summit about versioning the internal API's. I'm not sure how we can usefully version the API's without also documenting them, so that problem should be adressed in the relatively near future. We also can't really extend the EC2 API, so it is holding us back as we extend OpenStack's capabilities past those of the legacy clouds. If EC2 API is limiting what we can do, that's not going to change just because you move the EC2 API implementation into a proxy in front of the OpenStack API. The only difference is that it's suddenly the AWSOME development team's problem. With one native API, we can focus all our energies on making sure that API works. Then, knowing that the native API works, we can build other APIs on top through simple translation layers, and they will work also. Other APIs can be built on top in the same way (e.g. OCCI) Sorry, I'm having trouble here.. Are you suggesting that having two sibling frontend API's talking to a shared backend API is poor software engineering, but layering similar purposed API's on top of each other like this is good software engineering? -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ 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] Using Nova APIs from Javascript: possible?
Due to the redirect nature of the auth system we may need JSONP support for this to work. ___ 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] EBS-backed AMIs on nova: how?
Hi all, The feature comparison matrix at http://wiki.openstack.org/Nova/APIFeatureComparison has a row labelled AMI's backed by EBS, which suggests to me that there is a way to have nova-compute start a VM with its root store managed by nova-volume. But I haven't been able to find anything that shows how to achieve this. Can anyone provide a pointer? Thanks, David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Question #194111]: Does quantum support multi-nic setup ?
Dan, I've updated the question (few more queries) Also, you didn't say exactly how you were running devstack. Can you send your config? I've described my two-machine setup in the original question itself. I didn't know how to add an attachment to the question, so here is my nova.conf for your reference (See attached) It is fairly standard one, generated by stack.sh -Mandar __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding nova.conf Description: nova.conf ___ 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] wsgi code duplication
Hi Ghe, On Tue, 2012-04-24 at 12:15 +0200, Ghe Rivero wrote: Hi Everyone, i've been looking through wsgi code, and i have found a lot of duplicated code between all the projects. Thanks for looking into this. It sounds quite daunting. I wonder could we do this iteratively by extract the code which is most common into openstack-common, move the projects over to that and then start again on the next layer? 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] Canonical AWSOME
On Tue, 2012-04-24 at 13:26 +0200, Soren Hansen wrote: 23. apr. 2012 17.15 skrev Justin Santa Barbara jus...@fathomdb.com: With one native API, we can focus all our energies on making sure that API works. Then, knowing that the native API works, we can build other APIs on top through simple translation layers, and they will work also. Other APIs can be built on top in the same way (e.g. OCCI) Sorry, I'm having trouble here.. Are you suggesting that having two sibling frontend API's talking to a shared backend API is poor software engineering, but layering similar purposed API's on top of each other like this is good software engineering? Yeah, I'm with you here. I think the frustration about the native EC2 support boils down to: a) we haven't (yet) got the clean separation of layers that we'd like b) not enough people are working on EC2 support c) there's a concern that OpenStack providers may not enable it And my reaction to those is: a) we can fix that b) starting a new project doesn't help c) adding an EC2 frontend to deltacloud is a much more sane way of addressing this 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] Monitoring / Billing Architecture proposed
Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance The event has the somewhat generic name of 'compute.instance.exists' and is emitted on an periodic basis, currently by a cronjob. Currently, we only populate bandwidth data from XenServer, but if the hook is implemented for the kvm, etc drivers, it will be picked up automatically for them as well. Note that we could report other metrics similarly. On Apr 24, 2012, at 6:20 AM, Sandy Walsh wrote: I think we have support for this currently in some fashion, Dragon? -S On 04/24/2012 12:55 AM, Loic Dachary wrote: Metering needs to account for the volume of data sent to external network destinations ( i.e. n4 in http://wiki.openstack.org/EfficientMetering ) or the disk I/O etc. This kind of resource is billable. The information described at http://wiki.openstack.org/SystemUsageData will be used by metering but other data sources need to be harvested as well. -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ 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] Monitoring / Billing Architecture proposed
On 04/24/2012 03:06 PM, Monsyne Dragon wrote: Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance The event has the somewhat generic name of 'compute.instance.exists' and is emitted on an periodic basis, currently by a cronjob. Currently, we only populate bandwidth data from XenServer, but if the hook is implemented for the kvm, etc drivers, it will be picked up automatically for them as well. Note that we could report other metrics similarly. Hi, Thanks for clarifying this. So you're suggesting that the metering agent should collect this data from the nova queue instead of extracting it from the system (interface, disk stats etc.) ? And for other openstack components ( as Nick Barcet suggests below ) the metering agent will have to find another way. Or do you have something else in mind ? Cheers On 04/24/2012 12:17 PM, Nick Barcet wrote: On 04/23/2012 10:45 PM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com wrote: Doug, Do we mirror the table structure of nova, etc. and add created/modified columns? Or do we flatten into an instance event record with everything? I lean towards flattening the data as it is recorded and making a second pass during the bill calculation. You need to record instance modifications separately from the creation, especially if the modification changes the billing rate. So you might have records for: created instance, with UUID, name, size, timestamp, ownership information, etc. resized instance, with UUID, name, new size, timestamp, ownership information, etc. deleted instance, with UUID, name, size, timestamp, ownership information, etc. Maybe some of those values don't need to be reported in some cases, but if you record a complete picture of the state of the instance then the code that aggregates the event records to produce billing information can use it to make decisions about how to record the charges. There is also the case where an instance is still no longer running but nova thinks it is (or the reverse), so some sort of auditing sweep needs to be included (I think that's what Dough called the farmer but I don't have my notes in front of me). When I wrote [1], one of the things that I never assumed was how agents would collect their information. I imagined that the system should allow for multiple implementation of agents that would collect the same counters, assuming that 2 implementations for the same counter should never be running at once. That said, I am not sure an event based collection of what nova is notifying would satisfy the requirements I have heard from many cloud providers: - how do we ensure that event are not forged or lost in the current nova system? - how can I be sure that an instance has not simply crashed and never started? - how can I collect information which is not captured by nova events? Hence the proposal to use a dedicated event queue for billing, allowing for agents to collect and eventually validate data from different sources, including, but not necessarily limiting, collection from the nova events. Moreover, as soon as you generalize the problem to other components than just Nova (swift, glance, quantum, daas, ...) just using the nova event queue is not an option anymore. [1] http://wiki.openstack.org/EfficientMetering Nick On Apr 24, 2012, at 6:20 AM, Sandy Walsh wrote: I think we have support for this currently in some fashion, Dragon? -S On 04/24/2012 12:55 AM, Loic Dachary wrote: Metering needs to account for the volume of data sent to external network destinations ( i.e. n4 in http://wiki.openstack.org/EfficientMetering ) or the disk I/O etc. This kind of resource is billable. The information described at http://wiki.openstack.org/SystemUsageData will be used by metering but other data sources need to be harvested as well. -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- 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] Using Nova APIs from Javascript: possible?
JSONP is great, but won't work with POST requests. I don't quite understand what Due to the redirect nature of the auth system means, though. If I use a custom Webkit browser allow cross domain XMLHttpRequests it works fine - I do a POST to /v2.0/tokens, get the token and then use that. What am I missing? Nick On Tue, Apr 24, 2012 at 8:57 PM, Sandy Walsh sandy.wa...@rackspace.comwrote: Due to the redirect nature of the auth system we may need JSONP support for this to work. ___ 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] Using Nova APIs from Javascript: possible?
On 04/24/2012 10:19 AM, Nick Lothian wrote: JSONP is great, but won't work with POST requests. I don't quite understand what Due to the redirect nature of the auth system means, though. Sorry, I am working on a few things that are related. OpenID and various other systems have issues along these lines that are due to the fact that they are done with redirects. UI'll try to be clearer in the future. That actually works fine because the token is not in the header when it comes from Keystone. However, if you were to post toa web app that then needed to make your browser post to a remote system (which is where the same origin policy comes in to play) you need to set that Auth token into a custom header, and Javascript is forbidden to do that. Yes, the Javascript can say post to glance or some other openstack API server, but it can't set the X auth header with the token from Keystone in order to make the call authenticated. Nick On Tue, Apr 24, 2012 at 8:57 PM, Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com wrote: Due to the redirect nature of the auth system we may need JSONP support for this to work. ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack 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] Regular XenAPI Meeting
Hi John +1 would be interested for monthly meeting. Time is ok. Alan From: openstack-bounces+alan.kavanagh=ericsson@lists.launchpad.net [mailto:openstack-bounces+alan.kavanagh=ericsson@lists.launchpad.net] On Behalf Of John Garbutt Sent: April-23-12 1:21 PM To: openstack@lists.launchpad.net Subject: [Openstack] Regular XenAPI Meeting Hi, Are people keen for a XenAPI virt layer meetup on IRC every month? I have added a suggested time to the wiki, as a starting point: Monthly, second Wednesday at 17:00 UTC Does that seem a reasonable time for those that want to attend? It can be more frequent if we find that useful. I don't want to detract from the other meetings, but it would be good to keep all of us working on the XenAPI layer in regular contact. Cheers, 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] Monitoring / Billing Architecture proposed
On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote: On 04/24/2012 03:06 PM, Monsyne Dragon wrote: Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance The event has the somewhat generic name of 'compute.instance.exists' and is emitted on an periodic basis, currently by a cronjob. Currently, we only populate bandwidth data from XenServer, but if the hook is implemented for the kvm, etc drivers, it will be picked up automatically for them as well. Note that we could report other metrics similarly. Hi, Thanks for clarifying this. So you're suggesting that the metering agent should collect this data from the nova queue instead of extracting it from the system (interface, disk stats etc.) ? And for other openstack components ( as Nick Barcet suggests below ) the metering agent will have to find another way. Or do you have something else in mind ? If it's something we have access to, we should emit it in those usage events. As far as the other components, glance is already using the same notification system. (there was a thread awhile back about putting it into openstack.common) It would be nice to have all of the components using it. Cheers On 04/24/2012 12:17 PM, Nick Barcet wrote: On 04/23/2012 10:45 PM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com wrote: Doug, Do we mirror the table structure of nova, etc. and add created/modified columns? Or do we flatten into an instance event record with everything? I lean towards flattening the data as it is recorded and making a second pass during the bill calculation. You need to record instance modifications separately from the creation, especially if the modification changes the billing rate. So you might have records for: created instance, with UUID, name, size, timestamp, ownership information, etc. resized instance, with UUID, name, new size, timestamp, ownership information, etc. deleted instance, with UUID, name, size, timestamp, ownership information, etc. Maybe some of those values don't need to be reported in some cases, but if you record a complete picture of the state of the instance then the code that aggregates the event records to produce billing information can use it to make decisions about how to record the charges. There is also the case where an instance is still no longer running but nova thinks it is (or the reverse), so some sort of auditing sweep needs to be included (I think that's what Dough called the farmer but I don't have my notes in front of me). When I wrote [1], one of the things that I never assumed was how agents would collect their information. I imagined that the system should allow for multiple implementation of agents that would collect the same counters, assuming that 2 implementations for the same counter should never be running at once. That said, I am not sure an event based collection of what nova is notifying would satisfy the requirements I have heard from many cloud providers: - how do we ensure that event are not forged or lost in the current nova system? - how can I be sure that an instance has not simply crashed and never started? - how can I collect information which is not captured by nova events? Hence the proposal to use a dedicated event queue for billing, allowing for agents to collect and eventually validate data from different sources, including, but not necessarily limiting, collection from the nova events. Moreover, as soon as you generalize the problem to other components than just Nova (swift, glance, quantum, daas, ...) just using the nova event queue is not an option anymore. [1] http://wiki.openstack.org/EfficientMetering Nick On Apr 24, 2012, at 6:20 AM, Sandy Walsh wrote: I think we have support for this currently in some fashion, Dragon? -S On 04/24/2012 12:55 AM, Loic Dachary wrote: Metering needs to account for the volume of data sent to external network destinations ( i.e. n4 in http://wiki.openstack.org/EfficientMetering ) or the disk I/O etc. This kind of resource is billable. The information described at http://wiki.openstack.org/SystemUsageData will be used by metering but other data sources need to be harvested as well. -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Loïc Dachary Chief Research Officer // eNovance labs http://labs.enovance.comhttp://labs.enovance.com/ // ✉ l...@enovance.commailto:l...@enovance.com ☎ +33 1 49 70 99 82
Re: [Openstack] Canonical AWSOME
If EC2 API is limiting what we can do, that's not going to change just because you move the EC2 API implementation into a proxy in front of the OpenStack API. The only difference is that it's suddenly the AWSOME development team's problem. I think it's actually the EC2 API caller's problem. It's easy to map a subset to a superset, but you can't cover the superset with the subset. Suppose Quantum defines e.g. Layer 2 security groups, which I think has no parallel in EC2. If you want to use L2 security groups, you'd have to use the OpenStack API. A nice AWSOME developer might treat it as their problem, but it's not really. With one native API, we can focus all our energies on making sure that API works. Then, knowing that the native API works, we can build other APIs on top through simple translation layers, and they will work also. Other APIs can be built on top in the same way (e.g. OCCI) Sorry, I'm having trouble here.. Are you suggesting that having two sibling frontend API's talking to a shared backend API is poor software engineering, but layering similar purposed API's on top of each other like this is good software engineering? Obviously not when you put it like that :-) The difference that I see is whether the 'service' layer is documented and kept stable (i.e. subject to API evolution rules). Right now, we do that work for the OpenStack API only. I think it's great if someone is going to document and stabilize our internal APIs. However, unless you're willing to do it personally, I don't think anyone should assume it'll be done. So my viewpoint is that, while it would be great to have interface contracts on all our internal interfaces, I'll believe it when I see it. Until then, we have one stable interface, and so using that stable interface as the service layer seems like a sensible approach. I can see us using ProtocolBuffers or JSON schema for messages that go over the message bus, maybe even in Folsom. I can't see us locking down the other code interfaces before we give up on this Python thing and port to Java, i.e. it's not going to happen. Actually, I think JSON schema for our message-bus messages might be a really good idea (tm). Violations could just be warnings until we get things locked down... maybe I should propose a blueprint? (Although I have enough of a blueprint backlog as it is...) Justin ___ 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] Using Nova APIs from Javascript: possible?
On 04/24/2012 11:19 AM, Nick Lothian wrote: JSONP is great, but won't work with POST requests. Hmm, good point. I don't quite understand what Due to the redirect nature of the auth system means, though. If I use a custom Webkit browser allow cross domain XMLHttpRequests it works fine - I do a POST to /v2.0/tokens, get the token and then use that. What am I missing? The Auth system will give you a token and then a new management url where the actual commands are issued (the real Nova API endpoint). These are often two different systems (domains), so cross-site requests are mandatory. -S Nick On Tue, Apr 24, 2012 at 8:57 PM, Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com wrote: Due to the redirect nature of the auth system we may need JSONP support for this to work. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto: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] wsgi code duplication
On Apr 24, 2012, at 9:28 AM, Ghe Rivero wrote: On Tue, Apr 24, 2012 at 2:40 PM, Mark McLoughlin mar...@redhat.com wrote: Hi Ghe, On Tue, 2012-04-24 at 12:15 +0200, Ghe Rivero wrote: Hi Everyone, i've been looking through wsgi code, and i have found a lot of duplicated code between all the projects. Thanks for looking into this. It sounds quite daunting. I wonder could we do this iteratively by extract the code which is most common into openstack-common, move the projects over to that and then start again on the next layer? Cheers, Mark. I have plans to try to move as much as possible into openstack-common. I will start with nova as a test bed and see what we get from there. My future plans include db code and tests (in the case of quantum, plugins test also have a lot of duplicated code). I register a bp for the wsgi issue: https://blueprints.launchpad.net/openstack-common/+spec/wsgi-common Ghe Rivero Is there a code metrics site that continually reports on metrics like duplication? Adding Ghe's report to a metric site would be the first step. That has always been a starting point as it gives code reviewers quick evaluation criteria to stop duplication before it ends up in trunk. Going at it directly fixes it looking backward but the duplication ends up back int the code eventually. The reports help fix the issue going forward.___ 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] Sharing disk: OCFS2 or GFS2?
As far as I know, the current volume service doesn't support connecting the same volume to multiple instances at the same time, so neither of these can work directly through nova apis. -nld On Tue, Apr 24, 2012 at 4:44 AM, Daniel Martinez danie...@gmail.com wrote: Hello everyone. My setup is simple. A volumen shared by iSCSI from our Netapp storage that I would like to use it for the instances running on our nova-compute nodes. Has anyone tried to use OCFS2 or GFS2 as FS via iSCSI mounted on the nova-computes as a sharing disk and running the instances into it? The plan b is to create a volumen by node and to format it as ext3 or ext4. Any recomendations? Thanks! Regards, Daniel ___ 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] Regular XenAPI Meeting
I'd be interest to join too. Shall we use a wiki page to collate names and affiliations of people interested (there's a Launchpad group set up by the way - https://launchpad.net/~openstack-xenapi), as well as meeting details? Thanks, Armando On Tue, Apr 24, 2012 at 3:32 PM, Alan Kavanagh alan.kavan...@ericsson.com wrote: Hi John +1 would be interested for monthly meeting. Time is ok. Alan From: openstack-bounces+alan.kavanagh=ericsson@lists.launchpad.net [mailto:openstack-bounces+alan.kavanagh=ericsson@lists.launchpad.net] On Behalf Of John Garbutt Sent: April-23-12 1:21 PM To: openstack@lists.launchpad.net Subject: [Openstack] Regular XenAPI Meeting Hi, Are people keen for a XenAPI virt layer meetup on IRC every month? I have added a suggested time to the wiki, as a starting point: Monthly, second Wednesday at 17:00 UTC Does that seem a reasonable time for those that want to attend? It can be more frequent if we find that useful. I don’t want to detract from the other meetings, but it would be good to keep all of us working on the XenAPI layer in regular contact. Cheers, 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 ___ 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] Canonical AWSOME
Actually, I think JSON schema for our message-bus messages might be a really good idea (tm). Violations could just be warnings until we get things locked down... maybe I should propose a blueprint? (Although I have enough of a blueprint backlog as it is...) ___ 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] Canonical AWSOME
Actually, I think JSON schema for our message-bus messages might be a really good idea (tm). Violations could just be warnings until we get things locked down... maybe I should propose a blueprint? (Although I have enough of a blueprint backlog as it is...) This was discussed at the summit in (I believe) the API versioning talk. There is a strong bias toward JSON inside RPC messages. However, this is actually transparent to Nova as the RPC implementations do the decoding and encoding. It is also hard to test and trigger such warnings as, as far as Nova knows, all the interfaces pass python data types, not JSON. Some RPC mechanisms could transparently serialize. As long as there is an abstraction layer, it should be oblivious to the serialization and we should not care too strongly. There was a patch a few weeks ago that has enforced using a common RPC exception serializer using JSON, which I'm not sure is, or is not, a good thing. I haven't yet updated the ZeroMQ driver to use this, but am in the process of making these changes as I update for Folsom. All that said, I do intend that the ZeroMQ driver will use JSON when it lands in Folsom. (it currently Pickles, but only because there was a bug in Essex at one point, breaking JSON serialization) -- Eric Windisch ___ 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] Heat API v2 released!
Hi, Heat is a AWS CloudForm API implementation for OpenStack. The purpose of the software is to orchestrate resources (including virtual machines, networks, storage) into a running cloud application. The software converts an AWS template into native OpenStack API calls and provides a REST API to access the template (called a stack). Our development community has been busy over the last 3 weeks working on our second release. New in this release is: + composite instance support + floating IP support + security group support + volume support + improved keystone authentication + sqlalchemy database support + amqp engine support + describe API implementation + events_list API implementation + improved delete API implementation + better JEOS security + cfn tools implementation + Improved template library examples We have also started working on a roadmap. If your interested in seeing our roadmap work, check out: https://github.com/heat-api/heat/wiki To get started with the code check out: https://github.com/heat-api/heat/wiki/Getting-Started-with-Heat-v2-M1 And download the tag from here: https://github.com/heat-api/heat/tarball/v2-M1.release If you want to contribute to the software or are having trouble getting started, join us on #heat on freenode irc or our mailing list at http://ists.heat-api.org/mailman/listinfo Regards -steve ___ 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] Regular XenAPI Meeting
Good plan, I have started a wiki page to capture that stuff: http://wiki.openstack.org/XenAPIMeetings Cheers, John -Original Message- From: Armando Migliaccio [mailto:amigliac...@internap.com] Sent: 24 April 2012 16:23 To: Alan Kavanagh Cc: John Garbutt; openstack@lists.launchpad.net Subject: Re: [Openstack] Regular XenAPI Meeting I'd be interest to join too. Shall we use a wiki page to collate names and affiliations of people interested (there's a Launchpad group set up by the way - https://launchpad.net/~openstack-xenapi), as well as meeting details? Thanks, Armando On Tue, Apr 24, 2012 at 3:32 PM, Alan Kavanagh alan.kavan...@ericsson.com wrote: Hi John +1 would be interested for monthly meeting. Time is ok. Alan From: openstack- bounces+alan.kavanagh=ericsson@lists.launchpad.net [mailto:openstack- bounces+alan.kavanagh=ericsson.com@lists.launchpad.n et] On Behalf Of John Garbutt Sent: April-23-12 1:21 PM To: openstack@lists.launchpad.net Subject: [Openstack] Regular XenAPI Meeting Hi, Are people keen for a XenAPI virt layer meetup on IRC every month? I have added a suggested time to the wiki, as a starting point: Monthly, second Wednesday at 17:00 UTC Does that seem a reasonable time for those that want to attend? It can be more frequent if we find that useful. I don't want to detract from the other meetings, but it would be good to keep all of us working on the XenAPI layer in regular contact. Cheers, 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 ___ 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] wsgi code duplication
Hi Ghe, I suppose it will be very useful. We are planning to create a new project for nova-volumes (cider?) and I’m sure it will have same duplicate classes. Sooner we will have a common openstack layer is better. Regards, -Vladimir *From:* openstack-bounces+vladimir=zadarastorage@lists.launchpad.net[mailto: openstack-bounces+vladimir=zadarastorage@lists.launchpad.net] *On Behalf Of *Ghe Rivero *Sent:* Tuesday, April 24, 2012 7:28 AM *To:* Mark McLoughlin *Cc:* openstack *Subject:* Re: [Openstack] wsgi code duplication On Tue, Apr 24, 2012 at 2:40 PM, Mark McLoughlin mar...@redhat.com wrote: Hi Ghe, On Tue, 2012-04-24 at 12:15 +0200, Ghe Rivero wrote: Hi Everyone, i've been looking through wsgi code, and i have found a lot of duplicated code between all the projects. Thanks for looking into this. It sounds quite daunting. I wonder could we do this iteratively by extract the code which is most common into openstack-common, move the projects over to that and then start again on the next layer? Cheers, Mark. I have plans to try to move as much as possible into openstack-common. I will start with nova as a test bed and see what we get from there. My future plans include db code and tests (in the case of quantum, plugins test also have a lot of duplicated code). I register a bp for the wsgi issue: https://blueprints.launchpad.net/openstack-common/+spec/wsgi-common Ghe Rivero -- Ghe Rivero *OpenStack Distribution Engineer www.stackops.com | * ghe.riv...@stackops.com diego.parri...@stackops.com | +34 625 63 45 23 | skype:ghe.rivero* * http://www.stackops.com/ ADVERTENCIA LEGAL Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley. * PRIVILEGED AND CONFIDENTIAL We hereby inform you, as addressee of this message, that e-mail and Internet do not guarantee the confidentiality, nor the completeness or proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does not assume any liability for those circumstances. Should you not agree to the use of e-mail or to communications via Internet, you are kindly requested to notify us immediately. This message is intended exclusively for the person to whom it is addressed and contains privileged and confidential information protected from disclosure by law. If you are not the addressee indicated in this message, you should immediately delete it and any attachments and notify the sender by reply e-mail. In such case, you are hereby notified that any dissemination, distribution, copying or use of this message or any attachments, for any purpose, is strictly prohibited by law. ___ 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] Monitoring / Billing Architecture proposed
On 04/24/2012 04:45 PM, Monsyne Dragon wrote: On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote: On 04/24/2012 03:06 PM, Monsyne Dragon wrote: Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance The event has the somewhat generic name of 'compute.instance.exists' and is emitted on an periodic basis, currently by a cronjob. Currently, we only populate bandwidth data from XenServer, but if the hook is implemented for the kvm, etc drivers, it will be picked up automatically for them as well. Note that we could report other metrics similarly. Hi, Thanks for clarifying this. So you're suggesting that the metering agent should collect this data from the nova queue instead of extracting it from the system (interface, disk stats etc.) ? And for other openstack components ( as Nick Barcet suggests below ) the metering agent will have to find another way. Or do you have something else in mind ? If it's something we have access to, we should emit it in those usage events. As far as the other components, glance is already using the same notification system. (there was a thread awhile back about putting it into openstack.common) It would be nice to have all of the components using it. Hi, I don't see a section in http://wiki.openstack.org/SystemUsageData about making sure all messages related to a billable event are accounted for. I mean, for instance, what if the event that says an instance is deleted is lost ? How is the billing software supposed to cope with that ? If it checks the status of all VM on a regular basis to deal with this, how can it figure out when the missed event occured ? It would be worth adding a short section about this in http://wiki.openstack.org/SystemUsageData . Or I can do it if you give me a hint. Cheers Cheers On 04/24/2012 12:17 PM, Nick Barcet wrote: On 04/23/2012 10:45 PM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com wrote: Doug, Do we mirror the table structure of nova, etc. and add created/modified columns? Or do we flatten into an instance event record with everything? I lean towards flattening the data as it is recorded and making a second pass during the bill calculation. You need to record instance modifications separately from the creation, especially if the modification changes the billing rate. So you might have records for: created instance, with UUID, name, size, timestamp, ownership information, etc. resized instance, with UUID, name, new size, timestamp, ownership information, etc. deleted instance, with UUID, name, size, timestamp, ownership information, etc. Maybe some of those values don't need to be reported in some cases, but if you record a complete picture of the state of the instance then the code that aggregates the event records to produce billing information can use it to make decisions about how to record the charges. There is also the case where an instance is still no longer running but nova thinks it is (or the reverse), so some sort of auditing sweep needs to be included (I think that's what Dough called the farmer but I don't have my notes in front of me). When I wrote [1], one of the things that I never assumed was how agents would collect their information. I imagined that the system should allow for multiple implementation of agents that would collect the same counters, assuming that 2 implementations for the same counter should never be running at once. That said, I am not sure an event based collection of what nova is notifying would satisfy the requirements I have heard from many cloud providers: - how do we ensure that event are not forged or lost in the current nova system? - how can I be sure that an instance has not simply crashed and never started? - how can I collect information which is not captured by nova events? Hence the proposal to use a dedicated event queue for billing, allowing for agents to collect and eventually validate data from different sources, including, but not necessarily limiting, collection from the nova events. Moreover, as soon as you generalize the problem to other components than just Nova (swift, glance, quantum, daas, ...) just using the nova event queue is not an option anymore. [1] http://wiki.openstack.org/EfficientMetering Nick On Apr 24, 2012, at 6:20 AM, Sandy Walsh wrote: I think we have support for this currently in some fashion, Dragon? -S On 04/24/2012 12:55 AM, Loic Dachary wrote: Metering needs to account for the volume of data sent to external network destinations ( i.e. n4 in http://wiki.openstack.org/EfficientMetering ) or the disk I/O etc. This kind of resource is billable. The information described at http://wiki.openstack.org/SystemUsageData will be used by metering but other
Re: [Openstack] Using Nova APIs from Javascript: possible?
Nick,
I know you said 'serverless clients' but you have to be serving the js from
somewhere right?
If you are using nginx it can be as simple as:
location /nova/ {
proxy_pass: http://nova-api.trystack.org;
}
then you can POST to yourserver/nova/v.02/. from the browser
etc.
(it's just about as simple on apache but you'd have to look it up)
But then i guess this won't work for you if you are writing
some distributable component/plugin/library.
(sorry if you've already dismissed this option but i thought it worth a
shot since it has worked flawlessly for me in the past)
On Tue, Apr 24, 2012 at 9:49 AM, Sandy Walsh sandy.wa...@rackspace.comwrote:
On 04/24/2012 11:19 AM, Nick Lothian wrote:
JSONP is great, but won't work with POST requests.
Hmm, good point.
I don't quite understand what Due to the redirect nature of the auth
system means, though.
If I use a custom Webkit browser allow cross domain XMLHttpRequests it
works fine - I do a POST to /v2.0/tokens, get the token and then use
that. What am I missing?
The Auth system will give you a token and then a new management url
where the actual commands are issued (the real Nova API endpoint). These
are often two different systems (domains), so cross-site requests are
mandatory.
-S
Nick
On Tue, Apr 24, 2012 at 8:57 PM, Sandy Walsh sandy.wa...@rackspace.com
mailto:sandy.wa...@rackspace.com wrote:
Due to the redirect nature of the auth system we may need JSONP
support
for this to work.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
mailto: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
--
Cheers,
Joel
___
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] wsgi code duplication
On Apr 24, 2012, at 10:55 AM, Thompson Lee wrote: On Apr 24, 2012, at 9:28 AM, Ghe Rivero wrote: I have plans to try to move as much as possible into openstack-common. I will start with nova as a test bed and see what we get from there. My future plans include db code and tests (in the case of quantum, plugins test also have a lot of duplicated code). I register a bp for the wsgi issue: https://blueprints.launchpad.net/openstack-common/+spec/wsgi-common Ghe Rivero Is there a code metrics site that continually reports on metrics like duplication? Adding Ghe's report to a metric site would be the first step. That has always been a starting point as it gives code reviewers quick evaluation criteria to stop duplication before it ends up in trunk. Going at it directly fixes it looking backward but the duplication ends up back int the code eventually. The reports help fix the issue going forward. I don't know of any duplication metrics being calculated, but Jenkins continually reports test coverage metrics: https://jenkins.openstack.org/portlet/dashboard_portlet_30/ Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com smime.p7s Description: S/MIME cryptographic signature ___ 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] Canonical AWSOME
On 04/24/2012 11:39 AM, Eric Windisch wrote: Actually, I think JSON schema for our message-bus messages might be a really good idea (tm). Violations could just be warnings until we get things locked down... maybe I should propose a blueprint? (Although I have enough of a blueprint backlog as it is...) This was discussed at the summit in (I believe) the API versioning talk. There is a strong bias toward JSON inside RPC messages. However, this is actually transparent to Nova as the RPC implementations do the decoding and encoding. It is also hard to test and trigger such warnings as, as far as Nova knows, all the interfaces pass python data types, not JSON. Some RPC mechanisms could transparently serialize. As long as there is an abstraction layer, it should be oblivious to the serialization and we should not care too strongly. There was a patch a few weeks ago that has enforced using a common RPC exception serializer using JSON, which I'm not sure is, or is not, a good thing. I haven't yet updated the ZeroMQ driver to use this, but am in the process of making these changes as I update for Folsom. The change was just to the fake rpc backend to help catch more errors in unit tests where non-primitive types are getting passed into rpc. All that said, I do intend that the ZeroMQ driver will use JSON when it lands in Folsom. (it currently Pickles, but only because there was a bug in Essex at one point, breaking JSON serialization) There may still be some datetime related problems lurking in there, but we need to fix them as they come up. If it causes a problem for you, it's likely a problem for the other drivers, as well. -- 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] Canonical AWSOME
Thanks for the pointer. I found the etherpad: http://etherpad.openstack.org/VersioningNovaRPCAPIs Is there a blueprint that came / is coming out of that? I think the data representation is orthogonal e.g. in theory, we could even use XML schemas: PyDict -- XML -- XML Schema Validation -- Warn / Throw \- JSON - Rabbit As it sounds like we are using JSON, it makes most sense to use JSON schemas. But doing so doesn't preclude us from using e.g. a binary format in future. I'd imagine that the RPC mechanism would simply select the relevant schema based on a few attributes of the dict (likely the queue method name). So this would remain transparent to the caller. A basic RPC mechanisms might validate and warn against a JSON schema, another might use the schema to build a compact binary representation. But I think we can achieve this without changing nova. On Tue, Apr 24, 2012 at 8:39 AM, Eric Windisch e...@cloudscaling.comwrote: Actually, I think JSON schema for our message-bus messages might be a really good idea (tm). Violations could just be warnings until we get things locked down... maybe I should propose a blueprint? (Although I have enough of a blueprint backlog as it is...) This was discussed at the summit in (I believe) the API versioning talk. There is a strong bias toward JSON inside RPC messages. However, this is actually transparent to Nova as the RPC implementations do the decoding and encoding. It is also hard to test and trigger such warnings as, as far as Nova knows, all the interfaces pass python data types, not JSON. Some RPC mechanisms could transparently serialize. As long as there is an abstraction layer, it should be oblivious to the serialization and we should not care too strongly. There was a patch a few weeks ago that has enforced using a common RPC exception serializer using JSON, which I'm not sure is, or is not, a good thing. I haven't yet updated the ZeroMQ driver to use this, but am in the process of making these changes as I update for Folsom. All that said, I do intend that the ZeroMQ driver will use JSON when it lands in Folsom. (it currently Pickles, but only because there was a bug in Essex at one point, breaking JSON serialization) -- Eric Windisch ___ 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] Regular XenAPI Meeting
+1 and good on the time here On Apr 23, 2012, at 10:21 AM, John Garbutt john.garb...@citrix.com wrote: Hi, Are people keen for a XenAPI virt layer meetup on IRC every month? I have added a suggested time to the wiki, as a starting point: Monthly, second Wednesday at 17:00 UTC Does that seem a reasonable time for those that want to attend? It can be more frequent if we find that useful. I don’t want to detract from the other meetings, but it would be good to keep all of us working on the XenAPI layer in regular contact. Cheers, 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 ___ 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] Using Nova APIs from Javascript: possible?
Jsonp sucks (get only) but might be the best choice. That's generally how AWS supports these use cases, fwiw. On Apr 24, 2012, at 7:49 AM, Sandy Walsh sandy.wa...@rackspace.com wrote: On 04/24/2012 11:19 AM, Nick Lothian wrote: JSONP is great, but won't work with POST requests. Hmm, good point. I don't quite understand what Due to the redirect nature of the auth system means, though. If I use a custom Webkit browser allow cross domain XMLHttpRequests it works fine - I do a POST to /v2.0/tokens, get the token and then use that. What am I missing? The Auth system will give you a token and then a new management url where the actual commands are issued (the real Nova API endpoint). These are often two different systems (domains), so cross-site requests are mandatory. -S Nick On Tue, Apr 24, 2012 at 8:57 PM, Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com wrote: Due to the redirect nature of the auth system we may need JSONP support for this to work. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto: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 ___ 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] Canonical AWSOME
I'm more in favor of just having a schema, I don't care if that compiles to protocol buffers, json, NEWAWESOMEhipsterMSGFORMAT. That schema will force people to think a little more when they add messages, and it will automatically document the messages that are being sent around. That's a big win I think and is a step to getting those schemas versioned... Just don't do pickling, pleasee (for other language users). On 4/24/12 8:39 AM, Eric Windisch e...@cloudscaling.com wrote: Actually, I think JSON schema for our message-bus messages might be a really good idea (tm). Violations could just be warnings until we get things locked down... maybe I should propose a blueprint? (Although I have enough of a blueprint backlog as it is...) This was discussed at the summit in (I believe) the API versioning talk. There is a strong bias toward JSON inside RPC messages. However, this is actually transparent to Nova as the RPC implementations do the decoding and encoding. It is also hard to test and trigger such warnings as, as far as Nova knows, all the interfaces pass python data types, not JSON. Some RPC mechanisms could transparently serialize. As long as there is an abstraction layer, it should be oblivious to the serialization and we should not care too strongly. There was a patch a few weeks ago that has enforced using a common RPC exception serializer using JSON, which I'm not sure is, or is not, a good thing. I haven't yet updated the ZeroMQ driver to use this, but am in the process of making these changes as I update for Folsom. All that said, I do intend that the ZeroMQ driver will use JSON when it lands in Folsom. (it currently Pickles, but only because there was a bug in Essex at one point, breaking JSON serialization) ___ 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] Using Nova APIs from Javascript: possible?
The JS may be served from a CDN. You can't assume a server-side proxy. Here's
an example of a sever-less JS application that communicates directly to EC2:
http://aws.amazon.com/developertools/1424 (there are versions for other
services like SQS and SDB as well). Server-less JS applications are a fairly
new breed of app that OpenStack should enable.
On Apr 24, 2012, at 9:04 AM, Joel Semar wrote:
Nick,
I know you said 'serverless clients' but you have to be serving the js from
somewhere right?
If you are using nginx it can be as simple as:
location /nova/ {
proxy_pass: http://nova-api.trystack.org;
}
then you can POST to yourserver/nova/v.02/. from the browser
etc.
(it's just about as simple on apache but you'd have to look it up)
But then i guess this won't work for you if you are writing some
distributable component/plugin/library.
(sorry if you've already dismissed this option but i thought it worth a shot
since it has worked flawlessly for me in the past)
On Tue, Apr 24, 2012 at 9:49 AM, Sandy Walsh sandy.wa...@rackspace.com
wrote:
On 04/24/2012 11:19 AM, Nick Lothian wrote:
JSONP is great, but won't work with POST requests.
Hmm, good point.
I don't quite understand what Due to the redirect nature of the auth
system means, though.
If I use a custom Webkit browser allow cross domain XMLHttpRequests it
works fine - I do a POST to /v2.0/tokens, get the token and then use
that. What am I missing?
The Auth system will give you a token and then a new management url
where the actual commands are issued (the real Nova API endpoint). These
are often two different systems (domains), so cross-site requests are
mandatory.
-S
Nick
On Tue, Apr 24, 2012 at 8:57 PM, Sandy Walsh sandy.wa...@rackspace.com
mailto:sandy.wa...@rackspace.com wrote:
Due to the redirect nature of the auth system we may need JSONP support
for this to work.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
mailto: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
--
Cheers,
Joel
___
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] Canonical AWSOME
The change was just to the fake rpc backend to help catch more errors in unit tests where non-primitive types are getting passed into rpc. My current code should still work, but the tests seem to have eliminated the more generic exception handling case with the assumption that testing the exceptions and the exception serialization/deserialization is sufficient. That said, I'd rather utilize *more* stuff from rpc.common, so won't complain too badly. I know that the ZeroMQ driver could be thinned a bit, by better using some of the primitives available in rpc.common and we might be able to refactor some of the stuff in ampq.py to be more generically useful (maybe). Right now, none of that is a huge concern to me, we can get it integrated and do the DRY later. -- Eric Windisch ___ 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] Monitoring / Billing Architecture proposed
Probably an extra audit system is required. I'm searching for solutions in the IT market. Regards On Tue, Apr 24, 2012 at 6:00 PM, Loic Dachary l...@enovance.com wrote: ** On 04/24/2012 04:45 PM, Monsyne Dragon wrote: On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote: On 04/24/2012 03:06 PM, Monsyne Dragon wrote: Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance The event has the somewhat generic name of 'compute.instance.exists' and is emitted on an periodic basis, currently by a cronjob. Currently, we only populate bandwidth data from XenServer, but if the hook is implemented for the kvm, etc drivers, it will be picked up automatically for them as well. Note that we could report other metrics similarly. Hi, Thanks for clarifying this. So you're suggesting that the metering agent should collect this data from the nova queue instead of extracting it from the system (interface, disk stats etc.) ? And for other openstack components ( as Nick Barcet suggests below ) the metering agent will have to find another way. Or do you have something else in mind ? If it's something we have access to, we should emit it in those usage events. As far as the other components, glance is already using the same notification system. (there was a thread awhile back about putting it into openstack.common) It would be nice to have all of the components using it. Hi, I don't see a section in http://wiki.openstack.org/SystemUsageData about making sure all messages related to a billable event are accounted for. I mean, for instance, what if the event that says an instance is deleted is lost ? How is the billing software supposed to cope with that ? If it checks the status of all VM on a regular basis to deal with this, how can it figure out when the missed event occured ? It would be worth adding a short section about this in http://wiki.openstack.org/SystemUsageData . Or I can do it if you give me a hint. Cheers Cheers On 04/24/2012 12:17 PM, Nick Barcet wrote: On 04/23/2012 10:45 PM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com brian.sch...@nimbisservices.com wrote: Doug, Do we mirror the table structure of nova, etc. and add created/modified columns? Or do we flatten into an instance event record with everything? I lean towards flattening the data as it is recorded and making a second pass during the bill calculation. You need to record instance modifications separately from the creation, especially if the modification changes the billing rate. So you might have records for: created instance, with UUID, name, size, timestamp, ownership information, etc. resized instance, with UUID, name, new size, timestamp, ownership information, etc. deleted instance, with UUID, name, size, timestamp, ownership information, etc. Maybe some of those values don't need to be reported in some cases, but if you record a complete picture of the state of the instance then the code that aggregates the event records to produce billing information can use it to make decisions about how to record the charges. There is also the case where an instance is still no longer running but nova thinks it is (or the reverse), so some sort of auditing sweep needs to be included (I think that's what Dough called the farmer but I don't have my notes in front of me). When I wrote [1], one of the things that I never assumed was how agents would collect their information. I imagined that the system should allow for multiple implementation of agents that would collect the same counters, assuming that 2 implementations for the same counter should never be running at once. That said, I am not sure an event based collection of what nova is notifying would satisfy the requirements I have heard from many cloud providers: - how do we ensure that event are not forged or lost in the current nova system? - how can I be sure that an instance has not simply crashed and never started? - how can I collect information which is not captured by nova events? Hence the proposal to use a dedicated event queue for billing, allowing for agents to collect and eventually validate data from different sources, including, but not necessarily limiting, collection from the nova events. Moreover, as soon as you generalize the problem to other components than just Nova (swift, glance, quantum, daas, ...) just using the nova event queue is not an option anymore. [1] http://wiki.openstack.org/EfficientMetering Nick On Apr 24, 2012, at 6:20 AM, Sandy Walsh wrote: I think we have support for this currently in some fashion, Dragon? -S On 04/24/2012 12:55 AM, Loic Dachary wrote: Metering needs to account for the volume of data sent to external network destinations ( i.e. n4 in
Re: [Openstack] Regular XenAPI Meeting
Good, +1 from me. Thanks, Hitesh Wadekar On Tue, Apr 24, 2012 at 9:14 PM, John Garbutt john.garb...@citrix.comwrote: Good plan, I have started a wiki page to capture that stuff: http://wiki.openstack.org/XenAPIMeetings Cheers, John -Original Message- From: Armando Migliaccio [mailto:amigliac...@internap.com] Sent: 24 April 2012 16:23 To: Alan Kavanagh Cc: John Garbutt; openstack@lists.launchpad.net Subject: Re: [Openstack] Regular XenAPI Meeting I'd be interest to join too. Shall we use a wiki page to collate names and affiliations of people interested (there's a Launchpad group set up by the way - https://launchpad.net/~openstack-xenapi), as well as meeting details? Thanks, Armando On Tue, Apr 24, 2012 at 3:32 PM, Alan Kavanagh alan.kavan...@ericsson.com wrote: Hi John +1 would be interested for monthly meeting. Time is ok. Alan From: openstack- bounces+alan.kavanagh=ericsson@lists.launchpad.net [mailto:openstack- bounces+alan.kavanagh=ericsson.com@lists.launchpad.n et] On Behalf Of John Garbutt Sent: April-23-12 1:21 PM To: openstack@lists.launchpad.net Subject: [Openstack] Regular XenAPI Meeting Hi, Are people keen for a XenAPI virt layer meetup on IRC every month? I have added a suggested time to the wiki, as a starting point: Monthly, second Wednesday at 17:00 UTC Does that seem a reasonable time for those that want to attend? It can be more frequent if we find that useful. I don't want to detract from the other meetings, but it would be good to keep all of us working on the XenAPI layer in regular contact. Cheers, 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 ___ 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] Monitoring / Billing Architecture proposed
Hi Monsyne,
I have set the notification_driver param, but no notification.* queues
created. I'm using devstack stable/essex.
stack@ubuntu:/$ sudo rabbitmqctl list_queues
Listing queues ...
volume_fanout_e0923a8bbb9f45dc9e63d382796a4c8f 0
cert.ubuntu 0
consoleauth.ubuntu 0
compute 0
compute.ubuntu 0
scheduler.ubuntu0
network_fanout_1a3d6d9e946b46d1bf64fc38be5a38aa 0
volume.ubuntu 0
compute_fanout_b29d53b516bb4acc9f8fb1bd4a9fc7f1 0
cert0
scheduler 0
consoleauth_fanout_d0fad95fbd0749929a84830a56551420 0
scheduler_fanout_0d320a2d79404d1d833ac248a8ff3dfc 0
network 0
volume 0
network.ubuntu 0
consoleauth 0
...done.
stack@ubuntu:/$
stack@ubuntu:/$ sudo rabbitmqctl list_exchanges
Listing exchanges ...
consoleauth_fanout fanout
compute_fanout fanout
amq.rabbitmq.trace topic
network_fanout fanout
amq.rabbitmq.logtopic
amq.match headers
amq.headers headers
scheduler_fanoutfanout
volume_fanout fanout
amq.topic topic
amq.direct direct
amq.fanout fanout
novatopic
direct
...done.
stack@ubuntu:/$
On Tue, Apr 24, 2012 at 2:25 AM, Monsyne Dragon mdra...@rackspace.comwrote:
This looks like just the standard RPC traffic.
You need to turn notifications on
(set:
notification_driver=nova.notifier.rabbit_notifier
in nova's config file)
and listen on the notification.* queues
On Apr 23, 2012, at 2:26 PM, Luis Gervaso wrote:
Joshua,
I have performed a create instance operation and here is an example data
obtained from stable/essex rabbitmq nova catch all exchange.
[*] Waiting for messages. To exit press CTRL+C
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
a1cb1cf61e5441c2a772b29d3cd54202, _context_read_deleted: no,
_context_request_id: req-db34ba32-8bd9-4cd5-b7b5-43705a9e258e, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:37:50.463586, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
ebb0b1c340de4024a22eafec9d0a2d66, _context_read_deleted: no,
_context_request_id: req-ddb51b2b-a29f-4aad-909d-3f7f79f053c4, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:38:59.217333, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [Member], _msg_id:
729535c00d224414a98286e9ce3475a9, _context_read_deleted: no,
_context_request_id: req-b056a8cc-3542-41a9-9e58-8fb592086264,
_context_auth_token: deb477655fba448e85199f7e559da77a,
_context_is_admin: false, _context_project_id:
df3827f76f714b1e8f31675caf84ae9d, _context_timestamp:
2012-03-24T01:39:19.813393, _context_user_id:
abe21eb7e6884547810f0a43c216e6a6, method:
get_floating_ips_by_project, _context_remote_address: 192.168.1.41}'
[x] Received '{_context_roles: [Member, admin],
_context_request_id: req-45e6c2af-52c7-4de3-af6c-6b2f7520cfd5,
_context_read_deleted: no, args: {request_spec: {num_instances:
1, block_device_mapping: [], image: {status: active, name:
cirros-0.3.0-x86_64-uec, deleted: false, container_format: ami,
created_at: 2012-03-20 17:37:08, disk_format: ami, updated_at:
2012-03-20 17:37:08, properties: {kernel_id:
6b700d25-3293-420a-82e4-8247d4b0da2a, ramdisk_id:
22b10c35-c868-4470-84ef-54ae9f17a977}, min_ram: 0, checksum:
2f81976cae15c16ef0010c51e3a6c163, min_disk: 0, is_public: true,
deleted_at: null, id: f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, size:
25165824}, instance_type: {root_gb: 0, name: m1.tiny, deleted:
false, created_at: null, ephemeral_gb: 0, updated_at: null,
memory_mb: 512, vcpus: 1, flavorid: 1, swap: 0, rxtx_factor:
1.0, extra_specs: {}, deleted_at: null, vcpu_weight: null, id: 2},
instance_properties: {vm_state: building, ephemeral_gb: 0,
access_ip_v6: null, access_ip_v4: null, kernel_id:
6b700d25-3293-420a-82e4-8247d4b0da2a, key_name: testssh,
ramdisk_id: 22b10c35-c868-4470-84ef-54ae9f17a977, instance_type_id:
2, user_data:
Re: [Openstack] Canonical AWSOME
On 04/24/2012 01:25 PM, Joshua Harlow wrote: I’m more in favor of just having a schema, I don’t care if that compiles to protocol buffers, json, NEWAWESOMEhipsterMSGFORMAT. That schema will force people to think a little more when they add messages, and it will automatically document the messages that are being sent around. That’s a big win I think and is a step to getting those schemas versioned... I'm not sure a schema is really necessary aside from the Python classes themselves. They're internal APIs, so they shouldn't be used from outside of Nova. A schema would be useful if we had to define the interfaces in some language neutral-format, but I don't think that really matters here. I'm going to work on a proposal / prototype for how we can handle versioning, though. The big goal here is making sure that we can maintain compatibility with the previous release. -- 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] HTTP status value naming normalization
Hello It's very cool. I send review request to review.openstack.org this a link to it https://review.openstack.org/#/c/6775/ Thank you, Victor 2012/4/23 Doug Hellmann doug.hellm...@dreamhost.com: This sounds like a good candidate to live in openstack-common, rather than being limited to Swift. On Sat, Apr 21, 2012 at 12:22 PM, John Dickinson m...@not.mn wrote: I like what you are trying to do here. Can you please submit this as a patch through gerrit so we can get the rest of the core devs to look at it? --John On Apr 20, 2012, at 12:14 PM, Victor Rodionov wrote: There are many place in Swift code where used hard coded values, such as response statuses (200, 201, 404, ...) which can replaced with constants HTTP_OK, HTTP_CREATED, HTTP_NOT_FOUND. Also there is widlly used idiom 200 = status 300, that can be replaced as well with something like this is_success(status). I want add modules for defining all required constants (Swift, HTTP). So I think this changes will improve Swift code readability. PS: this is an initial changes in github https://github.com/vitoordaz/swift/commit/7163d5df13ceaf8fc7b53ba812fe16bd7dd31131 ___ 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] Monitoring / Billing Architecture proposed
I take it that the instance manager doesn't generate any kind of heartbeat, so whatever monitoring/archiving service we do should internally poll the status over MQ? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 24, 2012, at 2:10 PM, Luis Gervaso wrote: Probably an extra audit system is required. I'm searching for solutions in the IT market. Regards On Tue, Apr 24, 2012 at 6:00 PM, Loic Dachary l...@enovance.com wrote: On 04/24/2012 04:45 PM, Monsyne Dragon wrote: On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote: On 04/24/2012 03:06 PM, Monsyne Dragon wrote: Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance The event has the somewhat generic name of 'compute.instance.exists' and is emitted on an periodic basis, currently by a cronjob. Currently, we only populate bandwidth data from XenServer, but if the hook is implemented for the kvm, etc drivers, it will be picked up automatically for them as well. Note that we could report other metrics similarly. Hi, Thanks for clarifying this. So you're suggesting that the metering agent should collect this data from the nova queue instead of extracting it from the system (interface, disk stats etc.) ? And for other openstack components ( as Nick Barcet suggests below ) the metering agent will have to find another way. Or do you have something else in mind ? If it's something we have access to, we should emit it in those usage events. As far as the other components, glance is already using the same notification system. (there was a thread awhile back about putting it into openstack.common) It would be nice to have all of the components using it. Hi, I don't see a section in http://wiki.openstack.org/SystemUsageData about making sure all messages related to a billable event are accounted for. I mean, for instance, what if the event that says an instance is deleted is lost ? How is the billing software supposed to cope with that ? If it checks the status of all VM on a regular basis to deal with this, how can it figure out when the missed event occured ? It would be worth adding a short section about this in http://wiki.openstack.org/SystemUsageData . Or I can do it if you give me a hint. Cheers Cheers On 04/24/2012 12:17 PM, Nick Barcet wrote: On 04/23/2012 10:45 PM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com wrote: Doug, Do we mirror the table structure of nova, etc. and add created/modified columns? Or do we flatten into an instance event record with everything? I lean towards flattening the data as it is recorded and making a second pass during the bill calculation. You need to record instance modifications separately from the creation, especially if the modification changes the billing rate. So you might have records for: created instance, with UUID, name, size, timestamp, ownership information, etc. resized instance, with UUID, name, new size, timestamp, ownership information, etc. deleted instance, with UUID, name, size, timestamp, ownership information, etc. Maybe some of those values don't need to be reported in some cases, but if you record a complete picture of the state of the instance then the code that aggregates the event records to produce billing information can use it to make decisions about how to record the charges. There is also the case where an instance is still no longer running but nova thinks it is (or the reverse), so some sort of auditing sweep needs to be included (I think that's what Dough called the farmer but I don't have my notes in front of me). When I wrote [1], one of the things that I never assumed was how agents would collect their information. I imagined that the system should allow for multiple implementation of agents that would collect the same counters, assuming that 2 implementations for the same counter should never be running at once. That said, I am not sure an event based collection of what nova is notifying would satisfy the requirements I have heard from many cloud providers: - how do we ensure that event are not forged or lost in the current nova system? - how can I be sure that an instance has not simply crashed and never started? - how can I collect information which is not captured by nova events? Hence the proposal to use a dedicated event queue for billing, allowing for agents to collect and eventually validate data from different sources, including, but not necessarily limiting, collection from the nova events. Moreover, as soon as you generalize the problem to other components than just Nova (swift, glance, quantum, daas, ...) just using the nova
Re: [Openstack] Sharing disk: OCFS2 or GFS2?
What do you mean by connecting at the same time? The semantics of a block service is that a volume is mounted by a single user at a time. When you want something more complex you should build that with a proxy on top of the base service. What you are talking about is a very Specialized need with your own logic on how to reconcile conflicting writes from your two mounts. -Original Message- From: openstack-bounces+caitlin.bestler=nexenta@lists.launchpad.net [mailto:openstack-bounces+caitlin.bestler=nexenta@lists.launchpad.net] On Behalf Of Narayan Desai Sent: Tuesday, April 24, 2012 7:56 AM To: Daniel Martinez Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Sharing disk: OCFS2 or GFS2? As far as I know, the current volume service doesn't support connecting the same volume to multiple instances at the same time, so neither of these can work directly through nova apis. -nld On Tue, Apr 24, 2012 at 4:44 AM, Daniel Martinez danie...@gmail.com wrote: Hello everyone. My setup is simple. A volumen shared by iSCSI from our Netapp storage that I would like to use it for the instances running on our nova-compute nodes. Has anyone tried to use OCFS2 or GFS2 as FS via iSCSI mounted on the nova-computes as a sharing disk and running the instances into it? The plan b is to create a volumen by node and to format it as ext3 or ext4. Any recomendations? Thanks! Regards, Daniel ___ 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
[Openstack] CPU processing time
Hi, guys, Can I ask some questions beyond OpenStack? If yes, who can give me some hints that if I need to design a datacenter, I have request numbers I need to process per day, different types of servers. How can I compute the processing time for each request, and how to decide the number of servers? If no, just ignore this message. Thanks~ ___ 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] Monitoring / Billing Architecture proposed
This kind of messages are coming from nova exchange aprox. each 60 secs
Can be this considered as a heartbeat for you?
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
On Tue, Apr 24, 2012 at 9:31 PM, Brian Schott
brian.sch...@nimbisservices.com wrote:
I take it that the instance manager doesn't generate any kind of
heartbeat, so whatever monitoring/archiving service we do should internally
poll the status over MQ?
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Apr 24, 2012, at 2:10 PM, Luis Gervaso wrote:
Probably an extra audit system is required. I'm searching for solutions in
the IT market.
Regards
On Tue, Apr 24, 2012 at 6:00 PM, Loic Dachary l...@enovance.com wrote:
**
On 04/24/2012 04:45 PM, Monsyne Dragon wrote:
On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote:
On 04/24/2012 03:06 PM, Monsyne Dragon wrote:
Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance
The event has the somewhat generic name of 'compute.instance.exists' and is
emitted on an periodic basis, currently by a cronjob.
Currently, we only populate bandwidth data from XenServer, but if the hook
is implemented for the kvm, etc drivers, it will be picked up automatically
for them as well.
Note that we could report other metrics similarly.
Hi,
Thanks for clarifying this. So you're suggesting that the metering agent
should collect this data from the nova queue instead of extracting it from
the system (interface, disk stats etc.) ? And for other openstack
components ( as Nick Barcet suggests below ) the metering agent will have
to find another way. Or do you have something else in mind ?
If it's something we have access to, we should emit it in those usage
events. As far as the other components, glance is already using the same
notification system. (there was a thread awhile back about putting it into
openstack.common) It would be nice to have all of the components using it.
Hi,
I don't see a section in http://wiki.openstack.org/SystemUsageData about
making sure all messages related to a billable event are accounted for. I
mean, for instance, what if the event that says an instance is deleted is
lost ? How is the billing software supposed to cope with that ? If it
checks the status of all VM on a regular basis to deal with this, how can
it figure out when the missed event occured ?
It would be worth adding a short section about this in
http://wiki.openstack.org/SystemUsageData . Or I can do it if you give
me a hint.
Cheers
Cheers
On 04/24/2012 12:17 PM, Nick Barcet wrote:
On 04/23/2012 10:45 PM, Doug Hellmann wrote:
On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott
brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com
brian.sch...@nimbisservices.com wrote: Doug, Do we mirror
the table structure of nova, etc. and add created/modified columns?
Or do we flatten into an instance event record with everything?
I lean towards flattening the data as it is recorded and making a second
pass during the bill calculation. You need to record instance modifications
separately from the creation, especially if the modification changes the
billing rate. So you might have records for: created instance, with UUID,
name, size, timestamp, ownership information, etc. resized instance, with
UUID, name, new size, timestamp, ownership information, etc. deleted
instance, with UUID, name, size, timestamp, ownership information, etc.
Maybe some of those values don't need to be reported in some cases, but if
you record a complete picture of the state of the instance then the code
that aggregates the event records to produce billing information can use it
to make decisions about how to record the charges. There is also the case
where an instance is still no longer running but nova thinks it is (or the
reverse), so some sort of auditing sweep needs to be included (I think
that's what Dough called the farmer but I don't have my notes in front of
me).
When I wrote [1], one of the things that I never assumed was how agents
would collect their information. I imagined that the system should allow
for multiple implementation of agents that would collect the same
counters, assuming that 2 implementations for the same counter should
never be running at once.
That said, I
Re: [Openstack] Monitoring / Billing Architecture proposed
Yeah, but does that mean the instance is alive and billable :-)? I guess that
counts! I thought they were only in response to external API/admin requests.
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Apr 24, 2012, at 3:42 PM, Luis Gervaso wrote:
This kind of messages are coming from nova exchange aprox. each 60 secs
Can be this considered as a heartbeat for you?
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
On Tue, Apr 24, 2012 at 9:31 PM, Brian Schott
brian.sch...@nimbisservices.com wrote:
I take it that the instance manager doesn't generate any kind of heartbeat,
so whatever monitoring/archiving service we do should internally poll the
status over MQ?
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Apr 24, 2012, at 2:10 PM, Luis Gervaso wrote:
Probably an extra audit system is required. I'm searching for solutions in
the IT market.
Regards
On Tue, Apr 24, 2012 at 6:00 PM, Loic Dachary l...@enovance.com wrote:
On 04/24/2012 04:45 PM, Monsyne Dragon wrote:
On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote:
On 04/24/2012 03:06 PM, Monsyne Dragon wrote:
Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each
instance The event has the somewhat generic name of
'compute.instance.exists' and is emitted on an periodic basis, currently
by a cronjob.
Currently, we only populate bandwidth data from XenServer, but if the
hook is implemented for the kvm, etc drivers, it will be picked up
automatically for them as well.
Note that we could report other metrics similarly.
Hi,
Thanks for clarifying this. So you're suggesting that the metering agent
should collect this data from the nova queue instead of extracting it from
the system (interface, disk stats etc.) ? And for other openstack
components ( as Nick Barcet suggests below ) the metering agent will have
to find another way. Or do you have something else in mind ?
If it's something we have access to, we should emit it in those usage
events. As far as the other components, glance is already using the same
notification system. (there was a thread awhile back about putting it into
openstack.common) It would be nice to have all of the components using it.
Hi,
I don't see a section in http://wiki.openstack.org/SystemUsageData about
making sure all messages related to a billable event are accounted for. I
mean, for instance, what if the event that says an instance is deleted is
lost ? How is the billing software supposed to cope with that ? If it checks
the status of all VM on a regular basis to deal with this, how can it figure
out when the missed event occured ?
It would be worth adding a short section about this in
http://wiki.openstack.org/SystemUsageData . Or I can do it if you give me a
hint.
Cheers
Cheers
On 04/24/2012 12:17 PM, Nick Barcet wrote:
On 04/23/2012 10:45 PM, Doug Hellmann wrote:
On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott
brian.sch...@nimbisservices.com
mailto:brian.sch...@nimbisservices.com wrote:
Doug,
Do we mirror the table structure of nova, etc. and add
created/modified columns?
Or do we flatten into an instance event record with everything?
I lean towards flattening the data as it is recorded and making a
second
pass during the bill calculation. You need to record instance
modifications separately from the creation, especially if the
modification changes the billing rate. So you might have records for:
created instance, with UUID, name, size, timestamp, ownership
information, etc.
resized instance, with UUID, name, new size, timestamp, ownership
information, etc.
deleted instance, with UUID, name, size, timestamp, ownership
information, etc.
Maybe some of those values don't need to be reported in some cases, but
if you record a complete picture of the state of the instance then the
code that aggregates the event records to produce billing information
can use it to make decisions about how to record the charges.
There is also the case where an instance is still no longer running but
nova thinks it is (or the reverse), so some sort of auditing sweep
needs
to
Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?
Having endpoints under the service construct is supposed to make it easier to programmatically find the endpoint(s) you are interested in. For example - as nova client I can parse the service catalog and identity nova by service-type compute in order to get the public, internal, and admin endpoints for nova. By having service type name as attributes under the endpoint, I'll have a harder time doing that (having to dive into each endpoint construct to identify the ones with service-type compute). Maybe it would be better to have each endpoint have its own construct inside of a service. So instead of http://paste.openstack.org/show/13678/ Maybe http://paste.openstack.org/show/13682/ From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Friday, April 20, 2012 4:16 PM To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Cc: Adam Gandelman Subject: [Openstack] [Keystone] What exactly are we modeling with endpoints? While I've been roaming about the summit and conference, I've been trying to figure out exactly what we're modeling with the current service and endpoints that are in the API today. After talking with a number of folks, it's getting clearer that how it's being used is very installation specific. I'd like to simplify this aspect of the API if at all possible, especially with a lot of the good ideas around describing the relationships between endpoints and and their installation. The use cases I'm hearing actively in use are: * (Horizon/UI/client) To indicate to a user where they can go to access their data * (Glance, Nova, Keystone client) to find the endpoint relevant to uploading images (current client implementations appear to assume there is only one image endpoint) The use case to indicate a geographic location for a datacenter or cloud is not consistent - some implementations I've learned of have that feature (and use Region for that sort of information), and others are load balancing a single endpoint to deploy to multiple datacenters and geographic regions from a single endpoint. At the summit and conference, I heard a desire to expose geographic information with the endpoints, but that is clearly an operator specific implementation/deployment detail. Likewise I heard a lot of We could really... if additional metadata was easily available on endpoints, again in fairly implementation/deployment specific detail. So looking forward towards a v.next API, what do you all think about having just endpoints, with everything else being attributes on those endpoints (including what service and type it is), with some expected conventions (that there are a few well defined types - such as PublicURL and InternalURL, and relevant names for the rest API endpoints (ec2, compute, volume, image, identity...) Additional metadata can then float on the endpoints in deployment/implementation specific ways that don't lock in other systems to be deployed and implemented in the same fashion. -joe On Apr 20, 2012, at 1:47 PM, Lorin Hochstein wrote: On Apr 13, 2012, at 12:34 PM, Adam Gandelman wrote: On 04/13/2012 10:50 AM, Dolph Mathews wrote: While $(tenant_id)s is certainly the documented syntax, it appears that the SQL catalog backend (and *only* the SQL catalog backend, as far as I can tell) explicitly supports both $(tenant_id)s and %(tenant_id)s: https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/sql.py#L163 Perhaps Adam Gandelman has some insight? -Dolph Dolph- No, the same is supported in the case of templated catalog as well, which is what the SQL catalog was largely based off: https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/templated.py#L115 Just tested that sed -i 's/\$/%/g' /etc/keystone/default_catalog.templates still produces a functional service catalog when configured to use the templated backend. Seeing as both are supported, perhaps it would be better for docs to be updated to refer to the use of % instead of $ to avoid people running into problems with the $() sub-shell? The OpenStack Install and Deploy manual has some language about this (see last paragraph): http://docs.openstack.org/trunk/openstack-compute/install/content/elements-of-keystone-service-catalog-entry.html This hasn't made its way into the admin docs yet, though. Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.comhttps://www.nimbisservices.com/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: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] [OpenStack][Nova] Minimum required code coverage per file
Hi All, I would like to propose a minimum required code coverage level per file in Nova. Say 80%. This would mean that any new feature/file should only be accepted if it has over 80% code coverage. Exceptions to this rule would be allowed for code that is covered by skipped tests (as long as 80% is reached when the tests are not skipped). With 193 python files in nova/tests, Nova unit tests produce 85% overall code coverage (calculated with ./run_test.sh -c [1]). But 23% of files (125 files) have lower then 80% code coverage (30 tests skipped on my machine). Getting all files to hit the 80% code coverage mark should be one of the goals for Folsom. Some files with low coverage: nova/flags 18% nova/tests/integrated/test_servers 27% nova/testing/runner 31% nova/api/ec2/faults 36% nova/network/quantum/client 36% nova/network/quantum/melange_connection 38% nova/openstack/common/iniparser 40% nova/openstack/common/cfg 41% nova/tests/db/fakes 41% nova/console/api 44% nova/image/s3 50% nova/api/ec2/__init__ 53% nova/notifier/log_notifier 56% best, Joe Gordon [1] With https://review.openstack.org/#/c/6750/ ___ 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] Monitoring / Billing Architecture proposed
I think so.
If it is in response or not, it's a truly heartbeat
On Tue, Apr 24, 2012 at 9:46 PM, Brian Schott
brian.sch...@nimbisservices.com wrote:
Yeah, but does that mean the instance is alive and billable :-)? I guess
that counts! I thought they were only in response to external API/admin
requests.
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Apr 24, 2012, at 3:42 PM, Luis Gervaso wrote:
This kind of messages are coming from nova exchange aprox. each 60 secs
Can be this considered as a heartbeat for you?
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe,
args: {instance_id: 6, instance_uuid:
e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
On Tue, Apr 24, 2012 at 9:31 PM, Brian Schott
brian.sch...@nimbisservices.com wrote:
I take it that the instance manager doesn't generate any kind of
heartbeat, so whatever monitoring/archiving service we do should internally
poll the status over MQ?
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Apr 24, 2012, at 2:10 PM, Luis Gervaso wrote:
Probably an extra audit system is required. I'm searching for solutions
in the IT market.
Regards
On Tue, Apr 24, 2012 at 6:00 PM, Loic Dachary l...@enovance.com wrote:
**
On 04/24/2012 04:45 PM, Monsyne Dragon wrote:
On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote:
On 04/24/2012 03:06 PM, Monsyne Dragon wrote:
Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each
instance The event has the somewhat generic name of
'compute.instance.exists' and is emitted on an periodic basis, currently
by a cronjob.
Currently, we only populate bandwidth data from XenServer, but if the hook
is implemented for the kvm, etc drivers, it will be picked up
automatically for them as well.
Note that we could report other metrics similarly.
Hi,
Thanks for clarifying this. So you're suggesting that the metering agent
should collect this data from the nova queue instead of extracting it from
the system (interface, disk stats etc.) ? And for other openstack
components ( as Nick Barcet suggests below ) the metering agent will have
to find another way. Or do you have something else in mind ?
If it's something we have access to, we should emit it in those usage
events. As far as the other components, glance is already using the same
notification system. (there was a thread awhile back about putting it into
openstack.common) It would be nice to have all of the components using it.
Hi,
I don't see a section in http://wiki.openstack.org/SystemUsageDataabout
making sure all messages related to a billable event are accounted
for. I mean, for instance, what if the event that says an instance is
deleted is lost ? How is the billing software supposed to cope with that ?
If it checks the status of all VM on a regular basis to deal with this, how
can it figure out when the missed event occured ?
It would be worth adding a short section about this in
http://wiki.openstack.org/SystemUsageData . Or I can do it if you give
me a hint.
Cheers
Cheers
On 04/24/2012 12:17 PM, Nick Barcet wrote:
On 04/23/2012 10:45 PM, Doug Hellmann wrote:
On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott
brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com
brian.sch...@nimbisservices.com wrote: Doug, Do we mirror
the table structure of nova, etc. and add created/modified columns?
Or do we flatten into an instance event record with everything?
I lean towards flattening the data as it is recorded and making a
second pass during the bill calculation. You need to record instance
modifications separately from the creation, especially if the modification
changes the billing rate. So you might have records for: created
instance, with UUID, name, size, timestamp, ownership information, etc.
resized instance, with UUID, name, new size, timestamp, ownership
information, etc. deleted instance, with UUID, name, size, timestamp,
ownership information, etc. Maybe some of those values don't need to be
reported in some cases, but if you record a complete picture of the state
of the instance then the code that aggregates the event records to produce
billing information can use it to make decisions about how to record the
charges. There is also the case where an
Re: [Openstack] Monitoring / Billing Architecture proposed
On Apr 24, 2012, at 11:00 AM, Loic Dachary wrote: On 04/24/2012 04:45 PM, Monsyne Dragon wrote: On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote: On 04/24/2012 03:06 PM, Monsyne Dragon wrote: Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance The event has the somewhat generic name of 'compute.instance.exists' and is emitted on an periodic basis, currently by a cronjob. Currently, we only populate bandwidth data from XenServer, but if the hook is implemented for the kvm, etc drivers, it will be picked up automatically for them as well. Note that we could report other metrics similarly. Hi, Thanks for clarifying this. So you're suggesting that the metering agent should collect this data from the nova queue instead of extracting it from the system (interface, disk stats etc.) ? And for other openstack components ( as Nick Barcet suggests below ) the metering agent will have to find another way. Or do you have something else in mind ? If it's something we have access to, we should emit it in those usage events. As far as the other components, glance is already using the same notification system. (there was a thread awhile back about putting it into openstack.common) It would be nice to have all of the components using it. Hi, I don't see a section in http://wiki.openstack.org/SystemUsageData about making sure all messages related to a billable event are accounted for. I mean, for instance, what if the event that says an instance is deleted is lost ? How is the billing software supposed to cope with that ? If it checks the status of all VM on a regular basis to deal with this, how can it figure out when the missed event occured ? FIrst, we use a reliable queueing mechanism to prevent that. Secondly there are periodic audit events that act as a check (and also contain data for usage over a time period, like bandwidth). It would be worth adding a short section about this in http://wiki.openstack.org/SystemUsageData . Or I can do it if you give me a hint. Cheers Cheers On 04/24/2012 12:17 PM, Nick Barcet wrote: On 04/23/2012 10:45 PM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com wrote: Doug, Do we mirror the table structure of nova, etc. and add created/modified columns? Or do we flatten into an instance event record with everything? I lean towards flattening the data as it is recorded and making a second pass during the bill calculation. You need to record instance modifications separately from the creation, especially if the modification changes the billing rate. So you might have records for: created instance, with UUID, name, size, timestamp, ownership information, etc. resized instance, with UUID, name, new size, timestamp, ownership information, etc. deleted instance, with UUID, name, size, timestamp, ownership information, etc. Maybe some of those values don't need to be reported in some cases, but if you record a complete picture of the state of the instance then the code that aggregates the event records to produce billing information can use it to make decisions about how to record the charges. There is also the case where an instance is still no longer running but nova thinks it is (or the reverse), so some sort of auditing sweep needs to be included (I think that's what Dough called the farmer but I don't have my notes in front of me). When I wrote [1], one of the things that I never assumed was how agents would collect their information. I imagined that the system should allow for multiple implementation of agents that would collect the same counters, assuming that 2 implementations for the same counter should never be running at once. That said, I am not sure an event based collection of what nova is notifying would satisfy the requirements I have heard from many cloud providers: - how do we ensure that event are not forged or lost in the current nova system? - how can I be sure that an instance has not simply crashed and never started? - how can I collect information which is not captured by nova events? Hence the proposal to use a dedicated event queue for billing, allowing for agents to collect and eventually validate data from different sources, including, but not necessarily limiting, collection from the nova events. Moreover, as soon as you generalize the problem to other components than just Nova (swift, glance, quantum, daas, ...) just using the nova event queue is not an option anymore. [1] http://wiki.openstack.org/EfficientMetering Nick On Apr 24, 2012, at 6:20 AM, Sandy Walsh wrote: I think we have support for this currently in some fashion, Dragon? -S On 04/24/2012 12:55 AM, Loic Dachary wrote: Metering needs to account for the volume of data sent to external network
Re: [Openstack] Monitoring / Billing Architecture proposed
On Apr 24, 2012, at 2:31 PM, Brian Schott wrote:
I take it that the instance manager doesn't generate any kind of heartbeat, so
whatever monitoring/archiving service we do should internally poll the status
over MQ?
Actually, it generates periodic 'heartbeat' events ('exists' events) for each
instance that existed during a given audit period.
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Apr 24, 2012, at 2:10 PM, Luis Gervaso wrote:
Probably an extra audit system is required. I'm searching for solutions in the
IT market.
Regards
On Tue, Apr 24, 2012 at 6:00 PM, Loic Dachary
l...@enovance.commailto:l...@enovance.com wrote:
On 04/24/2012 04:45 PM, Monsyne Dragon wrote:
On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote:
On 04/24/2012 03:06 PM, Monsyne Dragon wrote:
Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance
The event has the somewhat generic name of 'compute.instance.exists' and is
emitted on an periodic basis, currently by a cronjob.
Currently, we only populate bandwidth data from XenServer, but if the hook is
implemented for the kvm, etc drivers, it will be picked up automatically for
them as well.
Note that we could report other metrics similarly.
Hi,
Thanks for clarifying this. So you're suggesting that the metering agent should
collect this data from the nova queue instead of extracting it from the system
(interface, disk stats etc.) ? And for other openstack components ( as Nick
Barcet suggests below ) the metering agent will have to find another way. Or do
you have something else in mind ?
If it's something we have access to, we should emit it in those usage events.
As far as the other components, glance is already using the same notification
system. (there was a thread awhile back about putting it into
openstack.common) It would be nice to have all of the components using it.
Hi,
I don't see a section in http://wiki.openstack.org/SystemUsageData about making
sure all messages related to a billable event are accounted for. I mean, for
instance, what if the event that says an instance is deleted is lost ? How is
the billing software supposed to cope with that ? If it checks the status of
all VM on a regular basis to deal with this, how can it figure out when the
missed event occured ?
It would be worth adding a short section about this in
http://wiki.openstack.org/SystemUsageData . Or I can do it if you give me a
hint.
Cheers
Cheers
On 04/24/2012 12:17 PM, Nick Barcet wrote:
On 04/23/2012 10:45 PM, Doug Hellmann wrote:
On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott
brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com
mailto:brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com
wrote:
Doug,
Do we mirror the table structure of nova, etc. and add
created/modified columns?
Or do we flatten into an instance event record with everything?
I lean towards flattening the data as it is recorded and making a second
pass during the bill calculation. You need to record instance
modifications separately from the creation, especially if the
modification changes the billing rate. So you might have records for:
created instance, with UUID, name, size, timestamp, ownership
information, etc.
resized instance, with UUID, name, new size, timestamp, ownership
information, etc.
deleted instance, with UUID, name, size, timestamp, ownership
information, etc.
Maybe some of those values don't need to be reported in some cases, but
if you record a complete picture of the state of the instance then the
code that aggregates the event records to produce billing information
can use it to make decisions about how to record the charges.
There is also the case where an instance is still no longer running but
nova thinks it is (or the reverse), so some sort of auditing sweep needs
to be included (I think that's what Dough called the farmer but I
don't have my notes in front of me).
When I wrote [1], one of the things that I never assumed was how agents
would collect their information. I imagined that the system should allow
for multiple implementation of agents that would collect the same
counters, assuming that 2 implementations for the same counter should
never be running at once.
That said, I am not sure an event based collection of what nova is
notifying would satisfy the requirements I have heard from many cloud
providers:
- how do we ensure that event are not forged or lost in the current nova
system?
- how can I be sure that an instance has not simply crashed and never
started?
- how can I collect information which is not captured by nova events?
Hence the proposal to use a dedicated event queue for billing, allowing
for agents to collect and eventually validate data from different
sources, including, but
Re: [Openstack] Monitoring / Billing Architecture proposed
On Apr 24, 2012, at 2:46 PM, Brian Schott wrote:
Yeah, but does that mean the instance is alive and billable :-)? I guess that
counts! I thought they were only in response to external API/admin requests.
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
Actually, that is simply an rpc call message. Unrelated to notifications.
On Apr 24, 2012, at 3:42 PM, Luis Gervaso wrote:
This kind of messages are coming from nova exchange aprox. each 60 secs
Can be this considered as a heartbeat for you?
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
On Tue, Apr 24, 2012 at 9:31 PM, Brian Schott
brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com wrote:
I take it that the instance manager doesn't generate any kind of heartbeat, so
whatever monitoring/archiving service we do should internally poll the status
over MQ?
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com
ph: 443-274-6064tel:443-274-6064 fx: 443-274-6060tel:443-274-6060
On Apr 24, 2012, at 2:10 PM, Luis Gervaso wrote:
Probably an extra audit system is required. I'm searching for solutions in the
IT market.
Regards
On Tue, Apr 24, 2012 at 6:00 PM, Loic Dachary
l...@enovance.commailto:l...@enovance.com wrote:
On 04/24/2012 04:45 PM, Monsyne Dragon wrote:
On Apr 24, 2012, at 9:03 AM, Loic Dachary wrote:
On 04/24/2012 03:06 PM, Monsyne Dragon wrote:
Yes, we emit bandwidth (bytes in/out) on a per VIF basis from each instance
The event has the somewhat generic name of 'compute.instance.exists' and is
emitted on an periodic basis, currently by a cronjob.
Currently, we only populate bandwidth data from XenServer, but if the hook is
implemented for the kvm, etc drivers, it will be picked up automatically for
them as well.
Note that we could report other metrics similarly.
Hi,
Thanks for clarifying this. So you're suggesting that the metering agent should
collect this data from the nova queue instead of extracting it from the system
(interface, disk stats etc.) ? And for other openstack components ( as Nick
Barcet suggests below ) the metering agent will have to find another way. Or do
you have something else in mind ?
If it's something we have access to, we should emit it in those usage events.
As far as the other components, glance is already using the same notification
system. (there was a thread awhile back about putting it into
openstack.common) It would be nice to have all of the components using it.
Hi,
I don't see a section in http://wiki.openstack.org/SystemUsageData about making
sure all messages related to a billable event are accounted for. I mean, for
instance, what if the event that says an instance is deleted is lost ? How is
the billing software supposed to cope with that ? If it checks the status of
all VM on a regular basis to deal with this, how can it figure out when the
missed event occured ?
It would be worth adding a short section about this in
http://wiki.openstack.org/SystemUsageData . Or I can do it if you give me a
hint.
Cheers
Cheers
On 04/24/2012 12:17 PM, Nick Barcet wrote:
On 04/23/2012 10:45 PM, Doug Hellmann wrote:
On Mon, Apr 23, 2012 at 4:14 PM, Brian Schott
brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com
mailto:brian.sch...@nimbisservices.commailto:brian.sch...@nimbisservices.com
wrote:
Doug,
Do we mirror the table structure of nova, etc. and add
created/modified columns?
Or do we flatten into an instance event record with everything?
I lean towards flattening the data as it is recorded and making a second
pass during the bill calculation. You need to record instance
modifications separately from the creation, especially if the
modification changes the billing rate. So you might have records for:
created instance, with UUID, name, size, timestamp, ownership
information, etc.
resized instance, with UUID, name, new size, timestamp, ownership
information, etc.
deleted instance, with UUID, name, size, timestamp, ownership
information, etc.
Maybe some of those values don't need to be reported in some cases, but
if you record a complete picture of the state of the instance then the
code that aggregates the event records to produce
Re: [Openstack] [OpenStack][Nova] Minimum required code coverage per file
On Tue, Apr 24, 2012 at 1:11 PM, Joe Gordon j...@cloudscaling.com wrote: Hi All, I would like to propose a minimum required code coverage level per file in Nova. Say 80%. This would mean that any new feature/file should only be accepted if it has over 80% code coverage. Exceptions to this rule would be allowed for code that is covered by skipped tests (as long as 80% is reached when the tests are not skipped). With 193 python files in nova/tests, Nova unit tests produce 85% overall code coverage (calculated with ./run_test.sh -c [1]). But 23% of files (125 files) have lower then 80% code coverage (30 tests skipped on my machine). Getting all files to hit the 80% code coverage mark should be one of the goals for Folsom. Thanks for driving this Joe. Some files with low coverage: nova/network/quantum/client 36% nova/network/quantum/melange_connection 38% These two files will be removed in Folsom, as Nova will use the proper Quantum client lib, instead of having its own copy. Melange client functionality will be folded into Quantum client. Dan best, Joe Gordon [1] With https://review.openstack.org/#/c/6750/ ___ 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] raw or qcow2
On Apr 17, 2012, at 2:04 AM, William Herry wrote: so, what changes should I make if I want use raw in openstack, I didn't find some configure option in nova.conf.sample I also try to modify the source code in nova/virt/libvirt/utils.py, and didn't succeed I noticed that the type of snapshot is same as the instance's image by default, does this right, and what about the type of model image that uploaded to glance, does it affect the disk type I use? Thanks snapshots will not work with raw images. To make openstack use raw images, you simply have to set: use_cow_images=false you can upload to glance in qcow or raw, it will be decoded to raw when the image is downloaded to the compute host. Vish ___ 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][Nova] Minimum required code coverage per file
+1 From: openstack-bounces+nayna.patel=hp@lists.launchpad.net [mailto:openstack-bounces+nayna.patel=hp@lists.launchpad.net] On Behalf Of Dan Wendlandt Sent: Tuesday, April 24, 2012 2:58 PM To: Joe Gordon Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [OpenStack][Nova] Minimum required code coverage per file On Tue, Apr 24, 2012 at 1:11 PM, Joe Gordon j...@cloudscaling.commailto:j...@cloudscaling.com wrote: Hi All, I would like to propose a minimum required code coverage level per file in Nova. Say 80%. This would mean that any new feature/file should only be accepted if it has over 80% code coverage. Exceptions to this rule would be allowed for code that is covered by skipped tests (as long as 80% is reached when the tests are not skipped). With 193 python files in nova/tests, Nova unit tests produce 85% overall code coverage (calculated with ./run_test.sh -c [1]). But 23% of files (125 files) have lower then 80% code coverage (30 tests skipped on my machine). Getting all files to hit the 80% code coverage mark should be one of the goals for Folsom. Thanks for driving this Joe. Some files with low coverage: nova/network/quantum/client 36% nova/network/quantum/melange_connection 38% These two files will be removed in Folsom, as Nova will use the proper Quantum client lib, instead of having its own copy. Melange client functionality will be folded into Quantum client. Dan best, Joe Gordon [1] With https://review.openstack.org/#/c/6750/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.comhttp://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] raw or qcow2
What changes would be needed to make qcow2 files work as snapshots? Some type of image dependency management in glance (and failure cases) and the corresponding dependency fetching in nova (and failure cases)? Might be something pretty useful to have, instead of forcing raw for snapshots? On 4/24/12 3:51 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: On Apr 17, 2012, at 2:04 AM, William Herry wrote: so, what changes should I make if I want use raw in openstack, I didn't find some configure option in nova.conf.sample I also try to modify the source code in nova/virt/libvirt/utils.py, and didn't succeed I noticed that the type of snapshot is same as the instance's image by default, does this right, and what about the type of model image that uploaded to glance, does it affect the disk type I use? Thanks snapshots will not work with raw images. To make openstack use raw images, you simply have to set: use_cow_images=false you can upload to glance in qcow or raw, it will be decoded to raw when the image is downloaded to the compute host. Vish ___ 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] Regular XenAPI Meeting
John, Please count me in as well. Wu Sent from my iPad On Apr 24, 2012, at 11:44 PM, John Garbutt john.garb...@citrix.com wrote: Good plan, I have started a wiki page to capture that stuff: http://wiki.openstack.org/XenAPIMeetings Cheers, John -Original Message- From: Armando Migliaccio [mailto:amigliac...@internap.com] Sent: 24 April 2012 16:23 To: Alan Kavanagh Cc: John Garbutt; openstack@lists.launchpad.net Subject: Re: [Openstack] Regular XenAPI Meeting I'd be interest to join too. Shall we use a wiki page to collate names and affiliations of people interested (there's a Launchpad group set up by the way - https://launchpad.net/~openstack-xenapi), as well as meeting details? Thanks, Armando On Tue, Apr 24, 2012 at 3:32 PM, Alan Kavanagh alan.kavan...@ericsson.com wrote: Hi John +1 would be interested for monthly meeting. Time is ok. Alan From: openstack- bounces+alan.kavanagh=ericsson@lists.launchpad.net [mailto:openstack- bounces+alan.kavanagh=ericsson.com@lists.launchpad.n et] On Behalf Of John Garbutt Sent: April-23-12 1:21 PM To: openstack@lists.launchpad.net Subject: [Openstack] Regular XenAPI Meeting Hi, Are people keen for a XenAPI virt layer meetup on IRC every month? I have added a suggested time to the wiki, as a starting point: Monthly, second Wednesday at 17:00 UTC Does that seem a reasonable time for those that want to attend? It can be more frequent if we find that useful. I don't want to detract from the other meetings, but it would be good to keep all of us working on the XenAPI layer in regular contact. Cheers, 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 ___ 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] raw or qcow2
Joshua Harlow wrote: What changes would be needed to make qcow2 files work as snapshots? Some type of image dependency management in glance (and failure cases) and the corresponding dependency fetching in nova (and failure cases)? Might be something pretty useful to have, instead of forcing raw for snapshots? I think this is something that should be addressed in the new block storage project, and only incidentally in glance. Basically, glance can record the intent of X being based on snapshot Y, but building a volume X that is based on some copy of snapshot Y is best left to the block layer. Any solution expressed at the Glance layer is going to be biased towards doing the cloning too early. ___ 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] raw or qcow2
Ok, but forcing a new block storage project to have this feature, is that the right way? Maybe it will, just wondering. Glance seems to be the registry of images, so a natural progression is that it can maintain the image dependencies? This would allow the qcow2 image to pull the needed dependencies down to nova. On 4/24/12 4:44 PM, Caitlin Bestler caitlin.best...@nexenta.com wrote: Joshua Harlow wrote: What changes would be needed to make qcow2 files work as snapshots? Some type of image dependency management in glance (and failure cases) and the corresponding dependency fetching in nova (and failure cases)? Might be something pretty useful to have, instead of forcing raw for snapshots? I think this is something that should be addressed in the new block storage project, and only incidentally in glance. Basically, glance can record the intent of X being based on snapshot Y, but building a volume X that is based on some copy of snapshot Y is best left to the block layer. Any solution expressed at the Glance layer is going to be biased towards doing the cloning too early. ___ 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] Using Nova APIs from Javascript: possible?
Javascript *can* set custom headers, but only by using XMLHttpRequest. That cannot work cross-domain unless the appropriate CORS headers are set. Hence this issue :) On Apr 25, 2012 12:21 AM, Adam Young ayo...@redhat.com wrote: On 04/24/2012 10:19 AM, Nick Lothian wrote: JSONP is great, but won't work with POST requests. I don't quite understand what Due to the redirect nature of the auth system means, though. Sorry, I am working on a few things that are related. OpenID and various other systems have issues along these lines that are due to the fact that they are done with redirects. UI'll try to be clearer in the future. That actually works fine because the token is not in the header when it comes from Keystone. However, if you were to post toa web app that then needed to make your browser post to a remote system (which is where the same origin policy comes in to play) you need to set that Auth token into a custom header, and Javascript is forbidden to do that. Yes, the Javascript can say post to glance or some other openstack API server, but it can't set the X auth header with the token from Keystone in order to make the call authenticated. Nick On Tue, Apr 24, 2012 at 8:57 PM, Sandy Walsh sandy.wa...@rackspace.comwrote: Due to the redirect nature of the auth system we may need JSONP support for this to work. ___ 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 ___ 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] Using Nova APIs from Javascript: possible?
I actually like JSONP, but supporting it would be quite a substantial change to the APIs Adding CORS support is a relatively small change, and probably a more technically correct solution. It does have less browser support though. On Apr 25, 2012 4:01 AM, Tres Henry t...@treshenry.net wrote: Jsonp sucks (get only) but might be the best choice. That's generally how AWS supports these use cases, fwiw. On Apr 24, 2012, at 7:49 AM, Sandy Walsh sandy.wa...@rackspace.com wrote: On 04/24/2012 11:19 AM, Nick Lothian wrote: JSONP is great, but won't work with POST requests. Hmm, good point. I don't quite understand what Due to the redirect nature of the auth system means, though. If I use a custom Webkit browser allow cross domain XMLHttpRequests it works fine - I do a POST to /v2.0/tokens, get the token and then use that. What am I missing? The Auth system will give you a token and then a new management url where the actual commands are issued (the real Nova API endpoint). These are often two different systems (domains), so cross-site requests are mandatory. -S Nick On Tue, Apr 24, 2012 at 8:57 PM, Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com wrote: Due to the redirect nature of the auth system we may need JSONP support for this to work. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto: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 ___ 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] Using Nova APIs from Javascript: possible?
Yes, this will work if I know in advance what server I will be connecting
too.
However, it does remove the ability to support any cloud without
intervention on the serverside.
On Apr 25, 2012 2:46 AM, Joel Semar sema...@gmail.com wrote:
Nick,
I know you said 'serverless clients' but you have to be serving the js
from somewhere right?
If you are using nginx it can be as simple as:
location /nova/ {
proxy_pass: http://nova-api.trystack.org;
}
then you can POST to yourserver/nova/v.02/. from the browser
etc.
(it's just about as simple on apache but you'd have to look it up)
But then i guess this won't work for you if you are writing
some distributable component/plugin/library.
(sorry if you've already dismissed this option but i thought it worth a
shot since it has worked flawlessly for me in the past)
On Tue, Apr 24, 2012 at 9:49 AM, Sandy Walsh sandy.wa...@rackspace.comwrote:
On 04/24/2012 11:19 AM, Nick Lothian wrote:
JSONP is great, but won't work with POST requests.
Hmm, good point.
I don't quite understand what Due to the redirect nature of the auth
system means, though.
If I use a custom Webkit browser allow cross domain XMLHttpRequests it
works fine - I do a POST to /v2.0/tokens, get the token and then use
that. What am I missing?
The Auth system will give you a token and then a new management url
where the actual commands are issued (the real Nova API endpoint). These
are often two different systems (domains), so cross-site requests are
mandatory.
-S
Nick
On Tue, Apr 24, 2012 at 8:57 PM, Sandy Walsh sandy.wa...@rackspace.com
mailto:sandy.wa...@rackspace.com wrote:
Due to the redirect nature of the auth system we may need JSONP
support
for this to work.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
mailto: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
--
Cheers,
Joel
___
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] Using Nova APIs from Javascript: possible?
The solution until the webservice deliver that headers is:
Solution 1:
1. Put the webservice behind a remote or local proxy
2. Apply some a filter (decorator) for each response with the CORS headers
(in the proxy) in order to trick the browser
Solution 2:
Some time ago I tested it with Chrome (disabling security) and it worked
for me
Solution 3 (really dirty, but works):
Embedded Flash Proxy
On Wed, Apr 25, 2012 at 3:09 AM, Nick Lothian nick.loth...@gmail.comwrote:
Yes, this will work if I know in advance what server I will be connecting
too.
However, it does remove the ability to support any cloud without
intervention on the serverside.
On Apr 25, 2012 2:46 AM, Joel Semar sema...@gmail.com wrote:
Nick,
I know you said 'serverless clients' but you have to be serving the js
from somewhere right?
If you are using nginx it can be as simple as:
location /nova/ {
proxy_pass: http://nova-api.trystack.org;
}
then you can POST to yourserver/nova/v.02/. from the browser
etc.
(it's just about as simple on apache but you'd have to look it up)
But then i guess this won't work for you if you are writing
some distributable component/plugin/library.
(sorry if you've already dismissed this option but i thought it worth a
shot since it has worked flawlessly for me in the past)
On Tue, Apr 24, 2012 at 9:49 AM, Sandy Walsh
sandy.wa...@rackspace.comwrote:
On 04/24/2012 11:19 AM, Nick Lothian wrote:
JSONP is great, but won't work with POST requests.
Hmm, good point.
I don't quite understand what Due to the redirect nature of the auth
system means, though.
If I use a custom Webkit browser allow cross domain XMLHttpRequests
it
works fine - I do a POST to /v2.0/tokens, get the token and then use
that. What am I missing?
The Auth system will give you a token and then a new management url
where the actual commands are issued (the real Nova API endpoint). These
are often two different systems (domains), so cross-site requests are
mandatory.
-S
Nick
On Tue, Apr 24, 2012 at 8:57 PM, Sandy Walsh
sandy.wa...@rackspace.com
mailto:sandy.wa...@rackspace.com wrote:
Due to the redirect nature of the auth system we may need JSONP
support
for this to work.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
mailto: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
--
Cheers,
Joel
___
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
--
---
Luis Alberto Gervaso Martin
Woorea Solutions, S.L
CEO CTO
mobile: (+34) 627983344
luis@ luis.gerv...@gmail.comwoorea.es
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Using Nova APIs from Javascript: possible?
So, why such a focus on this? IMO both JSONP and CORS are way too early stage
to adopt and the security risks outweigh the rewards. Usually, I see people
doing this to enable mashups across separate providers.
Just curious why the focus/need is perceived in the community? If this is
really because of redirects then we probably have a broken model and/or
improper distribution of responsibilities.
Love to know if I'm missing a real use case. Can help fix model if it is
broken. Have much experience in this area.
IMO no solution should trick the browser.
Jan
On Apr 24, 2012, at 7:05 PM, Luis Gervaso l...@woorea.es wrote:
The solution until the webservice deliver that headers is:
Solution 1:
1. Put the webservice behind a remote or local proxy
2. Apply some a filter (decorator) for each response with the CORS headers
(in the proxy) in order to trick the browser
Solution 2:
Some time ago I tested it with Chrome (disabling security) and it worked for
me
Solution 3 (really dirty, but works):
Embedded Flash Proxy
On Wed, Apr 25, 2012 at 3:09 AM, Nick Lothian nick.loth...@gmail.com wrote:
Yes, this will work if I know in advance what server I will be connecting too.
However, it does remove the ability to support any cloud without intervention
on the serverside.
On Apr 25, 2012 2:46 AM, Joel Semar sema...@gmail.com wrote:
Nick,
I know you said 'serverless clients' but you have to be serving the js from
somewhere right?
If you are using nginx it can be as simple as:
location /nova/ {
proxy_pass: http://nova-api.trystack.org;
}
then you can POST to yourserver/nova/v.02/. from the browser
etc.
(it's just about as simple on apache but you'd have to look it up)
But then i guess this won't work for you if you are writing some
distributable component/plugin/library.
(sorry if you've already dismissed this option but i thought it worth a shot
since it has worked flawlessly for me in the past)
On Tue, Apr 24, 2012 at 9:49 AM, Sandy Walsh sandy.wa...@rackspace.com
wrote:
On 04/24/2012 11:19 AM, Nick Lothian wrote:
JSONP is great, but won't work with POST requests.
Hmm, good point.
I don't quite understand what Due to the redirect nature of the auth
system means, though.
If I use a custom Webkit browser allow cross domain XMLHttpRequests it
works fine - I do a POST to /v2.0/tokens, get the token and then use
that. What am I missing?
The Auth system will give you a token and then a new management url
where the actual commands are issued (the real Nova API endpoint). These
are often two different systems (domains), so cross-site requests are
mandatory.
-S
Nick
On Tue, Apr 24, 2012 at 8:57 PM, Sandy Walsh sandy.wa...@rackspace.com
mailto:sandy.wa...@rackspace.com wrote:
Due to the redirect nature of the auth system we may need JSONP support
for this to work.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
mailto: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
--
Cheers,
Joel
___
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
--
---
Luis Alberto Gervaso Martin
Woorea Solutions, S.L
CEO CTO
mobile: (+34) 627983344
l...@woorea.es
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack][Nova] Minimum required code coverage per file
On Apr 24, 2012, at 4:11 PM, Joe Gordon wrote: Hi All, I would like to propose a minimum required code coverage level per file in Nova. Say 80%. This would mean that any new feature/file should only be accepted if it has over 80% code coverage. Exceptions to this rule would be allowed for code that is covered by skipped tests (as long as 80% is reached when the tests are not skipped). I like the idea of looking at code coverage numbers. For any particular merge proposal, I'd also like to know whether it increases or decreases the overall code coverage of the project. I don't think we should gate on this, but it would be helpful for a reviewer to see that, especially for larger proposals. With 193 python files in nova/tests, Nova unit tests produce 85% overall code coverage (calculated with ./run_test.sh -c [1]). But 23% of files (125 files) have lower then 80% code coverage (30 tests skipped on my machine). Getting all files to hit the 80% code coverage mark should be one of the goals for Folsom. I would really like to see a visualization of the code coverage distribution, in order to help spot the outliers. Along these lines, there's been a lot of work in the software engineering research community about predicting which parts of the code are most likely to contain bugs (fault prone is a good keyword to find this stuff, e.g.: http://scholar.google.com/scholar?q=fault+prone, big names include Nachi Nagappan at MS Research and Elaine Weyuker, formerly of ATT Research). I would *love* to see some academic researchers try to apply those techniques to OpenStack to help guide QA activities by identifying which parts of the code should get more rigorous testing and review. Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com smime.p7s Description: S/MIME cryptographic signature ___ 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-poc] [Bug 983734] Re: Keystone fails badly if you miss one option
./etc/default_catalog.template is not a good default for template_file, I agree. But /etc/keystone/catalog.template or similar would be a fine default to include in the code. The tests would override the default As for error messages - I completely agree we should have good error handling like default_catalog.template not found None of this implies that we shouldn't have good defaults for options and instead require users to specify values for them -- You received this bug notification because you are a member of OpenStack Common Drivers, which is the registrant for openstack-common. https://bugs.launchpad.net/bugs/983734 Title: Keystone fails badly if you miss one option Status in OpenStack Identity (Keystone): Confirmed Status in openstack-common: Invalid Bug description: If you misspell or forget one option in keystone.conf (like template_file for TemplatedCatalog backend), Keystone will fail with misguiding critical failure (in my case, TypeError: coercing to Unicode: need string or buffer, NoneType found). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/983734/+subscriptions ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
