Re: [openstack-dev] [cinder]Do we have project scope for cinder?
Hi WangHao This was quite thoroughly discussed during the early discussions on replication. The general statement was 'not yet'. Getting any kind of workable replication API has proven to be very, very difficult to get right - we won't know for another full cycle whether we've actually gotten it somewhere near right, as operators start to deploy it. Piling more feature in the replication API before a) it has been used by operators and b) storage vendors have implemented what we already has would IMO be a mistake. None of this means that more DR interfaces don't belong in cinder, just that getting them right, getting them universal and getting them useful is quite a hard problem, and not one we should be in a rush to solve. Particularly as DR and replication is still a niche area of cinder, and we still have major issues in our basic functionality. On 30 November 2015 at 03:45, hao wang wrote: > Sean and Michal, > > In fact, there is a reason that I ask this question. Recently I have a > confusion about if cinder should provide the ability of Disaster > Recovery to storage resources, like volume. I mean we have volume > replication v1&v2, but for DR, specially DR between two independent > OpenStack sites(production and DR site), I feel we still need more > features to support it, for example consistency group for replication, > etc. I'm not sure if those features belong in Cinder or some new > project for DR. > > BR > WangHao > > 2015-11-30 3:02 GMT+08:00 Sean McGinnis : > > On Sun, Nov 29, 2015 at 11:44:19AM +, Dulko, Michal wrote: > >> On Sat, 2015-11-28 at 10:56 +0800, hao wang wrote: > >> > Hi guys, > >> > > >> > I notice nova have a clarification of project scope: > >> > http://docs.openstack.org/developer/nova/project_scope.html > >> > > >> > I want to find cinder's, but failed, do you know where to find it? > >> > > >> > It's important to let developers know what feature should be > >> > introduced into cinder and what shouldn't. > >> > > >> > BR > >> > Wang Hao > >> > >> I believe Nova team needed to formalize the scop to have an explanation > >> for all the "this doesn't belong in Nova" comments on feature requests. > >> Does Cinder suffer from similar problems? From my perspective it's not > >> critically needed. > > > > I agree. I haven't seen a need for something like that with Cinder. Wang > > Hao, is there a reason you feel you need that? > > > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [RFC] how to enable xbzrle compress for live migration
2015-11-30 14:45 GMT+08:00 Koniszewski, Pawel : > > -Original Message- > > From: Murray, Paul (HP Cloud) [mailto:pmur...@hpe.com] > > Sent: Friday, November 27, 2015 4:29 PM > > To: Daniel P. Berrange; Carlton, Paul (Cloud Services) > > Cc: 少合冯; OpenStack Development Mailing List (not for usage questions); > > John Garbutt; Koniszewski, Pawel; Jin, Yuntong; Feng, Shaohe; Qiao, > Liyong > > Subject: RE: [nova] [RFC] how to enable xbzrle compress for live > migration > > > > > > > > > -Original Message- > > > From: Daniel P. Berrange [mailto:berra...@redhat.com] > > > Sent: 26 November 2015 17:58 > > > To: Carlton, Paul (Cloud Services) > > > Cc: 少合冯; OpenStack Development Mailing List (not for usage > > questions); > > > John Garbutt; pawel.koniszew...@intel.com; yuntong@intel.com; > > > shaohe.f...@intel.com; Murray, Paul (HP Cloud); liyong.q...@intel.com > > > Subject: Re: [nova] [RFC] how to enable xbzrle compress for live > > > migration > > > > > > On Thu, Nov 26, 2015 at 05:49:50PM +, Paul Carlton wrote: > > > > Seems to me the prevailing view is that we should get live migration > > > > to figure out the best setting for itself where possible. There was > > > > discussion of being able have a default policy setting that will > > > > allow the operator to define balance between speed of migration and > > > > impact on the instance. This could be a global default for the > > > > cloud with overriding defaults per aggregate, image, tenant and > > > > instance as well as the ability to vary the setting during the > migration > > operation. > > > > > > > > Seems to me that items like compression should be set in > > > > configuration files based on what works best given the cloud > operator's > > environment? > > > > > > Merely turning on use of compression is the "easy" bit - there needs > > > to be a way to deal with compression cache size allocation, which > > > needs to have some smarts in Nova, as there's no usable "one size fits > > > all" value for the compression cache size. If we did want to hardcode > > > a compression cache size, you'd have to pick set it as a scaling > factor against > > the guest RAM size. > > > This is going to be very heavy on memory usage, so there needs careful > > > design work to solve the problem of migration compression triggering > > > host OOM scenarios, particularly since we can have multiple concurrent > > > migrations. > > > > > > > > > Use cases for live migration generally fall into two types: > > > > 1. I need to empty the host (host maintenance/reboot) > > > > 2. I generally want to balance load on the cloud > > > > The first case is by far the most common need right now and in that case > the > > node gets progressively more empty as VMs are moved off. So the resources > > available for caching etc. grow as the process goes on. > > I'd rather say that these resources might shrink. You need to turn off one > compute node, stack more VMs on remaining compute nodes and you need to > allocate cache on both sides, source and destination. > why do we need on destination? > > > The second case is less likely to be urgent from the operators point of > view, > > so doing things more slowly may not be a problem. > > > > So looking at how much resource is available at the start of a migration > and > > deciding then what to do on a per VM basis is probably not a bad idea. > > Especially if we can differentiate between the two cases. > > > > > > > Regards, > > > Daniel > > > -- > > > |: http://berrange.com -o- > http://www.flickr.com/photos/dberrange/ > > :| > > > |: http://libvirt.org -o- > http://virt-manager.org :| > > > |: http://autobuild.org -o- > http://search.cpan.org/~danberr/ :| > > > |: http://entangle-photo.org -o- > http://live.gnome.org/gtk-vnc :| > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] 答复: [congress]role in Congress
Hi Tim, In the implementation of Congress UI, I have realized that we need to add role assignment. In many systems and cases, RBAC (Role-Based Access Control) is an vital function which are beneficial to the division of work. I think we should have “admin” and “tenant” user at least. The admin user could define predicates or complicated relations used in the violations, and tenant user could just use the predicates defined by admin user. A typical example is that, the owner of network connected to VM should be in the same group with the owner of this VM. In this example, same_group is a predicates or complicated relations. It should be defined by admin user. And this predicate could be used by any tenant user. In this way, some typical or common predicates could be defined in a individual admin board, and other tenant user could choose which one to use. Yali 发件人: Tim Hinrichs [mailto:t...@styra.com] 发送时间: 2015年11月30日 10:37 收件人: zhangyali (D); OpenStack Development Mailing List (not for usage questions) 主题: Re: [openstack-dev][congress]role in Congress Hi Yali, We didn't discuss role assignment for service users in Tokyo. Could you explain a bit more what you need? Tim On Sun, Nov 29, 2015 at 7:33 PM zhangyali (D) mailto:zhangyali...@huawei.com>> wrote: Hi Tim and All, I remember there is a topic named “role assignment for service users” in the Tokyo Summit. Since I have not heard any message of this topic. Does anyone could contribute some information for me? I think it is vital for my design of Congress UI in horizon. Thanks a lot! Best Regards, Yali __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder]Do we have project scope for cinder?
Hi Philipp, 2015-11-30 14:36 GMT+08:00 Philipp Marek : > Hi Hao Wang, > >> In fact, there is a reason that I ask this question. Recently I have a >> confusion about if cinder should provide the ability of Disaster >> Recovery to storage resources, like volume. I mean we have volume >> replication v1&v2, but for DR, specially DR between two independent >> OpenStack sites(production and DR site), I feel we still need more >> features to support it, for example consistency group for replication, >> etc. > I'm currently developing consistency groups for the DRBD volume driver. > > > The only way it can do replication *is* for a consistency group as a whole, > so that feature will be available soonish - if you don't care that > Cinder/Openstack knows nothing about the ongoing replication. > Yes, recently I have some ideas about the DR, including the CG of replication. And I heard a different voice that we maybe shouldn't introduce DR into cinder, but on top of cinder, like another new project to focus on DR. So I want to get some opinions from our guys. > >> I'm not sure if those features belong in Cinder or some new >> project for DR. > IMO this belongs to Cinder. This is my point of view too, I think Cinder should provide the basic and atomical API to support DR function, of course the orchestration of DR process could be in Heat or some DR management system. > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova-scheduler] Scheduler sub-group meeting - Agenda 11/30
Meeting on #openstack-meeting-alt at 1400 UTC (7:00AM MDT) 1) Spec & BPs - https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking 2) Bugs - https://bugs.launchpad.net/nova/+bugs?field.tag=scheduler 3) Opens -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [RFC] how to enable xbzrle compress for live migration
> -Original Message- > From: Murray, Paul (HP Cloud) [mailto:pmur...@hpe.com] > Sent: Friday, November 27, 2015 4:29 PM > To: Daniel P. Berrange; Carlton, Paul (Cloud Services) > Cc: 少合冯; OpenStack Development Mailing List (not for usage questions); > John Garbutt; Koniszewski, Pawel; Jin, Yuntong; Feng, Shaohe; Qiao, Liyong > Subject: RE: [nova] [RFC] how to enable xbzrle compress for live migration > > > > > -Original Message- > > From: Daniel P. Berrange [mailto:berra...@redhat.com] > > Sent: 26 November 2015 17:58 > > To: Carlton, Paul (Cloud Services) > > Cc: 少合冯; OpenStack Development Mailing List (not for usage > questions); > > John Garbutt; pawel.koniszew...@intel.com; yuntong@intel.com; > > shaohe.f...@intel.com; Murray, Paul (HP Cloud); liyong.q...@intel.com > > Subject: Re: [nova] [RFC] how to enable xbzrle compress for live > > migration > > > > On Thu, Nov 26, 2015 at 05:49:50PM +, Paul Carlton wrote: > > > Seems to me the prevailing view is that we should get live migration > > > to figure out the best setting for itself where possible. There was > > > discussion of being able have a default policy setting that will > > > allow the operator to define balance between speed of migration and > > > impact on the instance. This could be a global default for the > > > cloud with overriding defaults per aggregate, image, tenant and > > > instance as well as the ability to vary the setting during the migration > operation. > > > > > > Seems to me that items like compression should be set in > > > configuration files based on what works best given the cloud operator's > environment? > > > > Merely turning on use of compression is the "easy" bit - there needs > > to be a way to deal with compression cache size allocation, which > > needs to have some smarts in Nova, as there's no usable "one size fits > > all" value for the compression cache size. If we did want to hardcode > > a compression cache size, you'd have to pick set it as a scaling factor > > against > the guest RAM size. > > This is going to be very heavy on memory usage, so there needs careful > > design work to solve the problem of migration compression triggering > > host OOM scenarios, particularly since we can have multiple concurrent > > migrations. > > > > > Use cases for live migration generally fall into two types: > > 1. I need to empty the host (host maintenance/reboot) > > 2. I generally want to balance load on the cloud > > The first case is by far the most common need right now and in that case the > node gets progressively more empty as VMs are moved off. So the resources > available for caching etc. grow as the process goes on. I'd rather say that these resources might shrink. You need to turn off one compute node, stack more VMs on remaining compute nodes and you need to allocate cache on both sides, source and destination. > The second case is less likely to be urgent from the operators point of view, > so doing things more slowly may not be a problem. > > So looking at how much resource is available at the start of a migration and > deciding then what to do on a per VM basis is probably not a bad idea. > Especially if we can differentiate between the two cases. > > > > Regards, > > Daniel > > -- > > |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ > :| > > |: http://libvirt.org -o- http://virt-manager.org > > :| > > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ > > :| > > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc > > :| smime.p7s Description: S/MIME cryptographic signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][Tempest] Use tempest-config for tempest-cli-improvements
Hi, I agree with Ken'ichi's opinion, basically. Tempest users should know "what do we test for?" and we shouldn't discover values that we test for automatically. If users seems that "My current cloud is good. This is what I expect.", discovering function could work. But I suppose many of users would use tempest-config-generator for a new their cloud. So I feel the tool users could be misunderstanding easily. But I also think that tempest users don't need to know all of the configurations. So, how about something like introducing "a configuration wizard" for tempest configuration? This is a just idea, though.. Anyway, if you have the motivation to introduce tempest-config, how about writing a spec for the feature for a concrete discussion? (I think we should have agreements about the target issues, users, solutions, etc.) Best Regards, -- Masayuki Igawa 2015年11月29日(日) 22:07 Yair Fried : > Hi, > I agree with Jordan. > We don't have to use the tool as part of the gate. It's target audience is > people and not CI systems. More specifically - new users. > However, we could add a gate (or a few) for the tool that makes sure a > proper conf file is generated. It doesn't have to run the tests, just > compare the output of the script to the conf generated by devstack. > > Re Rally - I believe the best place for tempest configuration script is > within tempest. That said, if the Tempest community doesn't want this tool, > we'll have to settle for the Rally solution. > > Regards > Yair > > On Fri, Nov 27, 2015 at 11:31 AM, Jordan Pittier < > jordan.pitt...@scality.com> wrote: > >> Hi, >> I think this script is valuable to some users: Rally and Red Hat >> expressed their needs, they seem clear. >> >> This tool is far from bullet proof and if used blindly or in case of >> bugs, Tempest could be misconfigured. So, we could have this tool inside >> the Tempest repository (in the tools/) but not use it at all for the Gate. >> >> I am not sure I fully understand the resistance for this, if we don"t use >> this config generator for the gate, what's the risk ? >> >> Jordan >> >> On Fri, Nov 27, 2015 at 8:05 AM, Ken'ichi Ohmichi >> wrote: >> >>> 2015-11-27 15:40 GMT+09:00 Daniel Mellado : >>> > I still do think that even if there are some issues addressed to the >>> > feature, such as skipping tests in the gate, the feature itself it's >>> still >>> > good -we just won't use it for the gates- >>> > Instead it'd be used as a wrapper for a user who would be interested on >>> > trying it against a real/reals clouds. >>> > >>> > Ken, do you really think a tempest user should know all tempest >>> options? >>> > As you pointed out there are quite a few of them and even if they >>> should at >>> > least know their environment, this script would set a minimum >>> acceptable >>> > default. Do you think PTL and Pre-PTL concerns that we spoke of would >>> still >>> > apply to that scenario? >>> >>> If Tempest users run part of tests of Tempest, they need to know the >>> options which are used with these tests only. >>> For example, current Tempest contains ironic API tests and the >>> corresponding options. >>> If users don't want to run these tests because the cloud don't support >>> ironic API, they don't need to know/setup these options. >>> I feel users need to know necessary options which are used on tests >>> they want, because they need to investigate the reason if facing a >>> problem during Tempest tests. >>> >>> Now Tempest options contain their default values, but you need a >>> script for changing them from the default. >>> Don't these default values work for your cloud at all? >>> If so, these values should be changed to better. >>> >>> Thanks >>> Ken Ohmichi >>> >>> --- >>> >>> > Andrey, Yaroslav. Would you like to revisit the blueprint to adapt it >>> to >>> > tempest-cli improvements? What do you think about this, Masayuki? >>> > >>> > Thanks for all your feedback! ;) >>> > >>> > El 27/11/15 a las 00:15, Andrey Kurilin escribió: >>> > >>> > Sorry for wrong numbers. The bug-fix for issue with counters is merged. >>> > Correct numbers(latest result from rally's gate[1]): >>> > - total number of executed tests: 1689 >>> > - success: 1155 >>> > - skipped: 534 (neutron,heat,sahara,ceilometer are disabled. [2] >>> should >>> > enable them) >>> > - failed: 0 >>> > >>> > [1] - >>> > >>> http://logs.openstack.org/27/246627/11/gate/gate-rally-dsvm-verify-full/800bad0/rally-verify/7_verify_results_--html.html.gz >>> > [2] - https://review.openstack.org/#/c/250540/ >>> > >>> > On Thu, Nov 26, 2015 at 3:23 PM, Yaroslav Lobankov < >>> yloban...@mirantis.com> >>> > wrote: >>> >> >>> >> Hello everyone, >>> >> >>> >> Yes, I am working on this now. We have some success already, but >>> there is >>> >> a lot of work to do. Of course, some things don't work ideally. For >>> example, >>> >> in [2] from the previous letter we have not 24 skipped tests, >>> actually much >>> >> more. So we have a bug somewhere :) >>> >> >>> >> Reg
Re: [openstack-dev] Devices in VM that are not in instance XML
Don't mean to keep replying to myself, but here are the details: · Kilo (RHEL OSP 7.0, but installed via packstack) · Compute host is RHEL 7.1 · VM is Centos 7.1 From: Sundar Nadathur Sent: Sunday, November 29, 2015 10:03 PM To: 'openstack-dev@lists.openstack.org' Subject: RE: Devices in VM that are not in instance XML Typo: nova/virt/libvirt/libvirt.py --> nova/virt/libvirt/driver.py Cheers, Sundar From: Sundar Nadathur Sent: Sunday, November 29, 2015 9:59 PM To: 'openstack-dev@lists.openstack.org' Subject: Devices in VM that are not in instance XML Hi, I am facing a strange issue where I remove some devices from a VM's xml before creating the domain, but both device types are still present in the VM, but with a different definition. Background: I am attempting to inject or remove some devices from specific VMs before they are brought up. More specifically, I'd like to update the instance's domain XML on the compute host before the instance is launched, as part of Nova Compute. This is to be done programmatically, not manually. However, the build_instance hook in Nova compute doesn't quite let one do that. In the 'pre' hook, the instance XML is not yet defined. In the post hook, it is defined but it already too late because the domain has been created from the xml. What I did: So, as an experiment, I modified nova/virt/libvirt/libvirt.py, specifically def spawn(...): disk_info = ... self._create_image(...) xml = self._get_guest_xml(..., write_to_disk=False) # -- Modify the xml here and write it to libvirt.xml self._create_domain_and_network(context, xml, ...) Also, I verified in _create_domain, just before: domain = self._conn.defineXML(xml) that the xml is as I intended. Problem: But it doesn't work. In this experiment, I am trying to remove the memballoon (virtio) device and an USB device from the domain XML. But both show up in the VM under lspci after the VM boots up, but with a different definition. The original XML had: Both got removed. But 'virsh dumpxml' of the VM shows: Where are these devices coming from, since they are not present in the defineXML that nova.compute.libvirt driver invokes? Cheers, Sundar Confidentiality Notice. This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder]Do we have project scope for cinder?
Hi Hao Wang, > In fact, there is a reason that I ask this question. Recently I have a > confusion about if cinder should provide the ability of Disaster > Recovery to storage resources, like volume. I mean we have volume > replication v1&v2, but for DR, specially DR between two independent > OpenStack sites(production and DR site), I feel we still need more > features to support it, for example consistency group for replication, > etc. I'm currently developing consistency groups for the DRBD volume driver. The only way it can do replication *is* for a consistency group as a whole, so that feature will be available soonish - if you don't care that Cinder/Openstack knows nothing about the ongoing replication. > I'm not sure if those features belong in Cinder or some new > project for DR. IMO this belongs to Cinder. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Devices in VM that are not in instance XML
Typo: nova/virt/libvirt/libvirt.py --> nova/virt/libvirt/driver.py Cheers, Sundar From: Sundar Nadathur Sent: Sunday, November 29, 2015 9:59 PM To: 'openstack-dev@lists.openstack.org' Subject: Devices in VM that are not in instance XML Hi, I am facing a strange issue where I remove some devices from a VM's xml before creating the domain, but both device types are still present in the VM, but with a different definition. Background: I am attempting to inject or remove some devices from specific VMs before they are brought up. More specifically, I'd like to update the instance's domain XML on the compute host before the instance is launched, as part of Nova Compute. This is to be done programmatically, not manually. However, the build_instance hook in Nova compute doesn't quite let one do that. In the 'pre' hook, the instance XML is not yet defined. In the post hook, it is defined but it already too late because the domain has been created from the xml. What I did: So, as an experiment, I modified nova/virt/libvirt/libvirt.py, specifically def spawn(...): disk_info = ... self._create_image(...) xml = self._get_guest_xml(..., write_to_disk=False) # -- Modify the xml here and write it to libvirt.xml self._create_domain_and_network(context, xml, ...) Also, I verified in _create_domain, just before: domain = self._conn.defineXML(xml) that the xml is as I intended. Problem: But it doesn't work. In this experiment, I am trying to remove the memballoon (virtio) device and an USB device from the domain XML. But both show up in the VM under lspci after the VM boots up, but with a different definition. The original XML had: Both got removed. But 'virsh dumpxml' of the VM shows: Where are these devices coming from, since they are not present in the defineXML that nova.compute.libvirt driver invokes? Cheers, Sundar Confidentiality Notice. This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Devices in VM that are not in instance XML
Hi, I am facing a strange issue where I remove some devices from a VM's xml before creating the domain, but both device types are still present in the VM, but with a different definition. Background: I am attempting to inject or remove some devices from specific VMs before they are brought up. More specifically, I'd like to update the instance's domain XML on the compute host before the instance is launched, as part of Nova Compute. This is to be done programmatically, not manually. However, the build_instance hook in Nova compute doesn't quite let one do that. In the 'pre' hook, the instance XML is not yet defined. In the post hook, it is defined but it already too late because the domain has been created from the xml. What I did: So, as an experiment, I modified nova/virt/libvirt/libvirt.py, specifically def spawn(...): disk_info = ... self._create_image(...) xml = self._get_guest_xml(..., write_to_disk=False) # -- Modify the xml here and write it to libvirt.xml self._create_domain_and_network(context, xml, ...) Also, I verified in _create_domain, just before: domain = self._conn.defineXML(xml) that the xml is as I intended. Problem: But it doesn't work. In this experiment, I am trying to remove the memballoon (virtio) device and an USB device from the domain XML. But both show up in the VM under lspci after the VM boots up, but with a different definition. The original XML had: Both got removed. But 'virsh dumpxml' of the VM shows: Where are these devices coming from, since they are not present in the defineXML that nova.compute.libvirt driver invokes? Cheers, Sundar Confidentiality Notice. This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstackclient][keystoneclient][devstack] Openstackclient do not work with auth_url without v2.0
I use 'unset OS_AUTH_TYPE' to get it work after sourcing crdentials. On Mon, Nov 30, 2015 at 6:13 AM, lichen.hangzhou wrote: > Hi guys, > > I re-installed my devstack environment recently on ubuntu 14.04 > > I try to use openstackclient command with devstack created user: > source devstack/accrc/admin/admin > openstack project list > > The command failed with error : The resource could not be found. (HTTP > 404). > And, the issue can be solved by change the auth_url with a v2.0 at the end > : export OS_AUTH_URL=http://9.197.45.36:35357/v2.0 > > I reported a bug > https://bugs.launchpad.net/python-keystoneclient/+bug/1519624 and > submitted a fix https://review.openstack.org/#/c/249578/. > > Because When I run openstackclient command with --debug, and I get log : > http://paste.openstack.org/show/479950/. > From the log, it is easy to see openstackclient already figured out this > command should sent to keystoneclient v2 even there is no v2.0 in the > environment setting. > So, I think this is a bug for keystoneclient. > But, some other guys do not agree with that, because keystoneclient > shouldn't have to check and parse URL bits like that. > > I do not really understand why keystoneclient can not do that. > > And, for openstack users, do they must explicit set the version of > keystone ? > While, I tested, with the same environment settings, > novaclient/glanceclient/neutronclient all can work, the issue only happenes > when we using openstacklcient. > > So, anyone can explain a little bit more why to me ? > > Thanks. > -chen > > > > > > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][tap-as-a-service] Tap-as-a-service API
hi, On Fri, Nov 27, 2015 at 2:02 AM, Fawad Khaliq wrote: > Folks, > > Any plan to revive this [1] so we can discuss and finalize the use cases and > APIs. > > [1] https://review.openstack.org/#/c/96149/ i think Anil will explain the history of the project. i suspect neutron-spec isn't appropriate place for us anymore. we can have subproject spec as other projects have. [2] [2] eg. https://github.com/openstack/networking-midonet/tree/master/specs > > Thanks, > Fawad Khaliq > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][midonet] networking-midonet weekly irc meeting
hi, we are going to migrate networking-midonet meeting from slack to irc. the plan is to have it 7:00 UTC on every Tuesdays. if you are interested but have a different time preference, please speak up. thank you. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [openstackclient][keystoneclient][devstack] Openstackclient do not work with auth_url without v2.0
Hi guys, I re-installed my devstack environment recently on ubuntu 14.04 I try to use openstackclient command with devstack created user: source devstack/accrc/admin/admin openstack project list The command failed with error : The resource could not be found. (HTTP 404). And, the issue can be solved by change the auth_url with a v2.0 at the end : export OS_AUTH_URL=http://9.197.45.36:35357/v2.0 I reported a bug https://bugs.launchpad.net/python-keystoneclient/+bug/1519624 and submitted a fix https://review.openstack.org/#/c/249578/. Because When I run openstackclient command with --debug, and I get log : http://paste.openstack.org/show/479950/. From the log, it is easy to see openstackclient already figured out this command should sent to keystoneclient v2 even there is no v2.0 in the environment setting. So, I think this is a bug for keystoneclient. But, some other guys do not agree with that, because keystoneclient shouldn't have to check and parse URL bits like that. I do not really understand why keystoneclient can not do that. And, for openstack users, do they must explicit set the version of keystone ? While, I tested, with the same environment settings, novaclient/glanceclient/neutronclient all can work, the issue only happenes when we using openstacklcient. So, anyone can explain a little bit more why to me ? Thanks. -chen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [congress]role in Congress
Hi Yali, We didn't discuss role assignment for service users in Tokyo. Could you explain a bit more what you need? Tim On Sun, Nov 29, 2015 at 7:33 PM zhangyali (D) wrote: > Hi Tim and All, > > > > I remember there is a topic named “role assignment for service users” in > the Tokyo Summit. Since I have not heard any message of this topic. Does > anyone could contribute some information for me? I think it is vital for my > design of Congress UI in horizon. Thanks a lot! > > > > > > Best Regards, > > Yali > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [murano]How to use Murano to transmit files to Mistral and execute scripts on Mistral
Stan, Thanks for your valuable comments! For the object storage support, does Murano have any plan to support the auto-uploading function? Thanks, Tony From: Stan Lagun [mailto:sla...@mirantis.com] Sent: Sunday, November 29, 2015 6:32 AM To: OpenStack Development Mailing List (not for usage questions) Cc: WANG, Ming Hao (Tony T) Subject: Re: [openstack-dev] [murano]How to use Murano to transmit files to Mistral and execute scripts on Mistral Hi Tony, Technically your solution is possible. Murano agent can be installed manually. All queue names are in agent's config file. Murano can talk to that manually installed agent and put files to that server. However I strongly advice not to do that. First of all it is not secure. Murano agent was designed as a remote execution mechanism rather than a tool to transfer files. Also it was design to be installed on VM rather that on a shared server. Currently there is no authentication for agents. Although it is not truly secure it still provides significant level of security because to make use of the agent you need to know its queue name which is a long random string that only murano engine and agent know and AMQP doesn't provide an API to query list of queue names. But if you install agent manually there will be a single queue. And all applications that need to access that agent will also need to know queue name. Thus it can be easily be compromised and attackers will gain ability to execute arbitrary code on the nova server. It is also doesn't seem like a right solution. There should not be such specific requirements like this to perform such trivial thing. Especially if it involves using tool that was design for something else. So what is the right solution? I can see 2 possible ways to address this issue: 1. Improve Mistral API to support file attachments to its workbooks (if it doesn't support it yet). Improve murano-mistral integration to support this feature. 2. Implement integration of Murano with object storage. Thus it will be possible from Murano workflow to upload file and provide Mistral with a URI to it. Solution #2 seem to be better. At least because it opens new possibilities for all applications and not just those that use Mistral. There is also a workaround that I can think of: make Murano application create temporary VM with FTP server or something like that, put file into it and give Mistral a URI it could use to access the file. Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Wed, Nov 18, 2015 at 1:06 PM, WANG, Ming Hao (Tony T) mailto:tony.a.w...@alcatel-lucent.com>> wrote: Dear Alexander and Murano developers and testers, Any suggestion for this? ☺ Thanks, Tony From: WANG, Ming Hao (Tony T) Sent: Tuesday, November 17, 2015 6:12 PM To: OpenStack Development Mailing List (not for usage questions) Subject: RE: [openstack-dev] [murano]How to use Murano to transmit files to Mistral and execute scripts on Mistral Alexander, Thanks for your response. During the workflow running stage, it may need to access some other artifacts. In my case, I use Mistral workflow to call Ansible playbook, and I need Murano to put Ansible playbook into right place on Mistral server so that Mistral workflow can find it. Thanks, Tony From: Alexander Tivelkov [mailto:ativel...@mirantis.com] Sent: Tuesday, November 17, 2015 4:19 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [murano]How to use Murano to transmit files to Mistral and execute scripts on Mistral Hi Tony, Probably I am missing something, but why do you need Murano Agent to interact with Mistral? You can call Mistral APIs right from MuranoPL code being executed by Murano Engine. Murano's core library contains the io.murano.system.MistralClient class ([1]) which may be used to upload and run mistral workflows. Please let me know if you need more details on this [1] https://github.com/openstack/murano/blob/master/murano/engine/system/mistralclient.py On Tue, Nov 17, 2015 at 5:07 AM WANG, Ming Hao (Tony T) mailto:tony.a.w...@alcatel-lucent.com>> wrote: Dear Murano developers and testers, I want to put some files that Mistral workflow needs into Murano package, and hope Murano can transmit them to Mistral before it calls Mistral workflow. The flow should be as following: 1. User uploads one Murano package which includes both Murano artifacts and Mistral artifacts to Murano; 2. Murano transmits the Mistral artifacts to Mistral, and Mistral does its work. After study, I thought muranoagent may be helpful and plan to install a muranoagent on the Mistral server since it can put files into nova server, and can run scripts on the nova server. After further study, I found muranoagent solution may be not feasible: 1. muranoagent and murano-engine(dsl) uses rabbitMQ to communicate. 2. When an Agent object is create
Re: [openstack-dev] [cinder]Do we have project scope for cinder?
Sean and Michal, In fact, there is a reason that I ask this question. Recently I have a confusion about if cinder should provide the ability of Disaster Recovery to storage resources, like volume. I mean we have volume replication v1&v2, but for DR, specially DR between two independent OpenStack sites(production and DR site), I feel we still need more features to support it, for example consistency group for replication, etc. I'm not sure if those features belong in Cinder or some new project for DR. BR WangHao 2015-11-30 3:02 GMT+08:00 Sean McGinnis : > On Sun, Nov 29, 2015 at 11:44:19AM +, Dulko, Michal wrote: >> On Sat, 2015-11-28 at 10:56 +0800, hao wang wrote: >> > Hi guys, >> > >> > I notice nova have a clarification of project scope: >> > http://docs.openstack.org/developer/nova/project_scope.html >> > >> > I want to find cinder's, but failed, do you know where to find it? >> > >> > It's important to let developers know what feature should be >> > introduced into cinder and what shouldn't. >> > >> > BR >> > Wang Hao >> >> I believe Nova team needed to formalize the scop to have an explanation >> for all the "this doesn't belong in Nova" comments on feature requests. >> Does Cinder suffer from similar problems? From my perspective it's not >> critically needed. > > I agree. I haven't seen a need for something like that with Cinder. Wang > Hao, is there a reason you feel you need that? > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [congress]role in Congress
Hi Tim and All, I remember there is a topic named "role assignment for service users" in the Tokyo Summit. Since I have not heard any message of this topic. Does anyone could contribute some information for me? I think it is vital for my design of Congress UI in horizon. Thanks a lot! Best Regards, Yali __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] drop eventlet support in puppet-keystone
Hello, Keystone team plans [1] to drop evenlet support and already started the work [2]. To make sure we follow the upstream project, I would like to initiate the work in our Puppet module; so we can take time to discuss the way we manage this change in puppet-keystone now, and in other modules that will (eventually later) decide to follow this path. Please review https://review.openstack.org/#/c/250546/ and use Gerrit to give feedback. [1] https://blueprints.launchpad.net/keystone/+spec/removed-as-of-mitaka [2] https://review.openstack.org/#/c/249486/ -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] weekly meeting #61
Hello! Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC in #openstack-meeting-4: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151201 Thanks, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Supporting Django 1.9
https://blueprints.launchpad.net/horizon/+spec/drop-dj17 This is where changes are currently being tracked. I don’t quite understand why these would be back ported; they would break Liberty with 1.7. Perhaps we can discuss on IRC tomorrow? Rob On 27/11/2015 13:58, "Thomas Goirand" wrote: >On 11/27/2015 11:18 AM, Rob Cresswell (rcresswe) wrote: >> Mitaka will support 1.9. I’m already working on it :) >> Liberty is >= 1.7 and < 1.9, so shouldn’t matter. >> >> Rob > >It does mater for me, at least until the final release of Mitaka. Could >you please make sure that all of these Django 1.9 patches are easily >identifiable, so that I can later on backport them (even if it never >reaches the upstream stable/liberty branch)? That would help me a lot. >I'm not sure how to list them all after the facts though. Maybe opening >a wiki page? Any suggestion? > >Cheers, > >Thomas Goirand (zigo) > > >__ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder]Do we have project scope for cinder?
On Sun, Nov 29, 2015 at 11:44:19AM +, Dulko, Michal wrote: > On Sat, 2015-11-28 at 10:56 +0800, hao wang wrote: > > Hi guys, > > > > I notice nova have a clarification of project scope: > > http://docs.openstack.org/developer/nova/project_scope.html > > > > I want to find cinder's, but failed, do you know where to find it? > > > > It's important to let developers know what feature should be > > introduced into cinder and what shouldn't. > > > > BR > > Wang Hao > > I believe Nova team needed to formalize the scop to have an explanation > for all the "this doesn't belong in Nova" comments on feature requests. > Does Cinder suffer from similar problems? From my perspective it's not > critically needed. I agree. I haven't seen a need for something like that with Cinder. Wang Hao, is there a reason you feel you need that? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][Tempest] Use tempest-config for tempest-cli-improvements
Hi, I agree with Jordan. We don't have to use the tool as part of the gate. It's target audience is people and not CI systems. More specifically - new users. However, we could add a gate (or a few) for the tool that makes sure a proper conf file is generated. It doesn't have to run the tests, just compare the output of the script to the conf generated by devstack. Re Rally - I believe the best place for tempest configuration script is within tempest. That said, if the Tempest community doesn't want this tool, we'll have to settle for the Rally solution. Regards Yair On Fri, Nov 27, 2015 at 11:31 AM, Jordan Pittier wrote: > Hi, > I think this script is valuable to some users: Rally and Red Hat expressed > their needs, they seem clear. > > This tool is far from bullet proof and if used blindly or in case of bugs, > Tempest could be misconfigured. So, we could have this tool inside the > Tempest repository (in the tools/) but not use it at all for the Gate. > > I am not sure I fully understand the resistance for this, if we don"t use > this config generator for the gate, what's the risk ? > > Jordan > > On Fri, Nov 27, 2015 at 8:05 AM, Ken'ichi Ohmichi > wrote: > >> 2015-11-27 15:40 GMT+09:00 Daniel Mellado : >> > I still do think that even if there are some issues addressed to the >> > feature, such as skipping tests in the gate, the feature itself it's >> still >> > good -we just won't use it for the gates- >> > Instead it'd be used as a wrapper for a user who would be interested on >> > trying it against a real/reals clouds. >> > >> > Ken, do you really think a tempest user should know all tempest options? >> > As you pointed out there are quite a few of them and even if they >> should at >> > least know their environment, this script would set a minimum acceptable >> > default. Do you think PTL and Pre-PTL concerns that we spoke of would >> still >> > apply to that scenario? >> >> If Tempest users run part of tests of Tempest, they need to know the >> options which are used with these tests only. >> For example, current Tempest contains ironic API tests and the >> corresponding options. >> If users don't want to run these tests because the cloud don't support >> ironic API, they don't need to know/setup these options. >> I feel users need to know necessary options which are used on tests >> they want, because they need to investigate the reason if facing a >> problem during Tempest tests. >> >> Now Tempest options contain their default values, but you need a >> script for changing them from the default. >> Don't these default values work for your cloud at all? >> If so, these values should be changed to better. >> >> Thanks >> Ken Ohmichi >> >> --- >> >> > Andrey, Yaroslav. Would you like to revisit the blueprint to adapt it to >> > tempest-cli improvements? What do you think about this, Masayuki? >> > >> > Thanks for all your feedback! ;) >> > >> > El 27/11/15 a las 00:15, Andrey Kurilin escribió: >> > >> > Sorry for wrong numbers. The bug-fix for issue with counters is merged. >> > Correct numbers(latest result from rally's gate[1]): >> > - total number of executed tests: 1689 >> > - success: 1155 >> > - skipped: 534 (neutron,heat,sahara,ceilometer are disabled. [2] should >> > enable them) >> > - failed: 0 >> > >> > [1] - >> > >> http://logs.openstack.org/27/246627/11/gate/gate-rally-dsvm-verify-full/800bad0/rally-verify/7_verify_results_--html.html.gz >> > [2] - https://review.openstack.org/#/c/250540/ >> > >> > On Thu, Nov 26, 2015 at 3:23 PM, Yaroslav Lobankov < >> yloban...@mirantis.com> >> > wrote: >> >> >> >> Hello everyone, >> >> >> >> Yes, I am working on this now. We have some success already, but there >> is >> >> a lot of work to do. Of course, some things don't work ideally. For >> example, >> >> in [2] from the previous letter we have not 24 skipped tests, actually >> much >> >> more. So we have a bug somewhere :) >> >> >> >> Regards, >> >> Yaroslav Lobankov. >> >> >> >> On Thu, Nov 26, 2015 at 3:59 PM, Andrey Kurilin > > >> >> wrote: >> >>> >> >>> Hi! >> >>> Boris P. and I tried to push a spec[1] for automation tempest config >> >>> generator, but we did not succeed to merge it. Imo, qa-team doesn't >> want to >> >>> have such tool:( >> >>> >> >>> >However, there is a big concern: >> >>> >If the script contain a bug and creates the configuration which makes >> >>> >most tests skipped, we cannot do enough tests on the gate. >> >>> >Tempest contains 1432 tests and difficult to detect which tests are >> >>> >skipped as unexpected. >> >>> >> >>> Yaroslav Lobankov is working on improvement for tempest config >> generator >> >>> in Rally. Last time when we launch full tempest run[2], we got 1154 >> success >> >>> tests and only 24 skipped. Also, there is a patch, which adds x-fail >> >>> mechanism(it based on subunit-filter): you can transmit a file with >> test >> >>> names + reasons and rally will modify results. >> >>> >> >>> [1] - https://review.openstack.org/#/c/94473/ >> >>> >>
Re: [openstack-dev] [cinder]Do we have project scope for cinder?
On Sat, 2015-11-28 at 10:56 +0800, hao wang wrote: > Hi guys, > > I notice nova have a clarification of project scope: > http://docs.openstack.org/developer/nova/project_scope.html > > I want to find cinder's, but failed, do you know where to find it? > > It's important to let developers know what feature should be > introduced into cinder and what shouldn't. > > BR > Wang Hao I believe Nova team needed to formalize the scop to have an explanation for all the "this doesn't belong in Nova" comments on feature requests. Does Cinder suffer from similar problems? From my perspective it's not critically needed. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][L3][DVR][arp]
If those 200 subnets are VXLAN networks, i think it is a good idea, since L2population already propagate this configuration to OVS-Agent. One comment for VLAN network, since DVR also support in VLAN network and L2population is not necessary in it, what is your consideration in this case? At 2015-11-29 14:15:11, "Wuhongning" wrote: >Is it a good idea to add a configuration item for dvr, to disable any arp >entry processing, and reuse arp response from L2population? > >When no static arp entry is found in qrouter namespace, it would cause a temp >arp request, then it reached the br-tun, and replied by the OVS flow table. > >In a public cloud like AWS, it allow 200 subnets for each vpc, so sync routes >would waste a lot of time >__ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
