Re: [Openstack] mailing list etiquette
Mark McLoughlin mar...@redhat.com writes: I wrote this some time ago: https://fedorahosted.org/rhevm-api/wiki/Email_Guidelines If it's helpful, I'm happy to move it across to the OpenStack wiki +1 to that! Chmouel. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Force dhcp release in Centos and Fedora
On 02/08/2012 12:47 PM, Ilya Kharin wrote: Hello. The component nova-network disassociate fixed IP of VM when it deleted. There are two mechanisms by timeout and force. Disassociate by timeout is a periodical task (period can be set by flag --fixed_ip_disassociate_timeout). The force disassociate is optional (enabled by flag --force_dhcp_release) and involved when instance have been deleted. In fact this process use CLI tool dhcp_release to send DHCPRELEASE message to dnsmasq server for drop lease and change state of fixed ip in database. In multi-host scheme it is important. So, dhcp_release is part of dnsmasq and not included in builds in Fedora and CentOS. It probably makes sense to include this command with Fedora 16 (diablo), Fedora 17 (essex), and EPEL 6 (diablo/essex). Also, in Fedora, builds of openstack-nova does not exists sudoers rule for dhcp_release command. Yep we'll handle that for Fedora 16. For Fedora 17 we use the new rootwrap functionality so this config burden is kept within upstream openstack. I created bug report for building dnsmasq with dhcp_release https://bugzilla.redhat.com/show_bug.cgi?id=788485. Cool, we'll discuss the details there so... cheers, Pádraig. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Dashboard: Associate IP doesn't work
Hi I created a server from cirros image using dashboard. I've also assigned a public IP to my tenant. When I try to assign that IP address to my server, the instance name is not shown and when I put mouse over Associate IP the whole page blinks! I am using devstack. It looks like something is wrong with dashboard. Any comment? Thanks Joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Dashboard Error: Unable to get vnc console for instance : The server could not comply with the request since it is either malformed or otherwise incorrect.
I realized that noVNC is not running on my machine. I started noVNC with this command cd /opt/stack/noVNC ./utils/nova-wsproxy.py --flagfile /opt/stack/nova/bin/nova.conf --web . 6080 /var/log/nova/nova-wsproxy.log 21 but it exit with this error message in the log file: WebSocket server settings: - Listen on :6080 - Flash security policy server - Web server. Web root: /opt/stack/noVNC - No SSL/TLS support (no cert file) Traceback (most recent call last): File ./utils/nova-wsproxy.py, line 171, in module server.start_server() File /opt/stack/noVNC/utils/websocket.py, line 760, in start_server lsock = self.socket(self.listen_host, self.listen_port) File /opt/stack/noVNC/utils/websocket.py, line 170, in socket sock.bind(addrs[0][4]) File /usr/lib/python2.7/socket.py, line 224, in meth return getattr(self._sock,name)(*args) socket.error: [Errno 98] Address already in use ~ I'd appreciate your help to fix the VNC issue. Regards Joe On Fri, Jan 27, 2012 at 11:56 AM, Joe Smithian joe.smith...@gmail.com wrote: Hi, I've lunched an instance using OpenStack dashboard but can't start a VNC session. It displays this error message: Error: Unable to get vnc console for instance 40c098b8-1c92-4b16-9c33-964ef6c5b950: The server could not comply with the request since it is either malformed or otherwise incorrect. Any idea what's wrong and how can be fixed? Thanks Joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] mailing list etiquette
On Wed, Feb 8, 2012 at 7:59 AM, Chmouel Boudjnah chmo...@openstack.orgwrote: Mark McLoughlin mar...@redhat.com writes: I wrote this some time ago: https://fedorahosted.org/rhevm-api/wiki/Email_Guidelines If it's helpful, I'm happy to move it across to the OpenStack wiki +1 +1 to that! Chmouel. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] NEuca Extentions for OpenStack
We work on the Open Resource Control Architecture (ORCA) project at RENCI UNC-Chapel Hill in collaboration with Duke University. ORCA is a control framework for provisioning virtual networked systems over heterogenous resources from substrates distributed across administrative domains. A simpler, but incomplete description is that ORCA provisions virtual environments of virtual and physical machines federated from multiple cloud sites with bandwidth provisioned network that connect them. It does this on demand, in response to the current needs of the users. ORCA is a long-term NSF GENI sponsored project that has been in development for nearly a decade. ORCA itself does not depend on any specific cloud virtualization stack and we have primarily been using Eucalyptus. Recently we have added OpenStack support. We like a lot of the features of OpenStack and will be primarily be using OpenStack going forward. However, ORCA requires modifications to the network functionality of both Eucalyptus and OpenStack. We call this modification Neuca and it has been incorporated into the main Eucalyptus release for about a year. I am contacting this list because I would like work on getting Necua extensions included into OpenStack. I am hoping that this message will find the appropriate people. More information about ORCA, NEuca, and RENCI can be found at the following urls: https://geni-orca.renci.org/trac/ https://geni-orca.renci.org/trac/wiki/NEuca-overview http://www.renci.org/ thanks, Paul Ruth Senior Distributed Systems Resercher RENCI - UNC Chapel Hill pr...@renci.orgmailto:pr...@renci.org ___ 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] mailing list etiquette
On Wed, 2012-02-08 at 09:58 -0500, andi abes wrote: On Wed, Feb 8, 2012 at 7:59 AM, Chmouel Boudjnah chmo...@openstack.orgwrote: Mark McLoughlin mar...@redhat.com writes: I wrote this some time ago: https://fedorahosted.org/rhevm-api/wiki/Email_Guidelines If it's helpful, I'm happy to move it across to the OpenStack wiki +1 +1 to that! Thanks guys. I've moved it to here: http://wiki.openstack.org/MailingListEtiquette Cheers, Mark. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [CHEF] Aligning Cookbook Efforts
On 02/08/2012 01:40 AM, Monty Taylor wrote: On 02/07/2012 08:32 PM, Jay Pipes wrote: Well, in my original email I proposed using the NTT PF Lab branch point for the stable/diablo branch of the upstream chef repos. If we can get a casual consensus from folks that this is OK, I will go ahead and push that to Gerrit. Please +1 if you are cool with that. This will allow us to have a branch of the upstream cookbooks that aligns with the core projects. Ping me when you want to do that... jeblair and I can handle getting the branch in once you have it. I'd like to do it today, please. Find me on IRC and we'll get this done. Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Devstack (sh) and tmux
Hi, As mentioned in bug #928967[1] tmux support in devstack is not working and I was wondering if there was much people using it and if I should fix it. The advantage of tmux support is aside of being arguably a better terminal wm it allows support for different shells than bash (ie: zsh) for devstack as reported in bug #928883[2]. What do you think? Is anyone using much tmux or other shells than bash with devstack. Chmouel. [1] https://bugs.launchpad.net/devstack/+bug/928967 [1] https://bugs.launchpad.net/devstack/+bug/928883 ___ 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] NEuca Extentions for OpenStack
Debo, Thanks for that link. It does seem that might be able to use the Quantum API. I will check it out and try to join their group. Paul On Feb 8, 2012, at 11:39 AM, Debo Dutta (dedutta) wrote: Have you guys looked at Quantum? Can the neuca model be adapted to use the quantum APIs? http://wiki.openstack.org/Quantum From a very high level, your neuca patches are bringing up VMs on a specific VLAN. eth1=vlan:eth0:20:192.168.1.3/24 ; eth1 attaches to eth0.20 on host and has IP 192.168.1.3/24 eth2=vlan:eth0:19:192.168.2.3/24 ; eth2 attaches to eth0.19 on host and has IP 192.168.2.3/24 In quantum, the *network* is the primary abstraction and can be implemented using VLANs or tunnels etc. We can create separate networks and bring up VMs on specified networks. debo From: openstack-bounces+dedutta=cisco@lists.launchpad.netmailto:openstack-bounces+dedutta=cisco@lists.launchpad.net [mailto:openstack-bounces+dedutta=cisco@lists.launchpad.net] On Behalf Of Paul Ruth Sent: Wednesday, February 08, 2012 8:28 AM To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Cc: Ilia Baldine Subject: [Openstack] NEuca Extentions for OpenStack We work on the Open Resource Control Architecture (ORCA) project at RENCI UNC-Chapel Hill in collaboration with Duke University. ORCA is a control framework for provisioning virtual networked systems over heterogenous resources from substrates distributed across administrative domains. A simpler, but incomplete description is that ORCA provisions virtual environments of virtual and physical machines federated from multiple cloud sites with bandwidth provisioned network that connect them. It does this on demand, in response to the current needs of the users. ORCA is a long-term NSF GENI sponsored project that has been in development for nearly a decade. ORCA itself does not depend on any specific cloud virtualization stack and we have primarily been using Eucalyptus. Recently we have added OpenStack support. We like a lot of the features of OpenStack and will be primarily be using OpenStack going forward. However, ORCA requires modifications to the network functionality of both Eucalyptus and OpenStack. We call this modification Neuca and it has been incorporated into the main Eucalyptus release for about a year. I am contacting this list because I would like work on getting Necua extensions included into OpenStack. I am hoping that this message will find the appropriate people. More information about ORCA, NEuca, and RENCI can be found at the following urls: https://geni-orca.renci.org/trac/ https://geni-orca.renci.org/trac/wiki/NEuca-overview http://www.renci.org/ thanks, Paul Ruth Senior Distributed Systems Resercher RENCI - UNC Chapel Hill pr...@renci.orgmailto:pr...@renci.org ___ 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 (sh) and tmux
On 02/08/2012 11:44 AM, Chmouel Boudjnah wrote: Hi, As mentioned in bug #928967[1] tmux support in devstack is not working and I was wondering if there was much people using it and if I should fix it. The advantage of tmux support is aside of being arguably a better terminal wm it allows support for different shells than bash (ie: zsh) for devstack as reported in bug #928883[2]. What do you think? Is anyone using much tmux or other shells than bash with devstack. Nope, I only use bash... -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Devstack (sh) and tmux
the reason for adding tmux is that we were running into issues with services not launching inside screen (due to a timing issue). I'm for removing tmux - since the sleep between creating a screen using it has resolved the issue. Jesse On Wed, Feb 8, 2012 at 9:39 AM, Jay Pipes jaypi...@gmail.com wrote: On 02/08/2012 11:44 AM, Chmouel Boudjnah wrote: Hi, As mentioned in bug #928967[1] tmux support in devstack is not working and I was wondering if there was much people using it and if I should fix it. The advantage of tmux support is aside of being arguably a better terminal wm it allows support for different shells than bash (ie: zsh) for devstack as reported in bug #928883[2]. What do you think? Is anyone using much tmux or other shells than bash with devstack. Nope, I only use bash... -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Heads-up: new glance dependency on pysendfile
Folks, Just a quick heads-up that this review[1] if accepted will result in glance taking a soft dependency on pysendfile. The import is conditional, so where pysendfile is unavailable on a particular distro, the 'glance add' command will simply fallback to the pre-existing chunk-at-a-time logic. Russell Bryant is working on packaging pysendfile for Fedora[2], so that base will be covered. I also spoke to the maintainer of pysendfile and there are ogoing efforts in his community to update the python-sendfile packages for Debian/Ubuntu - the existing packages[3] were based on the now-obsolete 1.4.x version of pysendfile. Cheers, Eoghan [1] https://review.openstack.org/#change,3863 [2] http://www.spinics.net/linux/fedora/fedora-cloud/msg01224.html [3] http://packages.ubuntu.com/search?keywords=python-sendfile ___ 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 (sh) and tmux
Why not just daemonize the processes ;) This is pretty much what I am doing in devstackpy and it seems to work pretty well. I think people are pretty familiar with PID files, and files which contain stderr/stout as this is how a lot of other unix stuff runs. On 2/8/12 9:45 AM, Jesse Andrews anotherje...@gmail.com wrote: the reason for adding tmux is that we were running into issues with services not launching inside screen (due to a timing issue). I'm for removing tmux - since the sleep between creating a screen using it has resolved the issue. Jesse On Wed, Feb 8, 2012 at 9:39 AM, Jay Pipes jaypi...@gmail.com wrote: On 02/08/2012 11:44 AM, Chmouel Boudjnah wrote: Hi, As mentioned in bug #928967[1] tmux support in devstack is not working and I was wondering if there was much people using it and if I should fix it. The advantage of tmux support is aside of being arguably a better terminal wm it allows support for different shells than bash (ie: zsh) for devstack as reported in bug #928883[2]. What do you think? Is anyone using much tmux or other shells than bash with devstack. Nope, I only use bash... -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] officialize it!
+ ? On 2/8/12 5:10 AM, Andiabes andi.a...@gmail.com wrote: If do, maybe you can adapt the API to conform to: http://www.ietf.org/rfc/rfc2325.txt On Feb 7, 2012, at 6:26 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: Re: [Openstack] [DEVSTACK] officialize it! Ah, toaster as a service. I think java already did that ;) On 2/7/12 7:18 AM, Jay Pipes jaypi...@gmail.com wrote: On 02/07/2012 05:18 AM, Thierry Carrez wrote: Shameless plug: just a few weeks left before the core projects for Folsom are decided, so projects in incubation should propose themselves soon! Other projects that would like to be considered for Folsom core should probably have been in incubation for quite some time now. Thanks for the reminder, Thierry... I need to get my Toaster-as-a-Service project proposed for incubation. :) -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] [CHEF] Aligning Cookbook Efforts
Hi Jay, Thanks for taking the initiative to send this out! I added comments to your points are inline below: Proposal for Alignment == I think the following steps would be good to get done by the time Essex rolls out the door in April: 1) Create a stable/diablo branch of the openstack/openstack-chef cookbook repo and maintain it in the same way that we maintain stable branches for core OpenStack projects. I propose we use the branch point that NTT PF Lab used to create their fork of the upstream repo. I like the idea of maintaining a stable set of cookbooks for the official releases. The NTT branch sounds fine to me as a starting point for diablo. At the time of the diablo release I was maintaining cookbooks for SmokeStack here: https://github.com/dprince/openstack_cookbooks. Using these cookbooks around the date of the diablo release would be an option as well. 2) Work with Matt Ray and other Chef experts to combine any and all best practices that may be contained in the non-official cookbook repos into the upstream official repository. From a cursory overview, there are some differences in how databags are handled, how certs are handled, how certain cookbooks are constructed, and of course differences in the actual cookbooks in the repos themselves. 3) Consolidate documentation on how to use the cookbooks, the best practices used in constructing the cookbooks, and possibly some videos/tutorials walking folks through this critical piece of the OpenStack puzzle. This sounds great. 4) Create Jenkins builders for stable branch deployment testing. We currently test the official development cookbooks by way of SmokeStack gates on all core OpenStack projects. Would be great to get the same testing automated for non-development branches of the cookbooks. SmokeStack would easily support testing stable releases. In fact it be a lot easier to pull off stable release testing than it is to chase trunk like I'm currently doing :) I actually have a 'Libvirt Mysql Milestone Proposed (Diablo)' configuration in SmokeStack. I just haven't been running it mostly because I was focused on upstream releases and commits. Limited resources and time Getting more people involved would be great. Thoughts and criticism most welcome, and apologies in advance if I got any of the above history wrong. Feel free to correct me! Best, -jay One final note: We are looking at adding dual support for Fedora/puppet and Ubuntu/chef to SmokeStack in the near future. A guy named Derek Higgins from Red Hat has made excellent progress on this front. -- Dan Prince princ...@alumni.jmu.edu ___ 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] Heads-up: new glance dependency on pysendfile
Good to know! Thanks for the notice. Benchmark looks pretty awesome. BTW, does anybody knows who is taking care of it for Debian? Cheers, Ghe Rivero On Wed, Feb 8, 2012 at 7:16 PM, Eoghan Glynn egl...@redhat.com wrote: Folks, Just a quick heads-up that this review[1] if accepted will result in glance taking a soft dependency on pysendfile. The import is conditional, so where pysendfile is unavailable on a particular distro, the 'glance add' command will simply fallback to the pre-existing chunk-at-a-time logic. Russell Bryant is working on packaging pysendfile for Fedora[2], so that base will be covered. I also spoke to the maintainer of pysendfile and there are ogoing efforts in his community to update the python-sendfile packages for Debian/Ubuntu - the existing packages[3] were based on the now-obsolete 1.4.x version of pysendfile. Cheers, Eoghan [1] https://review.openstack.org/#change,3863 [2] http://www.spinics.net/linux/fedora/fedora-cloud/msg01224.html [3] http://packages.ubuntu.com/search?keywords=python-sendfile ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Ghe Rivero *OpenStack Distribution Engineer **www.stackops.com | * ghe.riv...@stackops.com diego.parri...@stackops.com ** | +34 625 63 45 23 | skype:ghe.rivero* * http://www.stackops.com/ * * ADVERTENCIA LEGAL Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley. * PRIVILEGED AND CONFIDENTIAL We hereby inform you, as addressee of this message, that e-mail and Internet do not guarantee the confidentiality, nor the completeness or proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does not assume any liability for those circumstances. Should you not agree to the use of e-mail or to communications via Internet, you are kindly requested to notify us immediately. This message is intended exclusively for the person to whom it is addressed and contains privileged and confidential information protected from disclosure by law. If you are not the addressee indicated in this message, you should immediately delete it and any attachments and notify the sender by reply e-mail. In such case, you are hereby notified that any dissemination, distribution, copying or use of this message or any attachments, for any purpose, is strictly prohibited by law. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Devstack (sh) and tmux
I like the idea of demonize it. Everyone using devstack should be able to open a terminal and use tail in the logs to see what's going on. Or maybe an option can be added to devstack to choose daemon vs. screen . BTW I use tmux+bash Ghe Rivero On Wed, Feb 8, 2012 at 7:24 PM, Joshua Harlow harlo...@yahoo-inc.comwrote: Why not just daemonize the processes ;) This is pretty much what I am doing in devstackpy and it seems to work pretty well. I think people are pretty familiar with PID files, and files which contain stderr/stout as this is how a lot of other unix stuff runs. On 2/8/12 9:45 AM, Jesse Andrews anotherje...@gmail.com wrote: the reason for adding tmux is that we were running into issues with services not launching inside screen (due to a timing issue). I'm for removing tmux - since the sleep between creating a screen using it has resolved the issue. Jesse On Wed, Feb 8, 2012 at 9:39 AM, Jay Pipes jaypi...@gmail.com wrote: On 02/08/2012 11:44 AM, Chmouel Boudjnah wrote: Hi, As mentioned in bug #928967[1] tmux support in devstack is not working and I was wondering if there was much people using it and if I should fix it. The advantage of tmux support is aside of being arguably a better terminal wm it allows support for different shells than bash (ie: zsh) for devstack as reported in bug #928883[2]. What do you think? Is anyone using much tmux or other shells than bash with devstack. Nope, I only use bash... -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Ghe Rivero *OpenStack Distribution Engineer **www.stackops.com | * ghe.riv...@stackops.com diego.parri...@stackops.com ** | +34 625 63 45 23 | skype:ghe.rivero* * http://www.stackops.com/ * * ADVERTENCIA LEGAL Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley. * PRIVILEGED AND CONFIDENTIAL We hereby inform you, as addressee of this message, that e-mail and Internet do not guarantee the confidentiality, nor the completeness or proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does not assume any liability for those circumstances. Should you not agree to the use of e-mail or to communications via Internet, you are kindly requested to notify us immediately. This message is intended exclusively for the person to whom it is addressed and contains privileged and confidential information protected from disclosure by law. If you are not the addressee indicated in this message, you should immediately delete it and any attachments and notify the sender by reply e-mail. In such case, you are hereby notified that any dissemination, distribution, copying or use of this message or any attachments, for any purpose, is strictly prohibited by law. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Heads-up: new glance dependency on pysendfile
BTW, does anybody knows who is taking care of it for Debian? Apparently Janoš Guljaš ja...@resenje.org was looking at packaging it for Debian. But apparently the original mainntainer of the python-sendfile package is uncontactable so a team upload (Debian Python Modules Team) would be needed Cheers, Eoghan ___ 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] Adding a Glance image via API without POSTing the image data?
Yep, that's pretty much exactly the implementation we were hoping might exist. If it can be built that would be phenomenal. Any thoughts on whether that might be possible before E4 closes, or will it have to wait until Folsom? - Gabriel -Original Message- From: Eoghan Glynn [mailto:egl...@redhat.com] Sent: Wednesday, February 08, 2012 3:12 AM To: Tres Henry; Gabriel Hurley Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Adding a Glance image via API without POSTing the image data? I think this is a slightly different (but related) use case. In this case the user wants to add an image to the configured Glance store through the web front-end performing the same task as 'glance add name=foo is_public=true blah.tar.gz' in the CLI. Ideally Horizon would provide a UI that allows the user to specify an image location URL and then optionally a check box for upload to image store or something along those lines. A-ha, I see what you mean. AFAIK that mode of upload separate to the image POST is not currently supported, but it would be quite straightforward to add say support for a header that identifies an image location for glance to retrieve from (as opposed to just recording the external location). Something like: X-Image-Meta-Retrieve-From: URI where URI is a HTTP, S3, or Swift location that's accessible to the glance API service. Would that address your use-case, Gabriel? Cheers, Eoghan On Feb 7, 2012, at 2:09 PM, Eoghan Glynn wrote: The Horizon team is looking at adding a first-pass implementation of image upload before the Essex release, and we'd really like to bypass the problems associated with, say, passing a 700MB Ubuntu image through the user's browser to a web server and then across to Glance... So the question is this: is there a way to add an image to Glance via the API *without* passing the image data in via the POST body? Options might include specifying a Swift object for the image, or a download URL... Hi Gabriel, Check out the X-Image-Meta-Location header which allows a pre-existing HTTP, S3, Swift or 'file://' image location to be specified. The result is that the image content is not uploaded to glance, instead the external location is relied upon. Cheers, Eoghan ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Devstack (sh) and tmux
On 02/08/2012 01:54 PM, Ghe Rivero wrote: I like the idea of demonize it. Everyone using devstack should be able to open a terminal and use tail in the logs to see what's going on. Or maybe an option can be added to devstack to choose daemon vs. screen . Option is best. I find both scenarios useful depending on what I'm working on. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Adding a Glance image via API without POSTing the image data?
Yep, that's pretty much exactly the implementation we were hoping might exist. If it can be built that would be phenomenal. Any thoughts on whether that might be possible before E4 closes, or will it have to wait until Folsom? I'll propose a blueprint and see if I can get it approved for E4. My feeling is that it should be do-able in that timeframe. Cheers, Eoghan From: Eoghan Glynn [mailto:egl...@redhat.com] A-ha, I see what you mean. AFAIK that mode of upload separate to the image POST is not currently supported, but it would be quite straightforward to add say support for a header that identifies an image location for glance to retrieve from (as opposed to just recording the external location). Something like: X-Image-Meta-Retrieve-From: URI where URI is a HTTP, S3, or Swift location that's accessible to the glance API service. Would that address your use-case, Gabriel? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Devstack (sh) and tmux
I'd vote for having daemonize as an option at best. In a development environment it's very nice to be able to kill all processes just by terminating the `screen' ( or `tmux') session rather than having to kill all the daemons individually. Plus it's nice to be able to see the current output from each process without having to worry about data that is still stuck in output buffers. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 From: openstack-bounces+donald.d.dugger=intel@lists.launchpad.net [mailto:openstack-bounces+donald.d.dugger=intel@lists.launchpad.net] On Behalf Of Ghe Rivero Sent: Wednesday, February 08, 2012 11:54 AM To: Joshua Harlow Cc: openstack Subject: Re: [Openstack] Devstack (sh) and tmux I like the idea of demonize it. Everyone using devstack should be able to open a terminal and use tail in the logs to see what's going on. Or maybe an option can be added to devstack to choose daemon vs. screen . BTW I use tmux+bash Ghe Rivero On Wed, Feb 8, 2012 at 7:24 PM, Joshua Harlow harlo...@yahoo-inc.commailto:harlo...@yahoo-inc.com wrote: Why not just daemonize the processes ;) This is pretty much what I am doing in devstackpy and it seems to work pretty well. I think people are pretty familiar with PID files, and files which contain stderr/stout as this is how a lot of other unix stuff runs. On 2/8/12 9:45 AM, Jesse Andrews anotherje...@gmail.comhttp://anotherje...@gmail.com wrote: the reason for adding tmux is that we were running into issues with services not launching inside screen (due to a timing issue). I'm for removing tmux - since the sleep between creating a screen using it has resolved the issue. Jesse On Wed, Feb 8, 2012 at 9:39 AM, Jay Pipes jaypi...@gmail.comhttp://jaypi...@gmail.com wrote: On 02/08/2012 11:44 AM, Chmouel Boudjnah wrote: Hi, As mentioned in bug #928967[1] tmux support in devstack is not working and I was wondering if there was much people using it and if I should fix it. The advantage of tmux support is aside of being arguably a better terminal wm it allows support for different shells than bash (ie: zsh) for devstack as reported in bug #928883[2]. What do you think? Is anyone using much tmux or other shells than bash with devstack. Nope, I only use bash... -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.nethttp://openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.nethttp://openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Ghe Rivero OpenStack Distribution Engineer www.stackops.comhttp://www.stackops.com/ | ghe.riv...@stackops.commailto:diego.parri...@stackops.com | +34 625 63 45 23 | skype:ghe.rivero http://www.stackops.com/ [http://stackops.s3-external-3.amazonaws.com/STACKOPSLOGO-ICON.png] ADVERTENCIA LEGAL Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley. * PRIVILEGED AND CONFIDENTIAL We hereby inform you, as addressee of this message, that e-mail and Internet do not guarantee the confidentiality, nor the completeness or proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does not assume any liability for those circumstances.
Re: [Openstack] three things about OpenStack docs
Hi Jaesuk - I would love to enable translation efforts for docs, but cannot coordinate them myself. In November, I sent a message to the mailing list [1] describing an outline for a process, but haven't identified anyone who would like to head up translation of documentation. A couple of thoughts for your content in particular: 1. People are welcome to add pages to the OpenStack wiki that are Korean translations of a page. Create the page by adding /ko to the URL of the page you want to translate then use this code at the top of the page: ##master-page:DevQuickstart ##master-date:2012-01-31 20:44:32 ##master-revision:6 #language ko 2. People could add to the Korean translation effort for the error strings. Here's an example of it for the nova project. https://translations.launchpad.net/nova/trunk/+pots/nova/ko/+translate Looks like Zhongyue Luo has been active there (go LZY!). I hope this is helpful to you and others who would like more of your first language covered by OpenStack. Please let me know if you have additional questions. Anne [1] http://www.mail-archive.com/openstack@lists.launchpad.net/msg05721.html On Mon, Feb 6, 2012 at 9:19 AM, Jaesuk Ahn bluejay@gmail.com wrote: Anne, This is Jaesuk Ahn from Korea User Group. Since the opening of OpenStack Korea Community last year, we have been keeping our (korean) wiki to share the information among the members. http://wiki.openstack.or.kr Most of wiki contents is about overview and installation. Most of wiki contents is created by our community members, not a direct translation of openstack documentation. As the number of people participating in the community activity grows up, there has been more people interested in documentation in two ways; 1) contributing to Korean wiki, and 2) participating in translation of the openstack documents, something like localization team at openstack docs. Although it has been a good thing for us to have our own wikipage to share information, IMHO, there should be a better way to collaborate with original openstack docs team to align what we are doing in Korea with global community. For example, we can gather the people from our Korea community, and make a team to work on Korean-version of openstack docs. If you have any idea for us to collaborate more with openstack.org, please let us know it. Thank you. On Sat, Jan 28, 2012 at 3:31 AM, Anne Gentle a...@openstack.org wrote: Hi all - I thought you'd want to know these three things about docs going on lately. 1. The new installation guide for Diablo that includes Compute, Identity, Image, and the Dashboard is now published. Find it here:http://docs.openstack.org/diablo/openstack-compute/install/content/. 2. The PDF links on the home page are being replaced with PDF links in the top bar of the HTML manual itself. PDFs aren't going missing, but the button is moving. Tell your friends and neighbors. 3. Now that we have feature freeze for many features, I'm going to start a list of documentation needs for the Essex release. This list will assist with doc priorities. 4. I lied when I said three things. 5. We'd like to hold a Doc Day in March to prep for the Essex release, similar to the Bug Squash day coming up next week. I'd like to visit sunny California for Doc Day but want other locations to feel free to hold their own as well. 6. The stable/diablo branch of openstack-manuals has been blocked from publishing for a little while but I'm aware of the problem and so are the members of the CI team. We'll get it fixed and will free the floodgates for the backported fixes. 7. We've got a great new manual titled Programming OpenStack Compute API with Shell and Python authored by Jacek Artymiak of DevGuide.net. I'm working on the backend to automate publishing from Markdown to get it on docs.openstack.org, but you can review the Markdown submission here: https://review.openstack.org/3515. 8. I'd like to go to a weekly docs team meeting for the remainder of the Essex release. I'd also like to change the time of day, but likely keep it on Monday prior to the team meeting. Suggestions welcome! As always, feel free to ask questions and rock the docs. Warmly, Anne ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Jaesuk Ahn, Ph.D. Team Leader | Cloud OS Dev. Team Cloud Infrastructure Department KT (Korea Telecom) T. +82-10-9888-0328 | F. +82-303-0993-5340 Active member on OpenStack Korea Community ___ 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 (sh) and tmux
Doesn't stdout have a buffer also ;) I'm all for options :-) On 2/8/12 11:15 AM, Dugger, Donald D donald.d.dug...@intel.com wrote: I'd vote for having daemonize as an option at best. In a development environment it's very nice to be able to kill all processes just by terminating the `screen' ( or `tmux') session rather than having to kill all the daemons individually. Plus it's nice to be able to see the current output from each process without having to worry about data that is still stuck in output buffers. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 From: openstack-bounces+donald.d.dugger=intel@lists.launchpad.net [mailto:openstack-bounces+donald.d.dugger=intel@lists.launchpad.net] On Behalf Of Ghe Rivero Sent: Wednesday, February 08, 2012 11:54 AM To: Joshua Harlow Cc: openstack Subject: Re: [Openstack] Devstack (sh) and tmux I like the idea of demonize it. Everyone using devstack should be able to open a terminal and use tail in the logs to see what's going on. Or maybe an option can be added to devstack to choose daemon vs. screen . BTW I use tmux+bash Ghe Rivero On Wed, Feb 8, 2012 at 7:24 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: Why not just daemonize the processes ;) This is pretty much what I am doing in devstackpy and it seems to work pretty well. I think people are pretty familiar with PID files, and files which contain stderr/stout as this is how a lot of other unix stuff runs. On 2/8/12 9:45 AM, Jesse Andrews anotherje...@gmail.com http://anotherje...@gmail.com wrote: the reason for adding tmux is that we were running into issues with services not launching inside screen (due to a timing issue). I'm for removing tmux - since the sleep between creating a screen using it has resolved the issue. Jesse On Wed, Feb 8, 2012 at 9:39 AM, Jay Pipes jaypi...@gmail.com http://jaypi...@gmail.com wrote: On 02/08/2012 11:44 AM, Chmouel Boudjnah wrote: Hi, As mentioned in bug #928967[1] tmux support in devstack is not working and I was wondering if there was much people using it and if I should fix it. The advantage of tmux support is aside of being arguably a better terminal wm it allows support for different shells than bash (ie: zsh) for devstack as reported in bug #928883[2]. What do you think? Is anyone using much tmux or other shells than bash with devstack. Nope, I only use bash... -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net http://openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net http://openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Devstack (sh) and tmux
Unless they've changed things (I've worked on so many versions of Linux/Unix I do get confused :) but `stdio' is supposed to check and, if the output is a file then it's buffered and, if it's a terminal, then it's unbuffered. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 From: Joshua Harlow [mailto:harlo...@yahoo-inc.com] Sent: Wednesday, February 08, 2012 1:16 PM To: Dugger, Donald D; Ghe Rivero Cc: openstack Subject: Re: [Openstack] Devstack (sh) and tmux Doesn't stdout have a buffer also ;) I'm all for options :-) On 2/8/12 11:15 AM, Dugger, Donald D donald.d.dug...@intel.com wrote: I'd vote for having daemonize as an option at best. In a development environment it's very nice to be able to kill all processes just by terminating the `screen' ( or `tmux') session rather than having to kill all the daemons individually. Plus it's nice to be able to see the current output from each process without having to worry about data that is still stuck in output buffers. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 From: openstack-bounces+donald.d.dugger=intel@lists.launchpad.net [mailto:openstack-bounces+donald.d.dugger=intel@lists.launchpad.net] On Behalf Of Ghe Rivero Sent: Wednesday, February 08, 2012 11:54 AM To: Joshua Harlow Cc: openstack Subject: Re: [Openstack] Devstack (sh) and tmux I like the idea of demonize it. Everyone using devstack should be able to open a terminal and use tail in the logs to see what's going on. Or maybe an option can be added to devstack to choose daemon vs. screen . BTW I use tmux+bash Ghe Rivero On Wed, Feb 8, 2012 at 7:24 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: Why not just daemonize the processes ;) This is pretty much what I am doing in devstackpy and it seems to work pretty well. I think people are pretty familiar with PID files, and files which contain stderr/stout as this is how a lot of other unix stuff runs. On 2/8/12 9:45 AM, Jesse Andrews anotherje...@gmail.com http://anotherje...@gmail.com wrote: the reason for adding tmux is that we were running into issues with services not launching inside screen (due to a timing issue). I'm for removing tmux - since the sleep between creating a screen using it has resolved the issue. Jesse On Wed, Feb 8, 2012 at 9:39 AM, Jay Pipes jaypi...@gmail.com http://jaypi...@gmail.com wrote: On 02/08/2012 11:44 AM, Chmouel Boudjnah wrote: Hi, As mentioned in bug #928967[1] tmux support in devstack is not working and I was wondering if there was much people using it and if I should fix it. The advantage of tmux support is aside of being arguably a better terminal wm it allows support for different shells than bash (ie: zsh) for devstack as reported in bug #928883[2]. What do you think? Is anyone using much tmux or other shells than bash with devstack. Nope, I only use bash... -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net http://openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net http://openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Devstack (sh) and tmux
Ya, I get confused also :-P Never really know when anymore, haha. On 2/8/12 12:23 PM, Dugger, Donald D donald.d.dug...@intel.com wrote: Unless they've changed things (I've worked on so many versions of Linux/Unix I do get confused :) but `stdio' is supposed to check and, if the output is a file then it's buffered and, if it's a terminal, then it's unbuffered. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 From: Joshua Harlow [mailto:harlo...@yahoo-inc.com] Sent: Wednesday, February 08, 2012 1:16 PM To: Dugger, Donald D; Ghe Rivero Cc: openstack Subject: Re: [Openstack] Devstack (sh) and tmux Doesn't stdout have a buffer also ;) I'm all for options :-) On 2/8/12 11:15 AM, Dugger, Donald D donald.d.dug...@intel.com wrote: I'd vote for having daemonize as an option at best. In a development environment it's very nice to be able to kill all processes just by terminating the `screen' ( or `tmux') session rather than having to kill all the daemons individually. Plus it's nice to be able to see the current output from each process without having to worry about data that is still stuck in output buffers. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 From: openstack-bounces+donald.d.dugger=intel@lists.launchpad.net [mailto:openstack-bounces+donald.d.dugger=intel@lists.launchpad.net] On Behalf Of Ghe Rivero Sent: Wednesday, February 08, 2012 11:54 AM To: Joshua Harlow Cc: openstack Subject: Re: [Openstack] Devstack (sh) and tmux I like the idea of demonize it. Everyone using devstack should be able to open a terminal and use tail in the logs to see what's going on. Or maybe an option can be added to devstack to choose daemon vs. screen . BTW I use tmux+bash Ghe Rivero On Wed, Feb 8, 2012 at 7:24 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: Why not just daemonize the processes ;) This is pretty much what I am doing in devstackpy and it seems to work pretty well. I think people are pretty familiar with PID files, and files which contain stderr/stout as this is how a lot of other unix stuff runs. On 2/8/12 9:45 AM, Jesse Andrews anotherje...@gmail.com http://anotherje...@gmail.com wrote: the reason for adding tmux is that we were running into issues with services not launching inside screen (due to a timing issue). I'm for removing tmux - since the sleep between creating a screen using it has resolved the issue. Jesse On Wed, Feb 8, 2012 at 9:39 AM, Jay Pipes jaypi...@gmail.com http://jaypi...@gmail.com wrote: On 02/08/2012 11:44 AM, Chmouel Boudjnah wrote: Hi, As mentioned in bug #928967[1] tmux support in devstack is not working and I was wondering if there was much people using it and if I should fix it. The advantage of tmux support is aside of being arguably a better terminal wm it allows support for different shells than bash (ie: zsh) for devstack as reported in bug #928883[2]. What do you think? Is anyone using much tmux or other shells than bash with devstack. Nope, I only use bash... -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net http://openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net http://openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Devstack (sh) and tmux
On Wed, Feb 08, 2012, Dugger, Donald D donald.d.dug...@intel.com wrote: Unless they've changed things (I've worked on so many versions of Linux/Unix I do get confused :) but `stdio' is supposed to check and, if the output is a file then it's buffered and, if it's a terminal, then it's unbuffered. Hi Don! I'm pretty sure this can vary from system to system, but generally stdio is line buffered if connected to a terminal. http://www.pixelbeat.org/programming/stdio_buffering/ Either way, your point still stands :) JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova command line versus Euca2ools
You understanding of the endpointTemplates is consistent with mine
endpointTemplate add [region] [service_name] [public_url] [admin_url]
[internal_url] [enabled] [is_global]
The public_url is accessible from outside the VM network and the internal
URL is accessible from the VM network.
Michael
-
Michael Fork
Cloud Architect, Emerging Solutions
IBM Systems Technology Group
From: Lillie Ross-CDSR11 ross.lil...@motorolasolutions.com
To: Michael J Fork/Rochester/IBM@IBMUS
Cc: Lillie Ross-CDSR11 ross.lil...@motorolasolutions.com,
openstack@lists.launchpad.net openstack@lists.launchpad.net, Kiall Mac
Innes ki...@managedit.ie
Date: 02/07/2012 05:32 PM
Subject:Re: [Openstack] Nova command line versus Euca2ools
The sweet smell of success...
Looking closely at my api-paste.ini file, and comparing to Kiall's
(ManagediT) templates, I noticed that I had my authorization pipelines
setup wrong. So I corrected these errors and now all nova client commands
seem to execute with no problem. Additionally, dashboard and euca2ools
now seems to be working without any errors. It's a beautiful thing!
Now a question. My network/installation is setup to isolate nova-compute
traffic on a private network. Should endpointTemplates be setup to
specify the private network URL for Internal URL field of the template?
My guess is yes, but thought I'd ask anyways.
Now, on to configuring Swift.
Thanks for everyone's patience and help. And thanks again to Kiall for
figuring all this out and leading the way.
Regards,
Ross
On Feb 6, 2012, at 5:09 PM, Michael J Fork wrote:
Can you verify your glance endpointTemplate is http://%HOST_IP%:9292/v1 ?
Hard to tell from the trace below if the v1.1/1/images/detail is against
the Nova API or Glance API.
Michael
-
Michael Fork
Cloud Architect, Emerging Solutions
IBM Systems Technology Group
From:Lillie Ross-CDSR11 ross.lil...@motorolasolutions.com
To:openstack@lists.launchpad.net openstack@lists.launchpad.net
Date:02/06/2012 05:41 PM
Subject:[Openstack] Nova command line versus Euca2ools
Sent by:openstack-bounces+mjfork=us.ibm@lists.launchpad.net
I currently have OpenStack installed (using the ManagedIT PPA) to use
Keystone for authentication. However I'm still receiving a number of
Malformed request URL messages, both in Dashboard as well as when using
the Nova command line client. Also, some of the Euca2ools command run OK,
others (such as euca-describe-images) don't. I'm aware that not all the
Euca commands are supported in Diablo, but currently I don't have any
commands that let me launch instances.
For example: euca-describe-availability-zones verbose yields
root@nova:~# euca-describe-availability-zones verbose
AVAILABILITYZONE nova available
AVAILABILITYZONE |- nova
AVAILABILITYZONE | |- nova-network enabled :-) 2012-02-06 22:15:16
AVAILABILITYZONE | |- nova-scheduler enabled :-) 2012-02-06 22:15:15
AVAILABILITYZONE | |- nova-vncproxy enabled :-) 2012-02-06 22:15:14
AVAILABILITYZONE | |- nova-compute enabled :-) 2012-02-06 22:15:07
AVAILABILITYZONE |- nova1
AVAILABILITYZONE | |- nova-compute enabled :-) 2012-02-06 22:15:08
however, euca-describe-images yields (with debug enabled)
root@nova:~# euca-describe-images --debug
2012-02-06 16:16:28,289 euca2ools [DEBUG]:Method: POST
2012-02-06 16:16:28,289 euca2ools [DEBUG]:Path: /services/Cloud/
2012-02-06 16:16:28,289 euca2ools [DEBUG]:Data:
2012-02-06 16:16:28,289 euca2ools [DEBUG]:Headers: {}
2012-02-06 16:16:28,290 euca2ools [DEBUG]:Host: 173.23.181.1:8773
2012-02-06 16:16:28,290 euca2ools [DEBUG]:establishing HTTP connection:
kwargs={}
2012-02-06 16:16:28,290 euca2ools [DEBUG]:using _calc_signature_2
2012-02-06 16:16:28,290 euca2ools [DEBUG]:query string:
AWSAccessKeyId=admin%3AadminAction=DescribeImagesSignatureMethod=HmacSHA256SignatureVersion=2Timestamp=2012-02-06T22%3A16%3A28ZVersion=2010-08-31
2012-02-06 16:16:28,290 euca2ools [DEBUG]:string_to_sign: POST
173.23.181.1:8773
/services/Cloud/
AWSAccessKeyId=admin%3AadminAction=DescribeImagesSignatureMethod=HmacSHA256SignatureVersion=2Timestamp=2012-02-06T22%3A16%3A28ZVersion=2010-08-31
2012-02-06 16:16:28,290 euca2ools [DEBUG]:len(b64)=44
2012-02-06 16:16:28,290 euca2ools [DEBUG]:base64 encoded digest:
vSajubq/uXVIsFyMiUjxViprJ1zYHPpIONPcW5cN5yI=
2012-02-06 16:16:28,290 euca2ools [DEBUG]:query_string:
AWSAccessKeyId=admin%3AadminAction=DescribeImagesSignatureMethod=HmacSHA256SignatureVersion=2Timestamp=2012-02-06T22%3A16%3A28ZVersion=2010-08-31
Signature: vSajubq/uXVIsFyMiUjxViprJ1zYHPpIONPcW5cN5yI=
send: 'POST /services/Cloud/ HTTP/1.1\r\nHost:
173.23.181.1:8773\r\nAccept-Encoding: identity\r\nContent-Length:
207\r\nContent-Type: application/x-www-form-urlencoded;
charset=UTF-8\r\nUser-Agent: Boto/2.0
Re: [Openstack] Remove Zones code - FFE
Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKenty jos...@pistoncloud.com mailto:jos...@pistoncloud.com, Vishvananda Ishaya vishvana...@gmail.com mailto:vishvana...@gmail.com Cc: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull the trigger. -S *From:* Joshua McKenty [jos...@pistoncloud.com mailto:jos...@pistoncloud.com] *Sent:* Wednesday, February 01, 2012 4:45 PM *To:* Vishvananda Ishaya *Cc:* Sandy Walsh; openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] Remove Zones code - FFE +1 to Vish's points. I know there are some folks coming online in the Folsom timeline that can help out with the new stuff, but this feels a bit like going backwards. -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has. On Wednesday, February 1, 2012 at 12:41 PM, Vishvananda Ishaya wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken? 1.b) if yes, is it fixable 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release? Vish On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote: As part of the new (and optional) Zones code coming down the pipe, part of this is to remove the old Zones implementation. More info in the merge prop: https://review.openstack.org/#change,3629 So, can I? can I? Huh? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] Update on Ubuntu automated testing and CI of Openstack
As promised for anyone who was interested when we announced to the last last week, here is a blog post James Page and I put together describing our Openstack testing efforts and infrastructure in greater detail: http://javacruft.wordpress.com/2012/02/08/automating-openstack-testing-on-ubuntu/ I'm quite pleased with the results of the testing over the last 2 weeks or so. We've already uncovered a number of bugs that we were able to help squash and continue to uncover subtle stuff we wouldn't have come across otherwise until after we've uploaded our weekly Essex/Precise snapshot into the archive. As a result, 'apt-get insatll $core_project' on Precise gets you something more stable than at any point during the Diablo/Oneiric cycle. In the short term, we'll be working to enable pre-commit multi-node smoke testing of the stable Diablo branch on Oneiric as well as deploying and enabling Swift so that we're utilizing all of the current Devstack exercises (we currently run all but swift). We're approaching the Ubuntu feature-freeze (Feb. 16th) and, as always, would greatly appreciate any help further testing and stabilizing Openstack on Ubuntu! Cheers, Adam ___ 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] LDAP support in Keystone Light/redux
I've made some strides in the KSL LDAP implementation. I've set up a github clone with the code pushed: https://github.com/admiyo/keystone/tree/ldap The code is ugly, as I'm in Just get it working mode. Cleanup will happend prior to any attempt to merge with the Redux branch. I've attempted to keep the same set of unit tests running as are used for the SQL backend. The one delta is Metadata, as I am not sure how (or even if) we want to reflect that in LDAP. I've made those three unit tests no-ops for LDAP. There are still more API calls to implement, (Tenant_Modify for example) and then I'll test out against a live Open LDAP instance. The one change I've made from the old config is that fields like URL no longer have ldap_ in front of them, so the config will look something like [ldap] url = ldap://localhost user = cn=Admin password = password backend_entities = ['Tenant', 'User', 'UserRoleAssociation', 'Role'] suffix ='cn=example,cn=com' Feedback requested. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
