date:20120605

Interesting, darn, that sorta makes it harder than it seems like it should be.

Is there any pattern that we can follow for this that other programs use, do 
most other programs shell out as root, and expect there command sets to be 
restricted? Do other similar programs just assume that they are running as a 
user that won't need to be restricted? Java seems like it would have the same 
issue, but of course its threaded, I there any similar concept there of 
temporarily escalating privileges for a thread, performing some action, then 
reducing privileges? I wonder if eventlet could support something like this (or 
be modified to?). Anyone else know other ways of doing this that might be 
useful? The suggestions that involve RPC being one way.

On 6/5/12 5:35 PM, "Eric Windisch"  wrote:





On Tuesday, June 5, 2012 at 19:18 PM, Joshua Harlow wrote:


Re: [Openstack] Question on nova disk injection... Why couldn't nova just 
escalate pythons privileges to the super user when writing a file (thus 
allowing it to use python file writing functions and such).

Because we use Eventlet. os.setuid applies to the entire process. Coroutine 
switching during this would be dangerous.

Three options seem to exist:

1. We can fork, but then we'll need use IPC, which in our case would be 
implemented via the RPC abstraction.  We would need to make changes to 
services.py and/or the binaries and possibly the RPC abstraction itself.  This 
would work well with ZeroMQ as it would be actual IPC, but the brokered RPC 
solutions would be less efficient. Overall, this reeks of complexity and 
danger, but the end result should be a clear net positive.

2. One less elegant, but easy, solution might just be to extend the rootwrap 
functionality. Have it support calling commands on the system *and* executing 
trusted Python methods with trusted arguments.  We'd still be shelling out to 
rootwrap, but rootwrap could internally provide 'mkdir' and 'chmod' style 
commands around the os stdlib, rather than shelling out a second time, as it 
does currently.

3. rootwrap itself could actually be implemented as a Nova service, if we could 
trust the RPC mechanism direct access to the rootwrap methods -- which we is 
not all too safe, currently. This would effectively be a mix of options 1/2.

I'm inclined to suggest option #2 as it is a relatively simple improvement that 
would give us short-term gains without much friction. This wouldn't exclude the 
other options from being worked on and seems to be a requirement for #3, anyway.
___
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...

2012-06-05 Thread Eric Windisch

On Tuesday, June 5, 2012 at 19:18 PM, Joshua Harlow wrote:

> Re: [Openstack] Question on nova disk injection... Why couldn’t nova just 
> escalate pythons privileges to the super user when writing a file (thus 
> allowing it to use python file writing functions and such).

Because we use Eventlet. os.setuid applies to the entire process. Coroutine 
switching during this would be dangerous.

Three options seem to exist:

1. We can fork, but then we'll need use IPC, which in our case would be 
implemented via the RPC abstraction.  We would need to make changes to 
services.py and/or the binaries and possibly the RPC abstraction itself.  This 
would work well with ZeroMQ as it would be actual IPC, but the brokered RPC 
solutions would be less efficient. Overall, this reeks of complexity and 
danger, but the end result should be a clear net positive.

2. One less elegant, but easy, solution might just be to extend the rootwrap 
functionality. Have it support calling commands on the system *and* executing 
trusted Python methods with trusted arguments.  We'd still be shelling out to 
rootwrap, but rootwrap could internally provide 'mkdir' and 'chmod' style 
commands around the os stdlib, rather than shelling out a second time, as it 
does currently.

3. rootwrap itself could actually be implemented as a Nova service, if we could 
trust the RPC mechanism direct access to the rootwrap methods -- which we is 
not all too safe, currently. This would effectively be a mix of options 1/2.

I'm inclined to suggest option #2 as it is a relatively simple improvement that 
would give us short-term gains without much friction. This wouldn't exclude the 
other options from being worked on and seems to be a requirement for #3, anyway.

--  
Eric Windisch

___
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 "migrate" and "resize"

2012-06-05 Thread William Herry

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] Question on nova disk injection...

Why couldn't nova just escalate pythons privileges to the super user when 
writing a file (thus allowing it to use python file writing functions and such).

Then after it writes it could drop it back to down to some other user?

That might make sense, idk, instead of having the disk injection act like a 
shell script which basically just emits a bunch of [tee, mv, touch, mkdir, cp] 
commands.

I've done something like this for anvil, not sure if its useful here but who 
knows:

https://github.com/yahoo/Openstack-Anvil/blob/master/anvil/shell.py#L70

On 6/5/12 2:50 PM, "Russell Bryant"  wrote:

On 06/05/2012 05:42 PM, Joshua Harlow wrote:
> Hi all,
>
> Just some questions that I had about how nova is doing disk injection
> and such.
>
> I was noticing that it the main disk/api.py does a lot of tee, cat and
> similar commands. Is there any reason it couldn't just use the standard
> python open and write data and such.
>
> Is it because of sudo access (which is connected to rootwrap?), just
> wondering since it seems sort of odd that to write a file there a tee
> call has to be done with piped input, when python already has file
> operators and such...

Yes, if it is using run_as_root=True, then it has to be run with
nova-rootwrap.

--
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

___
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] [Cinder] Weekly meeting reminder

2012-06-05 Thread John Griffith

Just a reminder, our weekly meeting will take place tomorrow (Wed, June 6)
at 16:00 UTC.

Agenda:
* status update
* outstanding items for F2
* outstanding reviews
* unassigned blueprints
* open discussion

Thanks,
John

___
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] Essex: LXC volume attachment does not work?

2012-06-05 Thread David Kang


 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  nbd7  
  oldmem  ram11  ram5rtc   sg2  shm   tty0   tty16  tty23  tty30  
tty38  tty45  tty52  tty6   ttyS0usbmon3  vcs2   vcsa3zero
bsg  disk   fuse   kvmloop6mcelog  nbd14  nbd8  
  portram12  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  stderrtty11  tty19  tty26  tty33  
tty40  tty48  tty55  tty62  ttyS3usbmon6  vcs5   vcsa6
console  dm-2   hidraw1loop1  lp1  nbd1nbd3   
network_latency pts ram15  ram9sdb   sg6  stdin tty12  tty2   
tty27  tty34  tty41  tty49  tty56  tty63  urandom  usbmon7  vcs6   vdc
core fb hugepages  loop2  lp2  nbd10   nbd4   
network_throughput  ram0ram2   random  sdb1  sg7  stdouttty13  tty20  
tty28  tty35  tty42  tty5   tty57  tty7   usbmon0  usbmon8  vcsa   vga_arbiter
cpu  fb0hvc0   loop3  lp3  nbd11   nbd5   null  
  ram1ram3   raw sg0   sg8  systtytty14  tty21  tty29  tty36  
tty43  tty50  tty58  tty8   usbmon1  vcs  vcsa1  vhost-net
cpu_dma_latency  fd input  loop4  MAKEDEV  nbd12   nbd6   nvram 
  ram10   ram4   rootsg1   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

Re: [Openstack] Question on nova disk injection...

2012-06-05 Thread Russell Bryant

On 06/05/2012 05:42 PM, Joshua Harlow wrote:
> Hi all,
> 
> Just some questions that I had about how nova is doing disk injection
> and such.
> 
> I was noticing that it the main disk/api.py does a lot of tee, cat and
> similar commands. Is there any reason it couldn’t just use the standard
> python open and write data and such.
> 
> Is it because of sudo access (which is connected to rootwrap?), just
> wondering since it seems sort of odd that to write a file there a tee
> call has to be done with piped input, when python already has file
> operators and such...

Yes, if it is using run_as_root=True, then it has to be run with
nova-rootwrap.

-- 
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] cfg usage - option registration, global objects

2012-06-05 Thread Russell Bryant

On 06/05/2012 05:35 PM, Russell Bryant wrote:
> On 06/05/2012 05:25 PM, Mark Washenberger wrote:
>>
>>
>> "Mark McLoughlin"  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. 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.
> 
> That all sounds nice in theory, but like you alluded to here, who
> specifically is going to sign up to do that?  I can finish the move of
> the current code (I have it ready to propose, actually), but I have
> other things I should work on after that.
> 
> How about the stakeholders interested in using this code in other
> projects?  Do you want the current code in now (with the likelihood of
> having to adapt to some API changes later), or would you like to get
> together and work on something new?  If so, I'll just toss the proposal
> of the current code for common and let someone else drive the new thing
> in instead.
> 

By the way, the move of the current code is "ready" if we agree to
proceed with it:

https://review.openstack.org/#/c/8206/

-- 
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

[Openstack] Question on nova disk injection...

Hi all,

Just some questions that I had about how nova is doing disk injection and such.

I was noticing that it the main disk/api.py does a lot of tee, cat and similar 
commands. Is there any reason it couldn't just use the standard python open and 
write data and such.

Is it because of sudo access (which is connected to rootwrap?), just wondering 
since it seems sort of odd that to write a file there a tee call has to be done 
with piped input, when python already has file operators and such...

Thx!
___
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

2012-06-05 Thread Russell Bryant

On 06/05/2012 05:25 PM, Mark Washenberger wrote:
> 
> 
> "Mark McLoughlin"  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. 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.

That all sounds nice in theory, but like you alluded to here, who
specifically is going to sign up to do that?  I can finish the move of
the current code (I have it ready to propose, actually), but I have
other things I should work on after that.

How about the stakeholders interested in using this code in other
projects?  Do you want the current code in now (with the likelihood of
having to adapt to some API changes later), or would you like to get
together and work on something new?  If so, I'll just toss the proposal
of the current code for common and let someone else drive the new thing
in instead.

-- 
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] cfg usage - option registration, global objects

2012-06-05 Thread Mark Washenberger

"Mark McLoughlin"  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. 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.

Respectfully,
markwash

___
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] Forking an OpenStack project to remotely save changes

On Tue, 2012-06-05 at 14:43 -0600, Everett Toews wrote:
> Hi All,
> 
> If you have a relatively long-lived topic branch, what's the best way to
> remotely save changes?
> 
> If you wanted to fork an OpenStack project on github, it would work
> something like:
> 
> 1. Fork the project on github.com to your own account
> 2. Clone the project locally
> 3. Add a remote branch to your local repo that points to the origin project
> repo you forked from
> 4. Create a remote branch for gerrit
> 5. Create a branch for your changes in the forked project
> 6. Commit and push your changes to your branch
> 7. When your branch is ready for review:
> a. pull from origin
> b. rebase your changes to the current state of the master
> 8. git review
> 
> I've done steps 1-6 working but I can't easily test 7 & 8 without sending
> in unnecessary changes for review. But if you lost your changes, you would
> just clone your forked project again.

What I do is:

  1) Clone from github.com/openstack/${project}

  2) Click "fork" on $project on github

  3) Add my fork as a remote to my local repo:

   $> git remote add -f github g...@github.com:markmc/${project}.git

  4) Create my topic branch, hack commit my changes

  5) Push to my forked repo:

   $> git push github HEAD:${topic}

  5) Hack, commit more changes, then clean up the series of patches 
 using 'rebase -i'

   $> git rebase -i origin/master

 this might involve rebasing onto latest upstream, squashing fixes
 into an earlier patch, re-ordering changes, editing commit messages

  6) Push to my forked repo either as a new branch if I worry that 
 others might have based their work on my first branch:

   $> git push github HEAD:${topic}-v2

 or, more usually, just push to the same branch:

   $> git push github +HEAD:${topic}

 (the '+' allows me to do a non-fast-forward push)

  7) When I'm done, submit it with git-review


I'm guessing the details of (5) and (6) is what you're missing?

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] Forking an OpenStack project to remotely save changes

2012-06-05 Thread Everett Toews

Hi All,

If you have a relatively long-lived topic branch, what's the best way to
remotely save changes?

If you wanted to fork an OpenStack project on github, it would work
something like:

1. Fork the project on github.com to your own account
2. Clone the project locally
3. Add a remote branch to your local repo that points to the origin project
repo you forked from
4. Create a remote branch for gerrit
5. Create a branch for your changes in the forked project
6. Commit and push your changes to your branch
7. When your branch is ready for review:
a. pull from origin
b. rebase your changes to the current state of the master
8. git review

I've done steps 1-6 working but I can't easily test 7 & 8 without sending
in unnecessary changes for review. But if you lost your changes, you would
just clone your forked project again.

Is this viable? Is this a reasonable way to remotely save changes?

One alternative would be to continually save changes using review drafts
with "git review -D". In this case if you lost your changes, you would have
to clone the origin project and then fetch the changes from gerrit.

Is this viable?

How are other people solving this problem?

Thanks,
Everett
___
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] Swift API - Differences between API docs and code

2012-06-05 Thread Anne Gentle

Ah, great question Adrian. Ideally the PTL and I work together to
identify a resource to update the API guide prior to the release going
out. John and I spoke early on in the Folsom release timeframe about
potential API changes but then we didn't connect the dots that the
1.5.0 release needs API doc changes. Thanks for bringing it up.

The source for the API guides are housed in separate repos, in this
case it's at:

http://github.com/openstack/object-api

Anne

On Tue, Jun 5, 2012 at 2:18 PM, Adrian Smith  wrote:
> I've been digging about in the Swift codebase recently and I've come
> across a few few features that aren't documented in the API docs. For
> example, metadata at the account level, "prefix" parameter at the
> account level, "end_marker" parameter, object versioning (new in
> 1.5.0). These are just a few. I'm sure there are other examples.
> Should these features be included in the API docs (perhaps v2.0) or
> were they purposely left out? Obviously the code will continue to
> evolve but I'm curious what the situation is regarding the
> documentation.
>
> On a related note, where can I find the docbook source used to
> generate the Swift API documentation,
> http://docs.openstack.org/api/openstack-object-storage/1.0/content/index.html.
> I've looked around in the openstack-manuals project but can't seem to
> find anything.
>
> Thanks
>
> Adrian
>
> ___
> 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] Trying to set up Quantum in Devstack

Thanks to all who responded. Was doing some tempest fixups that required 
a non-Quantum env yesterday, but I will get on with the proposed fixes 
to this today.


All the best,
jay

On 06/04/2012 01:04 PM, Dan Wendlandt wrote:



On Mon, Jun 4, 2012 at 9:30 AM, Takahiro Shida mailto:sh...@intellilink.co.jp>> wrote:

Hi jay,

I think, 'quantum' in ENABLED_SERVICES means quantum client.


This is close, but not completely correct. 'quantum' actually refers to
installing the quantum python server and client libraries and binaries,
without running any of the binaries.  This can be useful if, for
example, you have a host that needs to have the quantum client library
installed, but will not actually be running the quantum service (q-svc)
or a quantum agent (q-agt).  However, the name is confusing, so perhaps
we should change it.

So, you should add the q-svc in localrc.

ENABLED_SERVICES+=ENABLED___SERVICES,tempest,quantum,q-svc


Yes, and if you're doing a single-node setup where nova is running on
the same host, you'll want q-agt as well.

Dan


Best Regards,
- Takahiro Shida


(2012/06/05 1:14), Jay Pipes wrote:

Hey Stackers,

Trying to get Tempest + Quantum functional integrationt tests
running locally and am running into some issues. Hoping to get
some assistance.

I added this to my localrc:

ENABLED_SERVICES+=ENABLED___SERVICES,tempest,quantum

Cleared my /opt/stack to get a fully fresh pull of all services
in devstack, but when I run stack.sh, I get the following:

http://paste.openstack.org/__show/18331/


Is this just a simple configuration issue I've messed up? Any
help appreciated!

best,
-jay

_
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





--
~~~
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


___
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] Swift API - Differences between API docs and code

2012-06-05 Thread Adrian Smith

I've been digging about in the Swift codebase recently and I've come
across a few few features that aren't documented in the API docs. For
example, metadata at the account level, "prefix" parameter at the
account level, "end_marker" parameter, object versioning (new in
1.5.0). These are just a few. I'm sure there are other examples.
Should these features be included in the API docs (perhaps v2.0) or
were they purposely left out? Obviously the code will continue to
evolve but I'm curious what the situation is regarding the
documentation.

On a related note, where can I find the docbook source used to
generate the Swift API documentation,
http://docs.openstack.org/api/openstack-object-storage/1.0/content/index.html.
I've looked around in the openstack-manuals project but can't seem to
find anything.

Thanks

Adrian

___
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] Swift on WebOb 1.2

2012-06-05 Thread Pete Zaitcev

I just saw your change uploaded
 https://review.openstack.org/8195/

Thanks a lot! I'll have a look and review ASAP.

-- Pete

On Mon, 4 Jun 2012 14:40:21 +0900
iryoung jeong  wrote:

> Anyway, current status is that I make your PatchSet 3 passed all
> unit/functests with webob 1.1 and only 4 tests failed with webob 1.2b3.

___
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

2012-06-05 Thread Doug Hellmann

On Tue, Jun 5, 2012 at 12:59 PM, Nick Barcet wrote:

> On 06/05/2012 04:44 PM, Doug Hellmann wrote:
> > On Tue, Jun 5, 2012 at 10:41 AM, Doug Hellmann
> > mailto:doug.hellm...@dreamhost.com>>
> wrote:
> > On Tue, Jun 5, 2012 at 9:56 AM, Nick Barcet
> > 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?


>
> > 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 would be easier :)
>

Yeah, I think a regular RPC call would be the easiest implementation. So we
still need to specify the arguments to that call, but we don't have to
worry about how the messages travel back and forth.


>
> > Where ConfigDefault are the "sane" default proposed by the agent
> > authors.
> >
> >
> > Why is the agent proposing default settings?
>
> So that the first agent of a given type can populate its info with sane
> defaults that can then be edited later on?
>

If the agent plugins are installed on the server where the collector is
located, the collector can ask them for defaults.


>

Re: [Openstack] Quotas... 1 of 1 instances? What's the deal?


On 06/05/2012 01:31 PM, Kevin L. Mitchell wrote:

As I say, what's supposed to happen is that quotas are checked and
reservations created in one transaction; then you create the appropriate
database entries, and once that's done, you commit the reservations, at
which point "reserved" should revert to zero.  That this hasn't happened
is a clear indication of a bug.


Yup, so I think I've found it. Bug created:

https://bugs.launchpad.net/nova/+bug/1009115

Best,
-jay

___
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!!!

2012-06-05 Thread Từ Minh Mẫn

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  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  wrote:
>
>> 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  wrote:
>>
>>> 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  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  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  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 wrote:
>
>> 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  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  wrote:
>>>
 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=server&bits=32&release=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 
 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 
> wrote:
>
>> Yes sorry,
>> my question was intended to Từ Minh Mẫn  :-)
>>
>>
>>   Michael Pittaro 
>>  28 mai 2012 01:41
>> It's really a matter of which Linux distro you prefer (or know
>> better) - the OpenStack pieces are the same everywhere.  I 
>> personally work
>> with both Ubuntu _and_ Fedora regularly - but as long as I can run 
>> vim and
>> lxde, I'm usually happy with the environment. It's all Linux, after 
>> all.
>>
>> I tend to use Ubuntu for openstack development work since the
>> devstack.py toolchain favoured that initially, but I also run Fedora 
>> on
>> other machines.
>>
>> mike
>>
>>
>>   Michael Pittaro 
>>  27 mai 2012 19:00
>> On Fri, May 25, 2012 at 12:20 AM, Razique Mahroua
>>
>> The wiki page http://wiki.openstack.org/GetOpenStack lists many
>> of the
>> sources for OpenStack, and there are many links to distribution
>> specific install guides.
>>
>>>

[Openstack] Nova "migrate" and "resize"

2012-06-05 Thread Belmiro Moreira


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

Re: [Openstack] What does "nova migrate" do, exactly?

2012-06-05 Thread Belmiro Moreira


Hi,
The host is selected by the scheduler.

Belmiro

On 05-06-2012 17:40, Florian Haas wrote:

On 06/05/12 17:27, Vishvananda Ishaya wrote:

No, migrate does "dead" migration on a server.  Essentially snapshots the drive 
transfers it to a new server and reboots.  Migrate and live-migration do need to be 
consolidated.


Um, OK. How do I specify where to migrate to?

nova help migrate
usage: nova migrate [--poll]

Migrate a server.

Positional arguments:
  Name or ID of server.

Optional arguments:
   --pollBlocks while instance migrates so progress can be reported.

Slightly confused. :)

Cheers,
Florian

___
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] Parallel execution of Jenkins gate jobs

2012-06-05 Thread James E. Blair

Hi,

We have just changed the way Jenkins jobs are triggered for Gerrit
changes. This is another in a series of changes we're rolling out
based on needs described at the design summit.

We had been using the Gerrit Trigger Plugin to launch check and gate
jobs, but we're starting to run up against some scalability limits.
As we process more changes, and the tests for those changes get
longer, Jenkins was started to build up significant queues at times.
If we were to start gating on Tempest, Jenkins may just end up running
continuously, with long delays between approval and merging of
changes.

We have switched to a new system called Zuul, which is a python daemon
that watches the Gerrit event stream and triggers Jenkins jobs. Zuul
is extremely flexible, but its main advantage is that it will allow us
to perform speculative execution of Jenkins jobs. The general idea is
that most Jenkins jobs succeed, and as long as that is the case, we
can execute gate tests with those jobs in parallel. If they all
succeed, a large number of changes can be quickly merged.

Another change is that it is easy for us to construct job decision
trees and report that information meaningfully to Gerrit. This way we
can avoid wasting time running unit tests on changes that don't even
merge successfully

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.

We've been using Zuul for about a week to run testing for some of the
CI repositories. We think it's ready to run at scale, but there are
bound to be a few hiccups, and we'll try to get them fixed as quickly
as possible. I think being able to test and merge changes in parallel
will be a huge win, and we'll be able to do some cool things in the
future with the additional flexibility this brings.

For more details on the theory of operation, see:

http://amo-probos.org/post/14

or the project itself:

https://launchpad.net/zuul
https://github.com/openstack-ci/zuul

or the configuration file:

https://github.com/openstack/openstack-ci-puppet/blob/master/modules/openstack-ci-config/files/zuul/layout.yaml

As usual, everything is in git, and anyone can help contribute to this
effort.

-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] depend discrepancies

+100 for a list.

Please feel free to use something like what anvil has...

https://github.com/yahoo/Openstack-Anvil/blob/master/conf/distros/ubuntu-oneiric.yaml#L64

Or a subset...

On 6/5/12 8:52 AM, "Monty Taylor"  wrote:

Hey guys!

One of the things that came out of ODS is the idea of having a single
global dependency list. There are two bits to that - the mechanics of
managing the list (which I think we may have sorted) and then, you know,
making the list. In compiling the list of what the current global list
is, most of the things have clear and obvious answers. However, there
are three problematic deps: kombu, PasteDeploy and xattr. Here's what we
have for them:

./melange/tools/pip-requires:kombu==1.5.1
./glance/tools/pip-requires:kombu
./nova/tools/pip-requires:kombu==1.0.4
./cinder/tools/pip-requires:kombu==1.0.4

./keystone/tools/pip-requires:PasteDeploy
./melange/tools/pip-requires:PasteDeploy
./quantum/tools/pip-requires:PasteDeploy==1.5.0
./glance/tools/pip-requires:PasteDeploy
./nova/tools/pip-requires:PasteDeploy==1.5.0
./swift/tools/pip-requires:pastedeploy==1.3.3
./cinder/tools/pip-requires:PasteDeploy==1.5.0

./glance/tools/pip-requires:xattr>=0.6.0
./swift/tools/pip-requires:xattr==0.4

I have no personal emotions towards any of these versions ... but if
folks who matter could make some call on what they _should_ be, we can
move forward with the first step.

I should point out that at the moment we're looking at using update.py
from openstack-common to copy in the relevant depends from the master
list - so a project will only get the ones it needs. It also means that
a decision on a version here does not mean that everyone needs to move
to that version immediately ... just that we should be moving towards
supporting those versions before folsom, really.

Anywhoo... thoughts?

Monty

___
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] Libguestfs weirdness??

Ok, so part of the findings here is that when that flag is not enabled, it 
seems like the resize2fs and commands that run on the image file beforehand 
might actually screw up the image file (if it is qcow2). Has anyone tried this 
flag with a false value and used qcow2 images. Is there a patch to ubuntus 
resize2fs that makes it work with qcow2 images. I don't see how this could have 
worked without something like that previously (if ever).

It seems like the right way forward is to use libguestfs resize (which requires 
disk images to have a partition).

On 6/4/12 10:12 AM, "Joshua Harlow"  wrote:

Hi all,

I was wondering if there has been anyone else who has used this flag with 
libguestfs (on RH 6.2) that has noticed file sync issues.

force_raw_images=true

I have been turning that to false so that images need not be expanded for 
actual usage (it seems this only affects the base images in _base) but when 
turning that to false and when file injection occurs, it seems that the files 
get written (I've added os.listdir and such for debugging) but when unmounted 
and later that image is started it seems like those files either do not get 
synced back to the image (I even added a manual 'sync' call) or there is some 
other corruption that happens that causes those images to not contain those 
files when started (for reference I am using qcow2 files).

Has anyone else seen this type of issue?
It seems when it is set to true it is not a problem, but when it isn't then 
some weirdness happens

-Josh
___
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] Quotas... 1 of 1 instances? What's the deal?

2012-06-05 Thread Kevin L. Mitchell

On Tue, 2012-06-05 at 13:03 -0400, Jay Pipes wrote:
> On 06/04/2012 05:43 PM, Kevin L. Mitchell wrote:
> > One thing to check is the total quotas on memory and disk, relative to
> > the size of the instance.  The original code computes a maximum number
> > of instances based on those values; my new code simply tries to emulate
> > that computation.  (I'm pretty sure I got it right, but honestly quotas
> > needs further rototillings…)
> 
> Total is 24G and 12 cores available on box, so no probs there...

Available on the box, or available in your quotas?

> > Hmmm…when quiesced, you should only see reservations if instances are
> > actively building.  (In fact, reservations should be committed as soon
> > as the instances are created in the database.)  It's possible that I
> > missed places where instances are created, but I thought I got them all…
> 
> OK, so I checked again this morning and I'm still seeing the project 
> beginning with 287 above (the demo tenant) having 10 reserved, no 
> in_use, and a NULL until_refresh column. When is this quiescience point 
> supposed to come?

As I say, what's supposed to happen is that quotas are checked and
reservations created in one transaction; then you create the appropriate
database entries, and once that's done, you commit the reservations, at
which point "reserved" should revert to zero.  That this hasn't happened
is a clear indication of a bug.

Reservations expire, by default, after 24 hours (86400 seconds), and
that should also cause "reserved" to go to zero.  Check your
reservations table and see if the reservations tally up correctly, and
see if they've expired?  They should be expired by a periodic task on
the scheduler…

> When I check the instances table for that project_id, look what pops up:
> 
> mysql> select vm_state, task_state, count(*) as num from instances where 
> project_id = '287a92da0cf14a27a43c8737417b029d' group by vm_state, 
> task_state;
> +--++-+
> | vm_state | task_state | num |
> +--++-+
> | building | scheduling |   5 |
> | deleted  | NULL   |  68 |
> +--++-+
> 2 rows in set (0.00 sec)

So, only 5 instances, but they don't show up in "nova list"?  *boggle*

> I'm restarting my devstack + tempest runs with SCREEN_LOGDIR set so I 
> can track what's happening in the scheduler to leave the instances in 
> scheduling state. But clearly, something is haywire with either:
> 
>   * The error handling in how quotas are calculated (since by the DB, 
> there are only 5 out of the 10 quota-limited instances known to be 
> "scheduling"
>   * The reservation system is not freeing up resources after some amount 
> of time? Is there a configuration option for setting the expiration time 
> for reservations?

The expiration time on reservations is set using the reservation_expire
configuration option.  As mentioned, it defaults to 86400 seconds, and
the scheduler's _expire_reservations() periodic task is supposed to
trigger the reservation expiration.

(And I'm all for finding out what I missed and getting it fixed!)
-- 
Kevin L. Mitchell 


___
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] Websocket support long term


Thanks for the elaboration, Adam, appreciated. :)

Best,
-jay

On 06/04/2012 12:16 PM, Adam Young wrote:

On 06/04/2012 09:55 AM, Jay Pipes wrote:

On 05/30/2012 09:28 PM, Adam Young wrote:

The recent discussion about node.js made me rethink the state of
Websocket support for Apache and Openstack. A quick recap:

1) neither mod_wsgi nor mod_proxy support Web sockets.
2) There is a Websocket Module for Apache, but using it requires an
additional apache module.
3) There is websocket support in Eventlet.
4) The argument for node.js is the same for Eventlet: rapid dispatch to
support a large number of connections
5) noVNC currently uses websockify, and uses a simplistic web server to
proxy over VNC traffic.

The more I think about it, the more I think that the simplest, and most
correct path forward is to use the websocket Apache module, and to write
an additional module that will hook it up to Eventlet. Eventlet can
listen on a local Port (127.0.0.1 only) and Apache will map that to a
suburl. I'll code name it mod_websocket_proxy for now.




Adam, other than the NoVNC piece in Nova and the Horizon project in
general, where do you see the need for Websockets in OpenStack? I
could easily be mistaken (happens a lot!), but I see Websockets as a
great tool for client-side and UI interaction, and not so much useful
in the eventlet servers that we use for so many OpenStack services
(nova-api, swift-proxy, glance-api, glance-registry, keystone-api,
etc). Could you elaborate how you see Websockets (and your proposed
mod_websocket_proxy) being useful to OpenStack services outside of
horizon and noVNC?


Jay,

This is predominantly for Horizon. For other communication, I think AMQP
suffices, but we might want to revisit that assumption in the future.

I think that demand for Websockets is what is driving the push toward
Node.js. It is a natural complement to an event driven webserver.

While I think the quetion of noVNC itself justifies investigating
Websocket approaches, I can see the need for Websocket style development
where:

1. We need to traverse firewalls
2. We need the application to predominantly post data to the browser

Thus far we would otherwise choose AMQP for notifications, but it
doesn't seem to be the right solution for these cases. So, what are
these cases?

Log streaming seems to be the first case: a long running task generating
a lot of events, and a user wants to track what is happening as quickly
as they occur. This covers a lot of use cases.










Thanks!
-jay


___
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] cfg usage - option registration, global objects

2012-06-05 Thread Duncan McGreggor

On Tue, Jun 5, 2012 at 1:00 PM, Mark McLoughlin  wrote:
> On Tue, 2012-06-05 at 12:48 -0400, Duncan McGreggor wrote:
>> +1 :-)
>
> In all seriousness - Mark made two separate points. Which one are you
> top-posting a +1 to?

Ah, sorry -- I'll be more explicit. Condensing my previous comments:
if globals are in fact going to be used, I'm 100% in favor of a
solution that defines an API around the use of globals such that there
is a canonical way to access them and the proper means of accessing
them is well documented in the various functions/methods that provide
such access :-)

d

>> On Fri, Jun 1, 2012 at 10:37 AM, Mark Washenberger
>>  wrote:
>> > Hi Mark,
>> >
>> > Please forgive the top-posting! I always get way too wordy with
>> > inline replies.
>
> 
>
>> > Regarding configuration, I think there is another option I'd like us
>> > to adopt. We should implement the code as in your option #1, but then
>> > implement convenience factories that give the appearance of option #3
>> > or #2, or both, you pick. From your examples it might look something
>> > like this:
>> >
>> >    class Connection(object):
>> >
>> >        def __init__(self, broker_hostname, broker_port):
>> >            self.cnx = self.connect(broker_hostname, broker_port)
>> >
>> >        def cast(self, topic, msg):
>> >            self.cnx.cast(topic, msg)
>> >
>> >    def connection_from_global_conf():
>> >        return Connection(CONF.broker_hostname, CONF.broker_port)
>> >
>> > I think its pretty necessary that we don't do option #3 directly.
>> > There are some important use cases to consider, like migrating from
>> > one rpc implementation to another where you might want an adapter
>> > that can relay messages from one to the other. Also, cells with
>> > kombu at least requires that one process be able to talk to multiple
>> > brokers.
>
> 
>
> 
>
>> > Regarding incubation, I suppose I am confused. At what point during
>> > incubation do other projects start to use the shared library? I would
>> > imagine the answer to be "after incubation" but it sounds like there
>> > are several projects very eager to adopt rpc as soon as it lands in
>> > openstack common, even before incubation is complete.
>> >
>> > If incubation happens before the calcifying effects of shared use
>> > set in, then it sounds like a great place to address the other
>> > rpc-specific concerns we've talked about. Otherwise I guess we're
>> > stuck where I thought we were, where the bar needs to be set pretty
>> > high to initially land in os-common.
>
> 
>
> 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] Quotas... 1 of 1 instances? What's the deal?


On 06/04/2012 05:43 PM, Kevin L. Mitchell wrote:

One thing to check is the total quotas on memory and disk, relative to
the size of the instance.  The original code computes a maximum number
of instances based on those values; my new code simply tries to emulate
that computation.  (I'm pretty sure I got it right, but honestly quotas
needs further rototillings…)


Total is 24G and 12 cores available on box, so no probs there...


When I check the DB, though, I've seeing the following:

mysql>  select project_id, in_use, reserved, until_refresh from
quota_usages where resource = 'instances';
+--++--+---+
| project_id   | in_use | reserved | until_refresh |
+--++--+---+
| 287a92da0cf14a27a43c8737417b029d |  0 |   10 |  NULL |
| f0c72dea9fda459aac64de460300e1ec |  0 |2 |  NULL |
+--++--+---+
2 rows in set (0.00 sec)


Hmmm…when quiesced, you should only see reservations if instances are
actively building.  (In fact, reservations should be committed as soon
as the instances are created in the database.)  It's possible that I
missed places where instances are created, but I thought I got them all…


OK, so I checked again this morning and I'm still seeing the project 
beginning with 287 above (the demo tenant) having 10 reserved, no 
in_use, and a NULL until_refresh column. When is this quiescience point 
supposed to come?


When I check the instances table for that project_id, look what pops up:

mysql> select vm_state, task_state, count(*) as num from instances where 
project_id = '287a92da0cf14a27a43c8737417b029d' group by vm_state, 
task_state;

+--++-+
| vm_state | task_state | num |
+--++-+
| building | scheduling |   5 |
| deleted  | NULL   |  68 |
+--++-+
2 rows in set (0.00 sec)

Unfortunately, when logged into the Horizon control panel for the Demo 
project, the Instances and Volumes tab shows absolutely nothing.


When doing a nova list, here's what pops up:

jpipes@uberbox:~/repos/tempest$ nova list
++--++--+
| ID | Name | Status | Networks |
++--++--+
++--++--+

I'm restarting my devstack + tempest runs with SCREEN_LOGDIR set so I 
can track what's happening in the scheduler to leave the instances in 
scheduling state. But clearly, something is haywire with either:


 * The error handling in how quotas are calculated (since by the DB, 
there are only 5 out of the 10 quota-limited instances known to be 
"scheduling"
 * The reservation system is not freeing up resources after some amount 
of time? Is there a configuration option for setting the expiration time 
for reservations?


Best,
-jay

___
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 Tue, 2012-06-05 at 12:48 -0400, Duncan McGreggor wrote:
> +1 :-)

In all seriousness - Mark made two separate points. Which one are you
top-posting a +1 to?

> On Fri, Jun 1, 2012 at 10:37 AM, Mark Washenberger
>  wrote:
> > Hi Mark,
> >
> > Please forgive the top-posting! I always get way too wordy with
> > inline replies.



> > Regarding configuration, I think there is another option I'd like us
> > to adopt. We should implement the code as in your option #1, but then
> > implement convenience factories that give the appearance of option #3
> > or #2, or both, you pick. From your examples it might look something
> > like this:
> >
> >class Connection(object):
> >
> >def __init__(self, broker_hostname, broker_port):
> >self.cnx = self.connect(broker_hostname, broker_port)
> >
> >def cast(self, topic, msg):
> >self.cnx.cast(topic, msg)
> >
> >def connection_from_global_conf():
> >return Connection(CONF.broker_hostname, CONF.broker_port)
> >
> > I think its pretty necessary that we don't do option #3 directly.
> > There are some important use cases to consider, like migrating from
> > one rpc implementation to another where you might want an adapter
> > that can relay messages from one to the other. Also, cells with
> > kombu at least requires that one process be able to talk to multiple
> > brokers.





> > Regarding incubation, I suppose I am confused. At what point during
> > incubation do other projects start to use the shared library? I would
> > imagine the answer to be "after incubation" but it sounds like there
> > are several projects very eager to adopt rpc as soon as it lands in
> > openstack common, even before incubation is complete.
> >
> > If incubation happens before the calcifying effects of shared use
> > set in, then it sounds like a great place to address the other
> > rpc-specific concerns we've talked about. Otherwise I guess we're
> > stuck where I thought we were, where the bar needs to be set pretty
> > high to initially land in os-common.



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] [Metering] Agent configuration mechanism

2012-06-05 Thread Nick Barcet

On 06/05/2012 04:44 PM, Doug Hellmann wrote:
> On Tue, Jun 5, 2012 at 10:41 AM, Doug Hellmann
> mailto:doug.hellm...@dreamhost.com>> wrote:
> On Tue, Jun 5, 2012 at 9:56 AM, Nick Barcet
> 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.

> 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 would be easier :)

> Where ConfigDefault are the "sane" default proposed by the agent
> authors.
> 
> 
> Why is the agent proposing default settings?

So that the first agent of a given type can populate its info with sane
defaults that can then be edited later on?

> If no config record is found the collector creates the record, sets
> ConfVers to 1 and sends back a normal reply.
> 
> Reply sent by the collector:
>'correlation_id': x
>'version': '1.0',
> 
> 
> Do we need minor versions for the config settings, or are those
> simple sequence numbers to track which settings are the "most current"?

Simple sequence was what I was thinking about.

>'args': {'data': {
>   'Result': result.code,
>   'ConfVers': ConfVers,
>   'Config': Config,
>   },
>},
>}
> 
> Result is set as follow:
>200  -> Config was retrieved successfully
>201  -> Config was created based on received default (Config
> is empty)
>

Re: [Openstack] cfg usage - option registration, global objects

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. The alternative is that you don't make backwards
incompatible API changes.

> If so, how is the incubation process supposed to make things better in
> terms of my concerns about nova.rpc?
> 
> I just want to be able to make improvements to some of our programming
> practices without having to have a deep involvement with every
> openstack project. As a corporate sponsored developer, every extra bit
> of work I have to add in to a cleanup / technical debt / programming
> style task makes it harder to convince people to let me work on it
> during work hours. Every strategy I can think of to work around this
> extra difficulty would potentially run afoul of your pursuit of code
> conformity and reuse. That's why I keep pushing back on os-common.

I don't really follow.

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?

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] cfg usage - option registration, global objects

2012-06-05 Thread Duncan McGreggor

+1 :-)

d

On Fri, Jun 1, 2012 at 10:37 AM, Mark Washenberger
 wrote:
> Hi Mark,
>
> Please forgive the top-posting! I always get way too wordy with
> inline replies.
>
> Regarding configuration, I think there is another option I'd like us
> to adopt. We should implement the code as in your option #1, but then
> implement convenience factories that give the appearance of option #3
> or #2, or both, you pick. From your examples it might look something
> like this:
>
>    class Connection(object):
>
>        def __init__(self, broker_hostname, broker_port):
>            self.cnx = self.connect(broker_hostname, broker_port)
>
>        def cast(self, topic, msg):
>            self.cnx.cast(topic, msg)
>
>    def connection_from_global_conf():
>        return Connection(CONF.broker_hostname, CONF.broker_port)
>
> I think its pretty necessary that we don't do option #3 directly.
> There are some important use cases to consider, like migrating from
> one rpc implementation to another where you might want an adapter
> that can relay messages from one to the other. Also, cells with
> kombu at least requires that one process be able to talk to multiple
> brokers.
>
> Regarding incubation, I suppose I am confused. At what point during
> incubation do other projects start to use the shared library? I would
> imagine the answer to be "after incubation" but it sounds like there
> are several projects very eager to adopt rpc as soon as it lands in
> openstack common, even before incubation is complete.
>
> If incubation happens before the calcifying effects of shared use
> set in, then it sounds like a great place to address the other
> rpc-specific concerns we've talked about. Otherwise I guess we're
> stuck where I thought we were, where the bar needs to be set pretty
> high to initially land in os-common.
>
> "Mark McLoughlin"  said:
>
>> Hi Mark,
>>
>> On Thu, 2012-05-31 at 10:48 -0400, Mark Washenberger wrote:
>>>
>>> "Jay Pipes"  said:
>>> > On 05/29/2012 04:04 AM, Mark McLoughlin wrote:
>>> >> Adopting this pattern across all projects will actually help
>>> >> openstack-common more generally. For example, Russell is moving the RPC
>>> >> code into openstack-common and it has a bunch of configuration options.
>>> >> If it can assume a global configuration object, things become much
>>> >> easier.
>>> >
>>> > Unfortunately, what this leads to is interdependencies between the
>>> > openstack-common-rpc code and the openstack-common-cfg code. :( Now, if
>>> > someone wants to use the openstack RPC code in their own project, they
>>> > have to switch their way of configuring stuff to use global config
>>> > objects. Tight coupling means less adherence to the "do one thing and do
>>> > it well" mantra of *nix utilities and libraries and in general isn't
>>> > good software design.
>>>
>>>
>>> I personally would consider a rigid connection between the rpc library and
>>> the configuration to be inappropriate in the context of openstack common.
>>
>> This is a fairly general design question for openstack-common.
>>
>> If the behaviour of any given API should be dependent on the
>> configuration of the service (i.e. in nova.conf, glance-api.conf,
>> keystone.conf), then how should we design the API to handle that?
>>
>> Three options:
>>
>>   1) The API knows nothing about cfg:
>>
>>      class Connection(object):
>>
>>          def __init__(self, broker_hostname, broker_port):
>>              self.cnx = self.connect(broker_hostname, broker_port)
>>
>>          def cast(self, topic, msg):
>>              self.cnx.cast(topic, msg)
>>
>>   2) The API is passed a ConfigOpts instance:
>>
>>      class Connection(object):
>>
>>          def __init__(self, conf):
>>              self.cnx = self.connect(conf.broker_hostname,
>>                                      conf.broker_port)
>>
>>          def cast(self, topic, msg):
>>              self.cnx.cast(topic, msg)
>>
>>   3) The API uses the global config object
>>
>>      class Connection(object):
>>
>>          def __init__(self):
>>              self.cnx = self.connect(CONF.broker_hostname,
>>                                      CONF.broker_port)
>>
>>          def cast(self, topic, msg):
>>              self.cnx.cast(topic, msg)
>>
>>
>> I see (1) as having value if we want the API to be usable outside
>> OpenStack. That might be worthwhile long term, but openstack-common's
>> goal is to provide APIs shared between OpenStack projects.
>>
>> (2) and (3) have the huge benefit of configuration consistency - the
>> same configuration keys, defaults, etc. shared across projects.
>>
>> (2) has value if there are cases where we want to use a non-global cfg
>> object. Quantum might have this use case if it continues parsing plugin
>> configuration separately from its main configuration. We'll see.
>>
>> (3) has value if all use cases are using a global object.
>>
>> I can see us getting to a point where we support both (2) and (3). I'm
>> dubious of the value of (1) in the medium t

Re: [Openstack] cfg usage - option registration, global objects

2012-06-05 Thread Mark Washenberger

> 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? If so, 
how is the incubation process supposed to make things better in terms of my 
concerns about nova.rpc?

I just want to be able to make improvements to some of our programming 
practices without having to have a deep involvement with every openstack 
project. As a corporate sponsored developer, every extra bit of work I have to 
add in to a cleanup / technical debt / programming style task makes it harder 
to convince people to let me work on it during work hours. Every strategy I can 
think of to work around this extra difficulty would potentially run afoul of 
your pursuit of code conformity and reuse. That's why I keep pushing back on 
os-common.





___
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!!!

2012-06-05 Thread Từ Minh Mẫn

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  wrote:

> 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  wrote:
>
>> 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  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  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  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 wrote:

> 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  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  wrote:
>>
>>> 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=server&bits=32&release=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 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 wrote:

> Yes sorry,
> my question was intended to Từ Minh Mẫn  :-)
>
>
>   Michael Pittaro 
>  28 mai 2012 01:41
> It's really a matter of which Linux distro you prefer (or know
> better) - the OpenStack pieces are the same everywhere.  I personally 
> work
> with both Ubuntu _and_ Fedora regularly - but as long as I can run 
> vim and
> lxde, I'm usually happy with the environment. It's all Linux, after 
> all.
>
> I tend to use Ubuntu for openstack development work since the
> devstack.py toolchain favoured that initially, but I also run Fedora 
> on
> other machines.
>
> mike
>
>
>   Michael Pittaro 
>  27 mai 2012 19:00
> On Fri, May 25, 2012 at 12:20 AM, Razique Mahroua
>
> The wiki page http://wiki.openstack.org/GetOpenStack lists many
> of the
> sources for OpenStack, and there are many links to distribution
> specific install guides.
>
> mike
>   Razique Mahroua 
>  25 mai 2012 09:20
> Hey :-)
> Please start here :
> http://docs.openstack.org/essex/openstack-compute/starter/content/
>
> And let us know if you have any issues. Also join us on the IRC
> freenode channel "openstack"
> Razique
>
>
>   Từ Minh Mẫn 
>  25 mai 2012 09:07
> Dear all,
> I am student of master information, I am a new member of openstack
> mailing list.
> This is the first time I stu

[Openstack] depend discrepancies

2012-06-05 Thread Monty Taylor

Hey guys!

One of the things that came out of ODS is the idea of having a single
global dependency list. There are two bits to that - the mechanics of
managing the list (which I think we may have sorted) and then, you know,
making the list. In compiling the list of what the current global list
is, most of the things have clear and obvious answers. However, there
are three problematic deps: kombu, PasteDeploy and xattr. Here's what we
have for them:

./melange/tools/pip-requires:kombu==1.5.1
./glance/tools/pip-requires:kombu
./nova/tools/pip-requires:kombu==1.0.4
./cinder/tools/pip-requires:kombu==1.0.4

./keystone/tools/pip-requires:PasteDeploy
./melange/tools/pip-requires:PasteDeploy
./quantum/tools/pip-requires:PasteDeploy==1.5.0
./glance/tools/pip-requires:PasteDeploy
./nova/tools/pip-requires:PasteDeploy==1.5.0
./swift/tools/pip-requires:pastedeploy==1.3.3
./cinder/tools/pip-requires:PasteDeploy==1.5.0

./glance/tools/pip-requires:xattr>=0.6.0
./swift/tools/pip-requires:xattr==0.4

I have no personal emotions towards any of these versions ... but if
folks who matter could make some call on what they _should_ be, we can
move forward with the first step.

I should point out that at the moment we're looking at using update.py
from openstack-common to copy in the relevant depends from the master
list - so a project will only get the ones it needs. It also means that
a decision on a version here does not mean that everyone needs to move
to that version immediately ... just that we should be moving towards
supporting those versions before folsom, really.

Anywhoo... thoughts?

Monty

___
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] Fwd: Question about cloudfiles API

2012-06-05 Thread Chmouel Boudjnah

On Mon, Jun 4, 2012 at 8:49 PM, Shawn Heisey  wrote:
> server.  Keystone is not part of the multiserver howto:
> http://swift.openstack.org/howto_installmultinode.html

Hopefully we will be able to update that when the keystone/swift
middleware will be moved over swift repository.

Chmouel.

___
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] What does "nova migrate" do, exactly?

2012-06-05 Thread Florian Haas

On 06/05/12 17:27, Vishvananda Ishaya wrote:
> No, migrate does "dead" migration on a server.  Essentially snapshots the 
> drive transfers it to a new server and reboots.  Migrate and live-migration 
> do need to be consolidated.

Um, OK. How do I specify where to migrate to?

nova help migrate
usage: nova migrate [--poll] 

Migrate a server.

Positional arguments:
Name or ID of server.

Optional arguments:
  --pollBlocks while instance migrates so progress can be reported.

Slightly confused. :)

Cheers,
Florian

___
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] What does "nova migrate" do, exactly?

2012-06-05 Thread Vishvananda Ishaya

No, migrate does "dead" migration on a server.  Essentially snapshots the drive 
transfers it to a new server and reboots.  Migrate and live-migration do need 
to be consolidated.

Vish

On Jun 5, 2012, at 12:04 AM, Florian Haas wrote:

> Hi everyone,
> 
> do I understand correctly that "nova migrate" is intended to upgrade
> an instance's configuration from one Nova version to the next? I can't
> seem to find it documented anywhere, and would be happy to provide a
> doc patch if my hunch is correct.
> 
> Also if my assumption is correct, would people agree that this is a
> partial naming clash with "nova live-migration" which does something
> completely different (which might confuse users)? And would "nova
> upgrade" then perhaps be a better term for what "nova migrate" does
> now?
> 
> Cheers,
> Florian
> 
> ___
> 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] (no subject)

2012-06-05 Thread mwjpiero

Hi, all  I want to know is there anybody interested in using spice in Openstack.  First let spice enabled in vm's xml file, and spawn with spice.  Then let token to auth spice's password.  Now I want to do the first thing. Can anybody also do that?-- Sent from my HP TouchPad ___
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] Changes to the ceilometer Jenkins job

2012-06-05 Thread Monty Taylor

On 06/05/2012 05:24 AM, Julien Danjou wrote:
> On Tue, May 29 2012, Julien Danjou wrote:
> 
>> We noticed that currently, on Stackforge, the ceilometer project has
>> only one Jenkins job, checking that the merge occurs correctly.
>>
>> We'd like to add jobs to run unit tests, pep8, etc… I took a look at the
>> openstack-ci-puppet repo, but I'm not sure of the changes, so I prefer
>> to ask here for someone that understand this to help.
>> From what I see, it's likely we would like to use the default
>> "python_jobs" template.
> 
> Is there a way to add more checks without touching the
> openstack-ci-puppet repository?

Nope. BUT - you can certainly add more checks to the ceilometer.yaml
file and submit them for merge. (feel free to follow up with us if that
doesn't make sense the first time) We actually _just_ finished doing a
ton of work to make it possible to control all of this via git so that
we could let anyone help hack the jenkins jobs that they need.

> I'd like to run tests with tox on the same py26/27 envs but using a
> different set of pip-requires. I found out how to write the tox.ini
> part, but I am not sure how the envlist is controlled on the Jenkins
> side.

It should be easy enough to add a few jobs to your file that will run
the run_tox.sh script with the names of your new environments. Find us
in #openstack-infra and we'll talk you through it.

___
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

2012-06-05 Thread Doug Hellmann

On Tue, Jun 5, 2012 at 10:41 AM, Doug Hellmann
wrote:

>
>
> On Tue, Jun 5, 2012 at 9:56 AM, Nick Barcet 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.)
>
>
>>
>> 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.


>
>
>>
>> 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?
>
>
>>
>> Where ConfigDefault are the "sane" default proposed by the agent authors.
>>
>
> Why is the agent proposing default settings?
>
>
>>
>> If no config record is found the collector creates the record, sets
>> ConfVers to 1 and sends back a normal reply.
>>
>> Reply sent by the collector:
>>'correlation_id': x
>>'version': '1.0',
>>
>
> Do we need minor versions for the config settings, or are those simple
> sequence numbers to track which settings are the "most current"?
>
>
>>'args': {'data': {
>>   'Result': result.code,
>>   'ConfVers': ConfVers,
>>   'Config': Config,
>>   },
>>},
>>}
>>
>> Result is set as follow:
>>200  -> Config was retrieved successfully
>>201  -> Config was created based on received default (Config is empty)
>>304  -> Config version is identical to CurrentVersion (Config is empty)
>>
>
> Why does the agent need to know the difference between those? Shouldn't it
> simply use the settings it is given?
>
>
>>
>> This leaves open the question of having some UI to change the config,
>> but I thing we can live with manual updating of the records for the time
>> being.
>>
>
> Since we're using the service and RPC frameworks from nova elsewhere, we
> have the option of issuing commands to all of the agents from a central
> server. That would let us, for example, use a cast() call to push a new
> configuration out to all of the agents at once, on demand (from a command
> line program, for example).
>
> I don't see the need for storing the configuration in the database. It
> seems just as easy to have a configuration file on the central server. The
> collector could read the file each time it is asked for the agent
> configuration, and the command line program that pushes config changes out
> could do the same.
>
> 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 reque

Re: [Openstack] [Metering] Agent configuration mechanism

2012-06-05 Thread Doug Hellmann

On Tue, Jun 5, 2012 at 9:56 AM, Nick Barcet 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.)

>
> 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.

>
> 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?

>
> Where ConfigDefault are the "sane" default proposed by the agent authors.
>

Why is the agent proposing default settings?

>
> If no config record is found the collector creates the record, sets
> ConfVers to 1 and sends back a normal reply.
>
> Reply sent by the collector:
>'correlation_id': x
>'version': '1.0',
>

Do we need minor versions for the config settings, or are those simple
sequence numbers to track which settings are the "most current"?

>'args': {'data': {
>   'Result': result.code,
>   'ConfVers': ConfVers,
>   'Config': Config,
>   },
>},
>}
>
> Result is set as follow:
>200  -> Config was retrieved successfully
>201  -> Config was created based on received default (Config is empty)
>304  -> Config version is identical to CurrentVersion (Config is empty)
>

Why does the agent need to know the difference between those? Shouldn't it
simply use the settings it is given?

>
> This leaves open the question of having some UI to change the config,
> but I thing we can live with manual updating of the records for the time
> being.
>

Since we're using the service and RPC frameworks from nova elsewhere, we
have the option of issuing commands to all of the agents from a central
server. That would let us, for example, use a cast() call to push a new
configuration out to all of the agents at once, on demand (from a command
line program, for example).

I don't see the need for storing the configuration in the database. It
seems just as easy to have a configuration file on the central server. The
collector could read the file each time it is asked for the agent
configuration, and the command line program that pushes config changes out
could do the same.

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.

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] Is openstack-glance package broken?

2012-06-05 Thread Pádraig Brady

On 06/05/2012 09:37 AM, Pádraig Brady wrote:
> On 06/05/2012 08:56 AM, Patrick Petit wrote:
>> Hi there,
>>
>> Trying to install OpenStack on Fedora 16 following instructions at 
>> http://fedoraproject.org/wiki/Getting_started_with_OpenStack_on_Fedora_17
>>
>> Very early in the installation process here is what I get. This is new to me 
>> as previous installs worked okay at this point. Does it ring a bell ?
>> Thanks
>> Patrick
>>
>> $ sudo openstack-db --service glance --init
>> Please enter the password for the 'root' MySQL user: 
>> Verified connectivity to MySQL.
>> Creating 'glance' database.
>> Asking openstack-glance to sync the database.
>> Traceback (most recent call last):
>>   File "/usr/bin/glance-manage", line 43, in 
>> from glance.common import cfg
>> ImportError: cannot import name cfg
>> ERROR 1146 (42S02) at line 1: Table 'glance.migrate_version' doesn't exist
>> Final sanity check failed.
>> Please file a bug report on bugzilla.redhat.com  
>> against the openstack-glance package.
> 
> What package is this?
> $ rpm -q openstack-glance
> 
> Is this file present? It should be:
> /usr/lib/python2.7/site-packages/glance/common/cfg.py

Tying off loose ends...
Since glance.common.cfg was removed for folsom I suspected
that a folsom version of glance was installed and conflicting
with the packaged version.

This was confirmed with:

$ python -c 'from glance.common import config; print config.__file__'
/usr/lib/python2.7/site-packages/glance-2012.2-py2.7.egg/glance/common/config.pyc

So this issue is isolated to the OPs machine.

cheers,
Pádraig.

___
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] quantumclient=2012.1

2012-06-05 Thread Gary Kotton


On 06/05/2012 04:29 PM, Monty Taylor wrote:

On 06/05/2012 07:54 AM, Gary Kotton wrote:

Hi Monty and Dan,
Background: A short while ago I started to port bug fixes for Quantum
from Folsom-1 to Stable Essex. Jenkins did not accept the patches due to
the fact that the automatic tests did not pass. The failures are due to
2 reasons:
1. pep8 checks (addressed in the tox.ini)
2. missing files for automatic tests
A fix for this issue was proposed -
https://review.openstack.org/#/c/8023. Mark McLoughlin rightly pointed
out that the fix was risky by adding a considerable amount of code and
suggested adding quantumclient==2012.1 to the pip-requires. The problem
with this is that the quantumclient does not exist in pypi
(http://pypi.python.org/pypi/python-quantumclient).
How do you suggest that we proceed?

For now, add:

https://github.com/openstack/python-quantumclient/zipball/2012.1#egg=python-quantumclient

Thanks! I'll let you know if it works.

to the quantum stable/essex pip-requires

We're really close to figuring out the client lib upload issue overall
(there are about 100 requirement from about 100 different people - but I
think we've almost got it sorted) but until we can get it done properly,
just do the github zipball bit.



___
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] Libguestfs weirdness??

2012-06-05 Thread Richard W.M. Jones

On Mon, Jun 04, 2012 at 10:12:23AM -0700, Joshua Harlow wrote:
> Hi all,
> 
> I was wondering if there has been anyone else who has used this flag with 
> libguestfs (on RH 6.2) that has noticed file sync issues.
> 
> force_raw_images=true
> 
> I have been turning that to false so that images need not be expanded for 
> actual usage (it seems this only affects the base images in _base) but when 
> turning that to false and when file injection occurs, it seems that the files 
> get written (I've added os.listdir and such for debugging) but when unmounted 
> and later that image is started it seems like those files either do not get 
> synced back to the image (I even added a manual 'sync' call) or there is some 
> other corruption that happens that causes those images to not contain those 
> files when started (for reference I am using qcow2 files).
> 
> Has anyone else seen this type of issue?
> It seems when it is set to true it is not a problem, but when it isn't then 
> some weirdness happens

If you suspect a libguestfs issue, make sure that tracing and/or
debugging are enabled:

http://libguestfs.org/guestfs-faq.1.html#how_do_i_debug_when_using_the_api

Padraig, can libguestfs debug output be captured and logged properly
by Openstack?  If not then we should add a way to do this.  Let's talk
about it tomorrow.

Rich.

-- 
Richard Jones
Red Hat

___
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] doc: "Reference for Configuration Options in nova.conf" shows up twice in the Compute Admin Manual

2012-06-05 Thread Florian Haas

On 06/05/12 14:45, Anne Gentle wrote:
> In a word, yes.
> 
> I noticed this yesterday but hadn't logged a bug about it, thanks Florian.

https://review.openstack.org/8181
https://review.openstack.org/8182

Cheers,
Florian

___
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] Agent configuration mechanism

2012-06-05 Thread Nick Barcet

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.

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.

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,
   },
},

Where ConfigDefault are the "sane" default proposed by the agent authors.

If no config record is found the collector creates the record, sets
ConfVers to 1 and sends back a normal reply.

Reply sent by the collector:
'correlation_id': x
'version': '1.0',
'args': {'data': {
   'Result': result.code,
   'ConfVers': ConfVers,
   'Config': Config,
   },
},
}

Result is set as follow:
200  -> Config was retrieved successfully
201  -> Config was created based on received default (Config is empty)
304  -> Config version is identical to CurrentVersion (Config is empty)

This leaves open the question of having some UI to change the config,
but I thing we can live with manual updating of the records for the time
being.

Comments welcome...

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

Re: [Openstack] Install OpenStack on Fedora 16 and xen (not Xen Cloud Platform)

2012-06-05 Thread Massimo Canonico


Hi and thanks for your answer.

I was just wondering when I have to specify "libvirt_type" in the 
following procedure:


http://fedoraproject.org/wiki/Getting_started_with_OpenStack_Nova

Thanks,
 Massimo

On 06/01/2012 05:28 PM, John Garbutt wrote:

You can use Xen with OpenStack without XCP. You do Xen+libvirt.
libvirt_type="xen"

I haven't tried that myself, I am concentrating on XenAPI bases systems.

Cheers,
John


-Original Message-
From: openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net
[mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net]
On Behalf Of Massimo Canonico
Sent: 01 June 2012 15:22
To: openstack@lists.launchpad.net
Subject: [Openstack] Install OpenStack on Fedora 16 and xen (not Xen Cloud
Platform)

Hi all,
first of thank you very much for your support.

Right now I have a fedora 16 with xen (NOT XCP), that is, I have installed
those package:

xen-licenses-4.1.2-7.fc16.x86_64
xen-hypervisor-4.1.2-7.fc16.x86_64
xen-runtime-4.1.2-7.fc16.x86_64
netxen-firmware-4.0.534-4.fc15.noarch
xen-libs-4.1.2-7.fc16.x86_64
xen-4.1.2-7.fc16.x86_64

and xen seems happy:

[mex@minicloud03 ~]$ sudo xm info
[sudo] password for mex:
host   : minicloud03.di.unipmn.it
release: 3.3.7-1.fc16.x86_64
version: #1 SMP Tue May 22 13:59:39 UTC 2012
machine: x86_64
nr_cpus: 4
nr_nodes   : 1
cores_per_socket   : 4
threads_per_core   : 1
cpu_mhz: 2400
hw_caps:
bfebfbff:20100800::0940:e3bd::0001:000
0
virt_caps  : hvm
total_memory   : 4094
free_memory: 717
free_cpus  : 0
xen_major  : 4
xen_minor  : 1
xen_extra  : .2
xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler  : credit
xen_pagesize   : 4096
platform_params: virt_start=0x8000
xen_changeset  : unavailable
xen_commandline: placeholder
cc_compiler: gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC)
cc_compile_by  : mockbuild
cc_compile_domain  : phx2.fedoraproject.org
cc_compile_date: Mon May  7 23:28:57 UTC 2012
xend_config_format : 4


Now the question is:
- Can I install openstack in this machine or I must use XCP?

Thanks,
   Massimo

___
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] quantumclient=2012.1

2012-06-05 Thread Monty Taylor

On 06/05/2012 07:54 AM, Gary Kotton wrote:
> Hi Monty and Dan,
> Background: A short while ago I started to port bug fixes for Quantum
> from Folsom-1 to Stable Essex. Jenkins did not accept the patches due to
> the fact that the automatic tests did not pass. The failures are due to
> 2 reasons:
> 1. pep8 checks (addressed in the tox.ini)
> 2. missing files for automatic tests
> A fix for this issue was proposed -
> https://review.openstack.org/#/c/8023. Mark McLoughlin rightly pointed
> out that the fix was risky by adding a considerable amount of code and
> suggested adding quantumclient==2012.1 to the pip-requires. The problem
> with this is that the quantumclient does not exist in pypi
> (http://pypi.python.org/pypi/python-quantumclient).
> How do you suggest that we proceed?

For now, add:

https://github.com/openstack/python-quantumclient/zipball/2012.1#egg=python-quantumclient

to the quantum stable/essex pip-requires

We're really close to figuring out the client lib upload issue overall
(there are about 100 requirement from about 100 different people - but I
think we've almost got it sorted) but until we can get it done properly,
just do the github zipball bit.

___
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] doc: "Reference for Configuration Options in nova.conf" shows up twice in the Compute Admin Manual

2012-06-05 Thread Anne Gentle

In a word, yes.

I noticed this yesterday but hadn't logged a bug about it, thanks Florian.

Anne

On Tue, Jun 5, 2012 at 4:38 AM, Florian Haas  wrote:
> Anne & fellow doc geeks,
>
> http://docs.openstack.org/trunk/openstack-compute/admin/content/compute-options-reference.html
> http://docs.openstack.org/trunk/openstack-compute/admin/content/reference-for-options-in-nova-conf.html
>
> The former looks more current than the latter. Is
> compute-options-reference the correct place to submit patches to, and
> if so can the other one be removed?
>
> Cheers,
> Florian

___
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 Fri, 2012-06-01 at 10:37 -0400, Mark Washenberger wrote:
> Hi Mark,
> 
> Please forgive the top-posting! I always get way too wordy with
> inline replies.
> 
> Regarding configuration, I think there is another option I'd like us
> to adopt. We should implement the code as in your option #1, but then
> implement convenience factories that give the appearance of option #3
> or #2, or both, you pick. From your examples it might look something
> like this:
> 
> class Connection(object):
>  
> def __init__(self, broker_hostname, broker_port):
> self.cnx = self.connect(broker_hostname, broker_port)
>  
> def cast(self, topic, msg):
> self.cnx.cast(topic, msg)
> 
> def connection_from_global_conf():
> return Connection(CONF.broker_hostname, CONF.broker_port)
> 
> I think its pretty necessary that we don't do option #3 directly.
> There are some important use cases to consider, like migrating from
> one rpc implementation to another where you might want an adapter
> that can relay messages from one to the other. Also, cells with
> kombu at least requires that one process be able to talk to multiple
> brokers.

Yeah, I think that all makes sense.

Depending on the context, we might want to require only one of #1, #2 or
#3 to be supported in order for the API to be added to openstack-common
initially. I think there'll be good reasons in different cases why only
one of the options is required by initial users of the API.

> Regarding incubation, I suppose I am confused. At what point during
> incubation do other projects start to use the shared library? I would
> imagine the answer to be "after incubation" but it sounds like there
> are several projects very eager to adopt rpc as soon as it lands in
> openstack common, even before incubation is complete.
> 
> If incubation happens before the calcifying effects of shared use
> set in, then it sounds like a great place to address the other
> rpc-specific concerns we've talked about. Otherwise I guess we're
> stuck where I thought we were, where the bar needs to be set pretty
> high to initially land in os-common.

http://wiki.openstack.org/CommonLibrary#Incubation

In openstack-common, Incubation -> Core is "we're ready to commit to
backward compatibility". None of the APIs have reached that point yet.

While an API is incubating, other projects can still use it and the API
can make backwards incompatible changes. For example, I made a backwards
incompatible change to the cfg.ConfigOpts() constructor recently and
updated all projects to use the new API.

That's exactly the case here - we want openstack.common.rpc to initially
be a reasonable API that can be used by multiple OpenStack projects (say
nova, glance and quantum) but that doesn't mean we need to commit to
maintaining backwards compatibility for the API we initially add.

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] the right way to deprecate a config option?