[openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
Hi all, I see you are discussing that enabling glance API in Nova using Keystone catalog. I think there is one topic related to it that needs to be mentioned here. Hope we can take consideration. Current, Nova use config value glance_api_servers to talk to Glance, but there is one limitation using this configure that glance_api_servers has hard coded Glance API format, we can not configure arbitrary url using this configure, I have created a blueprint to track it. You can get more information https://blueprints.launchpad.net/nova/+spec/nova-enable-glance-arbitrary-url The related bug is https://bugs.launchpad.net/nova/+bug/1220131 On Nov 1, 2013 6:46 PM, John Garbutt j...@johngarbutt.com wrote: On 29 October 2013 16:11, Eddie Sheffield eddie.sheffi...@rackspace.com wrote: John Garbutt j...@johngarbutt.com said: Going back to Joe's comment: Can both of these cases be covered by configuring the keystone catalog? +1 If both v1 and v2 are present, pick v2, otherwise just pick what is in the catalogue. That seems cool. Not quite sure how the multiple glance endpoints works in the keystone catalog, but should work I assume. We hard code nova right now, and so we probably want to keep that route too? Nova doesn't use the catalog from Keystone when talking to Glance. There is a config value glance_api_servers which defines a list of Glance servers that gets randomized and cycled through. I assume that's what you're referring to with we hard code nova. But currently there's nowhere in this path (internal nova to glance) where the keystone catalog is available. Yes. I was not very clear. I am proposing we change that. We could try shoehorn the multiple glance nodes in the keystone catalog, then cache that in the context, but maybe that doesn't make sense. This is a separate change really. FYI: We cache the cinder endpoints from keystone catalog in the context already. So doing something like that with glance won't be without president. But clearly, we can't drop the direct configuration of glance servers for some time either. I think some of the confusion may be that Glanceclient at the programmatic client level doesn't talk to keystone. That happens happens higher in the CLI level which doesn't come into play here. From: Russell Bryant rbry...@redhat.com On 10/17/2013 03:12 PM, Eddie Sheffield wrote: Might I propose a compromise? 1) For the VERY short term, keep the config value and get the change otherwise reviewed and hopefully accepted. 2) Immediately file two blueprints: - python-glanceclient - expose a way to discover available versions - nova - depends on the glanceclient bp and allowing autodiscovery of glance version and making the config value optional (tho not deprecated / removed) Supporting both seems reasonable. At least then *most* people don't need to worry about it and it just works, but the override is there if necessary, since multiple people seem to be expressing a desire to have it available. +1 Can we just do this all at once? Adding this to glanceclient doesn't seem like a huge task. I worry about us never getting the full solution, but it seems to have got complicated. The glanceclient side is done, as far as allowing access to the list of available API versions on a given server. It's getting Nova to use this info that's a bit sticky. Hmm, OK. Could we not just cache the detected version, to reduce the impact of that decision. On 28 October 2013 15:13, Eddie Sheffield eddie.sheffi...@rackspace.com wrote: So...I've been working on this some more and hit a bit of a snag. The Glanceclient change was easy, but I see now that doing this in nova will require a pretty huge change in the way things work. Currently, the API version is grabbed from the config value, the appropriate driver is instantiated, and calls go through that. The problem comes in that the actually glance server isn't communicated with until very late in the process. Nothing sees the servers at the level where the driver is determined. Also there isn't a single glance server but a list of them, and in the even of certain communication failures the list is cycled through until success or a number of retries has passed. So to change this to auto configuring will require turning this upside down, cycling through the servers at a higher level, choosing the appropriate driver for that server, and handling retries at that same level. Doable, but a much larger task than I first was thinking. Also, I don't really want the added overhead of getting the api versions before every call, so I'm thinking that going through the list of servers at startup and discovering the versions then and caching that somehow would be helpful as well. Thoughts? I do worry about that overhead. But with Joe's comment, does it not just boil down
[openstack-dev] [horizon] BootstrapV3 and lessc
Hi, I talked with Jiri Tomasek who is currently in charge of the integration of Bootstrap V3 into Horizon. The integration is currently stuck and was waiting for almost two month that lesscpy could parse the Bootstrap v3 less template. I know that Nodejs was removed because of some dependencies issues in production environment, but we do not need Node in production environment. When node was removed it was compiling the less template at runtime, this is useful in development but not in production. Maybe it is possible to perform a dist task which will compile the less template for the package target. If we keep lesscpy we will have to maintain it every time less pre processor will upgrade, it is a lot of work in addition for few benefits. Currently, a review is waiting for the integration of bootstrap https://review.openstack.org/#/c/49710/ using lessc (node compiler). I need your reviews on this topic because a lot of work is currently done for the ui of Horizon and the integration of Bootstrap v3 is a huge bottleneck for further development. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] BootstrapV3 and lessc
On Monday 04 November 2013 10:52:21 Maxime Vidori wrote: Hi, I talked with Jiri Tomasek who is currently in charge of the integration of Bootstrap V3 into Horizon. The integration is currently stuck and was waiting for almost two month that lesscpy could parse the Bootstrap v3 less template. I know that Nodejs was removed because of some dependencies issues in production environment, but we do not need Node in production environment. Well, not really. As long as COMPRESS_OFFLINE isn't set in your local_settings.py, django_compressor will check if it has compiled CSS files in it's cache and generate them if not. So for a horizon deployment that is setup with the defaults, the very first HTTP request will just trigger the LESS compiler... Regardless of that, nodejs is a huge dependency of which not that many people have long experience with. While I know that nodejs is the new fancy of web development, things where radically different less than 2 years ago. It will the same in 2 years from now. That's why distros want to avoid it if they can. You simply don't know how reliable upstream is. What happens if they need to fix a security issue in that crappy old release that happens to be shipped in, say, openSUSE-12.2. On the other hand. using a pure-Python implementation has countless advantages in our context. It can be handled inside pip requirements files, whereas you need to interact with the underlying distro to get nodejs installed. Also, we where able to drop a pile of bit-rotting Javascript files that we had to copy from nodejs' codebase just because no distro provided less.js so far. When node was removed it was compiling the less template at runtime, this is useful in development but not in production. Maybe it is possible to perform a dist task which will compile the less template for the package target. We discussed this on IRC and I'd say compiling static assets (such as CSS) during sdist / bdist can't really hurt. If we keep lesscpy we will have to maintain it every time less pre processor will upgrade, it is a lot of work in addition for few benefits. Currently, a review is waiting for the integration of bootstrap https://review.openstack.org/#/c/49710/ using lessc (node compiler). Where do you get these numbers? So far, fixing up Lesscpy wasn't such a big task. For bootstrap3 support, the only thing missing was variable support in CSS media queries. I already added some quick hacks to unblock people for the time being (See [0]). LESS the language doesn't change that much, it's CSS3 that adds a ton of new features. I need your reviews on this topic because a lot of work is currently done for the ui of Horizon and the integration of Bootstrap v3 is a huge bottleneck for further development. [0] https://github.com/robotis/Lesscpy/issues/22 -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) signature.asc Description: This is a digitally signed message part. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] BootstrapV3 and lessc
On 11/04/2013 11:41 AM, Sascha Peilicke wrote: On Monday 04 November 2013 10:52:21 Maxime Vidori wrote: Hi, I talked with Jiri Tomasek who is currently in charge of the integration of Bootstrap V3 into Horizon. The integration is currently stuck and was waiting for almost two month that lesscpy could parse the Bootstrap v3 less template. I know that Nodejs was removed because of some dependencies issues in production environment, but we do not need Node in production environment. We didn't had nodejs for a long time in fedora, because it used to bundle a lot of code from other projects. The other issue is, that is a quite fast moving project. When you want a stable platform, you probably don't want to update every two to four weeks to a newer minor-version, and probably want to avoid new major versions at all. So, it ended up in: we compiled LESS code offline and combined that with the package. That is not ideal at all for folks changing the style to give their dashboard another look. I assume, that's a pretty common situation. Regardless of that, nodejs is a huge dependency of which not that many people have long experience with. While I know that nodejs is the new fancy of web development, things where radically different less than 2 years ago. It will the same in 2 years from now. That's why distros want to avoid it if they can. You simply don't know how reliable upstream is. What happens if they need to fix a security issue in that crappy old release that happens to be shipped in, say, openSUSE-12.2. Exactly, just compare the binary size with the size of less sourcecode in horizon sourcecode at all. So, that being said, dropping lesscss in favor of re-integrating node.js is a big step backwards. If there's something missing in lesscpy, we should fix that. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Summit: Late schedule change: Pypy and Py3 / Stable branch maintenance sessions
Hi! I swapped the Pypy and Py3 and Stable branch maintenance sessions in the release management track due to the session lead of one of them being blocked in a conference talk at the same time. People attending those sessions might want to check that their schedule still works out. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] BootstrapV3 and lessc
On Monday 04 November 2013 13:49:20 Matthias Runge wrote: On 11/04/2013 11:41 AM, Sascha Peilicke wrote: On Monday 04 November 2013 10:52:21 Maxime Vidori wrote: Hi, I talked with Jiri Tomasek who is currently in charge of the integration of Bootstrap V3 into Horizon. The integration is currently stuck and was waiting for almost two month that lesscpy could parse the Bootstrap v3 less template. I know that Nodejs was removed because of some dependencies issues in production environment, but we do not need Node in production environment. We didn't had nodejs for a long time in fedora, because it used to bundle a lot of code from other projects. The other issue is, that is a quite fast moving project. When you want a stable platform, you probably don't want to update every two to four weeks to a newer minor-version, and probably want to avoid new major versions at all. So, it ended up in: we compiled LESS code offline and combined that with the package. That is not ideal at all for folks changing the style to give their dashboard another look. I assume, that's a pretty common situation. Just to give people an impression, this is a RPM spec file stripped of everything except the nodejs / offline compression parts: http://paste.opensuse.org/view/raw/8915603 (as seen in [0]) Of course you can bet that your usual consultancy-based PoC deployment won't care about such details o:-) Regardless of that, nodejs is a huge dependency of which not that many people have long experience with. While I know that nodejs is the new fancy of web development, things where radically different less than 2 years ago. It will the same in 2 years from now. That's why distros want to avoid it if they can. You simply don't know how reliable upstream is. What happens if they need to fix a security issue in that crappy old release that happens to be shipped in, say, openSUSE-12.2. Exactly, just compare the binary size with the size of less sourcecode in horizon sourcecode at all. So, that being said, dropping lesscss in favor of re-integrating node.js is a big step backwards. If there's something missing in lesscpy, we should fix that. Matthias [0] https://build.opensuse.org/package/view_file/Cloud:OpenStack:Grizzly/openstack-dashboard/openstack-dashboard.spec?expand=1 -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) signature.asc Description: This is a digitally signed message part. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Mistral] Skipping community meeting on 11/04/2013
Hi, I would suggest we skip today’s community meeting. It is not going to be productive due to HK summit activities. Renat Akhmerov @ Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Re : welcoming new committers (was Re: When is it okay for submitters to say 'I don't want to add tests' ?)
On 10/31/2013 10:36 PM, Jeremy Stanley wrote: As has been said many times already, OpenStack does not lack developers... it lacks reviewers. In regards to reviews in general and in particular for welcoming new committers I think we need to be careful about reviewers NAK'ing a submission for what is essentially bikeshedding [1]. Reviewers should focus on code correctness and adherence to required guidelines and not NAK a submission because the submission offends their personal coding preferences [2]. If a reviewer thinks the code would be better with changes which do not affect correctness and are more in the vein of style modifications they should make helpful suggestions but give the review a 0 instead of actually NAK'ing the submission. NAK'ed reviews based on style issues force the submitter to adhere to someone else's unsubstantiated opinion and slows down the entire contribution process while submissions are reworked multiple times without any significant technical change. It's also demoralizing for submitters to have their contributions NAK'ed for reasons that are issues of opinion only, the submitter has to literally submit [3]. [1] http://en.wiktionary.org/wiki/bikeshedding [2] Despite the best attempts of computer science researchers over the years software development remains more of a craft than a science with unambiguous rules yielding exactly one solution. Often there are many valid approaches to solve a particular coding problem, the selection of one approach often boils down to the personal preferences of the craftsperson. This does not diminish the value of coding guidelines gleaned from years of analyzing software issues, what it does mean is those guidelines still leave plenty of room for different approaches and no one is the arbiter of the one and only correct way. [3] to give over or yield to the power or authority of another. -- John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Horizon OPENSTACK_SSL_NO_VERIFY Question
Hello community, I am trying to go through my OpenStack installation and turn on SSL. For the Horizon server I have found environment variable OPENSTACK_SSL_NO_VERIFY to use with unsigned certificates (set it to True for self-signed certificates). This works great when I turn Keystone SSL on using the self-signed certificates from the keystone-manage command. What I have not been able to find is documentation on what to do if you want SSL verification on using self-signed certificates. How do I tell Horizon what certificates to trust? Regards, Mark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Re : welcoming new committers (was Re: When is it okay for submitters to say 'I don't want to add tests' ?)
Good points from John. The only concern for first time reviewers is that their comments gets overseen by the committer. If the review comment is good, I feel core-reviewer must put some weight on it and thus encourage genuine suggestions. On Mon, Nov 4, 2013 at 9:33 AM, John Dennis jden...@redhat.com wrote: On 10/31/2013 10:36 PM, Jeremy Stanley wrote: As has been said many times already, OpenStack does not lack developers... it lacks reviewers. In regards to reviews in general and in particular for welcoming new committers I think we need to be careful about reviewers NAK'ing a submission for what is essentially bikeshedding [1]. Reviewers should focus on code correctness and adherence to required guidelines and not NAK a submission because the submission offends their personal coding preferences [2]. If a reviewer thinks the code would be better with changes which do not affect correctness and are more in the vein of style modifications they should make helpful suggestions but give the review a 0 instead of actually NAK'ing the submission. NAK'ed reviews based on style issues force the submitter to adhere to someone else's unsubstantiated opinion and slows down the entire contribution process while submissions are reworked multiple times without any significant technical change. It's also demoralizing for submitters to have their contributions NAK'ed for reasons that are issues of opinion only, the submitter has to literally submit [3]. [1] http://en.wiktionary.org/wiki/bikeshedding [2] Despite the best attempts of computer science researchers over the years software development remains more of a craft than a science with unambiguous rules yielding exactly one solution. Often there are many valid approaches to solve a particular coding problem, the selection of one approach often boils down to the personal preferences of the craftsperson. This does not diminish the value of coding guidelines gleaned from years of analyzing software issues, what it does mean is those guidelines still leave plenty of room for different approaches and no one is the arbiter of the one and only correct way. [3] to give over or yield to the power or authority of another. -- John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ravi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon OPENSTACK_SSL_NO_VERIFY Question
You'll want to add the OPENSTACK_SSL_CACERT setting in your local_settings.py and have the value be the path of your CA cert file. I thought it was documented, but looking now, I don't see it. https://github.com/openstack/horizon/blob/master/openstack_dashboard/local/local_settings.py.example#L134 is the best I can point to. I will update the documentation. David -Original Message- From: Miller, Mark M (EB SW Cloud - RD - Corvallis) Sent: Tuesday, November 05, 2013 2:18 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] Horizon OPENSTACK_SSL_NO_VERIFY Question Hello community, I am trying to go through my OpenStack installation and turn on SSL. For the Horizon server I have found environment variable OPENSTACK_SSL_NO_VERIFY to use with unsigned certificates (set it to True for self-signed certificates). This works great when I turn Keystone SSL on using the self-signed certificates from the keystone-manage command. What I have not been able to find is documentation on what to do if you want SSL verification on using self-signed certificates. How do I tell Horizon what certificates to trust? Regards, Mark ___ 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] Improvement of Cinder API wrt https://bugs.launchpad.net/nova/+bug/1213953
So, There's currently an outstanding issue with regards to a Nova shortcut command that creates a volume from an image and then boots from it in one fell swoop. The gist of the issue is that there is currently a set timeout which can time out before the volume creation has finished (it's designed to time out in case there is an error), in cases where the image download or volume creation takes an extended period of time (e.g. under a Gluster backend for Cinder with certain network conditions). The proposed solution is a modification to the Cinder API to provide more detail on what exactly is going on, so that we could programmatically tune the timeout. My initial thought is to create a new column in the Volume table called 'status_detail' to provide more detailed information about the current status. For instance, for the 'downloading' status, we could have 'status_detail' be the completion percentage or JSON containing the total size and the current amount copied. This way, at each interval we could check to see if the amount copied had changed, and trigger the timeout if it had not, instead of blindly assuming that the operation will complete within a given amount of time. What do people think? Would there be a better way to do this? Best Regards, Solly Ross ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Improvement of Cinder API wrt https://bugs.launchpad.net/nova/+bug/1213953
On 11/04/2013 03:49 PM, Solly Ross wrote: So, There's currently an outstanding issue with regards to a Nova shortcut command that creates a volume from an image and then boots from it in one fell swoop. The gist of the issue is that there is currently a set timeout which can time out before the volume creation has finished (it's designed to time out in case there is an error), in cases where the image download or volume creation takes an extended period of time (e.g. under a Gluster backend for Cinder with certain network conditions). The proposed solution is a modification to the Cinder API to provide more detail on what exactly is going on, so that we could programmatically tune the timeout. My initial thought is to create a new column in the Volume table called 'status_detail' to provide more detailed information about the current status. For instance, for the 'downloading' status, we could have 'status_detail' be the completion percentage or JSON containing the total size and the current amount copied. This way, at each interval we could check to see if the amount copied had changed, and trigger the timeout if it had not, instead of blindly assuming that the operation will complete within a given amount of time. What do people think? Would there be a better way to do this? The only other option I can think of would be some kind of callback that cinder could explicitly call to drive updates and/or notifications of faults rather than needing to wait for a timeout. Possibly a combination of both would be best, that way you could add a --poll option to the create volume and boot CLI command. I come from the kernel-hacking world and most things there involve event-driven callbacks. Looking at the openstack code I was kind of surprised to see hardcoded timeouts and RPC casts with no callbacks to indicate completion. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Network topologies
On Nov 2, 2013, at 3:12 PM, Salvatore Orlando sorla...@nicira.com wrote: Hi. I looked at the detailed API specification submitted by Edgar. I think that the document Edgar shared does a fine job in discussion how an API for managing logical topologies should work. On the other hand, there are two aspects which still need some clarification, and which perhaps are at the source of the confusion regarding whether it belongs to neutron, heat, or anywhere else. First, the use cases section merely re-states the objective session. I think that section should somehow address the questions why do we need this API? How having an API for storing network topologies would be useful for us. The other aspect is that - and I might be terribly wrong here - I think that one of the goals Neutron API was already supposed to abstract the complexity of network topologies - if we need another API (or perhaps more aptly an extension of the Neutron API) to satisfy this goal, does this mean the Neutron API is failing in one of its main goals? Not to hijack this thread, but this is exactly the reason Cisco, IBM, Juniper, Nuage Networks, Plexxi, Red Hat and others are proposing the following BP at the Summit this week [1]. I think as you will read in the BP the abstractions of the Neutron API can be extended such that it removes some of the complexity for API users. We have a session Friday afternoon in the Neutron track to discuss these in fact. Looking forwarding to a lively discussion! Thanks, Kyle [1] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?pli=1 Finally it would be interesting to have a few more details concerning how topologies created with this new API would be reflected on the existing data model. While this appears easy for bridges and routers, it is not immediate for other 'nfds' such as dhcp services. Salvatore On 29 October 2013 19:48, Aaron Rosen aro...@nicira.com wrote: Hi Edgar, I definitely see the usecase for the idea that you propose. In my opinion, I don't see the reason for moving the management of topology into neutron, Heat already provides this functionality (besides for the part of taking an existing deployment and generating a template file). Also, I wanted to point out that in a way you will have to do orchestration as you're topology manager will have to call the neutron api in order to create the topology and tear it down. Best, Aaron On Tue, Oct 29, 2013 at 11:33 AM, Edgar Magana emag...@plumgrid.com wrote: Tim, You statement building an api that manages a network topology more than one that needs to build out the dependencies between resources to help create the network topology Is exactly what we are proposing, and this is why we believe this is not under Heat domain. This is why we are NOT proposing to manage any dependency between network elements, that part is what I call intelligence of the orchestration and we are not proposing any orchestration system, you are already have that in place :-) So, we simple want an API that tenats may use to save, retrieve and share topologies. For instance, tenant A creates a topology with two networks (192.168.0.0/24 and 192.168.1.0/24) both with dhcp enabled and a router connecting them. So, we first create it using CLI commands or Horizon and then we call the API to save the topology for that tenant, that topology can be also share between tenants if the owner wanted to do that, the same concept that we have in Neutron for share networks, So Tenant B or any other Tenants, don't need to re-create the whole topology, just open the shared topology from tenant A. Obviously, overlapping IPs will be a must requirement. I am including in this thread to Mark McClain who is the Neutron PTL and the main guy expressing concerns in not having overlapping functionalities between Neutron and Heat or any other project. I am absolutely, happy to discuss further with you but if you are ok with this approach we could start the development in Neutron umbrella, final thoughts? Thanks, Edgar On 10/29/13 8:23 AM, Tim Schnell tim.schn...@rackspace.com wrote: Hi Edgar, It seems like this blueprint is related more to building an api that manages a network topology more than one that needs to build out the dependencies between resources to help create the network topology. If we are talking about just an api to save, duplicate, and share these network topologies then I would agree that this is not something that Heat currently does or should do necessarily. I have been focusing primarily on front-end work for Heat so I apologize if these questions have already been answered. How is this API related to the existing network topology in Horizon? The existing network topology can already define the relationships and dependencies using Neutron I'm assuming so there is no apparent need to use
Re: [openstack-dev] Improvement of Cinder API wrt https://bugs.launchpad.net/nova/+bug/1213953
On Tue, Nov 5, 2013 at 7:27 AM, John Griffith john.griff...@solidfire.com wrote: On Tue, Nov 5, 2013 at 6:29 AM, Chris Friesen chris.frie...@windriver.com wrote: On 11/04/2013 03:49 PM, Solly Ross wrote: So, There's currently an outstanding issue with regards to a Nova shortcut command that creates a volume from an image and then boots from it in one fell swoop. The gist of the issue is that there is currently a set timeout which can time out before the volume creation has finished (it's designed to time out in case there is an error), in cases where the image download or volume creation takes an extended period of time (e.g. under a Gluster backend for Cinder with certain network conditions). The proposed solution is a modification to the Cinder API to provide more detail on what exactly is going on, so that we could programmatically tune the timeout. My initial thought is to create a new column in the Volume table called 'status_detail' to provide more detailed information about the current status. For instance, for the 'downloading' status, we could have 'status_detail' be the completion percentage or JSON containing the total size and the current amount copied. This way, at each interval we could check to see if the amount copied had changed, and trigger the timeout if it had not, instead of blindly assuming that the operation will complete within a given amount of time. What do people think? Would there be a better way to do this? The only other option I can think of would be some kind of callback that cinder could explicitly call to drive updates and/or notifications of faults rather than needing to wait for a timeout. Possibly a combination of both would be best, that way you could add a --poll option to the create volume and boot CLI command. I come from the kernel-hacking world and most things there involve event-driven callbacks. Looking at the openstack code I was kind of surprised to see hardcoded timeouts and RPC casts with no callbacks to indicate completion. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I believe you're referring to [1], which was closed after a patch was added to nova to double the timeout length. Based on comments sounds like your still seeing issues on some Gluster (maybe other) setups? Rather than mess with the API in order to do debug, why don't you use the info in the cinder-logs? [1] https://bugs.launchpad.net/nova/+bug/1213953 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Choice of API infrastructure
On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes jaypi...@gmail.com wrote: On 11/02/2013 11:26 PM, Russell Bryant wrote: On 11/02/2013 11:54 AM, Adrian Otto wrote: Noorul, I agree that key decisions should be tracked in blueprints. This is the one for this decision which was made in our 2013-10-18 public meeting. Jay's submission is consistent with the direction indicated by the team. https://blueprints.launchpad.net/solum/+spec/rest-api-base Transcript log: http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html Heh, not much discussion there. :-) Agreed. I actually didn't know anything about the discussion -- I wasn't at the meeting. I just figured I would throw some example code up to Gerrit that shows how Falcon can be used for the API plumbing. Like I mentioned in a previous email, I believe it's much easier to discuss things when there is sample code... Here's my take ... Pecan+WSME has been pushed as the thing to standardize on across most OpenStack APIs. Ceilometer (and maybe others?) are already using it. Others, such as Nova, are planning to use it this cycle. [1][2] I've used both actually, and I've come to prefer Falcon because of its simplicity and specifically because of the following things: * It's lack of integration with WSME, which I don't care for. I don't care for WSME because I believe it tries to put the model at the view layer, instead of where it belongs, at the model layer. The models defined in WSME are completely different from the database models, and should not be used outside of the API code. Think of them as declaring the models for the consumer of the API, rather than the implementer of the API. The benefits of declaring WSME classes include automatic serialization in JSON and XML, generating WADL files to be included in the API docs (work is already happening to make this available for everyone), and consistent input and output types for API endpoints (making it easier for consumers of the API to use it and for implementers to validate inputs and assume consistent defaults). And, to be clear, Pecan and WSME are integrated by Pecan can definitely be used without WSME. I included WSME in the proposal to replace the home-grown WSGI framework because I thought it added significant benefits, but it is not going to be appropriate for all situations (streaming large image files is one example). * It doesn't need a configuration file, specifically a configuration file that is a Python file as opposed to an .ini file. Pecan does not require a configuration file. It can use one, but we set up the WSGI app factory in ceilometer to not use one and I expect the other projects to work the same way. Tuesday (today) at 2:00 there is a session in the Oslo track ( http://icehousedesignsummit.sched.org/event/b2680d411aa7f5d432438a435ac21fee) to discuss tips and pain points with Pecan WSME. I didn't intend to revisit the decision to start adopting either (we've spent an hour at each of the last summits going over that, as well as many email threads), but I do want to clear up any other misconceptions and discuss issues with either tool so that feedback can be incorporated upstream. Now that both Pecan and WSME are on stackforge, we have already had a few patches from OpenStack developers intended to improve and adjust them to meet our needs better. Doug I care less about the particular choice and more about consistency. It brings a lot of value, such as making it a lot easier for developers to jump around between the OpenStack projects. Can we first at least agree that there is value in standardizing on *something* for most OpenStack APIs? I completely understand the need for consistency. I pushed my patch as an example of how to do things the Falcon way. While I would prefer Falcon over Pecan (and certainly over Pecan+WSME), I will respect the push towards consistency if that's what is most important. That said, I also believe that the projects in Stackforge should be the laboratories of experiment, and these projects may serve as a good playground for various implementations of things. I remind the reader that over time, the development community has standardized on various things, only to find a better implementation in an incubated project. Pecan+WSME is actually an example of that experimentation turned accepted standard. Best, -jay I understand that there may be cases where the needs for an API justify being different. Marconi being more of a data-plane API vs control-plane means that performance concerns are much higher, for example. If we agree that consistency is good, does Solum have needs that make it different than the majority of OpenStack APIs? IMO, it does not. Can someone lay out a case for why all OpenStack projects should be using Falcon, if that's what you think Solum should use? Also, is anyone willing to put up
[openstack-dev] [oslo][heat]node.js RPC library
Hi I have a node.js application which needs to communicate with openstack modules. Is there a reference implementation of RPC cast() and call() over amqp? I looked at rpc-amqp module which doesn't seem to support cast(). Thanks for your help. Regards Subra ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Choice of API infrastructure
Doug Hellmann doug.hellm...@dreamhost.com writes: On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes jaypi...@gmail.com wrote: On 11/02/2013 11:26 PM, Russell Bryant wrote: On 11/02/2013 11:54 AM, Adrian Otto wrote: Noorul, I agree that key decisions should be tracked in blueprints. This is the one for this decision which was made in our 2013-10-18 public meeting. Jay's submission is consistent with the direction indicated by the team. https://blueprints.launchpad.net/solum/+spec/rest-api-base Transcript log: http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html Heh, not much discussion there. :-) Agreed. I actually didn't know anything about the discussion -- I wasn't at the meeting. I just figured I would throw some example code up to Gerrit that shows how Falcon can be used for the API plumbing. Like I mentioned in a previous email, I believe it's much easier to discuss things when there is sample code... Here's my take ... Pecan+WSME has been pushed as the thing to standardize on across most OpenStack APIs. Ceilometer (and maybe others?) are already using it. Others, such as Nova, are planning to use it this cycle. [1][2] I've used both actually, and I've come to prefer Falcon because of its simplicity and specifically because of the following things: * It's lack of integration with WSME, which I don't care for. I don't care for WSME because I believe it tries to put the model at the view layer, instead of where it belongs, at the model layer. The models defined in WSME are completely different from the database models, and should not be used outside of the API code. Think of them as declaring the models for the consumer of the API, rather than the implementer of the API. The benefits of declaring WSME classes include automatic serialization in JSON and XML, generating WADL files to be included in the API docs (work is already happening to make this available for everyone), and consistent input and output types for API endpoints (making it easier for consumers of the API to use it and for implementers to validate inputs and assume consistent defaults). And, to be clear, Pecan and WSME are integrated by Pecan can definitely be used without WSME. I included WSME in the proposal to replace the home-grown WSGI framework because I thought it added significant benefits, but it is not going to be appropriate for all situations (streaming large image files is one example). * It doesn't need a configuration file, specifically a configuration file that is a Python file as opposed to an .ini file. Pecan does not require a configuration file. It can use one, but we set up the WSGI app factory in ceilometer to not use one and I expect the other projects to work the same way. I see that in ceilometer project has both pypy and py33 gates switched off. Is this because of Pecan + WSME? From one of the conversations on IRC, it looks like Solum project would like to be py33 compatible from the beginning. Having said that, pecan fails to install on pypy and py33. See https://review.openstack.org/#/c/55083 Thanks and Regards Noorul Tuesday (today) at 2:00 there is a session in the Oslo track ( http://icehousedesignsummit.sched.org/event/b2680d411aa7f5d432438a435ac21fee) to discuss tips and pain points with Pecan WSME. I didn't intend to revisit the decision to start adopting either (we've spent an hour at each of the last summits going over that, as well as many email threads), but I do want to clear up any other misconceptions and discuss issues with either tool so that feedback can be incorporated upstream. Now that both Pecan and WSME are on stackforge, we have already had a few patches from OpenStack developers intended to improve and adjust them to meet our needs better. Doug I care less about the particular choice and more about consistency. It brings a lot of value, such as making it a lot easier for developers to jump around between the OpenStack projects. Can we first at least agree that there is value in standardizing on *something* for most OpenStack APIs? I completely understand the need for consistency. I pushed my patch as an example of how to do things the Falcon way. While I would prefer Falcon over Pecan (and certainly over Pecan+WSME), I will respect the push towards consistency if that's what is most important. That said, I also believe that the projects in Stackforge should be the laboratories of experiment, and these projects may serve as a good playground for various implementations of things. I remind the reader that over time, the development community has standardized on various things, only to find a better implementation in an incubated project. Pecan+WSME is actually an example of that experimentation turned accepted standard. Best, -jay I understand that there may be cases where the needs for an API justify
Re: [openstack-dev] [nova][scheduler]The database access in the scheduler filters
I agree that this will have benefit , but how much the benefit is may highly depends on the type of instance created. If most of the instance are normal instance w/o any special requirement, we will have no benefit at all. Thanks --jyh -Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: Sunday, November 03, 2013 12:12 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova][scheduler]The database access in the scheduler filters On 11/01/2013 06:39 AM, Jiang, Yunhong wrote: I noticed several filters (AggregateMultiTenancyIsoaltion, ram_filter, type_filter, AggregateInstanceExtraSpecsFilter) have DB access in the host_passes(). Some will even access for each invocation. Just curios if this is considered a performance issue? With a 10k nodes, 60 VM per node, and 3 hours VM life cycle cloud, it will have more than 1 million DB access per second. Not a small number IMHO. On a somewhat related note, here's an idea that would be pretty easy to implement. What if we added some optional metadata to scheduler filters to let them indicate where in the order of filters they should run? The filters you're talking about here we would probably want to run last. Other filters that could potentially efficiently eliminate a large number of hosts should be run first. -- Russell Bryant ___ 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][heat]node.js RPC library
On 11/04/2013 05:04 PM, Subrahmanyam Ongole wrote: Hi I have a node.js application which needs to communicate with openstack modules. Is there a reference implementation of RPC cast() and call() over amqp? I looked at rpc-amqp module which doesn't seem to support cast(). Thanks for your help. Subra, The RPC API is meant to be internal. Why not use the REST APIs? Plenty of infrastructure exists to work with rest apis in varoius languages/framewroks. For example, heat doesn't circumvent the REST APIs of OpenStack services and communicate with nova directly, but uses the nova rest API. Why would an application that is not integrated into OpenStack behave this way when those that are Integrated use rest APIs direclty? Regards -steve Regards Subra ___ 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] [Solum] : Lightening Talks and Unconference Sessions
1. Lightening Talk: Today (Tuesday) at 1:40 pm 2. Unconference: Solum- Goal, Vision, Roadmap: Wednesday 12:05 -12:45 pm 3. Unconference: Solum - what OpenStack services should it leverage: Thursday 5:20 - 6:00 pm See you all there!! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Climate Summit Unconference
Hello everyone! We will have unconference talk about Climate (OpenStack Reservation Service) tomorrow, 2 PM local Hong Kong time! We are waiting you in Meeting Room 2, SkyCity Marriott. Thank you and you are welcome! Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum]: Welcome to the community site for Solum !!
The community site for Solum has gone live! www.Solum.iohttp://www.Solum.io - this is a landing page for all things Solum related. Also check out the blog section on the site. The logo: is a placeholder for now. We are working on a cool new logo - but the placeholder right now isn't too bad either, is it? ___ 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 etherpads
Steve, Can we meet to talk about the network topologies BP? If you have an open spot I want to chat about it with Heat team Sent from my iPhone On Nov 5, 2013, at 9:19 AM, Steve Baker sba...@redhat.com wrote: Placeholder etherpads have now been created for Heat's design summit sessions on Thursday and Friday. https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads#Heat ___ 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] Network topologies
Excerpts from Kyle Mestery (kmestery)'s message of 2013-11-05 06:35:04 +0800: On Nov 2, 2013, at 3:12 PM, Salvatore Orlando sorla...@nicira.com wrote: Hi. I looked at the detailed API specification submitted by Edgar. I think that the document Edgar shared does a fine job in discussion how an API for managing logical topologies should work. On the other hand, there are two aspects which still need some clarification, and which perhaps are at the source of the confusion regarding whether it belongs to neutron, heat, or anywhere else. First, the use cases section merely re-states the objective session. I think that section should somehow address the questions why do we need this API? How having an API for storing network topologies would be useful for us. The other aspect is that - and I might be terribly wrong here - I think that one of the goals Neutron API was already supposed to abstract the complexity of network topologies - if we need another API (or perhaps more aptly an extension of the Neutron API) to satisfy this goal, does this mean the Neutron API is failing in one of its main goals? Not to hijack this thread, but this is exactly the reason Cisco, IBM, Juniper, Nuage Networks, Plexxi, Red Hat and others are proposing the following BP at the Summit this week [1]. I think as you will read in the BP the abstractions of the Neutron API can be extended such that it removes some of the complexity for API users. We have a session Friday afternoon in the Neutron track to discuss these in fact. Looking forwarding to a lively discussion! Thanks, Kyle [1] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?pli=1 Hi Kyle, can you copy this to etherpad.openstack.org and link it from https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads Thanks! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Mistral] HK Lightning talk at 1.35 pm
Hello everyone, I’d like to invite everyone to Mistral Lightning Talk that will be at 1.35 pm on Tuesday (today) in Expo Breakout Room 1. Looking forward to see you there! Renat Akhmerov @ Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Murano] Summit activities
Hi folks, OpenStack summit has begun, and we have pretty large part of the Murano team here in Hong Kong. You may always find me or anybody else from Mirantis - and we will be happy to answer any questions. Also, we have a Lighting Talk planned for tomorrow at 1:35 pm - I will quickly cover the updated vision of our mission. Also, on Friday at 11 am, as part of unconference track we'll have a session dedicated to discussing of Murano Application catalog use cases and roadmap. Also, feel free to come to Mirantis booth - we have the demo of our products there, and will be happy to answer any questions as well. See you at the summit! -- Kind Regards, Alexander Tivelkov Principal Software Engineer OpenStack Platform Product division Mirantis, Inc +7(495) 640 4904, ext 0236 +7-926-267-37-97(cell) Vorontsovskaya street 35 B, building 3, Moscow, Russia. ativel...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Mistral] HK Unconference talk on Thursday
Hi, We registered an Unconference talk for Mistral. Location: SkyCity Marriott, Meeting room 2 Time: on Thursday, 11.00am Everyone is welcome to join us there and discuss whatever you’re interested in! Renat Akhmerov @ Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum]: Welcome to the community site for Solum !!
This is cool, I think other OpenStack projects would do well to have a more user-centric landing page. I have a suggestion for a logo for Solum though ... http://www.openstack.org/brand/openstack-logo/ What I mean is, rather than create a new brand.. enhance the OpenStack brand with users. Excerpts from Roshan Agrawal's message of 2013-11-05 09:25:33 +0800: The community site for Solum has gone live! www.Solum.iohttp://www.Solum.io - this is a landing page for all things Solum related. Also check out the blog section on the site. The logo: is a placeholder for now. We are working on a cool new logo - but the placeholder right now isn't too bad either, is it? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] HK Summit - Image Creation and Customization unconference?
(Forgive the top-post) Done. I have requested: 3:30 - 4:10 PM Meeting Room 2 The State of Image Building As I say, I can speak briefly to the work we've been doing with Nova native image building but would be very interested to meet up with other interested parties who are approaching the fundamental problem of image construction and customization in OpenStack. -Ian On Thu, 2013-10-31 at 15:05 -0500, Ian McLeod wrote: On Thu, 2013-10-31 at 12:50 -0700, Mark Washenberger wrote: On Thu, Oct 31, 2013 at 12:20 PM, Ian McLeod imcl...@redhat.com wrote: On Thu, 2013-10-31 at 11:56 -0700, Clint Byrum wrote: Excerpts from Ian McLeod's message of 2013-10-31 11:27:39 -0700: Hello, Would any of you attending the summit be interested in snagging an unconference session to discuss the state of play with image creation, customization and import? I can contribute an overview and demonstration of our Nova-native image building tool. I'd be interested in exploring integration points with Disk Image Builder and Glance. Any takers? Sounds like a good opportunity! So any time Wednesday onward? That broad schedule constraint is good for Glance as well, as all of our sessions are on Tuesday. Cool. I'm not arriving until late Monday. I've asked russellb to try to grab an unconference slot. However, I suppose I should just extend this request to anyone who is interested. So, could I ask that any interested parties look at the unconference signup sheet when you arrive and, if you don't already see: Image Building and Customization please grab a time slot from Wednesday onward? -Ian ___ 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
[openstack-dev] [Trove][Savanna][Murano] Unified Agent proposal discussion at Summit
Hi guys, Recently we had several discussions about the guest VM agents: lot's of projects have the similar needs to run some special logic on the side of guest virtual machines. As far as I know, there are such agents in Savanna, Trove, Murano and may be some other projects as well. The obvious idea is to unite the efforts and have the unified solution which may satisfy everybody's needs. We've discussed this topic before with some of the teams, and got the promising-looking idea to create kind of unified agent library and put it in Oslo or some other shared project. We've scheduled an unconference session on the Summit, this Friday at 3:10 pm. Let's continue discussing the idea there: we may gather the common requirements, discuss the basic design concepts etc. See you there! -- Kind Regards, Alexander Tivelkov Principal Software Engineer OpenStack Platform Product division Mirantis, Inc +7(495) 640 4904, ext 0236 +7-926-267-37-97(cell) Vorontsovskaya street 35 B, building 3, Moscow, Russia. ativel...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Choice of API infrastructure
Doug, I respect you very much as an engineer and as a community member, so I want to preface this with a very important dislaimer: don't take these opinions as anything more than what they are...a discussion of differing viewpoints. Comments inline. On 11/04/2013 06:58 PM, Doug Hellmann wrote: On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: On 11/02/2013 11:26 PM, Russell Bryant wrote: On 11/02/2013 11:54 AM, Adrian Otto wrote: Noorul, I agree that key decisions should be tracked in blueprints. This is the one for this decision which was made in our 2013-10-18 public meeting. Jay's submission is consistent with the direction indicated by the team. https://blueprints.launchpad.__net/solum/+spec/rest-api-base https://blueprints.launchpad.net/solum/+spec/rest-api-base Transcript log: http://irclogs.solum.io/2013/__solum.2013-10-08-16.01.log.__html http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html http://irclogs.solum.io/2013/__solum.2013-10-08-16.01.log.__html http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html Heh, not much discussion there. :-) Agreed. I actually didn't know anything about the discussion -- I wasn't at the meeting. I just figured I would throw some example code up to Gerrit that shows how Falcon can be used for the API plumbing. Like I mentioned in a previous email, I believe it's much easier to discuss things when there is sample code... Here's my take ... Pecan+WSME has been pushed as the thing to standardize on across most OpenStack APIs. Ceilometer (and maybe others?) are already using it. Others, such as Nova, are planning to use it this cycle. [1][2] I've used both actually, and I've come to prefer Falcon because of its simplicity and specifically because of the following things: * It's lack of integration with WSME, which I don't care for. I don't care for WSME because I believe it tries to put the model at the view layer, instead of where it belongs, at the model layer. The models defined in WSME are completely different from the database models, and should not be used outside of the API code. Think of them as declaring the models for the consumer of the API, rather than the implementer of the API. I don't really see the point of the distinction. At the end of the day, the consumer of the API is using the API to manipulate and retrieve data. That data is really the model, with some syntactic sugar like Atom links, etc. Even in a control API -- as opposed to a data API like Glance, Ceilometer or Swift -- the benefits of a heavy API layer like Pecan and WSME are pretty small, IMO. I would much rather see the Ceilometer models [1] actually be models that can validate the data that is used to construct the model object instead of having duplicated WSME models repeated in the WSGI controller code [2]. The reason is because if/when I decide to make a Ceilometer API that uses a different protocol, say AMQP, instead of HTTP, now I need to duplicate all of the validation code that WSME is providing on the data model layer... however if the validation was in the models themselves, I could easily create an API on a different protocol using just the models for validation. The benefits of declaring WSME classes include automatic serialization in JSON and XML, generating WADL files to be included in the API docs (work is already happening to make this available for everyone), and consistent input and output types for API endpoints (making it easier for consumers of the API to use it and for implementers to validate inputs and assume consistent defaults). I can't stand XML. I believe it should be retired to the dustbin of coding history, like Basic. That said, consumers of a RESTful API don't care how the API is implemented. They care that it's documented and consistent, and if WSME makes API documentation easier, then that's A Good Thing, agreed. It's true that WSME includes some stuff to make validating inputs easier, but it does so, IMHO, at the expense of readability because everything is decorated and hidden away somewhere other than the models themselves. See note above... And, to be clear, Pecan and WSME are integrated by Pecan can definitely be used without WSME. I included WSME in the proposal to replace the home-grown WSGI framework because I thought it added significant benefits, but it is not going to be appropriate for all situations (streaming large image files is one example). * It doesn't need a configuration file, specifically a configuration file that is a Python file as opposed to an .ini file. Pecan does not require a configuration file. It can use one, but we set up the WSGI
Re: [openstack-dev] [Heat] Network topologies
On Nov 4, 2013, at 7:31 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Kyle Mestery (kmestery)'s message of 2013-11-05 06:35:04 +0800: On Nov 2, 2013, at 3:12 PM, Salvatore Orlando sorla...@nicira.com wrote: Hi. I looked at the detailed API specification submitted by Edgar. I think that the document Edgar shared does a fine job in discussion how an API for managing logical topologies should work. On the other hand, there are two aspects which still need some clarification, and which perhaps are at the source of the confusion regarding whether it belongs to neutron, heat, or anywhere else. First, the use cases section merely re-states the objective session. I think that section should somehow address the questions why do we need this API? How having an API for storing network topologies would be useful for us. The other aspect is that - and I might be terribly wrong here - I think that one of the goals Neutron API was already supposed to abstract the complexity of network topologies - if we need another API (or perhaps more aptly an extension of the Neutron API) to satisfy this goal, does this mean the Neutron API is failing in one of its main goals? Not to hijack this thread, but this is exactly the reason Cisco, IBM, Juniper, Nuage Networks, Plexxi, Red Hat and others are proposing the following BP at the Summit this week [1]. I think as you will read in the BP the abstractions of the Neutron API can be extended such that it removes some of the complexity for API users. We have a session Friday afternoon in the Neutron track to discuss these in fact. Looking forwarding to a lively discussion! Thanks, Kyle [1] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?pli=1 Hi Kyle, can you copy this to etherpad.openstack.org and link it from https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads Hi Clint: I've already posted an etherpad there, it's in fact at this link [1]. I've copied some notes there, it's hard to translate the diagrams but what I've put in there is enough to get the discussion going on Friday. Thanks, Kyle [1] https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neutron Thanks! ___ 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] Heat lunch
At 12:45 there will be a Heat lunch where anybody who wants to meet the Heat team is welcome to attend. The plan is to attempt to claim some tables in Exhibition Hall 3, near the Demo Theatre, on the tables next to the ping pong. I'll try to claim tables 230 and 231, or tables nearby. It would be great to meet you all and start our numerous discussions! cheers ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Summit: Late schedule change: Pypy and Py3 / Stable branch maintenance sessions
Thierry Carrez wrote: Hi! I swapped the Pypy and Py3 and Stable branch maintenance sessions in the release management track due to the session lead of one of them being blocked in a conference talk at the same time. People attending those sessions might want to check that their schedule still works out. So that created more problems than it solved... I just put the Py3/Pypy session back where it was (Friday morning), and swapped Vulnerability management and Stable maintenance instead. Hopefully that will cause less problems... -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Choice of API infrastructure
On Tue, Nov 5, 2013 at 8:11 AM, Noorul Islam K M noo...@noorul.com wrote: Doug Hellmann doug.hellm...@dreamhost.com writes: On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes jaypi...@gmail.com wrote: On 11/02/2013 11:26 PM, Russell Bryant wrote: On 11/02/2013 11:54 AM, Adrian Otto wrote: Noorul, I agree that key decisions should be tracked in blueprints. This is the one for this decision which was made in our 2013-10-18 public meeting. Jay's submission is consistent with the direction indicated by the team. https://blueprints.launchpad.net/solum/+spec/rest-api-base Transcript log: http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html Heh, not much discussion there. :-) Agreed. I actually didn't know anything about the discussion -- I wasn't at the meeting. I just figured I would throw some example code up to Gerrit that shows how Falcon can be used for the API plumbing. Like I mentioned in a previous email, I believe it's much easier to discuss things when there is sample code... Here's my take ... Pecan+WSME has been pushed as the thing to standardize on across most OpenStack APIs. Ceilometer (and maybe others?) are already using it. Others, such as Nova, are planning to use it this cycle. [1][2] I've used both actually, and I've come to prefer Falcon because of its simplicity and specifically because of the following things: * It's lack of integration with WSME, which I don't care for. I don't care for WSME because I believe it tries to put the model at the view layer, instead of where it belongs, at the model layer. The models defined in WSME are completely different from the database models, and should not be used outside of the API code. Think of them as declaring the models for the consumer of the API, rather than the implementer of the API. The benefits of declaring WSME classes include automatic serialization in JSON and XML, generating WADL files to be included in the API docs (work is already happening to make this available for everyone), and consistent input and output types for API endpoints (making it easier for consumers of the API to use it and for implementers to validate inputs and assume consistent defaults). And, to be clear, Pecan and WSME are integrated by Pecan can definitely be used without WSME. I included WSME in the proposal to replace the home-grown WSGI framework because I thought it added significant benefits, but it is not going to be appropriate for all situations (streaming large image files is one example). * It doesn't need a configuration file, specifically a configuration file that is a Python file as opposed to an .ini file. Pecan does not require a configuration file. It can use one, but we set up the WSGI app factory in ceilometer to not use one and I expect the other projects to work the same way. I see that in ceilometer project has both pypy and py33 gates switched off. Is this because of Pecan + WSME? From one of the conversations on IRC, it looks like Solum project would like to be py33 compatible from the beginning. No, that is not because of Pecan and WSME. The rest of ceilometer is not yet working on python 3 or pypy, as far as I know. Having said that, pecan fails to install on pypy and py33. See https://review.openstack.org/#/c/55083 Pecan tests run under python 3.3 and WSME runs under both python 3.3 and pypy. It looks like the issue with that changeset is an upstream dependency. In the past when we've seen that error it had to do with pbr and versions of setuptools, but I don't know if that's what's going on in this case. Doug Thanks and Regards Noorul Tuesday (today) at 2:00 there is a session in the Oslo track ( http://icehousedesignsummit.sched.org/event/b2680d411aa7f5d432438a435ac21fee ) to discuss tips and pain points with Pecan WSME. I didn't intend to revisit the decision to start adopting either (we've spent an hour at each of the last summits going over that, as well as many email threads), but I do want to clear up any other misconceptions and discuss issues with either tool so that feedback can be incorporated upstream. Now that both Pecan and WSME are on stackforge, we have already had a few patches from OpenStack developers intended to improve and adjust them to meet our needs better. Doug I care less about the particular choice and more about consistency. It brings a lot of value, such as making it a lot easier for developers to jump around between the OpenStack projects. Can we first at least agree that there is value in standardizing on *something* for most OpenStack APIs? I completely understand the need for consistency. I pushed my patch as an example of how to do things the Falcon way. While I would prefer Falcon over Pecan (and
Re: [openstack-dev] HK Summit - Image Creation and Customization unconference?
Apologies, updated with the day. (Thursday) On Mon, 2013-11-04 at 20:10 -0600, Ian McLeod wrote: (Forgive the top-post) Done. I have requested: Thursday 3:30 - 4:10 PM Meeting Room 2 The State of Image Building As I say, I can speak briefly to the work we've been doing with Nova native image building but would be very interested to meet up with other interested parties who are approaching the fundamental problem of image construction and customization in OpenStack. -Ian On Thu, 2013-10-31 at 15:05 -0500, Ian McLeod wrote: On Thu, 2013-10-31 at 12:50 -0700, Mark Washenberger wrote: On Thu, Oct 31, 2013 at 12:20 PM, Ian McLeod imcl...@redhat.com wrote: On Thu, 2013-10-31 at 11:56 -0700, Clint Byrum wrote: Excerpts from Ian McLeod's message of 2013-10-31 11:27:39 -0700: Hello, Would any of you attending the summit be interested in snagging an unconference session to discuss the state of play with image creation, customization and import? I can contribute an overview and demonstration of our Nova-native image building tool. I'd be interested in exploring integration points with Disk Image Builder and Glance. Any takers? Sounds like a good opportunity! So any time Wednesday onward? That broad schedule constraint is good for Glance as well, as all of our sessions are on Tuesday. Cool. I'm not arriving until late Monday. I've asked russellb to try to grab an unconference slot. However, I suppose I should just extend this request to anyone who is interested. So, could I ask that any interested parties look at the unconference signup sheet when you arrive and, if you don't already see: Image Building and Customization please grab a time slot from Wednesday onward? -Ian ___ 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] [Solum] Choice of API infrastructure
On Tue, Nov 5, 2013 at 10:37 AM, Jay Pipes jaypi...@gmail.com wrote: Doug, I respect you very much as an engineer and as a community member, so I want to preface this with a very important dislaimer: don't take these opinions as anything more than what they are...a discussion of differing viewpoints. Ditto. :-) Comments inline. On 11/04/2013 06:58 PM, Doug Hellmann wrote: On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: On 11/02/2013 11:26 PM, Russell Bryant wrote: On 11/02/2013 11:54 AM, Adrian Otto wrote: Noorul, I agree that key decisions should be tracked in blueprints. This is the one for this decision which was made in our 2013-10-18 public meeting. Jay's submission is consistent with the direction indicated by the team. https://blueprints.launchpad.__net/solum/+spec/rest-api-base https://blueprints.launchpad.net/solum/+spec/rest-api-base Transcript log: http://irclogs.solum.io/2013/__solum.2013-10-08-16.01.log.__ html http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html http://irclogs.solum.io/2013/__solum.2013-10-08-16.01.log._ _html http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html Heh, not much discussion there. :-) Agreed. I actually didn't know anything about the discussion -- I wasn't at the meeting. I just figured I would throw some example code up to Gerrit that shows how Falcon can be used for the API plumbing. Like I mentioned in a previous email, I believe it's much easier to discuss things when there is sample code... Here's my take ... Pecan+WSME has been pushed as the thing to standardize on across most OpenStack APIs. Ceilometer (and maybe others?) are already using it. Others, such as Nova, are planning to use it this cycle. [1][2] I've used both actually, and I've come to prefer Falcon because of its simplicity and specifically because of the following things: * It's lack of integration with WSME, which I don't care for. I don't care for WSME because I believe it tries to put the model at the view layer, instead of where it belongs, at the model layer. The models defined in WSME are completely different from the database models, and should not be used outside of the API code. Think of them as declaring the models for the consumer of the API, rather than the implementer of the API. I don't really see the point of the distinction. At the end of the day, the consumer of the API is using the API to manipulate and retrieve data. That data is really the model, with some syntactic sugar like Atom links, etc. Even in a control API -- as opposed to a data API like Glance, Ceilometer or Swift -- the benefits of a heavy API layer like Pecan and WSME are pretty small, IMO. That approach binds your API tightly to the database representation, which we were trying to avoid. I would much rather see the Ceilometer models [1] actually be models that can validate the data that is used to construct the model object instead of having duplicated WSME models repeated in the WSGI controller code [2]. The reason is because if/when I decide to make a Ceilometer API that uses a different protocol, say AMQP, instead of HTTP, now I need to duplicate all of the validation code that WSME is providing on the data model layer... however if the validation was in the models themselves, I could easily create an API on a different protocol using just the models for validation. We do that in some cases. However, there is also a difference in some cases between the validation at the API layer (a value must be a number, or a UUID, etc.) and the validation in the database layer (a number must fall within a range or a UUID must refer to an existing object). So there is a place for both, and the validation done in the WSME classes is not meant to be the only validation performed. The benefits of declaring WSME classes include automatic serialization in JSON and XML, generating WADL files to be included in the API docs (work is already happening to make this available for everyone), and consistent input and output types for API endpoints (making it easier for consumers of the API to use it and for implementers to validate inputs and assume consistent defaults). I can't stand XML. I believe it should be retired to the dustbin of coding history, like Basic. You've made that clear in the past. :-) I agree, for what it's worth. Some of our users do seem to want it, and with WSME *you don't have to care*. That said, consumers of a RESTful API don't care how the API is implemented. They care that it's documented and consistent, and if WSME makes API documentation easier, then
Re: [openstack-dev] [Solum] Choice of API infrastructure
On Nov 5, 2013, at 11:26 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Tue, Nov 5, 2013 at 10:37 AM, Jay Pipes jaypi...@gmail.com wrote: Doug, I respect you very much as an engineer and as a community member, so I want to preface this with a very important dislaimer: don't take these opinions as anything more than what they are...a discussion of differing viewpoints. Ditto. :-) Comments inline. On 11/04/2013 06:58 PM, Doug Hellmann wrote: On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: On 11/02/2013 11:26 PM, Russell Bryant wrote: On 11/02/2013 11:54 AM, Adrian Otto wrote: Noorul, I agree that key decisions should be tracked in blueprints. This is the one for this decision which was made in our 2013-10-18 public meeting. Jay's submission is consistent with the direction indicated by the team. https://blueprints.launchpad.__net/solum/+spec/rest-api-base https://blueprints.launchpad.net/solum/+spec/rest-api-base Transcript log: http://irclogs.solum.io/2013/__solum.2013-10-08-16.01.log.__html http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html http://irclogs.solum.io/2013/__solum.2013-10-08-16.01.log.__html http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html Heh, not much discussion there. :-) Agreed. I actually didn't know anything about the discussion -- I wasn't at the meeting. I just figured I would throw some example code up to Gerrit that shows how Falcon can be used for the API plumbing. Like I mentioned in a previous email, I believe it's much easier to discuss things when there is sample code... Here's my take ... Pecan+WSME has been pushed as the thing to standardize on across most OpenStack APIs. Ceilometer (and maybe others?) are already using it. Others, such as Nova, are planning to use it this cycle. [1][2] I've used both actually, and I've come to prefer Falcon because of its simplicity and specifically because of the following things: * It's lack of integration with WSME, which I don't care for. I don't care for WSME because I believe it tries to put the model at the view layer, instead of where it belongs, at the model layer. The models defined in WSME are completely different from the database models, and should not be used outside of the API code. Think of them as declaring the models for the consumer of the API, rather than the implementer of the API. I don't really see the point of the distinction. At the end of the day, the consumer of the API is using the API to manipulate and retrieve data. That data is really the model, with some syntactic sugar like Atom links, etc. Even in a control API -- as opposed to a data API like Glance, Ceilometer or Swift -- the benefits of a heavy API layer like Pecan and WSME are pretty small, IMO. That approach binds your API tightly to the database representation, which we were trying to avoid. I would much rather see the Ceilometer models [1] actually be models that can validate the data that is used to construct the model object instead of having duplicated WSME models repeated in the WSGI controller code [2]. The reason is because if/when I decide to make a Ceilometer API that uses a different protocol, say AMQP, instead of HTTP, now I need to duplicate all of the validation code that WSME is providing on the data model layer... however if the validation was in the models themselves, I could easily create an API on a different protocol using just the models for validation. We do that in some cases. However, there is also a difference in some cases between the validation at the API layer (a value must be a number, or a UUID, etc.) and the validation in the database layer (a number must fall within a range or a UUID must refer to an existing object). So there is a place for both, and the validation done in the WSME classes is not meant to be the only validation performed. +1 here - translation of a string to a uuid for use with a domain model is a good example of why a view model and a domain model exist. This is a practical concern that almost always comes up during API evolution. The benefits of declaring WSME classes include automatic serialization in JSON and XML, generating WADL files to be included in the API docs (work is already happening to make this available for everyone), and consistent input and output types for API endpoints (making it easier for consumers of the API to use it and for implementers to validate inputs and assume consistent defaults). I can't stand XML. I believe it should be retired to the dustbin of
Re: [openstack-dev] [Neutron] VLAN aware VMs
Guys, I just checked the schedule of unconference sessions. There are no free slots anymore. Yi On Tuesday, October 29, 2013, Isaku Yamahata wrote: Hi Erik and Li. Unconference at the next summit? On Mon, Oct 28, 2013 at 02:34:28PM -0700, beyounn beyo...@gmail.com javascript:; wrote: Hi Erik, While we were discussing about the service VM framework, the trunk port support was also mentioned. I think people do see the needs for it. I have seen someone have mentioned another BP https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-apiin your BP already. Maybe it is same as what you are doing. And the trunk port use case can also impact how the zone being constructed in the fwaas context (when a firewall VM uses a trunk port to connect multiple networks). The basic question is how we should present a trunk port and the vlan on a trunk port to Neutron. Yi From: Erik Moe [mailto:emoe...@gmail.com javascript:;] Sent: Monday, October 28, 2013 1:56 PM To: openstack-dev@lists.openstack.org javascript:; Subject: [openstack-dev] [Neutron] VLAN aware VMs Hi! We are looking into how to make it possible for tenant VMs to use VLAN tagged traffic to connect to different Neutron networks. The VID on frames sent/received will determine which Neutron network the frames are connected to. https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms I would like to find others that also see the need for this kind of functionality and would like to discuss this. Regards, Erik ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com javascript:; ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Android-x86 http://www.android-x86.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum]: Welcome to the community site for Solum !!
Clint, thanks. Logo - if an OpenStack related project is allowed to use the OpenStack logo, then we should absolutely do so. We can discuss in the next solum IRC meeting and decide. From: Clint Byrum [cl...@fewbar.com] Sent: Monday, November 04, 2013 7:46 PM To: openstack-dev Subject: Re: [openstack-dev] [Solum]: Welcome to the community site for Solum !! This is cool, I think other OpenStack projects would do well to have a more user-centric landing page. I have a suggestion for a logo for Solum though ... http://www.openstack.org/brand/openstack-logo/ What I mean is, rather than create a new brand.. enhance the OpenStack brand with users. Excerpts from Roshan Agrawal's message of 2013-11-05 09:25:33 +0800: The community site for Solum has gone live! www.Solum.iohttp://www.Solum.io - this is a landing page for all things Solum related. Also check out the blog section on the site. The logo: is a placeholder for now. We are working on a cool new logo - but the placeholder right now isn't too bad either, is it? ___ 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] Ceph and OpenStack unconference on Friday
We're having an unconference session at the OpenStack design summit on Friday at 2:20pm. If you're interested in Ceph integration with OpenStack, please join us to discuss future development. Josh ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Tuesday Lightning talks @ Expo Breakout Room 1
Dear presenters, All Lightning talks will be in Expo Breakout Room 1. Please arrive before 1:20 and try your laptops if you have slides to present. There is only VGA connector available, so please bring your adapters!!! Thanks Georgy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to skip certain unit tests?
Hi John, Rob, Thanks for the pointers - I used skipTest() within the specific tests I wanted to skip to get over the failing ones. Just an fyi, I'm working with my own internal quantum staging gate on an older release, so I haven't checked on the latest neutron master yet. In case I do find failures there, will attempt to fix them and/or let the community know. Cheers! Regards, Vijay On Wed, Oct 30, 2013 at 7:46 PM, Robert Collins robe...@robertcollins.netwrote: On 31 October 2013 15:20, John Griffith john.griff...@solidfire.com wrote: Hi Vijay, Theoretically there should never be broken tests in master, that's what the gates are for and if there are they should be fixed very quickly. Back to your question, I don't know of a way to skip from run_tests.sh, but there is a skip decorator that can be added to tests in the code. You can also specify specific tests to run. Using run_tests.sh (you can also do more sophisticated things with testr or tox directly) you could do something like: 'run_tests.sh cinder.tests.test_volumes' or more granular: 'run_tests.sh cinder.tests.test_volume:VolumeTestCase.test_create_delete_volume For any project that has switched to testr, it should be simple - pass -- some regex in. e.g. run_tests.sh -- (?!testnametoskip) Cheers, Rob -- 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] VLAN aware VMs
How about if we do a developers lounge chat at 2PM Thursday? On Nov 4, 2013, at 10:20 PM, Yi Sun beyo...@gmail.com wrote: Guys, I just checked the schedule of unconference sessions. There are no free slots anymore. Yi On Tuesday, October 29, 2013, Isaku Yamahata wrote: Hi Erik and Li. Unconference at the next summit? On Mon, Oct 28, 2013 at 02:34:28PM -0700, beyounn beyo...@gmail.com wrote: Hi Erik, While we were discussing about the service VM framework, the trunk port support was also mentioned. I think people do see the needs for it. I have seen someone have mentioned another BP https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api in your BP already. Maybe it is same as what you are doing. And the trunk port use case can also impact how the zone being constructed in the fwaas context (when a firewall VM uses a trunk port to connect multiple networks). The basic question is how we should present a trunk port and the vlan on a trunk port to Neutron. Yi From: Erik Moe [mailto:emoe...@gmail.com] Sent: Monday, October 28, 2013 1:56 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN aware VMs Hi! We are looking into how to make it possible for tenant VMs to use VLAN tagged traffic to connect to different Neutron networks. The VID on frames sent/received will determine which Neutron network the frames are connected to. https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms I would like to find others that also see the need for this kind of functionality and would like to discuss this. Regards, Erik ___ 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 -- Android-x86 http://www.android-x86.org ___ 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] Blueprint -- Floating IP Auto Association
I don't think there has been any development in the past 6 months. A few people have shown interest in it in the past, but the blueprint has currently no assignee. So If you want to work on it, feel free to assign to yourself. To quickly sum up the discussion around this blueprint, it could be implemented in two ways: - providing automation in the neutron API (creating the floating IP together with the port) - automating the operation on the orchestration side (nova-api in this case). There are pro and cons in both solutions. In my humble opinion, the only thing I would care of is that the existing operation in the Neutron API stay atomic as they are. Regards, Salvatore On 30 October 2013 08:46, Steven Weston steven-wes...@live.com wrote: Does anybody know what the status of this Blueprint is? https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip I am new to the neutron developer community and I am looking for a first project – this might be a good place to start. But the last update was in March of this year, so I don’t know if the specifications have been locked down yet. Anybody? Thanks! Steven Weston ___ 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] [Solum]: Welcome to the community site for Solum !!
On 11/04/2013 09:40 PM, Roshan Agrawal wrote: Clint, thanks. Logo - if an OpenStack related project is allowed to use the OpenStack logo, then we should absolutely do so. We can discuss in the next solum IRC meeting and decide. You can associate a project with OpenStack in Launchpad. The owner can click Change details-Part of-OpenStack in Launchpad. Not sure if that solves your problem, but this was fine WTPTB prior to Heat incubation. Regards -steve From: Clint Byrum [cl...@fewbar.com] Sent: Monday, November 04, 2013 7:46 PM To: openstack-dev Subject: Re: [openstack-dev] [Solum]: Welcome to the community site for Solum !! This is cool, I think other OpenStack projects would do well to have a more user-centric landing page. I have a suggestion for a logo for Solum though ... http://www.openstack.org/brand/openstack-logo/ What I mean is, rather than create a new brand.. enhance the OpenStack brand with users. Excerpts from Roshan Agrawal's message of 2013-11-05 09:25:33 +0800: The community site for Solum has gone live! www.Solum.iohttp://www.Solum.io - this is a landing page for all things Solum related. Also check out the blog section on the site. The logo: is a placeholder for now. We are working on a cool new logo - but the placeholder right now isn't too bad either, is it? ___ 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] VLAN aware VMs
Ok, 2PM Thursday is fine with me. On Tue, Nov 5, 2013 at 6:49 AM, Kyle Mestery (kmestery) kmest...@cisco.comwrote: How about if we do a developers lounge chat at 2PM Thursday? On Nov 4, 2013, at 10:20 PM, Yi Sun beyo...@gmail.com wrote: Guys, I just checked the schedule of unconference sessions. There are no free slots anymore. Yi On Tuesday, October 29, 2013, Isaku Yamahata wrote: Hi Erik and Li. Unconference at the next summit? On Mon, Oct 28, 2013 at 02:34:28PM -0700, beyounn beyo...@gmail.com wrote: Hi Erik, While we were discussing about the service VM framework, the trunk port support was also mentioned. I think people do see the needs for it. I have seen someone have mentioned another BP https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-apiin your BP already. Maybe it is same as what you are doing. And the trunk port use case can also impact how the zone being constructed in the fwaas context (when a firewall VM uses a trunk port to connect multiple networks). The basic question is how we should present a trunk port and the vlan on a trunk port to Neutron. Yi From: Erik Moe [mailto:emoe...@gmail.com] Sent: Monday, October 28, 2013 1:56 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN aware VMs Hi! We are looking into how to make it possible for tenant VMs to use VLAN tagged traffic to connect to different Neutron networks. The VID on frames sent/received will determine which Neutron network the frames are connected to. https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms I would like to find others that also see the need for this kind of functionality and would like to discuss this. Regards, Erik ___ 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 -- Android-x86 http://www.android-x86.org ___ 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] [Solum]: Welcome to the community site for Solum !!
Clint, The rules about use of the OpenStack brand are clear, and Solum is not allowed to use it. We are a part of the OpenStack ecosystem, but the OpenStack brand (trademark/logo) is reserved for those projects that are Integrated or Core. At this point what we need is a good collaboration among contributors, with participation from other OpenStack ecosystem projects. I think we are on the right track, and our community is forming nicely. When we have shippable software and are ready to build a user base, that's when the branding issues will matter more. Adrian On Nov 5, 2013, at 12:40 PM, Roshan Agrawal roshan.agra...@rackspace.com wrote: Clint, thanks. Logo - if an OpenStack related project is allowed to use the OpenStack logo, then we should absolutely do so. We can discuss in the next solum IRC meeting and decide. From: Clint Byrum [cl...@fewbar.com] Sent: Monday, November 04, 2013 7:46 PM To: openstack-dev Subject: Re: [openstack-dev] [Solum]: Welcome to the community site for Solum !! This is cool, I think other OpenStack projects would do well to have a more user-centric landing page. I have a suggestion for a logo for Solum though ... http://www.openstack.org/brand/openstack-logo/ What I mean is, rather than create a new brand.. enhance the OpenStack brand with users. Excerpts from Roshan Agrawal's message of 2013-11-05 09:25:33 +0800: The community site for Solum has gone live! www.Solum.iohttp://www.Solum.io - this is a landing page for all things Solum related. Also check out the blog section on the site. The logo: is a placeholder for now. We are working on a cool new logo - but the placeholder right now isn't too bad either, is it? ___ 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] baremetal provisioning
Hi I have noticed that if i generate a baremetal image of 8G, it takes around 20-25 minutes for the deployment. And, the entire disk image is built in the openstack server and then copied over. Isnt this a waste of time and space? Should the image with the 8G (or 30G or 100G, whatever i want) be created in the openstack server, and the whole image copied? Is there any other way, or is there a fix for this? Can we not specify the image size and the image not be created, but /dev/sdx be created during boot time? Thanks Ravi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] VLAN aware VMs
Yap, 2pm is good Yi On Tuesday, November 5, 2013, Erik Moe wrote: Ok, 2PM Thursday is fine with me. On Tue, Nov 5, 2013 at 6:49 AM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: How about if we do a developers lounge chat at 2PM Thursday? On Nov 4, 2013, at 10:20 PM, Yi Sun beyo...@gmail.com wrote: Guys, I just checked the schedule of unconference sessions. There are no free slots anymore. Yi On Tuesday, October 29, 2013, Isaku Yamahata wrote: Hi Erik and Li. Unconference at the next summit? On Mon, Oct 28, 2013 at 02:34:28PM -0700, beyounn beyo...@gmail.com wrote: Hi Erik, While we were discussing about the service VM framework, the trunk port support was also mentioned. I think people do see the needs for it. I have seen someone have mentioned another BP https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-apiin your BP already. Maybe it is same as what you are doing. And the trunk port use case can also impact how the zone being constructed in the fwaas context (when a firewall VM uses a trunk port to connect multiple networks). The basic question is how we should present a trunk port and the vlan on a trunk port to Neutron. Yi From: Erik Moe [mailto:emoe...@gmail.com] Sent: Monday, October 28, 2013 1:56 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN aware VMs Hi! We are looking into how to make it possible for tenant VMs to use VLAN tagged traffic to connect to different Neutron networks. The VID on frames sent/received will determine which Neutron network the frames are connected to. https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms I would like to find others that also see the need for this kind of functionality and would like to discuss this. Regards, Erik ___ 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 -- Android-x86 http://www.android-x86.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenSta -- Android-x86 http://www.android-x86.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Manual to build an application on open stack
Thank you Denis. While I look at trove, I had another question to the community on the front end UI. Do we have support for integrating a flex based application with open stack? On Nov 3, 2013 1:54 PM, Denis Makogon dmako...@mirantis.com wrote: I'd suggest you to take a look at OpenStack Trove for backend deployment. Also, i've seen at github ReST based OpenStack client written on java. If you need any help, you are free to ask community. Regards, Denis M. 2013/11/3 Krishanu Dhar rony.k...@gmail.com Thanks Denis. So,this is what I am planning. An application; I was thinking of writing it up in java 'coz I ain't that good in python. It could be accessed either via a web browser or an app could be downloaded to a desktop. Brief set of functionalities... 1. A db backend to store information retrieved from devices in the network. (MySQL may be) 2. Add devices to it for management (eg: switch, storage array, server) 3. Perform tasks on these devices. (eg: create, delete, modify logical objects) On Nov 2, 2013 4:32 PM, Denis Makogon dmako...@mirantis.com wrote: Ok, i got it. I'd suggest you to describe whole copcent of your application (if it is not commercial secret) and let community lead you to right direction. There simple rules of developing with OpenStack: 1. Python based. 2. Clinet/Server interaction 3. ReST 4. Test coverage. Inner test or Tempest. 2013/11/2 Krishanu Dhar rony.k...@gmail.com Sorry for being vague in my previous email. Thanks for the link, I'll go through it. I am trying to build an app that resides on the cloud and would want to perform some basic storage management operations. On Sat, Nov 2, 2013 at 3:07 PM, Denis Makogon dmako...@mirantis.comwrote: It depends on what kind of application your are building. There serveral way of developing something above openstack services. I hope this wikinpage would help you a bit https://wiki.openstack.org/wiki/Documentation 2013/11/2 Krishanu Dhar rony.k...@gmail.com Hi, I wanted to build an application on openstack and wanted help on how do i go about doing it? Since i am absolutely new to the stack I was wondering if their is a developer's manual or something of that sort. All I have done so far is started the installation of devstack. I am typing this email while the installation is progressing in the background. Thanks for you time and help. krish -- Krishanu ___ 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 -- Krishanu ___ 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] Improvement of Cinder API wrt https://bugs.launchpad.net/nova/+bug/1213953
So while doubling the timeout will fix some cases, there will be cases with larger volumes and/or slower systems where the bug will still hit. Even timing out on the download progress can lead to unnecessary timeouts (if it's really slow, or volume is really big, it can stay at 5% for some time). I think the proper fix is to make sure that Cinder is moving the volume into 'error' state in all cases where there is an error. Nova can then poll as long as its in the 'downloading' state, until it's 'available' or 'error'. Is there a reason why Cinder would legitimately get stuck in 'downloading'? Thanks, Avishay From: John Griffith john.griff...@solidfire.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 11/05/2013 07:41 AM Subject:Re: [openstack-dev] Improvement of Cinder API wrt https://bugs.launchpad.net/nova/+bug/1213953 On Tue, Nov 5, 2013 at 7:27 AM, John Griffith john.griff...@solidfire.com wrote: On Tue, Nov 5, 2013 at 6:29 AM, Chris Friesen chris.frie...@windriver.com wrote: On 11/04/2013 03:49 PM, Solly Ross wrote: So, There's currently an outstanding issue with regards to a Nova shortcut command that creates a volume from an image and then boots from it in one fell swoop. The gist of the issue is that there is currently a set timeout which can time out before the volume creation has finished (it's designed to time out in case there is an error), in cases where the image download or volume creation takes an extended period of time (e.g. under a Gluster backend for Cinder with certain network conditions). The proposed solution is a modification to the Cinder API to provide more detail on what exactly is going on, so that we could programmatically tune the timeout. My initial thought is to create a new column in the Volume table called 'status_detail' to provide more detailed information about the current status. For instance, for the 'downloading' status, we could have 'status_detail' be the completion percentage or JSON containing the total size and the current amount copied. This way, at each interval we could check to see if the amount copied had changed, and trigger the timeout if it had not, instead of blindly assuming that the operation will complete within a given amount of time. What do people think? Would there be a better way to do this? The only other option I can think of would be some kind of callback that cinder could explicitly call to drive updates and/or notifications of faults rather than needing to wait for a timeout. Possibly a combination of both would be best, that way you could add a --poll option to the create volume and boot CLI command. I come from the kernel-hacking world and most things there involve event-driven callbacks. Looking at the openstack code I was kind of surprised to see hardcoded timeouts and RPC casts with no callbacks to indicate completion. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I believe you're referring to [1], which was closed after a patch was added to nova to double the timeout length. Based on comments sounds like your still seeing issues on some Gluster (maybe other) setups? Rather than mess with the API in order to do debug, why don't you use the info in the cinder-logs? [1] https://bugs.launchpad.net/nova/+bug/1213953 ___ 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] Manual to build an application on open stack
Sorry, but i cannot answer that kind of question, you should ask Horizon guys. 2013/11/5 Krishanu Dhar rony.k...@gmail.com Thank you Denis. While I look at trove, I had another question to the community on the front end UI. Do we have support for integrating a flex based application with open stack? On Nov 3, 2013 1:54 PM, Denis Makogon dmako...@mirantis.com wrote: I'd suggest you to take a look at OpenStack Trove for backend deployment. Also, i've seen at github ReST based OpenStack client written on java. If you need any help, you are free to ask community. Regards, Denis M. 2013/11/3 Krishanu Dhar rony.k...@gmail.com Thanks Denis. So,this is what I am planning. An application; I was thinking of writing it up in java 'coz I ain't that good in python. It could be accessed either via a web browser or an app could be downloaded to a desktop. Brief set of functionalities... 1. A db backend to store information retrieved from devices in the network. (MySQL may be) 2. Add devices to it for management (eg: switch, storage array, server) 3. Perform tasks on these devices. (eg: create, delete, modify logical objects) On Nov 2, 2013 4:32 PM, Denis Makogon dmako...@mirantis.com wrote: Ok, i got it. I'd suggest you to describe whole copcent of your application (if it is not commercial secret) and let community lead you to right direction. There simple rules of developing with OpenStack: 1. Python based. 2. Clinet/Server interaction 3. ReST 4. Test coverage. Inner test or Tempest. 2013/11/2 Krishanu Dhar rony.k...@gmail.com Sorry for being vague in my previous email. Thanks for the link, I'll go through it. I am trying to build an app that resides on the cloud and would want to perform some basic storage management operations. On Sat, Nov 2, 2013 at 3:07 PM, Denis Makogon dmako...@mirantis.comwrote: It depends on what kind of application your are building. There serveral way of developing something above openstack services. I hope this wikinpage would help you a bit https://wiki.openstack.org/wiki/Documentation 2013/11/2 Krishanu Dhar rony.k...@gmail.com Hi, I wanted to build an application on openstack and wanted help on how do i go about doing it? Since i am absolutely new to the stack I was wondering if their is a developer's manual or something of that sort. All I have done so far is started the installation of devstack. I am typing this email while the installation is progressing in the background. Thanks for you time and help. krish -- Krishanu ___ 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 -- Krishanu ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Congress: an open policy framework
I hope that you guys made it safely to Hong Kong. We have secured an unconference session on Wednesday at 4:40 - 5:20 (SkyCity Meeting Room 2). There will be a panel of customers and vendors, and we are already gathering some really good feedback. We will also be able to run a demo of what we have running. Looking forward to the discussion. - Peter On Sat, Nov 2, 2013 at 9:31 PM, Tim Hinrichs thinri...@vmware.com wrote: Hi OpenStackers, We've been working on an open policy framework for OpenStack that we're calling Congress. We've been talking with OpenStack users and several of our partners to understand the kinds of rules and regulations they envision enforcing with a policy-based management framework. Across the board they are interested in policies that span networking, compute, storage, etc. The idea behind Congress is to have a single policy engine that integrates any collection of external authentication and data stores and allows cloud administrators to write policies over those data stores in a rich, declarative language. The policy engine can either enforce the policy proactively (i.e. preventing policy violations before they occur) or reactively (identifying violations after they occur and taking corrective action) or a combination (proactively when possible and reactively when not). The policy engine can also interact with the administrator, explaining the causes of violations, computing potential remediation plans, and simulating action executions to understand what violations those actions might cause. While the project is still in the early stages, we have identified a grammar for the policy language, implemented a policy engine, and written a proof of concept integration for ActiveDirectory. We would love to get participation and feedback. Code (in the midst of moving to stackforge): https://github.com/pballand/congress Wiki: https://wiki.openstack.org/wiki/Congress We'll be in Hong Kong, so if you would like to meet up to discuss please e-mail Peter pball...@vmware.com and Pierre pett...@vmware.com. -- The Congress Team ___ 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] [Solum]: Welcome to the community site for Solum !!
Excerpts from Adrian Otto's message of 2013-11-05 15:10:09 +0800: Clint, The rules about use of the OpenStack brand are clear, and Solum is not allowed to use it. We are a part of the OpenStack ecosystem, but the OpenStack brand (trademark/logo) is reserved for those projects that are Integrated or Core. At this point what we need is a good collaboration among contributors, with participation from other OpenStack ecosystem projects. I think we are on the right track, and our community is forming nicely. When we have shippable software and are ready to build a user base, that's when the branding issues will matter more. Agreed on all points. I'm sure we could have a lively debate on what a shippable Solum looks like. My point is, I don't believe that it is wise to build the Solum brand until you are ready to seek full integration with OpenStack. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Improvement of Cinder API wrt https://bugs.launchpad.net/nova/+bug/1213953
Replication of snapshots is one solution to this. You create a Cinder Volume once. snapshot it. Then replicate to the hosts that need it (this is the piece currently missing). Then you clone there. I will be giving an in an hour in conference session on this and other uses of snapshots in the last time slot Wednesday. On Nov 5, 2013 5:58 AM, Solly Ross sr...@redhat.com wrote: So, There's currently an outstanding issue with regards to a Nova shortcut command that creates a volume from an image and then boots from it in one fell swoop. The gist of the issue is that there is currently a set timeout which can time out before the volume creation has finished (it's designed to time out in case there is an error), in cases where the image download or volume creation takes an extended period of time (e.g. under a Gluster backend for Cinder with certain network conditions). The proposed solution is a modification to the Cinder API to provide more detail on what exactly is going on, so that we could programmatically tune the timeout. My initial thought is to create a new column in the Volume table called 'status_detail' to provide more detailed information about the current status. For instance, for the 'downloading' status, we could have 'status_detail' be the completion percentage or JSON containing the total size and the current amount copied. This way, at each interval we could check to see if the amount copied had changed, and trigger the timeout if it had not, instead of blindly assuming that the operation will complete within a given amount of time. What do people think? Would there be a better way to do this? Best Regards, Solly Ross ___ 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] VLAN aware VMs
I'm fine with 14:00 on Thursday. On Tue, Nov 05, 2013 at 07:59:55AM +0100, Erik Moe emoe...@gmail.com wrote: Ok, 2PM Thursday is fine with me. On Tue, Nov 5, 2013 at 6:49 AM, Kyle Mestery (kmestery) kmest...@cisco.comwrote: How about if we do a developers lounge chat at 2PM Thursday? On Nov 4, 2013, at 10:20 PM, Yi Sun beyo...@gmail.com wrote: Guys, I just checked the schedule of unconference sessions. There are no free slots anymore. Yi On Tuesday, October 29, 2013, Isaku Yamahata wrote: Hi Erik and Li. Unconference at the next summit? On Mon, Oct 28, 2013 at 02:34:28PM -0700, beyounn beyo...@gmail.com wrote: Hi Erik, While we were discussing about the service VM framework, the trunk port support was also mentioned. I think people do see the needs for it. I have seen someone have mentioned another BP https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-apiin your BP already. Maybe it is same as what you are doing. And the trunk port use case can also impact how the zone being constructed in the fwaas context (when a firewall VM uses a trunk port to connect multiple networks). The basic question is how we should present a trunk port and the vlan on a trunk port to Neutron. Yi From: Erik Moe [mailto:emoe...@gmail.com] Sent: Monday, October 28, 2013 1:56 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] VLAN aware VMs Hi! We are looking into how to make it possible for tenant VMs to use VLAN tagged traffic to connect to different Neutron networks. The VID on frames sent/received will determine which Neutron network the frames are connected to. https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms I would like to find others that also see the need for this kind of functionality and would like to discuss this. Regards, Erik ___ 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 -- Android-x86 http://www.android-x86.org ___ 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
