Re: [Openstack] [Metering] Agent configuration mechanism
On Tue, Jun 05 2012, Nick Barcet wrote: The main idea is that all agents of a given type should be sending similarly formatted information in order for the information to be usable, hence the need to ensure that configuration info is centrally stored and retrieved. This would rule out, in my mind, the idea that we could use the global flags object, as distribution of the configuration file is left to the cloud implementor and does not lend for easy and synchronized updates of agent config. IMHO this is solving a problem that already exists for all other OpenStack components. A problem that no other OpenStack components tried to resolved, AFAIK. So I don't see why we should try to resolve configuration deployment in ceilometer when it's a much larger issue in the project. -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Metering] Agent configuration mechanism
On Tue, Jun 05 2012, Nick Barcet wrote: The main idea is that all agents of a given type should be sending similarly formatted information in order for the information to be usable, hence the need to ensure that configuration info is centrally stored and retrieved. This would rule out, in my mind, the idea that we could use the global flags object, as distribution of the configuration file is left to the cloud implementor and does not lend for easy and synchronized updates of agent config. IMHO this is solving a problem that already exists for all other OpenStack components. A problem that no other OpenStack components tried to resolved, AFAIK. So I don't see why we should try to resolve configuration deployment in ceilometer when it's a much larger issue in the project. -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Metering] Agent configuration mechanism
On Tue, Jun 05 2012, Nick Barcet wrote: I would have thought that we may want to support different intervals per meters, based on the billing rules that one may want to offer. For example, I may want to bill compute by the hour but floating IPs by the day, hence have a different reporting interval for each. I don't think you want to poll once a day something you bill per day. If you poll only at noon, and I use a resource from 8:00 to 10:00, you'll miss my usage and I'll use resource for free. :) Yes, there's a minimum interval to be configured, but it's the interval that defined how much grained your metering/billing will be. E.g. if it's 1 hour, you won't charge anything used for less than one hour. You probably wants something like 5 minutes or less, and be sure the agent can keep up with the needed polling speed. :) -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] nova live-migration failing on Ubuntu precise; libvirt live migration is OK
Hi everyone,
a few people have reported issues with live migration lately, and
I've been digging into them to narrow them down.
The symptom is relatively easy to describe: you run nova live-migration
guest host, and nothing happens.
A few words of background:
- System is Ubuntu precise with stock packages and regular updates, no
external PPAs. nova-compute is at version 2012.1-0ubuntu2.1.
- libvirtd is running with the -l option and with a working
TCP socket as described here:
http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-live-migrations.html
- /var/lib/nova/instances is on GlusterFS.
Now, if you're setting various --*vnc* flags in nova.conf, live
migration fails even at the libvirt level (a similar issue has been
reported here recently, see
https://lists.launchpad.net/openstack/msg12425.html).
# virsh migrate --live --p2p --domain instance-000a \
--desturi qemu+tcp://skunk-x/system
error: Unable to read from monitor: Connection reset by peer
(skunk-x is secondary IP address of the host skunk, living in a
dedicated network used for migrations).
This is in the libvirt.log on the source host:
2012-06-05 20:39:25.838+: 12241: error :
virNetClientProgramDispatchError:174 : Unable to read from monitor:
Connection reset by peer
At the same time, I am seeing this in the libvirtd log on the target host:
2012-06-05 20:39:25.394+: 6828: error : qemuMonitorIORead:513 :
Unable to read from monitor: Connection reset by peer
Removing all --*vnc* flags from nova.conf resolved that issue for me.
Then, doing the same command as above resulted in a connection timeout,
because even if I set qemu+tcp://skunk-x/system as the libvirt
destination URI, libvirt opens a separate socket on an ephemeral port on
skunk's primary interface, which in that case was being blocked by my
iptables config:
# virsh migrate --live --p2p \
--domain instance-000d --desturi qemu+tcp://skunk-x/system
error: unable to connect to server at 'skunk:49159': Connection timed out
Switching the migration to tunnelled mode solved that issue.
# virsh domstate instance-000d
running
# virsh migrate --live --p2p \
--domain instance-000d --desturi qemu+tcp://skunk-x/system \
--tunnelled
# virsh --connect qemu+tcp://skunk-x/system domstate instance-000d
running
So therefore, these are the flags that I'm using in my nova.conf:
--live_migration_uri=qemu+tcp://%s-x/system
--live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,
VIR_MIGRATE_PEER2PEER, VIR_MIGRATE_TUNNELLED
(Note that VIR_MIGRATE_UNDEFINE_SOURCE, VIR_MIGRATE_PEER2PEER is the
default for --live_migration_flag; VIR_MIGRATE_TUNNELLED is my addition.
I've also tried migrating over the primary interface, without
tunnelling. No change: works in libvirt, doesn't work with Nova.)
nova live-migration guest host returns an exit code of 0, and the
only trace that I find of the migration in the logs is this, which is
evidently from the pre_live_migration method.
2012-06-06 11:05:13 DEBUG nova.rpc.amqp [-] received {u'_context_roles':
[u'KeystoneServiceAdmin', u'admin', u'KeystoneAdmin'], u'_msg_id':
u'069c958b7c03482aa4f0dda00010eb10', u'_context_read_deleted': u'no',
u'_context_request_id': u'req-71c4ffea-4d3d-471c-98bc-8a27aaff8f2c',
u'args': {u'instance_id': 13, u'block_migration': False, u'disk': None},
u'_context_auth_token': 'SANITIZED', u'_context_is_admin': True,
u'_context_project_id': u'9c929e61e7624fbe895ae0de38bd1471',
u'_context_timestamp': u'2012-06-06T09:05:09.992775',
u'_context_user_id': u'1c8c118c7c244d2d94cc516ab6f24c03', u'method':
u'pre_live_migration', u'_context_remote_address': u'10.43.0.2'} from
(pid=14437) _safe_log
/usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
Looks like it never gets to live_migration.
I'd be thankful for any clues as to where to dig further.
Cheers,
Florian
--
Need help with High Availability?
http://www.hastexo.com/now
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
[Openstack] Clarification on Ceilometer Implementation
Hi all, I am trying to implement Agent module in Ceilometer. Regarding that I have few doubts: How Ceilometer capturing the usage details? As we are already know nova simple usage module captures the usage details of nova. It works at API level. But here in ceilometer we are trying to implement Agent module at compute level. For that how can we capture the usage details? What is the format of Plug- In? We can implement plug-in in various ways. We can use dictionary format, JSON format, etc. In which format Ceilometer implementing the plug - in and what are the attributes in that. Thanks Regards, Bharath Kumar DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Metering] Agent configuration mechanism
On 06/05/2012 09:03 PM, Doug Hellmann wrote:
On Tue, Jun 5, 2012 at 12:59 PM, Nick Barcet nick.bar...@canonical.com
mailto:nick.bar...@canonical.com wrote:
On 06/05/2012 04:44 PM, Doug Hellmann wrote:
On Tue, Jun 5, 2012 at 10:41 AM, Doug Hellmann
doug.hellm...@dreamhost.com mailto:doug.hellm...@dreamhost.com
mailto:doug.hellm...@dreamhost.com
mailto:doug.hellm...@dreamhost.com wrote:
On Tue, Jun 5, 2012 at 9:56 AM, Nick Barcet
nick.bar...@canonical.com mailto:nick.bar...@canonical.com
mailto:nick.bar...@canonical.com
mailto:nick.bar...@canonical.com wrote:
Following up on our last meeting, here is a proposal for
centrally
hosting configuration of agents in ceilometer.
The main idea is that all agents of a given type should be
sending
similarly formatted information in order for the
information to be
usable, hence the need to ensure that configuration info is
centrally
stored and retrieved. This would rule out, in my mind,
the idea
that we
could use the global flags object, as distribution of the
configuration
file is left to the cloud implementor and does not lend
for easy and
synchronized updates of agent config.
Configuration format and content is left to the agent's
implementation,
but it is assumed that each meter covered by an agent can be :
* enabled or disabled
* set to send information at a specified interval.
Right now we only have one interval for all polling. Do you
think we
need to add support for polling different values at different
intervals? Do we need other per-agent settings, or are all of the
settings the same for all agents? (I had assumed the latter
would be
all we needed.)
I would have thought that we may want to support different intervals per
meters, based on the billing rules that one may want to offer. For
example, I may want to bill compute by the hour but floating IPs by the
day, hence have a different reporting interval for each.
I was planning to aggregate the values for items being billed over the
longer time frames, but we can make the polling interval configurable.
It will take some work, because of the way the scheduled tasks are
configured in the service and manager (right now we just schedule one
method to run, and it invokes each pollster).
How important is it to include this in Folsom?
Not crucial. I would classify this as Nice to have.
1/ Configuration is stored for each agent in the database
as follow
+---+
| Field | Type | Note
|
+---+
| AgentType | String | Unique agent type
|
| ConfVers | Integer | Version of the configuration
|
| Config| Text | JSON Configuration info (defined by
agent) |
+---+--++
2/ Config is retreived via the messaging queue upon boot
once a day
(this should be defined in the global flags object) to
check if the
config has changed.
Updating the config once a day is not going to be enough in an
environment with a lot of compute nodes.
Two thoughts merged into one sentence there. Need more caffeine.
What I was trying to say, was that updating the config once a day
might
not be enough and in environments with a lot of compute nodes going
around to manually restart the services each time the config changes
will be a pain. See below for more discussion of pushing config
settings
out.
Agreed, and that's why I proposed that the interval for confguration
refresh should be set in the Global object flag (this is something that
can be shared among all the agents).
Request sent by the agent upon boot and :
'reply_to': 'get_config_data',
'correlation_id': x
'version': '1.0',
'args': {'data': {
'AgentType': agent.type,
'CurrentVersion': agent.version,
'ConfigDefault': agent.default,
},
},
Is this a standard OpenStack RPC call?
Not sure about that, but if it can be, it
Re: [Openstack] [Metering] Agent configuration mechanism
On 06/06/2012 10:39 AM, Julien Danjou wrote: On Tue, Jun 05 2012, Nick Barcet wrote: I would have thought that we may want to support different intervals per meters, based on the billing rules that one may want to offer. For example, I may want to bill compute by the hour but floating IPs by the day, hence have a different reporting interval for each. I don't think you want to poll once a day something you bill per day. If you poll only at noon, and I use a resource from 8:00 to 10:00, you'll miss my usage and I'll use resource for free. :) I don't think I specified which interval we would use for each, but thanks for remind us of the limits of sampling. Yes, there's a minimum interval to be configured, but it's the interval that defined how much grained your metering/billing will be. E.g. if it's 1 hour, you won't charge anything used for less than one hour. You probably wants something like 5 minutes or less, and be sure the agent can keep up with the needed polling speed. :) The only point I am trying to make is that the sampling interval is a function of the billing interval. To insure efficient use of the resources, it would be better (not crucial) to ensure that the polling frequency be settable by meter, not just by agent. The later would just force to set the frequency to the lowest value needed for all meters covered by that agent. Again, this is acceptable, but not optimal. Nick signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Glance : How to inform user that snapshot has run into error ?
Hi, Related to instance being stuck in image_snapshot for extended period of time, it is easy to recover the instance (script uses pre-defined timeout to guess that snapshot has hung and will never complete) and bring it back to usable state, I also the *inform the user that their snapshot attempt has failed*. The image goes thru the following statuses during normal case : Queued - Saving - Active - Deleted If the upload of the image fails checksum verification, status is marked as killed (Using _safe_kill() - a private method) Neither of killed and deleted instances are shown to the user either in Dashboard (Horizon) or nova image-list So when recovering hung snapshot - what status should be set for the image ? (Such that user knows of the error) I'm thinking that we need to either Introduce a new status like error OR 1. Modify glance/registry/db/api.py : image_get_all() to return images with killed status (currently it is explicitly filtered out) AND 2. Expose an API to set the image status to killed (Currently _safe_kill is a private method) When I tried #1 above locally and set status of one of the images to killed directly in DB, manually then : 1. nova image-list showed this image status as ERROR 2. Dashboard/Horizon show the status as Killed Please suggest if you can think of better way to handle this. -Mandar __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] OpenStack Bug Triage day is tomorrow !
Hi everyone, Remember to set some time aside tomorrow to participate to our big BugTriage day ! We especially need Nova folks (230 New bugs to triage...), but there is work to do in all projects. The triaging tasks to complete are described in http://wiki.openstack.org/BugTriage :) More information on the event at: http://wiki.openstack.org/BugDays/20120607BugTriage http://fnords.wordpress.com/2012/06/06/openstack-bugtriage-day/ See you tomorrow ! -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Metering] Agent configuration mechanism
On 06/06/2012 10:35 AM, Julien Danjou wrote: On Tue, Jun 05 2012, Nick Barcet wrote: The main idea is that all agents of a given type should be sending similarly formatted information in order for the information to be usable, hence the need to ensure that configuration info is centrally stored and retrieved. This would rule out, in my mind, the idea that we could use the global flags object, as distribution of the configuration file is left to the cloud implementor and does not lend for easy and synchronized updates of agent config. IMHO this is solving a problem that already exists for all other OpenStack components. A problem that no other OpenStack components tried to resolved, AFAIK. So I don't see why we should try to resolve configuration deployment in ceilometer when it's a much larger issue in the project. Maybe the problem of discrepancy of configuration is more an issue for metering than for other components? At least that's my belief. In fact, I may very well want to have differences in configuration of different compute nodes in a single zone, for very valid reasons (ie use different hypervisor settings, balance usage of components, etc...). However if my metering agents are not all set to report the same things, I think I'll be in trouble to correlate anything, hence the need for metering configuration information to be provided centrally, for anything that sets the behavior of meters and which meters to use. Nick signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Capability of Openstack ?
Hi, Of course a basic question, Could anyone please let me know below concerns... 1. What are the advantages we will get if we prefer to use Openstack as a cloud solution? 2. What are the strong points of Openstack ? 3. While proposing Openstack as solution to the customer, How can I convenience them to go for Openstack? 4. What are the strong points and weak points of Openstack? 5. How Openstack will be the best cloud solution if compare to others (i.e., Eucalyptus, couldstack and etc.,) I know that Openstack is Fully opensource, can support to multiple hypervisors and has big support from the companies. -- Thanks Regards, Rajesh Avula 07259024701. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Metering] Agent configuration mechanism
On Wed, Jun 06 2012, Nick Barcet wrote: Maybe the problem of discrepancy of configuration is more an issue for metering than for other components? At least that's my belief. […] Sure, I don't say that it's useless to have a centralized configuration management in our case. I just think that it shouldn't be our problem to fix that right now, and that we shouldn't spend our energy trying to fix this. Deployers use configuration management tools to handle this in various OpenStack components so far. I think it's saner, for now, to let this continue until OpenStack provides something better all components can rely on. I'm just having the feeling we're going out of scope here. But this is just my opinion. :) -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] OpenStack :: Instance Spawning Error
Hi- I have Installed Openstack Essex on my Ubuntu 12.04 machine following the instructions from Openstack Compute Starter Guide May 4,2012http://docs.openstack.org/essex/openstack-compute/starter/content/Introduction_to_OpenStack_and_its_components-d1e59.html . I have downloaded Ubuntu 12.04 image from the Ubuntu Repository. And Followed the instructions of Image management from the Guidehttp://docs.openstack.org/trunk/openstack-compute/admin/content/booting-a-test-image.html . When I boot the image using the command, $ nova boot --image cirros-0.3.0-x86_64 --flavor m1.small --key_name test my-first-server The Image is moving from the states Scheduling, Networking and to Spawning. In the Spawning phase, a Error is returned. For the image I used m1.small flavor. I have two doubts/queries here. [1] How to bring up the instance. [2] I have the Client-1, Server-1 and Server-2 setup as given in the STARTER guide. How the VM are created in Server-2 from Server-1? It might be a very basic query, But I was struck very hardly there. Kindly please guide me understand the issue. Thanking you. -- Regards, -- Trinath Somanchi, +91 9866 235 130 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Essex: LXC volume attachment does not work?
Hi,
Can you please open up a bug in Launchpad please?
thanks
chuck
On Tue, 5 Jun 2012 15:38:11 -0700 (PDT)
David Kang dk...@isi.edu wrote:
Hello,
We are using Essex version.
We are testing volume attachment to an LXC instance.
From the code, the volume is mounted by the host machine to the file
system of the LXC instance.
# nova/virt/disk/api.py
utils.execute('mount', '-o', 'bind', src, target,
run_as_root=True)
From the host machine, it is visible.
But, inside of the LXC instance, it is not visible.
Does this method work?
Before Essex, we used lxc-attach command to run mknod command
inside of the LXC instance instead of mount it by the host outside
of the LXC instance. It did work.
Here are the content of the dev directory shown inside of the LXC
instance, and at the host side. Both are different. And dynamic
changes done by the host outside of the LXC instance is not shown
inside of the LXC instance. Is our LXC configuration or our LXC image
is wrong?
1. Inside the LXC instance
$ ls /dev
console full null nvidia0 nvidia1 nvidia2 nvidia3 nvidiactl
ptmx pts random tty tty1 urandom zero
2. At the host
$ ls /usr/local/nova/instances/instance-004f/rootfs/dev/
blockcrash full kmsg loop5mapper nbd13
nbd7oldmem ram11 ram5rtc sg2 shm
tty0 tty16 tty23 tty30 tty38 tty45 tty52 tty6 ttyS0
usbmon3 vcs2 vcsa3zero bsg disk fuse
kvmloop6mcelog nbd14 nbd8portram12
ram6rtc0 sg3 snapshot tty1 tty17 tty24 tty31 tty39
tty46 tty53 tty60 ttyS1usbmon4 vcs3 vcsa4 bus
dm-0 fw0logloop7mem nbd15 nbd9
ppp ram13 ram7sda sg4 snd tty10 tty18 tty25
tty32 tty4 tty47 tty54 tty61 ttyS2usbmon5 vcs4 vcsa5
char dm-1 hidraw0loop0 lp0 nbd0nbd2
net ptmxram14 ram8sda1 sg5 stderr
tty11 tty19 tty26 tty33 tty40 tty48 tty55 tty62 ttyS3
usbmon6 vcs5 vcsa6 console dm-2 hidraw1loop1
lp1 nbd1nbd3 network_latency pts ram15 ram9
sdb sg6 stdin tty12 tty2 tty27 tty34 tty41 tty49 tty56
tty63 urandom usbmon7 vcs6 vdc core fb
hugepages loop2 lp2 nbd10 nbd4 network_throughput ram0
ram2 random sdb1 sg7 stdouttty13 tty20 tty28 tty35
tty42 tty5 tty57 tty7 usbmon0 usbmon8 vcsa vga_arbiter
cpu fb0hvc0 loop3 lp3 nbd11 nbd5
nullram1ram3 raw sg0 sg8 systty
tty14 tty21 tty29 tty36 tty43 tty50 tty58 tty8 usbmon1
vcs vcsa1 vhost-net cpu_dma_latency fd input loop4
MAKEDEV nbd12 nbd6 nvram ram10 ram4 root
sg1 sg9 tty tty15 tty22 tty3 tty37 tty44 tty51 tty59
tty9 usbmon2 vcs1 vcsa2 VolGroup
Thanks,
David
--
Dr. Dong-In David Kang
Computer Scientist
USC/ISI
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack :: Instance Spawning Error
Ø The Image is moving from the states Scheduling, Networking and to Spawning. In the Spawning phase, a Error is returned. What error do you see ? If you haven’t enabled logging, please do and see if there are any errors – especially in nova-compute log. Which hypervisor are you using ? (Since the error is during “spawning” – it could be related to hypervisor.) -Mandar __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OpenStack][Nova] Can't access the outside from inside my instances.
Hello, I'm having trouble accessing the outside world from within my instances. For instance, i can ping other instances on my network but i am unable to ping www.google.com. Any ideas? Regards, Leander ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack][Nova] Can't access the outside from inside my instances.
dns ? resolv.conf in VM On Wed, Jun 6, 2012 at 4:51 PM, Leander Bessa Beernaert leande...@gmail.com wrote: Hello, I'm having trouble accessing the outside world from within my instances. For instance, i can ping other instances on my network but i am unable to ping www.google.com. Any ideas? Regards, Leander ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack][Nova] Can't access the outside from inside my instances.
Do you have default router in VM ? netstat -rn Do you have multinode configuration ? if all services on one node, do you have ip_forward enabled? sysctl net.ipv4.ip_forward On Wed, Jun 6, 2012 at 5:16 PM, Leander Bessa Beernaert leande...@gmail.com wrote: This is what i find inside my vms: domain novalocal search novalocal nameserver 10.0.8.1 I believe the name resolution is working (see output bellow from the ping command), but the vm's seem unable to access the ip. ping www.google.com PING www.l.google.com (74.125.230.16) 56(84) bytes of data. On Wed, Jun 6, 2012 at 2:12 PM, Anton Haldin ahal...@griddynamics.comwrote: dns ? resolv.conf in VM On Wed, Jun 6, 2012 at 4:51 PM, Leander Bessa Beernaert leande...@gmail.com wrote: Hello, I'm having trouble accessing the outside world from within my instances. For instance, i can ping other instances on my network but i am unable to ping www.google.com. Any ideas? Regards, Leander ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack][Nova] Can't access the outside from inside my instances.
On Wed, Jun 6, 2012 at 2:33 PM, Anton Haldin ahal...@griddynamics.comwrote: Do you have default router in VM ? netstat -rn Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.0.8.10.0.0.0 UG0 0 0 eth0 10.0.8.00.0.0.0 255.255.255.192 U 0 0 0 eth0 Do you have multinode configuration ? if all services on one node, do you have ip_forward enabled? sysctl net.ipv4.ip_forward I have one controller node and 4 compute nodes. On Wed, Jun 6, 2012 at 5:16 PM, Leander Bessa Beernaert leande...@gmail.com wrote: This is what i find inside my vms: domain novalocal search novalocal nameserver 10.0.8.1 I believe the name resolution is working (see output bellow from the ping command), but the vm's seem unable to access the ip. ping www.google.com PING www.l.google.com (74.125.230.16) 56(84) bytes of data. On Wed, Jun 6, 2012 at 2:12 PM, Anton Haldin ahal...@griddynamics.comwrote: dns ? resolv.conf in VM On Wed, Jun 6, 2012 at 4:51 PM, Leander Bessa Beernaert leande...@gmail.com wrote: Hello, I'm having trouble accessing the outside world from within my instances. For instance, i can ping other instances on my network but i am unable to ping www.google.com. Any ideas? Regards, Leander ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack][Nova] Can't access the outside from inside my instances.
I turned out to be a routing problem with the vlan configuration i was using. Thanks for the help nonetheless! Regards, Leander On Wed, Jun 6, 2012 at 2:50 PM, Leander Bessa Beernaert leande...@gmail.com wrote: On the host node, the value of /proc/sys/net/ipv4/ip_forward is 1. On Wed, Jun 6, 2012 at 2:39 PM, Anton Haldin ahal...@griddynamics.comwrote: you can check net.ipv4.ip_forward on machine with ip interface 10.0.8.1 i think on this machine you should have nova-network ( it manages iptables rules, brctl( bridges)) also you can use tcpdump on interface of VM to search icmp packets. On Wed, Jun 6, 2012 at 5:34 PM, Leander Bessa Beernaert leande...@gmail.com wrote: On Wed, Jun 6, 2012 at 2:33 PM, Anton Haldin ahal...@griddynamics.comwrote: Do you have default router in VM ? netstat -rn Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.0.8.10.0.0.0 UG0 0 0 eth0 10.0.8.00.0.0.0 255.255.255.192 U 0 0 0 eth0 Do you have multinode configuration ? if all services on one node, do you have ip_forward enabled? sysctl net.ipv4.ip_forward I have one controller node and 4 compute nodes. On Wed, Jun 6, 2012 at 5:16 PM, Leander Bessa Beernaert leande...@gmail.com wrote: This is what i find inside my vms: domain novalocal search novalocal nameserver 10.0.8.1 I believe the name resolution is working (see output bellow from the ping command), but the vm's seem unable to access the ip. ping www.google.com PING www.l.google.com (74.125.230.16) 56(84) bytes of data. On Wed, Jun 6, 2012 at 2:12 PM, Anton Haldin ahal...@griddynamics.com wrote: dns ? resolv.conf in VM On Wed, Jun 6, 2012 at 4:51 PM, Leander Bessa Beernaert leande...@gmail.com wrote: Hello, I'm having trouble accessing the outside world from within my instances. For instance, i can ping other instances on my network but i am unable to ping www.google.com. Any ideas? Regards, Leander ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] How to let nova use localtime rather than UTC time?
On Wed, 2012-06-06 at 21:33 +0800, livemoon wrote: I found nova use utcnow to get time and write it to db. So the create_time of vm also show utc time rather than localtime. That is correct. Is there any flag in nova.conf to let nova use localtime . You really don't want to do this. Trust me. If you need to see the time in the local timezone, then convert it; there are tools in python to do this. -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [metering] programmatic access to AWS billing data
I saw this blog post [1] this morning, and thought it might be something to keep an eye on for the G release of ceilometer. Doug [1] http://aws.typepad.com/aws/2012/06/new-programmatic-access-to-aws-billing-data.html ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Metering] Agent configuration mechanism
On Wed, Jun 6, 2012 at 6:36 AM, Julien Danjou julien.dan...@enovance.comwrote: On Wed, Jun 06 2012, Nick Barcet wrote: Maybe the problem of discrepancy of configuration is more an issue for metering than for other components? At least that's my belief. […] Sure, I don't say that it's useless to have a centralized configuration management in our case. I just think that it shouldn't be our problem to fix that right now, and that we shouldn't spend our energy trying to fix this. Deployers use configuration management tools to handle this in various OpenStack components so far. I think it's saner, for now, to let this continue until OpenStack provides something better all components can rely on. I'm just having the feeling we're going out of scope here. But this is just my opinion. :) You make a good point. I tend to forget that the ops guys have tools for pushing config changes and restarting services. -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Metering] polling intervals, was: Agent configuration mechanism
Starting a new thread for this topic... On Wed, Jun 6, 2012 at 5:43 AM, Nick Barcet nick.bar...@canonical.comwrote: On 06/05/2012 09:03 PM, Doug Hellmann wrote: Right now we only have one interval for all polling. Do you think we need to add support for polling different values at different intervals? Do we need other per-agent settings, or are all of the settings the same for all agents? (I had assumed the latter would be all we needed.) I would have thought that we may want to support different intervals per meters, based on the billing rules that one may want to offer. For example, I may want to bill compute by the hour but floating IPs by the day, hence have a different reporting interval for each. I was planning to aggregate the values for items being billed over the longer time frames, but we can make the polling interval configurable. It will take some work, because of the way the scheduled tasks are configured in the service and manager (right now we just schedule one method to run, and it invokes each pollster). How important is it to include this in Folsom? Not crucial. I would classify this as Nice to have. We need a ticket to track this. It's going to require some work on the agent service, because right now the code that loads the plugins doesn't have access to the object that knows how to run jobs at regular intervals. I would rather have a complete tool that works at a single interval, then go back and enhance it to allow other intervals during the next release cycle. Is that going to meet your needs? Doug ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Question on nova disk injection...
What implementation suboption would have your preference ? Is nova-rootwrap now universally used ? Should we prefer compatibility or absence of confusion ? There is an issue of how to extend rootwrap from third-party backend drivers. If this was (is?) addressed, universal use of rootwrap will be an easier sell.___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Metering] signing messages, was Re: Agent configuration mechanism
Starting a new thread... On Wed, Jun 6, 2012 at 5:43 AM, Nick Barcet nick.bar...@canonical.comwrote: On 06/05/2012 09:03 PM, Doug Hellmann wrote: On Tue, Jun 5, 2012 at 12:59 PM, Nick Barcet nick.bar...@canonical.com mailto:nick.bar...@canonical.com wrote: On 06/05/2012 04:44 PM, Doug Hellmann wrote: On Tue, Jun 5, 2012 at 10:41 AM, Doug Hellmann doug.hellm...@dreamhost.com mailto:doug.hellm...@dreamhost.com mailto:doug.hellm...@dreamhost.com mailto:doug.hellm...@dreamhost.com wrote: On Tue, Jun 5, 2012 at 9:56 AM, Nick Barcet nick.bar...@canonical.com mailto:nick.bar...@canonical.com mailto:nick.bar...@canonical.com mailto:nick.bar...@canonical.com wrote: Have you given any thought to distributing the secret value used for signing incoming messages? A central configuration authority does not give us a secure way to deliver secrets like that. If anyone with access to the message queue can retrieve the key by sending RPC requests, we might as well not sign the messages. Actually, the private key used to generate a signature should be unique to each host, if we want them to have any value at all, therefore distributing a common signature should NOT be part of this, or we would fall under the notion of a shared secret, which is, IMHO, not any better than having a global password. I would recommend that, for the time being, we just generate a random key pair per host the first time the agent is run, allowing for someone with further requirement to eventually populate this value by another mean. In any case, if we want to effectively check the signature, the public key does need to be accessible by the collector to check it and have yet to define a way to do so... Proposals welcome, but again, while I think we should lay the ground for a great security experience, we certainly don't need to solve it all in v1. The current implementation uses hmac message signatures, which use a shared secret instead of public/private key pairs. We can have a separate secret for each agent, but we still need the collector(s) to have them all. I thought the point of signing the messages was to prevent an arbitrary agent from signing on to the message queue and sending bogus data. Do we need to be doing more than hmac for security? As stated since the beginning of the project, purpose of the signature is non repudiability, not only authentication. If I understand correctly, hmac signature will only provide authentication through a shared secret, shared secret which then should not be transmited on the wire to the agent, or else it would loose all purpose. Yes, hmac uses a shared secret to produce a SHA-256 (in our case) signature of the contents of the message. How that is interpreted is up to the application. For ceilometer it seemed like hmac would be sufficient for both ensuring that the agent was allowed to send messages (because it knows the secret) and that the message contents had not been modified in transit (because the signature is valid). We could have a separate secret for each agent, but I don't see how a keypair is better for this purpose. I'm no crypto expert, though. :-) To cover the non-repudiability requirement the message includes a UUID1 value, which includes the MAC of the sending host as well as time and counter components. No two agents will produce the same UUID1 value at the same time, and no two messages from the same agent will have the same value. I was envisioning a scenario that would allow both: 1. each agent instance generate a keypair 2. pub key is added to collector as in a trusted agent list 3. message are signed by agent using priv key and each message emitted carries a sequence number 4. collector checks signature using the pub key As a result, individual agents are authenticated, their signature is unique so they can be traced and you can't fool the system through a replay since the sequencing would be off. Nick ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Metering] Meeting agenda for Thursday at 16:00 UTC (June 7th, 2012)
Hi, The metering project team holds a meeting in #openstack-meeting, Thursdays at 1600 UTC http://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=0. Everyone is welcome. http://wiki.openstack.org/Meetings/MeteringAgenda Topic: Storage backend * Storage backend (high availability, SPOF etc.) * Agent configuration mechanism https://lists.launchpad.net/openstack/msg12760.html * Open discussion (if we have any time left) Cheers, -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] How to let nova use localtime rather than UTC time?
On Wed, Jun 06, 2012, livemoon mwjpi...@gmail.com wrote: I found nova use utcnow to get time and write it to db. So the create_time of vm also show utc time rather than localtime. You really don't want to do this. For instance, the database won't store the timezone, so in places where there is daylight savings time, timestamps can be ambiguous. As a best practice, the database should store in UTC and then tools should convert to a local timezone for convenience. JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Metering] News from 31/05 to 06/06
Hi, Here's a few things done in the last week concerning ceilometer: - The floating IP pollster have been merged https://github.com/stackforge/ceilometer/commit/bbc706c4c02d2750df961474b00998b9766cd47a - The configuration now uses openstack.common.cfg https://github.com/stackforge/ceilometer/commit/a49e59b1151ce87c8f4ed6e12368e01dbbb6243a - All instance events are listened to https://github.com/stackforge/ceilometer/commit/d615fb872ddceaf1ddef7e3997bcf2523cab283e - Updated to use the new Nova flag API https://github.com/stackforge/ceilometer/commit/6fa69bbdccb9273ef1e55f08dc3db926ab20529c Cheers, -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Clarification on Ceilometer Implementation
On Wed, Jun 6, 2012 at 5:33 AM, Kobagana Kumar kobagana_ku...@persistent.co.in wrote: Hi all, ** ** I am trying to implement Agent module in Ceilometer. Regarding that I have few doubts: ** ** How Ceilometer capturing the usage details? ** ** As we are already know nova simple usage module captures the usage details of nova. It works at API level. But here in ceilometer we are trying to implement Agent module at compute level. For that how can we *** * capture the usage details? Most of the ceilometer agents are going to run at a low level and talk directly to the hypervisor or network manager. For example, the pollsters that Julien wrote use libvirt to get the CPU utilization and disk I/O for a VM. You don't say what your plugin is going to measure, so I can't be much more specific than that. ** ** ** ** What is the format of Plug- In? ** ** We can implement plug–in in various ways. We can use dictionary format,*** * JSON format, etc. In which format Ceilometer implementing the plug – in ** ** and what are the attributes in that. We need to write some developer documentation, but we only finished the first implementation very recently. Until we have better docs, your best source of information is going to be (unfortunately) the source for the existing pollsters (in the ceilometer.compute package, look at libvirt.py and network.py). I will try to summarize what you need to be looking for: An agent plugin (a.k.a., pollster) is a Python class derived from ceilometer.plugin.PollsterBase. You need to implement the get_counters() method in your class. It should return an iterable containing ceilometer.counter.Counter instances filled in with the appropriate data. The code that calls the plugin will format the data from the Counter as a message and publish it, so your plugin doesn't have to worry about that at all. To register the plugin with the agent, create a setuptools entrypoint using the ceilometer.poll.compute namespace (see the setup.py for ceilometer for some examples). If we create a ceilometer agent process that needs to run on non-compute nodes, we will create another namespace for the pollster plugins. Let me know if that information raises more specific questions about how to implement a plugin. Doug ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [metering] need code reviews
Could someone have a look at https://review.stackforge.org/#/c/83/ and https://review.stackforge.org/#/c/99/ today? Thanks, Doug ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Jenkins Changes
There appears to have been some changes to Jenkins recently. Jobs do not appear to be associated with Gerrit changes anymore. https://jenkins.openstack.org/job/gate-nova-python27/ You can see jobs 335 and older have a link to Gerrit, but new jobs don't have any. This makes it harder to see what is happening in Jenkins but also removes the Retrigger link I used to use when there was a transient failure in a job. Was this an intended change in behavior? JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] cfg usage - option registration, global objects
On Wed, Jun 6, 2012 at 10:58 AM, Mark McLoughlin mar...@redhat.com wrote: On Tue, 2012-06-05 at 17:25 -0400, Mark Washenberger wrote: Mark McLoughlin mar...@redhat.com said: On Tue, 2012-06-05 at 12:21 -0400, Mark Washenberger wrote: http://wiki.openstack.org/CommonLibrary#Incubation Once an api is in incubation, if you make a change to it, you are expected to update all the other openstack projects (not just core projects?) to make them work with the new api. Am I understanding this requirement correctly? Yes, pretty much. I should clarify this - I don't think someone improving an API in openstack-common absolutely must update all projects that use it, but I think he/she often will update the major users to make sure the new API works. But the reality is that projects which use openstack-common need to be prepared that someday they might re-sync with latest openstack-common using update.py and find the API has changed. The alternative is that you don't make backwards incompatible API changes. ... What alternative strategy are you suggesting? That if glance, quantum, cinder and ceilometer want to re-use Nova's RPC code, they should copy-and-paste it and hack it to their needs? I don't think our only options here are immediate adoption and relative chaos. Here's what I would like to see: Quantum, cinder, and ceilometer get together, recognize a shared need for rpc, acknowledge the successes and failures of the nova.rpc library, and create a better implementation with eventual adoption by Nova kept in mind. Doesn't that sound better? This approach seems much nicer to me, because I believe that code reuse is likely to be detrimental unless the code we're talking about was created with reuse and generality in mind. Since I find that suggestion implausible regarding nova.rpc in particular, I think we will do better overall avoiding its wider adoption. Please, forgive me if I'm being drawn in falsely by the allure of better code. Code structure and quality *is* something I obsess about. But I appreciate the need to be practical in the short term as well, if I am not always the best at articulating it. The agreement from various quarters about the problems with the current nova.rpc gave me hope that we could craft a better rpc library without too much delay, even if I myself can only contribute in a small way to that effort. I think the summary is that you'd like (someone else?) to start from scratch on a new RPC API in openstack-common, whereas Russell has gone for the approach of taking Nova's RPC API and improving it iteratively. In the absence of someone appearing with that new idealised RPC API, I think it's reasonable for Russell to proceed with his approach. Yes, please, keep going! We're too close now to stop now. I do have some enhancements to propose, but I think I can make them in a backwards compatible way once the existing code is in the common lib. Ceilometer is currently importing bits we need either directly from nova or openstack-common (by importing I mean literally using the import statement in our code, not copying the required modules into the ceilometer code base). I was under the impression that this is how we wanted (new) projects to use openstack-common, but maybe I misunderstood? Should we be planning to copy code out of openstack-common into the ceilometer repository? Doug ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] cfg usage - option registration, global objects
On Wed, 2012-06-06 at 12:05 -0400, Doug Hellmann wrote: Ceilometer is currently importing bits we need either directly from nova or openstack-common (by importing I mean literally using the import statement in our code, not copying the required modules into the ceilometer code base). I was under the impression that this is how we wanted (new) projects to use openstack-common, but maybe I misunderstood? Should we be planning to copy code out of openstack-common into the ceilometer repository? Yep, the rpc code will be in incubation for a while: http://wiki.openstack.org/CommonLibrary Add an openstack-common.conf and use update.py to sync it across. Cheers, Mark. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Change user password (not admin)
Hi everyone! I am trying to develop a new feature to horizon, I want to users can update their own password. I used this: from horizon import api api.user_update_password( request, request.user.id, form.cleaned_data['new_password'], admin=True ) But the user is logged out because in keystone.py there is this: if not user.is_admin(): raise exceptions.NotAuthorized So, Only the user admin can use that method. How can I be able to use this method with a normal user, or do you recommend to query the database directly to modify the password in the user table. Thanks in advance! ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Can't manage volumes snapshots with python-novaclient
Hi, I have a bug with python-novaclient / Ubuntu 12.04 / Essex (2012.1-0ubuntu2.1 version for OpenStack packages). My nova.conf : http://paste.openstack.org/show/18372/ Issue : - When I go to the dashboard, from my project tab I can't go to Instances Volumes and Images Snapshots. Here the debug : http://paste.openstack.org/show/18363/ - nova volume-list fails : http://paste.openstack.org/show/18368/ Any idea ? Regards -- Emilien Macchi *SysAdmin (Intern)* *www.stackops.com* | emilien.mac...@stackops.com** * * ADVERTENCIA LEGAL Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley. * PRIVILEGED AND CONFIDENTIAL We hereby inform you, as addressee of this message, that e-mail and Internet do not guarantee the confidentiality, nor the completeness or proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does not assume any liability for those circumstances. Should you not agree to the use of e-mail or to communications via Internet, you are kindly requested to notify us immediately. This message is intended exclusively for the person to whom it is addressed and contains privileged and confidential information protected from disclosure by law. If you are not the addressee indicated in this message, you should immediately delete it and any attachments and notify the sender by reply e-mail. In such case, you are hereby notified that any dissemination, distribution, copying or use of this message or any attachments, for any purpose, is strictly prohibited by law. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OpenStack][Nova] VM cannot be shutdown after installing NOVA
Hi all, I Installed OpenStack Nova, Glance and KeyStone in an Ubuntu-12.04 virtual machine (Guest OS), in Virtual Box. Thereafter I'm having issues when shutting down the virtual machine (Guest machine), when I shut it down, it gets logged off only. So i have to force it power off. Thereafter restarting the machine I'm getting system errors, saying Exceptions has occurred, and asks for submitting bug reports. The issues seems to be having, nova-scheduler was shutdown unexpectedly .. nova-dhcpbridge was shutdown unexpectedly .. So, i guess this is a result of forcing power off the VM Is there any workaround for this? or is this a known issue ? Thanks in advance Sajith ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Cpu Affinity with Open Stack and KVM
Hi, I was looking to pin the virtual cores to physical cores when using KVM as hypervisor and Open stack and cloud management system. Is there an option where I can specify this preference? Thanks, Abhishek ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Parallel execution of Jenkins gate jobs
On Tue, Jun 05, 2012, James E. Blair cor...@inaugust.com wrote: One important difference is that the new system does not have retrigger buttons in Jenkins. If the gate tests fail with a false negative, you'll need to leave another Approved vote in Gerrit. This part of your post didn't immediately register with me. I have to say that with how unreliable some of the jobs are (which are usually problems fetching packages), this change makes approvals a bit more annoying. For instance: https://review.openstack.org/#/c/8133/ It failed with a transient failure in gate-nova-python27. No retrigger function anymore, so reapprove. It now passes in gate-nova-python27 but fails in gate-nova-python26 (which previously passed). I understand the problem is with upstream usually, but combined with the unreliability of upstream and the need to rerun *all* of the tests, it increases the amount of baby sitting required. That means more work for us core members. I'd really like to figure out a way to reduce the amount of unnecessary work for us. Possibly find out a way to cache packages to reduce the number of failures we see, provide a way to retrigger individual jobs again or perhaps something else. JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Jenkins Changes
Johannes Erdfelt johan...@erdfelt.com writes: There appears to have been some changes to Jenkins recently. Jobs do not appear to be associated with Gerrit changes anymore. https://jenkins.openstack.org/job/gate-nova-python27/ You can see jobs 335 and older have a link to Gerrit, but new jobs don't have any. This makes it harder to see what is happening in Jenkins but also removes the Retrigger link I used to use when there was a transient failure in a job. Was this an intended change in behavior? Yes, see the message with subject Parallel execution of Jenkins gate jobs on this list. The short version is that we've moved most triggering of Jenkins jobs out of the Gerrit Trigger Plugin. The bad news about that is that we lose the those links and the retrigger buttons. The good news is that we get parallel execution of gate jobs. This means that if you approve, say, four changes to nova, they will all test and merge at the same time (if they all succeed). Especially when we start gating on tempest, we are looking at significantly longer run-times for gate tests, so we very much need the ability to increase the rate at which we can test and merge changes. I think the trade off will be worth it. You can still link Jenkins jobs to Gerrit changes though. Near the top of most jobs, you will see a line like: Triggered by: https://review.openstack.org/8228 So you can see what change triggered a Job. Because jobs are run and are reported more quickly (Jenkins has gone from having a _huge_ queue of jobs to run to generally having no queue) the time between when there have been jobs triggered and when they are reported to Gerrit should be shorter, so there should be less need to search for a job in Jenkins. I also miss the retrigger button. If it is very important, we can work on adding equivalent functionality back. However, core members can always retrigger a change by leaving another Approved vote. Additionally, we're working on reducing transient failures -- we've just rolled out a local pypi mirror that is built from the requirements of the collection of projects. Hopefully we can reduce the number of transient failures and we won't need that functionality. -Jim ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Capability of Openstack ?
Hi Rajesh, I believe you'll find the answers to your questions on our website http://www.openstack.org/. You may be interested to read the stories told by OpenStack users on http://www.openstack.org/user-stories/. You may also be interested in the suggestions contained on http://www.openstack.org/projects. To answer your question #5, I like to point out at the massive amount of companies and people that contribute to OpenStack as one of its unique characteristics compared to other open source cloud frameworks. The full list of people that contributed to last release is on http://www.openstack.org/projects/essex/. The size of the community is an important factor in evaluating open source projects according to OSMM http://en.wikipedia.org/wiki/OpenSource_Maturity_Model Cheers, stef On Wed 06 Jun 2012 03:05:32 AM PDT, Rajesh Avula wrote: Hi, Of course a basic question, Could anyone please let me know below concerns... 1. What are the advantages we will get if we prefer to use Openstack as a cloud solution? 2. What are the strong points of Openstack ? 3. While proposing Openstack as solution to the customer, How can I convenience them to go for Openstack? 4. What are the strong points and weak points of Openstack? 5. How Openstack will be the best cloud solution if compare to others (i.e., Eucalyptus, couldstack and etc.,) I know that Openstack is Fully opensource, can support to multiple hypervisors and has big support from the companies. -- Thanks Regards, Rajesh Avula 07259024701. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Can't manage volumes snapshots with python-novaclient
I found the solution. My Volume Endpoint was in v1.1, and it should be v1. Status : fixed. Regards On Wed, Jun 6, 2012 at 7:42 PM, Kiall Mac Innes ki...@managedit.ie wrote: Have you checked the server logs? Both of the logs you pasted are from the client side.. (Horizon and the nova command both use python-novaclient to speak to nova-api - where the real error will be logged) Thanks, Kiall On Wed, Jun 6, 2012 at 5:35 PM, Emilien Macchi emilien.mac...@stackops.com wrote: Hi, I have a bug with python-novaclient / Ubuntu 12.04 / Essex (2012.1-0ubuntu2.1 version for OpenStack packages). My nova.conf : http://paste.openstack.org/show/18372/ Issue : - When I go to the dashboard, from my project tab I can't go to Instances Volumes and Images Snapshots. Here the debug : http://paste.openstack.org/show/18363/ - nova volume-list fails : http://paste.openstack.org/show/18368/ Any idea ? Regards -- Emilien Macchi *SysAdmin (Intern)* *www.stackops.com* | emilien.mac...@stackops.com** * * ADVERTENCIA LEGAL Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley. * PRIVILEGED AND CONFIDENTIAL We hereby inform you, as addressee of this message, that e-mail and Internet do not guarantee the confidentiality, nor the completeness or proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does not assume any liability for those circumstances. Should you not agree to the use of e-mail or to communications via Internet, you are kindly requested to notify us immediately. This message is intended exclusively for the person to whom it is addressed and contains privileged and confidential information protected from disclosure by law. If you are not the addressee indicated in this message, you should immediately delete it and any attachments and notify the sender by reply e-mail. In such case, you are hereby notified that any dissemination, distribution, copying or use of this message or any attachments, for any purpose, is strictly prohibited by law. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Emilien Macchi *SysAdmin (Intern)* *www.stackops.com* | emilien.mac...@stackops.com** * * ADVERTENCIA LEGAL Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley. * PRIVILEGED AND CONFIDENTIAL We hereby inform you, as addressee of this message, that e-mail and Internet do not guarantee the confidentiality, nor the completeness or proper reception of
Re: [Openstack] Nova migrate and resize
Hi, I mention nova user because it's the default in the main distros. If I understood correctly your question, you can have different users... of course you need to distribute the right keys for ssh access and make sure they have the right permissions in your nova installation. cheers, Belmiro On Jun 6, 2012, at 2:12 AM, William Herry wrote: Hi Belmiro, thanks for your share Is that required that the two node must have the same setting about the user, like they all use nova run nova-* command, what if I set them different(one of them run nova-* command with user 'stack', is it possible to make it work also? Thanks On Wed, Jun 6, 2012 at 2:17 AM, Belmiro Moreira moreira.belmiro.email.li...@gmail.com wrote: Hi, I spent some time today trying understand how to use successfully the “resize” and “migrate” in nova. Because I couldn’t find any documentation… I share my experience. I have a kvm multi-node installation using fedora 16. Migrate and resize use ssh to create the directories and transfer the image. So you need to make sure that “nova” user is able to ssh the other compute nodes. Make sure you have this in your ssh configuration: Host * StrictHostKeyChecking no UserKnownHostsFile=/dev/null Create a ssh key for “nova” and distribute it in your setup. If you are using Fedora set selinux to permissive. … and should work. cheers, Belmiro ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- William Herry williamherrych...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Metering] Agent configuration mechanism
On Wed, Jun 6, 2012 at 12:59 PM, Tim Bell tim.b...@cern.ch wrote: ** ** With the Chef and Puppet configurators, I think we cover a large share of the community. I’d suggest that once the formats of the configuration files are settled, we get the associated supporters in Chef-land and Puppet-land to add these to their recipes along with the other folsom changes…. ** ** Doing something in one component of OpenStack to perform configuration management would actually make our job more difficult as we’ve got the infrastructure with the puppetlabs recipes to deploy and having one configuration management system fighting another is likely to cause more difficulties than it solves. ** ** Document the configuration file formats etc. clearly and as consistently as possible with other openstack components but leave the actual configuration to the dedicated devops tools. That sounds like an excellent plan. We're using the cfg module from openstack-common, so the file format should be the same as for the other projects. ** ** Tim ** ** *From:* openstack-bounces+tim.bell=cern...@lists.launchpad.net [mailto: openstack-bounces+tim.bell=cern...@lists.launchpad.net] *On Behalf Of *Doug Hellmann *Sent:* 06 June 2012 17:03 *To:* Julien Danjou *Cc:* openstack@lists.launchpad.net *Subject:* Re: [Openstack] [Metering] Agent configuration mechanism ** ** ** ** On Wed, Jun 6, 2012 at 6:36 AM, Julien Danjou julien.dan...@enovance.com wrote: On Wed, Jun 06 2012, Nick Barcet wrote: Maybe the problem of discrepancy of configuration is more an issue for metering than for other components? At least that's my belief. […] Sure, I don't say that it's useless to have a centralized configuration management in our case. I just think that it shouldn't be our problem to fix that right now, and that we shouldn't spend our energy trying to fix this. ** ** ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Passing parameters from Quantum manager to Nova compute
Hi, While Quantum manager may communicate with compute nodes using a quantum agent, in some cases when Quantum is integrated with Nova, the agent may not be needed (while it can be used for enhanced services). In this cases, when the Quantum VIF driver (which is part of Nova compute) is used for VM provisioning/terminating/restarting utilizing the existing Nova infrastructure, it may be required to pass parameters from the quantum manager to the Quantum driver. Nevertheless, in current Nova architecture the Nova network does not pass the values returned from the quantum Manager to the compute nodes. I really think that passing the Quantum manager values to the Quantum VIF driver is really important for Quantum agent less implementation and it is quite an easy change to make. RamiC ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] secure logging in OpenStack
Hi all, I'm Paolo a research assistant at Polytechnic University of Turin. I wrote a library that implement some security features for logging. In a few words, the library generates a log files where all log entries are linked through an hash chain. In this way it's possible to verify the integrity of the log files. Now, I would to integrate functionalities provided by my library in the OpenStack logging system. From a rapid view of python logging module, I saw that its possible to define custom logging handlers. My idea is to define a new handler as follow class SecureLogHandler(logging.Handler) and to include it in the log module of OpenStack. Is this a good approach? There are some directives that I must follow (code styling, method definition, ...)? Thanks in advance for the replies!!! :-) Paolo -- PAOLO SMIRAGLIA Department of Control and Computer Engineering Polytechnic University of Turin Email: paolo.smirag...@polito.it smime.p7s Description: S/MIME Cryptographic Signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] How to let nova use localtime rather than UTC time?
Stored timestamps should always be in UTC, however efforts should be made to support local timezones as a user-configurable option. Horizon will be working towards this goal since Django has good timezone support, I'd encourage other projects to keep this on their radar as well. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Johannes Erdfelt Sent: Wednesday, June 06, 2012 8:35 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] How to let nova use localtime rather than UTC time? On Wed, Jun 06, 2012, livemoon mwjpi...@gmail.com wrote: I found nova use utcnow to get time and write it to db. So the create_time of vm also show utc time rather than localtime. You really don't want to do this. For instance, the database won't store the timezone, so in places where there is daylight savings time, timestamps can be ambiguous. As a best practice, the database should store in UTC and then tools should convert to a local timezone for convenience. JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Change user password (not admin)
I've had this fight with Joe Heck and Termie before. They rejected my attempts to modify the Keystone code to allow a user to change their own password. I believe their grounds were a combination of it being an admin activity, and that adding it to the user API would change the API contract and couldn't be done in until v.next of the API. Feel free to have at it with them again. ;-) - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Guillermo Alvarado Sent: Wednesday, June 06, 2012 9:24 AM To: openstack@lists.launchpad.net Subject: [Openstack] Change user password (not admin) Hi everyone! I am trying to develop a new feature to horizon, I want to users can update their own password. I used this: from horizon import api api.user_update_password( request, request.user.idhttp://request.user.id, form.cleaned_data['new_password'], admin=True ) But the user is logged out because in keystone.py there is this: if not user.is_admin(): raise exceptions.NotAuthorized So, Only the user admin can use that method. How can I be able to use this method with a normal user, or do you recommend to query the database directly to modify the password in the user table. Thanks in advance! ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Proposal to add Tihomir Trifinov to Horizon Core
A couple of us on the Horizon team have been talking, and we'd like to recognize the tremendous work the Tihomir has been doing on Horizon for the past 6+ months by making him a member of Horizon Core. He's been writing great code, doing consistent and helpful reviews, tackling important bugs, and all around being an excellent contributor. I certainly trust his judgment at this point. I believe the official process is to propose new additions to the core teams on the mailing list, so... that's what I'm doing. All the best, - Gabriel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Parallel execution of Jenkins gate jobs
Johannes Erdfelt johan...@erdfelt.com writes: On Tue, Jun 05, 2012, James E. Blair cor...@inaugust.com wrote: One important difference is that the new system does not have retrigger buttons in Jenkins. If the gate tests fail with a false negative, you'll need to leave another Approved vote in Gerrit. I have to say that with how unreliable some of the jobs are (which are usually problems fetching packages), this change makes approvals a bit more annoying. I wholeheartedly agree. That's why Monty has been working on setting up a pypi mirror so we can be responsible for ensuring that all of the pip dependencies are always available to Jenkins. You can see the result of his work here: http://pypi.openstack.org/ It's built from the pip dependencies of all the projects, so it should be exactly what we need to run tests. And the program that generates it here: https://github.com/openstack/openstack-ci-puppet/tree/master/modules/pypimirror For instance: https://review.openstack.org/#/c/8133/ It failed with a transient failure in gate-nova-python27. No retrigger function anymore, so reapprove. It now passes in gate-nova-python27 but fails in gate-nova-python26 (which previously passed). I understand the problem is with upstream usually, but combined with the unreliability of upstream and the need to rerun *all* of the tests, it increases the amount of baby sitting required. Indeed, that problem is due to a failure to download a pip requirement from sourceforge. It _should_ be cached in the mirror, but wasn't due to a bug in the mirroring code. Monty fixed that yesterday, so I'll go see why that hasn't propagated to the mirror. It also looks like the devstack hosts may not be using the mirror; I'm going to look into that as well. That means more work for us core members. I'd really like to figure out a way to reduce the amount of unnecessary work for us. Possibly find out a way to cache packages to reduce the number of failures we see, provide a way to retrigger individual jobs again or perhaps something else. Unfortunately, retriggering individual jobs was never technically correct with the way our trunk gating works, and even less so now that changes are being stacked on top of each other when testing (the state of the repository and set of changes that should be tested can change dramatically between test runs). So if we did implement a retrigger function, even it should cause all the tests to run again. I think we should concentrate our energy on reducing the transient failures. I think we have a good approach here, with the local pypi mirror as a method of caching packages. In short, I completely agree with your concerns. I want to make it so that the tests are extremely reliable and there is no need to retrigger, which will ultimately make less work for the core developers. I'm sorry if it's rough over the next few days as we work the bugs out. For my part, I will re-approve jobs that I see need it while I'm chasing down problems. -Jim ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] cfg usage - option registration, global objects
But the reality is that projects which use openstack-common need to be prepared that someday they might re-sync with latest openstack-common using update.py and find the API has changed. That sounds good, especially during the early parts of incubation. In the absence of someone appearing with that new idealised RPC API, I think it's reasonable for Russell to proceed with his approach. Looking more closely at Russell's improvements, and thinking about the big changes I think we ought to make, it seems he's done a lot of the good work already. I would like for us to kick the global and C-style polymorphism habits in rpc, but I guess the best I can do is try to add these changes after its in common. Sorry if this has already been posted somewhere and I just can't find it, but is there an openstack common weekly meeting where you guys talk about your blueprints and determine what is going into common and in what form? I think I can be less disruptive if I'm involved in these discussions much earlier. Mark McLoughlin mar...@redhat.com said: On Tue, 2012-06-05 at 17:25 -0400, Mark Washenberger wrote: Mark McLoughlin mar...@redhat.com said: On Tue, 2012-06-05 at 12:21 -0400, Mark Washenberger wrote: http://wiki.openstack.org/CommonLibrary#Incubation Once an api is in incubation, if you make a change to it, you are expected to update all the other openstack projects (not just core projects?) to make them work with the new api. Am I understanding this requirement correctly? Yes, pretty much. I should clarify this - I don't think someone improving an API in openstack-common absolutely must update all projects that use it, but I think he/she often will update the major users to make sure the new API works. But the reality is that projects which use openstack-common need to be prepared that someday they might re-sync with latest openstack-common using update.py and find the API has changed. The alternative is that you don't make backwards incompatible API changes. ... What alternative strategy are you suggesting? That if glance, quantum, cinder and ceilometer want to re-use Nova's RPC code, they should copy-and-paste it and hack it to their needs? I don't think our only options here are immediate adoption and relative chaos. Here's what I would like to see: Quantum, cinder, and ceilometer get together, recognize a shared need for rpc, acknowledge the successes and failures of the nova.rpc library, and create a better implementation with eventual adoption by Nova kept in mind. Doesn't that sound better? This approach seems much nicer to me, because I believe that code reuse is likely to be detrimental unless the code we're talking about was created with reuse and generality in mind. Since I find that suggestion implausible regarding nova.rpc in particular, I think we will do better overall avoiding its wider adoption. Please, forgive me if I'm being drawn in falsely by the allure of better code. Code structure and quality *is* something I obsess about. But I appreciate the need to be practical in the short term as well, if I am not always the best at articulating it. The agreement from various quarters about the problems with the current nova.rpc gave me hope that we could craft a better rpc library without too much delay, even if I myself can only contribute in a small way to that effort. I think the summary is that you'd like (someone else?) to start from scratch on a new RPC API in openstack-common, whereas Russell has gone for the approach of taking Nova's RPC API and improving it iteratively. In the absence of someone appearing with that new idealised RPC API, I think it's reasonable for Russell to proceed with his approach. Cheers, Mark. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OSSA 2012-007] Security groups fail to be set correctly (CVE-2012-2654)
OpenStack Security Advisory: 2012-007 CVE: 2012-2654 Date: June 6, 2012 Title: Security groups fail to be set correctly Impact: Medium Reporter: HP Cloud Services hpcs.secur...@hp.com Products: Nova Affects: All versions Description: HP Cloud Services reported a vulnerability in Nova API handling. When a security group is created via the EC2 or OS API's that uses a protocol defined in the incorrect case i.e 'TCP' rather than 'tcp' it causes a later string comparison to fail. This leads to Security Groups not being set correctly. Once the Nova DB has been polluted with the incorrect case any subsequent modifications to the security group will also fail. Database considerations: The fix will make Nova resilient to any protocol case inconsistencies that may be in the Nova DB. Users may want to consider sanitizing their database by forcing all protocol entries to lower case, hardening their DB against any failures of future code that may expect the data to be lower case. Fixes: Folsom: https://github.com/openstack/nova/commit/ff06c7c885dc94ed7c828e8cdbb8b5d850a7e654 Essex: https://github.com/openstack/nova/commit/9f9e9da777161426a6f8cb4314b78e09beac2978 Diablo: https://review.openstack.org/#/c/8239/ Notes: This fix will be included in the folsom-2 development milestone and in future essex and diablo releases. -- Russell Bryant OpenStack Vulnerability Management Team ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Essex: LXC volume attachment does not work?
Sure,
It is done.
It is reported as
OpenStack Compute (nova) Bugs Bug #1009701
Thanks,
David
--
Dr. Dong-In David Kang
Computer Scientist
USC/ISI
- Original Message -
Hi,
Can you please open up a bug in Launchpad please?
thanks
chuck
On Tue, 5 Jun 2012 15:38:11 -0700 (PDT)
David Kang dk...@isi.edu wrote:
Hello,
We are using Essex version.
We are testing volume attachment to an LXC instance.
From the code, the volume is mounted by the host machine to the
file
system of the LXC instance.
# nova/virt/disk/api.py
utils.execute('mount', '-o', 'bind', src, target,
run_as_root=True)
From the host machine, it is visible.
But, inside of the LXC instance, it is not visible.
Does this method work?
Before Essex, we used lxc-attach command to run mknod command
inside of the LXC instance instead of mount it by the host outside
of the LXC instance. It did work.
Here are the content of the dev directory shown inside of the LXC
instance, and at the host side. Both are different. And dynamic
changes done by the host outside of the LXC instance is not shown
inside of the LXC instance. Is our LXC configuration or our LXC
image
is wrong?
1. Inside the LXC instance
$ ls /dev
console full null nvidia0 nvidia1 nvidia2 nvidia3 nvidiactl
ptmx pts random tty tty1 urandom zero
2. At the host
$ ls /usr/local/nova/instances/instance-004f/rootfs/dev/
block crash full kmsg loop5 mapper nbd13
nbd7 oldmem ram11 ram5 rtc sg2 shm
tty0 tty16 tty23 tty30 tty38 tty45 tty52 tty6 ttyS0
usbmon3 vcs2 vcsa3 zero bsg disk fuse
kvm loop6 mcelog nbd14 nbd8 port ram12
ram6 rtc0 sg3 snapshot tty1 tty17 tty24 tty31 tty39
tty46 tty53 tty60 ttyS1 usbmon4 vcs3 vcsa4 bus
dm-0 fw0 log loop7 mem nbd15 nbd9
ppp ram13 ram7 sda sg4 snd tty10 tty18 tty25
tty32 tty4 tty47 tty54 tty61 ttyS2 usbmon5 vcs4 vcsa5
char dm-1 hidraw0 loop0 lp0 nbd0 nbd2
net ptmx ram14 ram8 sda1 sg5 stderr
tty11 tty19 tty26 tty33 tty40 tty48 tty55 tty62 ttyS3
usbmon6 vcs5 vcsa6 console dm-2 hidraw1 loop1
lp1 nbd1 nbd3 network_latency pts ram15 ram9
sdb sg6 stdin tty12 tty2 tty27 tty34 tty41 tty49 tty56
tty63 urandom usbmon7 vcs6 vdc core fb
hugepages loop2 lp2 nbd10 nbd4 network_throughput ram0
ram2 random sdb1 sg7 stdout tty13 tty20 tty28 tty35
tty42 tty5 tty57 tty7 usbmon0 usbmon8 vcsa vga_arbiter
cpu fb0 hvc0 loop3 lp3 nbd11 nbd5
null ram1 ram3 raw sg0 sg8 systty
tty14 tty21 tty29 tty36 tty43 tty50 tty58 tty8 usbmon1
vcs vcsa1 vhost-net cpu_dma_latency fd input loop4
MAKEDEV nbd12 nbd6 nvram ram10 ram4 root
sg1 sg9 tty tty15 tty22 tty3 tty37 tty44 tty51 tty59
tty9 usbmon2 vcs1 vcsa2 VolGroup
Thanks,
David
--
Dr. Dong-In David Kang
Computer Scientist
USC/ISI
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] install cloud computing by openstack!!!
What messages do you get? Have you set the right environment variables? export OS_AUTH_URL=http://controller public ip:5000/v2.0/ export OS_TENANT_NAME=admin export OS_USERNAME=admin export OS_PASSWORD=admin export OS_REGION_NAME=myRegion export SERVICE_TOKEN=admin export SERVICE_ENDPOINT=http://controller public ip:35357/v2.0 Set the variables to the values used during installation. One more thing: Make sure you're using a the right IP, this must be static assigned in /etc/network/interfaces. Adding the export instructions to ~/.bashrc makes them available after every login. On Wed, Jun 6, 2012 at 5:37 AM, Từ Minh Mẫn tuminh...@gmail.com wrote: Sorry, The last time, I already run keystone ok, but this time I restart server1, and I can not run keystone, I must reinstall keystone, I do not know why? Please show me how to install keystone and can continue run keystone when we restart server1! Thanks you so much! On 6 June 2012 02:10, Dolph Mathews dolph.math...@gmail.com wrote: Based on your previous emails, I'm not clear on whether or not you have confirmed that keystone is successfully running against your mysql server as expected. Can you authenticate with your keystone server using keystoneclient? -Dolph On Tue, Jun 5, 2012 at 12:49 PM, Từ Minh Mẫn tuminh...@gmail.com wrote: Dear all, I am install server1, and I am installing glance, when I type command: glance index, it have error:* ...you are not authenticated,* And When I install Client1, I type command: nova list to check connectivity to Openstack setup, it have error:* ERROR: n/a (HTTP 400)* , Please help me to solve this problems, Thank you very much! On 5 June 2012 23:03, Từ Minh Mẫn tuminh...@gmail.com wrote: Dear all, Thank you for all reply, I have already install server to glance, and I continue install client1. I have problem want to ask: The server1, I installed in Virtual machine and client1 I also install in virtual machine, is it ok? On 4 June 2012 06:07, William Herry william.herry.ch...@gmail.comwrote: 1. check if mysql is running(netstat -antlp | grep 3306) 2. check if keystone.conf point to the right mysql url On Sun, Jun 3, 2012 at 1:50 AM, Từ Minh Mẫn tuminh...@gmail.comwrote: Sorry, I check step by step from create database, and when I use command: sudo keystone-manage db_sync It have a error: 2003,Can't connect to MySQL server on '10.10.10.2 (101)) None None Please help me: Can I check this error? Thanks so much! On 2 June 2012 23:08, Dolph Mathews dolph.math...@gmail.com wrote: Can you share your keystone configuration and keystoneclient configuration? A 400 could be as simple as the keystone service not running. -Dolph Mathews On Jun 2, 2012, at 1:48 AM, Từ Minh Mẫn tuminh...@gmail.com wrote: When I try to do tenant-create I also have problem: No handlers could be found for logger keystoneclient.client Unable to communicate with identity service: [Error 111] Connection refused. (HTTP 400) When I use command: keystone tenant-list, it have them same error! Please help me!!! Thanks so much! On 1 June 2012 00:40, Dolph Mathews dolph.math...@gmail.com wrote: That's just a warning you can safely ignore for now (and a known issue): https://bugs.launchpad.net/keystone/+bug/936404 On Thu, May 31, 2012 at 12:09 PM, Từ Minh Mẫn tuminh...@gmail.comwrote: Dear all, When I Create Tenants: I use command: keystone tenant-create --name admin, Have error: No handlers could be found for logger keystoneclient.client Please help me!!! On 29 May 2012 08:30, Từ Minh Mẫn tuminh...@gmail.com wrote: If I use Ubuntu 12.04 32bit, do I have any problem when I install cloud computing? On 29 May 2012 00:38, Sébastien Han han.sebast...@gmail.comwrote: There are tons of answers by simply googling your issue... and this problem is more related to the Ubuntu Server mailing but anyway you should try with the Ubuntu Server 32 bits. http://www.ubuntu.com/start-download?distro=serverbits=32release=lts Or try to enable Intel VT-x or AMD-V from your BIOS (if your processor supports the extensions). Hope it helps :) Cheers. ~Seb. On Mon, May 28, 2012 at 7:12 PM, Từ Minh Mẫn tuminh...@gmail.com wrote: I reading document about install: http://docs.openstack.org/essex/openstack-compute/starter/content/Base_OS-d1e542.html I am using Window7 32bit, I want to install server1(64 bit version of Ubuntu server 12.04) on Virtual machine (VMWare Workstation 8), When I boot VMWare to install Ubuntu, I have problem: This kernel requires an x86-64 CPU, but only detected an i686 CPU. Unable to boot – please use a kernel appropriate for your CPU Please help me to solve this problem! On 28 May 2012 14:49, Razique Mahroua razique.mahr...@gmail.com wrote: Yes sorry, my question was intended to Từ Minh Mẫn tuminh...@gmail.com:-) Michael Pittaro mik...@lahondaresearch.org 28 mai 2012 01:41 It's really a matter of
Re: [Openstack] Passing parameters from Quantum manager to Nova compute
On Wed, 2012-06-06 at 21:35 +0300, Rami Cohen wrote: Hi, While Quantum manager may communicate with compute nodes using a quantum agent, in some cases when Quantum is integrated with Nova, the agent may not be needed (while it can be used for enhanced services). In this cases, when the Quantum VIF driver (which is part of Nova compute) is used for VM provisioning/terminating/restarting utilizing the existing Nova infrastructure, it may be required to pass parameters from the quantum manager to the Quantum driver. Nevertheless, in current Nova architecture the Nova network does not pass the values returned from the quantum Manager to the compute nodes. I really think that passing the Quantum manager values to the Quantum VIF driver is really important for Quantum agent less implementation and it is quite an easy change to make. You can pass any values you want in the NetworkModel's various metadata fields, with the caveat that you must ensure that it is not required for other network managers. Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Integration Test Failing for Review
Hello Everyone! I have a review up that keeps failing the integration tests on Jenkins due to some sort of dependency issue. I am not really sure what the issue is, but the stack trace in the console output is complaining about No module named version tools.setuptools_hooks from within Django Appconfig, see here: https://jenkins.openstack.org/job/gate-integration-tests-devstack-vm/4629/console Is there something I need to do/can be done to make this run? Here is the review: https://review.openstack.org/#/c/7367/ John Postlethwait Nebula, Inc. 206-999-4492 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Openstack-operators] Quantum+Openvswitch: possible network configurations
Hi Igor, How did you progress in your dual node ? I'm interesting about that :-) Regards On Sat, Jun 2, 2012 at 6:03 PM, Igor Laskovy igor.lask...@gmail.com wrote: Hello all from sunny Kiev! I have lab with two nodes (controller and compute) and Quantum+Openvswitch setup. With which options in nova.conf I can configure just simply putting my instances into one network without providing any gw/nats, without setting any ip subnets and dhcp activities for this network? Just putting virtual nics in the bridge, mark it with some vlan id/xvlan label and run traffic away through one of the network card of physical host. -- Igor Laskovy Kiev, Ukraine ___ Openstack-operators mailing list openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- Emilien Macchi *SysAdmin (Intern)* *www.stackops.com* | emilien.mac...@stackops.com** * * ADVERTENCIA LEGAL Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley. * PRIVILEGED AND CONFIDENTIAL We hereby inform you, as addressee of this message, that e-mail and Internet do not guarantee the confidentiality, nor the completeness or proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does not assume any liability for those circumstances. Should you not agree to the use of e-mail or to communications via Internet, you are kindly requested to notify us immediately. This message is intended exclusively for the person to whom it is addressed and contains privileged and confidential information protected from disclosure by law. If you are not the addressee indicated in this message, you should immediately delete it and any attachments and notify the sender by reply e-mail. In such case, you are hereby notified that any dissemination, distribution, copying or use of this message or any attachments, for any purpose, is strictly prohibited by law. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] How to let nova use localtime rather than UTC time?
On Wed, Jun 06, 2012, Gabriel Hurley gabriel.hur...@nebula.com wrote: Stored timestamps should always be in UTC, however efforts should be made to support local timezones as a user-configurable option. Horizon will be working towards this goal since Django has good timezone support, I'd encourage other projects to keep this on their radar as well. I'm a little confused by your reply. You said it should always be stored in UTC, but then it should be user-configurable to use local timezones? JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova multi_host and Quantum
Hi David, It will be possible to use Quantum in Folsom with a multi_host like approach where the gateway forwarding, NAT, and DHCP are handled locally The work for Quantum to be feature complete is all targeted for the F-2 milestone (early July), but realistically, some of that will spill into F-3, including likely the multi_host work. Its also worth noting that to ensure a smooth transition, we are planning on keeping the existing Nova network managers (Flat, FlatDHCP, Vlan) in the Folsom release. So while the default will shift to being Quantum, people will have time to get experience with Quantum before having to change anything about their existing setups. Dan On Wed, Jun 6, 2012 at 11:17 AM, David Kranz david.kr...@qrclab.com wrote: I am confused about the plan for this in Folsom. I have seen by searching that multi_host in nova.conf and using Quantum is not supported in Essex, and that in Folsom there will be a Quantum way to get the same kind of ha as with multi_host. Does that mean that multi_host is being deprecated? At which milestone is Quantum scheduled to be feature-complete? -David __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/~openstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal to add Tihomir Trifinov to Horizon Core
I absolutely agree with this sentiment. Tihomir has been doing an amazing job and has been extremely attentive and helpful. John Postlethwait Nebula, Inc. 206-999-4492 On Wednesday, June 6, 2012 at 12:12 PM, Gabriel Hurley wrote: A couple of us on the Horizon team have been talking, and we'd like to recognize the tremendous work the Tihomir has been doing on Horizon for the past 6+ months by making him a member of Horizon Core. He's been writing great code, doing consistent and helpful reviews, tackling important bugs, and all around being an excellent contributor. I certainly trust his judgment at this point. I believe the official process is to propose new additions to the core teams on the mailing list, so... that's what I'm doing. All the best, - Gabriel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net (mailto:openstack@lists.launchpad.net) Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Passing parameters from Quantum manager to Nova compute
On Wed, Jun 6, 2012 at 11:35 AM, Rami Cohen ramic.h...@gmail.com wrote: Hi, While Quantum manager may communicate with compute nodes using a quantum agent, in some cases when Quantum is integrated with Nova, the agent may not be needed (while it can be used for enhanced services). In this cases, when the Quantum VIF driver (which is part of Nova compute) is used for VM provisioning/terminating/restarting utilizing the existing Nova infrastructure, it may be required to pass parameters from the quantum manager to the Quantum driver. Nevertheless, in current Nova architecture the Nova network does not pass the values returned from the quantum Manager to the compute nodes. I really think that passing the Quantum manager values to the Quantum VIF driver is really important for Quantum agent less implementation and it is quite an easy change to make. Hi Rami, I see no problem with the vif-driver getting information returned from Quantum per-se. In fact, tr3buchet is reworking the nova/quantum integration code and as a result some values from Quantum (e.g., allocated MAC + IP address) will most definitely be passed to the vif-driver. However, I do want to make sure that the vif-plugging driver stays thin and focused primarily on connecting the vNIC to the switch. Dan RamiC ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] cfg usage - option registration, global objects
On Wed, 2012-06-06 at 15:41 -0400, Mark Washenberger wrote: Sorry if this has already been posted somewhere and I just can't find it, but is there an openstack common weekly meeting where you guys talk about your blueprints and determine what is going into common and in what form? I think I can be less disruptive if I'm involved in these discussions much earlier. We haven't been doing meetings, but there was a long thread on this a while back: https://lists.launchpad.net/openstack/msg09456.html Cheers, Mark. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal to add Tihomir Trifinov to Horizon Core
+1! On Jun 6, 2012, at 12:12 PM, Gabriel Hurley wrote: A couple of us on the Horizon team have been talking, and we'd like to recognize the tremendous work the Tihomir has been doing on Horizon for the past 6+ months by making him a member of Horizon Core. He's been writing great code, doing consistent and helpful reviews, tackling important bugs, and all around being an excellent contributor. I certainly trust his judgment at this point. I believe the official process is to propose new additions to the core teams on the mailing list, so... that's what I'm doing. All the best, - Gabriel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] How to let nova use localtime rather than UTC time?
Storage is consistent--UTC. Display to user should go through an optional layer to convert it to an end user-specified local timezone. This is part of localization (l10n) which is the complement to internationalization (i18n). Other examples of localization include number and date formatting. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Johannes Erdfelt Sent: Wednesday, June 06, 2012 1:51 PM To: openstack@lists.launchpad.net Subject: Re: [Openstack] How to let nova use localtime rather than UTC time? On Wed, Jun 06, 2012, Gabriel Hurley gabriel.hur...@nebula.com wrote: Stored timestamps should always be in UTC, however efforts should be made to support local timezones as a user-configurable option. Horizon will be working towards this goal since Django has good timezone support, I'd encourage other projects to keep this on their radar as well. I'm a little confused by your reply. You said it should always be stored in UTC, but then it should be user-configurable to use local timezones? JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Yahoo! is expanding its Virtualization Operations team!
Hey Folks, Operating one of the worlds largest unix environments, Yahoo! is beginning to embrace virtualization in a big way. We're looking to hire some awesome Senior level operations engineers to join our virtualization operations team. If you've ever wanted to be a part of what may become the worlds largest Openstack shop and sit on the bleeding edge of operationalizing Openstack; now's the time. Yahoo! is a pretty awesome place to work for, with incredible people and technology driving our business. The official version of the job description is below. It's not nearly as ass-kicky as the one I wrote, but my boss says I need to use this one. Because this version doesn't include photographs of my VP sitting on the back of a golf cart, in a Ghille suit, drinking beer, while a teammate fires a bow at pictures of moose from the back of said golf-cart. Which is moving. Like I said, Yahoo! is pretty awesome. If you're interested, please drop me a line. -James --- Sr. OpenStack/Virtualization Engineer Yahoo! is the premier digital media company. We deliver your world, your way by creating deeply personal digital experiences that keep more than half a billion people connected to what matters most - across devices and around the globe. And it's the Yahoos behind the scenes who make this all possible. We are energetic, idea-driven people who are passionate about shaping the future of the digital world. So if this sounds like you, come show us what you've got. Yahoo! Inc. is an equal opportunity employer. Key Responsibilities: *Work with Yahoo! OpenStack architecture team to deploy OpenStack and Virtualization at Yahoo!. *Assist with the development of automated OpenStack/KVM deployment solutions and distribution services. *Support and interact with customers through a combination of ticket, IM, phone and in person. *Troubleshoot OpenStack/KVM environments to resolve virtualization related issues. *Perform configuration quality checks on all virtual devices. *Establish monitoring for OpenStack services. *Work with the OpenStack community to address technical issues. Technical Skills: *At least five years of Unix systems admin experience in a large production Unix environment, RedHat preferred. *Solid network experience working with TCP/IP, VLAN's, routing, etc. Exposure to firewalls, DNS and or load balancers would be ideal. *Some practical experience in implementing, operating and troubleshooting the following: -Hypervisor configuration (KVM, XenServer, etc) (required) -Python (required) -OpenStack (should be familiar) -MySQL -Bash -Apache -Perl Intangible Assets: *A passion for virtualization technology and open cloud standards. *Experience in a role where good attention to detail was clearly demonstrated. *Motivated self-starter, who can complete work with minimal supervision. *Able to multi-task and remain effective under pressure. *Proven strong verbal and written communication, with colleagues and customers. *Willing to participate in a 24/7 on-call rotation.! ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Change user password (not admin)
Hi, There has been a first attempt at this in keystone. See https://review.openstack.org/#/c/7437/ And bug: https://bugs.launchpad.net/keystone/+bug/996922 It needs more work to make it secure though. Cheers, Sam On Thu, Jun 7, 2012 at 7:13 AM, Kiall Mac Innes ki...@managedit.ie wrote: On Wed, Jun 6, 2012 at 7:55 PM, Gabriel Hurley gabriel.hur...@nebula.com wrote: Feel free to have at it with them again. ;-) Feel free to add my +1 next time it comes up! Users being unable to change their own passwords simply seems wrong to me! Thanks, Kiall ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] 回复： Cpu Affinity with Open Stack and KVM
Libvirt supports what do you want. Openstack may not wrapper that feature. New patches in libvirt support pin hypervisor thread to PCPU through cgroup. Ben -原信息- 发自： Abhishek Gupta 发送： 2012/06/07, 01:19 收件人: openstack@lists.launchpad.net 主题： [Openstack] Cpu Affinity with Open Stack and KVM Hi, I was looking to pin the virtual cores to physical cores when using KVM as hypervisor and Open stack and cloud management system. Is there an option where I can specify this preference? Thanks, Abhishek ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Agenda for QA Status Meeting for 6/7
The weekly QA Team meeting takes place at 17:00 UTC on IRC (#openstack-meeting on Freenode). We invite anyone interested in testing, quality assurance and performance engineering to attend the weekly meeting. The agenda for this week is as follows: * Status of Swift tests (Jose) * Status of parallelization modifications (Daryl) * Outstanding code reviews -Review all outstanding code reviews in the queue: -https://review.openstack.org/#/q/status:open+project:openstack/tempest,n,z * New items for discussion - Discussion on David's resource management branch - Further thoughts on test resource management (Sam) - Expectations of Tempest execution time * Work in progress that will be landing soon - Smoke testing base classes? - Swift tests - Instance level tests for the rest of the Compute API actions * Open discussion Feel free to add to the agenda as needed. Daryl ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Yahoo! is expanding its Virtualization Operations team!
On 06/06/2012 07:08 PM, James R Penick wrote: Hey Folks, snip Check out: http://openstack.org/community/jobs/ -- Russell Bryant ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Passing parameters from Quantum manager to Nova compute
Dan, I totally agree that the driver should be thin and focus on VM provision/termination. While ii may be looked unimportant, I just prefer that the quantum manager will determine both VIF and bridge name instead of using a convention that these names are extracted from the UUID. Best Regards, RamiC On Thu, Jun 7, 2012 at 12:08 AM, Dan Wendlandt d...@nicira.com wrote: On Wed, Jun 6, 2012 at 11:35 AM, Rami Cohen ramic.h...@gmail.com wrote: Hi, While Quantum manager may communicate with compute nodes using a quantum agent, in some cases when Quantum is integrated with Nova, the agent may not be needed (while it can be used for enhanced services). In this cases, when the Quantum VIF driver (which is part of Nova compute) is used for VM provisioning/terminating/restarting utilizing the existing Nova infrastructure, it may be required to pass parameters from the quantum manager to the Quantum driver. Nevertheless, in current Nova architecture the Nova network does not pass the values returned from the quantum Manager to the compute nodes. I really think that passing the Quantum manager values to the Quantum VIF driver is really important for Quantum agent less implementation and it is quite an easy change to make. Hi Rami, I see no problem with the vif-driver getting information returned from Quantum per-se. In fact, tr3buchet is reworking the nova/quantum integration code and as a result some values from Quantum (e.g., allocated MAC + IP address) will most definitely be passed to the vif-driver. However, I do want to make sure that the vif-plugging driver stays thin and focused primarily on connecting the vNIC to the switch. Dan RamiC ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ -- RamiC™ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack-qa-team] Agenda for QA Status Meeting for 6/7
The weekly QA Team meeting takes place at 17:00 UTC on IRC (#openstack-meeting on Freenode). We invite anyone interested in testing, quality assurance and performance engineering to attend the weekly meeting. The agenda for this week is as follows: * Status of Swift tests (Jose) * Status of parallelization modifications (Daryl) * Outstanding code reviews -Review all outstanding code reviews in the queue: -https://review.openstack.org/#/q/status:open+project:openstack/tempest,n,z * New items for discussion - Discussion on David's resource management branch - Further thoughts on test resource management (Sam) - Expectations of Tempest execution time * Work in progress that will be landing soon - Smoke testing base classes? - Swift tests - Instance level tests for the rest of the Compute API actions * Open discussion Feel free to add to the agenda as needed. Daryl -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
