Re: [Openstack-operators] [User-committee] [scientific-wg] possible time change for non-US fortnightly meeting

Same here :-) Thanks! Dario Vianello Cloud Bioinformatics Application Architect European Bioinformatics Institute (EMBL-EBI) Wellcome Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK Email: da...@ebi.ac.uk > On 28 Jun 2016, at 13:42, > wrote: > > 0900 would wor

Re: [Openstack-operators] Data-Migration Juno -> Mitaka

Hi Blair, thank you for your answere. The Tool Roland suggested was what we are looking for, we want to migrate the enduser data from one cloud to another. Your suggestion with the database transfer sounds also interessting but if i dump my Juno DB and import it into the Mitaka TestDB, would th

Re: [Openstack-operators] Data-Migration Juno -> Mitaka

Hi Roland, thank you, this is what i'm looking for, I will have a look and give it a try and give you feedback how it worked for us :-) Regards, Michael > Roland Chan hat am 29. Juni 2016 um 01:54 geschrieben: > > Hi Michael > > ​We built a tool called GUTS to migrate various assets b

[Openstack-operators] Heat is error with Conflicting value ethertype IPv4, what is wrong?

hi,everyone Heat is error when create cluster with AWS::EC2::SecurityGroup :openstack dataprocessing cluster create --json my_cluster_create_vmdk.json { "name": "my-cluster-vmdk-1", "plugin_name": "vanilla-vmdk", "hadoop_version": "2.7.1", "cluster_template_id" : "25183942-4093-468b-8d7a-

Re: [Openstack-operators] Data-Migration Juno -> Mitaka

Hi Roland - GUTS looks cool! But I took Michael's question to be more about control plane data than end-user instances etc...? Michael - If that's the case then you probably want to start with dumping your present Juno DBs, importing into your Mitaka test DB and then attempting the migrations to

Re: [Openstack-operators] Data-Migration Juno -> Mitaka

Hi Michael ​We built a tool called GUTS to migrate various assets between OpenStack deployment (and other things as well). You can check it out at ​ https://github.com/aptira/guts. It can migrate Instances, Volumes, Networks, Tenants, Users and Security Groups from one OpenStack to another. It's

[Openstack-operators] [Magnum] Want to know our users

Hi all, FYI. The Magnum team is collecting a list of Magnum users. If you are using Magnum, we would like to have your name and organization recorded in our wiki [1]. Please note that this is totally optional, but we hope you will let us know if you are our users. [1] https://wiki.openstack.or

[Openstack-operators] [telco][nfv] ops telecom/nfv working group meeting tomorrow

Hi All, Just a quick reminder that our bi-weekly meeting will occur tomorrow, Weds at 15:00 UTC in openstack-meeting-4 [1]. Feel free to add to the agenda [2]. :) Thanks and hope to see you there, Curtis. [1]: http://eavesdrop.openstack.org/#OpenStack_Operators_Telco_and_NFV_Working_Group [2]:

[Openstack-operators] [scientific][scientific-wg] Reminder: Scientific WG Meeting Tuesday 2100 UTC

Hi all - We have a Scientific WG IRC meeting later today at 2100 UTC on channel #openstack-meeting. The agenda is available here[1] and full IRC meeting details are here[2]. This week we’ll be looking at the HPC/Research track for the upcoming Barcelona summit, and a review of actions achieve

Re: [Openstack-operators] [openstack] [tools] OpenStack client in a Docker container

Gerard, Yup we would take it in Kolla. Prevents dirtying a system for CLI based operations. Regards -steve From: "Fox, Kevin M" mailto:kevin@pnnl.gov>> Date: Tuesday, June 28, 2016 at 4:41 AM To: Gerard Braad mailto:m...@gbraad.nl>>, "openst...@lists.openstack.org

Re: [Openstack-operators] [HA] RFC: user story including hypervisor reservation / host maintenance / storage AZs / event history (fwd)

Juvonen, Tomi (Nokia - FI/Espoo) wrote: > Thank you very much from the interest. Need to look over other > discussion and perhaps have a session in Barcelona to look the > way forward after change in Nova. Indeed, sounds good! > > -Original Message- > > From: Adam Spiers [mailto:aspi...@

Re: [Openstack-operators] [neutron] Cross region traffic and Neutron

Hola Sergio, This is a network problem, I think you can solve it connecting both regions via site to site VPN (L2 or L3) This is a reference post for AWS but I hope this may help you: http://blog.rackspace.com/how-to-build-fault-tolerant-cross-region-aws-virtual-private-cloud-communication-p

Re: [Openstack-operators] [openstack] [tools] OpenStack client in a Docker container

Looks awesome, it has to be really useful. Thanks! On Tue, Jun 28, 2016 at 2:41 PM, Fox, Kevin M wrote: > Cool. Maybe this could be contributed to the Kolla project? > > Thanks, > Kevin > > -- > *From:* Gerard Braad > *Sent:* Monday, June 27, 2016 8:58:18 PM > *To:*

Re: [Openstack-operators] [User-committee] [scientific-wg] possible time change for non-US fortnightly meeting

0900 would work better for me :) Thanks Alexander From: Blair Bethwaite [mailto:blair.bethwa...@gmail.com] Sent: 28 June 2016 12:37 To: user-committee ; openstack-oper. Subject: [User-committee] [scientific-wg] possible time change for non-US fortnightly meeting Hi all, Currently th

Re: [Openstack-operators] [openstack] [tools] OpenStack client in a Docker container

Cool. Maybe this could be contributed to the Kolla project? Thanks, Kevin From: Gerard Braad Sent: Monday, June 27, 2016 8:58:18 PM To: openst...@lists.openstack.org; openstack-operators Subject: [Openstack-operators] [openstack] [tools] OpenStack client in a Dock

[Openstack-operators] [scientific-wg] possible time change for non-US fortnightly meeting

Hi all, Currently the scientific-wg is meeting weekly on irc with alternating times week to week - 2100 UTC Tues this week and 0700 UTC Weds next week. The basic idea being to have both US and non-US friendly times. The former time is pretty well attended but the latter is somewhat hit and miss s

[Openstack-operators] how to deel with 'HEAT-E99001 Service nova is not available for resource type OS::Nova::FloatingIP' error message

hi, when i create cluster with cmd: openstack dataprocessing cluster create --json my_cluster_create_vmdk.json Cluster status change to Error after: Cluster status has been changed. New status=Spawning [lv@localhost ~(sahara)]$ openstack dataprocessing cluster list +-

[Openstack-operators] same availability zone for cinder and nova with cross_az_attach=False

Dear operators, do you have experience of using nova's option cross_az_attach with False value? Current behavior is that if cross_az_attach option is set to false, nova should ensure cinder and nova AZ's are matching and create both volume and instance in the same availability zone. So far, so go