Re: [Openstack] devstack issue related to Python-keystoneclient
On Thu, Jul 25, 2013 at 11:05 AM, Jay Lau jay.lau@gmail.com wrote: Thanks Davanum for the quick response! Can you please show me the configuration for how to disable Horizon in localrc? In localrc: disable_service horizon This particular problem appears to be due to out-of-date source trees, in this case an older horizon with an out of date requirements.txt. Try this: grep keystoneclient /opt/stack/*/requirements.txt /opt/stack/*/tools/*requires* and see of any lines in the output have '0.3' at the end of them. If so, it's out of date. Refresh that repo (RECLONE=yes is helpful here) or rebase it if you are working on that one. This all assumes you're running trunk... dt -- Dean Troyer dtro...@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] devstack issue related to Python-keystoneclient
On Thu, Jul 25, 2013 at 11:14 AM, Dean Troyer dtro...@gmail.com wrote: This particular problem appears to be due to out-of-date source trees, in this case an older horizon with an out of date requirements.txt. I should add...providing the output of tools/info.sh is extremely helpful in debugging these sorts of things remotely... dt -- Dean Troyer dtro...@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] Image prep. cloud-init user configuration help.
On Tue, Jul 23, 2013 at 1:49 AM, Jake G. dj_dark_jungl...@yahoo.com wrote: I am following the part on how to set up cloud-init from the below guide, but I was wondering how to change the user? I do not have the default ec2-user on my instance image. Do I just create this user in the instance? What permissions do I give the user? About half way down this page (http://hackstack.org/x/blog/2013/04/25/a-centos-6-image-for-openstack/) is a link to a centos 6 kickstart file that configures cloud-init during the kickstart %POST phase to behave similar to how it works on Ubuntu images by default: create a 'centos' user with sudo permissions to root. dt -- Dean Troyer dtro...@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] Keystone Identity API v3 interface
On Mon, Jun 24, 2013 at 2:00 PM, Ruslan Kiianchuk ruslan.kiianc...@gmail.com wrote: Perhaps, --os-url is new parameter in openstackclient (can't remember it using in keystoneclient). By the way, a doc mentions that --os-url is a URL keystoneclient uses --os-endpoint for the same thing. to OpenStack service. Do they mean URL of the Nova API on controller node or something else, do you know? It is the service URL that would have otherwise been obtained from the service catalog. In the library CLIs it is obvious how it is used but in openstackclient it must match the API supporting the command that you are using...i.e: openstack ... --os-url http://169.254.169.200:9292/ server list will fail as you are sending a compute API command to the (presumably from the port) image API endpoint. dt -- Dean Troyer dtro...@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] Devstack usage in Install Openstack
On Sat, May 11, 2013 at 3:30 AM, Mahzad Zahedi ict.mywork2...@gmail.com wrote: But how to add my ESXi servers and so on to it ? what is usage of dashboard? is it just a demo?? ... Plz help me .if using Devstack is just a demo i should go to install real openstack. DevStack is designed to be a development environment and is also used in the OpenStack integration tests. It should never be used for production. You may be able to configure it to include your ESXi servers but will likely have to do some of that configuration by hand. You should probably consider installing from one of the vendor package sets if you want to operate your setup for any length of time or have plans to eventually open it up to other users, even just for testing. DevStack re-initializes everything from scratch every time you run stack.sh. dt -- Dean Troyer dtro...@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] [OpenStack][DevStack] How to contribute?
On Tue, May 7, 2013 at 9:16 PM, Gareth academicgar...@gmail.com wrote: In OpenStack 'how-to-contribute' document, the first step is join the team in Launchpad. All of ~swift, ~nova, ~glance are ok. But ~devstack is a restricted team here[1]. Does that 'joining the team' is a necessary step for contributing? Not for DevStack, the only team we have set up is the core team. IIRC, if you are not a member of any other teams you would need to join the OpenStack team[1] that is linked in the grey box under the team list. Otherwise you just need to have completed the CLA-related bits that allows you to send reviews to Gerrit. dt [1] https://launchpad.net/~openstack -- Dean Troyer dtro...@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] Fwd: Nova API Keypairs
On Thu, Apr 25, 2013 at 8:34 AM, Anne Gentle a...@openstack.org wrote: Can you better explain to Jamie how keypair injection works and what Compute API commands correspond with the Dashboard creation and association of keypairs? I'll take a stab at the basic use of keypairs from the Nova CLI. I don't think Horizon does anything drastically different than this. DevStack has an example in https://github.com/openstack-dev/devstack/blob/master/exercises/boot_from_volume.sh that may be useful. Lines 123-129 demonstrate removing an old keypair and adding a new one with the same name. (In the DevStack case, a new keypair is generated on every run, this is not how things normally work, hence the delete.) This shows how Nova will generate the pair and return the private key as the output. You must capture it then, there is no way to get it later. Line 161 shows how to use it during the server boot process. The other way is to use existing ssh keypairs and is how I do things in my own scripts. Add an existing ssh public key to Nova (set KEYNAME to something unique, I often use `hostname`): # ensure keypair is present if ! nova keypair-list | grep -q $KEYNAME; then nova keypair-add --pub_key=$HOME/.ssh/id_rsa.pub $KEYNAME echo Added keypair for $KEYNAME fi KEY=--key-name=$KEYNAME Then, later in the nova boot command: nova boot ... $KEY ... servername In either case you should be able to ssh directly into the instance. In the first case (Nova generating the keypair) remember to tell ssh to use the private file with -i private-key-file. dt -- Dean Troyer dtro...@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] [Glance][Image-Create][OZ]
On Tue, Mar 19, 2013 at 4:41 AM, Jiang Jim jiangwt...@gmail.com wrote: found miss cmdline section in the instance i launch by qcow2. When I add it to libvirt, I can add output to /dev/ttyS0. Is qcow2 images can not out put the system log while ami does? It has nothing to do with the image format and everything to do with (as you found) the command line options baked into the image. Plus the grub configuration if you are using and expect to see the grub menu. My normal tactic is to: * add this to the kernel command line (usually in Fedora kickstart files): console=tty console=ttyS0 * set in /etc/default/grub: GRUB_TERMINAL=console GRUB_CMDLINE_LINUX=console=ttyS0 console=tty GRUB_CMDLINE_LINUX_DEFAULT=console=ttyS0 dt -- Dean Troyer dtro...@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] Unauthenticated service probe for OpenStack components
On Thu, Mar 14, 2013 at 3:40 PM, Tim Bell tim.b...@cern.ch wrote: Currently, curl to the service URL just gives 401 error. Check the exit code, it should be 0 because that 401 error is generated by the api server. It's alive and responding, just not with 200 codes. If the server doesn't respond curl's exit code is non-zero (7 I think?). We did the same thing in DevStack for checking api server responses. dt -- Dean Troyer dtro...@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] Are the Python APIs public or internal?
On Fri, Mar 1, 2013 at 11:50 AM, Miller, Mark M (EB SW Cloud - RD - Corvallis) mark.m.mil...@hp.com wrote: I have a question about the keystone client. You just mentioned keystoneclient.v3. I was under the impression that the keystone client was going to be deprecated and replaced by the openstackclient. However, when I checked yesterday I noticed that the openstackclient was listed as “abandoned”. Are you saying that an updated version of the keystoneclient will shortly be made available for V3? If so, would you please post the URL for the project? Where is openstackclient marked abandoned? It is still under development, albiet at a slower pace than I'd like. It is meant to be a single CLI for OpenStack that leverages the libraries provided by the individual project clients. So it uses the keystoneclient python libs but not the cli/shell bits. dt -- Dean Troyer dtro...@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] n-api installation problem with devstack (on Ubuntu )
On Thu, Feb 14, 2013 at 3:45 AM, swapnil khanapurkar
contact2swapni...@gmail.com wrote:
But the nova-api is running at http://10.233.53.154:8774
root@vmfolsom154:~/devstack# wget -q -O- http://10.233.53.154:8774
{versions: [{status: CURRENT, updated: 2011-01-21T11:33:21Z,
id: v2.0, links: [{href: http://10.233.53.154:8774/v2/;,
rel: self}]}]}
You appear to have another nova api process running that is bound to
8774. lsof will help you find it.
So where/which file can I change 127.0.0.1 to 10.233.53.154?
And how can I configure/edit in nova.conf file.As I am using
devstack,the settings are default and they are overwritten everytime i
run ./stack.sh.
Much of the configuration in nova.conf can be set in DevStack's
localrc. Looking through lib/nova will help you find the variable
names that are available for modification.
You can set HOST_IP in localrc to force all of the services to bind to
a specific IP.
dt
--
Dean Troyer
dtro...@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] openstack client question
On Tue, Feb 12, 2013 at 5:32 PM, Miller, Mark M (EB SW Cloud - RD - Corvallis) mark.m.mil...@hp.com wrote: I recently installed the latest openstackclient hoping to find support for the new Grizzly V3 Keystone commands (i.e. groups, domains, credentials, etc.). Will these commands be added to the client in the future or will we need to use the curl command to execute REST calls against the Keystone APIs? openstackclient is very much a work-in-progress overall, as are the Identity v3 commands. group and project are present but you have to specify the Identity API version 3 to use them: --os-identity-api-version=3 on the command line or OS_IDENTITY_API_VERSION=3 in the environment). Steve has a proposal at https://review.openstack.org/20854 that supports credential, domain and policy objects but IIRC it needs some updates for both the entrypoint changes from last week and possibly some recent API changes. dt -- Dean Troyer dtro...@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] How to generate an API key
On Fri, Feb 8, 2013 at 9:19 AM, Anne Gentle a...@openstack.org wrote: My understanding is that API keys are a provider's term. They are specially generated per user by the provider. In general, Anne is right that a word like 'key' is context sensitive. AWS and Rax use it for access to the APIs but in different ways. The only place that OpenStack itself uses it in a user context is in relation to the EC2 API or the ssh keypairs. In regards to the EC2 keys, they can be generated with this: keystone ec2-credentials-create The other place 'key' is used is with the ssh key pair used for instance logins. Those are also long-lived and generated on demand. However they are not related to controlling API acces, just to controlling login to running instances. They are controlled in the Compute API and can be seen with: nova help | grep key dt -- Dean Troyer dtro...@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] running devstack
On Fri, Jan 11, 2013 at 7:34 AM, Snider, Tim tim.sni...@netapp.com wrote: But then trying to run any of the exercises fails with X11 connection rejected because of wrong authentication. What didn't I get setup correctly? The first rulle of devstack is don't run as root. The second rule of devstack... Only stack.sh has the defensive prevent-running-as-root code in it. It'll create a 'stack' user if it doesn't exist then switch to it and exec itself and leave you in a shell as 'stack'. root@84Server:~/devstack/exercises# ./client-env.sh * Begin DevStack Exercise: ./client-env.sh * Test Keystone X11 connection rejected because of wrong authentication. This looks like an ssh client message. I have no idea why it would appear here as we don't use ssh directly for anything in that test. As Sean suggested set up your environment and try a couple of things by hand: # cd to devstack directory . openrc admin admin keystone catalog --service identity # if that doesn't work try: keystone --debug catalog It is possible that the keystone database did not get initialized properly. If you are still having trouble, the output of tools/info.sh would also bee useful to see. dt -- Dean Troyer dtro...@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] keystone start fails due to mysql password mismatch running stack.sh
On Fri, Jan 11, 2013 at 2:13 PM, Snider, Tim tim.sni...@netapp.com wrote: The localrc file has the correct unencoded password: root@84Server:~/devstack# cat localrc FLOATING_RANGE=192.168.1.224/27 FIXED_RANGE=10.0.0.0/24 FIXED_NETWORK_SIZE=256 FLAT_INTERFACE=eth0 ADMIN_PASSWORD=infiniti MYSQL_PASSWORD=infiniti RABBIT_PASSWORD=infiniti + mysql -uroot -pec0ff00c787573ed5ea2 -e 'DROP DATABASE IF EXISTS keystone;' OK, this is the clue... the password in mysql commands is not encoded, it is $MYSQL_PASSWORD. And in fact that isn't an encoded password but an auto-generated one from the read_password function that creates a password if one is not entered using 'openssl rand -hex 10'. Something is stomping on your MYSQL_PASSWORD from localrc. Is that value different on each run? dt -- Dean Troyer dtro...@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] Stopping Devstack from running
On Thu, Dec 20, 2012 at 9:10 PM, Sankha Narayan Guria sankh...@gmail.com wrote: I had installed Devstack on my Ubuntu system from http://devstack.org/ and it runs everytime when I boot my system. Is there a way to stop that? Nothing is mentioned on their website. The only bits of DevStack that are set to automatically run at boot are the service packages provided by the OS such as Apache (as you found), the database server (MySQL by default), the queue server (rabbitmq by default) and tgt if you have cinder enabled.. Are you saying that you get all of the services running in screen on boot? That would mean that stack.sh or rejoin-stack.sh is being run by a boot script and it shouldn't be. Oddly enough there are a number of people that wish DevStack would survive a reboot. We actively discourage that to keep it from being used for more than development. dt -- Dean Troyer dtro...@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] LVM over LVM is acceptable?
On Mon, Nov 26, 2012 at 8:04 PM, Lei Zhang zhang.lei@gmail.com wrote: Another question. If the vm treat the vol-0 as a normal block device, is it necessary to partition? If not, the fdisk will show Disk /dev/vdb doesn't contain a valid partition table. If yes, how can I extend the volume on the vm? It seems that treat the volume as a normal block device is not a good idea. It is not necessary to partition the device (vdb) inside com-0. If you use it as an LVM physical device (PV) inside com-0 then pvresize will update the metadata o recognize the new size inside com-0 after you lvextend the vol-0 in the host. If you do partition /dev/vdb and don't use LVM in com-0 it is still possible to grow a partition, but you'll have to delete and re-create the last partition to get com-0 to recognize the additional space. And you'd also need to do the filesystem resize too. Nested LVM can be tricky but if you are careful to keep the layers separated it can work. dt -- Dean Troyer dtro...@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] [devstack] Malformed Documentation on stack.sh script web site
On Wed, Nov 7, 2012 at 9:27 AM, Gui Maluf guimal...@gmail.com wrote: In http://devstack.org/stack.sh.html above Log Files, the whole documentation is malformed. All descriptions stop to match with the current piece of code. I don't know who to warn, so I'm sending this email here. Actually, it is the reverse that is the case...everything _after_ Log Files is broken. We use shocco to format those pages from the bash scripts. It treats the comments as documentation and puts it to the left of the code that follows. This is why there is markdown formatting in the comments of devstack scripts. In this particular case, the spinner string was being improperly recognized by shocco and it stopped formatting the output. This is a good excuse to do another periodic doc/formatting pass through stack.sh, I'll commit this fix then. dt -- Dean Troyer dtro...@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] Could I restart devstack with old configuration?
On Thu, Oct 25, 2012 at 10:03 AM, Tong Li liton...@us.ibm.com wrote: you can run rejoin-stack.sh from devstack directory to restart the whole thing. However, there are some problems dealing with volume. But other services should be OK. rejoin-stack.sh only addresses restarting the processes running under screen. If you've used unstack.sh or rebooted it will probably not bring everything back. We do need restack.sh to undo unstack.sh. ;) As an alternative, if/when you do want to start with a fresh install but have additional things to add you can create local.sh to do that work at the end of stack.sh. There is an example in samples/local.sh. dt -- Dean Troyer dtro...@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] Folsom on Oracle VirtualBox using qemu
On Tue, Oct 2, 2012 at 12:08 PM, Chandra Kamalakantha chandra_kamalakan...@yahoo.com wrote: Has anyone running into this error listed below while starting nova-compute (Folsom release) on Oracle VirtualBox using qemu as virtualization type? CRITICAL nova [-] Class LibvirtDriver could not be found: 'module' object has no attribute LibvirtDriver # Virt driver connection_type=libvirt Try removing connection_type and adding the following: compute_driver=libvirt.LibvirtDriver This changed between Essex and Folsom... dt -- Dean Troyer dtro...@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] Setting Expectations
On Tue, Aug 14, 2012 at 1:06 PM, Andrew Clay Shafer
a...@parvuscaptus.com wrote:
You say OpenStack has survived, but I believe we may have compounded and
multiplied the challenges OpenStack faces by collectively neglecting to
resolve this. Without going into all the technical necessity and political
complexity, I would argue we allowed OpenStack fragmentation at the project
level. Without a unified conscience of purpose, the fragmentation only gets
magnified at the point users are interacting with different deployments.
This fragmentation with projects and goals is a real threat to the
long-term viability of OpenStack as a cloud standard.
I don't believe that the kernel is a perfect analogy, but even if it was
this one sentence 'OpenStack is like the Linux kernel' will not make it so.
Honestly, I HATE this analogy. OpenStack has no BDFL, it has now a
foundation that is governed by Corporate interests that have a history
of working on common standards and tweaking them to add 'value'
('differentiation' I think is the buzzword for that). The
organization of the foundation is partially designed to prevent any
one or two of these interests from pushing the whole in their
particular direction. The foundation will have to prove itself
capable of pulling the projects forward. Together.
What is the OpenStack equivalent of this?
https://lkml.org/lkml/2012/3/8/495
The problem we have is that people in Linus' position are not created,
they grow and the position, respect and authority is earned. The TC
may be able to earn some of that over time, but without unifying
leadership it will be tough going. Hopefully their separation from
the rest of the board can give them a chance to provide the technical
leadership and direction needed even if it stubs a few toes along the
way.
It kills me that the acronym for OpenStack Foundation is OSF. While I
don't think we can really be the Linux of the cloud any time soon, we
will have to really work to NOT be the UNIX of the cloud...
dt
--
Dean Troyer
dtro...@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] devstack + exercise.sh failures
On Thu, Aug 9, 2012 at 2:33 PM, Thomas Gall thomasag...@gmail.com wrote: FAILED boot_from_volume FAILED euca FAILED floating_ips FAILED volumes These all spawn instances so there's the first thing to check... I'm new so certainly possible I've missed an email/bug that documents this. I did also try on f17 but the results were exactly the same. Not that it should matter but I have devstack running inside of a kvm partition. Nothing obvious seems amiss. Yes, running inside a VM does make a difference, mostly in the default timeouts. Also, how much ram does your devstack VM have? You'll need 1G minimum to run everything unless you have Swift enabled, then at least 1.5G. localrc has nothing in it but the settings for MYSQL_PASSWORD, RABBIT_PASSWORD, SERVICE_TOKEN, SERVICE_PASSWORD, ADMIN_PASSWORD I usually set the following timeouts running in a Rax VM (VirtualBox often needs a bit longer for me): # Timeouts ACTIVE_TIMEOUT=120 ASSOCIATE_TIMEOUT=60 BOOT_TIMEOUT=120 SERVICE_TIMEOUT=120 If you immediately do the following: . openrc nova list after the exercise failure, what to you see? If there is one running VM and maybe one or more in error state, you may be up agains the timeouts or possibly don't have enough RAM in your devstack vm. Try running just one exercise at a time to debug this, exercises/floating_ips.sh is what I usually use. Another trick I use to reduce the RAM required for the VMs is to create an m1.miro flavor and set in localrc: DEFAULT_INSTANCE_TYPE=m1.micro The exercises will honor that in selecting the VM to create when they run. The commands to do that are in samples/local.sh in the devstack directory. dt -- Dean Troyer dtro...@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] Command Argument Naming Style
On Thu, Jul 19, 2012 at 4:36 AM, Hua ZZ Zhang zhu...@cn.ibm.com wrote: I found an interesting thing about the naming style of current command arguments. it is a little difference across different components. you can see nova/quantum/swift/keystone are using both dash '-' and underline '_'. Only keystone is mixed with two style: --xx_yyy_zzz --xx-yyy-zzz And glance use the --xx-yyy-zzz style which only contains dash '-'. IMO, it's better to be consisitent in naming style for all core components, including the usage text. secondly, avoid using same argument name with different meanings or different argument name for the same meaning. Thirdly, keep it simple as possible, don't use unnecessary symbols. We strive for consistency and unfortunately we are still not there yet. The goal is to use '-' in option names everywhere but we also have backward compatibility to consider. Glance and keystone are the two that I've managed to complete so far, the others are on my list and I haven't gotten there yet. The goal is to add the options containing '-' and document those while maintaining the options containing '_' for compatibility and documenting them as deprecated, if at all, and to be removed sometime in the future (6 months at least). FWIW, glance will never have the '_' option names because it is a new client and already breaks backward compatibility with the original glance client. dt -- Dean Troyer dtro...@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] UnifiedCLI suggestion
On Mon, Jun 25, 2012 at 5:28 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Mon, Jun 25, 2012 at 6:19 PM, Ken Thomas k...@yahoo-inc.com wrote: [...] I've already submitted the keystone changes for review (https://review.openstack.org/#/c/8958/3/keystoneclient/shell.py) and I'd be happy to make the same change to UnifiedCLI as well. Thanks, Ken! That sounds like a good change to make. If you add me as a reviewer on the patch, I'll make sure to look at the changes. I created a blueprint for this: https://blueprints.launchpad.net/python-openstackclient/+spec/password-prompt linking back to the keystone blueprint. That looks like a good solution. Thanks Ken dt -- Dean Troyer dtro...@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] [Devstack]Keystone authentication problem when installing
On Wed, Jun 27, 2012 at 9:34 PM, Ke Wu ke...@ibeca.me wrote: Here is my localrc: ENABLED_SERVICES=$ENABLED_SERVICES,swift MYSQL_PASSWORD=password ADMIN_PASSWORD= password RABBIT_PASSWORD= password SERVICE_TOKEN= password SWIFT_HASH= password Do you have spaces following the '=' as shown above? If so that will put a space as the first character of the value. HOST_IP=10.0.0.0 If you set HOST_IP it should be set to the IP address of your primary interface, not a network address. Could you show us the lines _before_ the error log you posted? Specifically, I'd like to see the group of variable assignments immediately before keystone_data.sh is called. dt -- Dean Troyer dtro...@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
[Openstack] [devstack] Recent updates
A quick summary of recent significant DevStack changes: * Keystone Service Catalog SQL back-end Add KEYSTONE_CATALOG_BACKEND=sql to localrc to tell Keystone to use the SQL backend for the service catalog. This enables the keystone service-* and endpoint-* commands to manage the service catalog. See files/keystone_data.sh for the default commands used by DevStack. DevStack continues to use the templated service catalog by default. * Remove default services from ENABLED_SERVICES This change allows easy the removal of services that are in ENABLED_SERVICES by default (see the list in stackrc) by appending the service name prefixed with a '-' to ENABLED_SERVICES. For example, to switch from Nova Volumes to Cinder, you would add this to localrc: ENABLED_SERVICES+=,-n-vol,c-api,c-sch,c-vol (Note the leading comma following the equals sign) * Cinder Support Speaking of Cinder, basic support was merged last week. Since it is still a bit of a moving target additional updates may still be required. Enable Cinder as shown in the ENABLED_SERVICES section above. Nova Volume will remain DevStack's default until some time after Cinder becomes the default in Nova. * The default volume group name has changed to stack-volumes to remove the nova project name (it was formerly nova-volumes). Set it in localrc with VOLUME_GROUP. * The default backing file is now /opt/stack/data/stack-volumes-backing-file (it was formerly /opt/stack/nova-volumes-backing-file). Set it in localrc with VOLUME_NAME_PREFIX. * Colored logs Vish added color to Nova's logs a couple of weeks ago to greatly help visually scanning the log files. Set LOG_COLOR=False in localrc to disable the color as it is enabled by default. Also note that if SYSLOG=true the log coloring is also disabled. dt -- Dean Troyer dtro...@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] horizon install from devstack fails to find glanceclient/versioninfo
On Tue, Jun 26, 2012 at 3:43 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Thanks for the pointer to the devstack change. I +1ed, but don't have commit review access there to do any more than that. It just merged...I've requeued a couple of reviews that failed earlier due to this problem, we'll see how it goes. dt -- Dean Troyer dtro...@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] horizon install from devstack fails to find glanceclient/versioninfo
On Tue, Jun 26, 2012 at 6:37 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: OK, I got past that part but now I'm seeing an error about a missing volume group stack-volumes. Is that related to enabling cinder? The only settings I have in my localrc file are passwords. Is there something else I need to do to ensure cinder is on? I use this to enable cinder: ENABLED_SERVICES=$(echo $ENABLED_SERVICES | sed 's/n-vol/c-api,c-sch,c-vol/') But the volume group should be created either way. The cinder patch did change its name from nova-volumes to stack-volumes though. dt -- Dean Troyer dtro...@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] [devstack] Easing maintenance of list of distro packages to install
On Wed, Jun 20, 2012 at 5:06 AM, Vincent Untz vu...@suse.com wrote: - this leads to incomplete updates for dependencies. It happens that someone updates the apts files but not the rpms ones. (shameless This is going to always be a problem, independent of the mechanism used to manage package lists. The simple fact is that we really only develop DevStack on Ubuntu, anything else is a second-class citizen by definition. I do test Fedora periodically, but as of this point those are the only two distros we have committed to support, and Fedora still lags (try running stack.sh on f17 sometime). - this just doesn't scale when adding support for another distro, especially as rpm-based distros don't all share the same package names (hence files/rpms/ cannot really be shared). The directory names could easily be anything else, it was originally meant to distinguish packages (apts) vs pips. I already have some working code for that, but I want to check if people are fine with the idea before submitting it for review. We have had other package dependency schemes proposed in the past, in the end the issue isn't the mechanism but the support. As it is the Fedora lists still often lag unless I can catch a review and prompt the author to add the required entry in the rpms directory Support aside, anything that we might adopt will necessarily be kept simple, such as changing the packaging names (apts/rpms) to packager names (ubuntu,fedora,etc). dt -- Dean Troyer dtro...@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] New layout of the OpenStack mailing lists
On Fri, May 25, 2012 at 10:49 AM, Stefano Maffulli stef...@openstack.org wrote: The rationale is that in 2012 we have better ways to send announcements out: blogs, RSS, twitter, G+, newsletters, etc. Besides, the list hasn't been used for months and nobody complained for the lack of content. Just because it hasn't been used doesn't mean it shouldn't be used...there have been a number of notices on the -dev list recently that could/should have gone out on announcements (folsom-1 yesterday?). In any case, my idea is to replace the list with a newsletter: people interested in receiving regular updates (like the weekly newsletter I send out) will subscribe there. Part of the point of low-volume announce lists is that when something _does_ show up from there you pay attention to it. I don't think parsing through a newsletter achieves the same result at all, neither do blogs or twitter/FB/G+ unless those accounts are functional equivalents to -announce, then its just a matter of remembering to go check them. dt -- Dean Troyer dtro...@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] devstack installation failing
On Fri, May 25, 2012 at 1:53 AM, Vaze, Mandar mandar.v...@nttdata.com wrote: You can run the following command on the terminal from the directory that has all your Openstack projects (e.g. from /opt/stack) “cd /opt/stack ; for d in `ls -1`; do echo updating $d; cd $d; git pull; cd /opt/stack; done” You can also put 'RECLONE=yes' in front of stack.sh on the command line or add it to localrc to force stack.sh to update all repositories. RECLONE=yes ./stack.sh dt -- Dean Troyer dtro...@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] devstack multi-node tutorial fails
On Thu, May 24, 2012 at 4:46 AM, Mauch, Viktor (SCC) ma...@kit.edu wrote: H, who would be the responsible person to make corrections and insert some more comments to the current multi node tutorial of devstack?? The devstack.org site is built from the gh-pages branch of devstack at https://github.com/cloudbuilders/devstack/tree/gh-pages. Clone that, make your changes and send a pull request. Let us know you've done that, it's the only time that we use pull requests in that repo. dt -- Dean Troyer dtro...@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] nova user management without the dashboard
On Thu, May 24, 2012 at 1:36 PM, Sharif Islam isla...@indiana.edu wrote: the dashboard and grabbing the file. However, keystone seems to not have a equivalent command like this: nova-manage project zipfile projectname username username-projectname-nova.zip It isn't a complete replacement, but you can get your ec2 creds form keystone like this: keystone ec2-credentials-create You should be able to use https://github.com/openstack-dev/devstack/blob/master/eucarc as a model for turning that into a novarc file. dt -- Dean Troyer dtro...@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] Quantum+Openvswitch: could not open /dev/net/tun: Operation not permitted
On Thu, May 24, 2012 at 3:05 PM, Igor Laskovy igor.lask...@gmail.com wrote: kvm: -netdev tap,ifname=tap24b9f3da-8b,script=,id=hostnet0: could not open /dev/net/tun: Operation not permitted By chance I just happened to find the solution this afternoon...add the following to /etc/libvirt/qemu.conf and restart libvirt: cgroup_device_acl = [ /dev/null, /dev/full, /dev/zero, /dev/random, /dev/urandom, /dev/ptmx, /dev/kvm, /dev/kqemu, /dev/rtc, /dev/hpet, /dev/net/tun, ] It is possible that the list can be pared down, I pulled that verbatim from http://fedoraproject.org/wiki/Quantum. dt -- Dean Troyer dtro...@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] About openstack common client
On Fri, May 18, 2012 at 12:16 AM, Yong Sheng Gong gong...@cn.ibm.com wrote: I just want to ask about the relationship among openstackclient https://launchpad.net/python-openstackclient and other clients. Will openstackclient replace other clients ( such as quantum client, keystone client, nova client, xx) or just a supplement? It will be a fully-functional-and-then-some replacement. by now, the openstackclient is calling codes from other clients, so it seems it is just another client wrapper. In this case, we will have to implement two set of front codes to call specific client. One will be in openstackclient, and one will be in separate client itself. I'm not sure what you are implementing here; if it is an interface that uses the CLI to drive OpenStack then you only need to talk to one CLI (openstackclient) or to the existing CLIs (*client). openstackclient has an advantage for scripted use in that it has an option for easily parsable output. dt -- Dean Troyer dtro...@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] About openstack common client
On Fri, May 18, 2012 at 9:17 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: I expect non-common shell clients to be deprecated and eventually ripped out. We're probably a bit too early in the game to explicitly discourage development on those shell commands though. I'm waffling on agreeing with you here. It is true that (AFAIK) we aren't set up for packaging builds yet for semi-official installations (i.e., not using devstack), but I would like to have people who are more familiar with the other command line programs contributing to the common client, too. I expect the existing project-specific CLIs to be around fot some time. The bit that openstackclient replaces is actually pretty small code-wise so maintaining them isn't as much duplicated work as it might seem. dt -- Dean Troyer dtro...@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
[Openstack] [client] final openstackclient binary name
There has been a little more activity in the discussion in http://etherpad.openstack.org/FolsumCLI this week regarding the name of the python-openstackclient binary. It is currently 'stack'. Summary of the vote as of now: openstack: net +2 stack: net +1 ost: net 0 fog: net -1 oscli: -3 I have proposed https://review.openstack.org/7024 to change it to 'openstack'. We'll wait a day or two for opinions/votes to collect in the review. Thanks dt -- Dean Troyer dtro...@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] [client] Where will client API libraries live?
On Wed, May 2, 2012 at 9:13 AM, Lorin Hochstein lo...@nimbisservices.com wrote: Will the new unified CLI also provide Python bindings, so people can write Python scripts against the libraries that ship with the CLI (like python-novaclient)? Or is that out of scope? We use the existing API libraries from python-*client projects. openstackclient replaces the shell (UI) of the existing clients. does it include client API libraries? * not directly, abstract out common ancestor classes We discussed at the summit factoring out the common bits of the API libraries and putting those into openstackclient, but that is not the immediate priority. I think we need a bit more thought about use cases for, say, glanceclient requiring openstackclient even in a stand-alone installation. dt -- Dean Troyer dtro...@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] [client] creating blueprints for the unified CLI project
On Wed, May 2, 2012 at 10:18 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Maybe I'm doing this wrong. I wanted to make a list of the things I know we have to do, so people who don't have access to the inside of my head can divy up the list (that's a short list). These things are features not bugs so I thought blueprints was the right way to go. It's fine to log to-dos as bugs especially if they're not big changes. Blueprints are generally used to outline larger changes/features/etc. They get prioritized, and assigned like bugs but also have the ability to target them to future releases (we don't have any set up yet). For example, the api-versioning should outline the implementation of handling multiple API versions. devstack-integration could have been a bug; that can also be assigned to the devstack project and tracked to a review when it is closed. I did a quick prioritization pass on the blueprints just now. dt -- Dean Troyer dtro...@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] [client] creating blueprints for the unified CLI project
On Wed, May 2, 2012 at 1:51 PM, Matt Joyce m...@nycresistor.com wrote: I skipped out on blue printing and just submitted a gerrit review for adding argparse flags for specifying URL for specific APIs. Why is this needed? These URLs come from the service catalog. Cases where you do need to override that use --os-url as part of token flow auth, skipping the service catalog. Is that cool or do we want blue prints at that level of low complexity? There should be some sort of discussion for design changes/additions. Blueprints are a way to do that and record the discussion and target/track the work. These discussions do happen in the Gerrit review comments too, but those are more reactive than proactive. BTW, rather than abandon your initial change, you could have made the update, commited with 'git commit -a --amend' and push a new patchset with 'git review'. As long as the change id in the log message doesn't change Gerrit does the Right Thing. See the bottom of http://wiki.openstack.org/GerritWorkflow for details. dt -- Dean Troyer dtro...@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] OpenStack Client Followup
On Tue, May 1, 2012 at 12:54 PM, Adam Spiers aspi...@suse.com wrote: Agreed - while server-side auditing is a more important component than client-side, having both sounds potentially useful to me too. And while it's outside the scope of a CLI HIG discussion, it's nevertheless relevant to any work on a unified CLI. Sounds like a blueprint waiting to be written... ;) dt -- Dean Troyer dtro...@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] [client] OpenStack Client Followup
On Tue, May 1, 2012 at 1:49 PM, Adam Spiers aspi...@suse.com wrote: Sorry, that made me think of another newbie question - is the intention that all actions (including user- / site- / vendor-specific extensions) *must* be implemented in Python using the client API modules? Or will it also be able to support extensions simply by dropping arbitrary openstack-ACTION executables on $PATH? I like the way git lets you do the latter, e.g. I have a bunch of shell scripts At this point we have only talked about extending the client via cliff-derived plugins. I'm trying to decide what the value add of arbitrary binaries being called is; the way I imagine it the binary would have to duplicate the token flow auth at a minimum, why not just call it directly? git has the advantage here of keeping its state in the filesystem. What little state we have is in memory. dt -- Dean Troyer dtro...@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] OpenStack Client Followup
On Tue, May 1, 2012 at 2:11 PM, Adam Spiers aspi...@suse.com wrote: As of my recent patch, --help is contextual in nova: I hadn't seen that yet... and I have started work on some of the other commands too, so it would be helpful if we could reach a consensus on this soon ... although please let me know if I am wasting my time working on other commands due to any imminent rewrites using python-openstack! The continued existence of the project-specific commands is really up to the projects themselves. I think it would be great to converge them on things like this, but trying to get them all to work the same is what led us to openstackclient due to backward compatibility and all. My guess would be that the existing client binaries would live through the 'G' release even if we decided to deprecate them now. I agree with Dolph - there is a precedent from other well-known programs (git, hg, svn are the first ones I can think of) for --help to behave differently depending on whether or not it was preceded by a subcommand. So my vote is that we should definitely aim to adhere to this pattern. How about detailing it in the HIG and once we get a command or two implemented with argument parsing we give it a shot? dt -- Dean Troyer dtro...@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] [client] OpenStack Client Followup
On Tue, May 1, 2012 at 2:36 PM, Matt Joyce m...@nycresistor.com wrote: That made me think of something. Is the intention for the client to be portable? Due to the dependencies it'll be about as portable than the existing OpenStack clients. Regarding installation, pip is^H^Hwill be your friend. I'd expect the distros to pick it up at some point, too. dt -- Dean Troyer dtro...@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] OpenStack Client Followup
On Tue, May 1, 2012 at 3:59 PM, Matt Joyce m...@nycresistor.com wrote: How does this blueprint play into this client. Is it a separate admin only client or just a subset of this guy? https://blueprints.launchpad.net/nova/+spec/admin-cli Since we are consumers of the python-novaclient API libraries we need to track the movement of the admin stuff. That particular blueprint has not been targeted yet so we don't know if it will be implemented in folsom. As far as whether we support admin-only commands, I think we should. If they have their own client libs then we'll split them up too. I actually kind of liked the side effect of the old nova-manage in that it was self-enforcing for admin-ness since you needed to run it on the node itself. dt -- Dean Troyer dtro...@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] New Mailing List for Python OpenStack Client
On Mon, Apr 30, 2012 at 12:07 PM, Jay Pipes jaypi...@gmail.com wrote: Please, no! We already have too many mailing lists IMHO. If we want developers and operators and people interested in client tooling to have a full view of the OpenStack ecosystem, creating yet more mailing lists inhibits the sharing of behaviour among related community members. Roger that. It's deactivated. dt -- Dean Troyer dtro...@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] [client] OpenStack Client Followup
On Mon, Apr 30, 2012 at 11:13 AM, Adam Spiers aspi...@suse.com wrote: Count me in - by 'build a list' do you mean a new mailing list? You're in! For now that's just a list I'm keeping. tweaks. Should we discuss the FIXMEs you marked here or elsewhere? I wanted to make a few suggestions before I forget - can always continue discussion elsewhere if appropriate: This is it for now except for what we may do in the wiki itself while writing the doc. There is activity going on that may shift traffic on the lists. One of the things that will happen is the addition of prefixes in the subject so we can start by using [client]. 1. Regarding The subject names are always specified in command in their singular form. This is contrary to natural language use. - I didn't understand the second sentence here, but shouldn't the HIG should allow for scenarios where the verb can operate both on individual objects and on multiple objects in batch? I was referring to 'list server' vs 'list servers'. It would be nice to accept either where plural is natural, but that is a lower priority thing to solve. (Grammatical nitpick: if the verb is acting on the noun, then the HIG should refer to the noun as object rather than subject.) That was a deliberate choice based on how overloaded the word 'object' is in programming. My HS English teacher is preparing a detention for me I'm sure... 2. I think it would be good if the HIG gave guidelines on how the command should behave when run with no arguments. For some commands that is totally valid, for some that is an error condition. This probably belongs with the specific command definitions. 3. I think it would be good if the HIG recommended that, at least when subcommands are permitted, single arguments '--help' and 'help' always generate identical output: The intent is for '-h' and '--help' to provide global options and how to get specific command help. A 'help' command should list the available commands based on installed modules (and ultimately on permissions?) and 'help command' should display detailed help on 'command'. https://bugs.launchpad.net/keystone/+bug/936399 Heh. My past catches up with me. I've changed my mind here due to the potentially long list of commands involved. Simple, obvious, concise. Pick two. ;) 4. I think it would be good if the HIG gave guidelines on how the help text should be formatted - in particular that positional arguments are covered by the help text (e.g. keystone-manage does not currently give any info on positional arguments required until you specify too few). That's a good idea. I'd propose that it be close to what we can get out of argparse to minimise the amount of duplicated work. Go ahead and start drafting in the wiki. BTW, that page is in RST so it can be included in the source docs too. I'm not happy with the formatting though. dt -- Dean Troyer dtro...@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] OpenStack Client Followup
On Mon, Apr 30, 2012 at 1:18 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Running a cliff-based app without any arguments enters interactive mode (as of 0.4) which gives the user a new prompt and lets them run multiple commands before exiting. This is intended to be used as an optimization for commands to cache authentication credentials and clients and avoid logging in for every sub-command. Dang dude, let us catch up! Do we need to specify this beyond saying that all subcommands must use argparse for argument parsing (the new framework depends on it anyway, and then they are all consistent)? We should document that, I had just assumed it until now. dt -- Dean Troyer dtro...@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] OpenStack Client Followup
On Mon, Apr 30, 2012 at 2:19 PM, Dolph Mathews dolph.math...@gmail.com wrote: I find this behavior really annoying... --help should be contextual (depending on whether a subcommand is present, and what it is). I hope not... +1 for argparse. Actually, argparse is one reason for this behaviour. It doesn't like duplicated options in subparsers, nor subsets of names like we found in keystone with --tenant and --tenant_id, etc. IIRC none of the existing clients do that, they all rely on 'help command' to get command-specific help. dt -- Dean Troyer dtro...@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] curl command
On Fri, Apr 20, 2012 at 12:11 AM, andrei cosmin andrei_t...@yahoo.com wrote:
curl -d '{auth: {tenantName: openstackDemo,
passwordCredentials:{username: adminUser, password: secretword}}}'
-H Content-type: application/json http://192.168.206.130:35357/v2.0/tokens
| python -mjson.tool
i get the following error:
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
0curl: (7) couldn't connect to host
^^
This is the key bit, it looks like keystone may not be running?
i used my ip and the rest i leaved as it is. Where do i find my tenantName
and password credentials? What can be the problem?
By default devstack creates an 'admin' user and a 'demo' user, both
with the password of the value you set in $ADMIN_PASSWORD. There is a
matching tenant name for both accounts.
It may be easier to use the keystone command rather than curl to get
your token info. The equivalent command is:
keystone --os_tenant_name=openstackDemo --os_username=openstackDemo
--os_password=secretword
--os_auth_url=http://192.168.206.130:35357/v2.0/tokens token-get
And even better, the glance command also understands the --os_*
options for authentication so you do not necessarily need to get a
token first.
dt
--
Dean Troyer
dtro...@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
[Openstack] OpenStack Client Followup
We had a good discussion about a unified OpenStack command line client on Monday at the Design Summit. The notes are in the Etherpad at http://etherpad.openstack.org/FolsumCLI, I summarized my recollection at the bottom; those who were there feel free to add the bits I missed. One of the first things to do is to find out who is interested in contributing to this project.and hopefully coordinating some of the work with the other emerging project-specific clients. Send me an email and I'll build a list to get the discussion started. We also should look for some consensus on the name of the command itself. 'oscli' is a placeholder, and while sufficiently short and unique for my tastes it is hard to pronounce and remember. The leading candidates I have heard at the summit so far are 'openstack' and 'stack'. Let's gather some feedback at the bottom of the Etherpad about this as I am sure there are other opinions out there. Thanks dt -- Dean Troyer dtro...@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] Endpoints problems
On Fri, Apr 13, 2012 at 8:28 AM, Guilherme Birk guib...@hotmail.com wrote: keystone --token ADMIN --endpoint http://192.168.100.142:35357/v2.0 endpoint-create --region RegionOne --service_id=1fd7b5f1add74aa4b6efc514fd153e72 --publicurl=http://192.168.100.142:8774/v2/$(tenant_id)s --adminurl=http://192.168.100.142:8774/v2/$(tenant_id)s --internalurl=http://192.168.100.142:8774/v2/$(tenant_id)s But I'm getting a tenant_id: command not found. When I list the endpoints all my url's are like http://192.168.100.142:8774/v2/s; for the created endpoint. Am I doing something wrong ? You need to escape the '$'s in your URLs or change the double quotes around them to single quotes. The shell sees the $(tenant_id) and attempts to execute a command called tenant_id. dt -- Dean Troyer dtro...@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
[Openstack] DevStack stable/essex branch
The stable/essex branch of DevStack has been created in GitHub (https://github.com/openstack-dev/devstack/tree/stable/essex) with stackrc pre-configured to pull from stable/essex branches of the project repos as appropriate. http://devstack.org has been updated to reflect the current state. dt -- Dean Troyer dtro...@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] devstack stable/essex branch
On Tue, Apr 10, 2012 at 3:22 PM, Everett Toews everett.to...@cybera.ca wrote: Maybe I missed something but where is the stable/essex branch for devstack on Github? There isn't one yet...but when there is it will look exactly like https://github.com/dtroyer/devstack/tree/stable/essex-repo, which is the devstack trunk as of right now (b7748fbe44) + changing stackrc to point to stable/essex rather than master branches (fe08c5bfe4). dt -- Dean Troyer dtro...@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] python-glanceclient
On Tue, Apr 3, 2012 at 10:39 PM, Brian Waldon brian.wal...@rackspace.com wrote: to be a drop-in replacement for the existing client that lives in Glance, but a complete rewrite with a shiny new interface that maintains feature-parity. Coolness! I've added it to the command mapping in http://wiki.openstack.org/UnifiedCLI/Mapping and it looks pretty close. (Ignoring the verb-object vs object-verb debate). The biggest difference is the name for image membser: 'member' vs 'image-member'. I decided that 'member' was a bit too generic for a combined client; with a glance-only client that context makes it obvious. As for integrating this new client with the necessary OpenStack projects, here's a little roadmap I came up with: X 1) Basic functionality X 2) Integrate with Gerrit 3) Verify feature parity I see some things in the old CLI that I don't see in the new one at a quick glance. Will do more study once it is in DevStack (see below). 4) Integrate with DevStack It's on the roadmap now dt -- Dean Troyer dtro...@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] Client debugs??
On Wed, Apr 4, 2012 at 7:24 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: keystone token-get --debug U get: keystone: error: unrecognized arguments: --debug But if u do it before it works, odd. Guess that’s a “false” message/error. Actually that is exactly how it is supposed to work. Although it is hidden, --debug is a global option (defined in keystone/shell.py) just like --os_username and friends, which means it must appear before the command. All options that follow the command are command specific. dt -- Dean Troyer dtro...@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] euca2ools: Failure communicating with keystone (Essex on Ubuntu 12.04 B1)
On Fri, Mar 16, 2012 at 11:01 AM, Kevin Jackson ke...@linuxservices.co.uk wrote: [...] NOVA_REGION=nova export NOVA_USERNAME=demo export NOVA_PROJECT_ID=demo export NOVA_PASSWORD=openstack export NOVA_API_KEY=openstack export NOVA_REGION_NAME=$NOVA_REGION export NOVA_URL=http://$NOVA_API_HOST:5000/v2.0/; export NOVA_VERSION=1.1 export OS_AUTH_USER=demo export OS_AUTH_KEY=openstack export OS_AUTH_TENANT=demo export OS_AUTH_URL=http://$KEYSTONE_API_HOST:5000/v2.0/; export OS_AUTH_STRATEGY=keystone I know the documentation has not caught up to the code yet, but for the above you should switch to the common auth variables (see http://wiki.openstack.org/CLIAuth) that have been supported since E4: export OS_USERNAME=demo export OS_TENANT_NAME=demo export OS_PASSWORD=openstack export OS_REGION_NAME=nova export OS_AUTH_URL=http://$KEYSTONE_API_HOST:5000/v2.0/; export NOVA_VERSION=1.1 DevStack has new docs that talk about the auth variables (http://devstack.org/openrc.html) and the current way to set up euca creds (http://devstack.org/eucarc.html) using Keystone. These can easily be adapted to any Essex-4+ installation of OpenStack. I'm not certain this will fix your problem, but using the current auth config will help debugging it. dt -- Dean Troyer dtro...@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] Ubuntu 12.04 B1, Keystone (redux) + Service Catalogs
On Sun, Mar 11, 2012 at 2:35 PM, Kevin Jackson ke...@linuxservices.co.uk wrote: Thanks Adam for clarifying the position of the ENVVARS: SERVICE_ENDPOINT and SERVICE_TOKEN. There are a couple of issues I have with this though: 1) It's not clear that these are strictly over-riding envvars. Actually, the environment variables (if set) are used for the default value of the command-line options, so the command-line option do in fact override the environment variables. https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/shell.py#L97 dt -- Dean Troyer dtro...@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] devstack and api-paste.ini
On Wed, Mar 7, 2012 at 4:35 PM, Ken Thomas k...@yahoo-inc.com wrote: There have been some recent changes to the devstack script w.r.t. nova/api-paste.ini that puzzle me. There's the template api-paste.ini with various tokens that need to be substituted, and some of them are commented out. Ken, I have a medium-term goal to switch from maintaining templated config files for services in DevStack and re-write the sample config files supplied with the source where possible. This is the first instance of that; note that DevStack no longer carries files/nova-api-paste.ini. Is it just me, or would it would be much less confusing if the config template was closer to the final result without the need for magic sed incantations to remove commented out settings? Is that template config used elsewhere where it might need those comments to remain in place? (If so, I haven't been able to find 'em.) The sample file in Nova's source (etc/nova/api-paste.ini) has some templating in it, but it is also still configured by default for using a service token to authenticate to Keystone instead of the service username/password that DevStack now uses. Since that file may be used in other places I don't make many assumptions about what is there, so the sed script in stack.sh is a bit defensive and able to handle a couple of variations that the sample api-paste.ini may present. Clear as mud? ;) dt -- Dean Troyer dtro...@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
[Openstack-poc] [Bug 947718] [NEW] [DEFAULT] group name in config file must be uppercase
Public bug reported: As handled by openstack.common.cfg the default group header ([DEFAULT]) is only recognized in uppercase. [default] is not recognized as a valid group header for global config options. ** Affects: openstack-common Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Common Drivers, which is the registrant for openstack-common. https://bugs.launchpad.net/bugs/947718 Title: [DEFAULT] group name in config file must be uppercase Status in openstack-common: New Bug description: As handled by openstack.common.cfg the default group header ([DEFAULT]) is only recognized in uppercase. [default] is not recognized as a valid group header for global config options. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-common/+bug/947718/+subscriptions ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
[Openstack] DevStack and Fedora
I have proposed a DevStack branch that supports Fedora 16 at https://review.openstack.org/4364. Not everything is working yet, as outlined below. I am proposing now anyway to get feedback on the direction and some of the decisions I made along the way. Even though this release is targeted specifically to Fedora 16, the direction needs to include consideration for Debian and RHEL/CentOS/etc. Status = Ubuntu: runs the same as before; i.e. anything broken without this patch is still broken. Fedora: stack.sh runs to completion WITHOUT n-vol, quantum, melange enabled. Swift installs but doesn't respond. Open Questions Internally I am using the following convention to refer to the distros: Ubuntu uses the codename adjective as expected; other Debian-based distros use the codename directly (lenny, squeeze). In the Red Hat/Fedora world the codenames are not as commonly used, rather vendor/release names such as fedora16 (or f16), rhel5.5 or centos60. The default for anything not otherwise recognized will be vendor-release.update. Many of the differences are due to the packaging (deb vs rpm) and that is what should be tested rather than release names. At this point my plan is to only maintain package lists for Ubuntu and Fedora. Contributions are always welcome. Remaining FIXMEs == lxc and cgroups: cgroup filesystems are mounted at /sys/fs/cgroup: lxc is untested tgtd is misbehaving on fedora16 for me: volumes don't work packaging for OpenVSwitch isn't in fedora's default repos (yet), need to be located: quantum and melange are untested dt -- Dean Troyer dtro...@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] XCP toolstack support for devstack
On Tue, Feb 21, 2012 at 11:51 AM, Anthony Young sleepsonthefl...@gmail.com wrote: This looks great! From the looks of things, the main difference seem to be slight changes due to the fact that dom0 is ubuntu, rather than redhat. Is that accurate? If so, it seems like it should be straightforward to support both with roughly the same code, and just if-else the ubuntu/redhat code. In fact, we could probably even automatically check the os, and do the right thing depending on the situation. Anthony, my multi-distro branch has the basics in it for detection and abstraction of distro differences. It's probably time for me to rebase and propose it. It's working on F16 now. dt -- Dean Troyer dtro...@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] devstack and stable/diablo
On Tue, Feb 21, 2012 at 1:23 PM, Yun Mao yun...@gmail.com wrote: What's the recommended way to play with stable/diablo with devstack? We've been using the stable/diablo branch of devstack but stack.sh in that branch is old that has some annoying small issues. If I use the master branch of devstack but replace stackrc with the stable/diablo branch content, would that be a problem? Is it recommended? Thanks, That is likely to not work as stack.sh changes to keep up with development in the truck branches of the projects. Fixing bugs in devstack stable/diable is possible, it is just not something that we spend any time on normally. dt -- Dean Troyer dtro...@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] Remove Zones code - FFE
On Feb 17, 2012, at 9:06 AM, Ed Leafe wrote: The term zone was adopted at a time when we weren't really focusing on mimicking the AWS Availability Zone concept, and in hindsight, it was a poor choice. So we should learn from that mistake and make sure we don't choose a replacement term that already has a common usage, such as shards segments or clusters. On Sat, Feb 18, 2012 at 12:54 PM, Chris Behrens cbehr...@codestud.com wrote: Sector? Getting away from computing related collectives: assembly - lends itself to sub-assembly, etc faction - When these servers over here disagree with those servers over there, such as in Xen vs KVM configurations schism - a fancier-and-harder-to-spell-and-pronounce faction coalition - when the Xen vs KVM schism gets patched up and instead they separate based on vi vs emacs or Gnome vs KDE And my favorite (partly because it is only 4 characters!): bloc - a group with a common interest, sometimes in voting situations dt -- Dean Troyer dtro...@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] How to re-create a stack with devstack
On Thu, Jan 26, 2012 at 2:58 PM, Naveed Massjouni navee...@gmail.com wrote: I would like to know the proper way to blow away a stack and create a fresh stack with devstack. Currently, I hit ctrl-c and ctrl-d a bunch of times to close all the windows in the screen session. Then I run ./stack.sh again. Is this the best way? Is this documented somewhere? killall screen works well for me. dt -- Dean Troyer dtro...@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
