Re: [openstack-dev] [Heat] Proposing Thomas Spatzier for heat-core
+1 ! On 04/23/2014 02:43 AM, Zane Bitter wrote: Resending with [Heat] in the subject line. My bad. On 22/04/14 14:21, Zane Bitter wrote: I'd like to propose that we add Thomas Spatzier to the heat-core team. Thomas has been involved in and consistently contributing to the Heat community for around a year, since the time of the Havana design summit. His code reviews are of extremely high quality IMO, and he has been reviewing at a rate consistent with a member of the core team[1]. One thing worth addressing is that Thomas has only recently started expanding the focus of his reviews from HOT-related changes out into the rest of the code base. I don't see this as an obstacle - nobody is familiar with *all* of the code, and we trust core reviewers to know when we are qualified to give +2 and when we should limit ourselves to +1 - and as far as I know nobody else is bothered either. However, if you have strong feelings on this subject nobody will take it personally if you speak up :) Heat Core team members, please vote on this thread. A quick reminder of your options[2]: +1 - five of these are sufficient for acceptance 0 - abstention is always an option -1 - this acts as a veto cheers, Zane. [1] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt [2] https://wiki.openstack.org/wiki/Heat/CoreTeam#Adding_or_Removing_Members ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [MagnetoDB] Confusing Cassandra behavior
Hello everyone! Today I'm faced with unexpected Cassandra behavior. Please keep in mind that if you execute UPDATE query end set all fields to null (or empty collections for collection type) it can delete your record, but also it can only set values to null and keep record alive. It depends on how to record was created: using insert query or update query. Please take a look at reproduce steps here https://gist.github.com/dukhlov/11195881. FYI: Cassandra 2.0.7 has been released. As we know there were some fixes for condition operation and batch operations which are necessary for us. So It would be nice to update magnetodb devstack to use Cassandra 2.0.7 -- Best regards, Dmitriy Ukhlov Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][blueprint] Accelerate the booting process of a number of vms via VMThunder
For live migration, we use shared storage so I don't think it's quite the same as getting/putting image bits from/to arbitrary locations.With a good zero-copy transfer lib, live migration support can be extended to non-shared storage, or cross-datacenter. It's a kind ofvalue. task = image_api.copy(from_path_or_uri, to_path_or_uri) # do some other work copy_task_result = task.wait() +1 looks cool! how about zero-copying? At 2014-04-23 07:21:27,Jay Pipes jaypi...@gmail.com wrote: Hi Vincent, Zhi, Huiba, sorry for delayed response. See comments inline. On Tue, 2014-04-22 at 10:59 +0800, Sheng Bo Hou wrote: I actually support the idea Huiba has proposed, and I am thinking of how to optimize the large data transfer(for example, 100G in a short time) as well. I registered two blueprints in nova-specs, one is for an image upload plug-in to upload the image to glance(https://review.openstack.org/#/c/84671/), the other is a data transfer plug-in(https://review.openstack.org/#/c/87207/) for data migration among nova nodes. I would like to see other transfer protocols, like FTP, bitTorrent, p2p, etc, implemented for data transfer in OpenStack besides HTTP. Data transfer may have many use cases. I summarize them into two catalogs. Please feel free to comment on it. 1. The machines are located in one network, e.g. one domain, one cluster, etc. The characteristic is the machines can access each other directly via the IP addresses(VPN is beyond consideration). In this case, data can be transferred via iSCSI, NFS, and definitive zero-copy as Zhiyan mentioned. 2. The machines are located in different networks, e.g. two data centers, two firewalls, etc. The characteristic is the machines can not access each other directly via the IP addresses(VPN is beyond consideration). The machines are isolated, so they can not be connected with iSCSI, NFS, etc. In this case, data have to go via the protocols, like HTTP, FTP, p2p, etc. I am not sure whether zero-copy can work for this case. Zhiyan, please help me with this doubt. I guess for data transfer, including image downloading, image uploading, live migration, etc, OpenStack needs to taken into account the above two catalogs for data transfer. For live migration, we use shared storage so I don't think it's quite the same as getting/putting image bits from/to arbitrary locations. It is hard to say that one protocol is better than another, and one approach prevails another(BitTorrent is very cool, but if there is only one source and only one target, it would not be that faster than a direct FTP). The key is the use case(FYI:http://amigotechnotes.wordpress.com/2013/12/23/file-transmission-with-different-sharing-solution-on-nas/). Right, a good solution would allow for some flexibility via multiple transfer drivers. Jay Pipes has suggested we figure out a blueprint for a separate library dedicated to the data(byte) transfer, which may be put in oslo and used by any projects in need (Hoping Jay can come in:-)). Huiba, Zhiyan, everyone else, do you think we come up with a blueprint about the data transfer in oslo can work? Yes, so I believe the most appropriate solution is to create a library -- in oslo or a standalone library like taskflow -- that would offer a simple byte streaming library that could be used by nova.image to expose a neat and clean task-based API. Right now, there is a bunch of random image transfer code spread throughout nova.image and in each of the virt drivers there seems to be different re-implementations of similar functionality. I propose we clean all that up and have nova.image expose an API so that a virt driver could do something like this: from nova.image import api as image_api ... task = image_api.copy(from_path_or_uri, to_path_or_uri) # do some other work copy_task_result = task.wait() Within nova.image.api.copy(), we would use the aforementioned transfer library to move the image bits from the source to the destination using the most appropriate method. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Fwd: [MagnetoDB] Confusing Cassandra behavior
-- Forwarded message -- From: Dmitriy Ukhlov dukh...@mirantis.com Date: Tue, Apr 22, 2014 at 10:56 PM Subject: [openstack-dev][MagnetoDB] Confusing Cassandra behavior To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Hello everyone! Today I'm faced with unexpected Cassandra behavior. Please keep in mind that if you execute UPDATE query end set all fields to null (or empty collections for collection type) it can delete your record, but also it can only set values to null and keep record alive. It depends on how to record was created: using insert query or update query. Please take a look at reproduce steps here https://gist.github.com/dukhlov/11195881. FYI: Cassandra 2.0.7 has been released. As we know there were some fixes for condition operation and batch operations which are necessary for us. So It would be nice to update magnetodb devstack to use Cassandra 2.0.7 -- Best regards, Dmitriy Ukhlov Mirantis Inc. -- Best regards, Dmitriy Ukhlov Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?
Excerpts from Jay Pipes' jaypi...@gmail.com message on 23/04/2014 01:43:42: On Tue, 2014-04-22 at 13:14 +0200, Thomas Spatzier wrote: snip * Identify key/value pairs that are relied on by all of Nova to be a specific key and value combination, and make these things actual real attributes on some object model -- since that is a much greater guard for the schema of an object and enables greater performance by allowing both type safety of the underlying data and removes the need to search by both a key and a value. Makes a lot of sense to me. So are you suggesting to have a set of well-defined property names per resource but still store them in the properties name-value map? Or would you rather make those part of the resource schema? I'd rather have the common ones in the resource schema itself, since that is, IMHO, better practice for enforcing consistency and type safety. +1, that's what I would prefer as well, but I wanted to make sure you mean the same. BTW, here is a use case in the context of which we have been thinking about that topic: we opened a BP for allowing constraint based selection of images for Heat templates, i.e. instead of saying something like (using pseudo template language) image ID must be in [fedora-19-x86_64, fedora-20-x86_64] say something like architecture must be x86_64, distro must be fedora, version must be between 19 and 20 (see also [1]). This of course would require the existence of well-defined properties in glance so an image selection query in Heat can work. Zactly :) As long as properties are just custom properties, we would require a lot of discipline from every to maintain properties correctly. Yep, and you'd need to keep in sync with the code in Nova that currently maintains these properties. :) Best, -jay And the implementation in Heat could be kind of tolerant, i.e. give it a try, and if the query fails just fail the stack creation. But if this is likely to happen in 90% of all environments, the usefulness is questionable. Here is a link to the BP I mentioned: [1] https://blueprints.launchpad.net/heat/+spec/constraint-based- flavors-and-images Regards, Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo] [Ironic] Can we change rpc_thread_pool_size default value?
Fwiw, we've seen this with nova-scheduler as well. I think the default pool size is too large in general. The problem that I've seen stems from the fact that DB calls all block and you can easily get a stack of 64 workers all waiting to do DB calls. And it happens to work out such that none of the rpc pool threads return before all run their DB calls. This is compounded by the explicit yield we have for every DB call in nova. Anyway, this means that all of the workers are tied up for quite a while. Since nova casts to the scheduler, it doesn't impact the API much. But if you were waiting on an RPC response, you could be waiting a while. Ironic does a lot of RPC calls. I don't think we know the exact behavior in Ironic, but I'm assuming it's something similar. If all rpc pool threads are essentially stuck until roughly the same time, you end up with API hangs. But we're also seeing periodic task run delays as well. It must be getting stuck behind a lot of the rpc worker threads such that lowering the number of threads helps considerably. Given DB calls all block the process right now, there's really not much advantage to a larger pool size. 64 is too much, IMO. It would make more sense if there was more IO that could be parallelized. That didn't answer your question. I've been meaning to ask the same one since we discovered this. :) - Chris On Apr 22, 2014, at 3:54 PM, Devananda van der Veen devananda@gmail.com wrote: Hi! When a project is using oslo.messaging, how can we change our default rpc_thread_pool_size? --- Background Ironic has hit a bug where a flood of API requests can deplete the RPC worker pool on the other end and cause things to break in very bad ways. Apparently, nova-conductor hit something similar a while back too. There've been a few long discussions on IRC about it, tracked partially here: https://bugs.launchpad.net/ironic/+bug/1308680 tldr; a way we can fix this is to set the rpc_thread_pool_size very small (eg, 4) and keep our conductor.worker_pool size near its current value (eg, 64). I'd like these to be the default option values, rather than require every user to change the rpc_thread_pool_size in their local ironic.conf file. We're also about to switch from the RPC module in oslo-incubator to using the oslo.messaging library. Why are these related? Because it looks impossible for us to change the default for this option from within Ironic, because the option is registered when EventletExecutor is instantaited (rather than loaded). https://github.com/openstack/oslo.messaging/blob/master/oslo/messaging/_executors/impl_eventlet.py#L76 Thanks, Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo] [Ironic] Can we change rpc_thread_pool_size default value?
On Tue, 2014-04-22 at 15:54 -0700, Devananda van der Veen wrote: Hi! When a project is using oslo.messaging, how can we change our default rpc_thread_pool_size? --- Background Ironic has hit a bug where a flood of API requests can deplete the RPC worker pool on the other end and cause things to break in very bad ways. Apparently, nova-conductor hit something similar a while back too. There've been a few long discussions on IRC about it, tracked partially here: https://bugs.launchpad.net/ironic/+bug/1308680 tldr; a way we can fix this is to set the rpc_thread_pool_size very small (eg, 4) and keep our conductor.worker_pool size near its current value (eg, 64). I'd like these to be the default option values, rather than require every user to change the rpc_thread_pool_size in their local ironic.conf file. We're also about to switch from the RPC module in oslo-incubator to using the oslo.messaging library. Why are these related? Because it looks impossible for us to change the default for this option from within Ironic, because the option is registered when EventletExecutor is instantaited (rather than loaded). https://github.com/openstack/oslo.messaging/blob/master/oslo/messaging/_executors/impl_eventlet.py#L76 It may have been possible for Ironic to set its own default before oslo.messaging, but it wouldn't have been recommended because there's no explicit API for doing so. With oslo.messaging, we have a set_transport_defaults() which shows how we'd approach adding this capability. The question comes down to whether this really is a situation where we need per-application defaults or just that the current defaults are screwed up. If the latter, I'd much rather just change the defaults. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer]support direct alarm_evaluator db access
Hi Nihongi, Thanks for your attention. I have tried to commit patches for this issue. Gerrit topic:https://review.openstack.org/#q,topic:bp/direct-alarm-evaluator-db-access,n,z https://review.openstack.org/#q,topic:bp/direct-alarm-evaluator-db-access,n,z hope it can be helpful for you, and any advice is appreciated:) ? 2014/4/21 18:01, Nobuyoshi Nihongi ??: Hi Liu sheng, We're also investigating alarm_evaluator performance. We observed that alarm_evaluator spends half of the time for calling ceilometerclient while evaluating alarms. Allowing alarm_evaluator directly access db will greatly improve the performance if you have many alarms. Best regards, Nihongi From: liusheng liusheng1...@126.com To: openstack-dev@lists.openstack.org Date: Tue, 15 Apr 2014 15:26:58 +0800 Subject: [openstack-dev] [ceilometer]support direct alarm_evaluator db access Hi there, Currently,alarm_evaluator invoke ceilometerclient to get all assigned alarms. and then, evaluate per alarm by get statistics, which will also call ceilometerclient. this process is: evaluator--ceilometerclient--ceilometer API--db. If we use default option of evaluation_interval (60s), and if we have many alarms, alarm_evaluator will frequently invoke ceilometerclient and will produce many http requests per minute. That is inefficient,it affect the performance of ceilometer(data collection, data query, e.g.). The better way is allowing alarm_evaluator access db directely. Should the related codes of alarm-evaluator need a refactor? Can you provide your thoughts about this? I have registered a related blueprint: https://blueprints.launchpad.net/ceilometer/+spec/direct-alarm-evaluator-db- access Best regards Liu sheng ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Nobuyoshi Nihongi NTT Software Innovation Center Phone: +81 422 59 4880 E-mail: nihongi.nobuyo...@lab.ntt.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] 答复: 答复: 答复: [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?
-邮件原件- 发件人: Jay Pipes [mailto:jaypi...@gmail.com] 发送时间: 2014年4月23日 7:41 收件人: openstack-dev@lists.openstack.org 主题: Re: [openstack-dev] 答复: 答复: [Nova][Neutron][Cinder][Heat]Should we support tags for os resources? On Tue, 2014-04-22 at 02:02 +, Huangtianhua wrote: Thanks very much. I have register the blueprints for nova. https://blueprints.launchpad.net/nova/+spec/add-tags-for-os-resources The simple plan is: 1. Add the tags api (create tags/delete tags/describe tags) for v3 api 2. Change the implement for instance from “metadata” to “tags” Your suggestions? Hi again, The Nova blueprint process has changed. We now use a Gerrit repository to submit, review, and approve blueprint specifications. Please see here for information on how to submit a spec for the proposed blueprint: https://wiki.openstack.org/wiki/Blueprints#Nova Thanks very much. I will submit a spec soon. Thank you! -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] [Nova] BP about usb-passthrough RE: Change in openstack/nova-specs[master]: Support specify USB controller for USB-passthrough
Hi Thanks for your reply. By now many people think USB-redirection is a valuable function, so I wrote a BP for it in https://blueprints.launchpad.net/nova/+spec/usb-redirection. I will write a detailed spec for it a little later, hope you can review it too. For use cases of USB-passthrough, we indeed have many requirements from customers in private cloud. I think Openstack may also been used for private cloud solution, so if we provide USB-passthrough as an optional function may also have some values. Welcome for any and more advices. Thanks -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Wednesday, April 23, 2014 1:23 PM To: Yuanjing (D) Cc: Daniel Berrange; Joe Gordon; openstack-dev@lists.openstack.org Subject: Re: [Openstack] [Nova] BP about usb-passthrough RE: Change in openstack/nova-specs[master]: Support specify USB controller for USB-passthrough On Wed, 2014-04-23 at 02:01 +, Yuanjing (D) wrote: Hi I have proposed three BPs about usb-passthrough. 1. Usb-passthrough is the core function I want to provide which is in https://review.openstack.org/#/c/86404/. 2. The function of specify usb controller for usb-passthrough is for refine the use of Usb-passthrough, which is in https://review.openstack.org/#/c/88337/. 3. The function of specify usb controller is the prerequisite of specify usb controller for usb-passthrough which is in https://review.openstack.org/#/c/88334. The backgrounds are: I want to make a detailed explanation about why I suggest to provide this function. We provide VDI(Virtual Desktop) and server virtualization solutions for customers, our customers have strong requirements for using USB devices. The typical use cases and our solutions are described as below: 1.In VDI solution, customers want to use local USB printers or USB scanners with TC(Thin-Client), because remote desktop protocol like ICA have already support USB-redirection, so customers only need to attach USB device to TC, the protocol can map USB device to VM. 2. In virtualization solution, when starting or restarting some business-critical applications, a connected USB-KEY is needed for authentication, some applications even need a daily authentication by USB-KEY. we suggest the following solutions: (1) Using physical 'USB-HUB' box and technology of USB-redirection over TCP/IP. Customers need to buy USB-HUB and install software in guest os, the software helps redirecting USB device to VM. (2) Using USB-Passthrough and USB hot-plug functions provided by our virtualization software. The end users(normally application or system administrators) insert USB devices to host that containing the VM, then can see USB device list in portal and choose USB device to attach. This solution has advantages that 1. It doesn't need additional physical devices 2. It doesn't need a special server to run spice client for USB-Redirection 3. Business-critical applications commonly need stable and long-standing USB-KEY to attach, USB-Passthrough maybe more stable than USB-Redirection over TCP/IP or remote desktop protocol. Hi Jing, thx for your above email. I think of cloud computing as providing a way for users to *not* have to manage hardware -- they are free to work with virtual servers and then throw them away when not needed or get a new one quickly if something bad happens. I'm afraid I don't see any relation to what I think of as cloud in the second use case you list above. I don't think having a system administrator running around to a physical machine in a datacenter and plugging in a USB key is a cloudy activity. For the first use case, however, where the user inserts a USB device on the thin client and USB redirection allows the VM to read/write to the USB device on the thin client, I certainly see a good use case there. However, I am uncertain which of your blueprints deals exclusively with the first use case. Could you advise on that? Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Proposing Thomas Spatzier for heat-core
Hi all, I just realized during a review that I see a couple of more options, so this poll seems to be thru already ;-) Thank you all for your support! I'm glad to be part of this great team! Cheers, Thomas Liang Chen cbjc...@linux.vnet.ibm.com wrote on 23/04/2014 07:53:07: From: Liang Chen cbjc...@linux.vnet.ibm.com To: openstack-dev@lists.openstack.org Date: 23/04/2014 07:56 Subject: Re: [openstack-dev] [Heat] Proposing Thomas Spatzier for heat-core +1 ! On 04/23/2014 02:43 AM, Zane Bitter wrote: Resending with [Heat] in the subject line. My bad. On 22/04/14 14:21, Zane Bitter wrote: I'd like to propose that we add Thomas Spatzier to the heat-core team. Thomas has been involved in and consistently contributing to the Heat community for around a year, since the time of the Havana design summit. His code reviews are of extremely high quality IMO, and he has been reviewing at a rate consistent with a member of the core team[1]. One thing worth addressing is that Thomas has only recently started expanding the focus of his reviews from HOT-related changes out into the rest of the code base. I don't see this as an obstacle - nobody is familiar with *all* of the code, and we trust core reviewers to know when we are qualified to give +2 and when we should limit ourselves to +1 - and as far as I know nobody else is bothered either. However, if you have strong feelings on this subject nobody will take it personally if you speak up :) Heat Core team members, please vote on this thread. A quick reminder of your options[2]: +1 - five of these are sufficient for acceptance 0 - abstention is always an option -1 - this acts as a veto cheers, Zane. [1] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt [2] https://wiki.openstack.org/wiki/Heat/CoreTeam#Adding_or_Removing_Members ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Service VMs
Hi. Keyle, thank you for starting this discussion to make progress. On Mon, Apr 21, 2014 at 08:41:19PM -0500, Kyle Mestery mest...@noironetworks.com wrote: On Mon, Apr 21, 2014 at 4:20 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Mon, Apr 21, 2014 at 3:07 PM, Kyle Mestery mest...@noironetworks.com wrote: For the upcoming Summit there are 3 sessions filed around Service VMs in Neutron. After discussing this with a few different people, I'd like to propose the idea that the Service VM work be moved out of Neutron and into it's own project on stackforge. There are a few reasons for this: How long do you anticipate the project needing to live on stackforge before it can move to a place where we can introduce symmetric gating with the projects that use it? To be honest, I'm not sure how long it will take. We will see after the summit. At this point, my feeling is - before the summit, preliminary discussion, preparation for the summit - discuss at the summit (including project name?) - after the summit, create its own project on stackforge and start its own activity like weekly IRC meeting. import neutron code repo as the first code base, and cleaning/stripping it up and so on. What do you think? The patches for this (look at the BP here [1]) have been in review for a while now as WIP. I think it's reasonable to expect that moving this to stackforge would let the authors and others interested collaborate faster. I expect this would take a cycle on stackforge before we could talk about other projects using this. But honestly, that's a better question for Isaku and Bob. In fact, this is not the first time that such opinion is claimed. But this is the first time to get much feedback. It's good timing to give it a consideration. Just to make it clear, the session slot will be allocated to discuss on this? At least it would be valuable to share the current status and to discuss on its future direction, and which part will be separated out and which part will remain in Neutron. Who is going to drive the development work? For that, I'm thinking Isaku and Bob (copied above) would be the ones driving it. But anyone else who is interested should feel free to jump in as well. I'm willing to take the responsibility (and to share it with Bob). Also others to help are very welcome. thanks, Thanks, Kyle [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms Doug 1. There is nothing Neutron specific about service VMs. 2. Service VMs can perform services for other OpenStack projects. 3. The code is quite large and may be better served being inside it's own project. Moving the work out of Neutron and into it's own project would allow for separate velocity for this project, and for code to be shared for the Service VM work for things other than Neutron services. I'm starting this email thread now to get people's feedback on this and see what comments other have. I've specifically copied Isaku and Bob, who both filed summit sessions on this and have done a lot of work in this area to date. Thanks, Kyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer]
Hi,please help me to fix an error in Ceilometer: Error communicating with http://controller:8777 [Errno 111] Connection refused ***my ceilometer.conf file is: [DEFAULT] # # Options defined in ceilometer.middleware # # Exchanges name to listen for notifications (multi valued) #http_control_exchanges=nova #http_control_exchanges=glance #http_control_exchanges=neutron #http_control_exchanges=cinder # # Options defined in ceilometer.pipeline # # Configuration file for pipeline definition (string value) #pipeline_cfg_file=pipeline.yaml # # Options defined in ceilometer.sample # # Source for samples emited on this instance (string value) #sample_source=openstack # # Options defined in ceilometer.api.app # # The strategy to use for auth: noauth or keystone. (string # value) auth_strategy=keystone # Deploy the deprecated v1 API. (boolean value) #enable_v1_api=true # # Options defined in ceilometer.compute.notifications # # Exchange name for Nova notifications (string value) nova_control_exchange=nova # # Options defined in ceilometer.compute.pollsters.util # # list of metadata prefixes reserved for metering use (list # value) #reserved_metadata_namespace=metering. # limit on length of reserved metadata values (integer value) #reserved_metadata_length=256 # # Options defined in ceilometer.compute.virt.inspector # # Inspector to use for inspecting the hypervisor layer (string # value) #hypervisor_inspector=libvirt # # Options defined in ceilometer.compute.virt.libvirt.inspector # # Libvirt domain type (valid options are: kvm, lxc, qemu, uml, # xen) (string value) #libvirt_type=kvm # Override the default libvirt URI (which is dependent on # libvirt_type) (string value) #libvirt_uri= # # Options defined in ceilometer.image.notifications # # Exchange name for Glance notifications (string value) #glance_control_exchange=glance # # Options defined in ceilometer.network.notifications # # Exchange name for Neutron notifications (string value) #neutron_control_exchange=neutron # # Options defined in ceilometer.objectstore.swift # # Swift reseller prefix. Must be on par with reseller_prefix # in proxy-server.conf. (string value) #reseller_prefix=AUTH_ # # Options defined in ceilometer.openstack.common.db.sqlalchemy.session # # the filename to use with sqlite (string value) sqlite_db=ceilometer.sqlite # If true, use synchronous mode for sqlite (boolean value) #sqlite_synchronous=true # # Options defined in ceilometer.openstack.common.eventlet_backdoor # # Enable eventlet backdoor. Acceptable values are 0, port, # and start:end, where 0 results in listening on a random # tcp port number; port results in listening on the # specified port number (and not enabling backdoor if that # port is in use); and start:end results in listening on # the smallest unused port number within the specified range # of port numbers. The chosen port is displayed in the # service's log file. (string value) #backdoor_port=None # # Options defined in ceilometer.openstack.common.lockutils # # Whether to disable inter-process locks (boolean value) #disable_process_locking=false # Directory to use for lock files. (string value) #lock_path=None # # Options defined in ceilometer.openstack.common.log # # Print debugging output (set logging level to DEBUG instead # of default WARNING level). (boolean value) #debug=false # Print more verbose output (set logging level to INFO instead # of default WARNING level). (boolean value) verbose=true # Log output to standard error (boolean value) #use_stderr=true # format string to use for log messages with context (string # value) #logging_context_format_string=%(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [%(request_id)s %(user)s %(tenant)s] %(instance)s%(message)s # format string to use for log messages without context # (string value) #logging_default_format_string=%(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [-] %(instance)s%(message)s # data to append to log format when level is DEBUG (string # value) #logging_debug_format_suffix=%(funcName)s %(pathname)s:%(lineno)d # prefix each line of exception output with this format # (string value) #logging_exception_prefix=%(asctime)s.%(msecs)03d %(process)d TRACE %(name)s %(instance)s # list of logger=LEVEL pairs (list value) #default_log_levels=amqplib=WARN,sqlalchemy=WARN,boto=WARN,suds=INFO,keystone=INFO,eventlet.wsgi.server=WARN # publish error events (boolean value) #publish_errors=false # make deprecations fatal (boolean value) #fatal_deprecations=false # If an instance is passed with the log message, format it # like this (string value) #instance_format=[instance: %(uuid)s] # If an instance UUID is passed with the log message, format # it like this (string value) #instance_uuid_format=[instance: %(uuid)s] # If this option is specified, the logging configuration file # specified is used and overrides any other logging options # specified. Please see the Python logging
Re: [openstack-dev] [TripleO][Summit] Topic review for Atlanta
On 22/04/14 01:01, Robert Collins wrote: I've pulled the summit talks into an etherpad (https://etherpad.openstack.org/p/tripleo-icehouse-summit) - btw, who can review these within the system itself? Anyhow - please put comments in the etherpad and help select the sessions we'll do during the summit. I've allocated myself 6 votes and distributed them to the proposed sessions (on the etherpad), might be a good idea for others to do the same and give you an idea of where the interest lies. I think we need to ensure reasonable coverage for: - CI - Finishing HA - Upgrades - Tuskar which arguably leaves just 2 slots for $whatever It seems to me we should focus on things where either: - we need to build basic consensus - crowdsourcing is at play I say that because we have many things being tackled and face time in the summit is precious - things that are straight engineering are not a particularly effective use of the time of a room with 30-80 people in it. -Rob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Undercloud Ceilometer
Hi Neal, thanks for response. So I would see it as UNDERCLOUD_USE_UI (TripleO UI can be placed only to Undercloud) And for overcloud: OVERCLOUD_USE_UI and OVERCLOUD_USE_CEILOMETER, cause in overcloud users might not want UI, but only data for billing. Does it sound reasonable? On 04/22/2014 06:23 PM, Neal, Phil wrote: From: Ladislav Smola [mailto:lsm...@redhat.com] Sent: Wednesday, April 16, 2014 8:37 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [TripleO] [Tuskar] Undercloud Ceilometer No response so far, but -1 on the image element for making Ceilometer optional. Sorry for the delayed response, Ladislov. It turns out that the mailing list was filtering out these TripleO mails for me. Let me add a little context to that -1: given that a TripleO user may not want to enable a UI layer at the undercloud level (there's a use case for using the undercloud solely for spinning up the overcloud), I think we want to support as small a footprint as possible. OK, so what about having variable in devtest_variables: USE_TRIPLEO_UI. I like this approach better...in fact I will look into adding something similar into the changes I'm making to enable Ceilometer by default in the overcloud control node: https://review.openstack.org/#/c/89625/1 It would add Undercloud Ceilometer, Tuskar-UI and Horizon. And Overcloud SNMPd. Defaulted to USE_TRIPLEO_UI=1 so we have UI stuff in CI. How does it sound? Perhaps specify something like UNDERCLOUD_USE_TRIPLEO_UI to be more specific on where this will be deployed. On 04/14/2014 01:31 PM, Ladislav Smola wrote: Hello, I am planning to add Ceilometer to Undercloud as default. Since Tuskar-UI uses it as primary source of metering samples and Tuskar should be in Undercloud as default, it made sense to me. So is my assumption correct or there are some reasons not to do this? Here are the reviews, that are adding working Undercloud Ceilometer: https://review.openstack.org/#/c/86915/ https://review.openstack.org/#/c/86917/ (depends on the template change) https://review.openstack.org/#/c/87215/ Configuration for automatic obtaining of stats from all Overcloud nodes via. SNMP will follow soon. Thanks, Ladislav ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Performance tests of ceilometer-collector and ceilometer-api with different backends
Hi Ilya, Interresting, thanks for sharing. So the quick conclusion to your numbers seems indicated that mongodb is more efficient for both reading and writing, except for 2 cases for retrieving data (meters and resouces listing) .. However for the reading operations, it's should be confirmed (or precised) where the time is really spent, would be interresting to compute the distribution of times spent by each layer : backend - api - cli .. similarly to what you did for collector by custom logging (or by instrumentation..) To add additional use cases (and to be more relevant) it will be good to use queries executed by billing systems or the alarm evaluator aka filtering a limited subsets of samples (by resource and/or user and/or tenant) .. to see the numbers without retrieving ten of thousands of samples. btw, others indicators should help to give a good picture, I see for now: errors rate, queue lenght (rabbit), returned samples|meters|resources by API calls, missing samples (after the populating) and some system metrics also. what was the caracteristics of serveurs used for these load test? my two cents. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron] Nova-network to Neutron migration: issues with libvirt
Very interesting topic! +1 Salvatore It would be nice to have an etherpad to share the information and organize a plan. This way it would be easier for interested people to join. Rossella On 04/23/2014 12:57 AM, Salvatore Orlando wrote: It's great to see that there is activity on the launchpad blueprint as well. From what I heard Oleg should have already translated the various discussion into a list of functional requirements (or something like that). If that is correct, it might be a good idea to share them with relevant stakeholders (operators and developers), define an actionable plan for Juno, and then distribute tasks. It would be a shame if it turns out several contributors are working on this topic independently. Salvatore On 22 April 2014 16:27, Jesse Pretorius jesse.pretor...@gmail.com mailto:jesse.pretor...@gmail.com wrote: On 22 April 2014 14:58, Salvatore Orlando sorla...@nicira.com mailto:sorla...@nicira.com wrote: From previous requirements discussions, There's a track record of discussions on the whiteboard here: https://blueprints.launchpad.net/neutron/+spec/nova-to-quantum-upgrade ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [MagnetoDB] Confusing Cassandra behavior
Hi Dmitriy, I have taken a look and found out that cassandra-cli output after UPDATE and INSERT operation is different, On first update it is update test SET value=null where id='1'; [default@test] list test; --- RowKey: 1 On first insert [default@test] list test; --- RowKey: 1 = (name=, value=, timestamp=1398166276501000) On Wed, Apr 23, 2014 at 8:56 AM, Dmitriy Ukhlov dukh...@mirantis.comwrote: Hello everyone! Today I'm faced with unexpected Cassandra behavior. Please keep in mind that if you execute UPDATE query end set all fields to null (or empty collections for collection type) it can delete your record, but also it can only set values to null and keep record alive. It depends on how to record was created: using insert query or update query. Please take a look at reproduce steps here https://gist.github.com/dukhlov/11195881. FYI: Cassandra 2.0.7 has been released. As we know there were some fixes for condition operation and batch operations which are necessary for us. So It would be nice to update magnetodb devstack to use Cassandra 2.0.7 -- Best regards, Dmitriy Ukhlov Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] [qa] EC2 status and call for assistance
I've spent a couple of days getting to the bottom of: Bug 1302774 - Failed to detach volume because of volume not found error prevents vm teardown This is an ec2 specific failure path, which mostly looks like a combination of a not very good test case and the EC2 code in nova collapsing the volume states in a way that seems completely incorrect based on what I can read on what's expected from this call. However, these are symptoms of a bigger issue. The EC2 paths in Nova are old, fragile, and error prone. The test coverage for these paths is minimal, and largely hasn't evolved in the last year. The last substantial addition to the EC2 tests in Tempest was by Burt Holtzman in July 2013, Burt has also been contributing to the Nova side, but beyond Burt, there basically aren't contributors right now. I really don't like shipping code in Nova that we know isn't good. With very few contributions in this code though, it's defacto, if not officially, deprecated. I'd like to see if there are any more people interested in keeping these interfaces functional (by contributing both on the nova and tempest sides). If so, great! If we get to the end of Juno in the current state, I think we need to consider actually deprecating the EC2 support in Nova. Because I'm pretty sure what we have today actually only works if you are using boto on the client side, and doesn't really look like EC2 at any real level of inspection. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [MagnetoDB] Confusing Cassandra behavior
Sorry, the previous message has been mistakenly sent.
So,
I have taken a look and found out that cassandra-cli output after UPDATE
and INSERT operation is different,
On first update it is
update test SET value=null where id='1';
[default@test] list test;
---
RowKey: 1
On first insert
insert into test (id, value) VALUES('1', null);
[default@test] list test;
---
RowKey: 1
= (name=, value=, timestamp=1398166276501000)
It seems thous operations are handled in different ways in CQL part or
something.
I had no chance to look closer today, but hope it helps.
About Cassandra version update, I think it is time and we have to do it.
For now I've filed BP for that
https://blueprints.launchpad.net/magnetodb/+spec/update-cassandra-to-2.0.7,
let us discuss it.
With best regards,
Ilya Sviridov
On Wed, Apr 23, 2014 at 2:41 PM, Ilya Sviridov isviri...@mirantis.comwrote:
Hi Dmitriy,
I have taken a look and found out that cassandra-cli output after UPDATE
and INSERT operation is different,
On first update it is
update test SET value=null where id='1';
[default@test] list test;
---
RowKey: 1
On first insert
[default@test] list test;
---
RowKey: 1
= (name=, value=, timestamp=1398166276501000)
On Wed, Apr 23, 2014 at 8:56 AM, Dmitriy Ukhlov dukh...@mirantis.comwrote:
Hello everyone!
Today I'm faced with unexpected Cassandra behavior. Please keep in mind
that if you execute UPDATE query end set all fields to null (or empty
collections for collection type) it can delete your record, but also it can
only set values to null and keep record alive. It depends on how to record
was created: using insert query or update query. Please take a look at
reproduce steps here https://gist.github.com/dukhlov/11195881.
FYI: Cassandra 2.0.7 has been released. As we know there were some fixes
for condition operation and batch operations which are necessary for us. So
It would be nice to update magnetodb devstack to use Cassandra 2.0.7
--
Best regards,
Dmitriy Ukhlov
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] having trouble with tox
Hi, I'm having trouble with tox to run unit tests of Ceilometer. I run devstack on Ubuntu13.10 which is running as a Guest OS in VirtualBox. Ceilometer commit id is e5b7606eaa94033256eb1aca5f6a6eed4f9e54a0. The VM is connecting to the Internet via proxy server. I'm using tox 1.6.1 instead of 1.7.1 to avoid bug [1]. I didn't make any changes in tox.ini from default settings. I was following the instruction [2]. When I typed the following command; $ tox -e py27,pep8 I didn't get any response for more than 2 hours. Then I found the following message in /opt/stack/ceilometer/.tox/py27/ log/py27-1.log. Actually, the message was stopping halfway. - : Downloading/unpacking jsonschema=2.0.0,3.0.0 (from -r /opt/stack/ ceilometer/requirements.txt (line 10)) Storing download in cache at ./.tox/_download/https%3A%2F%2Fpypi. python.org%2Fpackages%2Fsource%2Fj%2Fjsonschema%2Fjsonschema-2.3.0.tar. gz Running s - After that, I terminated tox with Ctrl+C and found the whole message as follows. - : Downloading/unpacking oslo.config=1.2.0 (from -r /opt/stack/ceilometer/ requirements.txt (line 15)) Storing download in cache at ./.tox/_download/https%3A%2F%2Fpypi. python.org%2Fpackages%2Fsource%2Fo%2Foslo.config%2Foslo.config-1.3.0.tar. gz Running setup.py egg_info for package oslo.config Cleaning up... Operation cancelled by user Storing complete log in /home/openstack/.pip/pip.log - Any advice or information would be greatly appreciated. [1]:https://bugs.launchpad.net/openstack-ci/+bug/1274135 [2]:http://docs.openstack.org/developer/ceilometer/contributing/source.html#running-the-tests Best regards, Nihongi -- Nobuyoshi Nihongi NTT Software Innovation Center Phone: +81 422 59 4880 E-mail: nihongi.nobuyo...@lab.ntt.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer]
Hi, seems your ceilo api is either not started or you're using a bad hostname (controller) first you must check ceilo api log to valid that the service is well started. from where are you using the ceilo cli (I guess you use the cli)? is the controller is accessible from here? , try to ping controller and telnet controler 8777 to confirm. .. otherwise .. do you have a http proxy setted ? good luck 2014-04-23 11:50 GMT+02:00 Hachem Chraiti hachem...@gmail.com: Hi,please help me to fix an error in Ceilometer: Error communicating with http://controller:8777 [Errno 111] Connection refused ***my ceilometer.conf file is: [DEFAULT] # # Options defined in ceilometer.middleware # # Exchanges name to listen for notifications (multi valued) #http_control_exchanges=nova #http_control_exchanges=glance #http_control_exchanges=neutron #http_control_exchanges=cinder # # Options defined in ceilometer.pipeline # # Configuration file for pipeline definition (string value) #pipeline_cfg_file=pipeline.yaml # # Options defined in ceilometer.sample # # Source for samples emited on this instance (string value) #sample_source=openstack # # Options defined in ceilometer.api.app # # The strategy to use for auth: noauth or keystone. (string # value) auth_strategy=keystone # Deploy the deprecated v1 API. (boolean value) #enable_v1_api=true # # Options defined in ceilometer.compute.notifications # # Exchange name for Nova notifications (string value) nova_control_exchange=nova # # Options defined in ceilometer.compute.pollsters.util # # list of metadata prefixes reserved for metering use (list # value) #reserved_metadata_namespace=metering. # limit on length of reserved metadata values (integer value) #reserved_metadata_length=256 # # Options defined in ceilometer.compute.virt.inspector # # Inspector to use for inspecting the hypervisor layer (string # value) #hypervisor_inspector=libvirt # # Options defined in ceilometer.compute.virt.libvirt.inspector # # Libvirt domain type (valid options are: kvm, lxc, qemu, uml, # xen) (string value) #libvirt_type=kvm # Override the default libvirt URI (which is dependent on # libvirt_type) (string value) #libvirt_uri= # # Options defined in ceilometer.image.notifications # # Exchange name for Glance notifications (string value) #glance_control_exchange=glance # # Options defined in ceilometer.network.notifications # # Exchange name for Neutron notifications (string value) #neutron_control_exchange=neutron # # Options defined in ceilometer.objectstore.swift # # Swift reseller prefix. Must be on par with reseller_prefix # in proxy-server.conf. (string value) #reseller_prefix=AUTH_ # # Options defined in ceilometer.openstack.common.db.sqlalchemy.session # # the filename to use with sqlite (string value) sqlite_db=ceilometer.sqlite # If true, use synchronous mode for sqlite (boolean value) #sqlite_synchronous=true # # Options defined in ceilometer.openstack.common.eventlet_backdoor # # Enable eventlet backdoor. Acceptable values are 0, port, # and start:end, where 0 results in listening on a random # tcp port number; port results in listening on the # specified port number (and not enabling backdoor if that # port is in use); and start:end results in listening on # the smallest unused port number within the specified range # of port numbers. The chosen port is displayed in the # service's log file. (string value) #backdoor_port=None # # Options defined in ceilometer.openstack.common.lockutils # # Whether to disable inter-process locks (boolean value) #disable_process_locking=false # Directory to use for lock files. (string value) #lock_path=None # # Options defined in ceilometer.openstack.common.log # # Print debugging output (set logging level to DEBUG instead # of default WARNING level). (boolean value) #debug=false # Print more verbose output (set logging level to INFO instead # of default WARNING level). (boolean value) verbose=true # Log output to standard error (boolean value) #use_stderr=true # format string to use for log messages with context (string # value) #logging_context_format_string=%(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [%(request_id)s %(user)s %(tenant)s] %(instance)s%(message)s # format string to use for log messages without context # (string value) #logging_default_format_string=%(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [-] %(instance)s%(message)s # data to append to log format when level is DEBUG (string # value) #logging_debug_format_suffix=%(funcName)s %(pathname)s:%(lineno)d # prefix each line of exception output with this format # (string value) #logging_exception_prefix=%(asctime)s.%(msecs)03d %(process)d TRACE %(name)s %(instance)s # list of logger=LEVEL pairs (list value)
[openstack-dev] [UX] Proposed tools and workflows for OpenStack User Experience contributors
Dear OpenStack UX community and everybody else who is interested in OpenStack's user experience, When there is more contributors appearing in time, I would like us to establish a formal process of how the UX work should be organized. Therefore I am suggesting a few tools below for us to be more effective, transparent and to provide a single way to all contributors so that it is easy for everybody to start, to contribute and to get oriented in our world. Wiki = introduction to OpenStack User Experience = how to contribute guide = documentation of processes = redirecting people to the right places of their interest (IRC, Launchpad, etc) Mailing list - [UX] --- = discussions about various issues = openstack-dev mailing list, using [UX] tag in the subject + brings more attention to the UX issues + not separated from other OpenStack's projects + threading is already there (e-mail clients) + no need for setting up and maintaining additional server to run our own forum - requires to store attachments somewhere else (some other server) ... similar case with current askbot anyway - requires contributors to register to the openstack-dev mailing list ... each contributor should do that anyway Discussion forum - (terminate) -- + more interactive + easier for newcomers - separating UX outside the OpenStack world - we haven't found any other suitable tool for discussions yet (current AskBot is not doing very well) - in order not to fragment discussions into multiple places, I am suggesting termination of current AskBot and keeping discussions in mailing list IRC meetings = regular meetings, each 2-3 weeks, short meeting, mostly dealing with organizational stuff and bringing attention on hot topics + brings people together + helps with UX organization - requires people to make a time for it ... should be short though, so it shouldn't be big deal Launchpad (StoryBoard in the future) = organization of UX work, overview of who is working on what, prioritizing stories, etc. + helps organizing work + helps documenting UX efforts - requires maintenance ... the same way as for any other program Wishlist (currently Launchpad) -- = list of areas where other projects need a help from UX and UX person can take tasks + easy way of other teams how to interact with UX team when they look for a help + easy way for UXers to see areas where is a need for help Storage place (GitHUb) -- = server where we can store temporary materials as well as final solutions - github for permanent solutions (guidelines, final designs, ...)? Templates library - = library containing pre-prepared templates for UI designs (ready to use already designed elements, etc) + helps designers to produce designs easier by applying copypaste methodology in the templates ... Should contain wireframes as well as visual designed elements ... Should be available for multiple applications (InDesign, Inkscape, etc) ??? (user community for feedback gathering) --- = tool for grouping people who are willing to give feedback on current UX in OpenStack I am looking forward to hearing back from you with your feedback and opinions. If it seems to you like a good overview of how things can work, I will be happy to break it down into smaller pieces and make it happen so that we can start using all these tools as soon as possible. Thank you all -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Service VMs
On Tue, Apr 22, 2014 at 6:49 PM, Isaku Yamahata isaku.yamah...@gmail.com wrote: Hi. Keyle, thank you for starting this discussion to make progress. On Mon, Apr 21, 2014 at 08:41:19PM -0500, Kyle Mestery mest...@noironetworks.com wrote: On Mon, Apr 21, 2014 at 4:20 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Mon, Apr 21, 2014 at 3:07 PM, Kyle Mestery mest...@noironetworks.com wrote: For the upcoming Summit there are 3 sessions filed around Service VMs in Neutron. After discussing this with a few different people, I'd like to propose the idea that the Service VM work be moved out of Neutron and into it's own project on stackforge. There are a few reasons for this: How long do you anticipate the project needing to live on stackforge before it can move to a place where we can introduce symmetric gating with the projects that use it? To be honest, I'm not sure how long it will take. We will see after the summit. At this point, my feeling is - before the summit, preliminary discussion, preparation for the summit - discuss at the summit (including project name?) - after the summit, create its own project on stackforge and start its own activity like weekly IRC meeting. import neutron code repo as the first code base, and cleaning/stripping it up and so on. What do you think? What I'm worried about is having neutron (or another project) depending on a quickly-evolving stackforge project, and having that cause instability in tests. We can't (by policy) gate an integrated project on a stackforge project, but we may be able to set up some test jobs on the new project to warn when changes there are likely to break the app. Doug PS - We have some tools in oslo that may help create a better starting point than forking the entire neutron repository. In particular, oslo-incubator/tools/graduate.sh shows how to extract the git history for a subset of a repository. It would need to be altered for your case, since it assumes you're building a new oslo library repository from the oslo-incubator, but you could use it as an example of how to do the sort of extraction you actually need. The patches for this (look at the BP here [1]) have been in review for a while now as WIP. I think it's reasonable to expect that moving this to stackforge would let the authors and others interested collaborate faster. I expect this would take a cycle on stackforge before we could talk about other projects using this. But honestly, that's a better question for Isaku and Bob. In fact, this is not the first time that such opinion is claimed. But this is the first time to get much feedback. It's good timing to give it a consideration. Just to make it clear, the session slot will be allocated to discuss on this? At least it would be valuable to share the current status and to discuss on its future direction, and which part will be separated out and which part will remain in Neutron. Who is going to drive the development work? For that, I'm thinking Isaku and Bob (copied above) would be the ones driving it. But anyone else who is interested should feel free to jump in as well. I'm willing to take the responsibility (and to share it with Bob). Also others to help are very welcome. thanks, Thanks, Kyle [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms Doug 1. There is nothing Neutron specific about service VMs. 2. Service VMs can perform services for other OpenStack projects. 3. The code is quite large and may be better served being inside it's own project. Moving the work out of Neutron and into it's own project would allow for separate velocity for this project, and for code to be shared for the Service VM work for things other than Neutron services. I'm starting this email thread now to get people's feedback on this and see what comments other have. I've specifically copied Isaku and Bob, who both filed summit sessions on this and have done a lot of work in this area to date. Thanks, Kyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
[openstack-dev] [python-openstacksdk] Class Design Vote (until EOD Thursday)
Per the meeting yesterday, we're having a vote on which way to go between Ed's and Jamie's proposals. If you have an opinion one way or another, please make it known at https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDecision Voting ends at the end of the day UTC on Thursday. If you enter it'll enter your name and the time you voted. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] nova-specs and python-novaclient
On 04/22/2014 08:24 PM, Joe Gordon wrote: On Tue, Apr 22, 2014 at 5:04 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: On Tue, 2014-04-22 at 17:00 -0700, Joe Gordon wrote: Hi All, Several folks have submitted python-novaclient blueprints to nova specs for the Juno Release [0][1], but since python-novaclient isn't part of the integrated release this doesn't really make sense. Furthermore the template we have has sections that make no sense for the client (such as 'REST API impact'). So how should we handle python-novaclient blueprints? Keep them in nova-specs in a separate directory? Separate repo? I think generalize the nova-specs repo from a repo for blueprints for just nova to a repo for all 'compute program' blueprints. Right now that would just cover nova and python-novaclient, but may include other repositories in the future. Here is a proof of concept: https://review.openstack.org/#/c/89725/ John originally mentioned this on the review, but Phil and I both seem to agree. Most novaclient work can just be a work item of a nova blueprint. How about we just handle it that way? I don't really expect any major work in novaclient beyond basic support of new APIs. It seems that the major new work in this area is going into creating a common client. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Service VMs
On Tue, Apr 22, 2014 at 5:49 PM, Isaku Yamahata isaku.yamah...@gmail.com wrote: Hi. Keyle, thank you for starting this discussion to make progress. On Mon, Apr 21, 2014 at 08:41:19PM -0500, Kyle Mestery mest...@noironetworks.com wrote: On Mon, Apr 21, 2014 at 4:20 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Mon, Apr 21, 2014 at 3:07 PM, Kyle Mestery mest...@noironetworks.com wrote: For the upcoming Summit there are 3 sessions filed around Service VMs in Neutron. After discussing this with a few different people, I'd like to propose the idea that the Service VM work be moved out of Neutron and into it's own project on stackforge. There are a few reasons for this: How long do you anticipate the project needing to live on stackforge before it can move to a place where we can introduce symmetric gating with the projects that use it? To be honest, I'm not sure how long it will take. We will see after the summit. At this point, my feeling is - before the summit, preliminary discussion, preparation for the summit - discuss at the summit (including project name?) - after the summit, create its own project on stackforge and start its own activity like weekly IRC meeting. import neutron code repo as the first code base, and cleaning/stripping it up and so on. What do you think? I think this is a good starting plan. The patches for this (look at the BP here [1]) have been in review for a while now as WIP. I think it's reasonable to expect that moving this to stackforge would let the authors and others interested collaborate faster. I expect this would take a cycle on stackforge before we could talk about other projects using this. But honestly, that's a better question for Isaku and Bob. In fact, this is not the first time that such opinion is claimed. But this is the first time to get much feedback. It's good timing to give it a consideration. Just to make it clear, the session slot will be allocated to discuss on this? At least it would be valuable to share the current status and to discuss on its future direction, and which part will be separated out and which part will remain in Neutron. Yes, I will keep this summit session so we can discuss it in Atlanta and move forward from there. Who is going to drive the development work? For that, I'm thinking Isaku and Bob (copied above) would be the ones driving it. But anyone else who is interested should feel free to jump in as well. I'm willing to take the responsibility (and to share it with Bob). Also others to help are very welcome. thanks, Thanks, Kyle [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms Doug 1. There is nothing Neutron specific about service VMs. 2. Service VMs can perform services for other OpenStack projects. 3. The code is quite large and may be better served being inside it's own project. Moving the work out of Neutron and into it's own project would allow for separate velocity for this project, and for code to be shared for the Service VM work for things other than Neutron services. I'm starting this email thread now to get people's feedback on this and see what comments other have. I've specifically copied Isaku and Bob, who both filed summit sessions on this and have done a lot of work in this area to date. Thanks, Kyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [UX] Proposed tools and workflows for OpenStack User Experience contributors
On Apr 23, 2014, at 8:13 AM, Jaromir Coufal jcou...@redhat.com wrote: Dear OpenStack UX community and everybody else who is interested in OpenStack's user experience, Thanks very much for taking the time to write this up, Jarda. I think this would be an awesome list of topics to cover in the User Experience cross-project sessions scheduled for the Summit on Tuesday afternoon. What do others think? I’ll also add some thoughts below to start to drive the conversation further on this list. When there is more contributors appearing in time, I would like us to establish a formal process of how the UX work should be organized. Therefore I am suggesting a few tools below for us to be more effective, transparent and to provide a single way to all contributors so that it is easy for everybody to start, to contribute and to get oriented in our world. Wiki = introduction to OpenStack User Experience = how to contribute guide = documentation of processes = redirecting people to the right places of their interest (IRC, Launchpad, etc) +1. It would be awesome to include some basics about using the mailing list for communication along with IRC and how to balance the two. Mailing list - [UX] --- = discussions about various issues = openstack-dev mailing list, using [UX] tag in the subject + brings more attention to the UX issues + not separated from other OpenStack's projects + threading is already there (e-mail clients) + no need for setting up and maintaining additional server to run our own forum - requires to store attachments somewhere else (some other server) ... similar case with current askbot anyway - requires contributors to register to the openstack-dev mailing list ... each contributor should do that anyway A big +1 to this. Currently there is a mailing list called openstack-personas that has been meant just for the persona effort, but I’ve been trying to get folks who have been involved in that effort to be sure to subscribe to this list and start generating any conversations that are pure UX here on the dev list instead of that personas mailing list. The personas mailing list was really just meant to kick off all of the work that would be done and then we’d bring high level details to this list anyways. Having more or less all UX conversations in one place makes way more sense to me. Discussion forum - (terminate) -- + more interactive + easier for newcomers - separating UX outside the OpenStack world - we haven't found any other suitable tool for discussions yet (current AskBot is not doing very well) - in order not to fragment discussions into multiple places, I am suggesting termination of current AskBot and keeping discussions in mailing list Another idea would be to use the general OpenStack Askbot, but I agree it is yet another place to go to review things and the current way of using Askbot has been difficult to keep up with and follow active discussions. +1 to finding a way to use the mailing list efficiently for design reviews. I’ve found that having a way to leave comments right inline on a design has been very helpful. Jacki and I have been using a tool called “Invision” to share our designs back and forth to get each others feedback and it has been great. I think there is also a tool called Review Board that is open source. Could be worth checking that out as a discussion tool? No matter what, we should work this into the Mailing List too so that folks know when feedback has been given. IRC meetings = regular meetings, each 2-3 weeks, short meeting, mostly dealing with organizational stuff and bringing attention on hot topics + brings people together + helps with UX organization - requires people to make a time for it ... should be short though, so it shouldn't be big deal Again, a huge +1 from me. I think this is the biggest thing that we are missing as a UX community. It will definitely help with organization and communication on who is actively working on what. Agreed they should be short and shouldn’t be a big time commitment to those who are active in UX in the community. Launchpad (StoryBoard in the future) = organization of UX work, overview of who is working on what, prioritizing stories, etc. + helps organizing work + helps documenting UX efforts - requires maintenance ... the same way as for any other program We need to figure out how our Launchpad blueprints relate to development blueprints. Maybe within StoryBoard there will be a way to link these in the future? I’ve worked on projects in the past using an Agile tool that allowed “predecessors” so the dev team knew that a design story was still being worked on and they would be notified when the design was ready for the implementation story to be taken on. Would it be possible to give a short demo of where
[openstack-dev] We will start the DVR meeting around 8.20a.m today.
Hi Folks, I will start the meeting around 8.20a.m today. Thanks Swaminathan Vasudevan Systems Software Engineer (TC) HP Networking Hewlett-Packard 8000 Foothills Blvd M/S 5541 Roseville, CA - 95747 tel: 916.785.0937 fax: 916.785.1815 email: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Congrats and welcome to OPW interns!
On 22/04/14 23:00, Anne Gentle wrote: Hi all, I want to warmly welcome our new interns joining us through the GNOME Outreach Program for Women. Here's a little bit of information about the participants and their projects. Virginia Gresham is in Guilford, CT and Deer Isle, ME (east coast US, represent!) She'll work on a persona research and design project for the Horizon dashboard. That'll include Horizon usability tests. Liz Blanchard and Ju Lim are her mentors. Ana Malagon will work out of New Haven, CT doing period-spanning statistics for Ceilometer with mentor Eoghan Glynn. Nataliia Uvarova (AAzza on IRC) is in Gjøvik, Norway and Kiev, Ukraine (that's a commute to me, maybe I will check that geography). She'll work on Py3K support in Marconi with Flavio Percoco and Alejandro Cabrera. Congratulations on getting accepted everyone, and welcome to the OpenStack community! I hope to see you around on IRC and that you'll find your internship to be both productive and fun. Don't hesitate to ask questions! I also want to show our appreciation to the mentors who worked with many applicants and who did such a great job gathering projects and getting first patches submitted and reviewed. Julie Pichon especially shone while sorting through the many applicants and working with other organizations who also get great interns through this program. One of our prior interns, Terri Yu, did a fantastic job helping applicants and recruiting great people for OpenStack. I know there are many more who helped this round and I can't say enough about what super humans we have here. Thanks Anne :) The official announcement is here: https://wiki.gnome.org/OutreachProgramForWomen/2014/MayAugust#OpenStack With OPW and GSoC, we have 10 interns with many more mentors working on OpenStack. This is fantastic! Thanks everyone who is making these programs a reality for our community. Agreed! Many thanks especially to the mentors for volunteering their time and being so helpful. Cheers, Julie Anne ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Proposing Thomas Spatzier for heat-core
On 23/04/14 04:14, Thomas Spatzier wrote: Hi all, I just realized during a review that I see a couple of more options, so this poll seems to be thru already ;-) Yep, I updated the list yesterday :) Thank you all for your support! I'm glad to be part of this great team! Congrats, and keep up the great work! cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][blueprint] Accelerate the booting process of a number of vms via VMThunder
On Wed, 2014-04-23 at 13:56 +0800, lihuiba wrote: For live migration, we use shared storage so I don't think it's quite the same as getting/putting image bits from/to arbitrary locations. With a good zero-copy transfer lib, live migration support can be extended to non-shared storage, or cross-datacenter. It's a kind of value. Hmm, I totally see the value of doing this. Not sure that there could be the same kinds of liveness guarantees with non-shared-storage, but I am certainly happy to see a proof of concept in this area! :) task = image_api.copy(from_path_or_uri, to_path_or_uri) # do some other work copy_task_result = task.wait() +1 looks cool! how about zero-copying? It would be an implementation detail within nova.image.api.copy() function (and the aforementioned image bits mover library) :) The key here is to leak as little implementation detail out of the nova.image.api module Best, -jay At 2014-04-23 07:21:27,Jay Pipes jaypi...@gmail.com wrote: Hi Vincent, Zhi, Huiba, sorry for delayed response. See comments inline. On Tue, 2014-04-22 at 10:59 +0800, Sheng Bo Hou wrote: I actually support the idea Huiba has proposed, and I am thinking of how to optimize the large data transfer(for example, 100G in a short time) as well. I registered two blueprints in nova-specs, one is for an image upload plug-in to upload the image to glance(https://review.openstack.org/#/c/84671/), the other is a data transfer plug-in(https://review.openstack.org/#/c/87207/) for data migration among nova nodes. I would like to see other transfer protocols, like FTP, bitTorrent, p2p, etc, implemented for data transfer in OpenStack besides HTTP. Data transfer may have many use cases. I summarize them into two catalogs. Please feel free to comment on it. 1. The machines are located in one network, e.g. one domain, one cluster, etc. The characteristic is the machines can access each other directly via the IP addresses(VPN is beyond consideration). In this case, data can be transferred via iSCSI, NFS, and definitive zero-copy as Zhiyan mentioned. 2. The machines are located in different networks, e.g. two data centers, two firewalls, etc. The characteristic is the machines can not access each other directly via the IP addresses(VPN is beyond consideration). The machines are isolated, so they can not be connected with iSCSI, NFS, etc. In this case, data have to go via the protocols, like HTTP, FTP, p2p, etc. I am not sure whether zero-copy can work for this case. Zhiyan, please help me with this doubt. I guess for data transfer, including image downloading, image uploading, live migration, etc, OpenStack needs to taken into account the above two catalogs for data transfer. For live migration, we use shared storage so I don't think it's quite the same as getting/putting image bits from/to arbitrary locations. It is hard to say that one protocol is better than another, and one approach prevails another(BitTorrent is very cool, but if there is only one source and only one target, it would not be that faster than a direct FTP). The key is the use case(FYI:http://amigotechnotes.wordpress.com/2013/12/23/file-transmission-with-different-sharing-solution-on-nas/). Right, a good solution would allow for some flexibility via multiple transfer drivers. Jay Pipes has suggested we figure out a blueprint for a separate library dedicated to the data(byte) transfer, which may be put in oslo and used by any projects in need (Hoping Jay can come in:-)). Huiba, Zhiyan, everyone else, do you think we come up with a blueprint about the data transfer in oslo can work? Yes, so I believe the most appropriate solution is to create a library -- in oslo or a standalone library like taskflow -- that would offer a simple byte streaming library that could be used by nova.image to expose a neat and clean task-based API. Right now, there is a bunch of random image transfer code spread throughout nova.image and in each of the virt drivers there seems to be different re-implementations of similar functionality. I propose we clean all that up and have nova.image expose an API so that a virt driver could do something like this: from nova.image import api as image_api ... task = image_api.copy(from_path_or_uri, to_path_or_uri) # do some other work copy_task_result = task.wait() Within nova.image.api.copy(), we would use the aforementioned transfer library to move the image bits from the source to the destination using the most appropriate method. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Flavor(?) Framework
Hi neutrons, A quick question of the ^^^ I heard from many of you that a term 'flavor' is undesirable, but so far there were no suggestions for the notion that we are going to introduce. So please, suggest you name for the resource. Names that I've been thinking of: - Capability group - Service Offering Thoughts? Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Performance tests of ceilometer-collector and ceilometer-api with different backends
Hi, Swann! Thanks for your feedback) On Wed, Apr 23, 2014 at 2:33 PM, Swann Croiset swan...@gmail.com wrote: Hi Ilya, Interresting, thanks for sharing. So the quick conclusion to your numbers seems indicated that mongodb is more efficient for both reading and writing, except for 2 cases for retrieving data (meters and resouces listing) .. It's not so indisputable fact. Performance fall may happen due to cluster VMs base. For future tests we've already added standalone mysql and standalone hbase backend. Also we will deploy mongo cluster on vms in the nearest future However for the reading operations, it's should be confirmed (or precised) where the time is really spent, would be interresting to compute the distribution of times spent by each layer : backend - api - cli .. similarly to what you did for collector by custom logging (or by instrumentation..) To add additional use cases (and to be more relevant) it will be good to use queries executed by billing systems or the alarm evaluator aka filtering a limited subsets of samples (by resource and/or user and/or tenant) .. to see the numbers without retrieving ten of thousands of samples. They are good ideas. I'll add it to tests and show results as soon as possible. btw, others indicators should help to give a good picture, I see for now: errors rate, queue lenght (rabbit), returned samples|meters|resources by API calls, missing samples (after the populating) and some system metrics also. In present time we are calculating the time which messages are waiting for in rabbitmq queue. This metric has the same meaning as queue length. Also we logs backend errors but not so many errors as we might expect happens in tests. what was the caracteristics of serveurs used for these load test? Controller with 16Gb RAM, 8 procs and 3 VMs with 8 GB RAM and 8 procs (for Hbase). Best regards, Tyaptin Ilia, Intern Software Engineer. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Flavor(?) Framework
On Wed, 2014-04-23 at 19:05 +0400, Eugene Nikanorov wrote: Hi neutrons, A quick question of the ^^^ I heard from many of you that a term 'flavor' is undesirable, but so far there were no suggestions for the notion that we are going to introduce. So please, suggest you name for the resource. Names that I've been thinking of: - Capability group - Service Offering Load balancer type VPN type Firewall type Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Flavor(?) Framework
Thanks, that can be an option. Just wondering, can we find a single name? Thanks, Eugene. On Wed, Apr 23, 2014 at 7:19 PM, Jay Pipes jaypi...@gmail.com wrote: On Wed, 2014-04-23 at 19:05 +0400, Eugene Nikanorov wrote: Hi neutrons, A quick question of the ^^^ I heard from many of you that a term 'flavor' is undesirable, but so far there were no suggestions for the notion that we are going to introduce. So please, suggest you name for the resource. Names that I've been thinking of: - Capability group - Service Offering Load balancer type VPN type Firewall type Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Proposing Thomas Spatzier for heat-core
+1 On 04/23/2014 07:53 AM, Liang Chen wrote: +1 ! On 04/23/2014 02:43 AM, Zane Bitter wrote: Resending with [Heat] in the subject line. My bad. On 22/04/14 14:21, Zane Bitter wrote: I'd like to propose that we add Thomas Spatzier to the heat-core team. Thomas has been involved in and consistently contributing to the Heat community for around a year, since the time of the Havana design summit. His code reviews are of extremely high quality IMO, and he has been reviewing at a rate consistent with a member of the core team[1]. One thing worth addressing is that Thomas has only recently started expanding the focus of his reviews from HOT-related changes out into the rest of the code base. I don't see this as an obstacle - nobody is familiar with *all* of the code, and we trust core reviewers to know when we are qualified to give +2 and when we should limit ourselves to +1 - and as far as I know nobody else is bothered either. However, if you have strong feelings on this subject nobody will take it personally if you speak up :) Heat Core team members, please vote on this thread. A quick reminder of your options[2]: +1 - five of these are sufficient for acceptance 0 - abstention is always an option -1 - this acts as a veto cheers, Zane. [1] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt [2] https://wiki.openstack.org/wiki/Heat/CoreTeam#Adding_or_Removing_Members ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Flavor(?) Framework
On Wed, Apr 23, 2014 at 10:19 AM, Jay Pipes jaypi...@gmail.com wrote: On Wed, 2014-04-23 at 19:05 +0400, Eugene Nikanorov wrote: Hi neutrons, A quick question of the ^^^ I heard from many of you that a term 'flavor' is undesirable, but so far there were no suggestions for the notion that we are going to introduce. So please, suggest you name for the resource. Names that I've been thinking of: - Capability group - Service Offering Load balancer type VPN type Firewall type +1 I like the type constructs. Thanks, Kyle Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Flavor(?) Framework
On Wed, 2014-04-23 at 19:24 +0400, Eugene Nikanorov wrote: Thanks, that can be an option. Just wondering, can we find a single name? service type? :) Oh, I guess that's taken. Well, we could always rename the existing service type to service class or service family. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Flavor(?) Framework
Suggest “service-type” Eugene. /Alan From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: April-23-14 11:05 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron] Flavor(?) Framework Hi neutrons, A quick question of the ^^^ I heard from many of you that a term 'flavor' is undesirable, but so far there were no suggestions for the notion that we are going to introduce. So please, suggest you name for the resource. Names that I've been thinking of: - Capability group - Service Offering Thoughts? Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Flavor(?) Framework
Think that's a good idea Jay A slight twist perhaps: Network Service Type /Alan -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: April-23-14 11:29 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Flavor(?) Framework On Wed, 2014-04-23 at 19:24 +0400, Eugene Nikanorov wrote: Thanks, that can be an option. Just wondering, can we find a single name? service type? :) Oh, I guess that's taken. Well, we could always rename the existing service type to service class or service family. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] Undercloud Ceilometer
-Original Message- From: Ladislav Smola [mailto:lsm...@redhat.com] Sent: Wednesday, April 23, 2014 4:29 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [TripleO] [Tuskar] Undercloud Ceilometer Hi Neal, thanks for response. So I would see it as UNDERCLOUD_USE_UI (TripleO UI can be placed only to Undercloud) And for overcloud: OVERCLOUD_USE_UI and OVERCLOUD_USE_CEILOMETER, cause in overcloud users might not want UI, but only data for billing. Does it sound reasonable? Yep, agreed that UI/metering are different use cases. Will work OVERCLOUD_USE_CEILOMETER use case into changes first, then address UI later if someone else hasn't picked it up. - Phil On 04/22/2014 06:23 PM, Neal, Phil wrote: From: Ladislav Smola [mailto:lsm...@redhat.com] Sent: Wednesday, April 16, 2014 8:37 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [TripleO] [Tuskar] Undercloud Ceilometer No response so far, but -1 on the image element for making Ceilometer optional. Sorry for the delayed response, Ladislov. It turns out that the mailing list was filtering out these TripleO mails for me. Let me add a little context to that -1: given that a TripleO user may not want to enable a UI layer at the undercloud level (there's a use case for using the undercloud solely for spinning up the overcloud), I think we want to support as small a footprint as possible. OK, so what about having variable in devtest_variables: USE_TRIPLEO_UI. I like this approach better...in fact I will look into adding something similar into the changes I'm making to enable Ceilometer by default in the overcloud control node: https://review.openstack.org/#/c/89625/1 It would add Undercloud Ceilometer, Tuskar-UI and Horizon. And Overcloud SNMPd. Defaulted to USE_TRIPLEO_UI=1 so we have UI stuff in CI. How does it sound? Perhaps specify something like UNDERCLOUD_USE_TRIPLEO_UI to be more specific on where this will be deployed. On 04/14/2014 01:31 PM, Ladislav Smola wrote: Hello, I am planning to add Ceilometer to Undercloud as default. Since Tuskar-UI uses it as primary source of metering samples and Tuskar should be in Undercloud as default, it made sense to me. So is my assumption correct or there are some reasons not to do this? Here are the reviews, that are adding working Undercloud Ceilometer: https://review.openstack.org/#/c/86915/ https://review.openstack.org/#/c/86917/ (depends on the template change) https://review.openstack.org/#/c/87215/ Configuration for automatic obtaining of stats from all Overcloud nodes via. SNMP will follow soon. Thanks, Ladislav ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Flavor(?) Framework
Yeah, service type has internal meaning, I'd avoid using that term. Network service type probably is a bit of tautology, because we only offer network services :) Eugene. On Wed, Apr 23, 2014 at 7:52 PM, Alan Kavanagh alan.kavan...@ericsson.comwrote: Think that's a good idea Jay A slight twist perhaps: Network Service Type /Alan -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: April-23-14 11:29 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Flavor(?) Framework On Wed, 2014-04-23 at 19:24 +0400, Eugene Nikanorov wrote: Thanks, that can be an option. Just wondering, can we find a single name? service type? :) Oh, I guess that's taken. Well, we could always rename the existing service type to service class or service family. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Performance tests of ceilometer-collector and ceilometer-api with different backends
Joe, There are a number of problem reports on ceilometer performance and some promising blueprints to address them. I'd suggest we re-run the performance test when those are in place. Having reference performance tests such as this are helpful to pick up cases where there are regression or scalability problems such as you raise (and production users see them also) Tim On 23 Apr 2014, at 18:51, Joe Gordon joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote: On Mon, Apr 21, 2014 at 2:10 PM, Ilya Tyaptin ityap...@mirantis.commailto:ityap...@mirantis.com wrote: Hi team! In light of discussions about ceilometer backends, we decided to test performance of different storage backends with collector and api services because these services depend on backends availability. For the collector testing we are using not completely real data, we are generating looking like real samples with variable rate, sending them to the collector and metering the time of these messages processing. Testing result is the time between message receiving for recording message to db. For the api testing we are only comparing the time of requests to api with different backends. We have prepared a document with more detailed description of test plan and first results. This url: https://docs.google.com/document/d/1ARpKiYW2WN94JloG0prNcLjMeom-ySVhe8fvjXG_uRU/edit?usp=sharing I am not sure if I read the 'Testing api' section correctly. Is that table in seconds? If so a REST API that takes over two minutes (sample-list for Hbase, meter-list in Mongo) doesn't sound very good. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Performance tests of ceilometer-collector and ceilometer-api with different backends
On Wed, 2014-04-23 at 17:32 +, Tim Bell wrote: There are a number of problem reports on ceilometer performance and some promising blueprints to address them. I'd suggest we re-run the performance test when those are in place. Having reference performance tests such as this are helpful to pick up cases where there are regression or scalability problems such as you raise (and production users see them also) ++, and also need the SQL driver tested as well. Best, jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [UX] User Experience cross-project sessions at Summit
Hi All, I’m happy to say that there will be two slots (back to back) on the cross-project track for us to have discussions around User Experience during Summit \o/. I’d like to propose we talk about the following, but am completely open to suggestions from whoever is interested in attending these sessions. Let me know if anyone has any thoughts here! 1) Introduction of everyone in the session. -What role do you have today? -How does UX affect you? -How will you (if you plan to) contribute to OpenStack UX? -How active do you plan to be for the Juno development cycle? 2) Discussion of where are are currently in UX. -What components have we worked on so far? -What does our current process look like? -What tools do we use? -What has worked well? -What could be improved? 3) Discussion on where we want to go for Juno. -How should we improve our process and tooling during the Juno release? How do we track this and who will take certain action items? -What tools should we remove/add? (Jarda sent a nice e-mail proposal around yesterday that would be great to discuss further) -What are our goals for UX during the Juno release? (More research/requirements work? More designing? More user testing?...) Which components will we focus on? (Horizon? Tuskar? Heat? Ceilometer?….) Which features will we focus on? 4) UX as a program. -What does it mean to be a program? -Would UX make sense to be a program? If so, how should we work together to make this something we could propose as a team? Thanks all, Liz ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Performance tests of ceilometer-collector and ceilometer-api with different backends
On Wed, Apr 23, 2014 at 10:32 AM, Tim Bell tim.b...@cern.ch wrote: Joe, There are a number of problem reports on ceilometer performance and some promising blueprints to address them. I'd suggest we re-run the performance test when those are in place. Having reference performance tests such as this are helpful to pick up cases where there are regression or scalability problems such as you raise (and production users see them also) Tim, Do you have any links to those blueprints? https://blueprints.launchpad.net/ceilometer/juno is pretty sparse. Tim On 23 Apr 2014, at 18:51, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Apr 21, 2014 at 2:10 PM, Ilya Tyaptin ityap...@mirantis.comwrote: Hi team! In light of discussions about ceilometer backends, we decided to test performance of different storage backends with collector and api services because these services depend on backends availability. For the collector testing we are using not completely real data, we are generating looking like real samples with variable rate, sending them to the collector and metering the time of these messages processing. Testing result is the time between message receiving for recording message to db. For the api testing we are only comparing the time of requests to api with different backends. We have prepared a document with more detailed description of test plan and first results. This url: *https://docs.google.com/document/d/1ARpKiYW2WN94JloG0prNcLjMeom-ySVhe8fvjXG_uRU/edit?usp=sharing https://docs.google.com/document/d/1ARpKiYW2WN94JloG0prNcLjMeom-ySVhe8fvjXG_uRU/edit?usp=sharing* I am not sure if I read the 'Testing api' section correctly. Is that table in seconds? If so a REST API that takes over two minutes (sample-list for Hbase, meter-list in Mongo) doesn't sound very good. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [qa] EC2 status and call for assistance
On Wed, Apr 23, 2014 at 4:47 AM, Sean Dague s...@dague.net wrote: I've spent a couple of days getting to the bottom of: Bug 1302774 - Failed to detach volume because of volume not found error prevents vm teardown This is an ec2 specific failure path, which mostly looks like a combination of a not very good test case and the EC2 code in nova collapsing the volume states in a way that seems completely incorrect based on what I can read on what's expected from this call. However, these are symptoms of a bigger issue. The EC2 paths in Nova are old, fragile, and error prone. The test coverage for these paths is minimal, and largely hasn't evolved in the last year. The last substantial addition to the EC2 tests in Tempest was by Burt Holtzman in July 2013, Burt has also been contributing to the Nova side, but beyond Burt, there basically aren't contributors right now. I really don't like shipping code in Nova that we know isn't good. With very few contributions in this code though, it's defacto, if not officially, deprecated. I'd like to see if there are any more people interested in keeping these interfaces functional (by contributing both on the nova and tempest sides). If so, great! If we get to the end of Juno in the current state, I think we need to consider actually deprecating the EC2 support in Nova. Because I'm pretty sure what we have today actually only works if you are using boto on the client side, and doesn't really look like EC2 at any real level of inspection. I Agree with this general sentiment. I would like to see EC2 support stay, but if no one is maintaining it and we know its broken we should deprecate it. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [qa] EC2 status and call for assistance
Sean, We have a bunch of tempest tests we’re ready to push back that increase coverage for the EC2 tests. Also, rather than deprecating the EC2 pieces, which are in use by ~35% of the community, I’d like to recommend we move them into Stackforge as we did with the GCE APIs. That way these can become optional components installed by those who want to use them. The other advantage is that they can be iterated on out of band. I would still like to see them all in the CI system however. Thanks, --Randy Founder CEO, Cloudscaling Board of Directors, OpenStack Foundation +1 (415) 787-2253 [SMS or voice] TWITTER: twitter.com/randybias LINKEDIN: linkedin.com/in/randybias CALENDAR: doodle.com/randybias On Apr 23, 2014, at 4:47 AM, Sean Dague s...@dague.net wrote: I've spent a couple of days getting to the bottom of: Bug 1302774 - Failed to detach volume because of volume not found error prevents vm teardown This is an ec2 specific failure path, which mostly looks like a combination of a not very good test case and the EC2 code in nova collapsing the volume states in a way that seems completely incorrect based on what I can read on what's expected from this call. However, these are symptoms of a bigger issue. The EC2 paths in Nova are old, fragile, and error prone. The test coverage for these paths is minimal, and largely hasn't evolved in the last year. The last substantial addition to the EC2 tests in Tempest was by Burt Holtzman in July 2013, Burt has also been contributing to the Nova side, but beyond Burt, there basically aren't contributors right now. I really don't like shipping code in Nova that we know isn't good. With very few contributions in this code though, it's defacto, if not officially, deprecated. I'd like to see if there are any more people interested in keeping these interfaces functional (by contributing both on the nova and tempest sides). If so, great! If we get to the end of Juno in the current state, I think we need to consider actually deprecating the EC2 support in Nova. Because I'm pretty sure what we have today actually only works if you are using boto on the client side, and doesn't really look like EC2 at any real level of inspection. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Design summit preparation - Next steps for Heat Software Orchestration
On Tue, Apr 22, 2014 at 8:42 PM, Thomas Spatzier thomas.spatz...@de.ibm.com wrote: #2 Enable add-hoc actions on software components: Apart from basic resource lifecycle hooks, it would be desirable to allow for invocation of add-hoc actions on software. Examples would be the ad-hoc creation of DB backups, application of patches, or creation of users for an application. Such hooks (implemented as scripts, Chef recipes or Puppet facts) could be defined in the same way as basic lifecycle hooks. They could be triggered by doing property updates on the respective SoftwareDeployment resources (just a thought and to be discussed during design sessions). I think this item could help bridging over to some discussions raised by the Murano team recently (my interpretation: being able to trigger actions from workflows). It would add a small feature on top of the current software orchestration in Heat and keep definitions in one place. And it would allow triggering by something or somebody else (e.g. a workflow) probably using existing APIs. Hi Thomas, This is exactly what we need in Heat for Murano workflows. Also, I believe that what you described above, perfectly maps on TOSCA, which is also very good for us :) From the implementation point of view and our previous discussions I figure out that Mistral can be a good fit for lifecycle hooks execution. Renat (Mistral lead) added a topic [1] for Heat weekly meeting, I hope we can discuss this today as part of that topic. [1] https://wiki.openstack.org/wiki/Meetings/HeatAgenda Thanks, Ruslan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [openstack-php-sdk] Contributing guidelines
Hey PHP SDK folks (although others are welcome to chime in too), I am thinking of adding a CONTRIBUTING.rst to the root of our repo at http://git.openstack.org/cgit/stackforge/openstack-sdk-php/tree/. My immediate, selfish need is to have a single place where we capture any decisions around contribution process so I don’t have to remember them or rehash them often. Longer term I think this would be useful to all potential contributors - in making them feel welcome and less overwhelmed - especially as the project grows. If you think this would be a useful addition, please read on. Putting on a new contributor’s hat, here are some of the questions (in no particular order) that come to my mind when I encounter a new project: 1. What is the overall development process? 2. I see a bunch of directories and files in the source tree. What do these mean? 3. What do I need to setup in my development environment so I can contribute? 4. Are there any coding standards I should adhere to? 5. I'm ready to submit my first patch. What happens next? 6. How do I run the unit tests? 7. How do I run the integration tests? Can you think of more questions, ones you might’ve had in the past perhaps? I imagine the CONTRIBUTING.rst to be comprised of answers to these questions (but perhaps not necessarily in QA format). I realize that some of these answers would overlap with information that already exists elsewhere. We would link to those sources while still giving our contributors a single starting point within the context of our project. Please note that, at this time, I’m just soliciting approval for having a CONTRIBUTING.rst and coming up with the list of questions that it would answer. I am not (yet) looking for us to come up with all the answers and agree on them as a team. Thoughts? Shaunak ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Globalization] REST API sorting by status severity vs. alphabetical status key
I am trying to address the following use case: - Assume that the REST APIs support returning data based on a user-defined sort key (assuming that this get approved: https://review.openstack.org/#/c/84451/) - UI contains a table showing items (servers, volumes, etc.) and their status (as a sortable column) and uses pagination to get only a page of data - UI is translated into a non-English language - User wants to sort the table by status In this case, the sorting by status is done against the English key values in the database (active, error, etc.). The UI will then translate the status values into the user's locale and (from the user's perspective) the data will not be in sorted order -- thus confusing and frustrating the user. Note that UI cannot do the sort client-side since pagination is used so it the client only has a sub-set of the total data. I have prototyped a sort by case solution that would allow status to be sorted by severity. In SQL the case statement can be used to map a string to an int and then sort the rows based on the int value (ie, error=0, building=1, active=2, etc.). Using this approach, sorting by status would result in an enum-like sort (based on severity) instead of an alphabetical sort based on the English key values. This solution allows enum-like data to be sorted in a consistent way across all locales -- the solution is generic and can be applied to any column where the values are a known set. The case processing would need to be done in the common paginate_query function: https://github.com/openstack/oslo-incubator/blob/master/openstack/common/db/sqlalchemy/utils.py#L62 This type of sort would not be the default behavior for a status column (or any enum-like column) and the caller would need to specify a unique sort direction key for it (ie, 'asc_case' or 'desc_case'). In theory, this type of sorting support could also be globally enabled/disabled by a deployer (default would be disabled) to further reduce impact. Lastly, I have some performance data and sorting the status by case (vs. alphabetical) has a minimal impact on performance. Before I create a proposal for juno I wanted to get some early feedback on the high-level approach. Please reply with feedback on this solution. Thanks, Steven Kaufer___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [qa] EC2 status and call for assistance
On 04/23/2014 02:47 PM, Randy Bias wrote: Sean, We have a bunch of tempest tests we’re ready to push back that increase coverage for the EC2 tests. Also, rather than deprecating the EC2 pieces, which are in use by ~35% of the community, I’d like to recommend we move them into Stackforge as we did with the GCE APIs. That way these can become optional components installed by those who want to use them. The other advantage is that they can be iterated on out of band. I would still like to see them all in the CI system however. Assistance on Tempest would be highly appreciated. I'm a little saddened that there is apparently a large set of out of tree tests that this is the first we've heard of. These would have been good community contributions during the icehouse cycle. Tempest runs like any other part of OpenStack, so a giant dump isn't going to work, and it's going to have to be proposed in manageable and reviewable chunks. If people want EC2 in the main CI it needs to stay in Nova. It's either part of the project, and supported, or it's not, and it's not. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Performance tests of ceilometer-collector and ceilometer-api with different backends
Do you have any links to those blueprints? https:// blueprints.launchpad.net/ceilometer/juno is pretty sparse. we'll probably add targets closer to summit (or post summit). blueprints of interest may be: https://blueprints.launchpad.net/ceilometer/+spec/big-data-sql https://blueprints.launchpad.net/ceilometer/+spec/tighten-model https://blueprints.launchpad.net/ceilometer/+spec/bulk-message-handling we're still prioritising design sessions but it's safe to say this session will be there: http://summit.openstack.org/cfp/details/163 cheers, gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
Hi y'all! As discussed in last week's IRC meeting, my team members and I have produced a revised draft of the API v2.0 proposal started last week by the Rackspace crew. (Thanks again for this, y'all-- this helped us get a heck of a head start on our revised proposal.) Our v2.0 API proposal revision can be found here: https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit?usp=sharing (I've enabled commenting on the above google doc, but for longer discussion of fundamental issues, let's keep that to this mailing list, eh!) Please also pay attention to the Introduction section of this document: I've defined which glossary of terms we're using there and provided links to a proposed corresponding object model diagram and its source. Further, I've pointed out decisions we made drafting this API as well as issues not yet addressed. I would appreciate your feedback on all of this (again, the discussions for which should probably happen on this mailing list). To get to some of the points I know a lot of people will be interested in: - This proposal does include a single-call interface for both creation and deletion, and yes, all primitives can be created through it. - This proposal does include L7 functionality support, based somewhat loosely on the ideas represented here: https://wiki.openstack.org/wiki/Neutron/LBaaS/l7 - This proposal does include SSL termination and re-encryption support, based loosely both on what we already do in our envionment, as well as this: https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL - We have also tried to keep in mind features in use and requested in the following two documents as well: https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWcusp=sharing - HA functionality is not addressed in this document, per se, other than expressing the conviction that however this is handled will probably not affect the user API expressed in this document. (We have an ongoing discussion about this going on in another mailing list thread-- and now that I'm not neck deep in API documentation I'll probably jump back onto this in the next couple of days.) And... I think that's about it. Please have fun ripping this draft to shreds! Thanks, Stephen -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Status of the agent driver
On Apr 22, 2014 11:51 AM, Jim Rollenhagen j...@jimrollenhagen.com wrote: Hi folks! Deva and I talked a bit more about the agent driver last night, and I wanted to give everyone a quick status update on where we stand with merging the agent driver into Ironic itself. First off, we’ve taken all of the agent driver patches we had and squashed them into the main agent patch here: https://review.openstack.org/#/c/84795/ That patch still depends on two other patches: * https://review.openstack.org/#/c/81391/ * https://review.openstack.org/#/c/81919/ which should be close to landing. The plan going forward is to continue to iterate on 84795 until it lands. Not everything is complete yet, but I would prefer it to land it and file bugs, etc. for missing features or things that are broken. The patch is already pretty large and getting a bit unwieldy. What we know is not ready today (I’d like to land these in later patches, but feedback welcome on that): * tear_down() is not fully implemented. * Networking things are not fully implemented. * More hardware info coming from the agent should be stored in the database (IMO). * The agent and PXE drivers should have similar driver_info and instance_info - this is not true today. * The agent currently relies on a static DHCP configuration rather than the Neutron support the PXE driver uses - which means the agent cannot be used side-by-side with other drivers today. This should be fixes but may take a fair amount of work. * There are quite a few TODOs littered around - some are functional things, others are optimizations. If there are some that should be implemented before landing this, we’re happy to do so. We would appreciate it if folks could start reviewing this patch, in case there are things I missed in this list. One last thing: testing. We plan to add tempest tests for this driver sooner than later. I think having similar or identical driver_info, and using Neutron for DHCP, etc, will simplify these tests, and possibly converge them to one test. That said, I’d like to start writing the tempest tests now and converge as we go. Thanks for the excellent summary of our discussion, Jim! I would appreciate it if a few more people could take some time to review the agent driver and associated patches, and really think about the architecture and implications here. We've discussed the need for a more capable agent even before the Hong Kong summit. Now we need reviewers to step up and help make it happen. Things that are on my mind as I review these patches: * What are the operational and external requirements to use this? Are they documented somewhere? Do they expand the project's scope or increase operational complexity? * How can I test the agent driver today? I hesitate to land this much code without the ability to test it locally. * What is the plan for automated testing? * Given the above, what needs to be done before landing the agent driver, and what can be iterated upon after landing it? A few specific points that you mention, which I'd like to expand on... the dependency on a static external DHCP server seems like a blocker to me. This prevents co-operation of the current PXE class of drivers, and would require many changes to devstack/lib/ironic to prepare the environment appropriately for the agent. Our reference implementation -- what we test in the gate -- should be integrated with other OpenStack components, so I don't feel that we should even add that support to devstack temporarily. The lack of tear_down() is another blocker, in my opinion. That is a required part of a core driver interface; the driver is incomplete without that. On the other hand, I think that moving all the instance-specific bits from driver_info to instance_info could be done after landing the driver. That'll require staging and coordinating changes to several projects (at a minimum, ironic and tempest). We should also do it in a way that is compatible with the Icehouse-stable branch (I don't think that will be hard). I'm fine with landing the driver while there are still optimization #TODO's, partial (or missing) implementations of optional features, etc. I would like to start discussing the status of the agent and agent driver during every weekly meeting, and have added it to the agenda. I realize we have only one more meeting before the summit, and I'd like to use a portion of that time to go over the plan for the summit session devoted to the agent. Cheers, Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Meeting time redux
On 04/23/2014 12:12 PM, Zane Bitter wrote: At the beginning of this year we introduced alternating times for the Heat weekly IRC meeting, in the hope that our contributors in Asia would be able to join us. The consensus is that this hasn't worked out as well as we had hoped - even the new time falls at 8am in Beijing, so folks are regularly unable to make the meeting. It also falls at 5pm on the west coast of the US, so folks from there are also regularly unable to make the meeting too. And of course it is in the middle of the night for Europe, so the meeting room looks like a ghost town. Since we are in a new development cycle (with the PTL in a different location) and daylight savings has kicked in/out in many places, let's review our options. Here are our choices as I see it: * Keep going with the current system or some minor tweak to it. * Flip the alternate meeting by 12 hours to 1200 UTC. (8pm in China, late night in Oceania, early-morning on the east coast of the US and we lose the rest of the US.) * Lose all US-based folks and have a meeting for the rest of the world at around 0700 UTC. (US-based folks include me, so I would have to ask someone else to take care of passing on messages-from-the-PTL.) * Abandon the alternating meetings altogether. abandon What would people prefer? I'd particularly like to hear from folks based in Asia what times would enable them to regularly attend, while still ensuring there are other people there to talk to ;) thanks, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] Question regarding new panels and tests
I have a question about adding new panels with respect to tests. I have a new panel (for the Sahara project, data processing) that lives (for now at least) under the projects folder. The plan is to have it activated only by using the new enabled mechanism to define a new panel group, data processing, where it and several other panels will eventually show up. When I did this, it works fine for me when I run it, but running the tests (tox -e py27) fails because my panel is not registered anywhere. Is there a config for the tests that I can tweak so that my panel can be registered for the tests (tests/enabled or something like that? Thanks, Chad ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [qa] EC2 status and call for assistance
On Apr 23, 2014, at 12:04 PM, Sean Dague s...@dague.net wrote: We have a bunch of tempest tests we’re ready to push back that increase coverage for the EC2 tests. Also, rather than deprecating the EC2 pieces, which are in use by ~35% of the community, I’d like to recommend we move them into Stackforge as we did with the GCE APIs. That way these can become optional components installed by those who want to use them. The other advantage is that they can be iterated on out of band. I would still like to see them all in the CI system however. Assistance on Tempest would be highly appreciated. I'm a little saddened that there is apparently a large set of out of tree tests that this is the first we've heard of. These would have been good community contributions during the icehouse cycle. Tempest runs like any other part of OpenStack, so a giant dump isn't going to work, and it's going to have to be proposed in manageable and reviewable chunks. If people want EC2 in the main CI it needs to stay in Nova. It's either part of the project, and supported, or it's not, and it's not. It wasn’t intentional. More of a resource constraint issue than anything else. Some of us are at small startups and it can be very challenging to prioritize beyond our immediate needs. I’m in the process of standing up one of the largest OpenStack private clouds out there right now for a Fortune 10 company. That kind of takes precedence. I’m sorry this happens. Your email fortunately catalyzed me to get off my arse, not to mention Joe Gordon prodding me. If being in mainline is required for the CI system, then sure, I prefer the EC2 APIs stay there. I think there should be some thought given to how to support StackForge projects as “nice to haves” in the CI system though. Doesn’t really make sense for something to have to be suddenly thrown over the wall into integrated before being in some kind of CI pipeline. StackForge, as I understand it, is the “official” place for incubating projects. If so, should there be some kind of best effort CI system for those being incubated that have an intention for becoming integrated?? Maybe I just don’t understand how StackForge is supposed to work then. We’ll get the new tests we have into some manageable chunks for review and inclusion into tempest mainline. Thanks, —Randy Ps. Looping in Reliance as I believe they have skin in the game here as well. Founder CEO, Cloudscaling Board of Directors, OpenStack Foundation +1 (415) 787-2253 [SMS or voice] TWITTER: twitter.com/randybias LINKEDIN: linkedin.com/in/randybias CALENDAR: doodle.com/randybias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [qa] EC2 status and call for assistance
On Wed, 2014-04-23 at 11:47 -0700, Randy Bias wrote: Sean, We have a bunch of tempest tests we’re ready to push back that increase coverage for the EC2 tests. Also, rather than deprecating the EC2 pieces, which are in use by ~35% of the community, I’d like to recommend we move them into Stackforge as we did with the GCE APIs. That way these can become optional components installed by those who want to use them. The other advantage is that they can be iterated on out of band. I would still like to see them all in the CI system however. +1 on all points. -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Globalization] REST API sorting by status severity vs. alphabetical status key
Hi Steven, thx for the detailed email. Some comments inline...
On Wed, 2014-04-23 at 13:59 -0500, Steven Kaufer wrote:
I am trying to address the following use case:
- Assume that the REST APIs support returning data based on a
user-defined sort key (assuming that this get approved:
https://review.openstack.org/#/c/84451/)
- UI contains a table showing items (servers, volumes, etc.) and their
status (as a sortable column) and uses pagination to get only a page
of data
- UI is translated into a non-English language
- User wants to sort the table by status
In this case, the sorting by status is done against the English key
values in the database (active, error, etc.). The UI will then
translate the status values into the user's locale and (from the
user's perspective) the data will not be in sorted order -- thus
confusing and frustrating the user. Note that UI cannot do the sort
client-side since pagination is used so it the client only has a
sub-set of the total data.
Indeed, this is a problem.
I have prototyped a sort by case solution that would allow status to
be sorted by severity. In SQL the case statement can be used to map
a string to an int and then sort the rows based on the int value (ie,
error=0, building=1, active=2, etc.). Using this approach, sorting by
status would result in an enum-like sort (based on severity) instead
of an alphabetical sort based on the English key values. This
solution allows enum-like data to be sorted in a consistent way across
all locales -- the solution is generic and can be applied to any
column where the values are a known set.
The case processing would need to be done in the common paginate_query
function:
https://github.com/openstack/oslo-incubator/blob/master/openstack/common/db/sqlalchemy/utils.py#L62
This type of sort would not be the default behavior for a status
column (or any enum-like column) and the caller would need to specify
a unique sort direction key for it (ie, 'asc_case' or 'desc_case').
In theory, this type of sorting support could also be globally
enabled/disabled by a deployer (default would be disabled) to further
reduce impact.
Lastly, I have some performance data and sorting the status by case
(vs. alphabetical) has a minimal impact on performance.
Before I create a proposal for juno I wanted to get some early
feedback on the high-level approach. Please reply with feedback on
this solution.
So, I feel that the above solution (while innovative certainly! :) ) is
not actually addressing the underlying source of the problem here, and
that is that statuses are stored in the database as English-language
strings instead of integer code values in a lookup table.
By addressing the underlying source of the problem -- by changing the
instances.{vm,task,power}_state columns to an integer value and using a
lookup table in the cases when translation from code to display is
needed -- we both solve the problem of i18n sorting and increase the
database performance, since queries on these state columns will use an
index on a datatype with a much slimmer width.
Best,
-jay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Status of the agent driver
On Wed, Apr 23, 2014 at 12:19 PM, Devananda van der Veen devananda@gmail.com wrote: On Apr 22, 2014 11:51 AM, Jim Rollenhagen j...@jimrollenhagen.com wrote: Hi folks! Deva and I talked a bit more about the agent driver last night, and I wanted to give everyone a quick status update on where we stand with merging the agent driver into Ironic itself. First off, we’ve taken all of the agent driver patches we had and squashed them into the main agent patch here: https://review.openstack.org/#/c/84795/ That patch still depends on two other patches: * https://review.openstack.org/#/c/81391/ * https://review.openstack.org/#/c/81919/ which should be close to landing. The plan going forward is to continue to iterate on 84795 until it lands. Not everything is complete yet, but I would prefer it to land it and file bugs, etc. for missing features or things that are broken. The patch is already pretty large and getting a bit unwieldy. What we know is not ready today (I’d like to land these in later patches, but feedback welcome on that): * tear_down() is not fully implemented. * Networking things are not fully implemented. * More hardware info coming from the agent should be stored in the database (IMO). * The agent and PXE drivers should have similar driver_info and instance_info - this is not true today. * The agent currently relies on a static DHCP configuration rather than the Neutron support the PXE driver uses - which means the agent cannot be used side-by-side with other drivers today. This should be fixes but may take a fair amount of work. * There are quite a few TODOs littered around - some are functional things, others are optimizations. If there are some that should be implemented before landing this, we’re happy to do so. We would appreciate it if folks could start reviewing this patch, in case there are things I missed in this list. One last thing: testing. We plan to add tempest tests for this driver sooner than later. I think having similar or identical driver_info, and using Neutron for DHCP, etc, will simplify these tests, and possibly converge them to one test. That said, I’d like to start writing the tempest tests now and converge as we go. Thanks for the excellent summary of our discussion, Jim! I would appreciate it if a few more people could take some time to review the agent driver and associated patches, and really think about the architecture and implications here. We've discussed the need for a more capable agent even before the Hong Kong summit. Now we need reviewers to step up and help make it happen. Things that are on my mind as I review these patches: * What are the operational and external requirements to use this? Are they documented somewhere? Do they expand the project's scope or increase operational complexity? * How can I test the agent driver today? I hesitate to land this much code without the ability to test it locally. * What is the plan for automated testing? * Given the above, what needs to be done before landing the agent driver, and what can be iterated upon after landing it? A few specific points that you mention, which I'd like to expand on... the dependency on a static external DHCP server seems like a blocker to me. This prevents co-operation of the current PXE class of drivers, and would require many changes to devstack/lib/ironic to prepare the environment appropriately for the agent. Our reference implementation -- what we test in the gate -- should be integrated with other OpenStack components, so I don't feel that we should even add that support to devstack temporarily. The lack of tear_down() is another blocker, in my opinion. That is a required part of a core driver interface; the driver is incomplete without that. On the other hand, I think that moving all the instance-specific bits from driver_info to instance_info could be done after landing the driver. That'll require staging and coordinating changes to several projects (at a minimum, ironic and tempest). We should also do it in a way that is compatible with the Icehouse-stable branch (I don't think that will be hard). I'm fine with landing the driver while there are still optimization #TODO's, partial (or missing) implementations of optional features, etc. I would like to start discussing the status of the agent and agent driver during every weekly meeting, and have added it to the agenda. I realize we have only one more meeting before the summit, and I'd like to use a portion of that time to go over the plan for the summit session devoted to the agent. Apparently I can't read my own calendar today... we have *two* more meetings before the summit. -D ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [QA] Meeting Thursday April 24th at 17:00UTC
Just a quick reminder that the weekly OpenStack QA team IRC meeting will be tomorrow Thursday, April 24th at 17:00 UTC in the #openstack-meeting channel. The agenda for tomorrow's meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Anyone is welcome to add an item to the agenda. To help people figure out what time 17:00 UTC is in other timezones tomorrow's meeting will be at: 13:00 EDT 02:00 JST 02:30 ACST 19:00 CEST 12:00 CDT 10:00 PDT -Matt Treinish ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] [Gantt] Scheduler related sessions for the Juno summit
Hi all, I just noticed (with a slight delay due to lack of notifications from summit.openstack.org) that most of the Nova proposals for sessions were under review with comments. As Scheduler code is on a big turn for Juno with the forklift efforts and the Gantt project, I think it's worth having a whole overview of all the proposals within a single etherpad [1] Proposers, please review the etherpad and add your own sessions if you consider they are related to scheduling efforts. Nova reviewers, feel free to look at this etherpad to see if there are duplicates and comment if so. I'll be glad helping you with triaging all those proposals and making sure we are on the same page. -Sylvain [1] : https://etherpad.openstack.org/p/Gantt-summit-sessions ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Question regarding new panels and tests
I have a question about adding new panels with respect to tests. I have a new panel (for the Sahara project, data processing) that lives (for now at least) under the projects folder. The plan is to have it activated only by using the new enabled mechanism to define a new panel group, data processing, where it and several other panels will eventually show up. When I did this, it works fine for me when I run it, but running the tests (tox -e py27) fails because my panel is not registered anywhere. Is there a config for the tests that I can tweak so that my panel can be registered for the tests (tests/enabled or something like that? Thanks, Chad Hiya - I haven't tested this, but one thing you could try. . . if you look at horizon/openstack_dashboard/settings.py, there's a section that determines where the dashboard looks for plugins (https://github.com/openstack/horizon/blob/master/openstack_dashboard/settings.py#L220) # Load the pluggable dashboard settings import openstack_dashboard.enabled import openstack_dashboard.local.enabled from openstack_dashboard.utils import settings INSTALLED_APPS = list(INSTALLED_APPS) # Make sure it's mutable settings.update_dashboards([ openstack_dashboard.enabled, openstack_dashboard.local.enabled, ], HORIZON_CONFIG, INSTALLED_APPS) If you edit horizon/openstack_dashboard/settings.py to add a similar section, only using, say, openstack_dashboard.test.local.enabled, you may be able to enable the panels for the tests there. Mainn ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Globalization] REST API sorting by status severity vs. alphabetical status key
Jay,
Thanks for the reply. I agree that changing the datamodel would be the
ideal solution. But, to be honest, the scope of that change frightens me.
How would you recommend that a change like this would be handled (in
addition to the DB migration work)? We obviously cannot break existing
codepaths that assume that the existing English key values would be
returned from the DB.
Is there an existing layer that would perform the mapping between the enum
values in the DB and the String keys?
Thanks,
Steven Kaufer
Jay Pipes jaypi...@gmail.com wrote on 04/23/2014 02:56:14 PM:
From: Jay Pipes jaypi...@gmail.com
To: openstack-dev@lists.openstack.org,
Date: 04/23/2014 02:56 PM
Subject: Re: [openstack-dev] [Globalization] REST API sorting by
status severity vs. alphabetical status key
Hi Steven, thx for the detailed email. Some comments inline...
On Wed, 2014-04-23 at 13:59 -0500, Steven Kaufer wrote:
I am trying to address the following use case:
- Assume that the REST APIs support returning data based on a
user-defined sort key (assuming that this get approved:
https://review.openstack.org/#/c/84451/)
- UI contains a table showing items (servers, volumes, etc.) and their
status (as a sortable column) and uses pagination to get only a page
of data
- UI is translated into a non-English language
- User wants to sort the table by status
In this case, the sorting by status is done against the English key
values in the database (active, error, etc.). The UI will then
translate the status values into the user's locale and (from the
user's perspective) the data will not be in sorted order -- thus
confusing and frustrating the user. Note that UI cannot do the sort
client-side since pagination is used so it the client only has a
sub-set of the total data.
Indeed, this is a problem.
I have prototyped a sort by case solution that would allow status to
be sorted by severity. In SQL the case statement can be used to map
a string to an int and then sort the rows based on the int value (ie,
error=0, building=1, active=2, etc.). Using this approach, sorting by
status would result in an enum-like sort (based on severity) instead
of an alphabetical sort based on the English key values. This
solution allows enum-like data to be sorted in a consistent way across
all locales -- the solution is generic and can be applied to any
column where the values are a known set.
The case processing would need to be done in the common paginate_query
function:
https://github.com/openstack/oslo-incubator/blob/master/
openstack/common/db/sqlalchemy/utils.py#L62
This type of sort would not be the default behavior for a status
column (or any enum-like column) and the caller would need to specify
a unique sort direction key for it (ie, 'asc_case' or 'desc_case').
In theory, this type of sorting support could also be globally
enabled/disabled by a deployer (default would be disabled) to further
reduce impact.
Lastly, I have some performance data and sorting the status by case
(vs. alphabetical) has a minimal impact on performance.
Before I create a proposal for juno I wanted to get some early
feedback on the high-level approach. Please reply with feedback on
this solution.
So, I feel that the above solution (while innovative certainly! :) ) is
not actually addressing the underlying source of the problem here, and
that is that statuses are stored in the database as English-language
strings instead of integer code values in a lookup table.
By addressing the underlying source of the problem -- by changing the
instances.{vm,task,power}_state columns to an integer value and using a
lookup table in the cases when translation from code to display is
needed -- we both solve the problem of i18n sorting and increase the
database performance, since queries on these state columns will use an
index on a datatype with a much slimmer width.
Best,
-jay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][L3] Team Meeting Thursday at 1500 UTC
Tomorrow's meeting will be at 1500 UTC in #openstack-meeting-3. The current agenda can be found on the subteam meeting page [1]. There are a few relatively new agenda items in addition to the old favorites. - L3 Vendor plugins. Paul Michali (pcm) has proposed a summit topic on this. - DNS Resolution internal and external to Neutron - Pluggable External Networks Carl Baldwin Neutron L3 Subteam Lead [1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Agenda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Gantt] Scheduler related sessions for the Juno summit
Hi. I just want to be honest here and set expectations. The entire nova track has 27 slots this summit. We need to cover all of the drivers, the transition from nova-network to neutron, the v3 API, and a bunch of other stuff. I can't see a quarter of our slots being used for scheduler topics. At this point I don't know if this means some of these proposals will be rejected, or if they'll be merged -- I'm waiting to see the comments from nova developers first. Michael On Thu, Apr 24, 2014 at 6:09 AM, Sylvain Bauza sylvain.ba...@gmail.com wrote: Hi all, I just noticed (with a slight delay due to lack of notifications from summit.openstack.org) that most of the Nova proposals for sessions were under review with comments. As Scheduler code is on a big turn for Juno with the forklift efforts and the Gantt project, I think it's worth having a whole overview of all the proposals within a single etherpad [1] Proposers, please review the etherpad and add your own sessions if you consider they are related to scheduling efforts. Nova reviewers, feel free to look at this etherpad to see if there are duplicates and comment if so. I'll be glad helping you with triaging all those proposals and making sure we are on the same page. -Sylvain [1] : https://etherpad.openstack.org/p/Gantt-summit-sessions ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Question regarding new panels and tests
Thanks Mainn, that approach does work to get my panels registered for the tests and takes care of all of the errors that I saw. Bad news is that it gives me a couple of new ones. They are pasted here: http://ur1.ca/h5l8u It looks like the panel_group_tests and panel tests want to do a deepcopy on HORIZON_CONFIG, which usually works now fails. In test/settings.py, I can do the deepcopy before I call settings.update_dashboards, but it will fail after the call to update_dashboards. Something non-deep-copy-able must be getting stuck in there, but I can't see it. Any thoughts? Thanks again, Chad - Original Message - From: Tzu-Mainn Chen tzuma...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Wednesday, April 23, 2014 4:23:29 PM Subject: Re: [openstack-dev] [Horizon] Question regarding new panels and tests I have a question about adding new panels with respect to tests. I have a new panel (for the Sahara project, data processing) that lives (for now at least) under the projects folder. The plan is to have it activated only by using the new enabled mechanism to define a new panel group, data processing, where it and several other panels will eventually show up. When I did this, it works fine for me when I run it, but running the tests (tox -e py27) fails because my panel is not registered anywhere. Is there a config for the tests that I can tweak so that my panel can be registered for the tests (tests/enabled or something like that? Thanks, Chad Hiya - I haven't tested this, but one thing you could try. . . if you look at horizon/openstack_dashboard/settings.py, there's a section that determines where the dashboard looks for plugins (https://github.com/openstack/horizon/blob/master/openstack_dashboard/settings.py#L220) # Load the pluggable dashboard settings import openstack_dashboard.enabled import openstack_dashboard.local.enabled from openstack_dashboard.utils import settings INSTALLED_APPS = list(INSTALLED_APPS) # Make sure it's mutable settings.update_dashboards([ openstack_dashboard.enabled, openstack_dashboard.local.enabled, ], HORIZON_CONFIG, INSTALLED_APPS) If you edit horizon/openstack_dashboard/settings.py to add a similar section, only using, say, openstack_dashboard.test.local.enabled, you may be able to enable the panels for the tests there. Mainn ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Performance tests of ceilometer-collector and ceilometer-api with different backends
I am not sure if I read the 'Testing api' section correctly. Is that table in seconds? If so a REST API that takes over two minutes (sample-list for Hbase, meter-list in Mongo) doesn't sound very good. Tim, Joe, in api tests values are in seconds. It's known issues and we will log and meter step by step api work: backend, ceilometer-api, cli. Test results may help find weak link. ++, and also need the SQL driver tested as well. Jay, test results for mysql will be ASAP. Best regards, Tyaptin Ilia, Intern Software Engineer. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Gantt] Scheduler related sessions for the Juno summit
Thanks Michael for the feedback, greatly appreciated :-) Reply inline. 2014-04-23 22:53 GMT+02:00 Michael Still mi...@stillhq.com: Hi. I just want to be honest here and set expectations. The entire nova track has 27 slots this summit. We need to cover all of the drivers, the transition from nova-network to neutron, the v3 API, and a bunch of other stuff. I can't see a quarter of our slots being used for scheduler topics. At this point I don't know if this means some of these proposals will be rejected, or if they'll be merged -- I'm waiting to see the comments from nova developers first. No worries, to be honest, we had no ideas on how many sessions the Scheduler could have for the Summit, hence the idea of tracking all the ideas into a single etherpad. If you take a look at the etherpad, a bunch of 3 slots would potentially allow us to have enough materials for producing outputs. Let's wait for community feedback on the proposals, and we'll see how we can arrange all the ideas the good way. -Sylvain Michael On Thu, Apr 24, 2014 at 6:09 AM, Sylvain Bauza sylvain.ba...@gmail.com wrote: Hi all, I just noticed (with a slight delay due to lack of notifications from summit.openstack.org) that most of the Nova proposals for sessions were under review with comments. As Scheduler code is on a big turn for Juno with the forklift efforts and the Gantt project, I think it's worth having a whole overview of all the proposals within a single etherpad [1] Proposers, please review the etherpad and add your own sessions if you consider they are related to scheduling efforts. Nova reviewers, feel free to look at this etherpad to see if there are duplicates and comment if so. I'll be glad helping you with triaging all those proposals and making sure we are on the same page. -Sylvain [1] : https://etherpad.openstack.org/p/Gantt-summit-sessions ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Gantt] Scheduler related sessions for the Juno summit
I'm not sure we're asking for a quarter of the slots, I agree that would be excessive but there is a significant amount of interest in the scheduler this cycle so we'll have to see what we can come up with. I think we can merge a few things, but that raises the question of what should be the expectation, do you have a feel for how many scheduler sessions we should target? -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 -Original Message- From: Michael Still [mailto:mi...@stillhq.com] Sent: Wednesday, April 23, 2014 2:54 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] [Gantt] Scheduler related sessions for the Juno summit Hi. I just want to be honest here and set expectations. The entire nova track has 27 slots this summit. We need to cover all of the drivers, the transition from nova-network to neutron, the v3 API, and a bunch of other stuff. I can't see a quarter of our slots being used for scheduler topics. At this point I don't know if this means some of these proposals will be rejected, or if they'll be merged -- I'm waiting to see the comments from nova developers first. Michael On Thu, Apr 24, 2014 at 6:09 AM, Sylvain Bauza sylvain.ba...@gmail.com wrote: Hi all, I just noticed (with a slight delay due to lack of notifications from summit.openstack.org) that most of the Nova proposals for sessions were under review with comments. As Scheduler code is on a big turn for Juno with the forklift efforts and the Gantt project, I think it's worth having a whole overview of all the proposals within a single etherpad [1] Proposers, please review the etherpad and add your own sessions if you consider they are related to scheduling efforts. Nova reviewers, feel free to look at this etherpad to see if there are duplicates and comment if so. I'll be glad helping you with triaging all those proposals and making sure we are on the same page. -Sylvain [1] : https://etherpad.openstack.org/p/Gantt-summit-sessions ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [qa] EC2 status and call for assistance
On Wed, Apr 23, 2014 at 12:39 PM, Randy Bias ran...@cloudscaling.comwrote: On Apr 23, 2014, at 12:04 PM, Sean Dague s...@dague.net wrote: We have a bunch of tempest tests we’re ready to push back that increase coverage for the EC2 tests. Also, rather than deprecating the EC2 pieces, which are in use by ~35% of the community, I’d like to recommend we move them into Stackforge as we did with the GCE APIs. That way these can become optional components installed by those who want to use them. The other advantage is that they can be iterated on out of band. I would still like to see them all in the CI system however. Assistance on Tempest would be highly appreciated. I'm a little saddened that there is apparently a large set of out of tree tests that this is the first we've heard of. These would have been good community contributions during the icehouse cycle. Tempest runs like any other part of OpenStack, so a giant dump isn't going to work, and it's going to have to be proposed in manageable and reviewable chunks. If people want EC2 in the main CI it needs to stay in Nova. It's either part of the project, and supported, or it's not, and it's not. It wasn’t intentional. More of a resource constraint issue than anything else. Some of us are at small startups and it can be very challenging to prioritize beyond our immediate needs. I’m in the process of standing up one of the largest OpenStack private clouds out there right now for a Fortune 10 company. That kind of takes precedence. I’m sorry this happens. Your email fortunately catalyzed me to get off my arse, not to mention Joe Gordon prodding me. If being in mainline is required for the CI system, then sure, I prefer the EC2 APIs stay there. I think there should be some thought given to how to support StackForge projects as “nice to haves” in the CI system though. Doesn’t really make sense for something to have to be suddenly thrown over the wall into integrated before being in some kind of CI pipeline. StackForge, as I understand it, is the “official” place for incubating projects. If so, should there be some kind of best effort CI system for those being incubated that have an intention for becoming integrated?? Maybe I just don’t understand how StackForge is supposed to work then. So no one is seriously discussing moving EC2 out of nova right now. The issue is that the EC2 code and tempest tests aren't being maintained are slowly code rotting. The goal of this thread is to get some volunteers to work on EC2. I'd like to see if there are any more people interested in keeping these interfaces functional (by contributing both on the nova and tempest sides). If so, great! We’ll get the new tests we have into some manageable chunks for review and inclusion into tempest mainline. Looking forward to it. Thanks, —Randy Ps. Looping in Reliance as I believe they have skin in the game here as well. Founder CEO, Cloudscaling Board of Directors, OpenStack Foundation +1 (415) 787-2253 [SMS or voice] TWITTER: twitter.com/randybias LINKEDIN: linkedin.com/in/randybias CALENDAR: doodle.com/randybias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
Hey Stephen!
Thanks for the proposal and spending time on it (I know it is a large
time investment). This is actually very similar in structure to
something I had started on except a load balancer object was the root
and it had a one-to-many relationship to VIPs and each VIP had a
one-to-many relationship to listeners. We decided to scrap that because
it became a bit complicated and the concept of sharing VIPs across load
balancers (single port and protocol this time), accomplished the same
thing but with a more streamlined API. The multiple VIPs having
multiple listeners was the main complexity and your proposal does not
have that either.
Anyway, some comments and questions on your proposal are listed below.
Most are minor quibbles, questions and suggestions that can probably be
fleshed out later when we decide on one proposal and I am going to use
your object names as terminology.
1. If a VIP can have IPv4 and IPv6 IPs at the same time is that really a
single VIP? Why not call that a load balancer? I'm always going to
advocate for calling the root object a load balancer, and I think even
in this proposal calling the VIP a load balancer makes sense. Renaming
your model's load balancer to something else should be trivial.
2. How would a user be able to add another IPv4 or IPv6 IP to the same VIP?
3. Pool does not have a subnet attribute, how do you define what subnet
the pool members should be on?
4. In the single create call, how would a user reuse an object that is
defined inside that request body since they will not have an actual id.
5. I would like to see expanded details of child objects when getting
the details of an object (i.e. GET /pools shows details of a health monitor)
6. Why is there a protocol on the pool object and the listener object?
Is this for translating from secure protocols to insecure protocols
(i.e. HTTPS to HTTP).
7. When returning lists of objects (i.e. GET /vips, GET /pools) I'd like
to see the name returned as well.
8. Can all primitives be shared among other parent objects belonging to
the same tenant?
9. can pool members be shared between pools on the same tenant?
-if so, what happens if two pools are sharing the same pool member,
one pool has a health monitor, the other does not. The pool member's
status will get updated to DOWN for both pools.
-if not, why not just make them children resources of /pools (i.e.
/pools/{pool_id}/members).
Again, thanks for spending the time on this. It has a lot of good ideas
and things we did not think about. We've been requested to do a POC of
our proposal, will you and your team be able to do the same?
Thanks,
Brandon
On 04/23/2014 02:15 PM, Stephen Balukoff wrote:
Hi y'all!
As discussed in last week's IRC meeting, my team members and I have
produced a revised draft of the API v2.0 proposal started last week by
the Rackspace crew. (Thanks again for this, y'all-- this helped us get
a heck of a head start on our revised proposal.)
Our v2.0 API proposal revision can be found here:
https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit?usp=sharing
(I've enabled commenting on the above google doc, but for longer
discussion of fundamental issues, let's keep that to this mailing
list, eh!)
Please also pay attention to the Introduction section of this
document: I've defined which glossary of terms we're using there and
provided links to a proposed corresponding object model diagram and
its source. Further, I've pointed out decisions we made drafting this
API as well as issues not yet addressed. I would appreciate your
feedback on all of this (again, the discussions for which should
probably happen on this mailing list).
To get to some of the points I know a lot of people will be interested in:
* This proposal does include a single-call interface for both
creation and deletion, and yes, all primitives can be created
through it.
* This proposal does include L7 functionality support, based
somewhat loosely on the ideas represented here:
https://wiki.openstack.org/wiki/Neutron/LBaaS/l7
* This proposal does include SSL termination and re-encryption
support, based loosely both on what we already do in our
envionment, as well as this:
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL
* We have also tried to keep in mind features in use and requested
in the following two documents as well:
https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements
https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWcusp=sharing
* HA functionality is not addressed in this document, per se, other
than expressing the conviction that however this is handled will
probably not affect the user API expressed in this document. (We
have an ongoing discussion about this going on in another mailing
list thread-- and now that I'm not neck deep in API documentation
I'll
Re: [openstack-dev] [Globalization] REST API sorting by status severity vs. alphabetical status key
On Wed, 2014-04-23 at 15:29 -0500, Steven Kaufer wrote: Thanks for the reply. I agree that changing the datamodel would be the ideal solution. But, to be honest, the scope of that change frightens me. How would you recommend that a change like this would be handled (in addition to the DB migration work)? We obviously cannot break existing codepaths that assume that the existing English key values would be returned from the DB. Is there an existing layer that would perform the mapping between the enum values in the DB and the String keys? Theoretically, at least, all the status values should be using and comparing against constants; see, for instance, nova/compute/vm_states.py. Those could be converted to integers, with a translation table specified in the database migration. The scary thing, though, is just how long that migration will end up taking… -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] status of VPNaaS and FWaaS APIs in Icehouse
Are VPNaaS and FWaaS APIs still considered experimental in Icehouse? For VPNaaS, [1] says This extension is experimental for the Havana release. For FWaaS, [2] says The Firewall-as-a-Service (FWaaS) API is an experimental API... Thanks, - Jack [1] http://docs.openstack.org/api/openstack-network/2.0/content/vpnaas_ext.html [2] http://docs.openstack.org/admin-guide-cloud/content/fwaas.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Globalization] REST API sorting by status severity vs. alphabetical status key
On Wed, 2014-04-23 at 17:19 -0500, Kevin L. Mitchell wrote: On Wed, 2014-04-23 at 15:29 -0500, Steven Kaufer wrote: Thanks for the reply. I agree that changing the datamodel would be the ideal solution. But, to be honest, the scope of that change frightens me. How would you recommend that a change like this would be handled (in addition to the DB migration work)? We obviously cannot break existing codepaths that assume that the existing English key values would be returned from the DB. Is there an existing layer that would perform the mapping between the enum values in the DB and the String keys? Theoretically, at least, all the status values should be using and comparing against constants; see, for instance, nova/compute/vm_states.py. Those could be converted to integers, with a translation table specified in the database migration. The scary thing, though, is just how long that migration will end up taking Worth it, IMO :) There's also a possibility of adding support for the status codes, but keeping the string columns in the database, and then using the nova object versioning to migrate the object schema over time to the point where the migration is a simple DROP COLUMN. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] (no subject)
Hey, I'm looking through the use-cases doc for review, and I'm confused about the 6th one. I'm familiar with HTTP cookie based session persistence, but to satisfy secure-traffic for this case would there be decryption of content, injection of the cookie, and then re-encryption? Is there another session persistence type that solves this issue already? Use Cases: https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis -Trevor Vardeman ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Globalization] REST API sorting by status severity vs. alphabetical status key
On Wed, 2014-04-23 at 18:28 -0400, Jay Pipes wrote: Worth it, IMO :) yeah, we're talking about thousands and thousands of rows that have to be updated before the API can be restarted… There's also a possibility of adding support for the status codes, but keeping the string columns in the database, and then using the nova object versioning to migrate the object schema over time to the point where the migration is a simple DROP COLUMN. I like that idea better, TBH, but we're probably talking about a long-time deprecation here, like on the order of a couple of releases; that would give plenty of time for the majority of the records to be revisited and make the final migration run for a lot shorter time. -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] Agent manager customization
Hi Carl, A clear l3 agent manager interface with hookable methods would clearly simplify the understanding, the dev/support. Difficulties: 1. (un)deployment method names are associated to the triggering event not to performed action: - router deployment is done by _router_added - router gateway deployment/config is done by external_gateway_added - more generally (un)deployments are done by the associated *_added and *_removed methods It implies to fully understand the behaviour of the L3 agent manager in order to check that (un)deployment actions are done and only done by the associated triggering event methods. 2. Because docstrings are missing, i needed to double check previous check. 3. Customization testing is not really easy, because inherited manager implementation could change. So i preferred to perform only black box tests to reduce coupling between implementation and tests. 4. Support: extending a class without a contract/interface implies to perform some adaptations/checks (not so much in practice) simplified by previous tests But that's the topic ! 5. It's not possible currently to change l3 agent manager through configuration - so i must develop my own neutron-l3-agent binary implementation in order to allow providing a custom manager to main() - i must verify my binary was not erased during updates Awkward: 6. (un)deployment methods get the router RouterInfo using different strategies: - _router_added builds it and stores it in self.router_info cache - _router_removed get it from self.router_info cache - external_gateway/internal_network_added/removed get it through arguments 7._router_added and _process_routers have strange behaviours: - _process_routers calls _router_added will verifying to build router RouterInfo object - _router_added computes the router RouterInfo object and store it in self.router_info - _process_routers get it back from self.router_info IMHO, it seems more logical to let - _process_routers builds and stores router RouterInfo object and - _process_routers pass the object as an argument to _router_added The same might apply to _router_removed and _process_routers ? I must share with pcm about L3 Vendor plugins BPs to verify my understanding and possible synergies. But a priori [1] BP seems to be the only synergy candidate. Cedric [1] https://blueprints.launchpad.net/neutron/+spec/l3-svcs-vendor-validation On Tue, Apr 22, 2014 at 6:18 PM, Carl Baldwin c...@ecbaldwin.net wrote: Cedric, I'm just getting back from a short vacation. Please excuse the delayed reply. I have a feeling that this subject may have been discussed in the past before I was very active in Neutron. So, others may chime in if I'm missing something. For the customizations that you're making, it sounds like some sort of hook system would work best. You are currently using inheritance to achieve it but I worry that the L3 agent class has not been designed for this inheritance and may not be entirely suitable for your needs. What has been your experience? Have you found it easy to maintain your subclass as the L3 agent evolves? If not, what problems have you seen? Are there parts of the agent design that made it difficult or awkward? I suspect that a well-designed and stable hook system will better suit your needs in the long run. However, nothing like that exists in the agent now. Is there some synergy here with the L3 Vendor plugins summit topic proposal [1]. Could you look through that proposal and the linked blueprints with that in mind? Carl [1] http://summit.openstack.org/cfp/details/81 On Fri, Apr 18, 2014 at 9:11 AM, zz elle zze...@gmail.com wrote: Hi everyone, I would like to propose a change to simplify/allow l3 agent manager customization and i would like the community feedback. Just to precise my context, I deploy OpenStack for small specific business use cases and i often customize it because of specific use case needs. In particular must of the time i must customize L3 agent behavior in order to: - add custom iptables rules in the router (on router/port post-deployment), - remove custom iptables rules in the router (on port pre-undeployment), - update router config through sysctl (on router post-deployment), - start an application in the router (on router/port post-deployment), - stop an application in the router (on router/port pre-undeployment), - etc ... Currently (Havana,Icehouse), i create my own L3 agent manager which extends neutron one. And I replace neutron-l3-agent binary, indeed it's not possible to change/hook l3 agent manager implementation by configuration. What would be the correct way to allow l3 agent manager customization ? - Allow to specify l3 agent manager implementation through configuration == like the option router_scheduler_driver which allows to change router scheduler implementation - Allow to hook l3 agent manager implementation
Re: [openstack-dev] [nova] [qa] EC2 status and call for assistance
On Thu, Apr 24, 2014 at 4:47 AM, Randy Bias ran...@cloudscaling.com wrote: ... I’d like to recommend we move them into Stackforge as we did with the GCE APIs. That way these can become optional components installed by those who want to use them. The other advantage is that they can be iterated on out of band. I would still like to see them all in the CI system however. How does state mapping work in the stackforge GCE API? The problem we've had in the past is that EC2 requires we create synthetic identifiers for many of our objects and map them to our UUIDs. That mapping is stored in the nova database, and I would be uncomfortable with allowing out of tree code to manipulate our database. I'm hoping the GCE code has solved a similar problem in an interesting way. Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [qa] EC2 status and call for assistance
On Thu, Apr 24, 2014 at 7:39 AM, Joe Gordon joe.gord...@gmail.com wrote: So no one is seriously discussing moving EC2 out of nova right now. The issue is that the EC2 code and tempest tests aren't being maintained are slowly code rotting. The goal of this thread is to get some volunteers to work on EC2. I'd like to see if there are any more people interested in keeping these interfaces functional (by contributing both on the nova and tempest sides). If so, great! Sure, but if this code continues being ignored, then I don't see how we have a choice long term. So a few questions: - who currently ships a private cloud with EC2 enabled? - who has a public cloud with EC2 enabled? These seem like the obvious places to talk to people about helping us get this code maintained before we're forced to drop it. Unfortunately we can't compel people to work on things, but we can make it in their best interests. A followup question as well -- there's a proposal to implement the Nova v2 API on top of the v3 API. Is something similar possible with EC2? Most of the details of EC2 have fallen out of my brain, but I'd be very interested in if such a thing is possible. Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic]problem deploying ironic with devstack
On Mon, Apr 21, 2014 at 3:52 AM, Gopi Krishna Saripuri saripurig...@outlook.com wrote: I'm trying to deploy ironic with devstack. I'm following the instructions @ http://docs.openstack.org/developer/ironic/dev/dev- quickstart.html#deploying-ironic-with-devstack. It is failing to start nova-scheduler and failing with below error. 2014-04-21 08:01:13.005 INFO nova.virt.driver [-] Loading compute driver 'ironic.nova.virt.ironic. IronicDriver' 2014-04-21 08:01:13.006 ERROR nova.virt.driver [-] Unable to load the virtualization driver 2014-04-21 08:01:13.006 TRACE nova.virt.driver Traceback (most recent call last): 2014-04-21 08:01:13.006 TRACE nova.virt.driver File /opt/stack/nova/nova/virt/driver.py, line 1218, in load_compute_driver 2014-04-21 08:01:13.006 TRACE nova.virt.driver virtapi) 2014-04-21 08:01:13.006 TRACE nova.virt.driver File /opt/stack/nova/nova/openstack/common/importutils.py, line 52, in import_object_ns 2014-04-21 08:01:13.006 TRACE nova.virt.driver return import_class(import_str)(*args, **kwargs) 2014-04-21 08:01:13.006 TRACE nova.virt.driver File /opt/stack/nova/nova/openstack/common/importutils.py, line 28, in import_class 2014-04-21 08:01:13.006 TRACE nova.virt.driver __import__(mod_str) 2014-04-21 08:01:13.006 TRACE nova.virt.driver ImportError: No module named nova.virt.ironic 2014-04-21 08:01:13.006 TRACE nova.virt.driver Here is my localrc contents. snip Could someone help me in resolving this issue. I'm trying this on a baremetal server not on vm running ubuntu 12.03. Hi! First of all, I'm not aware of ubuntu 12.03, but I assume that is just a typo and you meant 12.04. Secondly, the error you pasted is from nova-compute, not nova-scheduler. In any case, this sounds like an environment problem - perhaps Ironic is not in python's path, or the version of Ironic you have locally does not contain the nova virt driver. Devstack should have cloned Ironic into /opt/stack/ironic, and the driver should be present at /opt/stack/ironic/ironic/nova/virt/ironic/driver.py Hope that helps, Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder] proposal of definitions/processes for cinder-spec
All, I have gotten questions from our driver developers asking for details regarding the move to using cinder-specs for proposing Blueprints. I brought this topic up in today's Cinder Weekly Meeting, but the meeting was lightly attended so we decided to move the discussion here. I am going to put this note in the form of 'question' and proposed answer based on the brief discussion we had today. Note that the answers here are based on the assumption that we want to keep Cinder's use of 'specs' as close to Nova's as possible. I used the following mailing list thread as a starting point for some of these answers: http://lists.openstack.org/pipermail/openstack-dev/2014-April/032796.html Q: When is a spec approved? A: When it receives a +2 from the PTL and at least one other Core reviewer. Q: How long are specs valid for? A: For the duration of the release cycle. Any specs that are not approved during that period of type will need to be resubmitted for the subsequent release. Q: What will the spec template look like? A: This is one of the points I would like to discuss. The Nova template currently looks like this: https://github.com/openstack/nova-specs/blob/master/specs/template.rst Do we want to follow the same template. In the interest of staying in sync with Nova's implementation I would say yes, but does this meet our needs? Are there other/different fields we want to consider to help for instances where the Blueprint is for a new driver or change to a driver? I think we might need, for instance, a 'Drivers Impacted' field. Q: Will driver developers have to use the same template for functions in their drivers? A: Also a point I would like to discuss. Developers had asked if a more limited template would be used for changes going into the developer's driver. At first I thought maybe a different template for Blueprints against a driver might be appropriate, but after looking more closely at Nova's template perhaps that is not necessary. I would lean towards keeping one template, but maybe not requiring all fields depending on what our final template ends up looking like. Q: Where do specs for python-cinderclient go? A: Looks like Nova has added a python-novaclient directory. I don't think we would need a separate python-cinderclient-specs repository but don't have a strong opinion on this point. I am sure this is not an exhaustive list of questions/answers at this point in time but I wanted to start the discussion so we could help move this process forward. I look forward to your feedback. -Jay Bryant jsbry...@electronicjungle.net Freenode: jungleboyj ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal
Hi Brandon! Thanks for the questions. Responses inline: On Wed, Apr 23, 2014 at 2:51 PM, Brandon Logan brandon.lo...@rackspace.comwrote: Hey Stephen! Thanks for the proposal and spending time on it (I know it is a large time investment). This is actually very similar in structure to something I had started on except a load balancer object was the root and it had a one-to-many relationship to VIPs and each VIP had a one-to-many relationship to listeners. We decided to scrap that because it became a bit complicated and the concept of sharing VIPs across load balancers (single port and protocol this time), accomplished the same thing but with a more streamlined API. The multiple VIPs having multiple listeners was the main complexity and your proposal does not have that either. Anyway, some comments and questions on your proposal are listed below. Most are minor quibbles, questions and suggestions that can probably be fleshed out later when we decide on one proposal and I am going to use your object names as terminology. 1. If a VIP can have IPv4 and IPv6 IPs at the same time is that really a single VIP? Why not call that a load balancer? I'm always going to advocate for calling the root object a load balancer, and I think even in this proposal calling the VIP a load balancer makes sense. Renaming your model's load balancer to something else should be trivial. A couple things about this: The more I think about it, the more I like the idea of not using the term 'loadbalancer' for any of the primitives in the model. In my original version of this we had called the thing presently known as a load balancer a cluster but then that's also a pretty over-used term. The problem with the term loadbalancer is that people seem to jump to conclusions too readily as to what it means (which slows down discussions all over the place-- both talking to users and talking to Neutron core developers).I was *really* tempted to call it what we've started to call it internally (Efkalb reminiscent of the squonky discussion we had earlier)... but then I figured it probably made more sense to stick with the glossary this group has already agreed upon for now. I'm still for changing the name and making the policy decision that no single primitive will be called a loadbalancer. My thought is that this whole project we're working on is the load balancer, but when we're talking about the nitty-gritty details, we should use more specific terms. :/ Having said this, I think VIP still makes good sense for the name of the object that is the root of the user API. One of the key characteristics of a virtual IP as the world knows it is that it can float from machine to machine as necessary. The fact that this object can have both an IPv4 and an IPv6 address just means these addresses should float together. We had considered creating an object that just has an 'ip_address' field and then have an 'address_type' field or something to distinguish it between IPv4 and IPv6. But we decided to go with what's there because of practical considerations: The *only* case we've seen in use by our customers where they want services exposed on both IPv4 and IPv6 is where they're delivering the exact same functionality or content, just over the different IP protocol. This means that in a load balancer configuration, the listeners, pools, rules, SSL certificates, etc. are all the same for both the IPv4 and IPv6 service. To allow for an IPv4 and IPv6 VIP to share all the same child primitives, we'd have to make some kind of other primitive which acts as a join between VIPs and Listeners (as you alluded to above was in your original model), which seemed like a lot more complication than was necessary, considering the only case where we'd likely see it in use. Also, in a lot of actual implementations, it's also more efficient to have a single process listen on multiple IPs if they're going to have the same back-ends, rules, SSL certs, etc. So we cheated a bit, and said a 'VIP' can have both a single IPv4 and a single IPv6 address. It's also worth saying that in designing this object model, we took pains to try to minimize the explosion of too many primitive objects because this leads to a lot of complication that most people never need anyway. And, it's also hard to get this group to agree to drastic changes because backward compatibility, and the need to support the models we do agree on for a very long time factor into the cost of maintaining things. 2. How would a user be able to add another IPv4 or IPv6 IP to the same VIP? A single VIP can have only a single IPv4 address and a single IPv6 address. If you need another IPv4 address, create another VIP. :) 3. Pool does not have a subnet attribute, how do you define what subnet the pool members should be on? So, this is one where I'm a bit torn: It's clear from some of the re-encryption discussion that sometimes members of the same pool will be in different
Re: [openstack-dev] [nova] nova-specs and python-novaclient
On Wed, Apr 23, 2014 at 11:34 PM, Russell Bryant rbry...@redhat.com wrote: John originally mentioned this on the review, but Phil and I both seem to agree. Most novaclient work can just be a work item of a nova blueprint. How about we just handle it that way? For those cases where that's true I agree that's the way to go. I don't really expect any major work in novaclient beyond basic support of new APIs. It seems that the major new work in this area is going into creating a common client. I don't think we should block the possibility of there being a novaclient specific BP sometime in the future. When we think of a good reason for one, let's just put it in a subdirectory. Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Meeting time redux
Seeing as its a global project, there will never be a great time. Alternating in nice, but that has the potential for someone missing important events for having their say cause they may just wait to the next more convenient meeting. We could have meetings based off where most contributors are, but that has the potential of stifling other contributors who want to get more involved (like me, but luckily I'm in Oz so a good timezone for the current meetings). We can keep them as they are, or keep it democratic, I think that the PTL should try and attend most meetings as they have been elected to help guide the project. Seeing as they are elected and should be there how about having a meeting time that best suits them? Tho that would effect me this time :) We vote for PTL so it is democratic, it's always going to be a bad time somewhere in the world, so this makes it fair. And everyone who wants to be involved will always know the time. Best part is, if someone doesn't like it, let them run for PTL. Anyway, that's my 2 cents on the matter. Matt On Apr 24, 2014 5:17 AM, Zane Bitter zbit...@redhat.com wrote: At the beginning of this year we introduced alternating times for the Heat weekly IRC meeting, in the hope that our contributors in Asia would be able to join us. The consensus is that this hasn't worked out as well as we had hoped - even the new time falls at 8am in Beijing, so folks are regularly unable to make the meeting. It also falls at 5pm on the west coast of the US, so folks from there are also regularly unable to make the meeting too. And of course it is in the middle of the night for Europe, so the meeting room looks like a ghost town. Since we are in a new development cycle (with the PTL in a different location) and daylight savings has kicked in/out in many places, let's review our options. Here are our choices as I see it: * Keep going with the current system or some minor tweak to it. * Flip the alternate meeting by 12 hours to 1200 UTC. (8pm in China, late night in Oceania, early-morning on the east coast of the US and we lose the rest of the US.) * Lose all US-based folks and have a meeting for the rest of the world at around 0700 UTC. (US-based folks include me, so I would have to ask someone else to take care of passing on messages-from-the-PTL.) * Abandon the alternating meetings altogether. What would people prefer? I'd particularly like to hear from folks based in Asia what times would enable them to regularly attend, while still ensuring there are other people there to talk to ;) thanks, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat][Summit] Input wanted - real world heat spec
Hi, we've got this summit session planned - http://summit.openstack.org/cfp/details/428 which is really about https://etherpad.openstack.org/p/heat-workflow-vs-convergence We'd love feedback and questions - this is a significant amount of work, but work I (and many others based on responses so far) believe it is needed to really take Heat to users and ops teams. Right now we're looking for both high and low level design and input. If you're an operator/user/developer of/with/around heat - please take a couple of minutes to look - feedback inline in the etherpad, or here on the list - whatever suits you. The basic idea is: - no changes needed to the heat template language etc - take a holistic view and fix the system's emergent properties by using a different baseline architecture within it - ??? - profit! This can be constrasted with many other existing attempts to design solutions which relied on keeping the basic internals of heat as-is and just tweaking things - an approach we don't believe will work - the issues arise from the current architecture, not the quality of the code (which is fine). Cheers, Lifeless, Spamaps and Radix -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Use cases document
Hi Samuel, I'm a little confused what you're asking for: Do you want us to add use cases to the document directly, or discuss them here first and then someone (presumably you?) adds them to the document after it's agreed it's a valid use case? It sounds like one or more of the use cases you've collected so far might have gone missing. Does it make sense to move the list of use cases to the wiki, then, where everyone can edit and there's history kept so mistakes can be rolled back easily? (I ask, because I've been thinking of new use cases all week as I've been working on the API revision proposal, and I'd like to get them recorded and / or discussed.) Stephen On Tue, Apr 22, 2014 at 1:26 AM, Samuel Bercovici samu...@radware.comwrote: Hi, I have seen a few addition to https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1 I think that it would make sense to keep this document with uses cases that were discussed in ML. A use case that I have seen and is missing is related to availability zones. Please feel free to update this and add your own to the document. I have also added sections for Cloud Admin/Cloud Operator use cases. Please add additional use cases based on your experience. Regards, -Sam. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [qa] EC2 status and call for assistance
-Original Message-
From: Michael Still [mailto:mi...@stillhq.com]
Sent: Thursday, April 24, 2014 8:10 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [qa] EC2 status and call for assistance
On Thu, Apr 24, 2014 at 7:39 AM, Joe Gordon joe.gord...@gmail.com wrote:
So no one is seriously discussing moving EC2 out of nova right now. The
issue is that the EC2 code and tempest tests aren't being maintained are
slowly code rotting. The goal of this thread is to get some volunteers to
work on EC2.
I'd like to see if there are any more people interested in keeping these
interfaces functional (by contributing both on the nova and tempest
sides). If so, great!
Sure, but if this code continues being ignored, then I don't see how
we have a choice long term.
So a few questions:
- who currently ships a private cloud with EC2 enabled?
- who has a public cloud with EC2 enabled?
These seem like the obvious places to talk to people about helping us
get this code maintained before we're forced to drop it. Unfortunately
we can't compel people to work on things, but we can make it in their
best interests.
A followup question as well -- there's a proposal to implement the
Nova v2 API on top of the v3 API. Is something similar possible with
EC2? Most of the details of EC2 have fallen out of my brain, but I'd
be very interested in if such a thing is possible.
The difference between v2 and v3 is not so big, and it is easy to
implement v2 API on top of v3 API. However EC2 API is very different
from v2/v3 API, so I think it is difficult to implement EC2 API on top
of v3 API.
Ex) Create a keypair
EC2[1]:
https://ec2.amazonaws.com/?Action=CreateKeyPair
KeyName=my-key-pair
AUTHPARAMS
v2[2]:
http://{nova-api}/v2/{tenant_id}/os-keypairs
{
keypair: {
name: keypair-dab428fe-6186-4a14-b3de-92131f76cd39,
public_key: ssh-rsa B3Nza[..]== Generated by Nova
}
}
I feel it would be nice to keep current EC2 implementation if necessary.
Thanks
Ken'ichi Ohmichi
---
[1]:
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-CreateKeyPair.html
[2]: http://api.openstack.org/api-ref-compute-v2-ext.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] [nova] Havana - Icehouse upgrades with cells
Yeah I’m not sure what’s going on, I removed my hacks and tried it using the conductor rpcapi service and got what I think is a recursive call in nova-conductor. Added more details to https://bugs.launchpad.net/nova/+bug/1308805 I’m thinking there maybe something missing in the stable/havana branch or else cells is doing something different when it comes to objects. I don’t think it is a cells issue though as debugging it, it seems like it just can’t back port a 1.13 object to 1.9. Cheers, Sam On 23 Apr 2014, at 1:01 am, Chris Behrens cbehr...@codestud.com wrote: On Apr 19, 2014, at 11:08 PM, Sam Morrison sorri...@gmail.com wrote: Thanks for the info Chris, I’ve actually managed to get things working. Haven’t tested everything fully but seems to be working pretty good. On 19 Apr 2014, at 7:26 am, Chris Behrens cbehr...@codestud.com wrote: The problem here is that Havana is not going to know how to backport the Icehouse object, even if had the conductor methods to do so… unless you’re running the Icehouse conductor. But yes, your nova-computes would also need the code to understand to hit conductor to do the backport, which we must not have in Havana? OK this conductor api method was actually back ported to Havana, it kept it’s 1.62 version for the method but in Havana conductor manager it is set to 1.58. That is easily fixed but then it gets worse. I may be missing something but the object_backport method doesn’t work at all and looking at the signature never worked? I’ve raised a bug: https://bugs.launchpad.net/nova/+bug/1308805 (CCing openstack-dev and Dan Smith) That looked wrong to me as well, and then I talked with Dan Smith and he reminded me the RPC deserializer would turn that primitive into a an object on the conductor side. The primitive there is the full primitive we use to wrap the object with the versioning information, etc. Does your backport happen to not pass the full object primitive? Or maybe missing the object RPC deserializer on conductor? (I would think that would have to be set in Havana) nova/service.py would have: 194 serializer = objects_base.NovaObjectSerializer() 195 196 self.rpcserver = rpc.get_server(target, endpoints, serializer) 197 self.rpcserver.start() I’m guessing that’s there… so I would think maybe the object_backport call you have is not passing the full primitive. I don’t have the time to peak at your code on github right this second, but maybe later. :) - Chris This also means that if you don’t want your computes on Icehouse yet, you must actually be using nova-conductor and not use_local=True for it. (I saw the patch go up to fix the objects use of conductor API… so I’m guessing you must be using local right now?) Yeah we still haven’t moved to use conductor so if you also don’t use conductor you’ll need the simple fix at bug: https://bugs.launchpad.net/nova/+bug/1308811 So, I think an upgrade process could be: 1) Backport the ‘object backport’ code into Havana. 2) Set up *Icehouse* nova-conductor in your child cells and use_local=False on your nova-computes 3) Restart your nova-computes. 4) Update *all* nova-cells processes (in all cells) to Icehouse. You can keep use_local=False on these, but you’ll need that object conductor API patch. At this point you’d have all nova-cells and all nova-conductors on Icehouse and everything else on Havana. If the Havana computes are able to talk to the Icehouse conductors, they should be able to backport any newer object versions. Same with nova-cells receiving older objects from nova-api. It should be able to backport them. After this, you should be able to upgrade nova-api… and then probably upgrade your nova-computes on a cell-by-cell basis. I don’t *think* nova-scheduler is getting objects yet, especially if you’re somehow magically able to get builds to work in what you tested so far. :) But if it is, you may find that you need to insert an upgrade of your nova-schedulers to Icehouse between steps 3 and 4 above…or maybe just after #4… so that it can backport objects, also. I still doubt this will work 100%… but I dunno. :) And I could be missing something… but… I wonder if that makes sense? What I have is an Icehouse API cell and a Havana compute cell and havana compute nodes with the following changes: Change the method signature of attach_volume to match icehouse, the additional arguments are optional and don’t seem to break things if you ignore them. https://bugs.launchpad.net/nova/+bug/1308846 Needed a small fix for unlocking, there is a race condition that I have a fix for but haven’t pushed up. Then I hacked up a fix for object back porting. The code is at https://github.com/NeCTAR-RC/nova/commits/nectar/havana-icehouse-compat The last three commits are the fixes needed. I still need to push up the unlocking one and
[openstack-dev] PyCon Australia Call For Proposals
Hi There, Just a friendly note that PyCon Australia's call for proposals closes tomorrow. PyCon Australia 2014 will be held in Brisbane 1st-5th of August. OpenStack content is welcome in the main programme. For full details and to submit, see http://2014.pycon-au.org/cfp Cheers, Josh -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Globalization] REST API sorting by status severity vs. alphabetical status key
yeah, we're talking about thousands and thousands of rows that have to be updated before the API can be restarted… There's also a possibility of adding support for the status codes, but keeping the string columns in the database, and then using the nova object versioning to migrate the object schema over time to the point where the migration is a simple DROP COLUMN. I like that idea better, TBH, but we're probably talking about a long-time deprecation here, like on the order of a couple of releases; that would give plenty of time for the majority of the records to be revisited and make the final migration run for a lot shorter time. -- Thanks for the discussion. So how would this new flow work? In Juno would there be an additional status_int column that would be populated and (eventually) replace the existing status (as string) column? How would the object versioning populate the new column for the existing records? Any examples or details that would help explain how this could work would be appreciated. Lastly, is there agreement that this is an issue that needs to be addressed? Note that this seems to be a pervasive problem, I've investigated the status column in cinder and nova but I suspect that the same issue exists in other components. Thanks, Steven Kaufer Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Meeting time redux
Well, in a world where people are driven crazy by all kinds of internal and external work items, it would be definitely difficult to find a time slot that suits everyone. In a MNE like IBM, we always have this problem. We do a lot of meetings in evenings (before 11:30pm most of the time), and some early morning conference calls. At least, losing all US-based folks is not a good option. Having PTL in the discussion is desirable, certainly. Just two cents from me. Regards, - Qiming On Wed, Apr 23, 2014 at 03:12:40PM -0400, Zane Bitter wrote: At the beginning of this year we introduced alternating times for the Heat weekly IRC meeting, in the hope that our contributors in Asia would be able to join us. The consensus is that this hasn't worked out as well as we had hoped - even the new time falls at 8am in Beijing, so folks are regularly unable to make the meeting. It also falls at 5pm on the west coast of the US, so folks from there are also regularly unable to make the meeting too. And of course it is in the middle of the night for Europe, so the meeting room looks like a ghost town. Since we are in a new development cycle (with the PTL in a different location) and daylight savings has kicked in/out in many places, let's review our options. Here are our choices as I see it: * Keep going with the current system or some minor tweak to it. * Flip the alternate meeting by 12 hours to 1200 UTC. (8pm in China, late night in Oceania, early-morning on the east coast of the US and we lose the rest of the US.) * Lose all US-based folks and have a meeting for the rest of the world at around 0700 UTC. (US-based folks include me, so I would have to ask someone else to take care of passing on messages-from-the-PTL.) * Abandon the alternating meetings altogether. What would people prefer? I'd particularly like to hear from folks based in Asia what times would enable them to regularly attend, while still ensuring there are other people there to talk to ;) thanks, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] How to re-compile Devstack Code
Hi, I have Devstack havana setup on Ubuntu 13.10. I am trying to modify some files in /opt/stack/* folder. How do I re-compile the Devstack to make my changes get effect. Does unstacking and stacking works?. I see unstacking and stacking installs everything fresh. Correct me if wrong. Thanks, Shiva ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to re-compile Devstack Code
Hi shiva You can reload the openstack services by following the below steps after making the desired changes.. i) Enter into the devstack directry i.e cd devstack ii) Execute rejoin-stackh.sh i.e ./rejoin-stack.sh iii) Press ctrl+a+shift+ iv) Select the appropriate service to restart Please let me know if further issues. Thanks On Thu, Apr 24, 2014 at 11:12 AM, shiva m anjane...@gmail.com wrote: Hi, I have Devstack havana setup on Ubuntu 13.10. I am trying to modify some files in /opt/stack/* folder. How do I re-compile the Devstack to make my changes get effect. Does unstacking and stacking works?. I see unstacking and stacking installs everything fresh. Correct me if wrong. Thanks, Shiva ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to re-compile Devstack Code
If you put OFFLINE=True in your localrc (or local.conf) file, then you can: ./unstack.sh; ./stack.sh without the stack.sh attempting to recheck out the latest code. Matt On Apr 24, 2014 3:49 PM, shiva m anjane...@gmail.com wrote: Hi, I have Devstack havana setup on Ubuntu 13.10. I am trying to modify some files in /opt/stack/* folder. How do I re-compile the Devstack to make my changes get effect. Does unstacking and stacking works?. I see unstacking and stacking installs everything fresh. Correct me if wrong. Thanks, Shiva ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][blueprint] Accelerate the booting process of a number of vms via VMThunder
For live migration, we use shared storage so I don't think it's quite the same as getting/putting image bits from/to arbitrary locations. Hi, I'm the first author of the TPDS paper of VMThunder. Based on the same techniques and architecture of VMThunder, we have given a new live migration method. As the same as VMThunder, this new live migration method is a storage level solution and can support several kinds of popular hypervisor without modifying them. Technically, this method is a pre-copy and post-copy hybrid method and based on a previous work of ours, which is a live storage migration. (DLSM: Decoupled Live Storage Migration with Distributed Device Mapper Storage. *accepted by t**he 8th IEEE International Symposium on Service-Oriented System Engineering (SOSE)*, Oxford, U.K. April, 2014.) We are now working on this method and preparing to post a new paper to one coming conference. In summary, I think that the architecture of VMThunder is a powerful platform that can support several popular IaaS features, like large scale provisioning, bulk data dissemination, live migration, live spawning, and etc. (VM cluster live spawning is also a current work of us that still under researching) Regards, Thank you! ~-~-~-~-~-~-~-~-~-~-~ Brian Zhaoning Zhang PhD Cand. PDL, NUDT ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Service VMs
+1 for the proposal to make it as separate project. Can we name it as 'Virtue'!!. Any suggestions/comments. Regards, Balaji.P -Original Message- From: Kyle Mestery [mailto:mest...@noironetworks.com] Sent: Wednesday, April 23, 2014 7:17 PM To: OpenStack Development Mailing List (not for usage questions) Cc: isaku yamahata Subject: Re: [openstack-dev] [neutron] Service VMs On Tue, Apr 22, 2014 at 5:49 PM, Isaku Yamahata isaku.yamah...@gmail.com wrote: Hi. Keyle, thank you for starting this discussion to make progress. On Mon, Apr 21, 2014 at 08:41:19PM -0500, Kyle Mestery mest...@noironetworks.com wrote: On Mon, Apr 21, 2014 at 4:20 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Mon, Apr 21, 2014 at 3:07 PM, Kyle Mestery mest...@noironetworks.com wrote: For the upcoming Summit there are 3 sessions filed around Service VMs in Neutron. After discussing this with a few different people, I'd like to propose the idea that the Service VM work be moved out of Neutron and into it's own project on stackforge. There are a few reasons for this: How long do you anticipate the project needing to live on stackforge before it can move to a place where we can introduce symmetric gating with the projects that use it? To be honest, I'm not sure how long it will take. We will see after the summit. At this point, my feeling is - before the summit, preliminary discussion, preparation for the summit - discuss at the summit (including project name?) - after the summit, create its own project on stackforge and start its own activity like weekly IRC meeting. import neutron code repo as the first code base, and cleaning/stripping it up and so on. What do you think? I think this is a good starting plan. The patches for this (look at the BP here [1]) have been in review for a while now as WIP. I think it's reasonable to expect that moving this to stackforge would let the authors and others interested collaborate faster. I expect this would take a cycle on stackforge before we could talk about other projects using this. But honestly, that's a better question for Isaku and Bob. In fact, this is not the first time that such opinion is claimed. But this is the first time to get much feedback. It's good timing to give it a consideration. Just to make it clear, the session slot will be allocated to discuss on this? At least it would be valuable to share the current status and to discuss on its future direction, and which part will be separated out and which part will remain in Neutron. Yes, I will keep this summit session so we can discuss it in Atlanta and move forward from there. Who is going to drive the development work? For that, I'm thinking Isaku and Bob (copied above) would be the ones driving it. But anyone else who is interested should feel free to jump in as well. I'm willing to take the responsibility (and to share it with Bob). Also others to help are very welcome. thanks, Thanks, Kyle [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms Doug 1. There is nothing Neutron specific about service VMs. 2. Service VMs can perform services for other OpenStack projects. 3. The code is quite large and may be better served being inside it's own project. Moving the work out of Neutron and into it's own project would allow for separate velocity for this project, and for code to be shared for the Service VM work for things other than Neutron services. I'm starting this email thread now to get people's feedback on this and see what comments other have. I've specifically copied Isaku and Bob, who both filed summit sessions on this and have done a lot of work in this area to date. Thanks, Kyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
