Re: [openstack-dev] [Openstack] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes??
(not sure if my answer has been sent, sorry if duplicate) I don't touch ppc for a while but AFAIK this should work as long as you run full emulation (qemu, not kvm) as libvirt_type in nova.conf and get the qemu-system-ppc64le installed in the compute node. Assume also you get the ppc64le image to launch your instance. Expect poor performance though. On Mon, Nov 19, 2018 at 4:12 PM Sean Mooney wrote: > adding openstack dev. > On Mon, 2018-11-19 at 18:08 +, Sean Mooney wrote: > > On Mon, 2018-11-19 at 11:57 -0500, Ken D'Ambrosio wrote: > > > On 2018-11-19 11:25, Yedhu Sastri wrote: > > > > Hello All, > > > > > > > > I have some use-cases which I want to test in PowerPC > architecture(ppc64). As I dont have any Power machines I > > > > would > > > > like to try it with ppc64 VM's. Is it possible to run these kind of > VM's on my OpenStack cluster(Queens) which > > > > runs > > > > on X86_64 architecture nodes(OS RHEL 7)?? > > > > > > > > > > I'm not 100% sure, but I'm 95% sure that the answer to your question > is "No." While there's much emulation that > > > occurs, the CPU isn't so much emulated, but more abstracted. > Constructing and running a modern CPU in software > > > would > > > be non-trivial. > > > > you can do this but not with kvm. > > you need to revert the virt dirver in the nova.conf back to qemu to > disable kvm to allow emulation of other > > plathforms. > > that said i have only emulated power on x86_64 using libvirt or qemu > idrectly never with openstack but i belive we > > used > > to support this i just hav enot done it personally. > > > > > > -Ken > > > > > > > I set the image property architecture=ppc64 to the ppc64 image I > uploaded to glance but no success in launching VM > > > > with those images. I am using KVM as hypervisor(qemu 2.10.0) in my > compute nodes and I think it is not built to > > > > support power architecture. For testing without OpenStack I manually > built qemu on a x86_64 host with ppc64 > > > > support(qemu-ppc64) and then I am able to host the ppc64 VM. But I > dont know how to do this on my OpenStack > > > > cluster. > > > > Whether I need to manually build qemu on compute nodes with ppc64 > support or I need to add some lines in my > > > > nova.conf to do this?? Any help to solve this issue would be much > appreciated. > > > > > > > > > > > > -- > > > > Thank you for your time and have a nice day, > > > > > > > > With kind regards, > > > > Yedhu Sastri > > > > > > > > ___ > > > > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > Post to : openst...@lists.openstack.org > > > > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > > _______ > > > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > Post to : openst...@lists.openstack.org > > > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > __ > 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 > -- Rafael Folco Senior Software Engineer __ 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] [tripleo] Proposal: Remove newton/ocata CI jobs
Greetings, The non-containerized multinode scenario jobs were active up to Ocata release and are no longer supported. I'm proposing a cleanup [1] on these old jobs so I've added this topic to the next tripleo meeting agenda [2] to discuss with the tripleo team. Since this may affect multiple projects, these jobs need to be deleted from their respective zuul config before the cleanup on tripleo-ci. Thanks, --Folco [1] https://review.openstack.org/#/c/617999/ [2] https://etherpad.openstack.org/p/tripleo-meeting-items __ 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] [tripleo] TripleO CI Summary: Sprint 21
Greetings, The TripleO CI team has just completed Sprint 21 (Oct-18 thru Nov-07). The following is a summary of completed work during this sprint cycle: - Created an initial base Standalone job for Fedora 28. - Added initial support for installing Tempest rpm in openstack-ansible_os-tempest. - Started running project specific tempest tests against puppet-projects in tripleo-standalone gates. - Added initial support to python-tempestconf on openstack-ansible_os-tempest. - Prepared grounds to make all required variables for the zuulv3 workflow available for the reproducer. The sprint task board for CI team has moved from Trello to Taiga [1]. The Ruck and Rover notes for this sprint has been tracked in the etherpad [2]. The planned work for the next sprint focuses in iterating on the upstream standalone job for Fedora 28 to bring it to completion. This includes moving the multinode scenarios to the standalone jobs. The team continues to work on the reproducer, enabling Tempest coverage in puppet-* projects, and preparing a CI environment for OVB. The Ruck and Rover for this sprint are Gabriele Cerami (panda) and Chandan Kumar (chkumar). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Thanks, Folco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/sprint-21-175 [2] https://review.rdoproject.org/etherpad/p/ruckrover-sprint21 __ 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] [tripleo] TripleO CI Summary: Sprint 20
Oops. Missing footer info. [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/sprint-20-193 [2] https://review.rdoproject.org/etherpad/p/ruckrover-sprint20.1 On Thu, Oct 18, 2018 at 2:05 PM Rafael Folco wrote: > Greetings, > > The TripleO CI team has just completed Sprint 20 (Sep-27 thru Oct-17). > The following is a summary of completed work during this sprint cycle: > >- > >Bootstrapped upstream standalone job on Fedora 28. >- > >Migrated RDO jobs in Software Factory to native Zuul v3. >- > >Refactored Tempest tooling (python-tempestconf). >- > >Made possible the use of zuul inventory variables from the job to the >quickstart workflow >- > >Build-test-packages role is now using zuul variables to gather >information on the changes alongside the old ZUUL_CHANGES method, which is >now deprecated and will be removed in the future. >- > >Translated bash variables into ansible as part of the ZuulV3 migration >work. >- Enabled stackviz on openstack/openstack-ansible-os_tempest role. >- > >Enabled projects to override tempest tests via zuul variables in the >job definition. > > > The sprint task board for CI team has moved from Trello to Taiga [1]. The > Ruck and Rover notes for this sprint has been tracked in the etherpad [2]. > > The planned work for the next sprint focuses in running the upstream > standalone job in Fedora 28 and continuing part of the work done in Sprint > 20, including python-tempestconf refactoring, and enabling stackviz. > > The Ruck and Rover for this sprint are Sagi Shnaidman (sshnaidm) and > Rafael Folco (rfolco). Please direct questions or queries to them regarding > CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix > on their nick. > > Thanks, > Folco > > -- > Rafael Folco > Senior Software Engineer > -- Rafael Folco Senior Software Engineer __ 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] [tripleo] TripleO CI Summary: Sprint 20
Greetings, The TripleO CI team has just completed Sprint 20 (Sep-27 thru Oct-17). The following is a summary of completed work during this sprint cycle: - Bootstrapped upstream standalone job on Fedora 28. - Migrated RDO jobs in Software Factory to native Zuul v3. - Refactored Tempest tooling (python-tempestconf). - Made possible the use of zuul inventory variables from the job to the quickstart workflow - Build-test-packages role is now using zuul variables to gather information on the changes alongside the old ZUUL_CHANGES method, which is now deprecated and will be removed in the future. - Translated bash variables into ansible as part of the ZuulV3 migration work. - Enabled stackviz on openstack/openstack-ansible-os_tempest role. - Enabled projects to override tempest tests via zuul variables in the job definition. The sprint task board for CI team has moved from Trello to Taiga [1]. The Ruck and Rover notes for this sprint has been tracked in the etherpad [2]. The planned work for the next sprint focuses in running the upstream standalone job in Fedora 28 and continuing part of the work done in Sprint 20, including python-tempestconf refactoring, and enabling stackviz. The Ruck and Rover for this sprint are Sagi Shnaidman (sshnaidm) and Rafael Folco (rfolco). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Thanks, Folco -- Rafael Folco Senior Software Engineer __ 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] [tripleo][ci] use of tags in launchpad bugs
Thanks for the clarifications about official tags. I was the one creating random/non-official tags for tripleo bugs. Although this may be annoying for some people, it helped me while ruckering/rovering CI to open unique bugs and avoid dups for the first time(s). There isn't a standard way of filing a bug. People open bugs using different/non-standard wording in summary and description. I just thought it was a good idea to tag featuresetXXX, ovb, branch, etc., so when somebody asks me if there is a bug for the job XYZ, the bug could be found more easily. Since sprint 10 ruck/rover started recording notes [1] and this helps to keep track of the issues. Perhaps the CI team could implement something on CI monitoring that links a bug to the failing job(s), e.g: [LP XX]. I'm doing a cleanup for the open bugs removing the non-official tags. Thanks, --Folco [1] https://review.rdoproject.org/etherpad/p/ruckrover-sprint11 On Fri, Apr 6, 2018 at 6:09 AM, Jiří Stránský <ji...@redhat.com> wrote: > On 5.4.2018 21:04, Alex Schultz wrote: > >> On Thu, Apr 5, 2018 at 12:55 PM, Wesley Hayutin <whayu...@redhat.com> >> wrote: >> >>> FYI... >>> >>> This is news to me so thanks to Emilien for pointing it out [1]. >>> There are official tags for tripleo launchpad bugs. Personally, I like >>> what >>> I've seen recently with some extra tags as they could be helpful in >>> finding >>> the history of particular issues. >>> So hypothetically would it be "wrong" to create an official tag for each >>> featureset config number upstream. I ask because that is adding a lot of >>> tags but also serves as a good test case for what is good/bad use of >>> tags. >>> >>> >> We list official tags over in the specs repo[0]. That being said as >> we investigate switching over to storyboard, we'll probably want to >> revisit tags as they will have to be used more to replace some of the >> functionality we had with launchpad (e.g. milestones). You could >> always add the tags without being an official tag. I'm not sure I >> would really want all the featuresets as tags. I'd rather see us >> actually figure out what component is actually failing than relying on >> a featureset (and the Rosetta stone for decoding featuresets to >> functionality[1]). >> > > We could also use both alongside. Component-based tags better relate to > the actual root cause of the bug, while featureset-based tags are useful in > relation to CI. > > E.g. "I see fs037 failing, i wonder if anyone already reported a bug for > it" -- if the reporter tagged the bug, it would be really easy to figure > out the answer. > > This might also again bring up the question of better job names to allow > easier mapping to featuresets. IMO: > > tripleo-ci-centos-7-containers-multinode -- not great > tripleo-ci-centos-7-featureset010 -- not great > tripleo-ci-centos-7-containers-mn-fs010 -- *happy face* > > Jirka > > > >> >> Thanks, >> -Alex >> >> >> [0] http://git.openstack.org/cgit/openstack/tripleo-specs/tree/s >> pecs/policy/bug-tagging.rst#n30 >> [1] https://git.openstack.org/cgit/openstack/tripleo-quickstart/ >> tree/doc/source/feature-configuration.rst#n21 >> >>> Thanks >>> >>> [1] https://bugs.launchpad.net/tripleo/+manage-official-tags >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.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:unsubscrib >> e >> 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 > -- Rafael Folco Senior Software Engineer __ 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][placement] Interested in getting involved in placement API coding?
owned ! Rafael Folco OpenStack Continuous Integration IBM Linux Technology Center > On Dec 29, 2016, at 11:55 AM, Jay Pipes <jaypi...@gmail.com> wrote: > > Hi folks, happy holidays from the placement team :) > > I created a bug/feature request today for some new API functionality in the > placement REST API: > > https://bugs.launchpad.net/nova/+bug/1653122 > > It's low-hanging fruit and should be a relatively straightforward way for a > newcomer to the placement service inside Nova to get involved in development > and learn about the placement API. > > First come, first served :) > > I'm around on IRC if anyone has questions or wants to chat about the work. > > Best, > -jay > > __ > 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] [QA][Nova] Tempest Hypervisor Feature Tagging
Thanks John. Maybe we can just start simple: tag each feature in support-matrix.ini and add the metadata to each of the tests that uses that feature. Then we can query that info as we want. I added my comments to that change. Thanks. -rfolco Rafael Folco OpenStack Continuous Integration IBM Linux Technology Center > On Nov 6, 2015, at 10:38 AM, John Garbutt <j...@johngarbutt.com> wrote: > > On 5 November 2015 at 19:31, Rafael Folco <rfo...@linux.vnet.ibm.com> wrote: >> Is there any way to know what hypervisor features[1] were tested in a >> Tempest run? >> From what I’ve seen, currently there is no way to tell what tests cover what >> features. >> Looks like Tempest has UUID and service tagging, but no reference to the >> hypervisor features. >> >> It would be good to track/map covered features and generate a report for CI. >> In case of any interest in that, I’d like to validate if the metadata >> tagging (similar to UUID) is a reasonable approach. >> >> [1] http://docs.openstack.org/developer/nova/support-matrix.html > > I have proposed a change to take the support-matrix and include test > coverage and doc coverage: > https://review.openstack.org/#/c/215664/4/doc/source/feature_classification.rst,cm > > The plan was certainly to (in a similar way to DefCore) map tempest > uuids to groups of features. > > I would love help to push that effort forward, as I just don't have > the bandwidth to do it myself right now. > > Thanks, > John > > __ > 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] [QA][Nova] Tempest Hypervisor Feature Tagging
Is there any way to know what hypervisor features[1] were tested in a Tempest run? From what I’ve seen, currently there is no way to tell what tests cover what features. Looks like Tempest has UUID and service tagging, but no reference to the hypervisor features. It would be good to track/map covered features and generate a report for CI. In case of any interest in that, I’d like to validate if the metadata tagging (similar to UUID) is a reasonable approach. [1] http://docs.openstack.org/developer/nova/support-matrix.html <http://docs.openstack.org/developer/nova/support-matrix.html> Thanks. -rfolco Rafael Folco OpenStack Continuous Integration IBM Linux Technology Center __ 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] libvirtError: XML error: Missing CPU model name on 2nd level vm
cat /proc/cpuinfo
Make sure the cpu model and version is listed on
/usr/share/libvirt/cpu_map.xml
Hope this helps.
On Tue, Aug 5, 2014 at 2:49 PM, Solly Ross sr...@redhat.com wrote:
Hi Kevin,
Running devstack in a VM is perfectly doable. Many developers use
devstack inside a VM (I run mine inside a VM launched using libvirt
on KVM). I can't comment on the issue that you're encountering,
but perhaps something wasn't configured correctly when you launched the
VM?
Best Regards,
Solly Ross
- Original Message -
From: Chen CH Ji jiche...@cn.ibm.com
To: openstack-dev@lists.openstack.org
Sent: Friday, August 1, 2014 5:04:16 AM
Subject: [openstack-dev] [nova] libvirtError: XML error: Missing CPU
model name on 2nd level vm
Hi
I don't have a real PC to so created a test env ,so I created a 2nd
level env
(create a kvm virtual machine on top of a physical host then run
devstack o
the vm)
I am not sure whether it's doable because I saw following error when
start
nova-compute service , is it a bug or I need to update my configuration
instead? thanks
2014-08-01 17:04:51.532 DEBUG nova.virt.libvirt.config [-] Generated XML
('cpu\n archx86_64/arch\n topology sockets=1 cores=1
threads=1/\n/cpu\n',) from (pid=16956) to_xml
/opt/stack/nova/nova/virt/libvirt/config.py:79
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 346,
in
fire_timers
timer()
File /usr/lib/python2.7/dist-packages/eventlet/hubs/timer.py, line 56,
in
__call__
cb(*args, **kw)
File /usr/lib/python2.7/dist-packages/eventlet/event.py, line 163, in
_do_send
waiter.switch(result)
File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line
194, in
main
result = function(*args, **kwargs)
File /opt/stack/nova/nova/openstack/common/service.py, line 490, in
run_service
service.start()
File /opt/stack/nova/nova/service.py, line 164, in start
self.manager.init_host()
File /opt/stack/nova/nova/compute/manager.py, line 1055, in init_host
self.driver.init_host(host=self.host)
File /opt/stack/nova/nova/virt/libvirt/driver.py, line 633, in
init_host
self._do_quality_warnings()
File /opt/stack/nova/nova/virt/libvirt/driver.py, line 616, in
_do_quality_warnings
caps = self._get_host_capabilities()
File /opt/stack/nova/nova/virt/libvirt/driver.py, line 2942, in
_get_host_capabilities
libvirt.VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES)
File /usr/lib/python2.7/dist-packages/eventlet/tpool.py, line 179, in
doit
result = proxy_call(self._autowrap, f, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/eventlet/tpool.py, line 139, in
proxy_call
rv = execute(f,*args,**kwargs)
File /usr/lib/python2.7/dist-packages/eventlet/tpool.py, line 77, in
tworker
rv = meth(*args,**kwargs)
File /usr/lib/python2.7/dist-packages/libvirt.py, line 3127, in
baselineCPU
if ret is None: raise libvirtError ('virConnectBaselineCPU() failed',
conn=self)
libvirtError: XML error: Missing CPU model name
Best Regards!
Kevin (Chen) Ji 纪 晨
Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
___
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
