[openstack-dev] No Project release status meeting tomorrow
While we all recover from havana-2 and some of us party for the 3rd OpenStack birthday at OSCON, we'll be skipping the release status meeting tomorrow at 21:00 UTC. PTLs should take the extra time to review their havana-3 plans and trim them to come up with reasonable objectives where appropriate ! Back to our regular schedule next week. -- 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] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling
On Fri, Jul 19 2013, Sean Dague wrote: I assume it would gracefully degrade to the existing static allocators if something went wrong. If not, well that would be very bad. Ceilometer is an integrated project in Havana. Utilization based scheduling would be a new feature. I'm not sure why we think that duplicating the metrics collectors in new code would be less buggy than working with Ceilometer. Nova depends on external projects all the time. If we have a concern about robustness here, we should be working as an overall project to address that. +1 -- Julien Danjou -- Free Software hacker - freelance consultant -- http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova][Oslo-incubator] Automatic retry db.api query if database connection lost
Hi All. There is a blueprint ( https://blueprints.launchpad.net/nova/+spec/db-reconnect) by Devananda van der Veen, which goal is to implement reconnection to a database and retrying of the last operation if a db connection fails. I’m working on the implementation of this BP in oslo-incubator ( https://review.openstack.org/#/c/33831/). Function _raise_if_db_connection_lost() was added to _wrap_db_error() decorator defined in openstack/common/db/sqlalchemy/session.py. This function catches sqlalchemy.exc.OperationalError and finds database error code in this exception. If this error code is on `database has gone away` error codes list, this function raises DBConnectionError exception. Decorator for db.api methods was added to openstack/common/db/api.py. We can apply this decorator to methods in db.sqlalchemy.api (not to individual queries). It catches DBConnectionError exception and retries the last query in a loop until it succeeds, or until the timeout is reached. The timeout value is configurable with min, max, and increment options. We suppose that all db.api methods are executed inside a single transaction, so retrying the whole method, when a connection is lost, should be safe. I would really like to receive some comments about the following suggestions: 1. I can’t imagine a situation when we lose connection to an SQLite DB. Also, as far as I know, SQLite is not used in production at the moment, so we don't handle this case. 2. Please, leave some comments about `database has gone away` error codes list in MySQL and PostgreSQL. 3. Johannes Erdfelt suggested that “retrying the whole method, even if it's in a transaction, is only safe the entire method is idempotent. A method could execute successfully in the database, but the connection could be dropped before the final status is sent to the client.” I agree, that this situation can cause data corruption in a database (e. g., if we try to insert something to a database), but I’m not sure, how RDBMS handle this. Also, I haven't succeeded in creation of a functional test case, that would allow to reproduce the described situation easily. Thanks, Victor ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pip requirements externally host (evil evil stab stab stab)
Hi Salvatore, I intend to replace the netifaces module which Ryu agent uses with the ip_lib module. Thanks, Kaneko 2013/7/21 Salvatore Orlando sorla...@nicira.com: I reckon the netifaces package is only used in Neutron's Ryu plugin. At a first glance, it should be possible to replace its current usage with the iplib module which has been developed within neutron itself. Unless we hear otherwise from contributors to the Ryu plugin it is my opinion that we should move towards replacing netifaces. Salvatore On 19 July 2013 20:04, Monty Taylor mord...@inaugust.com wrote: Hey guys! PyPI is moving towards the world of getting people to stop hosting stuff via external links. It's been bad for us in the past and one of the reasons for the existence of our mirror. pip 1.4 has an option to disallow following external links, and in 1.5 it's going to be the default behavior. Looking forward, we have 5 pip packages that host their stuff externally. If we have any pull with their authors, we should get them to actually upload stuff to pypi. If we don't, we should strongly consider our use of these packages. As soon as pip 1.4 comes out, I would like to moving forward restrict the addition of NEW requirements that do not host on pypi. (all 5 of these host insecurely as well, fwiw) The culprits are: dnspython,lockfile,netifaces,psutil,pysendfile ___ 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] tripleo/incubator now in gerrit
If you were using it from https://github.com/tripleo/incubator, you should update your remotes to reference https://github.com/openstack/tripleo-incubator. I'll get the .gitreview stuff setup shortly. Cheers, Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] A simple way to improve nova scheduler
On 07/22/2013 08:16 AM, Boris Pavlovic wrote: * How do you bring a new scheduler up in an existing deployment and make it get the full state of the system? You should wait for a one periodic task time. And you will get full information about all compute nodes. This also affects upgrading a scheduler. Also consider a continuous deployment setup. Every time you update a scheduler, it's not usable for (periodic task interval) seconds/minutes? -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling
Sandy Walsh wrote on 2013-07-19: On 07/19/2013 09:47 AM, Day, Phil wrote: -Original Message- From: Sean Dague [mailto:s...@dague.net] Sent: 19 July 2013 12:04 To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling (was: New DB column or new DB table?) On 07/19/2013 06:18 AM, Day, Phil wrote: Ceilometer is a great project for taking metrics available in Nova and other systems and making them available for use by Operations, Billing, Monitoring, etc - and clearly we should try and avoid having multiple collectors of the same data. But making the Nova scheduler dependent on Ceilometer seems to be the wrong way round to me - scheduling is such a fundamental operation that I want Nova to be self sufficient in this regard. In particular I don't want the availability of my core compute platform to be constrained by the availability of my (still evolving) monitoring system. If Ceilometer can be fed from the data used by the Nova scheduler then that's a good plus - but not the other way round. I assume it would gracefully degrade to the existing static allocators if something went wrong. If not, well that would be very bad. Ceilometer is an integrated project in Havana. Utilization based scheduling would be a new feature. I'm not sure why we think that duplicating the metrics collectors in new code would be less buggy than working with Ceilometer. Nova depends on external projects all the time. If we have a concern about robustness here, we should be working as an overall project to address that. -Sean Just to be cleat its about a lot more than just robustness in the code - its the whole architectural pattern of putting Ceilometer at the centre of Nova scheduling that concerns me. As I understand it Celiometer can collect metrics from more than one copy of Nova - which is good; I want to run multiple independent copies in different regions and I want to have all of my monitoring data going back to one place. However that doesn't mean that I now also want all of those independent copies of Nova depending on that central monitoring infrastructure for something as basic as scheduling. (I don't want to stop anyone that does either - but I don't see why I should be forced down that route). The original change that sparked this debate came not from anything to do with utilisation based scheduling, but the pretty basic and simple desire to add new types of consumable resource counters into the scheduler logic in a more general way that having to make a DB schema change. This was generally agreed to be a good thing, and it pains me to see that valuable work now blocked on what seems to be turning into an strategic discussion around the role of Ceilometer (Is it a monitoring tool or a fundamental metric bus, etc). At the point where Ceilomter can be shown to replace the current scheduler resource mgmt code in Nova, then we should be talking about switching to it - but in the meantime why can't we continue to have incremental improvements in the current Nova code ? +1 +1 We can keep discussion to determine RR for Nova and Ceilometer. Can we have a decision to make so we can move forward to have incremental improvements in Nova? Thanks. -- Shane Cheers Phil ___ 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] [Nova] New DB column or new DB table?
Daniel raised a good point, I also agreed that is not a good architecture. Nova can't touch any monitoring stuffs - I don't think that is good. At least, Ceilometer can be a monitoring hub for external utilities. On the other hand, for the options Lianhao raised. Is a query on a DB and a json column faster than the one on two-DB join? I have no experimental data but I doubt it. Thanks. -- Shane Dan Smith wrote on 2013-07-20: IIUC, Ceilometer is currently a downstream consumer of data from Nova, but no functionality in Nova is a consumer of data from Ceilometer. This is good split from a security separation point of view, since the security of Nova is self-contained in this architecture. If Nova schedular becomes dependant on data from ceilometer, then now the security of Nova depends on the security of Ceilometer, expanding the attack surface. This is not good architecture IMHO. Agreed. At the same time, I hear your concerns about the potential for duplication of stats collection functionality between Nova Ceilometer. I don't think we neccessarily need to remove 100% of duplication. IMHO probably the key thing is for the virt drivers to expose a standard API for exporting the stats, and make sure that both ceilometer nova schedular use the same APIs and ideally the same data feed, so we're not invoking the same APIs twice to get the same data. I imagine there's quite a bit that could be shared, without dependency between the two. Interfaces out of the virt drivers may be one, and the code that boils numbers into useful values, as well as perhaps the format of the JSON blobs that are getting shoved into the database. Perhaps a ceilo-core library with some very simple primitives and definitions could be carved out, which both nova and ceilometer could import for consistency, without a runtime dependency? --Dan ___ 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] A simple way to improve nova scheduler
Russell, To get information about all compute nodes we should wait one periodic task (60 seconds by default). So starting will take a while. But I don't think that this is a big problem: 1) if we are already able to wait each time for heavy and long ( few seconds) db querie 2) if we have more then one scheduler, we are always able to turn and change one by one. (I don't think that having for 5 minutes old and new schedulers will break anything). Also as a first step that could be done to speed up scheduler: We could just remove db.compute_node_get_all() and send RPC calls directly to schedulers. I think that patch-set that change this thing will be pretty small (~100-150 lines of code) and doesn't requirers big changes in current scheduler implementation. Best regards, Boris Pavlovic Mirantis Inc. On Mon, Jul 22, 2013 at 5:50 PM, Russell Bryant rbry...@redhat.com wrote: On 07/22/2013 08:16 AM, Boris Pavlovic wrote: * How do you bring a new scheduler up in an existing deployment and make it get the full state of the system? You should wait for a one periodic task time. And you will get full information about all compute nodes. This also affects upgrading a scheduler. Also consider a continuous deployment setup. Every time you update a scheduler, it's not usable for (periodic task interval) seconds/minutes? -- 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
[openstack-dev] [Heat] Multi region support for Heat
Hi folks, I would like to start a discussion about the blueprint I raised about multi region support. I would like to get feedback from you. If something is not clear or you have questions do not hesitate to ask. Please let me know what you think. Blueprint: https://blueprints.launchpad.net/heat/+spec/multi-region-support Wikipage: https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat Thanks, Bartosz ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] A simple way to improve nova scheduler
On 07/22/2013 10:43 AM, Boris Pavlovic wrote: Russell, To get information about all compute nodes we should wait one periodic task (60 seconds by default). So starting will take a while. But I don't think that this is a big problem: 1) if we are already able to wait each time for heavy and long ( few seconds) db querie 2) if we have more then one scheduler, we are always able to turn and change one by one. (I don't think that having for 5 minutes old and new schedulers will break anything). Also as a first step that could be done to speed up scheduler: We could just remove db.compute_node_get_all() and send RPC calls directly to schedulers. I think that patch-set that change this thing will be pretty small (~100-150 lines of code) and doesn't requirers big changes in current scheduler implementation. In any case, I think it's too late in the Havana cycle to be introducing a new effort like this. It will have to wait for Icehouse. We should plan to have a design summit session on it, as well. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Article on Improving Openstack's Parallel Performance
Hello, I've written an article about my ongoing work on improving OpenStack's parallel performance: http://blog.gridcentric.com/bid/318277/Boosting-OpenStack-s-Parallel-Performance The article discusses host configuration changes and patches (upstream and in progress) that give a 74% speedup in a parallel macro benchmark (boot 40 instances, ping them, ssh into them, delete them). This article is a follow up to my presentation at the OpenStack summit in Portland. Peter ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Savanna-all] Savanna EDP sequence diagrams added for discussion...
I updated the REST API draft - https://etherpad.openstack.org/savanna_API_draft_EDP_extensions. New methods related to job source and data discovery components were added; also the job object was updated. On Fri, Jul 19, 2013 at 12:26 AM, Trevor McKay tmc...@redhat.com wrote: fyi, updates to the diagram based on feedback On Thu, 2013-07-18 at 13:49 -0400, Trevor McKay wrote: Hi all, Here is a page to hold sequence diagrams for Savanna EDP, based on current launchpad blueprints. We thought it might be helpful to create some diagrams for discussion as the component specs are written and the API is worked out: https://wiki.openstack.org/wiki/Savanna/EDP_Sequences (The main page for EDP is here https://wiki.openstack.org/wiki/Savanna/EDP ) There is an initial sequence there, along with a link to the source for generating the PNG with PlantUML. Feedback would be great, either through IRC, email, comments on the wiki, or by modifying the sequence and/or posting additional sequences. The sequences can be generated/modified easily with with Plantuml which installs as a single jar file: http://plantuml.sourceforge.net/download.html java -jar plantuml.jar Choose the directory which contains plantuml text files and it will monitor, generate, and update PNGs as you save/modify text files. I thought it was broken the first time I ran it because there are no controls :) Very simple. Best, Trevor -- Mailing list: https://launchpad.net/~savanna-all Post to : savanna-...@lists.launchpad.net Unsubscribe : https://launchpad.net/~savanna-all More help : https://help.launchpad.net/ListHelp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] The PCI support blueprint
Hi, Boris I'm a surprised that you want to postpone the PCI support (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base) to I release. You and our team have been working on this for a long time, and the patches has been reviewed several rounds. And we have been waiting for your DB layer patch for two weeks without any update. Can you give more reason why it's pushed to I release? If you are out of bandwidth, we are sure to take it and push it to H release! Is it because you want to base your DB layer on your 'A simple way to improve nova scheduler'? That really does not make sense to me. Firstly, that proposal is still under early discussion and get several different voices already, secondly, PCI support is far more than DB layer, it includes resource tracker, scheduler filter, libvirt support enhancement etc. Even if we will change the scheduler that way after I release, we need only change the DB layer, and I don't think that's a big effort! Thanks --jyh ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The PCI support blueprint
On 07/22/2013 11:17 AM, Jiang, Yunhong wrote: Hi, Boris I'm a surprised that you want to postpone the PCI support (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base) to I release. You and our team have been working on this for a long time, and the patches has been reviewed several rounds. And we have been waiting for your DB layer patch for two weeks without any update. Can you give more reason why it's pushed to I release? If you are out of bandwidth, we are sure to take it and push it to H release! Is it because you want to base your DB layer on your 'A simple way to improve nova scheduler'? That really does not make sense to me. Firstly, that proposal is still under early discussion and get several different voices already, secondly, PCI support is far more than DB layer, it includes resource tracker, scheduler filter, libvirt support enhancement etc. Even if we will change the scheduler that way after I release, we need only change the DB layer, and I don't think that's a big effort! Boris mentioned scalability concerns with the current approach on IRC. I'd like more detail. In general, if we can see a reasonable path to upgrade what we have now to make it better in the future, then we don't need to block it because of that. If the current approach will result in a large upgrade impact to users to be able to make it better, that would be a reason to hold off. It also depends on how serious the scalability concerns are. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Configuration file generator
Hi there, I've been working on the changes that would need to be done to make the default config generator work for Neutron. However, the current default config generator doesn't support the possibility to generate different configuration files (e.g. one per service/plugin). I can imagine two options: a. move every options in oslo.config.cfg.CONF, moving the plugins into their own section rather than in their own file, register all options at module-level, avoiding duplicate options. b. enhance config.generator to generate a config file from a particular object (not always olso.config.cfg.CONF like it's done currently). That means Neutron should evolve to provide a global CONF object per plugin at least. Option a. is how all other OpenStack projects¹ are working so far. Option b. requires a bit more work on both side. Is there any particular way you guys see things? ¹ nova, ceilometer and heat at least for now -- Julien Danjou /* Free Software hacker * freelance consultant http://julien.danjou.info */ signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pip requirements externally host (evil evil stab stab stab)
As a heads up I filed bugs with each of these projects (with the exception of netifaces, which doesn't appear to have a tracker). The dnspython maintainer has already uploaded the package to PyPi and disabled scraping! Alex On Fri, Jul 19, 2013 at 8:04 PM, Monty Taylor mord...@inaugust.com wrote: Hey guys! PyPI is moving towards the world of getting people to stop hosting stuff via external links. It's been bad for us in the past and one of the reasons for the existence of our mirror. pip 1.4 has an option to disallow following external links, and in 1.5 it's going to be the default behavior. Looking forward, we have 5 pip packages that host their stuff externally. If we have any pull with their authors, we should get them to actually upload stuff to pypi. If we don't, we should strongly consider our use of these packages. As soon as pip 1.4 comes out, I would like to moving forward restrict the addition of NEW requirements that do not host on pypi. (all 5 of these host insecurely as well, fwiw) The culprits are: dnspython,lockfile,netifaces,psutil,pysendfile ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] DevStack deployment issue
There is bug in requests package versions. Current version 1.2.3 is stable. According to pypi, eggs of versions 1.2.1, 1.2.2 are broken. Please fix it im cinder requirements ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [barbican]
Hi All, I am following Barbican project and I have some question around it, I would appreciate if someone can answer them or point me to the correct resource 1. What is the state of the project, is it in the state where it can be utilized in production deployments? 2.Dose Barbican is an implementation of https://wiki.openstack.org/wiki/KeyManager BP? If not please point me to the correct design/BP resource on which Barbican is based on. 3.Is it KMIP (KMIP 1.1 spec https://www.oasis-open.org/standards#kmipspecv1.1) complaint? If not, what are the plans any initiative so far? Thanks, Arvind ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Swift] erasure codes, digging deeper
I think most folks are on the same page wrt EC being consider a level or storage policy as we've been discussing in other forums. I saw the previous note on account versus container and was actually thinking it made more sense to me at least to enable billing per container as opposed to trying to shoehorn attribute of a set of data (like a storage policy) to and account so I like where you're going w/the suggestion. I'm not even sure we need to answer the detailed question of what defines these levels, or storage policies, only that the design allows for their efficient use and flexible definitions. Thx Paul From: David Hadas [mailto:david.ha...@gmail.com] Sent: Monday, July 22, 2013 9:35 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Swift] erasure codes, digging deeper Hi, In Portland, we discussed a somewhat related issue of having multiple replication levels in one Swift cluster. It may be that a provider would not wish to expose the use of EC or the level of replication used. For example a provider may offer a predefined set of services such as Gold, Silver and Bronze, Aluminum which a user can choose from. The provider may decide how each level is implemented (As a silly example: Gold is 4 way replication, Silver is a 3 way replication, Bronze is EC, Aluminum is single replica without EC). Does it make sense to consider EC as an implementation of a certain service level (the same as for example the choice of the number of replicas)? Now we are back to the question of what is the right unit in which we define this 'level of service' (Gold, Silver...). Should the level of service be defined when the account is created or should we allow a user to state: I would like to have a container with Gold to keep my work, Bronze to keep my family pictures and videos and Aluminum to keep a copy of all my music files. If we choose to enable container service levels, we need to enable billing per level of service such that a single account could be billed for the actual use it has done per each level of service. Maybe we even need to have all statistics gathered to be grouped by service level. I am not sure if we can escape that even with account service levels. DH On Thu, Jul 18, 2013 at 9:37 PM, John Dickinson m...@not.mnmailto:m...@not.mn wrote: Yes, and I'd imagine that the normal default would be for replicated data. Moving the granularity from a container to account-based, as Chmouel and Chuck said, is interesting too. --John On Jul 18, 2013, at 11:32 AM, Christian Schwede i...@cschwede.demailto:i...@cschwede.de wrote: A solution to this might be to set the default policy as a configuration setting in the proxy. If you want a replicated swift cluster just allow this policy in the proxy and set it to default. The same for EC cluster, just set the allowed policy to EC. If you want both (and let your users decide which policy to use) simply configure a list of allowed policies with the first one in the list as the default policy in case they don't set a policy during container creation. Am 18.07.13 20:15, schrieb Chuck Thier: I think you are missing the point. What I'm talking about is who chooses what data is EC and what is not. The point that I am trying to make is that the operators of swift clusters should decide what data is EC, not the clients/users. How the data is stored should be totally transparent to the user. Now if we want to down the road offer user defined classes of storage (like how S3 does reduced redundancy), I'm cool with that, just that it should be orthogonal to the implementation of EC. -- Chuck On Thu, Jul 18, 2013 at 12:57 PM, John Dickinson m...@not.mnmailto:m...@not.mn mailto:m...@not.mnmailto:m...@not.mn wrote: Are you talking about the parameters for EC or the fact that something is erasure coded vs replicated? For the first, that's exactly what we're thinking: a deployer sets up one (or more) policies and calls them Alice, Bob, or whatever, and then the API client can set that on a particular container. This allows users who know what they are doing (ie those who know the tradeoffs and their data characteristics) to make good choices. It also allows deployers who want to have an automatic policy to set one up to migrate data. For example, a deployer may choose to run a migrator process that moved certain data from replicated to EC containers over time (and drops a manifest file in the replicated tier to point to the EC data so that the URL still works). Like existing features in Swift (eg large objects), this gives users the ability to flexibly store their data with a nice interface yet still have the ability to get at some of the pokey bits underneath. --John On Jul 18, 2013, at 10:31 AM, Chuck Thier cth...@gmail.commailto:cth...@gmail.com mailto:cth...@gmail.commailto:cth...@gmail.com wrote: I'm with
Re: [openstack-dev] [Swift] erasure codes, digging deeper
On Jul 22, 2013, at 9:34 AM, David Hadas david.ha...@gmail.com wrote: Hi, In Portland, we discussed a somewhat related issue of having multiple replication levels in one Swift cluster. It may be that a provider would not wish to expose the use of EC or the level of replication used. For example a provider may offer a predefined set of services such as Gold, Silver and Bronze, Aluminum which a user can choose from. The provider may decide how each level is implemented (As a silly example: Gold is 4 way replication, Silver is a 3 way replication, Bronze is EC, Aluminum is single replica without EC). Does it make sense to consider EC as an implementation of a certain service level (the same as for example the choice of the number of replicas)? yes, that's actually exactly what I'm thinking. Now we are back to the question of what is the right unit in which we define this 'level of service' (Gold, Silver...). Should the level of service be defined when the account is created or should we allow a user to state: I would like to have a container with Gold to keep my work, Bronze to keep my family pictures and videos and Aluminum to keep a copy of all my music files. If we choose to enable container service levels, we need to enable billing per level of service such that a single account could be billed for the actual use it has done per each level of service. Maybe we even need to have all statistics gathered to be grouped by service level. I am not sure if we can escape that even with account service levels. Either on the account or container level, the billing number generator will need to correlate particular bytes with a particular service level. That would be in ceilometer, slogging, or whatever other people are using. DH On Thu, Jul 18, 2013 at 9:37 PM, John Dickinson m...@not.mn wrote: Yes, and I'd imagine that the normal default would be for replicated data. Moving the granularity from a container to account-based, as Chmouel and Chuck said, is interesting too. --John On Jul 18, 2013, at 11:32 AM, Christian Schwede i...@cschwede.de wrote: A solution to this might be to set the default policy as a configuration setting in the proxy. If you want a replicated swift cluster just allow this policy in the proxy and set it to default. The same for EC cluster, just set the allowed policy to EC. If you want both (and let your users decide which policy to use) simply configure a list of allowed policies with the first one in the list as the default policy in case they don't set a policy during container creation. Am 18.07.13 20:15, schrieb Chuck Thier: I think you are missing the point. What I'm talking about is who chooses what data is EC and what is not. The point that I am trying to make is that the operators of swift clusters should decide what data is EC, not the clients/users. How the data is stored should be totally transparent to the user. Now if we want to down the road offer user defined classes of storage (like how S3 does reduced redundancy), I'm cool with that, just that it should be orthogonal to the implementation of EC. -- Chuck On Thu, Jul 18, 2013 at 12:57 PM, John Dickinson m...@not.mn mailto:m...@not.mn wrote: Are you talking about the parameters for EC or the fact that something is erasure coded vs replicated? For the first, that's exactly what we're thinking: a deployer sets up one (or more) policies and calls them Alice, Bob, or whatever, and then the API client can set that on a particular container. This allows users who know what they are doing (ie those who know the tradeoffs and their data characteristics) to make good choices. It also allows deployers who want to have an automatic policy to set one up to migrate data. For example, a deployer may choose to run a migrator process that moved certain data from replicated to EC containers over time (and drops a manifest file in the replicated tier to point to the EC data so that the URL still works). Like existing features in Swift (eg large objects), this gives users the ability to flexibly store their data with a nice interface yet still have the ability to get at some of the pokey bits underneath. --John On Jul 18, 2013, at 10:31 AM, Chuck Thier cth...@gmail.com mailto:cth...@gmail.com wrote: I'm with Chmouel though. It seems to me that EC policy should be chosen by the provider and not the client. For public storage clouds, I don't think you can make the assumption that all users/clients will understand the storage/latency tradeoffs and benefits. On Thu, Jul 18, 2013 at 8:11 AM, John Dickinson m...@not.mn mailto:m...@not.mn wrote: Check out the slides I linked. The plan is to enable an EC policy that is then set on a container. A cluster may have a
Re: [openstack-dev] A simple way to improve nova scheduler
On 07/22/2013 12:51 PM, John Garbutt wrote: On 22 July 2013 13:23, Boris Pavlovic bo...@pavlovic.me wrote: I see only one race condition. (in current solution we have the same situtaiton) Between request to compute node and data is updated in DB, we could use wrong state of compute node. By the way it is fixed by retry. This race turns out to be a big deal when there are bursts of VM.start requests. I am currently thinking about ways we can look to eliminate this one. Hoping to have a design summit session on that. Cool. In addition to retries, it's somewhat mitigated by using the scheduler_host_subset_size to reduce the chance that multiple schedulers choose the same host. # New instances will be scheduled on a host chosen randomly # from a subset of the N best hosts. This property defines the # subset size that a host is chosen from. A value of 1 chooses # the first host returned by the weighing functions. This # value must be at least 1. Any value less than 1 will be # ignored, and 1 will be used instead (integer value) #scheduler_host_subset_size=1 -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] havana-3 reality check and deadlines
Greetings, havana-1: 16 blueprints implemented havana-2: 25 blueprints implemented havana-3: currently 96 blueprints targeted [1] The number of blueprints targeted at havana-3 is completely unrealistic. As a result, there are number of important points and actions we need to take: * If you have a havana-3 blueprint, please review it and make sure the status is accurate and that you still intend to deliver it. If not, please change the milestone to next or ping someone in nova-drivers [2] to do it. * Earlier in the cycle we discussed a deadline for when patches must be submitted to make the feature freeze [3]. We also re-visited the topic in our last Nova meeting. This deadline is August 21 (2 weeks before feature freeze) and it *will* be enforced. * To nova-core: we need to do our best to prioritize our review time in havana-3, to make sure we get the most important stuff reviewed and merged. * To everyone, I'm sorry, but some stuff that is ready on time probably won't make it. That's the risk of delivering toward the end of the development cycle. To have the best chance, get your code up for review *ASAP*. * I will be regularly working on pruning this list. Please come talk to me if you think there is a blueprint we should discuss deferring. Let me know if you have any comments or questions. Thanks, [1] https://launchpad.net/nova/+milestone/havana-3 [2] https://launchpad.net/~nova-drivers/+members#active [3] http://lists.openstack.org/pipermail/openstack-dev/2013-April/007823.html -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] havana-3 reality check and deadlines
Thx for helping corral it all russell :) Sent from my really tiny device... On Jul 22, 2013, at 11:03 AM, Russell Bryant rbry...@redhat.com wrote: Greetings, havana-1: 16 blueprints implemented havana-2: 25 blueprints implemented havana-3: currently 96 blueprints targeted [1] The number of blueprints targeted at havana-3 is completely unrealistic. As a result, there are number of important points and actions we need to take: * If you have a havana-3 blueprint, please review it and make sure the status is accurate and that you still intend to deliver it. If not, please change the milestone to next or ping someone in nova-drivers [2] to do it. * Earlier in the cycle we discussed a deadline for when patches must be submitted to make the feature freeze [3]. We also re-visited the topic in our last Nova meeting. This deadline is August 21 (2 weeks before feature freeze) and it *will* be enforced. * To nova-core: we need to do our best to prioritize our review time in havana-3, to make sure we get the most important stuff reviewed and merged. * To everyone, I'm sorry, but some stuff that is ready on time probably won't make it. That's the risk of delivering toward the end of the development cycle. To have the best chance, get your code up for review *ASAP*. * I will be regularly working on pruning this list. Please come talk to me if you think there is a blueprint we should discuss deferring. Let me know if you have any comments or questions. Thanks, [1] https://launchpad.net/nova/+milestone/havana-3 [2] https://launchpad.net/~nova-drivers/+members#active [3] http://lists.openstack.org/pipermail/openstack-dev/2013-April/007823.html -- 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] The PCI support blueprint
Ian, I don't like to write anything personally. But I have to write some facts: 1) I see tons of hands and only 2 solutions my and one more that is based on code. 2) My code was published before session (18. Apr 2013) 3) Blueprints from summit were published (03. Mar 2013) 4) My Blueprints were published (25. May 2013) 5) Patches based on my patch were published only (5. Jul 2013) 2 All, I don't won't to hide anything from community, cores or PTLs. I have only one goal and it is to make OpenStack better. Recently I get new task on my job: Scalability/Performance and Benchmarks So with my colleagues we started investigating some code around scheduler. (Jiang sorry for lag in 2 weeks) After making investigations and tests we found that one of the reason why scheduler works slow and has problems with scalability is work with DB. JOINS are pretty unscalable and slow thing and if we add one more JOIN that is required by PCI passthrough we will get much worse situation. We started investigating how to solve two competing things: Scalability vs Flexibility About flexibility: I don't think that our current scheduler is handy, I have to add 800 lines of code just to be able to use list of JSON objects in scheduler as one more resource (with complex structure). If we don't use new table we should use some kind of key/value, and if we use a lot of key/values we will get problems with performance and scalability or if we store in one key/value we will get another problem with races and tons of dirty code. So we will get the same problems in future. Also using of resources from different providers (such as cinder) are pretty hard tasks. So Alexey K., Alexei O. and me found a way to make our scheduler work without DB with pretty small changes in current solution. New approach allows us in the same time to have scalability and flexibility. What means scalability: We don't need to store anything about PCI devices in DB. And should just add some small extra code in resource tracker. I understand that it is too late to implement such things in H-3 (I absolutely agree with Russell). (Even if they require just 100-150 lines of code.) So if we implement solution based on my current code, after improving scheduler we should: 1) remove absolutly DB layer 2) 100% replace compute.api layer 3) partial replace scheduler layer 4) change compute.manager And only libvirt (that should be improved) and auto discovering will be untouched (but they are not enough reviewed in this moment) will be untouched. So I really don't understand why we should hurry up. Why we are not able firstly to: 1) Prepare patches around improving scheduler (before summit) 2) Prepare all things that will be untouched (libvirt/auto discovering) (before summit) 3) Speak about all this stuff one more time on summit 4) Improve and implement all these work in I-1 ? 5) Test and improve it during I-2 and I-3. I think that it will be much better for OpenStack code at all. If Russell and other cores would like to implement current PCI passthrough approach anyway. I won't block anything and tomorrow at evening will be finished DB layer Best regards, Boris Pavlovic --- Mirantis Inc. On Mon, Jul 22, 2013 at 8:49 PM, Ian Wells ijw.ubu...@cack.org.uk wrote: Per the last summit, there are many interested parties waiting on PCI support. Boris (who unfortunately waasn't there) jumped in with an implementation before the rest of us could get a blueprint up, but I suspect he's been stretched rather thinly and progress has been much slower than I was hoping it would be. There are many willing hands happy to take this work on; perhaps it's time we did, so that we can get something in before Havana. I'm sure we could use a better scheduler. I don't think that actually affects most of the implementation of passthough and I don't think we should tie the two together. The perfect is the enemy of the good. And as far as the quantity of data passed back - we've discussed before that it would be nice (for visibility purposes) to be able to see an itemised list of all of the allocated and unallocated PCI resources in the database. There could be quite a lot per host (256 per card x say 10 cards depending on your hardware). But passing that itemised list back is somewhat of a luxury - in practice, what you need for scheduling is merely a list of categories of card (those pools where any one of the PCI cards in the pool would do) and counts. The compute node should be choosing a card from the pool in any case. The scheduler need only find a machine with cards available. I'm not totally convinced that passing back the itemised list is necessarily a problem, but in any case we can make the decision one way or the other, take on the risk if we like, and get the code written - if it turns out not to be scalable then we can fix *that* in the next release, but at least we'll have something to play with in the meantime. Delaying the whole
[openstack-dev] [nova] Multiple interfaces, same network
A while back (just before the summit, as I recall), there was a patch submitted to remove the constraints on being able to connect multiple interfaces of the same VM to the same Neutron network. [1] It was unclear at the time whether this is a bug being fixed or a feature being added, which rather stalled the discussion, along with several 'eww, why would you do this' comments. To that end, I've added a blueprint to make the feature request [2], and I'd like to bring the discussion here as to whether it's productive to do. Personally, I want it because I want to simulate physical networks - where it's perfectly legitimate to connect one machine to the same network twice. I can't simulate those networks without this feature. I would argue that this makes people's lives easier in certain awkward situations - if they have a VM configured to use two ports they can use both ports on the same network if they wish - and is a low risk change which should just work (something we can prove out with adequate tests). It also only affects anyone who actually tries to connect one VM to the same network twice - that is, making the change has no effect on the configurations that work today. -- Ian. [1] https://review.openstack.org/#/c/26370 [2] https://blueprints.launchpad.net/nova/+spec/two-vifs-one-net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Split the Identity Backend blueprint
On 07/22/2013 01:38 PM, Miller, Mark M (EB SW Cloud - RD - Corvallis) wrote: Hello, I have been reading source code in an attempt to figure out how to use the new split backend feature, specifically how to split the identity data between an ldap server and the standard Keystone sql database. However, I haven't been able to figure it out quite yet. Does someone have some examples of this new feature in action? Is there another configuration file that is required? [identity] driver = driver = keystone.identity.backends.sql.Identity [assignment] driver = ??? [ldap] Quite a few options Regards, Mark Miller RIght now the only support split approach is LDAP for Identity, SQL for assignments. [identity] driver = keystone.identity.backends.ldap.Identity [assignment] driver = keystone.assignment.backends.sql.Identity ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The PCI support blueprint
Hi one more time. I will refactor DB layer tomorrow. As I said I don't want to be a block. Best regards, Boris Pavlovic --- Mirantis Inc. On Mon, Jul 22, 2013 at 11:08 PM, Boris Pavlovic bo...@pavlovic.me wrote: Ian, I don't like to write anything personally. But I have to write some facts: 1) I see tons of hands and only 2 solutions my and one more that is based on code. 2) My code was published before session (18. Apr 2013) 3) Blueprints from summit were published (03. Mar 2013) 4) My Blueprints were published (25. May 2013) 5) Patches based on my patch were published only (5. Jul 2013) 2 All, I don't won't to hide anything from community, cores or PTLs. I have only one goal and it is to make OpenStack better. Recently I get new task on my job: Scalability/Performance and Benchmarks So with my colleagues we started investigating some code around scheduler. (Jiang sorry for lag in 2 weeks) After making investigations and tests we found that one of the reason why scheduler works slow and has problems with scalability is work with DB. JOINS are pretty unscalable and slow thing and if we add one more JOIN that is required by PCI passthrough we will get much worse situation. We started investigating how to solve two competing things: Scalability vs Flexibility About flexibility: I don't think that our current scheduler is handy, I have to add 800 lines of code just to be able to use list of JSON objects in scheduler as one more resource (with complex structure). If we don't use new table we should use some kind of key/value, and if we use a lot of key/values we will get problems with performance and scalability or if we store in one key/value we will get another problem with races and tons of dirty code. So we will get the same problems in future. Also using of resources from different providers (such as cinder) are pretty hard tasks. So Alexey K., Alexei O. and me found a way to make our scheduler work without DB with pretty small changes in current solution. New approach allows us in the same time to have scalability and flexibility. What means scalability: We don't need to store anything about PCI devices in DB. And should just add some small extra code in resource tracker. I understand that it is too late to implement such things in H-3 (I absolutely agree with Russell). (Even if they require just 100-150 lines of code.) So if we implement solution based on my current code, after improving scheduler we should: 1) remove absolutly DB layer 2) 100% replace compute.api layer 3) partial replace scheduler layer 4) change compute.manager And only libvirt (that should be improved) and auto discovering will be untouched (but they are not enough reviewed in this moment) will be untouched. So I really don't understand why we should hurry up. Why we are not able firstly to: 1) Prepare patches around improving scheduler (before summit) 2) Prepare all things that will be untouched (libvirt/auto discovering) (before summit) 3) Speak about all this stuff one more time on summit 4) Improve and implement all these work in I-1 ? 5) Test and improve it during I-2 and I-3. I think that it will be much better for OpenStack code at all. If Russell and other cores would like to implement current PCI passthrough approach anyway. I won't block anything and tomorrow at evening will be finished DB layer Best regards, Boris Pavlovic --- Mirantis Inc. On Mon, Jul 22, 2013 at 8:49 PM, Ian Wells ijw.ubu...@cack.org.uk wrote: Per the last summit, there are many interested parties waiting on PCI support. Boris (who unfortunately waasn't there) jumped in with an implementation before the rest of us could get a blueprint up, but I suspect he's been stretched rather thinly and progress has been much slower than I was hoping it would be. There are many willing hands happy to take this work on; perhaps it's time we did, so that we can get something in before Havana. I'm sure we could use a better scheduler. I don't think that actually affects most of the implementation of passthough and I don't think we should tie the two together. The perfect is the enemy of the good. And as far as the quantity of data passed back - we've discussed before that it would be nice (for visibility purposes) to be able to see an itemised list of all of the allocated and unallocated PCI resources in the database. There could be quite a lot per host (256 per card x say 10 cards depending on your hardware). But passing that itemised list back is somewhat of a luxury - in practice, what you need for scheduling is merely a list of categories of card (those pools where any one of the PCI cards in the pool would do) and counts. The compute node should be choosing a card from the pool in any case. The scheduler need only find a machine with cards available. I'm not totally convinced that passing back the itemised list is necessarily a problem,
Re: [openstack-dev] Change in openstack/neutron[master]: Add method to get iptables traffic counters
Sylvain, Something like this would require no marking: # iptables -N test2 # iptables -N test3 # iptables -A test3 # iptables -A test2 -d 9.9.9.9/32 -j RETURN # iptables -A test2 -d 10.10.10.10/32 -j RETURN # iptables -A test2 -j test3 # iptables -A OUTPUT -j test2 # ping -I eth0 -r 9.9.9.9 PING 9.9.9.9 (9.9.9.9) from 16.1.1.40 eth0: 56(84) bytes of data. ^C --- 9.9.9.9 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1007ms # iptables-save -c | grep test :test2 - [0:0] :test3 - [0:0] [3198:403274] -A OUTPUT -j test2 [2:168] -A test2 -d 9.9.9.9/32 -j RETURN [0:0] -A test2 -d 10.10.10.10/32 -j RETURN [3196:403106] -A test2 -j test3 [3196:403106] -A test3 # iptables -L test2 -v -x -n Chain test2 (1 references) pkts bytes target prot opt in out source destination 2 168 RETURN all -- * * 0.0.0.0/0 9.9.9.9 00 RETURN all -- * * 0.0.0.0/0 10.10.10.10 3182 401554 test3 all -- * * 0.0.0.0/0 0.0.0.0/0 iptables -L test3 -v -x -n Chain test3 (1 references) pkts bytes target prot opt in out source destination 3182 401554all -- * * 0.0.0.0/0 0.0.0.0/0 And I seems similar to your cut/paste from below. Thoughts? -Brian On 07/22/2013 03:55 AM, Sylvain Afchain wrote: Hi Brian, Thanks for your reply. 1. This isn't something a tenant should be able to do, so should be admin-only, correct? Correct. 2. I think it would be useful for an admin to be able to add metering rules for all tenants with a single command. This gets back to wanting to pre-seed an ini file with a set of subnets, then add/subtract from it later without restarting the daemon. I agree with you, could be a future enhancement. 3. I think it would be better if you didn't mark the packets, for performance reasons. If you were marking them on input to be matched by something on output I'd feel different, but for just counting bytes we should be able to do it another way. I can get back to you next week on figuring this out. Ok, I'll take a look too. Thanks. Sylvain. - Original Message - From: Brian Haley brian.ha...@hp.com To: Sylvain Afchain sylvain.afch...@enovance.com Cc: openstack-dev@lists.openstack.org Sent: Friday, July 19, 2013 11:47:41 PM Subject: Re: Change in openstack/neutron[master]: Add method to get iptables traffic counters Hi Sylvain, Sorry for the slow reply, I'll have to look closer next week, but I did have some comments. 1. This isn't something a tenant should be able to do, so should be admin-only, correct? 2. I think it would be useful for an admin to be able to add metering rules for all tenants with a single command. This gets back to wanting to pre-seed an ini file with a set of subnets, then add/subtract from it later without restarting the daemon. 3. I think it would be better if you didn't mark the packets, for performance reasons. If you were marking them on input to be matched by something on output I'd feel different, but for just counting bytes we should be able to do it another way. I can get back to you next week on figuring this out. Thanks, -Brian On 07/18/2013 04:29 AM, Sylvain Afchain wrote: Hi Brian, For iptables rules, see below Yes the only way to setup metering labels/rules is the neutronclient. I agree with you about the future enhancement. Regards, Sylvain - Original Message - From: Brian Haley brian.ha...@hp.com To: Sylvain Afchain sylvain.afch...@enovance.com Cc: openstack-dev@lists.openstack.org Sent: Thursday, July 18, 2013 4:58:26 AM Subject: Re: Change in openstack/neutron[master]: Add method to get iptables traffic counters Hi Sylvain, I think I've caught-up with all your reviews, but I still did have some questions on the iptables rules, below. One other question, and maybe it's simply a future enhancement, but is the only way to setup these meters using neutronclient? I think being able to specify these in an .ini file would be good as well, which is something I'd want to do as a provider, such that they're always there, and actually not visible to the tenant. On 07/11/2013 10:04 AM, Sylvain Afchain wrote: Hi Brian, You're right It could be easier with your approach to get and keep the traffic counters. I will add a new method to get the details of traffic counters of a chain. https://review.openstack.org/35624 Thoughts? Regards, Sylvain. - Original Message - From: Sylvain Afchain sylvain.afch...@enovance.com To: Brian Haley brian.ha...@hp.com Cc: openstack-dev@lists.openstack.org Sent: Thursday, July 11, 2013 11:19:39 AM Subject: Re: Change in openstack/neutron[master]: Add method to get iptables traffic counters Hi Brian, First thanks for the reviews and your detailed email. Second I will update
Re: [openstack-dev] [barbican]
I'm the product owner for Barbican at Rackspace. I'll take a shot an answering your questions. 1. What is the state of the project, is it in the state where it can be utilized in production deployments? We currently in active development and pushing for our 1.0 release for Havana. As to production deployments, the answer right now is none. We are currently working on enabling Barbican to use hardware security modules for key storage. Once this code is complete, we should be close to a place where the first production deployment is feasible. At Rack, we are building out the infrastructure to do so and I hope to have good news once we get towards the Summit. 2. Dose Barbican is an implementation of https://wiki.openstack.org/wiki/KeyManager BP? If not please point me to the correct design/BP resource on which Barbican is based on. We are inspired by the blueprint you linked. That blueprint was a bit more limited than we were planning and we have changed quite a bit. For a more detailed version, you can find lots of documentation on our wiki here: https://github.com/cloudkeep/barbican/wiki/Blueprint:-Technical-Approach https://github.com/cloudkeep/barbican https://github.com/cloudkeep/barbican/wiki 3. Is it KMIP (KMIP 1.1 spec https://www.oasis-open.org/standards#kmipspecv1.1) complaint? If not, what are the plans any initiative so far? Not right now. As I mentioned in a previous email (I'll copy the contents below), KMIP is not the greatest protocol for this use case. Our current plans are to expose the Barbican API to all consumers. This is a standard OpenStack API using ReST / JSON, authing through keystone, etc. If there is enough interest, I am planning on supporting KMIP inside Barbican to talk to various HSM type providers. This would most likely not be exposed to customers. I haven't heard from anyone who needs KMIP support at this point. Mostly the questions have just been whether we are planning on supporting it. If you have a strong use case as to why you want / need it, I'd love to hear it. You can respond here or reach out to me at jarret.r...@rackspace.commailto:jarret.r...@rackspace.com Thanks, Jarret Here is the previous email relating to KMIP for additional reading: I'm not sure that I agree with this direction. In our investigation, KMIP is a problematic protocol for several reasons: * We haven't found an implementation of KMIP for Python. (Let us know if there is one!) * Support for KMIP by HSM vendors is limited. * We haven't found software implementations of KMIP suitable for use as an HSM replacement. (e.g. Most deployers wanting to use KMIP would have to spend a rather large amount of money to purchase HSMs) * From our research, the KMIP spec and implementations seem to lack support for multi-tenancy. This makes managing keys for thousands of users difficult or impossible. The goal for the Barbican system is to provide key management for OpenStack. It uses the standard interaction mechanisms for OpenStack, namely ReST and JSON. We integrate with keystone and will provide common features like usage events, role-based access control, fine grained control, policy support, client libs, Celiometer support, Horizon support and other things expected of an OpenStack service. If every product is forced to implement KMIP, these features would most likely not be provided by whatever vendor is used for the Key Manager. Additionally, as mentioned in the blueprint, I have concerns that vendor specific data will be leaked into the rest of OpenStack for things like key identifiers, authentication and the like. I would propose that rather than each product implement KMIP support, we implement KMIP support into Barbican. This will allow the products to speak ReST / JSON using our client libraries just like any other OpenStack system and Barbican will take care of being a good OpenStack citizen. On the backend, Barbican will support the use of KMIP to talk to whatever device the provider wishes to deploy. We will also support other interaction mechanisms including PKCS through OpenSSH, a development implementation and a fully free and open source software implementation. This also allows some advanced uses cases including federation. Federation will allow customers of public clouds like Rackspace's to maintain custody of their keys while still being able to delegate their use to the Cloud for specific tasks. I've been asked about KMIP support at the Summit and by several of Rackspace's partners. I was planning on getting to it at some point, probably after Icehouse. This is mostly due to the fact that we didn't find a suitable KMIP implementation for Python so it looks like we'd have to write one. If there is interest from people to create that implementation, we'd be happy to help do the work to integrate it into Barbican. We just released our M2 milestone and we are on track for our 1.0 release for Havana. I
[openstack-dev] [Nova] support for multiple active scheduler policies/drivers
Dear all, Following the initial discussions at the last design summit, we have published the design [2] and the first take on the implementation [3] of the blueprint adding support for multiple active scheduler policies/drivers [1]. In a nutshell, the idea is to allow overriding the 'default' scheduler configuration parameters (driver, filters, their configuration parameters, etc) for particular host aggregates. The 'policies' are introduced as sections in nova.conf, and each host aggregate can have a key-value specifying the policy (by name). Comments on design or implementation are welcome! Thanks, Alex [1] https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers [2] https://wiki.openstack.org/wiki/Nova/MultipleSchedulerPolicies [3] https://review.openstack.org/#/c/37407/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The PCI support blueprint
Ian, your suggestion of retrieving changes since a timestamp is good. When a scheduler first comes online (in an HA context), it requests compute node status providing Null for timestamp to retrieve everything. It also paves the way for full in memory record of all compute node status because it requires that each scheduler keep a copy of the status. The Scheduler could retrieve status every second or whenever it gets a new VM request. Under heavy load, that is frequent requests, the timestamps would be closer and hopefully fewer changes being returned. We may want to make the frequency of polling a configurable item to tune .. too infrequent means payload large (no worse than today's full load), too often may be moot. Regards Malini -Original Message- From: Ian Wells [mailto:ijw.ubu...@cack.org.uk] Sent: Monday, July 22, 2013 1:56 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] The PCI support blueprint On 22 July 2013 21:08, Boris Pavlovic bo...@pavlovic.me wrote: Ian, I don't like to write anything personally. But I have to write some facts: 1) I see tons of hands and only 2 solutions my and one more that is based on code. 2) My code was published before session (18. Apr 2013) 3) Blueprints from summit were published (03. Mar 2013) 4) My Blueprints were published (25. May 2013) 5) Patches based on my patch were published only (5. Jul 2013) Absolutely. Your patch and our organisation crossed in the mail, and everyone held off work on this because you were working on this. That's perfectly normal, just unfortunate, and I'm grateful for your work on this, not pointing fingers. After making investigations and tests we found that one of the reason why scheduler works slow and has problems with scalability is work with DB. JOINS are pretty unscalable and slow thing and if we add one more JOIN that is required by PCI passthrough we will get much worse situation. Your current PCI passthrough design adds a new database that stores every PCI device in the cluster, and you're thinking of crossing that with the compute node and its friends. That's certainly unscalable. I think the issue here is, in fact, more that you're storing every PCI device. The scheduler doesn't care. In most cases, devices are equivalent, so instead of storing 1024 devices you can store one single row in the stats table saying pci_device_class_networkcard = 1024. There may be a handful of these classes, but there won't be 1024 of them per cluster node. The compute node can take any one of the PCI devices in that class and use it - the scheduler should neither know nor care. This drastically reduces the transfer of information from the compute node to host and also reduces the amount of data you need to store in the database - and the scheduler DB doesn't need changing at all. This seems like a much more low impact approach for now - it doesn't change the database at all and it and doesn't add much to the scheduling problem (indeed, no overhead at all for the non-PCI users) until we solve the scalability issues you're talking about at some later date. For what it's worth, one way of doing that without drastic database design would be to pass compute_node_get_all a timestamp, return only stats updated since that timestamp, return a new timestamp, and merge that in with what the scheduler already knows about. There's some refinement to that - since timestamps are not reliable clocks in databases - but it reduces the flow of data from the DB file substantially and works with an eventually consistent system. (Truthfully, I prefer your in-memory-store idea, there's nothing about these stats that really needs to survive a reboot of the control node, but this might be a quick fix.) -- 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
Re: [openstack-dev] [Nova] support for multiple active scheduler policies/drivers
On 07/22/2013 05:15 PM, Alex Glikson wrote: Dear all, Following the initial discussions at the last design summit, we have published the design [2] and the first take on the implementation [3] of the blueprint adding support for multiple active scheduler policies/drivers [1]. In a nutshell, the idea is to allow overriding the 'default' scheduler configuration parameters (driver, filters, their configuration parameters, etc) for particular host aggregates. The 'policies' are introduced as sections in nova.conf, and each host aggregate can have a key-value specifying the policy (by name). Comments on design or implementation are welcome! Thanks, Alex [1] https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers [2] https://wiki.openstack.org/wiki/Nova/MultipleSchedulerPolicies [3] https://review.openstack.org/#/c/37407/ Thanks for bringing this up. I do have some comments. The current design shows 2 different use cases for how a scheduling policy would be chosen. #1 - policy associated with a host aggregate This seems very odd to me. Scheduling policy is what chooses hosts, so having a subset of hosts specify which policy to use seems backwards. #2 - via a scheduler hint It also seems odd to have the user specifying scheduling policy. This seems like something that should be completely hidden from the user. How about just making the scheduling policy choice as simple as an item in the flavor extra specs? The design also shows some example configuration. It shows a global set of enabled scheduler filters, and then policy specific tweaks of filter config (CPU allocation ratio in the example). I would expect to be able to set a scheduling policy specific list of scheduler filters and weights, as well. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Multi region support for Heat
On 22/07/13 16:52 +0200, Bartosz Górski wrote: Hi folks, I would like to start a discussion about the blueprint I raised about multi region support. I would like to get feedback from you. If something is not clear or you have questions do not hesitate to ask. Please let me know what you think. Blueprint: https://blueprints.launchpad.net/heat/+spec/multi-region-support Wikipage: https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat What immediatley looks odd to me is you have a MultiCloud Heat talking to other Heat's in each region. This seems like unneccessary complexity to me. I would have expected one Heat to do this job. -Angus Thanks, Bartosz ___ 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] Configuration file generator
Also for your information, I created a bug : https://bugs.launchpad.net/neutron/+bug/1199963 and a first patchset for generating the new configuration file with Oslo config scripts : https://review.openstack.org/#/c/36546/ Emilien Macchi # OpenStack Engineer // eNovance Inc. http://enovance.com // ? emil...@enovance.com ? +33 (0)1 49 70 99 80 // 10 rue de la Victoire 75009 Paris On 07/22/2013 06:34 PM, Julien Danjou wrote: Hi there, I've been working on the changes that would need to be done to make the default config generator work for Neutron. However, the current default config generator doesn't support the possibility to generate different configuration files (e.g. one per service/plugin). I can imagine two options: a. move every options in oslo.config.cfg.CONF, moving the plugins into their own section rather than in their own file, register all options at module-level, avoiding duplicate options. b. enhance config.generator to generate a config file from a particular object (not always olso.config.cfg.CONF like it's done currently). That means Neutron should evolve to provide a global CONF object per plugin at least. Option a. is how all other OpenStack projects¹ are working so far. Option b. requires a bit more work on both side. Is there any particular way you guys see things? ¹ nova, ceilometer and heat at least for now ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] support for multiple active scheduler policies/drivers
On Mon, Jul 22, 2013 at 3:04 PM, Russell Bryant rbry...@redhat.com wrote: On 07/22/2013 05:15 PM, Alex Glikson wrote: Dear all, Following the initial discussions at the last design summit, we have published the design [2] and the first take on the implementation [3] of the blueprint adding support for multiple active scheduler policies/drivers [1]. In a nutshell, the idea is to allow overriding the 'default' scheduler configuration parameters (driver, filters, their configuration parameters, etc) for particular host aggregates. The 'policies' are introduced as sections in nova.conf, and each host aggregate can have a key-value specifying the policy (by name). Comments on design or implementation are welcome! Thanks, Alex [1] https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers [2] https://wiki.openstack.org/wiki/Nova/MultipleSchedulerPolicies [3] https://review.openstack.org/#/c/37407/ Thanks for bringing this up. I do have some comments. The current design shows 2 different use cases for how a scheduling policy would be chosen. #1 - policy associated with a host aggregate This seems very odd to me. Scheduling policy is what chooses hosts, so having a subset of hosts specify which policy to use seems backwards. #2 - via a scheduler hint It also seems odd to have the user specifying scheduling policy. This seems like something that should be completely hidden from the user. How about just making the scheduling policy choice as simple as an item in the flavor extra specs? ++, IMHO we already reveal too much scheduling information to the user via are current set of scheduler hints. The design also shows some example configuration. It shows a global set of enabled scheduler filters, and then policy specific tweaks of filter config (CPU allocation ratio in the example). I would expect to be able to set a scheduling policy specific list of scheduler filters and weights, as well. -- 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] A simple way to improve nova scheduler
An interesting idea, I'm not sure how useful it is but it could be. If you think of the compute node capability information as an 'event stream' then you could imagine using something like apache flume (http://flume.apache.org/) or storm (http://storm-project.net/) to be able to sit on this stream and perform real-time analytics of said stream to update how scheduling can be performed. Maybe the MQ or ceilometer can be the same 'stream' source but it doesn't seem like it is needed to 'tie' the impl to those methods. If you consider compute nodes as producers of said data and then hook a real-time processing engine on-top that can adjust some scheduling database used by a scheduler then it seems like u could vary how often compute nodes produce said stream info, where and how said stream info is stored and analyzed which will allow you to then adjust how 'real-time' you want said compute scheduling capability information to be up to date. Just seems that real-time processing is a similar model as what is needed here. Maybe something like that is where this should end up? -Josh From: Joe Gordon joe.gord...@gmail.commailto:joe.gord...@gmail.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, July 22, 2013 3:47 PM To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] A simple way to improve nova scheduler On Mon, Jul 22, 2013 at 5:16 AM, Boris Pavlovic bo...@pavlovic.memailto:bo...@pavlovic.me wrote: Joe, Speaking of Chris Beherns Relying on anything but the DB for current memory free, etc, is just too laggy… so we need to stick with it, IMO. http://lists.openstack.org/pipermail/openstack-dev/2013-June/010485.html It doesn't scale, use tons of resources, works slow and is hard to extend. Also the mechanism of getting free and used memory is done by virt layer. And only thing that could be laggy is rpc (but it is used also by compute node update) You say it doesn't scale and uses tons of resources can you show to reproduce your findings. Also just because the current implementation of the scheduler is non-optimal doesn't mean the no DB is the only solution, I am interested in seeing other possible solutions before going down such a drastically different road (no-db). Such as pushing more of the logic into the DB and not searching through all compute nodes in python space or looking at removing the periodic updates all together or ???. * How do you bring a new scheduler up in an existing deployment and make it get the full state of the system? You should wait for a one periodic task time. And you will get full information about all compute nodes. sure, that may work we need to add logic in to handle this. * Broadcasting RPC updates from compute nodes to the scheduler means every scheduler has to process the same RPC message. And if a deployment hits the point where the number of compute updates is consuming 99 percent of the scheduler's time just adding another scheduler won't fix anything as it will get bombarded too. If we are speaking about numbers. You are able to see our doc, where they are counted. If we have 10k nodes it will make only 150rpc calls/sec (which means nothing for cpu). By the way we way we will remove 150 calls/s from conductor. One more thing currently in 10nodes deployment I think we will spend almost all time fro waiting DB (compute_nodes_get_all()). And also when we are calling this method in this moment we should process all data for 60 sec. (So in this case in numbers we are doing on scheduler side 60*request_pro_sec of our approach. Which means if we get more then 1 request pro sec we will do more CPU load.) There are deployments in production (bluehost) that are already bigger then 10k nodes, AFAIK the last numbers I heard were 16k nodes and they didn't use our scheduler at all. So a better upper limit would be something like 30k nodes. At that scale we get 500 RPC broadcasts per second (assuming 60 second periodic update) from periodic updates, plus updates from state changes. If we assume only 1% of compute nodes have instances that are changing state that is an additional 300 RPC broadcasts to the schedulers per second. So now we have 800 per second. How many RPC updates (from compute node to scheduler) per second can a single python thread handle without DB access? With DB Access? As for your second point, I don't follow can you elaborate. Also OpenStack is already deeply invested in using the central DB model for the state of the 'world' and while I am not against changing that, I think we should evaluate that switch in a larger context. Step by step. As first step we could just remove compute_node_get_all method. Which will make our openstack much scalable and fast. Yes, step by step is how to fix
[openstack-dev] [ceilometer] [horizon] Python client uncapping, currently blocking issues
A couple weeks ago after a really *fun* night we started down this road of uncapping all the python clients to ensure that we're actually testing the git clients in the gate. We're close, but we need the help of the horizon and ceilometerclient teams to get us there: 1) we need a rebase on this patch for Horizon - https://review.openstack.org/#/c/36897/ 2) we need a python-ceilometerclient release, as ceilometer uses python-ceilometerclient (for unit tests) which means we can't bump ceilometer client (https://review.openstack.org/#/c/36905/) until it's done. After which we should have a clean gate, and we can look at enforcing behavior in it. Would really appreciate help by the horizon and ceilometer teams to get this sorted shortly. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Split the Identity Backend blueprint
On 07/22/2013 07:43 PM, Miller, Mark M (EB SW Cloud - RD - Corvallis) wrote: Adam, You wrote: [identity] driver = keystone.identity.backends.ldap.Identity [assignment] driver = keystone.assignment.backends.sql.Identity Did you mean to write: [assignment] driver = keystone.assignment.backends.sql.Assignment Yes, that was a mistake on my part. Sorry Mark *From:*Adam Young [mailto:ayo...@redhat.com] *Sent:* Monday, July 22, 2013 12:50 PM *To:* Miller, Mark M (EB SW Cloud - RD - Corvallis) *Cc:* Dolph Mathews; OpenStack Development Mailing List *Subject:* Re: [keystone] Split the Identity Backend blueprint On 07/22/2013 01:38 PM, Miller, Mark M (EB SW Cloud - RD - Corvallis) wrote: Hello, I have been reading source code in an attempt to figure out how to use the new split backend feature, specifically how to split the identity data between an ldap server and the standard Keystone sql database. However, I haven't been able to figure it out quite yet. Does someone have some examples of this new feature in action? Is there another configuration file that is required? [identity] driver = driver = keystone.identity.backends.sql.Identity [assignment] driver = ??? [ldap] Quite a few options Regards, Mark Miller RIght now the only support split approach is LDAP for Identity, SQL for assignments. [identity] driver = keystone.identity.backends.ldap.Identity [assignment] driver = keystone.assignment.backends.sql.Identity ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Neutron Network Statistics
Hi!
I am interested to know if the topic of surfacing networking statistics through
the Neutron APIs has been discussed and if there are any existing blueprints
working on this feature? Specifically, the current APIs,
https://wiki.openstack.org/wiki/Neutron/APIv2-specification, do not support
reading network counters typically available through SNMP. I think these
'/stats' would prove to be quite valuable for performance and fault monitoring.
If I am a Openstack / Neutron tenant and I have created my own networks, how
can I see performance and faults?
Examples,
GET /networks/{network_id}/stats
GET/subnets/{subnet-id}/stats
GET /floatingips/{floatingip_id}/stats
Status : [up,down,error]
Usage : [sum of Tx and Rx packets]
ReceivedRate: [Rate of data received in kB/sec]
TransmittedRate : [Rate of data transmitted in kB/sec]
PacketTx: [total # of packets transmitted since reset]
PacketRx: [total # of packets received in since reset]
Etc ...
Thanks,
Peter.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Neutron Network Statistics
Hi Mellquist
I'm also interested in the feature.
Could you write some blueprint for proposal?
(May be havana is overloaded, so it will go to icehouse)
Best
Nachi
2013/7/22 Mellquist, Peter peter.mellqu...@hp.com:
Hi!
I am interested to know if the topic of surfacing networking statistics
through the Neutron APIs has been discussed and if there are any existing
blueprints working on this feature? Specifically, the current APIs,
https://wiki.openstack.org/wiki/Neutron/APIv2-specification, do not support
reading network counters typically available through SNMP. I think these
‘/stats’ would prove to be quite valuable for performance and fault
monitoring. If I am a Openstack / Neutron tenant and I have created my own
networks, how can I see performance and faults?
Examples,
GET /networks/{network_id}/stats
GET/subnets/{subnet-id}/stats
GET /floatingips/{floatingip_id}/stats
Status : [up,down,error]
Usage : [sum of Tx and Rx packets]
ReceivedRate: [Rate of data received in kB/sec]
TransmittedRate : [Rate of data transmitted in kB/sec]
PacketTx: [total # of packets transmitted since reset]
PacketRx: [total # of packets received in since reset]
Etc …
Thanks,
Peter.
___
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] [vmware] VMwareAPI sub-team status update 2013-07-22
** No meeting this week ** I have a conflict and can't run the meeting this week. We'll be back http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130731T1700 Two of us ran into a problem with an odd pep8 failure: E: nova.conf.sample is not up to date, please run tools/conf/generate_sample.sh Yaguang Tang gave the work around: nova.conf.sample is not up to date, please run tools/conf/generate_sample.sh ,then resubmit. I've put all these reviews under the re-work section. Hopefully this is simple and we can fix them this week. Blueprints targeted for Havana-3: * https://blueprints.launchpad.net/nova/+spec/vmware-image-clone-strategy - nova.conf.sample out of date * https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed-by-one-service - needs review New Blueprint: * https://blueprints.launchpad.net/nova/+spec/vmware-configuration-section Needs one more +2 / Approve button: * https://review.openstack.org/#/c/33504/ * https://review.openstack.org/#/c/36411/ Ready for core-reviewer: * https://review.openstack.org/#/c/33100/ Needs VMware API expert review (no human reviews): * https://review.openstack.org/#/c/30282/ * https://review.openstack.org/#/c/30628/ * https://review.openstack.org/#/c/32695/ * https://review.openstack.org/#/c/37389/ * https://review.openstack.org/#/c/37539/ Work/re-work in progress: * https://review.openstack.org/#/c/30822/ - weird Jenkins issue, fault is not in the patch * https://review.openstack.org/#/c/37819/ - weird Jenkins issue, fault is not in the patch * https://review.openstack.org/#/c/34189/ - in danger of becoming abandoned Needs help/discussion (has a -1): * https://review.openstack.org/#/c/34685/ * https://review.openstack.org/#/c/34685/ Meeting info: * https://wiki.openstack.org/wiki/Meetings/VMwareAPI # Shawn Hartsock ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] There are no OpenStack talks submitted to XenCon, CFP ends this week
Sounds like a deafening silence. -- Joshua McKenty Chief Technology Officer Piston Cloud Computing, Inc. +1 (650) 242-5683 +1 (650) 283-6846 http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has. On Jul 22, 2013, at 12:19 PM, Atwood, Mark mark.atw...@hp.com wrote: Hi! While I was at the Community Leadership Summit conference this weekend, I met the community manager for the Xen hypervisor project. He told me that there are *no* OpenStack talks submitted to the upcoming XenCon conference. The CFP closes this Friday. Allow me to suggest that any of us who have something to say about Xen in Nova in OpenStack, submit papers. Thanks! ..m -- Mark Atwood mark.atw...@hp.com Director - Open Source Engagement for HP Cloud Services and OpenStack +1-206-473-7118 ___ 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] There are no OpenStack talks submitted to XenCon, CFP ends this week
On Tue, Jul 23, 2013 at 5:19 AM, Atwood, Mark mark.atw...@hp.com wrote: Hi! While I was at the Community Leadership Summit conference this weekend, I met the community manager for the Xen hypervisor project. He told me that there are *no* OpenStack talks submitted to the upcoming XenCon conference. The CFP closes this Friday. Allow me to suggest that any of us who have something to say about Xen in Nova in OpenStack, submit papers. Mark -- I can't see an obvious URL for the CFP. Can you chase down the community manager and ask what it is? Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Multi region support for Heat
On 07/23/2013 10:46 AM, Angus Salkeld wrote: On 22/07/13 16:52 +0200, Bartosz Górski wrote: Hi folks, I would like to start a discussion about the blueprint I raised about multi region support. I would like to get feedback from you. If something is not clear or you have questions do not hesitate to ask. Please let me know what you think. Blueprint: https://blueprints.launchpad.net/heat/+spec/multi-region-support Wikipage: https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat What immediatley looks odd to me is you have a MultiCloud Heat talking to other Heat's in each region. This seems like unneccessary complexity to me. I would have expected one Heat to do this job. It should be possible to achieve this with a single Heat installation - that would make the architecture much simpler. I've been thinking about this recently and can see a more generic case than multi-region. Currently a stack is launched into a single cloud, into a context which includes: - keystone endpoint - tenant/project - user credentials If this context was represented as a template resource (and also specified a region), then other resources could specify which context to provision within. This is more generic than multi-region because some contexts can have completely different keystone endpoints (multi-cloud), or can have the same endpoint region and only differ in the credentials or tenant. This could also fulfill requirements such as these https://lists.launchpad.net/openstack/msg25031.html So I would modify your blueprint template examples in the following way: - assume the new HOT template work will provide something that will make those Mappings sections unnecessary - Create a new resource OS::Cloud::Context with properties for keystone endpoint, tenant, credentials and region. - Allow all other resources to optionally specify a context (instead of RegionName) - in the implementation, give the resource the appropriate instance of OpenStackClients which matches the requested context ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
