Re: [openstack-dev] what code in cinder volume driver supports volume migration between two backends of same type but having different volume types? [cinder]

[Avishay Traeger]

Nikesh,
The case you are trying is supposed to fail.  You have a volume of type
dothill_realstor1 which is defined to say "this volume must be on backend
DotHill_RealStor1".  This is a requirement that you defined for that
volume.  Now you want to migrate it to realstor2, which is a violation of
the requirement that you specified.  To migrate it, you should change the
volume type (retype), which changes the requirement.

Thanks,
Avishay

On Sat, Feb 28, 2015 at 11:02 AM, Nikesh Kumar Mahalka <
nikeshmaha...@vedams.com> wrote:

> I tried below link  for volume migration on my driver and also similar
> efforts for LVM.
> Even whatever documents available in openstack for
> volume-migration,each one showing volume migration of a volume having
> volume type None
>
> I added host assisted volume migration function in my cinder driver.
> When i am trying volume migration on a volume without volume type,then
> my volume migration function is getting called and i  am able to do
> volume migration.
>
> But when i am trying volume migration on a volume having volume
> type,then my volume migration function is not getting called.
>
>
> http://paste.openstack.org/show/183392/
> http://paste.openstack.org/show/183405/
>
>
>
> On Tue, Jan 20, 2015 at 12:31 AM, Nikesh Kumar Mahalka
>  wrote:
> > do cinder retype (v2) works for lvm?
> > How to use cinder retype?
> >
> > I tried for volume migration from one volume-type LVM backend to
> > another volume-type LVM backend.But its failed.
> > How can i acheive this?
> >
> > Similarly i am writing a cinder volume driver for my array and want to
> > migrate volume from one volume type to another volume type for my
> > array backends.
> > so want to know how can i achieve this in cinder driver?
> >
> >
> >
> > Regards
> > Nikesh
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
*Avishay Traeger*
*Storage R&D*

Mobile: +972 54 447 1475
E-mail: avis...@stratoscale.com



Web  | Blog 
 | Twitter  | Google+

 | Linkedin 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Heat: autoscaling across availability zones

[Mike Spreitzer]

> From: Weidong Shao 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 02/28/2015 02:12 PM
> Subject: [openstack-dev] Heat: autoscaling across availability zones
> 
> From the  heat template reference doc, it seems that auto-scaling 
> across AZs is not supported.   Is there any blueprint or plan in 
> adding this support?

Yes.  Here are some ways you can find that work:

https://blueprints.launchpad.net/openstack/?searchtext=availabilityzone

https://review.openstack.org/#/q/message:availability+message:zone,n,z 
includes some relevant answers; I have not yet figured out how to narrow 
the query to match only items in the heat and heat-specs projects.

Subscribe to notifications from Gerrit about activity in the Heat project, 
watch the email subject lines as they whizz by.

Regards,
Mike__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

[Ramakrishnan G]

> You may not realize you do a disservice to those reading this post and
> those reviewing future patches if you set unreasonable expectations.

> Telling others that they can expect a patch merged in the same day is
> not reasonable, even if that has been your experience. While we do our
> best to keep current, we all are very busy and requests for repos are
> increasing. If folks want a repo they can submit a patch to create one,
> here is a good guide:
> http://docs.openstack.org/infra/manual/creators.html and it will be
> reviewed along with all other patches to project-config.

Anita,

Thanks for correcting me.  Yeah, I just quoted *my experience with
openstack-infra *blindly.  Sorry for that.

Rather I also wanted to point out to our folks, things in infra are so
automated that putting an openstack-related module into stackforge has been
become fully automatic and easy *(easy for the requestor, of course keeping
in mind that the request has to be correct and get's reviewed and approved
by  infra guys)*.  Kudos to you guys :-)

Regards,
Ramesh


On Sun, Mar 1, 2015 at 12:49 AM, Anita Kuno  wrote:

> On 02/28/2015 01:28 AM, Ramakrishnan G wrote:
> > Hello All,
> >
> > This is about adding vendor drivers in Ironic.
> >
> > In Kilo, we have many vendor drivers getting added in Ironic which is a
> > very good thing.  But something I noticed is that, most of these reviews
> > have lots of hardware-specific code in them.  This is something most of
> the
> > other Ironic folks cannot understand unless they go and read the hardware
> > manuals of the vendor hardware about what is being done.  Otherwise we
> just
> > need to blindly mark the file as reviewed.
> >
> > Now let me pitch in with our story about this.  We added a vendor driver
> > for HP Proliant hardware (the *ilo drivers in Ironic).  Initially we
> > proposed this same thing in Ironic that we will add all the hardware
> > specific code in Ironic itself under the directory drivers/modules/ilo.
> > But few of the Ironic folks didn't agree on this (Devananda especially
> who
> > is from my company :)). So we created a new module proliantutils, hosted
> in
> > our own github and recently moved it to stackforge.  We gave a limited
> set
> > of APIs for Ironic to use - like get_host_power_status(),
> set_host_power(),
> > get_one_time_boot(), set_one_time_boot(), etc. (Entire list is here
> >
> https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/operations.py
> > ).
> >
> > We have only seen benefits in doing it.  Let me bring in some examples:
> >
> > 1) We tried to add support for some lower version of servers.  We could
> do
> > this without making any changes in Ironic (Review in proliantutils
> > https://review.openstack.org/#/c/153945/)
> > 2) We are adding support for newer models of servers (earlier we use to
> > talk to servers in protocol called RIBCL, newer servers we will use a
> > protocol called RIS) - We could do this with just 14 lines of actual code
> > change in Ironic (this was needed mainly because we didn't think we will
> > have to use a new protocol itself when we started) -
> > https://review.openstack.org/#/c/154403/
> >
> > Now talking about the advantages of putting hardware-specific code in
> > Ironic:
> >
> > *1) It's reviewed by Openstack community and tested:*
> > No. I doubt if I throw in 600 lines of new iLO specific code that is
> here (
> >
> https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/ris.py
> )
> > for Ironic folks, they will hardly take a look at it.  And regarding
> > testing, it's not tested in the gate unless we have a 3rd party CI for
> it.
> >  [We (iLO drivers) also don't have 3rd party CI right now, but we are
> > working on it.]
> >
> > *2) Everything gets packaged into distributions automatically:*
> > Now the hardware-specific code that we add in Ironic under
> > drivers/modules// will get packaged into distributions, but this
> > code in turn will have dependencies  which needs to be installed manually
> > by the operator (I assume vendor specific dependencies are not considered
> > by Linux distributions while packaging Openstack Ironic). Anyone
> installing
> > Ironic and wanting to manage my company's servers will again need to
> > install these dependencies manually.  Why not install the wrapper if
> there
> > is one too.
> >
> > I assume we only get these advantages by moving all of hardware-specific
> > code to a wrapper module in stackforge and just exposing some APIs for
> > Ironic to use:
> > * Ironic code would be much cleaner and easier to maintain
> > * Any changes related to your hardware - support for newer hardware, bug
> > fixes in particular models of hardware, would be very easy. You don't
> need
> > to change Ironic code for that. You could just fix the bug in your
> module,
> > release a new version and ask your users to install a newer version of
> the
> > module.
> > * python-fooclient could be used outside Ironic to easily manage 

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

[Anita Kuno]

On 02/28/2015 01:28 AM, Ramakrishnan G wrote:
> Hello All,
> 
> This is about adding vendor drivers in Ironic.
> 
> In Kilo, we have many vendor drivers getting added in Ironic which is a
> very good thing.  But something I noticed is that, most of these reviews
> have lots of hardware-specific code in them.  This is something most of the
> other Ironic folks cannot understand unless they go and read the hardware
> manuals of the vendor hardware about what is being done.  Otherwise we just
> need to blindly mark the file as reviewed.
> 
> Now let me pitch in with our story about this.  We added a vendor driver
> for HP Proliant hardware (the *ilo drivers in Ironic).  Initially we
> proposed this same thing in Ironic that we will add all the hardware
> specific code in Ironic itself under the directory drivers/modules/ilo.
> But few of the Ironic folks didn't agree on this (Devananda especially who
> is from my company :)). So we created a new module proliantutils, hosted in
> our own github and recently moved it to stackforge.  We gave a limited set
> of APIs for Ironic to use - like get_host_power_status(), set_host_power(),
> get_one_time_boot(), set_one_time_boot(), etc. (Entire list is here
> https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/operations.py
> ).
> 
> We have only seen benefits in doing it.  Let me bring in some examples:
> 
> 1) We tried to add support for some lower version of servers.  We could do
> this without making any changes in Ironic (Review in proliantutils
> https://review.openstack.org/#/c/153945/)
> 2) We are adding support for newer models of servers (earlier we use to
> talk to servers in protocol called RIBCL, newer servers we will use a
> protocol called RIS) - We could do this with just 14 lines of actual code
> change in Ironic (this was needed mainly because we didn't think we will
> have to use a new protocol itself when we started) -
> https://review.openstack.org/#/c/154403/
> 
> Now talking about the advantages of putting hardware-specific code in
> Ironic:
> 
> *1) It's reviewed by Openstack community and tested:*
> No. I doubt if I throw in 600 lines of new iLO specific code that is here (
> https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/ris.py)
> for Ironic folks, they will hardly take a look at it.  And regarding
> testing, it's not tested in the gate unless we have a 3rd party CI for it.
>  [We (iLO drivers) also don't have 3rd party CI right now, but we are
> working on it.]
> 
> *2) Everything gets packaged into distributions automatically:*
> Now the hardware-specific code that we add in Ironic under
> drivers/modules// will get packaged into distributions, but this
> code in turn will have dependencies  which needs to be installed manually
> by the operator (I assume vendor specific dependencies are not considered
> by Linux distributions while packaging Openstack Ironic). Anyone installing
> Ironic and wanting to manage my company's servers will again need to
> install these dependencies manually.  Why not install the wrapper if there
> is one too.
> 
> I assume we only get these advantages by moving all of hardware-specific
> code to a wrapper module in stackforge and just exposing some APIs for
> Ironic to use:
> * Ironic code would be much cleaner and easier to maintain
> * Any changes related to your hardware - support for newer hardware, bug
> fixes in particular models of hardware, would be very easy. You don't need
> to change Ironic code for that. You could just fix the bug in your module,
> release a new version and ask your users to install a newer version of the
> module.
> * python-fooclient could be used outside Ironic to easily manage foo
> servers.
> * Openstack CI for free if you are in stackforge - unit tests, flake tests,
> doc generation, merge, pypi release everything handled automatically.
> 
> I don't see any disadvantages.
> 
> Now regarding the time taken to do this, if you have all the code ready now
> in Ironic (which assume you will already have), perhaps it will take a day
> to do this - half a day for putting into a separate module in python/github
> and half a day for stackforge. The request to add stackforge should get
> approved in the same day (if everything is all-right).
You may not realize you do a disservice to those reading this post and
those reviewing future patches if you set unreasonable expectations.

Telling others that they can expect a patch merged in the same day is
not reasonable, even if that has been your experience. While we do our
best to keep current, we all are very busy and requests for repos are
increasing. If folks want a repo they can submit a patch to create one,
here is a good guide:
http://docs.openstack.org/infra/manual/creators.html and it will be
reviewed along with all other patches to project-config.

Thank you,
Anita.
> 
> Let me know all of your thoughts on this.  If we agree, I feel we should
> have some documentation on it in our Ironi

[openstack-dev] Heat: autoscaling across availability zones

[Weidong Shao]

>From the  heat template reference doc, it seems that auto-scaling across
AZs is not supported.   Is there any blueprint or plan in adding this
support?

Thanks,
Wei
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Policy][Group-based-policy] Bug squashing day

[Sumit Naiksatam]

Hi, Per our discussion in the last weekly IRC meeting, we will have
the bug squashing day for GBP on Tuesday, March 3rd. We will
coordinate activities over the #openstack-gbp channel. Please join and
participate.

Thanks,
~Sumit.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

[Clint Byrum]

I'm not sure I understand your statement Gary. If Ironic defines
what is effectively a plugin API, and the vendor drivers are careful
to utilize that API properly, the two sets of code can be released
entirely independent of one another. This is how modules work in the
kernel, X.org drivers work, and etc. etc. Of course, vendors could be
irresponsible and break compatibility with older releases of Ironic,
but that is not in their best interest, so I don't see why anybody would
need to tightly couple.

As far as where generic code goes, that seems obvious: it all has to go
into Ironic and be hidden behind the plugin API.

Excerpts from Gary Kotton's message of 2015-02-28 09:28:55 -0800:
> Hi,
> There are pros and cons for what you have mentioned. My concern, and I 
> mentioned them with the neutron driver decomposition, is that we are are 
> loosing the community inputs and contributions. Yes, one can certainly move 
> faster and freer (which is a huge pain point in the community). How are 
> generic code changes percolated to your repo? Do you have an automatic CI 
> that detects this? Please note that when itonic release you will need to 
> release your repo so that the relationship is 1:1...
> Thanks
> Gary
> 
> From: Ramakrishnan G 
> mailto:rameshg87.openst...@gmail.com>>
> Reply-To: OpenStack List 
> mailto:openstack-dev@lists.openstack.org>>
> Date: Saturday, February 28, 2015 at 8:28 AM
> To: OpenStack List 
> mailto:openstack-dev@lists.openstack.org>>
> Subject: [openstack-dev] [Ironic] Adding vendor drivers in Ironic
> 
> 
> Hello All,
> 
> This is about adding vendor drivers in Ironic.
> 
> In Kilo, we have many vendor drivers getting added in Ironic which is a very 
> good thing.  But something I noticed is that, most of these reviews have lots 
> of hardware-specific code in them.  This is something most of the other 
> Ironic folks cannot understand unless they go and read the hardware manuals 
> of the vendor hardware about what is being done.  Otherwise we just need to 
> blindly mark the file as reviewed.
> 
> Now let me pitch in with our story about this.  We added a vendor driver for 
> HP Proliant hardware (the *ilo drivers in Ironic).  Initially we proposed 
> this same thing in Ironic that we will add all the hardware specific code in 
> Ironic itself under the directory drivers/modules/ilo.  But few of the Ironic 
> folks didn't agree on this (Devananda especially who is from my company :)). 
> So we created a new module proliantutils, hosted in our own github and 
> recently moved it to stackforge.  We gave a limited set of APIs for Ironic to 
> use - like get_host_power_status(), set_host_power(), get_one_time_boot(), 
> set_one_time_boot(), etc. (Entire list is here 
> https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/operations.py).
> 
> We have only seen benefits in doing it.  Let me bring in some examples:
> 
> 1) We tried to add support for some lower version of servers.  We could do 
> this without making any changes in Ironic (Review in proliantutils 
> https://review.openstack.org/#/c/153945/)
> 2) We are adding support for newer models of servers (earlier we use to talk 
> to servers in protocol called RIBCL, newer servers we will use a protocol 
> called RIS) - We could do this with just 14 lines of actual code change in 
> Ironic (this was needed mainly because we didn't think we will have to use a 
> new protocol itself when we started) - 
> https://review.openstack.org/#/c/154403/
> 
> Now talking about the advantages of putting hardware-specific code in Ironic:
> 
> 1) It's reviewed by Openstack community and tested:
> No. I doubt if I throw in 600 lines of new iLO specific code that is here 
> (https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/ris.py)
>  for Ironic folks, they will hardly take a look at it.  And regarding 
> testing, it's not tested in the gate unless we have a 3rd party CI for it.  
> [We (iLO drivers) also don't have 3rd party CI right now, but we are working 
> on it.]
> 
> 2) Everything gets packaged into distributions automatically:
> Now the hardware-specific code that we add in Ironic under 
> drivers/modules// will get packaged into distributions, but this code 
> in turn will have dependencies  which needs to be installed manually by the 
> operator (I 

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

[Gary Kotton]

Hi,
There are pros and cons for what you have mentioned. My concern, and I 
mentioned them with the neutron driver decomposition, is that we are are 
loosing the community inputs and contributions. Yes, one can certainly move 
faster and freer (which is a huge pain point in the community). How are generic 
code changes percolated to your repo? Do you have an automatic CI that detects 
this? Please note that when itonic release you will need to release your repo 
so that the relationship is 1:1...
Thanks
Gary

From: Ramakrishnan G 
mailto:rameshg87.openst...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Saturday, February 28, 2015 at 8:28 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Ironic] Adding vendor drivers in Ironic


Hello All,

This is about adding vendor drivers in Ironic.

In Kilo, we have many vendor drivers getting added in Ironic which is a very 
good thing.  But something I noticed is that, most of these reviews have lots 
of hardware-specific code in them.  This is something most of the other Ironic 
folks cannot understand unless they go and read the hardware manuals of the 
vendor hardware about what is being done.  Otherwise we just need to blindly 
mark the file as reviewed.

Now let me pitch in with our story about this.  We added a vendor driver for HP 
Proliant hardware (the *ilo drivers in Ironic).  Initially we proposed this 
same thing in Ironic that we will add all the hardware specific code in Ironic 
itself under the directory drivers/modules/ilo.  But few of the Ironic folks 
didn't agree on this (Devananda especially who is from my company :)). So we 
created a new module proliantutils, hosted in our own github and recently moved 
it to stackforge.  We gave a limited set of APIs for Ironic to use - like 
get_host_power_status(), set_host_power(), get_one_time_boot(), 
set_one_time_boot(), etc. (Entire list is here 
https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/operations.py).

We have only seen benefits in doing it.  Let me bring in some examples:

1) We tried to add support for some lower version of servers.  We could do this 
without making any changes in Ironic (Review in proliantutils 
https://review.openstack.org/#/c/153945/)
2) We are adding support for newer models of servers (earlier we use to talk to 
servers in protocol called RIBCL, newer servers we will use a protocol called 
RIS) - We could do this with just 14 lines of actual code change in Ironic 
(this was needed mainly because we didn't think we will have to use a new 
protocol itself when we started) - https://review.openstack.org/#/c/154403/

Now talking about the advantages of putting hardware-specific code in Ironic:

1) It's reviewed by Openstack community and tested:
No. I doubt if I throw in 600 lines of new iLO specific code that is here 
(https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/ris.py)
 for Ironic folks, they will hardly take a look at it.  And regarding testing, 
it's not tested in the gate unless we have a 3rd party CI for it.  [We (iLO 
drivers) also don't have 3rd party CI right now, but we are working on it.]

2) Everything gets packaged into distributions automatically:
Now the hardware-specific code that we add in Ironic under 
drivers/modules// will get packaged into distributions, but this code 
in turn will have dependencies  which needs to be installed manually by the 
operator (I assume vendor specific dependencies are not considered by Linux 
distributions while packaging Openstack Ironic). Anyone installing Ironic and 
wanting to manage my company's servers will again need to install these 
dependencies manually.  Why not install the wrapper if there is one too.

I assume we only get these advantages by moving all of hardware-specific code 
to a wrapper module in stackforge and just exposing some APIs for Ironic to use:
* Ironic code would be much cleaner and easier to maintain
* Any changes related to your hardware - support for newer hardware, bug fixes 
in particular models of hardware, would be very easy. You don't need to change 
Ironic code for that. You could just fix the bug in your module, release a new 
version and ask your users to install a newer version of the module.
* python-fooclient c

Re: [openstack-dev] [nova] how safe is it to change NoAuthMiddlewareBase?

[Jay Pipes]

On 02/26/2015 04:27 AM, Sean Dague wrote:

In trying to move the flavor manage negative tests out of Tempest and
into the Nova functional tree, I ran into one set of tests which are
permissions checking. Basically that a regular user isn't allowed to do
certain things.

In (nearly) all our tests we use auth_strategy=noauth which takes you to
NoAuthMiddlewareBase instead of to keystone. That path makes you an
admin regardless of what credentials you send in -
https://github.com/openstack/nova/blob/master/nova/api/openstack/auth.py#L56-L59

What I'd like to do is to change this so that if you specify
user_id='admin' then is_admin is set true, and it's not true otherwise.

That has a bunch of test fall out, because up until this point most of
the test users are things like 'fake', which would regress to non admin.
About 25% of the api samples tests fail in such a change, so they would
need to be fixed.


Taking a step back... what exactly is the purpose of the API samples 
"functional tests"? If the purpose of these tests has anything to do 
with validating some policy thing, then I suppose it's worth changing 
the auth middleware to support non-adminness. But, I don't think the API 
samples test purpose has anything to do with that (I think the purpose 
of the API samples tests is fuzzy, at best, actually). So, I'd just 
leave them as-is and not change anything at all.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Need help in configuring keystone

[Akshik DBK]

Hi Marco, did you get a chance to look at the logs,
Regards,Akshik

From: aks...@outlook.com
To: openstack-dev@lists.openstack.org
Date: Fri, 27 Feb 2015 22:50:47 +0530
Subject: Re: [openstack-dev] Need help in configuring keystone




Hi Marco,
Thanks for responding, Ive cleared the log file and have restarted the shibd 
service.
the metadata file got created, i've attached the log file and metadata file as 
well.
Regards,Akshik

Date: Fri, 27 Feb 2015 15:12:39 +0100
From: marco.farge...@ct.infn.it
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Need help in configuring keystone

Hi Akshik,
 
the metadata error is in your SP, if the error was on testshib you
should not be redirected back after the login. Maybe there is a configuration
problem with shibboleth. Try to restart the service and look at shibboleth logs.
Check also the metadata of testshib are downloaded correctly because from the 
error
it seems you have not the metadata of testshib.
 
Cheers,
Marco
 
On Fri, Feb 27, 2015 at 06:39:30PM +0530, Akshik DBK wrote:
> Hi Marek ,
> I've registered with testshib, this is my keystone-apache-error.log log i get 
> [error] [client 121.243.33.212] No MetadataProvider available., referer: 
> https://idp.testshib.org/idp/profile/SAML2/Redirect/SSO
> From: aks...@outlook.com
> To: openstack-dev@lists.openstack.org
> Date: Fri, 27 Feb 2015 15:56:57 +0530
> Subject: [openstack-dev] Need help in configuring keystone
> 
> 
> 
> 
> Hi I'm new to SAML, trying to integrate keystone with SAML, Im using Ubuntu 
> 12.04 with Icehouse,im following http://docs.openstack.org/developer/k...when 
> im trying to configure keystone with two idp,when i access 
> https://MYSERVER:5000/v3/OS-FEDERATIO...it gets redirected to testshib.org , 
> it prompts for username and password when the same is given im 
> gettingshibsp::ConfigurationException at ( 
> https://MYSERVER:5000/Shibboleth.sso/... ) No MetadataProvider available.here 
> is my shibboleth2.xml content xmlns="urn:mace:shibboleth:2.0:native:sp:config"
> xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config"
> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
> xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
> clockSkew="180">
> 
> https://MYSERVER:5000/Shibboleth";>
>  relayState="ss:mem" handlerSSL="false">
> https://idp.testshib.org/idp/shibboleth"; 
> ECP="true">
> SAML2 SAML1
> 
> 
> SAML2 Local
> 
>  signing="false"/>
> 
>  showAttributeValues="false"/>
> 
> 
> 
>  logoLocation="/shibboleth-sp/logo.jpg"
> styleSheet="/shibboleth-sp/main.css"/>
> 
>  path="attribute-map.xml"/>
> 
>  path="attribute-policy.xml"/>
>  certificate="sp-cert.pem"/>
> 
>  entityID="https://MYSERVER:5000/Shibboleth";>
> 
>  relayState="ss:mem" handlerSSL="false">
>  entityID="https://portal4.mss.internalidp.com/idp/shibboleth"; ECP="true">
> SAML2 SAML1
> 
> SAML2 Local
> 
> 
>  uri="https://portal4.mss.internalidp.com/idp/shibboleth";
>  backingFilePath="/tmp/tata.xml" reloadInterval="18" />
> 
> 
>  entityID="https://MYSERVER:5000/Shibboleth";>
>  relayState="ss:mem" handlerSSL="false">
> https://idp.testshib.org/idp/shibboleth"; 
> ECP="true">
> SAML2 SAML1
> 
> 
> SAML2 Local
> 
> 
>  uri="https://idp.testshib.org/idp/shibboleth";  
> backingFilePath="/tmp/testshib.xml" reloadInterval="18"/>
> 
> 
> 
>  path="security-policy.xml"/>
>  path="protocols.xml"/>
> here is my wsgi-keystoneWSGIScriptAlias /keystone/main  
> /var/www/cgi-bin/keystone/main
> WSGIScriptAlias /keystone/admin  /var/www/cgi-bin/keystone/admin
> 
> 
> # NSSRequireSSL
> SSLRequireSSL
> Authtype none
> 
> 
> 
> SetHandler shib
> 
> 
> 
> ShibRequestSetting requireSession 1
> ShibRequestSetting applicationId idp_1
> AuthType shibboleth
> ShibRequireAll On
> ShibRequireSession On
> ShibExportAssertion Off
> Require valid-user
> 
> 
> 
> ShibRequestSetting requireSession 1
> ShibRequestSetting applicationId idp_2
> AuthType shibboleth
> ShibRequireAll On
> ShibRequireSession On
> ShibExportAssertion Off
> Require valid-user
>  
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 

Re: [openstack-dev] [Magnum] Mid-Cycle Meetup Planning

[Adrian Otto]

The full agenda is linked from:

https:// wiki.openstack.org/wiki/Magnum/Mid-Cycle

See my other email for my 5 asks of our participants.

Adrian


 Original message 
From: Weidong Shao
Date:02/27/2015 10:33 PM (GMT-08:00)
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [Magnum] Mid-Cycle Meetup Planning

Could you post the detailed agenda for both days?  Thanks!

On Mon, Jan 26, 2015 at 3:54 PM Adrian Otto 
mailto:adrian.o...@rackspace.com>> wrote:
Team,

Thanks for participating in the poll. Due to considerable scheduling conflicts, 
I am expanding the poll to include the following Monday 2015-03-02+Tuesday 
2015-03-03. Hopefully these alternate dates can get more of us together on the 
same days.

Please take a moment to respond to the poll a second time to indicate your 
availability on the newly proposed dates:

http://doodle.com/ddgsptuex5u3394m

Thanks,

Adrian

On Jan 8, 2015, at 2:24 PM, Adrian Otto 
mailto:adrian.o...@rackspace.com>> wrote:

> Team,
>
> If you have been watching the Magnum project you know that things have really 
> taken off recently. At Paris we did not contemplate a Mid-Cycle meet-up but 
> now that we have come this far so quickly, and have such a broad base of 
> participation now, it makes sense to ask if you would like to attend a 
> face-to-face mid-cycle meetup. I propose the following for your consideration:
>
> - Two full days to allow for discussion of Magnum architecture, and 
> implementation of our use cases.
> - Located in San Francisco.
> - Open to using Los Angeles or another west coast city to drive down travel 
> expenses, if that is a concern that may materially impact participation.
> - Dates: February 23+24 or 25+26
>
> If you think you can attend (with 80+% certainty) please indicate your 
> availability on the proposed dates using this poll:
>
> http://doodle.com/ddgsptuex5u3394m
>
> Please also add a comment on the Doodle Poll indicating what Country/US City 
> you will be traveling FROM in order to attend.
>
> I will tabulate the responses, and follow up to this thread. Feel free to 
> respond to this thread to discuss your thoughts about if we should meet, or 
> if there are other locations or times that we should consider.
>
> Thanks,
>
> Adrian
>
> PS: I do recognize that some of our contributors reside in countries that 
> require Visas to travel to the US, and those take a long time to acquire. The 
> reverse is also true. For those of you who can not attend in person, we will 
> explore options for remote participation using teleconferencing technology, 
> IRC, Etherpad, etc for limited portions of the agenda.
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Ask for review for cinder driver patch

[Anita Kuno]

On 02/27/2015 10:02 PM, liuxinguo wrote:
> Hi Mike,
> 
> I have fixed the patch as your comments and have committed it at 
> https://review.openstack.org/#/c/152116/.
> 
> Would you please have a review at it, thanks!
> 
> Best regards,
> Liu
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
The mailing list is not the place to ask for reviews on patches.

If you want to discuss the status of a patch the best place is to join
irc, in this case #openstack-cinder, and discuss the patch and its
status in there.

Thank you,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] what code in cinder volume driver supports volume migration between two backends of same type but having different volume types? [cinder]

[Nikesh Kumar Mahalka]

I tried below link  for volume migration on my driver and also similar
efforts for LVM.
Even whatever documents available in openstack for
volume-migration,each one showing volume migration of a volume having
volume type None

I added host assisted volume migration function in my cinder driver.
When i am trying volume migration on a volume without volume type,then
my volume migration function is getting called and i  am able to do
volume migration.

But when i am trying volume migration on a volume having volume
type,then my volume migration function is not getting called.


http://paste.openstack.org/show/183392/
http://paste.openstack.org/show/183405/



On Tue, Jan 20, 2015 at 12:31 AM, Nikesh Kumar Mahalka
 wrote:
> do cinder retype (v2) works for lvm?
> How to use cinder retype?
>
> I tried for volume migration from one volume-type LVM backend to
> another volume-type LVM backend.But its failed.
> How can i acheive this?
>
> Similarly i am writing a cinder volume driver for my array and want to
> migrate volume from one volume type to another volume type for my
> array backends.
> so want to know how can i achieve this in cinder driver?
>
>
>
> Regards
> Nikesh

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Sahara][HDP]Cluster staty in Configuring status forever

[Li, Chen]

Hi Sahara,

I'm a new bird here for both sahara & HDP.
I just installed a total fresh all-in-one Openstack environment by devstack, 
and want to build my first Hadoop cluster.

Limited to my knowledge about Hadoop and HDP, I  hope to build a cluster as 
small as I can.

All things are build based on plugin HDP  2.0.6.


1.   I created 2 node-group templates:

a.   Master

NAMENODE

ZOOKEEPER_SERVER

AMBARI_SERVER

HISTORYSERVER

RESOURCEMANAGER

b.  slave

NODEMANAGER





2.   I create a cluster template which include the above 2 node groups.

3.   I launched the cluster in Horizon, and started waiting...

4.   The cluster stalled at status "Configuring".

Anyone know why this happened ??

Thanks.
-chen


I did a little check, as "nova list" showed:
nova list

+--+---+++-++
| ID   | Name  | Status | 
Task State | Power State | Networks   |

+--+---+++-++
| f2e27b00-858e-4c71-822d-abc1bd35b0d4 | kk-basic-master-001   | ACTIVE | - 
 | Running | private=10.0.0.4, 192.169.14.3 |
| e757756c-7d53-49e0-91b1-af7e67b85f03 | kk-smallest-slave-001 | ACTIVE | - 
 | Running | private=10.0.0.5, 192.169.14.4 |

+--+---+++-++

Instances were started successfully and network is working well too.

The sahara log keeps printing:
2015-02-28 16:30:27.908 DEBUG sahara.utils.ssh_remote [-] [kk-basic-master-001] 
Retrieving HTTP session for 192.169.14.3:8080 from (pid=28144) _log_command 
/opt/stack/sahara/sahara/utils/ssh_remote.py:759
2015-02-28 16:30:27.909 DEBUG sahara.utils.ssh_remote [-] cached HTTP session 
for 192.169.14.3:8080 is  
from (pid=28144) _get_http_client 
/opt/stack/sahara/sahara/utils/ssh_remote.py:200
2015-02-28 16:30:27.910 DEBUG urllib3.util.retry [-] Converted retries value: 0 
-> Retry(total=0, connect=None, read=None, redirect=0) from (pid=28144) 
from_int /usr/local/lib/python2.7/dist-packages/urllib3/util/retry.py:155
2015-02-28 16:30:27.911 INFO urllib3.connectionpool [-] Resetting dropped 
connection: proxy-socks.sc.intel.com
2015-02-28 16:30:28.216 DEBUG urllib3.connectionpool [-] "GET 
http://192.169.14.3:8080/api/v1/hosts HTTP/1.1" 503 784 from (pid=28144) 
_make_request 
/usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:368
2015-02-28 16:30:28.219 INFO 
sahara.plugins.hdp.versions.version_2_0_6.versionhandler [-] Waiting to connect 
to ambari server ...
2015-02-28 16:30:32.277 DEBUG sahara.openstack.common.periodic_task [-] Running 
periodic task SaharaPeriodicTasks.terminate_unneeded_transient_clusters from 
(pid=28144) run_periodic_tasks 
/opt/stack/sahara/sahara/openstack/common/periodic_task.py:219
2015-02-28 16:30:32.277 DEBUG sahara.service.periodic [-] Terminating unneeded 
transient clusters from (pid=28144) terminate_unneeded_transient_clusters 
/opt/stack/sahara/sahara/service/periodic.py:131
2015-02-28 16:30:32.316 DEBUG sahara.openstack.common.loopingcall [-] Dynamic 
looping call > 
sleeping for 9.96 seconds from (pid=28144) _inner 
/opt/stack/sahara/sahara/openstack/common/loopingcall.py:132
2015-02-28 16:30:33.278 DEBUG sahara.utils.ssh_remote [-] [kk-basic-master-001] 
Retrieving HTTP session for 192.169.14.3:8080 from (pid=28144) _log_command 
/opt/stack/sahara/sahara/utils/ssh_remote.py:759
2015-02-28 16:30:33.279 DEBUG sahara.utils.ssh_remote [-] cached HTTP session 
for 192.169.14.3:8080 is  
from (pid=28144) _get_http_client 
/opt/stack/sahara/sahara/utils/ssh_remote.py:200
2015-02-28 16:30:33.280 DEBUG urllib3.util.retry [-] Converted retries value: 0 
-> Retry(total=0, connect=None, read=None, redirect=0) from (pid=28144) 
from_int /usr/local/lib/python2.7/dist-packages/urllib3/util/retry.py:155
2015-02-28 16:30:33.281 INFO urllib3.connectionpool [-] Resetting dropped 
connection: proxy-socks.sc.intel.com
2015-02-28 16:30:33.573 DEBUG urllib3.connectionpool [-] "GET 
http://192.169.14.3:8080/api/v1/hosts HTTP/1.1" 503 784 from (pid=28144) 
_make_request 
/usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:368
2015-02-28 16:30:33.574 INFO 
sahara.plugins.hdp.versions.version_2_0_6.versionhandler [-] Waiting to connect 
to ambari server ...
2015-02-28 16:30:38.634 DEBUG sahara.utils.ssh_remote [-] [kk-basic-master-001] 
Retrieving HTTP session for 192.169.14.3:8080 from (pid=28144) _log_command 
/opt/stack/sahara/sahara/utils/ssh_remote.py:759
2015-02-28 16:30:38.634 DEBUG sahara.utils.ssh_remote [-] cached HTTP session 
for 192.169.14.3:8080 is  
from (pid=28144) _get_http_client 
/opt/stack/sahara/sahara/utils/ssh_remote.py:200
2015-02-28 16:30:38.63

[openstack-dev] [Magnum][Containers] Magnum Midcycle Agenda

[Adrian Otto]

Team,

It is not too late to register for the our Midcycle Meetup in San Francisco for 
Monday 3/2 and Tuesday 3/3. Find the link to tickets on the Wiki page:

https://wiki.openstack.org/wiki/Magnum/Midcycle

I have published the revised Agenda Etherpad (subject to change):

https://etherpad.openstack.org/p/magnum-midcycle-topics

Asks:

1) For those of you wishing to attend remotely, please add your names and 
timezones to the REMOTES line for that session. We will have a webex conference 
set up to allow for remote participation. 

2) Our discussions will have a leader, and a scribe for etherpad note taking. 
Please sign up to lead sessions you proposed by putting your name on the 
etherpad next to LEADER for that session.

3) We will be keeping notes for each session in the linked etherpads. Everyone 
is encouraged to participate in interactive note taking. Please volunteer to 
take scribe duty for at least one of the sessions. Pick the session that you 
are unlikely to do a lot of talking in.

4) If you are a remote attendee, and you would like us to move a session to a 
different time because of your timezone, or other reason, please contact me 
directly by email so I can work to accommodate you.

5) You may add additional topics to the numbered list at the bottom of the 
Agenda etherpad. We can fit topics into the Parking Lot timeslots.

I look forward to seeing all of you in San Francisco (in person, or remotely) 
on Monday.

Thanks,

Adrian
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev