[openstack-dev] [devstack] Review request for 41053
Hi fellows, Can someone of the devstack-core team please review this patch: https://review.openstack.org/#/c/41053/ ? - Roman ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Documentation and patches
Lorin Hochstein wrote: Would it help if doc bugs were associated with the relevant OpenStack project, in addition to the openstack-manauls project? For example, we could mark nova-related doc bugs as nova project bugs in addition to openstack-manuals project bugs. I'm not a big fan of this idea. The goal of task tracking is to have actionable tasks that can be completed by committing a solution to one given repository. So if the fix is supposed to land in an docs repo (and not, say, in the nova repo), then the bug should appear in the docs task tracking, and be automatically closed when the commit mentioning the bug lands into that repository. The problem if you add a 'nova' task for the same bug is that there will be no way of closing that bug automatically, since there is actually nothing to land in that repository. You're using task tracking to do a notification and an easy search for the developers. That is not what the 'project' means in task tracking. You're using a 'nova' task only to attract 'nova devs' attention. This makes the whole task tracking more inaccurate. I would rather use tagging to link a doc bug (or a QA bug) to a wanted audience, and encourage people to search for tasks being tagged with the name of their project, which is where their help is required. Or use subscription. Something that is linked to the people and not the code repository. -- 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] [Neutron] Resource URL support for more than two levels
Hi Mark, Do you suggest us to pause on this BP. Let us know if someone is already working on this. Regards, Balaji.P From: Mark McClain [mailto:mark.mccl...@dreamhost.com] Sent: Friday, August 30, 2013 5:41 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron] Resource URL support for more than two levels Stay tuned. There are folks working on a proposed set of API framework changes. This will be something that we'll discuss as part of deciding the features in the Icehouse release. mark On Aug 29, 2013, at 10:08 AM, Justin Hammond justin.hamm...@rackspace.commailto:justin.hamm...@rackspace.com wrote: I find that kind of flexibility quite valuable for plugin developers. +1 to this. I'd like to be involved if possible with helping you with it. From: balaji patnala patnala...@gmail.commailto:patnala...@gmail.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thu, 29 Aug 2013 11:02:33 +0530 To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: openst...@lists.openstack.orgmailto:openst...@lists.openstack.org openst...@lists.openstack.orgmailto:openst...@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Resource URL support for more than two levels Hi, When compared to Nova URL implementations, It is observed that the Neutron URL support cannot be used for more than TWO levels. Applications which want to add as PLUG-IN may be restricted with this. We want to add support for changes required for supporting more than TWO Levels of URL by adding the support changes required in Core Neutron Files. Any comments/interest in this.? Regards, Balaji.P On Tue, Aug 27, 2013 at 5:04 PM, B Veera-B37207 b37...@freescale.commailto:b37...@freescale.com wrote: Hi, The current infrastructure provided in Quantum [Grizzly], while building Quantum API resource URL using the base function 'base.create_resource()' and RESOURCE_ATTRIBUTE_MAP/SUB_RESOURCE_ATTRIBUTE_MAP, supports only two level URI. Example: GET /lb/pools/pool_id/members/member_id Some applications may need more than two levels of URL support. Example: GET /lb/pools/pool_id/members/member_id/xyz/xyz_id If anybody is interested in this, we want to contribute for this as BP and make it upstream. Regards, Veera. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] Help needed in installing xmlsec1 python library
Hi, Thank you so much for the response. I got it sorted out. Regards Deepak Selvaraj MSc.,Future Computing University of Kent From: Noorul Islam K M noo...@noorul.com Sent: Monday, September 02, 2013 3:47 AM To: D.Selvaraj Cc: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Help needed in installing xmlsec1 python library D.Selvaraj ds...@kent.ac.uk writes: Hi Stackers, Can someone please suggest me with an easy way to download Xmlsec module in my unix environment ? I have downloaded it but I am not able to install it. When I click make it shows an error stating there is no make available. Please help More information will be helpful to provide concrete answers. 1. Which version of Unix? 2. Where did you download the package from? 3. What are the steps you followed? Thanks and Regards Noorul ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Review request for 40171
Hi, all， Could any one from the nova core team take a look at the patch https://review.openstack.org/#/c/40171/ Clean destroy for project quota * Destroy user quotas under the project when deleting project quota. * Fixes bug 1206479 https://code.launchpad.net/bugs/1206479 Change-Id: Id8391a2f6c25974b990c4a95a6bc99d696cd1c98https://review.openstack.org/#q,Id8391a2f6c25974b990c4a95a6bc99d696cd1c98,n,z Thanks Yingjun ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposal for Raksha, a Data Protection As a Service project
On 01/09/13 23:11, Alex Rudenko wrote: Hello everyone, I would like to ask a question. But, first of all, I would like to say that I'm new to OpenStack so the question might be irrelevant. From what I've understood, the idea is to back up an entire stack including VMs, volumes, networks etc. Let's call the information about how these pieces are interconnected - a topology. This topology also has to be backed up along with VMs, volumes, networks, right? And then this topology can be used to restore the entire stack. As for me, it looks very similar to what the Heat project does. Am I right? So maybe it's possible to use the Heat project for this kind of backup/restore functionality? Best regards, Alex That's actually an excellent question. One of the things that's new in Heat for the Havana release is Suspend/Resume operations on stacks. Basically this involves going through the stack in (reverse) dependency order and calling suspend/resume APIs for each resource where that makes sense. Steve Hardy has written the code for this in such a way as to be pretty generic and allow us to add more operations quite easily in the future. So to the extent that you just require something to go through every resource in a stack in dependency order and call an *existing* backup API, then Heat could fit the bill. If you require co-ordination between e.g. Nova and Cinder then Heat is probably not a good vehicle for implementing that. cheers, Zane. On Sun, Sep 1, 2013 at 10:23 PM, Giri Basava giri.bas...@triliodata.com mailto:giri.bas...@triliodata.com wrote: Dear All, This is a great discussion. If I understand this correctly, this is a proposal for data protection as a whole for the OpenStack cloud, however this is not yet an official incubation request. We are having a good discussion on how we can better serve the adoption of OpenStack. Having said that, the proposal will reuse the existing API and contributions by the community that are already in place. For example, Catlin's point is very valid... the Cinder storage vendor knows the best way to implement snapshots for their storage platforms. No doubt, Raksha should be leveraging that IP. Similarly Raksha will be leveraging Nova, Swift as well as Glance. Don't forget Neutron networking is very critical part of data protection for any VM or set of VMs. No one project has one single answer for a comprehensive data protection. The capabilities for backup and recovery exist in silos in various projects... 1. Images are backed-up by Nova 2. Volumes are backed-up by Cinder 3. I am not aware of a solution that can backup network configuration. 4. Not sure if we have something that can backup the resources of a VM ( vCPUs, Memory Configuration etc.) 5. One can't schedule and automate the above very easily. Ronen's point about consistency groups is right on the mark. We need to treat an application as an unit that may span multiple VMs, one or more images and one or more volumes. Just to reiterate, some form of these capabilities exist in the current projects, however as a user of OpenStack, I may not have a simple one click solution. With this proposal, the ask is to engage in a discussion to address the above use cases. IMHO we are on the right track with these discussions. We will be submitting the code in few days and looking forward for your feedback. I would also suggest a design summit where we can flush out more details. Regards, Giri -Original Message- From: Avishay Traeger [mailto:avis...@il.ibm.com mailto:avis...@il.ibm.com] Sent: Saturday, August 31, 2013 10:53 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] Proposal for Raksha, a Data Protection As a Service project +1 From: Ronen Kat/Haifa/IBM@IBMIL To: OpenStack Development Mailing List openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org, Date: 09/01/2013 08:02 AM Subject:Re: [openstack-dev] Proposal for Raksha, a Data Protection As a Service project Hi Murali, Thanks for answering. I think the issues you raised indeed make sense, and important ones. We need to provide backup both for: 1. Volumes 2. VM instances (VM image, VM metadata, and attached volumes) While the Cinder-backup handles (1), and is a very mature service, it does not provide (2), and for Cinder-backup it does not make sense to handle (2) as well. Backup of VMs (as a package) is beyond the scope of Cinder, which implies that indeed something beyond Cinder should take this task. I think this can be done by having Nova orchestrate or assist the backup, either of volumes or VMs. I think that from a backup perspective, there is also a need for
[openstack-dev] Backwards incompatible migration changes - Discussion
Howdy, At the moment database migrations are required to implement a downgrade method to ensure updates can be rolled back. Currently downgrades are only being tested by Jenkins/tox against sqlite databases. MySQL and Postgresql are not tested and often have special edge cases. I have been working on fixing broken downgrades to work correctly for these engines[0]. However, separate to that, there are cases where a migration may upgrade in a way that is not backwards compatible. For example, a column or even whole table may be dropped. The question of what to do in these circumstances is unclear with many migrations taking different approaches. For example, migration 209 creates a dump_table and populates it with data that will be dropped in the upgrade. This then sits there until the migration is downgraded at which point the data is copied back into place and the dump_table is removed. A similar approach (in [1]) is also being reviewed where lost data is copied into backup_table_migration_214 and restored on downgrade. Then we have the example [2] where no lost data is preserved. These all pose a few different questions. Namely: 1) Do we want to require migrations to downgrade data, or just schema? 2) If we do downgrade data then how should it look? There is perhaps a secondary discussion around the necessity of downgrades given most sysadmins would snapshot/backup a restore point before upgrading themselves but I want to suspend that for the purpose of this discussion. I think with #2 we should at least be listing the migration number in the table name for reference sake. This will also give administrators an idea of when they can safely drop backup tables (as a side note, perhaps this should be documented). We also have examples where data can be reconstructed without a backup table, usually when the migration moves data into a new table (for example [3]). So perhaps another option is we only require downgrading for data that can be reconstructed without backups. Cheers, Josh [0] https://review.openstack.org/#/c/40137/ [1] https://review.openstack.org/#/c/39685/ [2] https://review.openstack.org/#/c/42736/ [3] Migration 186 -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Savanna] supported hadoop versions
Hi Arindam, Currently Savanna has plugin structure and Vanilla plugin supports only Hadoop 1.1.2. But this restriction is reflected mostly in configs for Hadoop. You may take a look to all config-defaults files in https://github.com/stackforge/savanna/tree/master/savanna/plugins/vanilla/resources. Services starting may depend on version too. E.g. all processes are started using hadoop-daemon.sh. You may examine all this start-commands in this file: https://github.com/stackforge/savanna/blob/master/savanna/plugins/vanilla/run_scripts.py. So to support earlier hadoop versions a new plugin may be created and it will not be too different from existing Vanilla plugin. If you are interested in it's implementation you are very welcome! Thanks, Nadya ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposal for Raksha, a Data Protection As a Service project
I am not an expert in Heat but the way I understood the Heat project is that it is an orchestration layer that instantiate a composite application based on a template definition. The template may identify the vms, networks and storage resources needed to instantiate the composite application. Using the template, a tenant may instantiate one of more instances of composite application. Backup service such as Raksha has to backup composite application instances in their entirety. It can look into Heat meta data to understand the application definition and correctly backup the application. I am not sure Heat can manage individual application instances once they are created. I need to do more research on Heat, but I also defer comments to Heat experts. Other way to integrate Heat with Raskha is to make a backup policy part of Heat template and let Heat setup correct backup policy by calling Rakha Apis during composite application instantiation. Thanks, Murali Balcha On Sep 2, 2013, at 7:13 AM, Zane Bitter zbit...@redhat.com wrote: On 01/09/13 23:11, Alex Rudenko wrote: Hello everyone, I would like to ask a question. But, first of all, I would like to say that I'm new to OpenStack so the question might be irrelevant. From what I've understood, the idea is to back up an entire stack including VMs, volumes, networks etc. Let's call the information about how these pieces are interconnected - a topology. This topology also has to be backed up along with VMs, volumes, networks, right? And then this topology can be used to restore the entire stack. As for me, it looks very similar to what the Heat project does. Am I right? So maybe it's possible to use the Heat project for this kind of backup/restore functionality? Best regards, Alex That's actually an excellent question. One of the things that's new in Heat for the Havana release is Suspend/Resume operations on stacks. Basically this involves going through the stack in (reverse) dependency order and calling suspend/resume APIs for each resource where that makes sense. Steve Hardy has written the code for this in such a way as to be pretty generic and allow us to add more operations quite easily in the future. So to the extent that you just require something to go through every resource in a stack in dependency order and call an *existing* backup API, then Heat could fit the bill. If you require co-ordination between e.g. Nova and Cinder then Heat is probably not a good vehicle for implementing that. cheers, Zane. On Sun, Sep 1, 2013 at 10:23 PM, Giri Basava giri.bas...@triliodata.com mailto:giri.bas...@triliodata.com wrote: Dear All, This is a great discussion. If I understand this correctly, this is a proposal for data protection as a whole for the OpenStack cloud, however this is not yet an official incubation request. We are having a good discussion on how we can better serve the adoption of OpenStack. Having said that, the proposal will reuse the existing API and contributions by the community that are already in place. For example, Catlin's point is very valid... the Cinder storage vendor knows the best way to implement snapshots for their storage platforms. No doubt, Raksha should be leveraging that IP. Similarly Raksha will be leveraging Nova, Swift as well as Glance. Don't forget Neutron networking is very critical part of data protection for any VM or set of VMs. No one project has one single answer for a comprehensive data protection. The capabilities for backup and recovery exist in silos in various projects... 1. Images are backed-up by Nova 2. Volumes are backed-up by Cinder 3. I am not aware of a solution that can backup network configuration. 4. Not sure if we have something that can backup the resources of a VM ( vCPUs, Memory Configuration etc.) 5. One can't schedule and automate the above very easily. Ronen's point about consistency groups is right on the mark. We need to treat an application as an unit that may span multiple VMs, one or more images and one or more volumes. Just to reiterate, some form of these capabilities exist in the current projects, however as a user of OpenStack, I may not have a simple one click solution. With this proposal, the ask is to engage in a discussion to address the above use cases. IMHO we are on the right track with these discussions. We will be submitting the code in few days and looking forward for your feedback. I would also suggest a design summit where we can flush out more details. Regards, Giri -Original Message- From: Avishay Traeger [mailto:avis...@il.ibm.com mailto:avis...@il.ibm.com] Sent: Saturday, August 31, 2013 10:53 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] Proposal for Raksha, a Data Protection As a
Re: [openstack-dev] Adding a new column to a table.
You should add also corresponding migration in: Nova/db/sqlalchemy/migrate_repo/... Send from my phone 02.09.2013, в 12:41, Peeyush Gupta gpeey...@ymail.com написал(а): Hi, I have been trying to add a new column to compute_nodes table. I understand the table is defined at db.sqlalchemy.models.py. So, I added a new field in the file and restarted the nova-compute process. But, there is no change in the table. What am I doing wrong? Where should I make changes to add the column? P.S: I am using devstack on Ubuntu 12.04 LTS Thanks, ~Peeyush Gupta ___ 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] [Murano] Murano v0.2 RC1 has been released
Good news everyone! Murano v0.2 Release Candidate 1 has been released, here are links to the sources: API Service: https://github.com/stackforge/murano-api/releases/tag/rc1 Client: https://github.com/stackforge/python-muranoclient/releases/tag/rc1 OS Agent: https://github.com/stackforge/murano-agent/releases/tag/rc1 Orchestration Engine: https://github.com/stackforge/murano-conductor/releases/tag/rc1 Dashboard: https://github.com/stackforge/murano-dashboard/releases/tag/rc1 Documentation: https://github.com/stackforge/murano-docs/releases/tag/rc1 You can try it and if you submit any new bugs (see https://bugs.launchpad.net/murano), there is a good chance they'll be fixed in final version 0.2 - which will be released on 5th September, as planned. We are finishing several screencasts right now, so stay tuned :)! -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposal for Raksha, a Data Protection As a Service project
Hi Murali, Le 02/09/2013 15:19, Murali Balcha a écrit : I am not an expert in Heat but the way I understood the Heat project is that it is an orchestration layer that instantiate a composite application based on a template definition. The template may identify the vms, networks and storage resources needed to instantiate the composite application. Using the template, a tenant may instantiate one of more instances of composite application. As per Heat mission statement [1], Heat role is to manage lifecycle of applications. I'm not an Heat expert at all, but at least regarding Nova, doing a snapshot is conceptually on the same page as boot or destroy. Re: Cinder, I would assume snapshotting a volume is also part of its management, like attaching it. From my pov, it would then make sense to describe the /backup operation /as a extended capability of the Heat API which could then calls its dependencies. -Sylvain Backup service such as Raksha has to backup composite application instances in their entirety. It can look into Heat meta data to understand the application definition and correctly backup the application. I am not sure Heat can manage individual application instances once they are created. I need to do more research on Heat, but I also defer comments to Heat experts. Other way to integrate Heat with Raskha is to make a backup policy part of Heat template and let Heat setup correct backup policy by calling Rakha Apis during composite application instantiation. Thanks, Murali Balcha On Sep 2, 2013, at 7:13 AM, Zane Bitter zbit...@redhat.com wrote: On 01/09/13 23:11, Alex Rudenko wrote: Hello everyone, I would like to ask a question. But, first of all, I would like to say that I'm new to OpenStack so the question might be irrelevant. From what I've understood, the idea is to back up an entire stack including VMs, volumes, networks etc. Let's call the information about how these pieces are interconnected - a topology. This topology also has to be backed up along with VMs, volumes, networks, right? And then this topology can be used to restore the entire stack. As for me, it looks very similar to what the Heat project does. Am I right? So maybe it's possible to use the Heat project for this kind of backup/restore functionality? Best regards, Alex That's actually an excellent question. One of the things that's new in Heat for the Havana release is Suspend/Resume operations on stacks. Basically this involves going through the stack in (reverse) dependency order and calling suspend/resume APIs for each resource where that makes sense. Steve Hardy has written the code for this in such a way as to be pretty generic and allow us to add more operations quite easily in the future. So to the extent that you just require something to go through every resource in a stack in dependency order and call an *existing* backup API, then Heat could fit the bill. If you require co-ordination between e.g. Nova and Cinder then Heat is probably not a good vehicle for implementing that. cheers, Zane. On Sun, Sep 1, 2013 at 10:23 PM, Giri Basava giri.bas...@triliodata.com mailto:giri.bas...@triliodata.com wrote: Dear All, This is a great discussion. If I understand this correctly, this is a proposal for data protection as a whole for the OpenStack cloud, however this is not yet an official incubation request. We are having a good discussion on how we can better serve the adoption of OpenStack. Having said that, the proposal will reuse the existing API and contributions by the community that are already in place. For example, Catlin's point is very valid... the Cinder storage vendor knows the best way to implement snapshots for their storage platforms. No doubt, Raksha should be leveraging that IP. Similarly Raksha will be leveraging Nova, Swift as well as Glance. Don't forget Neutron networking is very critical part of data protection for any VM or set of VMs. No one project has one single answer for a comprehensive data protection. The capabilities for backup and recovery exist in silos in various projects... 1. Images are backed-up by Nova 2. Volumes are backed-up by Cinder 3. I am not aware of a solution that can backup network configuration. 4. Not sure if we have something that can backup the resources of a VM ( vCPUs, Memory Configuration etc.) 5. One can't schedule and automate the above very easily. Ronen's point about consistency groups is right on the mark. We need to treat an application as an unit that may span multiple VMs, one or more images and one or more volumes. Just to reiterate, some form of these capabilities exist in the current projects, however as a user of OpenStack, I may not have a simple one click solution. With this proposal, the ask is to engage in a discussion to address the above use cases. IMHO we are on the
[openstack-dev] [Murano] Meeting Minutes 2013-08-26
Hello, Below, you can see the meeting minutes from today's Murano meeting. Minutes: http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-09-02-15.02.html Minutes (text): http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-09-02-15.02.txt Log: http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-09-02-15.02.log.html The next meeting will be 9th Sep. Have a nice day. -- Denis ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Infra] Meeting Tuesday September 3rd at 19:00 UTC
The OpenStack Infrastructure (Infra) team is hosting our weekly meeting tomorrow, Tuesday September 3rd, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend. -- Elizabeth Krumbach Joseph || Lyz || pleia2 http://www.princessleia.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] Testing support for PCI passthrough
Hi guys, Great work on adding PCI pass-through support to nova. We would like to test the support for PCI pass-through. We thought to use devstack (nova) on physical machine with SR-IOV devices and apply patches that are still under review. Can you please advise what should be defined in nova.conf and what should be requested on nova-boot command in order to create VM with PCI device? Is it according to documented at https://wiki.openstack.org/wiki/Enhanced-platform-awareness-pcie? Can you please help me to identify the use cases that merged patches support? Thank you very much, Irena ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Openstack Folsom + Quantum + XenServer 6.1.0 + Windows VM
Hi, I'm having a network problem when spawn windows vm into xenserver. A 'tap' and 'vif' interface are created until the boot is completed, after that interface 'tap' is removed and interface 'vif' loses id tag From what i searched, because of this Windows VM cant configure network correctly. ps; I can see the DHCP requests on the host, but them arent being sent to the network node by gre tunnel. It's been weeks trying to find for a solution with no success. Can someone please help me on this issue? I've followed the link below to configure xenserver to openstack https://github.com/openstack/nova/blob/master/plugins/xenserver/doc/networking.rst Thanks in advance -- Dbarros 5585 9919 6279 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] sample configuration file
Hi, Whilst reviewing the olso messaging (my poor browser with all of the open tabs) it has come to my attention that the nova sample configuration file no longer has the RPC message configuration values. The common CFG values are also no longer in the file. I think that this is a bug and would like to know what others think. Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Questions related to live migration without target host
Greetings, There is an issue related to live migration without target host might want to get more discussion/feedback from you experts: https://bugs.launchpad.net/nova/+bug/1214943. I have proposed a fix for this issue ( https://review.openstack.org/#/c/43213/), the fix was directly remove the checking for free ram and always trust the result from nova scheduler as nova scheduler already select a best host for live migration based on the function filter_scheduler.py:select_hosts. Please show your comments if any, you can also directly append your comments to https://review.openstack.org/#/c/43213/. Thanks, Jake Liu UnitedStack Inc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Questions related to live migration without target host
Greetings, There is an issue related to live migration might want to get more discussion/feedback from you experts: https://bugs.launchpad.net/nova/+bug/1214943 I have proposed a fix for this issue ( https://review.openstack.org/#/c/43213/), the fix was directly remove the checking for free ram and always trust the result from nova scheduler as nova scheduler already select a best host for live migration based on Thanks, Jake Liu UnitedStack Inc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] sample configuration file
This issue was first raised here, https://review.openstack.org/#/c/38333/ Some of us are trying to find a work-around solution but apparently things aren't as simple as they seem. On Tue, Sep 3, 2013 at 5:19 AM, Gary Kotton gkot...@vmware.com wrote: Hi, Whilst reviewing the olso messaging (my poor browser with all of the open tabs) it has come to my attention that the nova sample configuration file no longer has the RPC message configuration values. The common CFG values are also no longer in the file. I think that this is a bug and would like to know what others think. Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Intel SSG/STOD/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Scheduler sub-group meeting on 9/3
Let's try and have a meeting this week (hopefully a few can attend). Topics that come to mind: 1) Multiple-scheduler-drivers (seems to be some open issues from the mailing list) 2) Scheduler design sessions at the Icehouse summit 3) Perspective for Nova scheduler (Boris' proposal at https://docs.google.com/document/d/1_DRv7it_mwalEZzLy5WO92TJcummpmWL4NWsWf0UWiQ/edit#heading=h.6ixj0ctv4rwu ) -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
