Hi-
I have installed Nova Folsom-3 using source code. But my installation did
not create any nova-compute.conf or nova.conf in the /etc/ path, rather
/usr/bin/nova* scripts are created.
I want to know, In the Folsom-3 milestone of Nova, were there any changes
to the nova.conf when compared to
Hi Vish,
I had already a setting:
glance_api_servers=10.0.0.1:9292
i've also tried to add
glance_host=10.0.0.1
but i got the same error.. Also, after changing configuration and restarting
nova-compute restarts all instances, is that normal?
Best
Alessandro
Il giorno 23/ago/2012, alle ore
Hi-
Thanks for the reply,
While installing from the source, will it not be copied from the source to
/etc/nova .directory. I see that, /etc/nova directory itself is not created.
On Fri, Aug 24, 2012 at 12:51 PM, Ritesh Nanda riteshnand...@gmail.comwrote:
Hello Trinath,
If you are
Hi gang,
I used the devstack to install a all-one-one develop environment, but the
keystone service seemed not working for me.
The host OS is Ubuntu 12.04 with a statically assigned IP address
192.168.79.201. Since this host is in the internal network, I have to use a
gateway(with 2 NICs of
Hi everyone,
As the Foundation Board of Directors election is closing, we have new
elections coming up for the OpenStack technical contributors: the PTL
and TC elections.
The process we'll follow lives at:
http://wiki.openstack.org/Governance/TCElectionsFall2012
TL;DR summary:
* The election
Hi all,
Do you have any experience configuring OpenStack to work with IGMP traffic?
If I have IGMP server and appropriate network infrastructure, what is
the best way to bound it with one of OpenStack's private networks?
___
Mailing list:
2012/8/24 Gabriel Hurley gabriel.hur...@nebula.com
I traced this through the code at one point looking for the same thing.
As it stands, right now there is **not** a mechanism for customizing the
default security group’s rules. It’s created programmatically the first
time the rules for a
Keystone doesn't return 301's (ever). However, your 301 response headers
show:
Server: BlueCoat-Security-Appliance
I'm guessing that wasn't installed by devstack :)
-Dolph
On Fri, Aug 24, 2012 at 3:03 AM, Lu, Lianhao lianhao...@intel.com wrote:
Hi gang,
I used the devstack to install a
Hi,
Could someone give a practical overview of how configuring and using the
instance type extra specs extension capability introduced in Folsom?
If how extending an instance type is relatively clear.
Eg.: #nova-manage instance_type set_key --name=my.instancetype --key
cpu_arch --value 's==
Hi Salvatore,
I see you're working on getting plugins testable with tox:
https://review.openstack.org/#/c/11922/
What about keeping the plugins isolated for testing purposes? I have been
unable to work on it yet, but I was thinking it might be a good idea to move
the plugins out of the main
Parick,
We are using the feature in Bare-metal machine provisioning.
Some keys are automatically generated by nova-compute.
For example, hypervisor_type, hypervisor_version, etc. fields are
automatically
put into capabilities by nova-compute (in the case of libvirt).
So, you don't need to
Patrick-
We've enhanced `nova-manage' to manipulate the `extra_specs' entries, c.f.
https://blueprints.launchpad.net/nova/+spec/update-flavor-key-value, You can
add an `extra_specs' key/value pair to a flavor with the command:
nova-manage instance_type add_key m1.humongous
Hi Maru,
whether plugins should be packaged or not with the main quantum service is
a recurrent question on this mailing list - and I am afraid I don't have
answer to it!
Pro and cons of separating the plugins from the main repository have been
discussed on the mailing list and on the IRC
Maru Newby mne...@internap.com writes:
Hi Salvatore,
I see you're working on getting plugins testable with tox:
https://review.openstack.org/#/c/11922/
What about keeping the plugins isolated for testing purposes? I have
been unable to work on it yet, but I was thinking it might be a
Patrick,
Once a new item (key and value pair) is added to the capabilities, it can be
compared against extra_specs. The extra_specs can be populated in
instance_type_extra_specs table. The items in the extra_specs can start with
one of the keywords for operations such as = and s==. For
Hi,
I also reported this bug:
https://bugs.launchpad.net/nova/+bug/1040255
If someone can combine you guys solution and get a perfect way to fix this
bug, that will be great.
BRs,
Sam
On Thu, Aug 23, 2012 at 9:27 PM, heut2008 heut2...@gmail.com wrote:
this bug has been filed here
Vish,
I've tested your code and did more testing.
There are a couple of problems.
1. host name should be unique. If not, any repetitive updates of new
capabilities with the same host name are simply overwritten.
2. We cannot generate arbitrary host names on the fly.
The scheduler (I tested
https://review.openstack.org/#/c/11524/
Patches posted. Review solicited. Thanks in advance...
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help :
Sorry for the delayed response.
Boris-Michel Deschenes wrote:
That would be great Jim,
I've built a cloud that uses CentOS+libvirt+Xen 4.1.3 to do GPU passthrough
and I just love to be able to use libvirt with Xen, this setup makes a lot of
sense to me since our main, bigger cloud is the
Boris-Michel Deschenes wrote:
John,
Sorry for my late response..
It would be great to collaborate, like I said, I prefer to keep the libvirt
layer as it works great with openstack and many other techs (collectd,
virt-manager, etc.), the virsh tool is also very useful for us.
You say:
Hi Juris,
Some more detail would be useful here. It sounds like you're trying
to use multicast, for which IGMP is a control protocol. Is it that
you're trying to run nova VMs and make sure they can participate in
multicast groups? Basic flat Nova networking connects VMs directly to
a physical
Hello Everyone,
We had another productive nova meeting yesterday. I've included the summary
below.
Vish
Meeting summary
---
* http://wiki.openstack.org/Meetings/Nova (vishy, 21:01:14)
* Role Call (vishy, 21:01:34)
* LINK: Agenda: http://wiki.openstack.org/Meetings/Nova
Thanks Vishy, these meeting notes are super helpful IMHO.
On Aug 24, 2012, at 5:25 PM, Vishvananda Ishaya vishvana...@gmail.com wrote:
Hello Everyone,
We had another productive nova meeting yesterday. I've included the summary
below.
Vish
Meeting summary
---
*
tl;dr both Quantum and nova-network will be core and fully supported
in Folsom.
Hi folks,
Thierry, Vish and I have been spending some talking about OpenStack
networking in Folsom, and in particular the availability of
nova-network now that Quantum is a core project. We wanted to share
our
I would investigate changing the capabilities to key off of something other
than hostname. It looks from the table structure like compute_nodes could be
have a many-to-one relationship with services. You would just have to use a
little more than hostname. Perhaps (hostname, hypervisor_hostname)
Actually it looks like a different error. For some reason container format is
being sent in as none on the second node.
Is it possible the original image that you launched the vm from has been
deleted? For some reason it can't determine the container format.
If not, can you also make sure that
Highlights of the week
OpenStack at CloudOpen
http://www.openstack.org/blog/2012/08/openstack-at-cloudopen/
OpenStack is a protagonist of CloudOpen, the only conference providing a
collaboration and education space dedicated to advancing the open cloud.
Next week, from Aug 29
Hi Joseph and All,
You are pointing the root cause of my question. The question is about how to
specify capabilities for a compute node so that they can be compared with the
extra specs. I think how to define extra specs in a flavor is clear enough.
So, some capabilities are standard and are
Patrick,
That's a good point. I think the issue is already being discussed at
https://bugs.launchpad.net/nova/+bug/1039386 as Don Dugger pointed out.
That being said, as answers to some of your questions: yes, any key/value pair
can be used and it is user's (in this case, system admin's)
There are two entry points
1) the filters
2) the flavors
From a UI perspective it feels safer to let the user select extra spec keys and
values from drop-down lists (of pre-defined/registered keys and respective
values) to avoid typographic errors
This would then introduce a dependency, with
I have fixed it here https://review.openstack.org/#/c/11925/
2012/8/25 Sam Su susltd...@gmail.com:
Hi,
I also reported this bug:
https://bugs.launchpad.net/nova/+bug/1040255
If someone can combine you guys solution and get a perfect way to fix this
bug, that will be great.
BRs,
Sam
That'll work! Looks good to me. I can't review it on Gerrit but good
job. Beat me to it :)
On 08/24/2012 09:15 PM, heut2008 wrote:
I have fixed it here https://review.openstack.org/#/c/11925/
2012/8/25 Sam Su susltd...@gmail.com:
Hi,
I also reported this bug:
Folsom also supports setting key values for things like capabilities via host
aggregates. There is a filter[1] that matches the extra specs by exact
comparison just like was done for capabilities before the last patch. The new
extra specs matching should be added to it. These capabilities can
That's great, thank you for your efforts. Can you make a backport for essex?
Sent from my iPhone
On Aug 24, 2012, at 7:15 PM, heut2008 heut2...@gmail.com wrote:
I have fixed it here https://review.openstack.org/#/c/11925/
2012/8/25 Sam Su susltd...@gmail.com:
Hi,
I also reported this
On 08/21/2012 05:45 PM, Dan Smith wrote:
In other suites, I've seen an XFAIL result used to mark tests that we
know are failing right now so that they're not SKIPped like tests that
are missing some component, but rather just not fatal to the task at
hand. Maybe something like that would be
JB We're almost done with a project to move the build artifacts to a
JB static web server, where we plan to keep them indefinitely. The
JB artifacts in jenkins do have an expiration (currently about a
JB month), and we actually want to drastically shorten that because
JB long build histories
36 matches
Mail list logo