[Openstack-operators] glance-replicator

[Abel Lopez]

I'm trying to use glance-replicator, but it seems to be non-functional.

glance-replicator help compare
compare the contents of fromserver with those of toserver.

fromserver:port: the location of the master glance instance.
toserver:port:   the location of the slave glance instance.

Ok,
glance-replicator compare glance1:9292 glance2:9292
glance-replicator: error: unrecognized arguments: glance2:9292

Anyone have tips?


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] glance-replicator

[Sanjeev.Jaiswal]

Why don't you use GLINT tool from CERN? This works well in our environment and 
we are able to replicate images across Clouds.

Regards,
Sanjeev Jaiswal
VP - Cloud Operations 
Reliance Jio Infocomm Limited
"Confidentiality Warning: This message and any attachments are intended only 
for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. 
you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other 
use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the 
sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure 
no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from 
the use of this email or attachment."


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] glance-replicator

[Edgar Magana]

Hi,

Which version of Glance are you using? I am not able to reproduce your error 
message:

glance-replicator compare glance1:9292 glance2:12
[Errno -2] Name or service not known
Traceback (most recent call last):


Expected error but in your case it feels like a basic arguments construction 
issue in the code.

BTW. I tested with a old version of glance:

openstack-glance.noarch  2014.1.3

Edgar





On 2/16/16, 12:24 AM, "Abel Lopez"  wrote:

>I'm trying to use glance-replicator, but it seems to be non-functional.
>
>glance-replicator help compare
>compare the contents of fromserver with those of toserver.
>
>fromserver:port: the location of the master glance instance.
>toserver:port:   the location of the slave glance instance.
>
>Ok,
>glance-replicator compare glance1:9292 glance2:9292
>glance-replicator: error: unrecognized arguments: glance2:9292
>
>Anyone have tips?
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] OpenStack Contributor Awards

[Tom Fifield]

Hi all,

I'd like to introduce a new round of community awards handed out by the 
Foundation, to be presented at the feedback session of the summit.


Nothing flashy or starchy - the idea is that these are to be a little 
informal, quirky ... but still recognising the extremely valuable work 
that we all do to make OpenStack excel.


There's so many different areas worthy of celebration, but we think that 
there's a few main chunks of the community that need a little love,


* Those who might not be aware that they are valued, particularly new 
contributors

* Those who are the active glue that binds the community together
* Those who share their hard-earned knowledge with others and mentor
* Those who challenge assumptions, and make us think

Since it's first time (recently, at least), rather than starting with a 
defined set of awards, we'd like to have submissions of names in those 
broad categories. Then we'll have a little bit of fun on the back-end 
and try to come up with something that isn't just your standard set of 
award titles, and iterate to success ;)


The submission form is here, so please submit anyone who you think is 
deserving of an award!




https://docs.google.com/forms/d/1HP1jAobT-s4hlqZpmxoGIGTxZmY6lCWolS3zOq8miDk/viewform



in the meantime, let's use this thread to discuss the fun part: goodies. 
What do you think we should lavish award winners with? Soft toys? 
Perpetual trophies? baseball caps ?



Regards,


Tom, on behalf of the Foundation team



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [cinder] About how to make the vm use volume with libiscsi

[Xiao Ma (xima2)]

Hi, All

I want to make the qemu communicate with iscsi target using libiscsi directly, 
and I
followed https://review.openstack.org/#/c/135854/ to add
'volume_drivers = iscsi=nova.virt.libvirt.volume.LibvirtNetVolumeDriver’ in 
nova.conf
 and then restarted nova services and cinder services, but still the volume 
configuration of vm is as bellow:


  
  
  
  076bb429-67fd-4c0c-9ddf-0dc7621a975a
  



I use centos7 and Liberty version of OpenStack.
Could anybody tell me how can I achieve it?


Thanks.



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Openstack][Neutron][Ceilometer]

[Rubab Syed]

Hi there,

Is anyone currently using neutron-metering-agent at L3 routers level[1]
successfully?

[1] https://wiki.openstack.org/wiki/Neutron/Metering/Bandwidth

Thanks,
Rubab
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] VM HA support in trunk

[Bajin, Joseph]

I would have to agree with Matt.  The ability for any sort of handling of 
failures either reside within the application or tools around the application 
to make it work.  Having the infrastructure handle the failures, I believe, is 
a slippery slope that is starting to appear more and more. 

I do fear that many people/organizations are starting to look at the cloud as a 
“low cost” or “free” VMWare solution.  They want the same enterprise based 
availability and support that they get with a vendor paid solution without the 
cost of the vendor paid solution.   I have started to see and hear more about 
how vendors are adding “enterprise” solutions to OpenStack.  This includes High 
Availability features that rely on the infrastructure to manage instead of the 
application.  I fear the direction of all the projects will begin migrating 
this way as more vendors get involve and want to figure out business models 
that they can use around “enterprise” feature-sets. 

—Joe
  


From:  Matt Fischer 
Date:  Monday, February 15, 2016 at 10:59 AM
To:  Toshikazu Ichikawa 
Cc:  "openstack-operators@lists.openstack.org" 

Subject:  Re: [Openstack-operators] [nova] VM HA support in trunk

I believe that either have your customers design their apps to handle failures 
or have tools that are reactive to failures.

Unfortunately like many other private cloud operators we deal a lot with legacy 
applications that aren't scaled horizontally or fault tolerant and so we've 
built tooling to handle customer notifications (reactive). When we lose a 
compute host we generate a notice to customers and then work on evacuating 
their instances. For the evac portion nova host-evacuate or host-evacuate-live 
work fairly well, although we rarely get a functioning floating-IP after 
host-evacuate without other work.

Getting adoption of heat or other automation tooling to educate customers is a 
long process, especially when they're used to VMware where I think they get the 
VM HA stuff for "free".


On Mon, Feb 15, 2016 at 8:25 AM, Toshikazu Ichikawa 
 wrote:
Hi Affan,

 

 

I don’t think any components in Liberty provide HA VM support directly.

 

However, many works are published and open-sourced, here.

https://etherpad.openstack.org/p/automatic-evacuation

You may find ideas and solutions.

 

And, the discussion on this topic is on-going at HA meeting.

https://wiki.openstack.org/wiki/Meetings/HATeamMeeting

 

thanks,

Kazu

 

From: Affan Syed [mailto:affan.syed@gmail.com] 
Sent: Monday, February 15, 2016 12:51 PM
To: openstack-operators@lists.openstack.org
Subject: [Openstack-operators] [nova] VM HA support in trunk

 

reposting with the correct tag, hopefully. Would really appreciate some 
pointers. 

-- Forwarded message -
From: Affan Syed 
Date: Sat, 13 Feb 2016 at 15:13
Subject: [nova] VM HA support in trunk
To: 

 

Hi all,

I have been trying to understand if we currently have some VM HA support as 
part of Liberty?

 

To be precise, how are host being down due to power failure handled, 
specifically in terms of migrating the VMs but possibly even their networking 
configs (tunnels etc). 

 

The VM migration like XEN-HA or KVM cluster seem to require 1+1 HA, I have read 
a few places about celiometer+heat templates to launch VMs for an N+1 backup 
scenario, but these all seem like one-off setups. 

 

 

This issue seems to be very much important for legacy enterprises to move their 
"pets" --- not sure if we can simply wish away that mindset!

 

Affan

 

 

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Openstack][Neutron][Ceilometer]

[gordon chung]

On 16/02/2016 8:11 AM, Rubab Syed wrote:
> Hi there,
>
> Is anyone currently using neutron-metering-agent at L3 routers level[1]
> successfully?
>
> [1] https://wiki.openstack.org/wiki/Neutron/Metering/Bandwidth
>

i'm just going to list out some questions, they correspond to data flow:

- do you have the metering agent enabled[1]? are there any errors?
- do you have notification_driver option set in neutron.conf? (should be 
notification_driver = messagingv2)
- do you have any backlogged messages in message queue? specifically 
notifications.info queue.
- do you have ceilometer notification agent enabled? are there any errors?

[1] 
http://docs.openstack.org/admin-guide-cloud/networking_config-agents.html#configure-metering-agent

cheers,
-- 
gord

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] How are consumers/operators new to openstack supposed to know about upper-constraints?

[Matt Riedemann]

We have a team just upgrading to Liberty and they are having problems. 
While running down their list of packages they are using, I noticed they 
have os-brick 0.8.0 which is the latest version (from mitaka).


However, os-brick in stable/liberty upper-constraints is at 0.6.0 [1].

So while I don't think their immediate problems are due to using an 
untested version of os-brick on stable/liberty, they are obviously just 
picking up the latest versions of dependencies because they aren't 
capped in requirements.  That could eventually bite them because there
are things that don't work together in liberty depending on what 
versions you have [2].


My main question is, how are we expecting consumers/deployers of 
openstack to know about the upper-constraints file?  Where is that 
advertised in the manuals?


There is nothing in the Liberty release notes [3].

I'm sure there is probably something in the openstack/requirements repo 
devref, but I wouldn't expect a deployer to know that repo exists let 
alone to go off and read it's docs and understand how it applies to them 
(a lot of openstack developers probably don't know about the reqs repo 
or what it does).


Does the operator community have any tips or know something that I 
don't?  I think ops people that have been around awhile are just aware 
because it's been coming for a few releases now so they are aware of the 
magical unicorn and have sought out info on it, but what about new 
deployments?


[1] 
https://github.com/openstack/requirements/blob/0e8a4136b4e9e91293d46b99879c966e3bddd9bd/upper-constraints.txt#L181

[2] https://bugs.launchpad.net/oslo.service/+bug/1529594
[3] https://wiki.openstack.org/wiki/ReleaseNotes/Liberty

--

Thanks,

Matt Riedemann


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How are consumers/operators new to openstack supposed to know about upper-constraints?

[Ian Cordasco]

 

-Original Message-
From: Matt Riedemann 
Reply: Matt Riedemann 
Date: February 16, 2016 at 09:30:49
To: OpenStack Development Mailing List (not for usage questions) 
, openstack-operators@lists.openstack.org 

Subject:  [Openstack-operators] How are consumers/operators new to openstack 
supposed to know about upper-constraints?

> We have a team just upgrading to Liberty and they are having problems.
> While running down their list of packages they are using, I noticed they
> have os-brick 0.8.0 which is the latest version (from mitaka).
>  
> However, os-brick in stable/liberty upper-constraints is at 0.6.0 [1].
>  
> So while I don't think their immediate problems are due to using an
> untested version of os-brick on stable/liberty, they are obviously just
> picking up the latest versions of dependencies because they aren't
> capped in requirements. That could eventually bite them because there
> are things that don't work together in liberty depending on what
> versions you have [2].
>  
> My main question is, how are we expecting consumers/deployers of
> openstack to know about the upper-constraints file? Where is that
> advertised in the manuals?
>  
> There is nothing in the Liberty release notes [3].
>  
> I'm sure there is probably something in the openstack/requirements repo
> devref, but I wouldn't expect a deployer to know that repo exists let
> alone to go off and read it's docs and understand how it applies to them
> (a lot of openstack developers probably don't know about the reqs repo
> or what it does).
>  
> Does the operator community have any tips or know something that I
> don't? I think ops people that have been around awhile are just aware
> because it's been coming for a few releases now so they are aware of the
> magical unicorn and have sought out info on it, but what about new
> deployments?
>  
> [1]
> https://github.com/openstack/requirements/blob/0e8a4136b4e9e91293d46b99879c966e3bddd9bd/upper-constraints.txt#L181
>   
> [2] https://bugs.launchpad.net/oslo.service/+bug/1529594
> [3] https://wiki.openstack.org/wiki/ReleaseNotes/Liberty

This is actually a good question. I think some assumptions were made about how 
people are deploying OpenStack. I think those assumptions are along the lines 
of:

- Operators are deploying with downstream packages (from Ubuntu, Red Hat, etc.)
- Operators are using something like the Chef Cookbooks, Puppet Modules, or the 
Ansible Playbooks that ideally handle all of this for them.

I know OpenStack Ansible takes upper-constraints into consideration when it's 
building wheel repositories for dependencies. I would guess that the other 
deployment projects do something similar or also rest upon the usage of 
downstream packages. I think we (the developers) tend to think that anyone not 
using downstream packages is doing it wrong since they handle dependency 
management for us (as presented to the end user).

I'm not sure what the right solution will be because I would be surprised if 
some more explicit form of upper-constraints present in requirements of each 
project would be argued against as too much work/specificity.

I also think this clearly demonstrates why upper caps (although painful) are at 
least informational even when we have upper-constraints protecting the gates.

--  
Ian Cordasco


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Neutron][DVR] point of encapsulation/locating routing tables

[Adam Lawson]

Hi everyone:

Got a quick question for those of you with some knowledge of OVS and
namespaces within the context of DVR.

I'm trying to document exactly where namespaces are defined and where
encapsulation occurs if using (for instance) VxLAN/GRE tunnels.

Is there a quick and dirty slideshare or someone able to explain this quick
and dirty?

The question came up today is if we use tunnels, where does encapsulation
occur and where are the tables maintained and what data specifically sits
in each of those tables.

Is this an easy question to answer?

//adam

*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Neutron][DVR] point of encapsulation/locating routing tables

[Matt Kassawara]

Did you look at the DVR scenario in the networking guide [1]? DVR and other
architectures that use OVS build tunnels between br-tun bridges.

[1] http://docs.openstack.org/liberty/networking-guide/scenario-dvr-ovs.html

On Tue, Feb 16, 2016 at 12:47 PM, Adam Lawson  wrote:

> Hi everyone:
>
> Got a quick question for those of you with some knowledge of OVS and
> namespaces within the context of DVR.
>
> I'm trying to document exactly where namespaces are defined and where
> encapsulation occurs if using (for instance) VxLAN/GRE tunnels.
>
> Is there a quick and dirty slideshare or someone able to explain this
> quick and dirty?
>
> The question came up today is if we use tunnels, where does encapsulation
> occur and where are the tables maintained and what data specifically sits
> in each of those tables.
>
> Is this an easy question to answer?
>
> //adam
>
> *Adam Lawson*
>
> AQORN, Inc.
> 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW ext. 101
> International: +1 302-387-4660
> Direct: +1 916-246-2072
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] OpenStack Liberty automation script release.

[Hieu LE]

Thank JJ,

I have made a change in tools-contrib repo, please review and feedback.

Hieu LE.

On Sat, Dec 12, 2015 at 1:56 AM, JJ Asghar  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> > On Fri, Dec 11, 2015 at 8:19 AM, Bajin, Joseph  > > wrote:
> >
> > These would make great additions to the OpenStack Operators github
> > repos that we have setup.  It would probably fit under the
> > http://github.com/OpenStack/osops-tools-generic repo.
>
> Just gonna jump in and say it should be tools-contrib[1] to start off
> with. We are getting the bashpep8 checks in the tools-generic as i type
> this email.
>
> You'll want to check out the repo, then use the normal review[2] process
> to get the it up on review.openstack.org
>
>
> [1]: https://github.com/openstack/osops-tools-contrib
> [2]: http://docs.openstack.org/infra/manual/developers.html
>
> - --
> Best Regards,
> JJ Asghar
> c: 512.619.0722 t: @jjasghar irc: j^2
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2
> Comment: GPGTools - https://gpgtools.org
>
> iQIcBAEBCgAGBQJWaxxYAAoJEDZbxzMH0+jTvf4P/A2MjkDJkhT8gc8/QkK5ZEFP
> mX4S4GAiU9OaTrh0/JX6lCAdajL/dAuLAZ+AV36bEOmfjOXLZuiSvsXq48N9pTUR
> ZBIpkvy7pTWtXA1JVRvfuYgmKYTpN5CRvXnrjJx5BzM3UbkEomSccxTcdAuUbE8H
> sjIq1k8Asnk2V1Q57WYeNacKAFLSTsSoGf7ZaBK2MkSc7lJDE5gJpre/S3IuZWP9
> CxV8N4p8pBBcySq2bwO7xwq8E8Sd6tVJevgqZHczzYHkks7/NEHQqV93pcc1010b
> 5hzNSzyG+Eb+dZwDsRHoVFprPQiDOj7cyqYUPRbUpHZMNpv3Yc5727S+9Dq3/tZ4
> FouVX08orr4QkMGKhVMbkRJhMaobB9mag89zYaoENsPAnQsxBUezvKMHuVIX5pYB
> p+DbEmjaBi8NGZPPK8eWplBDePXfEuRn8oz61aJJ+UBhI1PLYtlEQLYxa2uKIvAX
> QAIhyGHzOBNtyRC5LKBWwsw57QkC+tTyFx+Y1gNpM2Al0luNAd+D0/gmgfCPZoxh
> aAelcyBKgfYpB1p6r+Gi0QTWVdUC8PCT3ib5iuvtl8XrVtYE/GglVF7JZ4tEmG+1
> VhB7j7n89AqGx21yU3aCi7HnWzSvhQVlLYkPosyzZWlvIXm8fWnM+cOSMAbjcKyf
> uooJ0yE1K9CFgV7hKHLm
> =AhYQ
> -END PGP SIGNATURE-
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS/CM/IT/M/MU d-@? s+(++):+(++) !a C()$ ULC(++)$ P L++(+++)$ E
!W N* o+ K w O- M V- PS+ PE++ Y+ PGP+ t 5 X R tv+ b+(++)>+++ DI- D+ G
e++(+++) h-- r(++)>+++ y-
--END GEEK CODE BLOCK--
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] vmware nsx 6

[Ignazio Cassano]

Hi all,
I would like to know if someone have configured openstack neutron with
vmware
nsx 6. I found old documentation about it.
Regards
Ignazio
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators