date:20121114

[Openstack] [Nova] Questions about '_update_usage_from_instances'

2012-11-14 Thread hzguanqiang

Hi, guys.

I found something confused when I studied resource tracking in Nova. In 
resource_tracker.py, the function '_update_usage_from_instances()' made a clear 
reset to 'self.traced_instaces' and 'resources'. And then for each instance, 
function '_update_usage_from_instance()' is called to update resources stats .

There is the question:
Because  function '_update_usage_from_instances()' has made a clear reset, 
every instance passed to '_update_usage_from_instance()' must be a new 
instance(is_new_instance=True). And to a new instance, 'sign' is set to 1. 
This's just ok. But there are a special situation that instance may be deleted 
here. Other words, a instance may be meanwhile new and deleted. In my 
understanding, for deleted instance, We should do nothing in resources stats. 
But for deleted instance, 'sign' is set to -1, not my expected 0. 
Why? Is this a bug or something? 

Any help is appreciated. Thanks.

2012-11-14



hzguanqiang___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [Nova] Questions about '_update_usage_from_instances'

2012-11-14 Thread hzguanqiang

Hi, guys.

I found something confused when I studied resource tracking in Nova. In 
resource_tracker.py, the function '_update_usage_from_instances()' made a clear 
reset to 'self.traced_instaces' and 'resources'. And then for each instance, 
function '_update_usage_from_instance()' is called to update resources stats .

There is the question:
Because  function '_update_usage_from_instances()' has made a clear reset, 
every instance passed to '_update_usage_from_instance()' must be a new 
instance(is_new_instance=True). And to a new instance, 'sign' is set to 1. 
This's just ok. But there are a special situation that instance may be deleted 
here. Other words, a instance may be meanwhile new and deleted. In my 
understanding, for deleted instance, We should do nothing in resources stats. 
But for deleted instance, 'sign' is set to -1, not my expected 0. 
Why? Is this a bug or something? 

Any help is appreciated. Thanks.

2012-11-14



hzguanqiang___
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] snapshots, backups of running VMs and compute node recovery

2012-11-14 Thread gtt116

Hi，

After delete all instance and recreate them, their fixed-ip and uuid
will change.
I don't think the way is good enough to end user.

If we can rebuild instance with same uuid and fixed-ip, etc to another
host will be good.

- Tian

于 2012年11月13日 17:02, Édouard Thuleau 写道:
 Hi Jānis,

 Yes, by deleted I mean clear all related VM entries in DB. I don't
 know how to do that for the moment.

 Édouard.

 On Mon, Nov 12, 2012 at 10:46 AM, Jānis Ģeņģeris
 janis.genge...@gmail.com wrote:
 Hi,

 What do you mean with deleting all servers? If the node is down, then all
 the VM data is gone too, or you are talking about DB entries?


 On Mon, Nov 12, 2012 at 11:08 AM, Édouard Thuleau thul...@gmail.com wrote:
 I try to implement a simple way to automate the backup mechanism (eg.
 every day): https://blueprints.launchpad.net/nova/+spec/backup-schedule

 And I though of a solution to respond to your needs: when a node fails
 (for any reasons), I disable it, I delete all servers was running on
 it and I restart them from the last available backup.

 Édouard.

 On Fri, Nov 9, 2012 at 8:45 PM, Vishvananda Ishaya
 vishvana...@gmail.com wrote:
 The libvirt driver has actually gotten quite good at rebuilding all of
 the data for instances. This only thing it can't do right now is redownload
 base images from glance. With current state if you simply back up the
 instances directory (usually /var/lib/nova/instances) then you can recover
 by bringing back the whole directory and doing a nova reboot uuid for 
 each
 instance.

 You could just stick the whole thing on an lvm and snaphot it regularly
 for dr. The _base directory can be regenerated with images from glance so
 you could also write a script to regenerate it and not have to worry about
 backing it up. The code to add to nova to make it automatically re-download
 the image from glance if it isn't there shouldn't be too bad either, which
 would mean you could safely ignore the _base directory for backups.
 Additionally using qcow images in glance and the config option
 `force_raw_images=False` will keep this directory much smaller.

 Vish


 On Nov 9, 2012, at 2:51 AM, Jānis Ģeņģeris janis.genge...@gmail.com
 wrote:

 Hello all,

 I would like to know the available solutions that are used regarding to
 backing up and/or snapshotting running
 instances on compute nodes. Documentation does not mention anything
 related to this. With snapshots I don't mean
 the current snapshot mechanism, that imports image of the running VM
 into glance. I'm using KVM, but this is
 significant for any hypervisor.

 Why is this important?
 Consider simple scenario when hardware on compute node fails and the
 node goes down immediately and is not recoverable
 in reasonable time. The images of the running instances are also lost.
 Shared file system is not considered here as it
 may cause IO bottlenecks and adds another layer of complexity.

 There have been a few discussions on the the list about this problem,
 but none have really answered the question.

 The documentation speaks of disaster recovery when power loss have
 happened and failed compute node recovery from
 shared file system. But don't cover the case without shared file system.

 I can think of few solutions currently (for KVM):
 a) using LVM images for VMs, and making LVM logical volume snapshots,
 but then the current nova snapshot mechanism
 will not work (from the docs - 'current snapshot mechanism in OpenStack
 Compute works only with instances backed
 with Qcow2 images');
 b) snapshot machines with OpenStack snapshotting mechanism, but this
 doesn't fit somehow, because it has
 other goal than creating backups, will be slow and pollute the glance
 image space;

 Regards
 --janis
 ___
 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




 --
 --janis
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


-- 
best regards,
gtt



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Can't switch projects in horizon using devstack to install stable/folsom

2012-11-14 Thread Ray Sun

I used devstack to install stable/folsom, but I can't switch projects after
successfully installation.

I try to find the reason, and I found the code in
python-keystoneclient/keystoneclient/v2_0/tokens.py:
 37 reset = 0
 38 if self.api.management_url is None:
 39 reset = 1
 40 self.api.management_url = self.api.auth_url
 41 token_ref = self._create('/tokens', params, access,
 42  return_raw=return_raw)
 43 if reset:
 44 self.api.management_url = None
 45 return token_ref

I don't know what does the code mean, but I guess it affects the project
switcher.

The reason is when the page is generating, the horizon try to retrieve all
accessible tenants, but in the request.user the endpoint is None, and this
variable is set by management_url. And the code above will always make the
management url is None. So can anyone explain the code for me? Thanks a lot.


- Ray
Yours faithfully, Kind regards.

CIeNET Technologies (Beijing) Co., Ltd
Email: qsun01...@cienet.com.cn
Office Phone: +86-01081470088-7079
Mobile Phone: +86-13581988291
___
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: Devstack does not complete the installation because of the inexistence of image files at images.ansolabs.com

2012-11-14 Thread Mate Lakat

Hi,

Sorry for the delay. tty.tgz and the guest tools are uploaded to github.
Here is the gerrit review for the devstack changes:

https://review.openstack.org/#/c/16069/1

In your mail, you were mentioning several other urls, I think they
have all been changed since then.

Mate

On Sun, Oct 28, 2012 at 08:17:28AM +, Afef MDHAFFAR wrote:
 
 
 Hi all
 
 I have noticed the Image url 
 (images.ansolabs.comhttp://images.ansolabs.com) used by devstack does not 
 work any more. It does not contain the required files by devstack
 It is now impossible to download all these files:
 http://images.ansolabs.com/cirros-0.3.0-x86_64-rootfs.img.gz
 http://images.ansolabs.com/tty.tgz
 http://images.ansolabs.com/devstackubuntupreseed.cfg
 http://images.ansolabs.com/xen/xe-guest-utilities_5.6.100-651_amd64.deb
 
 That's why devstack script does not complete the installation:
 ---
 + echo 'WARNING: no XenServer tools found, falling back to 5.6 tools'
 WARNING: no XenServer tools found, falling back to 5.6 tools
 + 
 TOOLS_URL=http://images.ansolabs.com/xen/xe-guest-utilities_5.6.100-651_amd64.deb
 + wget 
 http://images.ansolabs.com/xen/xe-guest-utilities_5.6.100-651_amd64.deb -O 
 xs-tools.deb
 --2012-10-26 23:47:53--  
 http://images.ansolabs.com/xen/xe-guest-utilities_5.6.100-651_amd64.deb
 Resolving images.ansolabs.comhttp://images.ansolabs.com 
 (images.ansolabs.comhttp://images.ansolabs.com)... 173.203.89.94
 Connecting to images.ansolabs.comhttp://images.ansolabs.com 
 (images.ansolabs.comhttp://images.ansolabs.com)|173.203.89.94|:80... 
 connected.
 HTTP request sent, awaiting response... 404 Not Found
 2012-10-26 23:47:54 ERROR 404: Not Found.
 
 + on_exit
 ++ seq 0 -1 0
 + for i in '$(seq $((${#on_exit_hooks[*]} - 1)) -1 0)'
 + eval '/home/afef/compute/devstack/tools/xen/scripts/manage-vdi close 
 computeDomU01 0 1'
 ++ /home/afef/compute/devstack/tools/xen/scripts/manage-vdi close 
 computeDomU01 0 1
 + action=close
 + vm=computeDomU01
 + device=0
 + part=1
 ++ xe_min vm-list name-label=computeDomU01
 ++ local cmd=vm-list
 ++ shift
 ++ xe vm-list --minimal name-label=computeDomU01
 + vm_uuid=89b0c708-d906-8ffd-44b7-f01ec678cd2a
 ++ xe_min vbd-list params=vdi-uuid 
 vm-uuid=89b0c708-d906-8ffd-44b7-f01ec678cd2a userdevice=0
 ++ local cmd=vbd-list
 ++ shift
 ++ xe vbd-list --minimal params=vdi-uuid 
 vm-uuid=89b0c708-d906-8ffd-44b7-f01ec678cd2a userdevice=0
 + vdi_uuid=79e827e9-d367-4648-bcfa-cbfecf6cfb47
 ++ xe_min vm-list is-control-domain=true
 ++ local cmd=vm-list
 ++ shift
 ++ xe vm-list --minimal is-control-domain=true
 + dom0_uuid=8cb654b9-b4e6-4569-bd38-7698a861fc98
 + '[' close == open ']'
 + '[' close == close ']'
 + close_vdi
 ++ xe_min vbd-list vm-uuid=8cb654b9-b4e6-4569-bd38-7698a861fc98 
 vdi-uuid=79e827e9-d367-4648-bcfa-cbfecf6cfb47
 ++ local cmd=vbd-list
 ++ shift
 ++ xe vbd-list --minimal vm-uuid=8cb654b9-b4e6-4569-bd38-7698a861fc98 
 vdi-uuid=79e827e9-d367-4648-bcfa-cbfecf6cfb47
 + vbd_uuid=1f5ee566-0a60-2706-3261-80b5017b1588
 ++ get_mount_device 1f5ee566-0a60-2706-3261-80b5017b1588
 ++ vbd_uuid=1f5ee566-0a60-2706-3261-80b5017b1588
 +++ xe_min vbd-list params=device uuid=1f5ee566-0a60-2706-3261-80b5017b1588
 +++ local cmd=vbd-list
 +++ shift
 +++ xe vbd-list --minimal params=device 
 uuid=1f5ee566-0a60-2706-3261-80b5017b1588
 ++ 
 dev=sm/backend/95ec7cbb-a45d-ad4c-c0df-0e548b9a56d4/79e827e9-d367-4648-bcfa-cbfecf6cfb47
 ++ [[ 
 sm/backend/95ec7cbb-a45d-ad4c-c0df-0e548b9a56d4/79e827e9-d367-4648-bcfa-cbfecf6cfb47
  =~ sm/ ]]
 ++ DEBIAN_FRONTEND=noninteractive
 ++ apt-get --option Dpkg::Options::=--force-confold --assume-yes install 
 kpartx
 +++ kpartx -av 
 /dev/sm/backend/95ec7cbb-a45d-ad4c-c0df-0e548b9a56d4/79e827e9-d367-4648-bcfa-cbfecf6cfb47
 +++ sed -ne 's,^\(.*1\)$,\1,p'
 +++ sed -ne 's,^add map \([a-z0-9\-]*\).*$,\1,p'
 ++ mapping=79e827e9-d367-4648-bcfa-cbfecf6cfb47p1
 ++ '[' -z 79e827e9-d367-4648-bcfa-cbfecf6cfb47p1 ']'
 ++ echo /dev/mapper/79e827e9-d367-4648-bcfa-cbfecf6cfb47p1
 + mount_device=/dev/mapper/79e827e9-d367-4648-bcfa-cbfecf6cfb47p1
 + run_udev_settle
 ++ which udevsettle
 + which_udev=
 + true
 + '[' -n '' ']'
 + udevadm settle
 + umount /dev/mapper/79e827e9-d367-4648-bcfa-cbfecf6cfb47p1
 + clean_dev_mappings
 ++ xe_min vbd-list params=device uuid=1f5ee566-0a60-2706-3261-80b5017b1588
 ++ local cmd=vbd-list
 ++ shift
 ++ xe vbd-list --minimal params=device 
 uuid=1f5ee566-0a60-2706-3261-80b5017b1588
 + 
 dev=sm/backend/95ec7cbb-a45d-ad4c-c0df-0e548b9a56d4/79e827e9-d367-4648-bcfa-cbfecf6cfb47
 + [[ 
 sm/backend/95ec7cbb-a45d-ad4c-c0df-0e548b9a56d4/79e827e9-d367-4648-bcfa-cbfecf6cfb47
  =~ sm/ ]]
 + kpartx -dv 
 /dev/sm/backend/95ec7cbb-a45d-ad4c-c0df-0e548b9a56d4/79e827e9-d367-4648-bcfa-cbfecf6cfb47
 del devmap : 79e827e9-d367-4648-bcfa-cbfecf6cfb47p5
 del devmap : 79e827e9-d367-4648-bcfa-cbfecf6cfb47p2
 del devmap : 79e827e9-d367-4648-bcfa-cbfecf6cfb47p1
 + xe vbd-unplug uuid=1f5ee566-0a60-2706-3261-80b5017b1588
 + xe vbd-destroy

[Openstack] Minutes from the Technical Committee meeting (Nov 13)

2012-11-14 Thread Thierry Carrez

The OpenStack Technical Committee (TC) met in #openstack-meeting at
20:00 UTC yesterday.

Here is a quick summary of the outcome of this meeting:

* The following motion on 3rd-party APIs was approved:

The previous aspirational statement that the PPB made in May 2012 about
3rd party APIs being implemented external to core stands. However, where
a given project does not yet expose a stable, complete, performant
interface for 3rd party APIs to build on, that project may choose to
accept proposed new APIs in the interim if it sees fit.

* Discussion continued on the Incubator/Core process update. The
mailing-list thread at [1] shows signs of crystallization. Hopefully the
TC will be able to agree at the next meeting on a direction and members
to represent that direction on the future joint committee to be
established with the Board of Directors.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2012-November/thread.html#2387

* We had the initial discussion on distribution and Python version
support policy. Discussion will continue on the mailing-list.

See details and full logs at:
http://eavesdrop.openstack.org/meetings/tc/2012/tc.2012-11-13-20.02.html

More information on the Technical Committee at:
http://wiki.openstack.org/Governance/TechnicalCommittee

-- 
Thierry Carrez (ttx)
Chair, OpenStack Technical Committee

___
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] Couldn't find stack-screenrc

2012-11-14 Thread Johannes Baltimore

Hi.

I got devstack today, but I've been going through a problem. Whenever i
turn on the machine, I cannot run the rejoin-stack.sh script, even though
I've ran stack.sh before. It says the stack-screenrc file couldn't be
found, and then asks me to run stack.sh again. Does anyone knows why does
this happen?

Thanks in advance
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Plans for Trusted Computing in OpenStack

2012-11-14 Thread Nicolae Paladi

That is correct, the variety of versions, components and patches is the
first thing
that comes to everyone's mind with this approach.
But the idea is not to have a trusted third party/CA that would be able to
assess _all_ combinations.
With both approaches, the 'assessment' is left out as a stub or
assumption (whichever you prefer).
In this case it doesn't actually matter who does the assessment - the IaaS
provider or a CA,
since the assessment criteria are the unsolved issue.

The use case we're examining here is when a certain IaaS provider is
contracted to supply
IaaS to a client with special requirements, let's call it C. That would
mean, e.g:
1. Potentially not all hosts would be used to deploy VMs for C
2. Potentially patches and versioning might go through a separate upgrade
flow for those hosts

To summarize and address your concerns here:
* imo once a client  is concerned enough to require trusted hosts, the
use of using external assessment case becomes valid
(and assessment by the IaaS provider becomes useless)
* wrt to variation of the software stack, the big issue is the assessment
criteria rather than the assessing party.


Cheers,
/Nico.



On 14 November 2012 04:27, Tian, Kevin kevin.t...@intel.com wrote:

  I would see the major blocking issue on this:

 ** **

 “However, imo an IaaS provider that claims to offer trusted hosts but
 hesitates to reveal the software stack of it's hosts to an external auditor
 (CA in this case) would have issues with credibility”

 ** **

 every IaaS provide has its own software stack, picking different
 components, with different versions, possibly adding different patches. The
 stack can be changed frequently. Rackspace says they can publish a build in
 less than 1hrs to deploy a new stack. Having an external CA to hold
 credentials for such large uncertain combos is almost a mission impossible.
 J

 ** **

 Thanks

 Kevin

 ** **

 ** **

 *From:* Nicolae Paladi [mailto:n.pal...@gmail.com]
 *Sent:* Tuesday, November 13, 2012 11:46 PM
 *To:* Dugger, Donald D
 *Cc:* openstack; Tian, Kevin; Li, Susie; Wei, Gang; Maliszewski, Richard L

 *Subject:* Re: [Openstack] Plans for Trusted Computing in OpenStack

  ** **

 Hi, 

 ** **

 I agree that the use case of a trusted IaaS provider (with possibly
 compromised nodes) is a valid one and should have support in the openstack
 codebase, although it seems rather dicey to trust the IaaS provider which
 does not trust it's own hosts.

 And your understanding is correct, the idea is to add a 3rd party 'CA'
 with the aim to assess the integrity of the hosts based on the data
 produced by the TPM.

 ** **

 What I am advocating here is the scenario where the IaaS can not be
 trusted.  

 In this case the CA would only gain information about the software stack
 of the IaaS provider's hosts, necessary to perform the attestation.
 However, imo an IaaS provider that claims to offer trusted hosts but
 hesitates to reveal the software stack of it's hosts to an external auditor
 (CA in this case) would have issues with credibility.

 ** **

 Wrt complexity, this would require:

 ** **

 * sending the attestation information externally to the 'CA' and taking a
 launch/not launch decision based on the result of the attestation. Even if
 the untrusted IaaS launches the VM, the client can easily detect the fraud.
 

 ** **

 * on the compute host, decrypting the nonce provided by the client (and
 _sealed_ by the CA to the trusted configuration of the host). That will add
 up to the codebase but is rather trivial (involves mostly interacting with
 the TPM).

 ** **

 Now, there are some design choices to be made, e.g. whether the host
 communicates its attestation credentials directly to the CA in an https
 session or the scheduler does that. However, it does not change the
 important point that the client can verify that the VM was started on a
 trusted host, without having to rely on the IaaS provider.

 ** **

 A common topic to both models (trusted or untrusted IaaS provider) is the
 question of security profiles for the hosts -- are you considering binary
 values (trusted/untrusted) or some finer-grained scale?

 ** **

 Happy to hear your opinions and continue the discussion;

 ** **

 cheers, 

 /Nico.

 ** **

 ** **

 On 12 November 2012 21:23, Dugger, Donald D donald.d.dug...@intel.com
 wrote:

 Nicolae-

  

 We’ve been working under the assumption you have trust the IaaS provider
 (individual nodes might have been compromised somehow but you trust the
 provider itself).  I think what you are looking at is adding a 3rd party
 CA which is significantly increasing the complexity of the solution and
 potentially exposing the IaaS’s infrastructure to a 3rd party, probably
 not desirable to the IaaS provider.

  

 I’ve added some others to the thread who can chime in with their opinions.
 

  

 --

 Don Dugger

Re: [Openstack] Couldn't find stack-screenrc

2012-11-14 Thread Everett Toews

From: Johannes Baltimore 
johannes.b...@gmail.commailto:johannes.b...@gmail.com
Date: Wednesday, November 14, 2012 8:34 AM
To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net 
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: [Openstack] Couldn't find stack-screenrc

Hi.

I got devstack today, but I've been going through a problem. Whenever i turn on 
the machine, I cannot run the rejoin-stack.sh script, even though I've ran 
stack.sh before. It says the stack-screenrc file couldn't be found, and then 
asks me to run stack.sh again. Does anyone knows why does this happen?

Thanks in advance

---

Did you run stack.sh as root?

I've noticed that when you start as root the stack-screenrc file doesn't get 
created. You can copy over an old stack-screenrc or just start it as a new user.

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] [nova-api] nova image-list giving authentication error

2012-11-14 Thread Ahmed Al-Mehdi

Hello,

I resolved the issue.   It was an error on my part not not correctly setting 
admin_tenant_name, admin_user, admin_password correctly in api-paste.ini.

Regards,
Ahmed.


From: Ahmed Al-Mehdi ah...@coraid.commailto:ah...@coraid.com
Date: Tuesday, November 13, 2012 3:30 PM
To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net 
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: [Openstack] [nova-api] nova image-list giving authentication error

Hello,

I am trying to test out nova installation per the instruction in OpenStack 
Deploy and Install Manual.  ( 
http://docs.openstack.org/trunk/openstack-compute/install/apt/content/configure-creds.html
 ).  However, when I issue nova image-list, I get the prompt -  password for 
your new keyring.   Can someone please help me understand what this keyring 
password is all about?  Did I make a mistake somewhere along the way in my 
setup?

root@bodega:/etc/nova# env | grep OS_
OS_REGION_NAME=RegionOne
OS_PASSWORD=admin
OS_AUTH_URL=http://10.176.20.158:5000/v2.0/
OS_USERNAME=admin
OS_TENANT_NAME=openstackDemo
root@bodega:/etc/nova#
root@bodega:/etc/nova# glance index
ID   Name   Disk Format 
 Container Format Size
 -- 
  --
48cc3352-dff3-4625-87b1-143ba1953c57 tty-linux  ami 
 ami25165824
c0f6a4df-5051-49d3-855e-8627c6c15ba6 tty-linux-ramdisk  ari 
 ari   96629
14652b05-0c27-45d1-b614-a059c9f4f7dc tty-linux-kernel   aki 
 aki 4404752
root@bodega:/etc/nova#
root@bodega:/etc/nova# nova image-list
Please set a password for your new keyring
Password (again):
Error: blank passwords aren't allowed.
Please set a password for your new keyringTraceback (most recent call last):
  File /usr/bin/nova, line 9, in module
…….




I googled the web, it seems setting environment OS_NO_CACHE=1 should avoid 
this issue.  However, now I am getting an authentication error, even though the 
username/password = admin/admin is correct.


root@bodega:/etc/nova# export OS_NO_CACHE=1
root@bodega:/etc/nova# nova image-list
ERROR: n/a (HTTP 401)


/var/log/nova-api.log:

2012-11-13 12:36:54 WARNING keystone.middleware.auth_token [-] Unexpected 
response from keystone service: {u'error': {u'message': u'The request you have 
made requires authentication.', u'code': 401, u'title': u'Not Authorized'}}
2012-11-13 12:36:54 WARNING keystone.middleware.auth_token [-] Authorization 
failed for token 94a69471564f492bb590b549a63870c9
2012-11-13 12:36:54 INFO keystone.middleware.auth_token [-] Invalid user token 
- rejecting request
2012-11-13 12:36:54 INFO nova.osapi_compute.wsgi.server [-] 10.176.20.158 - - 
[13/Nov/2012 12:36:54] GET /v2/ce1e819636744dc680fa5515f6475e87/images/detail 
HTTP/1.1 401 461 0.011898

2012-11-13 12:36:54 WARNING keystone.middleware.auth_token [-] Unexpected 
response from keystone service: {u'error': {u'message': u'The request you have 
made requires authentication.', u'code': 401, u'title': u'Not Authorized'}}
2012-11-13 12:36:54 WARNING keystone.middleware.auth_token [-] Authorization 
failed for token 8afc24d31b454a6a8a2a0e2331231071
2012-11-13 12:36:54 INFO keystone.middleware.auth_token [-] Invalid user token 
- rejecting request
2012-11-13 12:36:54 INFO nova.osapi_compute.wsgi.server [-] 10.176.20.158 - - 
[13/Nov/2012 12:36:54] GET /v2/ce1e819636744dc680fa5515f6475e87/images/detail 
HTTP/1.1 401 461 0.012803

I ran nova —debug image-list and pasted the output on paste bin - 
http://pastebin.com/JyCvBVmY.   I am going through the logs but not able to 
understand the cause of the authentication failure.  Any help would be highly 
appreciated.

Thank you,
Ahmed.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

2012-11-14 Thread Joe Savak

Hi Joe,
If I'm working across multiple tenants, I'd prefer one token that I can 
securely handle that proves access rights to the tenants I'm working with. 
Handling multiple tokens increases the complexity of clients needing to provide 
multi-tenancy access to an authenticated identity. It also adds more calls to 
keystone. 

Again, I think that having the keystone reference implementation restrict 
tokens to 1 tenant is fine. We shouldn't have such arbitrary restrictions in 
the API contract though. It needs to be extensible and flexible to allow for 
the all sorts of use cases that are likely to occur.

Thanks,
joe

-Original Message-
From: heckj [mailto:he...@mac.com] 
Sent: Tuesday, November 13, 2012 3:59 PM
To: Joe Savak
Cc: OpenStack Development Mailing List; openstack@lists.launchpad.net 
(openstack@lists.launchpad.net)
Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing 
authorization to projects/tenants in the Keystone V3 API

Hey Joe:

Currently a user scoped token doesn't include a service catalog - mostly 
because I think the service catalog generally requires tenant_id's to 
interpolate into the values to provide it. That doesn't mean we can't put 
in/include service catalog endpoints where that value doesn't need to be 
determined.

I'm also questioning the value of providing a token scoped to all tenants 
associated with a user - that seems to have the same value as just using a user 
token. 

In fact, even if we allow some arbitrary set of tenants to be scoped into a 
token along with a user, what on earth should be in the service catalog? 
Endpoints relevant to every possible tenant?

This just seems to be a potential explosion of data that is poorly scoped from 
a security perspective.

-joe

On Nov 13, 2012, at 1:42 PM, Joe Savak joe.sa...@rackspace.com wrote:
 Will user-scoped token include the full service catalog? 
 
 Also, I thought the consensus was to allow the API contract to be flexible on 
 how many tenants we can scope the token to. The ref impl can enforce 1 
 tenant-scoped token. Are we diverging from this?
 
 Thanks,
 joe
 
 -Original Message-
 From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net 
 [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On 
 Behalf Of heckj
 Sent: Tuesday, November 13, 2012 1:34 PM
 To: OpenStack Development Mailing List
 Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
 Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing 
 authorization to projects/tenants in the Keystone V3 API
 
 
 On Nov 13, 2012, at 11:01 AM, Jorge Williams jorge.willi...@rackspace.com 
 wrote:
 On Nov 13, 2012, at 11:35 AM, heckj wrote:
 So maintaining a token scoped to just the user, and a mechanism to scope it 
 to a tenant sound like all goodness. We can absolutely keep the API such 
 that it can provide either. 
 
 Right now, our auth_token middleware implicitly requires a tenant in that 
 scoping to work. If someone wanted to support a token scoped to just a user 
 for the services, they'd need a different middleware there. Keystone as a 
 service *doesn't* use the auth_token middleware, so with the V3 API we can 
 make it provide services appropriately based on a token scoped only to the 
 user.
 
 All that in place, allow a token to be indeterminate scoped to multiple 
 tenants is fraught with security flaws, and if we continue to provide 
 unscoped tokens, that should obviate the need for token scoped to multiple 
 tenants. 
 
 I'm not sure I'm following you there.  I don't see how unscoped tokens 
 obviate the need to scope to multiple tenants, these may be driven by  
 different concerns. 
 
 Again, I think we need to have some flexibility in how we scope tokens. The 
 API should be flexible enough to support different models -- I think that 
 scoping a token to multiple tenants is useful in cases such as delegation -- 
 where a single identity may be issued revokable access to a set of resources 
 in multiple projects.
 
 The consensus from the folks weighing in on this from a security perspective 
 seems to be that it's kosher to restrict tokens further (the least privilege 
 thing). Broadening the scope to multiple tenants or sets of tenants doesn't 
 appear to follow those best practices. If you wanted to accept a less-scoped 
 token than the scoped to single tenant, you can accept and use a user-scoped 
 token, at least by my read.
 
 -joe
 
 
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

2012-11-14 Thread heckj

If we're going to assert it's supported, we're doing an incredible dis-service 
to writing a spec to not implement that aspect of the spec, as that kind of set 
up just leads to incompatibilities and confusion when asserting how the spec 
should be used to provide interoperability.

If we accept this as a spec addition, then we MUST have an implementation that 
makes it clear how we expect to interoperate with that aspect of the 
specification, even if it's a configuration option that we don't normally 
enable. If we don't test and validate it to prove interoperability, then the 
spec is a worthless digital piece of paper.

So under that pretext, I welcome suggestions on how to interpret the spec 
you're proposing to some concrete implementations that can be verified for 
interoperability, and that are compatible with the existing and/or upcoming 
implementations for V3 API.

-joe

On Nov 14, 2012, at 1:35 PM, Joe Savak joe.sa...@rackspace.com wrote:
 Hi Joe,
   If I'm working across multiple tenants, I'd prefer one token that I can 
 securely handle that proves access rights to the tenants I'm working with. 
 Handling multiple tokens increases the complexity of clients needing to 
 provide multi-tenancy access to an authenticated identity. It also adds more 
 calls to keystone. 
 
 Again, I think that having the keystone reference implementation restrict 
 tokens to 1 tenant is fine. We shouldn't have such arbitrary restrictions in 
 the API contract though. It needs to be extensible and flexible to allow for 
 the all sorts of use cases that are likely to occur.
 
 Thanks,
 joe
 
 -Original Message-
 From: heckj [mailto:he...@mac.com] 
 Sent: Tuesday, November 13, 2012 3:59 PM
 To: Joe Savak
 Cc: OpenStack Development Mailing List; openstack@lists.launchpad.net 
 (openstack@lists.launchpad.net)
 Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing 
 authorization to projects/tenants in the Keystone V3 API
 
 Hey Joe:
 
 Currently a user scoped token doesn't include a service catalog - mostly 
 because I think the service catalog generally requires tenant_id's to 
 interpolate into the values to provide it. That doesn't mean we can't put 
 in/include service catalog endpoints where that value doesn't need to be 
 determined.
 
 I'm also questioning the value of providing a token scoped to all tenants 
 associated with a user - that seems to have the same value as just using a 
 user token. 
 
 In fact, even if we allow some arbitrary set of tenants to be scoped into a 
 token along with a user, what on earth should be in the service catalog? 
 Endpoints relevant to every possible tenant?
 
 This just seems to be a potential explosion of data that is poorly scoped 
 from a security perspective.
 
 -joe
 
 On Nov 13, 2012, at 1:42 PM, Joe Savak joe.sa...@rackspace.com wrote:
 Will user-scoped token include the full service catalog? 
 
 Also, I thought the consensus was to allow the API contract to be flexible 
 on how many tenants we can scope the token to. The ref impl can enforce 1 
 tenant-scoped token. Are we diverging from this?
 
 Thanks,
 joe
 
 -Original Message-
 From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net 
 [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On 
 Behalf Of heckj
 Sent: Tuesday, November 13, 2012 1:34 PM
 To: OpenStack Development Mailing List
 Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
 Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing 
 authorization to projects/tenants in the Keystone V3 API
 
 
 On Nov 13, 2012, at 11:01 AM, Jorge Williams jorge.willi...@rackspace.com 
 wrote:
 On Nov 13, 2012, at 11:35 AM, heckj wrote:
 So maintaining a token scoped to just the user, and a mechanism to scope 
 it to a tenant sound like all goodness. We can absolutely keep the API 
 such that it can provide either. 
 
 Right now, our auth_token middleware implicitly requires a tenant in that 
 scoping to work. If someone wanted to support a token scoped to just a 
 user for the services, they'd need a different middleware there. Keystone 
 as a service *doesn't* use the auth_token middleware, so with the V3 API 
 we can make it provide services appropriately based on a token scoped only 
 to the user.
 
 All that in place, allow a token to be indeterminate scoped to multiple 
 tenants is fraught with security flaws, and if we continue to provide 
 unscoped tokens, that should obviate the need for token scoped to multiple 
 tenants. 
 
 I'm not sure I'm following you there.  I don't see how unscoped tokens 
 obviate the need to scope to multiple tenants, these may be driven by  
 different concerns. 
 
 Again, I think we need to have some flexibility in how we scope tokens. The 
 API should be flexible enough to support different models -- I think that 
 scoping a token to multiple tenants is useful in cases such as delegation 
 -- where a single identity may

Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

2012-11-14 Thread Jorge Williams

From an API perspective the changes required are the following:

1. The validate call returns a list of tenants instead of a single
tenant.

If the tenant id is in the URI of the API, then the validation middleware can
assert that the tenant id is in the list of IDs.

Not sure if there's any additional changes, but I don't think so.

An alternative approach is to use the belongsTo query parameter in the validate
call. So if you know the tenantId of the resource, you can issue a validate
with ?belongsTo=tenatId and validation if the tenant is not in the list of
tenatIds for the token. The belongsTo query parameter is in the validate token
call in the API today

http://docs.openstack.org/api/openstack-identity-service/2.0/content/GET_validateToken_v2.0_tokens__tokenId__Admin_API_Service_Developer_Operations-d1e1356.html

And we use it quite a bit in our implementation, when we validate tokens --
that is in the case where a token may have access to multiple tenants.

Thoughts?

-jOrGe W.

On Nov 14, 2012, at 3:53 PM, heckj wrote:

If we're going to assert it's supported, we're doing an incredible
dis-service to writing a spec to not implement that aspect of the spec, as
that kind of set up just leads to incompatibilities and confusion when
asserting how the spec should be used to provide interoperability.

If we accept this as a spec addition, then we MUST have an implementation
that makes it clear how we expect to interoperate with that aspect of the
specification, even if it's a configuration option that we don't normally
enable. If we don't test and validate it to prove interoperability, then the
spec is a worthless digital piece of paper.

So under that pretext, I welcome suggestions on how to interpret the spec
you're proposing to some concrete implementations that can be verified for
interoperability, and that are compatible with the existing and/or upcoming
implementations for V3 API.

-joe

On Nov 14, 2012, at 1:35 PM, Joe Savak joe.sa...@rackspace.com wrote:
Hi Joe,
If I'm working across multiple tenants, I'd prefer one token that I can
securely handle that proves access rights to the tenants I'm working with.
Handling multiple tokens increases the complexity of clients needing to
provide multi-tenancy access to an authenticated identity. It also adds more
calls to keystone.

Again, I think that having the keystone reference implementation restrict
tokens to 1 tenant is fine. We shouldn't have such arbitrary restrictions in
the API contract though. It needs to be extensible and flexible to allow for
the all sorts of use cases that are likely to occur.

Thanks,
joe

-Original Message-
From: heckj [mailto:he...@mac.com]
Sent: Tuesday, November 13, 2012 3:59 PM
To: Joe Savak
Cc: OpenStack Development Mailing List; openstack@lists.launchpad.net
(openstack@lists.launchpad.net)
Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing
authorization to projects/tenants in the Keystone V3 API

Hey Joe:

Currently a user scoped token doesn't include a service catalog - mostly
because I think the service catalog generally requires tenant_id's to
interpolate into the values to provide it. That doesn't mean we can't put
in/include service catalog endpoints where that value doesn't need to be
determined.

I'm also questioning the value of providing a token scoped to all tenants
associated with a user - that seems to have the same value as just using a
user token.

In fact, even if we allow some arbitrary set of tenants to be scoped into a
token along with a user, what on earth should be in the service catalog?
Endpoints relevant to every possible tenant?

This just seems to be a potential explosion of data that is poorly scoped
from a security perspective.

-joe

On Nov 13, 2012, at 1:42 PM, Joe Savak joe.sa...@rackspace.com wrote:
Will user-scoped token include the full service catalog?

Also, I thought the consensus was to allow the API contract to be flexible
on how many tenants we can scope the token to. The ref impl can enforce 1
tenant-scoped token. Are we diverging from this?

Thanks,
joe

-Original Message-
From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net
[mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On
Behalf Of heckj
Sent: Tuesday, November 13, 2012 1:34 PM
To: OpenStack Development Mailing List
Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens
representing authorization to projects/tenants in the Keystone V3 API

On Nov 13, 2012, at 11:01 AM, Jorge Williams jorge.willi...@rackspace.com
wrote:
On Nov 13, 2012, at 11:35 AM, heckj wrote:
So maintaining a token scoped to just the user, and a mechanism to scope
it to a tenant sound like all goodness. We can absolutely keep the API
such that it

[Openstack] [nova-network] question about nova-network

2012-11-14 Thread Ahmed Al-Mehdi

Hello,

I have two physical servers, one server configured as as the controller node 
(running all nova services, except nova-compute), and second server as a 
compute node (running nova-compute).  My question is how does the controller 
node know there is a compute node out there, and that all Vms should be 
instantiated on it?

Also, my understanding is when the first VM is instantiated, the bridge 
interface br100 will be created automatically by nova-network on the 
controller node.  I am assuming user has to manually create the br100 on the 
compute node(s).  Is that right?

The reason I ask is I am trying to instantiate a VM, but running into an error.


root@bodega:~/.ssh# nova flavor-list
++---+---+--+---+--+---+-+---+-+
| ID | Name  | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | 
Is_Public | extra_specs |
++---+---+--+---+--+---+-+---+-+
| 1  | m1.tiny   | 512   | 0| 0 |  | 1 | 1.0 | 
True  | {}  |
| 2  | m1.small  | 2048  | 10   | 20|  | 1 | 1.0 | 
True  | {}  |
| 3  | m1.medium | 4096  | 10   | 40|  | 2 | 1.0 | 
True  | {}  |
| 4  | m1.large  | 8192  | 10   | 80|  | 4 | 1.0 | 
True  | {}  |
| 5  | m1.xlarge | 16384 | 10   | 160   |  | 8 | 1.0 | 
True  | {}  |
++---+---+--+---+--+---+-+---+-+
root@bodega:~/.ssh# nova image-list
+--+-+++
| ID   | Name| Status | Server |
+--+-+++
| 19beac6b-5a46-4712-a5b5-99c6e99daa67 | cirros-0.3.0-x86_64 | ACTIVE ||
| 48cc3352-dff3-4625-87b1-143ba1953c57 | tty-linux   | ACTIVE ||
| 14652b05-0c27-45d1-b614-a059c9f4f7dc | tty-linux-kernel| ACTIVE ||
| c0f6a4df-5051-49d3-855e-8627c6c15ba6 | tty-linux-ramdisk   | ACTIVE ||
+--+-+++
root@bodega:~/.ssh#
root@bodega:~/.ssh#
root@bodega:~/.ssh# nova boot --flavor 2 --image 
19beac6b-5a46-4712-a5b5-99c6e99daa67  --key_name mykey  --security_group  
default cirros
+-+--+
| Property| Value|
+-+--+
| OS-DCF:diskConfig   | MANUAL   |
| OS-EXT-SRV-ATTR:host| None |
| OS-EXT-SRV-ATTR:hypervisor_hostname | None |
| OS-EXT-SRV-ATTR:instance_name   | instance-0001|
| OS-EXT-STS:power_state  | 0|
| OS-EXT-STS:task_state   | scheduling   |
| OS-EXT-STS:vm_state | building |
| accessIPv4  |  |
| accessIPv6  |  |
| adminPass   | 9RTkufdA6oaF |
| config_drive|  |
| created | 2012-11-14T22:55:42Z |
| flavor  | m1.small |
| hostId  |  |
| id  | 3c8acf5b-dd4a-4830-b5bb-faf87f8c7b18 |
| image   | cirros-0.3.0-x86_64  |
| key_name| mykey|
| metadata| {}   |
| name| cirros   |
| progress| 0|
| security_groups | [{u'name': u'default'}]  |
| status  | BUILD|
| tenant_id   | ce1e819636744dc680fa5515f6475e87 |
| updated | 2012-11-14T22:55:42Z |
| user_id | ce016bb05df949ebbafcc7c165359d7c |
+-+--+


/var/log/nova/nova-api.log has the following log messages:

2012-11-14 14:58:35 INFO nova.api.openstack.wsgi 
[req-ad86174c-09eb-4ef3-8ffa-ec8a42a5c9e6 ce016bb05df949ebbafcc7c165359d7c

Re: [Openstack] Getting approved to submit code for review for OpenStack Swift

2012-11-14 Thread Clay Gerrard

Hi Peter,

No, nothing special should be needed - sometimes it's tricky to get your
launchpad account hooked into to review.openstack.org - but if that's
giving you trouble just ask for help in #openstack-dev (we've all been
there).

So yeah, if you've got some code that helps fix a problem or is small
improvement that works for you - just push it on up - we'd love to take a
look at it!  We'll give you feedback if you have any questions.
http://wiki.openstack.org/GerritWorkflow should be mostly all you need.

OTOH, if you have a bigger idea for something new or different, it makes
the review process easier if you can talk a little bit about what you're
doing with some of the swift core devs - context really helps on something
big or new - plus if you can explain what you're thinking before you get
too far down in the weeds, sometimes they can warn you about any big
gotchas that may not be obvious at first but could complicate the
implementation just cause of some weird corner of the swift internals.
Technically I think there's also like a blueprint process (
http://wiki.openstack.org/Blueprints ?), but I'm not sure it's strictly
necessary.  But it'd be more paperwork for notmyname - so that's fun.

Either way, we'd love to hear about what you're doing with swift, you can
post back here on the openstack mailing list, or even better - easiest
place to find some swifters is in #openstack-swift on Freenode!

Welcome!

-clayg


On Wed, Nov 14, 2012 at 12:48 PM, Peter Portante peter.a.porta...@gmail.com
 wrote:

 Good afternoon,

 I was wondering if there is anything else I must do in order to get
 approved to submit code for review in Gerrit for OpenStack Swift.

 Thanks,

 -peter
 --
 This message was sent from Launchpad by
 Peter Portante (https://launchpad.net/~peter-a-portante)
 using the Contact this team's admins link on the OpenStack Contributors
 team page (https://launchpad.net/~openstack-cla).
 For more information see
 https://help.launchpad.net/YourAccount/ContactingPeople

___
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] Getting approved to submit code for review for OpenStack Swift

2012-11-14 Thread Peter Portante

Thanks Clay,

I don't have a big set of changes, they are minor tweaks really. Hopefully
the code changes will be simply enough to review without engaging in a more
involved discussion ahead of time.

You can find them talked about at:

Unnecessary https://answers.launchpad.net/swift/+question/213796  fetch of
metadata in DELETE's mkstemp context?
https://answers.launchpad.net/swift/+question/213796
wishlist: Enhance  https://bugs.launchpad.net/swift/+bug/1067108 internal
server-to-server logs to add referer and a user-agent
https://bugs.launchpad.net/swift/+bug/1067108

I looked folks up on openstack-dev, and one person said it takes a number of
hours for gerrit and launchpad to sync up. So I will try again tomorrow.

Thanks for the welcome,

-peter


From:  Clay Gerrard clay.gerr...@gmail.com
Date:  Wednesday, November 14, 2012 8:33 PM
To:  Peter Portante peter.a.porta...@gmail.com,
openstack@lists.launchpad.net openstack@lists.launchpad.net
Subject:  Re: Getting approved to submit code for review for OpenStack Swift

Hi Peter,

No, nothing special should be needed - sometimes it's tricky to get your
launchpad account hooked into to review.openstack.org
http://review.openstack.org  - but if that's giving you trouble just ask
for help in #openstack-dev (we've all been there).

So yeah, if you've got some code that helps fix a problem or is small
improvement that works for you - just push it on up - we'd love to take a
look at it!  We'll give you feedback if you have any questions.
http://wiki.openstack.org/GerritWorkflow should be mostly all you need.

OTOH, if you have a bigger idea for something new or different, it makes the
review process easier if you can talk a little bit about what you're doing
with some of the swift core devs - context really helps on something big or
new - plus if you can explain what you're thinking before you get too far
down in the weeds, sometimes they can warn you about any big gotchas that
may not be obvious at first but could complicate the implementation just
cause of some weird corner of the swift internals.  Technically I think
there's also like a blueprint process
(http://wiki.openstack.org/Blueprints ?), but I'm not sure it's strictly
necessary.  But it'd be more paperwork for notmyname - so that's fun.

Either way, we'd love to hear about what you're doing with swift, you can
post back here on the openstack mailing list, or even better - easiest place
to find some swifters is in #openstack-swift on Freenode!

Welcome!

-clayg


On Wed, Nov 14, 2012 at 12:48 PM, Peter Portante
peter.a.porta...@gmail.com wrote:
 Good afternoon,
 
 I was wondering if there is anything else I must do in order to get
 approved to submit code for review in Gerrit for OpenStack Swift.
 
 Thanks,
 
 -peter
 --
 This message was sent from Launchpad by
 Peter Portante (https://launchpad.net/~peter-a-portante)
 using the Contact this team's admins link on the OpenStack Contributors
 team page (https://launchpad.net/~openstack-cla).
 For more information see
 https://help.launchpad.net/YourAccount/ContactingPeople



___
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] create more than 16cores in one server

2012-11-14 Thread Edward_Doong

Dear,
i have some issue about: create more than 16 cores in one server.
i already change QUOTA at my Project by nova-manager project quota 
--project=x --keys=cores --value=64
and my flavor format is: 8vcpus 8mems 0Disk
  1vcpus 1mems 0Disk

my physical machine env.
Host Server: Ubuntu 12.04 openstack essex
   CPU: 24Cores MEM:64Gmems
Node1 : Ubuntu 12.04 openstack essex
   CPU: 24Cores MEM:64Gmems

Host instances distribution: A: 8vcpus 8mems 0Disk
B: 8vcpus 8mems 0Disk
Node1 instances distribution:  C~L: 1vcpus 1mems 0Disk = 1*10 =10vcpus 10mems

Frist Test: 
1.nova-manager service disable --serivce=nova-compute --host=Node1
2.create new instances by 1vcpu 1mem in Host Server  Fail

Sec. Test:
1.nova-manager service disable --serivce=nova-compute --host=host
2.nova-manager service enable --serivce=nova-compute --host=Node1
3.create new instances by 6vcpus 1mem in Node1  PASS 10+6=16Cores
4.create new instances by 1vcpus 1mem in Node1  Fail
5.Delete step3.4 instances. and create new instances by 8vcpus 1mem in Node1 
 Fail

could someone give me a hint to solve this issue???

Edward
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

2012-11-14 Thread Yee, Guang

Is belongsTo mandatory? If not, what will token validation API return?

{access: [list of tokens]}

?


Guang


-Original Message-
From: Jorge Williams [mailto:jorge.willi...@rackspace.com] 
Sent: Wednesday, November 14, 2012 2:47 PM
To: OpenStack Development Mailing List
Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
Subject: Re: [openstack-dev] [Openstack] Fwd: [keystone] Tokens representing
authorization to projects/tenants in the Keystone V3 API

From an API perspective the changes required are the following:

1.  The validate call returns a list of tenants instead of a single
tenant.

If the tenant id is in the URI of the API, then the validation middleware
can assert that the tenant id is in the list of IDs.

Not sure if there's any additional changes, but I don't think so.

An alternative approach is to use the belongsTo query parameter in the
validate call.  So if you know the tenantId of the resource, you can issue a
validate with ?belongsTo=tenatId  and validation if the tenant is not in
the list of tenatIds for the token.  The belongsTo query parameter is in the
validate token call in the API today

http://docs.openstack.org/api/openstack-identity-service/2.0/content/GET_val
idateToken_v2.0_tokens__tokenId__Admin_API_Service_Developer_Operations-d1e1
356.html

And we use it quite a bit in our implementation, when we validate tokens --
that is in the case where a token may have access to multiple tenants.

Thoughts?

-jOrGe W.


On Nov 14, 2012, at 3:53 PM, heckj wrote:

 If we're going to assert it's supported, we're doing an incredible
dis-service to writing a spec to not implement that aspect of the spec, as
that kind of set up just leads to incompatibilities and confusion when
asserting how the spec should be used to provide interoperability.
 
 If we accept this as a spec addition, then we MUST have an implementation
that makes it clear how we expect to interoperate with that aspect of the
specification, even if it's a configuration option that we don't normally
enable. If we don't test and validate it to prove interoperability, then the
spec is a worthless digital piece of paper.
 
 So under that pretext, I welcome suggestions on how to interpret the spec
you're proposing to some concrete implementations that can be verified for
interoperability, and that are compatible with the existing and/or upcoming
implementations for V3 API.
 
 -joe
 
 On Nov 14, 2012, at 1:35 PM, Joe Savak joe.sa...@rackspace.com wrote:
 Hi Joe,
  If I'm working across multiple tenants, I'd prefer one token that I
can securely handle that proves access rights to the tenants I'm working
with. Handling multiple tokens increases the complexity of clients needing
to provide multi-tenancy access to an authenticated identity. It also adds
more calls to keystone. 
 
 Again, I think that having the keystone reference implementation restrict
tokens to 1 tenant is fine. We shouldn't have such arbitrary restrictions in
the API contract though. It needs to be extensible and flexible to allow for
the all sorts of use cases that are likely to occur.
 
 Thanks,
 joe
 
 -Original Message-
 From: heckj [mailto:he...@mac.com] 
 Sent: Tuesday, November 13, 2012 3:59 PM
 To: Joe Savak
 Cc: OpenStack Development Mailing List; openstack@lists.launchpad.net
(openstack@lists.launchpad.net)
 Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens
representing authorization to projects/tenants in the Keystone V3 API
 
 Hey Joe:
 
 Currently a user scoped token doesn't include a service catalog - mostly
because I think the service catalog generally requires tenant_id's to
interpolate into the values to provide it. That doesn't mean we can't put
in/include service catalog endpoints where that value doesn't need to be
determined.
 
 I'm also questioning the value of providing a token scoped to all tenants
associated with a user - that seems to have the same value as just using a
user token. 
 
 In fact, even if we allow some arbitrary set of tenants to be scoped into
a token along with a user, what on earth should be in the service catalog?
Endpoints relevant to every possible tenant?
 
 This just seems to be a potential explosion of data that is poorly scoped
from a security perspective.
 
 -joe
 
 On Nov 13, 2012, at 1:42 PM, Joe Savak joe.sa...@rackspace.com wrote:
 Will user-scoped token include the full service catalog? 
 
 Also, I thought the consensus was to allow the API contract to be
flexible on how many tenants we can scope the token to. The ref impl can
enforce 1 tenant-scoped token. Are we diverging from this?
 
 Thanks,
 joe
 
 -Original Message-
 From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net
[mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On
Behalf Of heckj
 Sent: Tuesday, November 13, 2012 1:34 PM
 To: OpenStack Development Mailing List
 Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
 Subject: Re:

Re: [Openstack] Couldn't find stack-screenrc

2012-11-14 Thread Chmouel Boudjnah

On Thu, Nov 15, 2012 at 4:09 AM, Everett Toews everett.to...@rackspace.com
wrote:

 From: Johannes Baltimore johannes.b...@gmail.com
 Date: Wednesday, November 14, 2012 8:34 AM
 To: openstack@lists.launchpad.net openstack@lists.launchpad.net
 Subject: [Openstack] Couldn't find stack-screenrc

 Hi.

 I got devstack today, but I've been going through a problem. Whenever i
turn
 on the machine, I cannot run the rejoin-stack.sh script, even though I've
 ran stack.sh before. It says the stack-screenrc file couldn't be found,
and
 then asks me to run stack.sh again. Does anyone knows why does this
happen?

 Thanks in advance

 ---

 Did you run stack.sh as root?

Not sure why the screenrc was not created but how do you run stack.sh as
root? There is a mechanism in the script to avoid that :

if [[ $EUID -eq 0 ]]; then
ROOTSLEEP=${ROOTSLEEP:-10}
echo You are running this script as root.
echo In $ROOTSLEEP seconds, we will create a user 'stack' and run as
that user
sleep $ROOTSLEEP

Chmouel.

 I've noticed that when you start as root the stack-screenrc file doesn't
get
 created. You can copy over an old stack-screenrc or just start it as a new
 user.

 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

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

35 matches

Mail list logo