Re: [Openstack] Share your localrc file for devstack
On Mon, Jul 29, 2013 at 5:55 AM, Jake G. wrote: > Networking for quantum is still kicking my butt. The gate tests run using this to create localrc, it shouldn't be too hard to follow... https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate.sh This is the default file I use for testing in a 2G vm with one NIC: # Because the host cloud uses nova's default: FIXED_RANGE=10.254.1.0/24 # Make Neutron happy NETWORK_GATEWAY=10.254.1.1 # Services #disable_service tempest #enable_service ceilometer #enable_service swift # DB #disable_service mysql #enable_service postgresql # Queues #ENABLED_SERVICES+=,-rabbit,qpid #ENABLED_SERVICES+=,-rabbit,-qpid,zeromq # Neutron disable_service n-net enable_service q-svc q-agt q-dhcp q-l3 q-meta Q_USE_DEBUG_COMMAND=True # Timeouts ACTIVE_TIMEOUT=300 ASSOCIATE_TIMEOUT=120 BOOT_TIMEOUT=240 SERVICE_TIMEOUT=240 TERMINATE_TIMEOUT=240 ADMIN_PASSWORD=xyzpdq DEFAULT_INSTANCE_TYPE=m1.micro EXTRA_OPTS=default_log_levels=sqlalchemy=WARN,boto=WARN,eventlet.wsgi.server=WARN LOGDAYS=1 LOGFILE=$DEST/logs/stack.sh.log DATABASE_PASSWORD=qwerty RABBIT_PASSWORD=qwerty RECLONE=yes SCREEN_LOGDIR=$DEST/logs/screen SERVICE_PASSWORD=$ADMIN_PASSWORD SERVICE_TOKEN=poiuyt SKIP_EXERCISES=boot_from_volume STACK_LOG=stack.sh.log SWIFT_HASH=8213897fads879789asdf789 SWIFT_REPLICAS=1 SYSLOG=true dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Share your localrc file for devstack
On Mon, Jul 29, 2013 at 7:48 AM, Jake G. wrote: > I have a single Ubuntu host with 2 nics. > One nic has a static IP > And the other is up but no config. > > What about flat networking and all that stuff that goes into the localrc > file? Small steps...make it work with only the static IP NIC first, then try to use the second NIC as your VM network (assuming that is what you want). The config I posted is a near-equivalent to nova network's flat model. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Prevent Devstack from creating demo project.
On Tue, Jul 30, 2013 at 10:40 AM, Shake Chen wrote: > I also have same question. The demo project make user confuse. Users? Please don't tell me if you actually have users on a DevStack setup... > On Tue, Jul 30, 2013 at 4:29 PM, Jake G. wrote: >> Wondering if there is a way to prevent devstack from creating a demo >> project and just leave the admin project as the default project? Edit them out of lib/keystone's create_keystone_accounts() function. Or create a local.sh script and remove them there. The demo project is used in the DevStack exercises and to illustrate how to create a simple project with roles. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Nova] Deprecation of nova-network deferred to Icehouse
On Tue, Jul 30, 2013 at 5:58 PM, Dan Sneddon wrote: > I agree that Neutron should be the default in Devstack, for exactly the > reason that Russell gives, but also because nova-network is now officially > deprecated. I am personally not ready to throw that switch yet, at least until the Neutron gate job passes regularly and is voting again. (Yes, I know there is a reason, that's not the point.) > What would be the appropriate Neutron model for Devstack by default? > FlatManager? Yes. That is what DevStack does for nova-network today. IIRC the idea was to get Neutron duplicating that setup, including security groups and floating IPs, then we woud make the change. The first step would be to make sure that the default Neutron config in DevStack is the correct setup so that only changing ENABLED_SERVICES is necessary to have the same basic configuration. The next thing I want to have is the code for unstack.sh to call to back out as much of the net configuration as possible. At least as far as nova-network does today with br100 holding the IP for the public interface, but even getting that out would be cool. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Prevent Devstack from creating demo project.
On Wed, Jul 31, 2013 at 10:27 AM, Mac Innes, Kiall wrote: > Totally off topic for the thread, but likely worth pointing out. I don't consider this off-topic at all, it is important that this is well-understood. > DevStack is not intended for standing up a production cloud. +++ Support-sounding questions on the non-development list don't give me warm fuzzy feelings that people listen to (or are aware of) this advice. There are other options listed in https://wiki.openstack.org/wiki/Get_OpenStack that are more suitable for operationally oriented (ie, have other users) installations. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] [openstackclient] python-openstackclient 0.2 release
It is my pleasure to announce the release of OpenStackClient 0,2.0. This is the first public release of OpenStackClient and is suitable for tire-kicking and general scrutinization. It is not ready for production use just yet as there still may be backward-incompatible changes. We have completed the following goals identified at the Havana Summit: * Implement commands for Identity, Compute, Image and Volume APIs. * Finalize the basic command structure; no major changes in command format are expected at this point. https://wiki.openstack.org/wiki/OpenStackClient/Commands has the details. * Removed the word 'tenant' in favor of 'project' as much as possible, even for Identity 2.0 commands python-openstaclclient can be installed from the following locations: http://tarballs.openstack.org/python-openstackclient/python-openstackclient-0.2.0.tar.gz https://pypi.python.org/pypi/python-openstackclient A big thank-you all of the contributors to OpenStackClient! dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] devstack won't startup nova-api
On Mon, Aug 5, 2013 at 1:10 PM, Steve Sonnenberg wrote: > Can anyone explain why I can't get a brand new devstack install up an > running. Which OS? There are still some known problems on Fedora and RHEL while we sort out the python dependency conflicts, although I haven't seen that particular failure yet. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Fwd: Re: I'm back
On Fri, Aug 9, 2013 at 1:06 PM, Alessio Ababilov wrote: >> Well, first I wrote two separate plugins for v2 and v3, but I decided >> to join them just for command-line tool convenience: user can omit >> "--os-auth-system=keystone" option and the system will be chosen >> automatically based on available arguments (in >> auth.load_plugin_from_args function). >> And v3 and v2 are distinguished by --os-identity-api-version option of >> the plugin. I'd like to suggest that having the option to use different Identity API versions for auth and for the other client operations would be useful. I'm not sure if that is inherent in this design or not... >> > Another standalone change is that v2 and v3 both currently authenticate >> > to keystone immediately upon creation, under the apiclient they won't. >> > I've got no real opinion either way but it may cause some discussion. >> I have developed the first version of common API client library more >> than a year ago for our own Web dashboard in Grid Dynamics and I >> definitely vote for lazy authentication. It is more convenient for >> user; also, authentication can be perfectly called explicitly by >> HttpClient.authenticate() One of the challenges I've had with OpenStackClient is to only perform the auth once then stuff the proper credentials into the other (compute, image, etc) clients to prevent them from doing it again. Again, my apologies for not having kept up on this but a completely separate auth step that can either be called as-needed or performed up front and passed in to the clients would be extremely useful. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] devstack on fedora 19 i386 failure
On Sun, Nov 24, 2013 at 9:06 AM, John Smith wrote: > It looks like the fedora 19 'i386' directory doesnt exist, there's > just a 'source' and 'x86_64' subdir. For comparison, the fedora 18 dir > f18 does have an i386 subdir. It was working yesterday :( > For now I can work around it by setting OFFLINE=True, but I wonder > what's going on here ? > <http://yum.theforeman.org/releases/1.3/f19/i386/repodata/repomd.xml> You are simply having a problem reaching the listed repo: > http://yum.theforeman.org/releases/1.3/f19/i386/repodata/repomd.xml: > [Errno 14] HTTP Error 404 - Not Found > Can you get this file via curl? Is yum working outside of DevStack? Given the weekend time, server maintenance is also not out of the question... dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Regarding Openstack upgrade for havana onwards
On Thu, Dec 5, 2013 at 8:01 PM, Joe Hakim Rahme < joe.hakim.ra...@enovance.com> wrote: > The only automated upgrade I know of is Grenade[1]. You should check it > out. > I should clarify this a bit to keep expectations realistic: Grenade is not a tool for performing upgrades, especially on production deployments. It is designed for testing the common upgrade path to detect when unexpected incompatabilities arise. It uses DevStack to set up the running system so right there it is not suitable for production use. It is useful to look at to get an idea of the minimum that needs to be done during an upgrade, though. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [DevStack] Using create-stack-user.sh
On Tue, Dec 17, 2013 at 5:30 PM, Everett Toews
wrote:
> I'd like to run DevStack using create-stack-user.sh but am getting an
> error.
[...]
> but having to clone the repo again feels wrong.
>
Understood, but chicken-v-egg here...
How is create-stack-user.sh intended to be used? Is there a way to use the
> stack user to run stack.sh without permission problems? What is the command
> flow?
>
Honestly, I don't use it. I run DevStack in disposable VMs and use either
the default user ('ubuntu' on precise, etc) or my own account if I have one
pre-configured. Its existance was because someone originally wanted to run
stack.sh as root and we didn't want that. I extracted that out of stack.sh
so we could just say "Don't Do That" (run stack.sh as root) to side-step a
class of subtle problems like what you are seeing.
> P.S. Is it a bug that create-stack-user.sh doesn't have the user execute
> bit set?
>
Yes. Again, I don't use it and never noticed. Thanks.
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] this can crash devstack
On Wed, Jan 1, 2014 at 8:58 PM, Peter Cheung wrote: > 1) import an qcow image to glance > 2) start the instance for that image > 3) init 6 > 4) delete that qcow image > 5) rejoin the devstack > > devstack will still running, but unable to start any instance, even > instances are not from that image. > Restarting after a reboot is really outside what DevStack is intended to be able to do. rejoin_stack.sh is only meant to restart the screen sessions and nothing else. Even then it isn't perfect, which is why you should run stack.sh again after rebooting. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] devstack + ldap
On Thu, Mar 6, 2014 at 9:51 AM, Craig Jellick wrote: > I cannot get devstack + ldap working. I've tried on Ubuntu and CentOS > vms and in both cases I get a similar error: > > In Ubuntu: > + ldapdelete -x -w test -D cn=Manager,dc=openstack,dc=org -H > ldap://localhost -r dc=openstack,dc=org > ldap_search: No such object (32) > This is another casualty of enabling errexit in stack.sh last week. This has always silently failed when that object was not present, such as on the first run. https://review.openstack.org/78675 fixes it for me locally, it's a one line change to lib/ldap. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Using Nova client with SSH SOCKS proxy
On Fri, May 16, 2014 at 10:41 AM, Adrian Smith wrote: > To access my controller I need to go through a intermediary box. > > I've created a local SOCKS proxy by ssh'ing to this intermediary with > the parameters -D 13392. > > I then set the environment variable, > export HTTP_PROXY=http://localhost:13392 > > But using "nova list" just gives an error, > $ nova list > ERROR: HTTPConnectionPool(host='localhost', port=13392): Max retries > exceeded with url: http://x.x.x.x:5000/v2.0/tokens (Caused by 'httplib.BadStatusLine'>: '') > > Should this work? Am I doing something wrong? > The nova client lib uses requests/urllib3 for HTTP, they do not support SOCKS proxies out of the box. There have been some forks/patches to add that to requests or urllib3, we have not tested those. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] OpenStackclient 0.4.0 release
OpenStackClient 0.4.0 has been released to PyPI. This release consists of a number of new commands and bug fixes. As of this release we feel it is ready for general consumption for the Compute, Identity, Image and Volume APIs. The commands for these APIs should be considered to be in their final form, although until the 1.0 release there is still the possibility of fixes/adjustments, particularly to command options. We will begin to observe a deprecation cycle to allow some time for adjustment. python-openstackclient can be installed from the following locations: PyPI: https://pypi.python.org/pypi/python-openstackclient OpenStack tarball: http://tarballs.openstack.org/python-openstackclient/python-openstackclient-0.4.0.tar.gz Release Highlights * Identity v2: rename 'token create' to 'token issue' and add 'token revoke' * Identity v3: rework the group/user/role list commands so each only lists its own data type; to get a list of the groups that user Xyzzy belongs to you would use 'group list –user Xyzzy'. * Identity v3: add new 'role assignment list' command add new 'extension list' command to list the available API extensions, currently supports the Identity API * Compute v2: rename 'agent' object to 'compute agent': 'compute agent list' * Identity v3: add 'identity provider create/delete/list/set/show' commands * Image v1: add –volume and –force to 'image create' * Volume v1: change –volume-type options for 'volume create' to –type fix quiet/verbose/debug output levels to be more consistent with other programs dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] OpenStack "K" naming poll
On Thu, Jul 10, 2014 at 10:19 AM, Gary Kotton wrote: > What about Kilimanjaro? That'll get you sentenced to writing it on the chalkboard once for each commit during the cycle... dt Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] create custom devstack setup with new backend enabled
On Mon, Jul 28, 2014 at 7:04 AM, Nikesh Kumar Mahalka < nikeshmaha...@vedams.com> wrote: [...] > 3)vi local.conf > > [[local|localrc]] > > ... CINDER_ENABLED_BACKENDS = client:client_driver > This is the problem. The localrc section of local.con is sourced as shell script just like localrc was, the spaces here cause the shell to look at CINDER_ENABLED_BACKENDS as a command, not a variable assignment. You can see the default values in cinder.conf... [...] 5) checking the contents of cinder.conf cat /etc/cinder/cinder.conf > > ... [DEFAULT] > rabbit_password = some_password > rabbit_hosts =192.168.2.64 > rpc_backend = cinder.openstack.common.rpc.impl_kombu > use_syslog = True > default_volume_type = lvm enabled_backends = lvmdriver-1 > Is this line really concatenated like this or is it a formatting error in the email? Either way, this is the default value because your CINDER_ENABLED_BACKENDS is not working. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] is anyone using zeromq for RPC?
On Fri, Sep 5, 2014 at 2:50 PM, Doug Hellmann wrote: > The zmq driver in oslo.messaging, used for internal communication between > OpenStack services, has been without a maintainer for a significant period > of time. It isn’t actively tested, and it isn’t clear whether or not it > works. The Oslo team would like to drop support for it in Kilo, but before > we do that we would like to find out if (a) anyone uses it and (b) if any > of those people would like to contribute to maintaining it. > I haven't seen any work on zmq in DevStack for some time either. We'll follow Oslo in dropping it if that decision is made. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] OpenStackClient 0.4.1 released
OpenStackClient 0.4.1 has been released to PyPI. This release consists of mostly bug fixes and a few new commands. python-openstackclient can be installed from the following locations: PyPI: https://pypi.python.org/pypi/python-openstackclient OpenStack tarball: http://tarballs.openstack.org/python-openstackclient/python-openstackclient-0.4.1.tar.gz Release Highlights * Bug 1319381: remove insecure keyring support * Bug 1337245: add user password set command * Bug 1337684: add extension list --compute * Bug 1337684: add extension list --compute * add container create and container delete commands * add initial support for global --timing option (similar to nova CLI) * complete Python 3 compatibility * add authentication via --os-trust-id for Identity v3 ...and more... dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Devstack][Icehouse] TENANT_ID Failure retrieving TENANT_ID for demo
On Wed, Sep 17, 2014 at 10:40 PM, foss geek wrote: > 2014-09-18 03:21:56.903 | ++ neutron net-create --tenant-id > db7fd8d208db41ea8622be52b520d44e private > 2014-09-18 03:21:56.904 | ++ grep ' id ' > 2014-09-18 03:21:56.905 | ++ get_field 2 > 2014-09-18 03:21:56.905 | ++ read data > 2014-09-18 03:21:58.466 | Not Found (HTTP 404) (Request-ID: > req-d3c47a05-d5ed-4bed-aebf-69d95edb85a5) > 2014-09-18 03:21:58.514 | + NET_ID= > 2014-09-18 03:21:58.514 | + die_if_not_set 396 NET_ID 'Failure creating > NET_ID for test-physnet1 db7fd8d208db41ea8622be52b520d44e' > This is your error report, neutron net-create failed. You'll need to dig through neutron logs to figure out why. I'd start with q-svc and q-agt logs. It is possible that this is a side-effect of an earlier error. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] python keystone v3 api coding question
On Mon, Oct 13, 2014 at 3:28 PM, Priti Desai wrote: > I don’t know about Keystone Client V3 API but OpenStack client has a way > to get the list of users and their roles under a project: > > *openstack role assignment list --project=project-a* > This is implemented in the v3 API with role_assignments.list(). OSC does a bit of processing before and after so to match its output you would want to look at openstackclient.identity.v3.role_assignment:ListRoleAssignment dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [DevStack] Keystone not restarting
On Tue, Oct 14, 2014 at 12:14 PM, Paul Carlton wrote: > I'm using devstack and doing 'unstack.sh' to stop devstack then making > code/config changes and doing 'rejoin_stack.sh' to restart it but it is not > starting apache or keystone processes. I've tried restarting apache myself > before and after rejoin but no joy. > > I can fix this by doing 'stack.sh' but then my nova.conf file changes are > lost. > rejoin-stack.sh is a hack that only restarts screen process but unstack.sh shuts down everything. And more things are moving to use mod_wsgi under Apache... The usual workflow is to attach to the screen process that the non-mod_wsgi servers run in, Ctrl-C the one you want to restart and re-run it. (Up arrow recalls the original command line.) Any changes you make in the source repos or config files will not be overwritten. Also, if you are making the same changes to nova.conf, see if using local.conf's additional config file bits work for you. http://devstack.org/configuration.html dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [DevStack] Keystone not restarting
On Tue, Oct 14, 2014 at 9:02 PM, Борис Бобров wrote: > Have a look at /etc/apache2/sites-available. For some reason > keystone's .conf files is not linked to /etc/apache2/sites-enabled, so it > doesn't go up when apache is restarted. Try creating symlink manually. > DevStack manages that symlink, ie, stack.sh puts in place and restarts Apache. unstack.sh removes it and restarts Apache. Adding it and manually restarting Apache doesn't hurt (if keystone is still configured). dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] OpenStack 2014.2 ("Juno") is released !
On Fri, Oct 17, 2014 at 9:30 AM, Ian Y. Choi wrote: > I am quite expecting 'juno/stable' branch for DevStack, but I can happily > wait that delay :) The DevStack stable/juno defaults update has merged and is ready. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [openstack-dev] cinder netapp 7 mode nfs driver - failed to mount share
On Thu, Dec 4, 2014 at 1:19 PM, K, Shanthakumar (HP Cloud) <
shanthakuma...@hp.com> wrote:
> I'm trying to integrate Netapp 7 mode NFS driver with openstack cinder
> volume provisioning using Juno 2.
>
> During the driver initialization I’m getting the following error and
> volume creation is failing.
>
> Do I need to do any changes in storage or client side ?
>
The log indicates this is a client-side issue:
> 2014-12-04 18:40:32.916 49304 WARNING cinder.volume.drivers.nfs
> [req-e14faed4-4ff7-47a0-8fcb-67d1a4cfd2e4 - - - - -] Exception during
> mounting NFS mount failed for share 10.XX.XX.XX:/nfsvol.Error - {'pnfs':
> u"Unexpected error while running command.\nCommand: sudo cinder-rootwrap
> /etc/cinder/rootwrap.conf mount -t nfs -o vers=4,minorversion=1
> 10.XX.XX.XX:/nfsvol
> /mnt/state/var/lib/cinder/mnt/527dc3646de39dbda076e3a72dca54e5\nExit code:
> 32\nStdout: ''\nStderr: 'mount.nfs: an incorrect mount option was
> specified\\n'", 'nfs': u"Unexpected error while running command.\nCommand:
> sudo cinder-rootwrap /etc/cinder/rootwrap.conf mount -t nfs
> 10.XX.XX.XX:/nfsvol
> /mnt/state/var/lib/cinder/mnt/527dc3646de39dbda076e3a72dca54e5\nExit code:
> 32\nStdout: ''\nStderr: 'mount.nfs: Protocol not supported\\n'"}
>
Make sure you have everything installed for NFS support on your cinder
volume nodes and nova compute nodes. This varies by distro, but you should
be able to do a manual mount of your NetApp shares before Cinder will be
happy.
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] [OpenStackClient] Release 1.0.0
OpenStackClient 1.0.0 has been released to PyPI. This release represents the results of a small band of contributors' work over the last -[0] years. Thanks to $(git log --format='%aN' | sort -u) for your help in making the command line a better place for us all. This also marks the stabilization of the command formats and options; any non-compatible changes to existing commands from here out will have a deprecation cycle of at least one non-bug-fix-only release[1] or six months. This specifically does not apply to the pretty-table output format (the default output of tables with the lines) as the alternate machine-readable formats should be used when parsing output. Non-shell-scripters note, JSON output support is now available. OpenStackClient can be installed from the following locations: * PyPI: https://pypi.python.org/pypi/python-openstackclient * OpenStack tarball: http://tarballs.openstack.org/python-openstackclient/python-openstackclient-1.0.0.tar.gz Release Notes * Bug 1337422: document different ways to authenticate * Bug 138: Creating volume from image required image ID * Bug 1292638: Perhaps API Versions should Match Easier * Bug 1390389: create with a soft fail (create or show) for keystone operations * Bug 1387932: add keystone v3 region object * Bug 1378842: OSC fails to show server details if booted from volume * Bug 1383338: server create problems in boot-from-volume * Bug 1337685: Add the ability to list networks extensions * Bug 1355838: Don’t make calls to Keystone for authN if insufficient args are present * Bug 1371924: strings are being treated as numbers * Bug 1372070: help text in error on openstack image save * Bug 1372744: v3 credential set always needs –user option * Bug 1376833: odd behavior when editing the domain of a user through Keystone v3 API * Bug 1378165: Domains should be supported for ‘user show’ command * Bug 1378565: The ‘–domain’ arg for identity commands should not require domain lookup * Bug 1379871: token issue for identity v3 is broken * Bug 1383083: repeated to generate clientmanager in interactive mode * Added functional tests framework and identity/object tests * Authentication Plugin Support * Use keystoneclient.session as the base HTTP transport * implement swift client commands * clean up ‘links’ section in keystone v3 resources * Add cliff-tablib to requirements * Include support for using oslo debugger in tests * Close file handlers that were left open * Added framework for i18n support, and marked Identity v2.0 files for translation * Add ‘command list’ command * CRUD Support for OS-FEDERATION resources (protocol, mappings, identity providers) dt [0] far longer that I had hoped back when this started... [1] a release increasing only the 'z' value in the x.y.z version scheme -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] [OpenStackClient] OSC Release 1.0.1
OpenStackClient 1.0.1 has been released to PyPI. This release corrects a regression in the 'ec2 credentials' commands in the 1.0.0 release that prevented them from working. OpenStackClient can be installed from the following locations: * PyPI: https://pypi.python.org/pypi/python-openstackclient * OpenStack tarball: http://tarballs.openstack.org/python-openstackclient/python-openstackclient-1.0.1.tar.gz Release Notes Bug 1399757: EC2 credentials create fails dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] [OpenStackClient] Adding Image 'member' commands
Glance has the concept of 'image members' as the mechanism for sharing
images between projects. We need to add this to OSC and I'd like to work
out the commands/options to do so A while back, markwash and I sat down
and sorted a simple set of additions to support the member operations for
both Image v1 and v2 APIs. I promptly went on and dropped this particular
ball.
I suppose first of all, does there remain a need/desire to add these for
Image API v1? The v2 set we came up with is much cleaner and I think is
highly preferable and if we can just leave OSC's Image v1 as-is I would
prefer to do that.
Conceptually, I see a shared image as an image with an attribute that is a
list of projects that it is shared with in addition to its home (owner)
project. To maintain that list, two new options can be added to 'image
create' and 'image set':
--share - add to the shared-with list for this image
--no-share - remove from the shared-with list ('image
set' only)
Both --share and --no-share options may be repeated, much as the
--properties option works today.
In addition, the 'receiving' project must ACK the sharing, which would be
an added option to 'image set':
--share ack - the magic value 'ACK' (case insensitive) signifies the
acceptance of a shared image by the 'receiving' project
A couple of new options are added to 'image list' to select shared images:
--shared - filter on shared images only
--project - filter on (this may imply --shared?)
Some of the questions I have:
* Is --no-share the correct antonym of --share? --unshare maybe? We have
a pattern of using regular English words were possible (enable|disable)
rather than the GNU style of prepending 'no-' to options, but that is my
current backup.
* Do we need an 'un-ACK' option for a 'receiving' project to remove the
shared image from their list without requiring the owner project to do so?
Is this even possible in the Image v2 API?
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [OpenStackClient] Adding Image 'member' commands
On Mon, Jan 5, 2015 at 10:17 AM, Kevin L. Mitchell < kevin.mitch...@rackspace.com> wrote: > (Shouldn't this be on openstack-dev?) It's really a CLI usability question, I'm looking for a user audience. I know how I'd do it already. ;) > On Fri, 2015-01-02 at 14:10 -0600, Dean Troyer wrote: > > * Is --no-share the correct antonym of --share? --unshare maybe? We > > have a pattern of using regular English words were possible (enable| > > disable) rather than the GNU style of prepending 'no-' to options, but > > that is my current backup. > > My mental model insists that "--no-share" would remove all shares, so > perhaps that's not the correct antonym. How about "--grant" and > "--revoke"? > I'm not thrilled with --no-share either, but using that style has been suggested before. I do think grant/revoke are worth considering though, thanks. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [OpenStackClient] Adding Image 'member' commands
On Tue, Jan 6, 2015 at 8:55 AM, Jay Pipes wrote:
> On 01/02/2015 03:10 PM, Dean Troyer wrote:
>
>> I suppose first of all, does there remain a need/desire to add these for
>> Image API v1?
>>
>
> Yes. There's many shops that still use the v1 Glance API. And, Nova
> itself, has little current support for v2 Glance API.
Fortunately Nova doesn't use a CLI to do that... ;) I'll take another look
at the differences...I really don't want for the user to need to know which
API version is being used if at all possible.
--share - add to the shared-with list for this image
>> --no-share - remove from the shared-with list
>> ('image set' only)
>>
>
> Is image set equal to image update in v1 parlance?
The 'set' verb is totally an artifact of OSC for changing attributes of an
existing resource.
>
> Both --share and --no-share options may be repeated, much as the
>> --properties option works today.
>>
>
> I would prefer --share and --unshare or --add-member and --remove-member.
> Typically, --no- prefix on a CLI option means to disable a boolean option.
I'll buy that. Or Kevin's suggestion of --grant/-revoke which I still need
to noodle over a bit.
> In addition, the 'receiving' project must ACK the sharing, which would
>> be an added option to 'image set':
>>
>> --share ack - the magic value 'ACK' (case insensitive) signifies the
>> acceptance of a shared image by the 'receiving' project
>>
>
> IMHO. Would have been a bit nicer to have something like this:
>
> glance image member [confirm|decline] []
OK, I'll re-think this...magic values stink...
>
> A couple of new options are added to 'image list' to select shared images:
>>
>> --shared - filter on shared images only
>> --project - filter on (this may imply --shared?)
>>
>
> Or:
>
> --shared-with=
I like that...
>
> Some of the questions I have:
>>
>> * Is --no-share the correct antonym of --share? --unshare maybe? We
>> have a pattern of using regular English words were possible
>> (enable|disable) rather than the GNU style of prepending 'no-' to
>> options, but that is my current backup.
>>
>
> Prefer --unshare to --no-share, but prefer --add-member/--remove-member to
> either :)
Honestly I'm trying very hard to avoid using the word 'member', it's
meaningless to me in this usage.
> * Do we need an 'un-ACK' option for a 'receiving' project to remove the
>> shared image from their list without requiring the owner project to do
>> so? Is this even possible in the Image v2 API?
>>
>
> See suggestion above:
>
> glance image member decline []
>
So decline is both a NAK and an un-ACK (after the image has already been
ACK-ed). Make sense? I can live with that if so, just wondering if that
will be obvious to other users.
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] [OpenStackClient] Release 1.0.2
OpenStackClient 1.0.2 has been released to PyPI. This release includes some command enhancements and a number of bug fixes. OpenStackClient can be installed from the following locations: PyPI: https://pypi.python.org/pypi/python-openstackclient OpenStack tarball: http://tarballs.openstack.org/python-openstackclient/python-openstackclient-1.0.2.tar.gz Release Notes Summary Wiki content migrated into docs in repo Bug 1385338: Improve domain related defaults when using v3 identity Bug 1400796: Quick usage report - nova usage Bug 1397251: allow openstack user list to use other filters Bug 1394793: support the keystone api /v3/users/$userid/projects Bug 1409179: user role list command should be worked into role list Bug 1390507: Quota show requires cinder in keystone catalog Bug 1400531: Authentication failure results in useless error message Bug 1400597: delete multiple objects Bug 1400795: No list availability zones option Bug 1404073: type should be required for v2.0 service create Bug 1404434: add missing docs for service command Bug 1404931: volume list does not show attached servers Bug 1404997: Allow description to be set for service create/update Bug 1405416: Compute region selection broken Bug 1406654: Remove deprecated commands from help Bug 1406737: v3 endpoint related commands access service.name without check Bug 1408585: Backup list doesn’t show backup’s name Bug 1410364: Version discovery fails with default Keystone config Bug 1411179: network client don’t use session Bug 1411337: identity v3 service list should have “description” column dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] [OpenStackClient] OSC release 1.0.3
OpenStackClient 1.0.3 has been released to PyPI. python-openstackclient can be installed from the following locations: PyPI: https://pypi.python.org/pypi/python-openstackclient OpenStack tarball: http://tarballs.openstack.org/python-openstackclient/python-openstackclient-1.0.3.tar.gz Please report issues through launchpad: https://bugs.launchpad.net/python-openstackclient Changes in python-openstackclient 1.0.2..1.0.3 -- * Add ``catalog list`` and ``catalog show`` commands for Identity v3. * Add 'hypervisor stats show' command . * Rename ``server resize`` option ``--verify`` to ``confirm``. It conflicted with the global ``--verify`` option and never worked prior to this. * Add ``trust create/delete/list/show`` commands. * Add ``--sort`` to ``image list`` command. * Change ``volume create`` option ``--snapshot-id`` to ``--snapshot``. The old name is still silently supported. * Add Network API quotas to ``quota show`` command. * Add ``--public``, ``--private``, ``--all``, ``--long`` options to ``flavor list`` command. Remove "Extra Specs", "Swap" and"RXTX Factor" columns from default output. * Add ``--shared``, ``--property`` options to ``image list`` command. * Add ``--size`` option to ``volume set`` command. * Bug 1353040: server create --nic option clumsy * Bug 1366279: nova lock command description rather terse * Bug 1399588: Authentication needed for help command * Bug 1401902: image filtering not available * Bug 1410251: sort and filter options on openstack image list * Bug 1411160: Add network support to quota show * Bug 1413718: support keystone v3 trust extension * Bug 1413954: missing volume extend * Bug 1415182: Add extra validation when extending volume * Bug 1416542: openstack client resize verify not completing workflow * Bug 1416780: flavor list missing features * Bug 1417614: tenant_id in server show * Bug 1417854: Fix help messages for `os security group rule create` and `os security group rule list` * Bug 1418024: wrong import of contrib module from novaclient * Bug 1418384: openstack client help shows domain can be changed for a project * Bug 1418742: volume create --snapshot-id is wrong * Bug 1418810: auth with os-token fails with unexpected keyword argument 'user_domain_id' * Bug 1420080: functional tests are failing with new keystoneclient release * Bug 1420732: Better error message for sort_items * Bug 1423748: Add support for hypervisor-stats and hypervisor-uptime command * Bug 1428912: authentication through password prompting is broken * Bug 1429211: 'catalog list' fails when region is not present Requirements updates diff --git a/requirements.txt b/requirements.txt index 4a5d70d..97d06c4 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ pbr>=0.6,!=0.7,<1.0 -six>=1.7.0 +six>=1.9.0 @@ -10,2 +10,2 @@ cliff-tablib>=1.0 -oslo.config>=1.6.0 # Apache-2.0 -oslo.i18n>=1.0.0 # Apache-2.0 +oslo.config>=1.9.0 # Apache-2.0 +oslo.i18n>=1.3.0 # Apache-2.0 @@ -15,2 +15,2 @@ python-glanceclient>=0.15.0 -python-keystoneclient>=0.11.1 -python-novaclient>=2.18.0 +python-keystoneclient>=1.1.0 +python-novaclient>=2.18.0,!=2.21.0 @@ -18 +18 @@ python-cinderclient>=1.1.0 -python-neutronclient>=2.3.6,<3 +python-neutronclient>=2.3.11,<3 dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Nova user missing for devstack install
On Mon, Mar 16, 2015 at 7:12 AM, somshekar kadam wrote: > In Packstack this what the first step is down when we install. setting up > sshkeys. > You've mentioned three different installers now, all three of which may have different practices regarding user accounts. There is no upstream OpenStack default here except in documentation. DevStack uses one non-root account for everything, by default that is 'stack', but it also works fine as _any_ non-root account. You will need to set up the ssh keys accordingly, which may include root->root. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] DevStack on Nginx
On Fri, Jul 3, 2015 at 10:24 PM, shine nelson wrote: > I recently installed DevStack on my new dedicated server running Debian 8 > (Jessie). I noticed that DevStack automatically installed the LAMP stack. I > would like to know whether DevStack supports Nginx server. If yes, can > someone point me in the right direction as to how to achieve this? > DevStack is only set up to use Apache. White technically possible, using Nginx would be a bit of work due to amount of configuration in multiple projects and is not something we intend to do. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Building DevStack
On Thu, Sep 3, 2015 at 1:25 PM, Timothy Symanczyk < timothy_symanc...@symantec.com> wrote: > A simpler way to simply restart horizon would be to follow the advice in > David’s original email. > Actually, to restart Horizon just restart Apache. This also applies to any other services when configured to run under mod_wsgi such as Keystone. As was mentioned earlier, the usual way to do stand-alone service development with DevStack is to start and stop the services within their screen sessions as needed. Ctrl-C, Up Arrow, Return is usually all that is required. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] SSL cert issue on openstack client
On Tue, Mar 22, 2016 at 7:41 PM, Jagga Soorma wrote: > However my mac os x desktop does that without any issues. I was able > to get around this on my CentOS server by downloading the > GeoTrust_CA_Bundle.crt locally and using "export > OS_CACERT=/var/tmp/GeoTrust_CA_Bundle.crt". However, I don't want to > have all my users to have to do this. Is there a way around this on > CentOS/Ubunut? I thought this would be part of the ssl chain included > on these distributions. > There are a couple of possibilities to explain the different behaviour, but some additional information is required to pinpoint the issue. How was OSC installed on the CentOS systems? (I presume that it was installed via pip on OS/X.) Some (if not all) packagers unbundle the urllib3 module that is included in the requests PyPI package. requests also includes its own CA bundle and this is also changed to use the system CA bundle/certs by some packagers. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Get URL for Horizon from CLI?
On Wed, Apr 20, 2016 at 12:41 PM, Ken D'Ambrosio wrote: > So I'm trying to write up a user/tenant creation script, and then when > it's done, I want to fire off an e-mail with relevant info to the new > user. One thing I'd like to send along is the URL for horizon for > whichever cloud I've just created them accounts on... but I don't see how > to get that from the CLI. > Usually, the dashboard URL is not available from any of the REST APIs. It is possible for a deployment to have a dashboard entry in the Service Catalog, if so you can get that using OpenStackClient with this (assuming the service type is 'dashbaord'): openstack catalog show dashboard dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Barcelona Food recommendations
On Thu, Oct 20, 2016 at 11:24 AM, Ed Leafe wrote: > My number one recommendation would be the Boqueria The famous marketplace > in the center of Las Ramblas. > > Enter through the main gates and take are hard left. At the end of the > market is a small restaurant with bar tables and some counter seats, > called Universal. My favorite place. The razor clams, octopus. > Mushrooms. All very simple, but so delicious. Wash it down with a $4 > glass of Rose' and call it a day. We didn't try Universal, but the market is FULL of fish and meat and cheese and bars and little restaurants like this, if you can't find something good there you must not like to eat. > As far as Tapas, The Gotica area has the best places. Don't go till > after 9pm, walk the streets and pop in and out of places all night long. Or keep going northeast across Via Laeitana toward Santa Maria del Mar in el Born. The random tourist ratio goes down, and the places called Bernie's Diner ratio goes up. > There are several other places in the Boqueria that are great and to be > honest, one of the best meals is some simple Ibirico Ham, Hunk of Bread > and some vino. I think most places call this pizza? :) At least Caputxes in el Born did ... dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [openstack-dev] Common client version to communicate with various OpenStack releases
On Sat, Apr 8, 2017 at 1:57 AM, Bharat Kumar Kobagana wrote: > Is it possible use same Python client version to communicate with all > releases? Yes, with one recent exception. If you use the current clients you will be backward-compatible for all non-end-of-life releases, and many before that will still work too, but may not be officially supported. The exception is novaclient 8.0, released last week, that removed all support for Nova network, so older clouds deployed with nova-net will not work for those functions removed (security groups, fixed/floating IPs, etc). novaclient 7.1.0 will still work fine. In general you will want to use the current clients whenever possible. We work very hard to remain backward compatible so users are not required to match clients to the cloud release. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [openstack-dev] Common client version to communicate with various OpenStack releases
On Mon, Apr 10, 2017 at 6:46 AM, Bharat Kumar Kobagana wrote: > Which are the non-end-of-life releases, till Kilo? Everything older than Mitaka is already EOL, Mitaka happens soon. The releases page[0] shows 10 Apr 2017 (today!?) as the EOL date for Mitaka, but I don't think that has officially occurred yet. What this mostly means is what we maintain update releases for and what is tested in our CI. We know there are still a lot of Kilo and Liberty (even older too) clouds running that still need support, and maintaining matching client libs for each release is not something we want to require. The novaclient 8.0 removal is the first instance I can think of in recent memory[1] where we have actually removed code like this, so in general staying on current libraries should be a good strategy. [0] https://releases.openstack.org/ [1] I know as soon as I say that I'll get reminded about something. :) -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [openstack-dev] [all][OSC] OpenStack Interpreter: A useful tool python interpreter tool for the OpenStack client libraries.
On Mon, May 1, 2017 at 11:11 PM, Adrian Turjak wrote: > As part of my dev work I recently put together a cool little tool which > lets me have much easier access to the various OpenStack python clients > in the scope of a python interpreter session. The first version was a > little rough and without os-client-config support. The current version > is now a plugin for the openstackclient and introduces a command that > simply authenticates you, sets up the environment and helper tools, and > then drops you into an ipython interactive session. The helper stuff is > fairly simple, but combined with the features of ipython it really lets > you start playing with the tools quickly, and by piggybacking onto > openstackclient I get access to a lot of the niceties and inbuilt auth > mechanisms. > > It is useful for learning, testing, or development against the various > openstack client libraries, and even as an ops tool to quickly run some > basic actions without having to resort to weird or silly bash command > combinations. This is at the other end of the spectrum of client usage from the CLI in that it takes a very developer-like view of the APIs. OSC has its interactive mode (using cmd2) that is just a command loop without even the ability to change global settings. My hunch is that something in between would be really useful, but I am not interested in creating yet another DSL for this to include flow control and branching. You mentioned Shade, which falls somewhere in between as it implements a lot of logic to hide differences in clouds and ease dealing with some of our API warts. What would you think about producing a Python mirror of the CLI interface with resource names, option names, everything, but in Python. I have not thought all the way through this yet, but think we could take advantage of using the cliff command classes and be able to re-use all of the bits already written. This also magnifies the things we need to add to (or factor out of) OSC to make it truly useful, such as manipulation of the global options, maintaining multiple client contexts, etc. Thanks for sharing! dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Devstack with OpenStack's local repo
On Thu, Nov 2, 2017 at 6:32 AM, Ramu, MohanX wrote: > I want to control that by connecting my local OpenStack repo is it possible? In stackrc you will find a number of environment variable pairs of the form XXX_REPO and XXX_BRANCH. Those can be used to get very specific about the repo and branch to check out for each project and many sub-projects and libraries. Also, the GIT_BASE variable may be sufficient to point at your own collection of repos. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Issues Understanding Neutron Networking Layout
On Thu, Dec 21, 2017 at 4:23 AM, wrote: > Controller in one location with a single IP connection (1 GE) > Compute node in a remote location with 4 10GE connections for public > networking and 1GE IP connection to the Controller > > The VMs on the Compute node will each have 2 10GE connections as they will > be forwarding data. > > I have successfully deployed a Pike system with ODL with the previously > attached local.conf. I'll be blunt here, DevStack is absolutely the wrong tool for this job. The fact that you got this far with it is admirable but it was never intended to support that sort of a custom installation, hence the difficulties you are experiencing. There are a number of assumption in DevStack that are contrary to your setup, including around the network configuration and how multi-node DevStack is built. Unless you really need the services built from source you will have a much better time down the road installing from packages of one form or another, if not just using something like Packstack. Sorting out the network configuration should be easier as you will not need to translate between DevStack's variables and the documented Neutron configs. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Issues Understanding Neutron Networking Layout
On Thu, Dec 21, 2017 at 11:11 AM, wrote: > Can you point me to any documentation to allow me to build to this kind of > layout? I'm afraid I do not have any good pointers for that sort of network setup, thus far my needs have been simple in that dept. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] masakari client (cannot list/add segment)
On Mon, Jul 2, 2018 at 7:43 AM, Torin Woltjer
wrote:
> Installed masakari 4.0.0 on queens. Hostmonitor, instancemonitor, and
> processmonitor all running on compute nodes. API and engine running on
> controller nodes. I've tried using the masakari client to list/add segments,
> any of those commands does nothing and returns:
>
> ("'NoneType' object has no attribute 'auth_url'", ',
> mode 'w' at 0x7f26bb4b71e0>)
That error is not very helpful but the clue is the 'auth_url' part.
This is usually caused by not having your auth variables set properly,
in this case OS_AUTH_URL. Check all of your auth configuration for
the client.
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] neutron python client stopped working
On Thu, Nov 15, 2018 at 2:10 AM Manuel Sopena Ballesteros wrote: > This looks like a stupid thing but I can’t make it to work. For some reason I > can’t run any openstack cli command related to neutron, however using neutron > cli seems to work so I am guessing this is just affecting the the python > client. I tried pip uninstall and install it again with no success. I am > using Rocky deployed through kolla-ansible The thing that sticks out to me here is that the network commands in OSC use the SDK rather than neutronclient and that seems to be what is broken, so verify you have a good install of openstacksdk that matches your python-openstackclient. I have the following versions installed and working: openstacksdk==0.19.0 python-openstackclient==3.17.0 dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
