[openstack-dev] [cinder][horizon]Proper error handling/propagation to UI

[Eduard Matei]

Hi,

We've been testing our cinder driver extensively and found a strange
behavior in the UI:
- when trying to delete a snapshot that has clones (created volume from
snapshot) and error is raised in our driver which turns into
"error_deleting" in cinder and the UI; further actions on that snapshot are
impossible from the ui, the user has to go to CLI and do cinder
snapshot-reset-state to be able to delete it (after having deleted the
clones)
- to help with that we implemented a check in the driver and now we raise
exception.SnapshotIsBusy; now the snapshot remains available (as it should
be) but no error "bubble" is shown in the UI (only the green one: Success.
Scheduled deleting of...). So the user has to go to c-vol screen and check
the cause of the error

So question: how should we handle this so that
a. The snapshot remains in state "available"
b. An error bubble is shown in the UI stating the cause.

Thanks,
Eduard

-- 

*Eduard Biceri Matei, Senior Software Developer*
www.cloudfounders.com
 | eduard.ma...@cloudfounders.com



*CloudFounders, The Private Cloud Software Company*

Disclaimer:
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed.
If you are not the named addressee or an employee or agent responsible
for delivering this message to the named addressee, you are hereby
notified that you are not authorized to read, print, retain, copy or
disseminate this message or any part of it. If you have received this
email in error we request you to notify us by reply e-mail and to
delete all electronic files of the message. If you are not the
intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.
E-mail transmission cannot be guaranteed to be secure or error free as
information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the content of this
message, and shall have no liability for any loss or damage suffered
by the user, which arise as a result of e-mail transmission.
__
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] [Keystone] [devstack] About _member_ role

[Pasquale Porreca]

As I said in your code review I don't really like an approach that
require saving a random generate id in the config file and a keystone
restart.
I would like you to review my proposal if you don't mind
https://review.openstack.org/156527

I think this is a quite important bug in devstack since it prevents
users to create or manage projects, so I would ask anyone interested -
especially devstack core reviewers - to give a look to the bug report
https://bugs.launchpad.net/devstack/+bug/1421616 and the proposed fixes.

On 02/27/15 06:38, Jamie Lennox wrote:
>
> - Original Message -
>> From: "Pasquale Porreca" 
>> To: "OpenStack Development Mailing List (not for usage questions)" 
>> 
>> Sent: Thursday, February 19, 2015 3:24:03 AM
>> Subject: Re: [openstack-dev] [Keystone] [devstack] About _member_ role
>>
>> Analyzing Horizon code I can confirm that the existence of _member_ role
>> is required, so the commit https://review.openstack.org/#/c/150667/
>> introduced the bug in devstack. More details and a fix proposal in my
>> change submission: https://review.openstack.org/#/c/156527/
>>
>> On 02/18/15 10:04, Pasquale Porreca wrote:
>>> I saw 2 different bug report that Devstack dashboard gives an error when
>>> trying to manage projects
>>> https://bugs.launchpad.net/devstack/+bug/1421616 and
>>> https://bugs.launchpad.net/horizon/+bug/1421999
>>> In my devstack environment projects were working just fine, so I tried a
>>> fresh installation to see if I could reproduce the bug and I could
>>> confirm that actually the bug is present in current devstack deployment.
>>> Both reports point to the lack of _member_ role this error, so I just
>>> tried to manually (i.e. via CLI) add a _member_ role and I verified that
>>> just having it - even if not assigned to any user - fix the project
>>> management in Horizon.
>>>
>>> I didn't deeply analyze yet the root cause of this, but this behaviour
>>> seemed quite weird, this is the reason I sent this mail to dev list.
>>> Your explanation somewhat confirmed my doubts: I presume that adding a
>>> _member_ role is merely a workaround and the real bug is somewhere else
>>> - in Horizon code with highest chance.
> Ok, so I dug into this today. The problem is that the 'member_role_name' that 
> is set in keystone CONF is only being read that first time when it creates 
> the default member role if not already present. At all other times keystone 
> works with the role id set by 'member_role_id' which has a default value. So 
> even though horizon is looking and finding a member_role_name it doesn't 
> match up with what keystone is doing when it uses member_role_id. 
>
> IMO this is wrong and i filed a bug against keystone: 
> https://bugs.launchpad.net/keystone/+bug/1426184
>
> In the mean time it works if you add both the member_role_name and 
> member_role_id to the config file. Unfortunately adding an ID means you need 
> to get the value from keystone and then set it into keystone's own config 
> file, so restarting keystone. This is similar to a review I had for policy so 
> I modified that and put up my own review 
> https://review.openstack.org/#/c/159690
>
> Given the keystone restart I don't know if it's cleaner, however that's the 
> way i know to solve this 'properly'. 
>
>
> Jamie
>
>>> On 02/17/15 21:01, Jamie Lennox wrote:
 - Original Message -
> From: "Pasquale Porreca" 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Sent: Tuesday, 17 February, 2015 9:07:14 PM
> Subject: [openstack-dev]  [Keystone] [devstack] About _member_ role
>
> I proposed a fix for a bug in devstack
> https://review.openstack.org/#/c/156527/ caused by the fact the role
> _member_ was not anymore created due to a recent change.
>
> But why is the existence of _member_ role necessary, even if it is not
> necessary to be used? Is this a know/wanted feature or a bug by itself?
 So the way to be a 'member' of a project so that you can get a token
 scoped to that project is to have a role defined on that project.
 The way we would handle that from keystone for default_projects is to
 create a default role _member_ which had no permissions attached to it,
 but by assigning it to the user on the project we granted membership of
 that project.
 If the user has any other roles on the project then the _member_ role is
 essentially ignored.

 In that devstack patch I removed the default project because we want our
 users to explicitly ask for the project they want to be scoped to.
 This patch shouldn't have caused any issues though because in each of
 those cases the user is immediately granted a different role on the
 project - therefore having 'membership'.

 Creating the _member_ role manually won't cause any problems, but what
 issue are you seeing where you need it?


 Jamie


> --
> Pasquale Porreca

[openstack-dev] [Nova][Flavor] Constraint in creating flavor with the same name and different ID

[Abhishek Talwar/HYD/TCS]

Hi All,

I am writing in reference to a bug ( Bug #1423885) I have been working on, It 
is regarding the inconsistency shown my "nova flavor show" command. I have a 
doubt regarding that why  there is a constraint to create two flavors with the 
same name whereas we can do the same for instances, images, volumes etc. 



-- 
Thanks and Regards
Abhishek Talwar
Employee ID : 770072
Assistant System Engineer
Tata Consultancy Services,Gurgaon
India
Contact Details : +918377882003
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


__
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] Ideas about Openstack Cinder for GSOC 2015

[harryxiyou]

Hi all,

I cannot find the proper idea about Openstack Cinder for GSOC 2015
here[1]. Could anyone please give me some clues?

[1] https://wiki.openstack.org/wiki/GSoC2015


Thanks, Harry

__
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] [all] creating a unified developer reference manual

[Thierry Carrez]

Doug Hellmann wrote:
> Maybe some of the folks in the meeting who felt more strongly that it
> should be a separate document can respond with their thoughts?

I don't feel very strongly and could survive this landing in
openstack-specs. My objection was the following:

- Specs are for designing the solution and implementation plan to a
specific problem. They are mainly used by developers and reviewers
during implementation as a clear reference rationale for change and
approved plan. Once they are fully implemented, they are kept for
history purpose, not for constant reference.

- Guidelines/developer doc are for all developers (old and new) to
converge on best practices on topics that are not directly implemented
as hacking rules. They are constantly used by everyone (not just
developers/reviewers of a given feature) and never become "history".

Putting guidelines doc in the middle of specs makes it a bit less
discoverable imho, especially by our new developers. It's harder to
determine which are still current and you should read. An "OpenStack
developer doc" sounds like a much better entry point.

That said, the devil is in the details, and some efforts start as specs
(for existing code to catch up with the recommendation) and become
guidelines (for future code being written). That is the case of the log
levels spec: it is both a spec and a guideline. Personally I wouldn't
object if that was posted in both areas, or if the relevant pieces were
copied, once the current code has caught up, from the spec to a dev
guideline.

In the eventlet case, it's only a set of best practices / guidelines:
there is no specific problem to solve, no catch-up plan for existing
code to implement. Only a collection of recommendations if you get to
write future eventlet-based code. Those won't start or end. Which is why
I think it should go straight to a developer doc.

-- 
Thierry Carrez (ttx)

__
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] [stable][all] Revisiting the 6 month release cycle [metrics]

[Daniel P. Berrange]

On Fri, Feb 27, 2015 at 09:51:34AM +1100, Michael Still wrote:
> On Fri, Feb 27, 2015 at 9:41 AM, Stefano Maffulli  
> wrote:
> 
> > Does it make sense to purge old stuff regularly so we have a better
> > overview? Or maybe we should chart a distribution of age of proposed
> > changesets, too in order to get a better understanding of where the
> > outliers are?
> 
> Given the abandon of a review isn't binding (a proposer can easily
> unabandon), I do think we should abandon more than we do now. The
> problem at the moment being that its a manual process which isn't much
> fun for the person doing the work.
> 
> Another factor to consider here is that abandoned patches against bugs
> make the bug look like someone is working on a fix, which probably
> isn't the case.
> 
> Nova has been trying some very specific things to try and address
> these issues, and I think we're improving. Those things are:
> 
> * specs
> * priority features

This increased level of process in Nova has actually made the negative
effects of the 6 month cycle noticably worse on balance. If you aren't
able to propose your feature in the right window of the dev cycle your
chances of getting stuff merged has gone down significantly and the time
before users are likely to see your feature has correspondingly gone up.
Previously people could come along with simple features at the end of
the cycle and we had the flexibility to be pragmmatic and review and
approve them. Now we're lacking them that ability even if we have the
spare review cycles to consider it. The processes adopted have merely
made us more efficient at disappointing contributors earlier in the
cycle. There's been no changes made that would  solve the bigger problem
of the fact that Nova is far too large vs the size of the core review
team, so we have a ongoing major bottleneck in our development. That,
bottleneck combined with the length of the 6 month cycle is an ongoing
disaster for our contributors.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] [all] creating a unified developer reference manual

[Gorka Eguileor]

On Wed, Feb 25, 2015 at 02:54:35PM -0500, Doug Hellmann wrote:
> 
> That leads to two questions, then:
> 
> 1. Should we have a unified developer guide for the project?

Sounds like a great idea to me, I think we should.

> 2. Where should it live and how should we manage it?
> 

I like Stefano's idea of it being under docs.openstack.org/developer

> An alternative is to designate a subsection of the openstack-specs
> repository for the content, as we’ve done in Oslo. In this case,
> though, I think it makes more sense to create a new repository. If
> there is a general agreement to go ahead with the plan, I will set
> that up with a Sphinx project framework to get us started.
> 
> Comments?
> 
> Doug

Gorka Eguileor.

__
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] Need help in configuring keystone

[Akshik DBK]

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

https://MYSERVER:5000/Shibboleth";>

https://idp.testshib.org/idp/shibboleth"; ECP="true">
SAML2 SAML1


SAML2 Local














https://MYSERVER:5000/Shibboleth";>


https://portal4.mss.internalidp.com/idp/shibboleth"; ECP="true">
SAML2 SAML1

SAML2 Local


https://portal4.mss.internalidp.com/idp/shibboleth";
 backingFilePath="/tmp/tata.xml" reloadInterval="18" />


https://MYSERVER:5000/Shibboleth";>

https://idp.testshib.org/idp/shibboleth"; 
ECP="true">
SAML2 SAML1


SAML2 Local


https://idp.testshib.org/idp/shibboleth";  
backingFilePath="/tmp/testshib.xml" reloadInterval="18"/>





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] [devstack] [Cinder-GlusterFS CI] centos7 gate job abrupt failures

[Deepak Shetty]

On Wed, Feb 25, 2015 at 11:48 PM, Deepak Shetty  wrote:

>
>
> On Wed, Feb 25, 2015 at 8:42 PM, Deepak Shetty 
> wrote:
>
>>
>>
>> On Wed, Feb 25, 2015 at 6:34 PM, Jeremy Stanley 
>> wrote:
>>
>>> On 2015-02-25 17:02:34 +0530 (+0530), Deepak Shetty wrote:
>>> [...]
>>> > Run 2) We removed glusterfs backend, so Cinder was configured with
>>> > the default storage backend i.e. LVM. We re-created the OOM here
>>> > too
>>> >
>>> > So that proves that glusterfs doesn't cause it, as its happening
>>> > without glusterfs too.
>>>
>>> Well, if you re-ran the job on the same VM then the second result is
>>> potentially contaminated. Luckily this hypothesis can be confirmed
>>> by running the second test on a fresh VM in Rackspace.
>>>
>>
>> Maybe true, but we did the same on hpcloud provider VM too and both time
>> it ran successfully with glusterfs as the cinder backend. Also before
>> starting
>> the 2nd run, we did unstack and saw that free memory did go back to 5G+
>> and then re-invoked your script, I believe the contamination could result
>> in some
>> additional testcase failures (which we did see) but shouldn't be related
>> to
>> whether system can OOM or not, since thats a runtime thing.
>>
>> I see that the VM is up again. We will execute the 2nd run afresh now and
>> update
>> here.
>>
>
> Ran tempest with configured with default backend i.e. LVM and was able to
> recreate
> the OOM issue, so running tempest without gluster against a fresh VM
> reliably
> recreates the OOM issue, snip below from syslog.
>
> Feb 25 16:58:37 devstack-centos7-rax-dfw-979654 kernel: glance-api invoked
> oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
>
> Had a discussion with clarkb on IRC and given that F20 is discontinued,
> F21 has issues with tempest (under debug by ianw)
> and centos7 also has issues on rax (as evident from this thread), the only
> option left is to go with ubuntu based CI job, which
> BharatK is working on now.
>

Quick Update:

Cinder-GlusterFS CI job on ubuntu was added (
https://review.openstack.org/159217)

We ran it 3 times against our stackforge repo patch @
https://review.openstack.org/159711
and it works fine (2 testcase failures, which are expected and we're
working towards fixing them)

For the logs of the 3 experimental runs, look @
http://logs.openstack.org/11/159711/1/experimental/gate-tempest-dsvm-full-glusterfs/

Of the 3 jobs, 1 was schedued on rax and 2 on hpcloud, so its working
nicely across
the different cloud providers.

thanx,
deepak
__
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

[Marek Denis]

Hi Akshik,

Did you upload your Metadata file to the testshib server?
You are advised to follow steps starting from here: 
http://testshib.org/register.html


For the record, Keystone will act here as a Service Provider,  so you 
need to follow testhib docs/tutorials for setting your SP (Service Provider)


Let me know if that was your issue.
If not, a more detailed steps of how your configured your Keystone 
acting as a Service Provider would be more helpful.


Marek Denis

On 27.02.2015 11:26, Akshik DBK wrote:


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 getting


*shibsp::ConfigurationException at ( 
https://MYSERVER:5000/Shibboleth.sso/... 
 ) No 
MetadataProvider available.*


here is my shibboleth2.xml content

| 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";>
 
 https://idp.testshib.org/idp/shibboleth";  
ECP="true">
 SAML2 SAML1
 

 SAML2 Local

 
 
 
 
 

 

 
 
 
 

 https://MYSERVER:5000/Shibboleth";>

 
 https://portal4.mss.internalidp.com/idp/shibboleth";  
ECP="true">
 SAML2 SAML1
 
 SAML2 Local
 

 https://portal4.mss.internalidp.com/idp/shibboleth";
  backingFilePath="/tmp/tata.xml"  reloadInterval="18"  />
 

 https://MYSERVER:5000/Shibboleth";>
 
 https://idp.testshib.org/idp/shibboleth";  
ECP="true">
 SAML2 SAML1
 

 SAML2 Local
 

 https://idp.testshib.org/idp/shibboleth";   
 backingFilePath="/tmp/testshib.xml"  reloadInterval="18"/>

 
 

 
 
|

here is my wsgi-keystone

|WSGIScriptAlias  /keystone/main/var/www/cgi-bin/keystone/main
WSGIScriptAlias  /keystone/admin/var/www/cgi-bin/keystone/admin


# NSSRequireSSL
SSLRequireSSL
Authtype  none



 SetHandler  shib



 ShibRequestSetting  requireSession1
 ShibRequestSetting  applicationId idp_1
 AuthType  shibboleth
 ShibRequireAll  On
 ShibRequireSession  On
 ShibExportAssertion  Off
 Require  valid-user



 ShibRequestSetting  requireSession1
 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


__
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] [Fuel] Stop distributing IMG artifact and start using hybrid ISO.

[Stanislaw Bogatkin]

Hi everyone,

we have merged code that will create hybrid ISO. Current 6.1 #147 ISO
already can be booted from USB by standard method (just using dd
of=/path/to/iso of=/path/to/usb/stick).

Creating IMG artifact will be disabled soon, so, please, be aware of it.
__
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] [stable][all] Revisiting the 6 month release cycle [metrics]

[Sean Dague]

On 02/26/2015 05:41 PM, Stefano Maffulli wrote:
> On Thu, 2015-02-26 at 15:58 -0600, Kevin L. Mitchell wrote:
>> One thing that comes to mind is that there are a lot of reviews that
>> appear to have been abandoned; I just cleared several from the
>> novaclient review queue (or commented on them to see if they were still
>> alive).  I also know of a few novaclient changes that are waiting for
>> corresponding nova changes before they can be merged.  Could these be
>> introducing a skew factor?
> 
> Maybe, depending on how many they are and how old are we talking about.
> How much cruft is there? Maybe the fact that we don't autoabandon
> anymore is a relevant factor?
> 
> Looking at Nova time to merge (not the client, since clients are not
> analyzed individually), the median is over 10 days (the mean wait is
> 29). But if you look at the trends of time to way for reviewers, they've
> been trending down for 3 quarters in a row (both, average and median)
> while time to wait for submitter is trending up.
> 
> http://git.openstack.org/cgit/openstack-infra/activity-board/plain/reports/2014-q4/pdf/projects/nova.pdf
> 
> Does it make sense to purge old stuff regularly so we have a better
> overview? Or maybe we should chart a distribution of age of proposed
> changesets, too in order to get a better understanding of where the
> outliers are?

We already purge old stuff that's unmergable (no activity in > 4 weeks
with either a core -2 or Jenkins -1). The last purge was about 4 weeks
ago. So effectively abandoned code isn't in the system.

The merge conflict detector will also mean that all patches eventually
get a Jenkins -1 if they aren't maintained. So you should consider
everything in the system active for some definition.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [Fuel] Stop distributing IMG artifact and start using hybrid ISO.

[Mike Scherbakov]

Thanks, Stas.
Eugene, please ensure that all teams are prepared for it.

On Fri, Feb 27, 2015 at 1:48 PM, Stanislaw Bogatkin 
wrote:

> Hi everyone,
>
> we have merged code that will create hybrid ISO. Current 6.1 #147 ISO
> already can be booted from USB by standard method (just using dd
> of=/path/to/iso of=/path/to/usb/stick).
>
> Creating IMG artifact will be disabled soon, so, please, be aware of it.
>
> __
> 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
>
>


-- 
Mike Scherbakov
#mihgen
__
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] [Fuel][Nova][Cinder] Operations: adding new nodes in "disabled" state, allowed for test tenant only

[Bogdan Dobrelya]

On 23.02.2015 15:13, Bogdan Dobrelya wrote:
> + [Fuel] tag
> + openstack-operators ML
> 
> Joe Gordon joe.gordon0 at gmail.com
> Thu Dec 4 13:26:59 UTC 2014
> 
>> On Wed, Dec 3, 2014 at 3:31 PM, Mike Scherbakov > mirantis.com>
>> wrote:
> 
>>> Hi all,
>>> enable_new_services in nova.conf seems to allow add new compute nodes in
>>> disabled state:
>>>
>>>
>> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L507-L508,
>>> so it would allow to check everything first, before allowing production
>>> workloads host a VM on it. I've filed a bug to Fuel to use this by
>> default
>>> when we scale up the env (add more computes) [1].
>>>
>>> A few questions:
>>>
>>>1. can we somehow enable compute service for test tenant first? So
>>>cloud administrator would be able to run test VMs on the node, and
>> after
>>>ensuring that everything is fine - to enable service for all tenants
>>>
>>>
> 
>> Although there may be more then one way to set this up in nova, this can
>> definitely be done via nova host aggregates. Put new compute services into
>> an aggregate that only specific tenants can access (controlled via
> scheduler filter).
> 
> Looks reasonable, +1 for Nova host aggregates [0].
> 
> There is still a question, though, about an enable_new_services
> parameter, cinder and other OpenStack services. It is not clear how to
> use this parameter from an operator perspective, for example:
> 1) While deploying or scaling the OpenStack environment, we should set
> enable_new_services=false for all services which support it.

Just a note, it looks like Nova doesn't honor the
enable_new_services=false setting [0].

[0] https://bugs.launchpad.net/nova/+bug/1426332

> 2) Once the deploy/scale is done, re-enable disabled services. But how
> exactly that should be done?
> * Set enable_new_services=True and restart the schedulers and conductor
> services? Or API services as well?
> * Keep enable_new_services=false in configs, but issue - for nova
> exmaple - 'nova-manage service enable ...' commands for added compute
> nodes? And what about cinder and other ones (there are no *-manage
> service enable commands)?
> * Some another way?
> 
> And regarding plans for implementing this improvement in Fuel, I believe
> for nova computes it could be done as a workaround for the 6.1 release
> with the help of enable_new_services configuration parameter and a
> separate Fuel post-deploy granular task which should re-enable the
> disabled compute services. But this should be re-implemented later with
> separate host aggregate for deployment and health checks, see the
> related blueprint [1].
> 
> [0]
> http://docs.openstack.org/havana/config-reference/content/host-aggregates.html
> [1] https://blueprints.launchpad.net/fuel/+spec/disable-new-computes
> 
>>
>>1.
>>2. What about Cinder? Is there a similar option / ability?
>>3. What about other OpenStack projects?
>>
>> What is your opinion, how we should approach the problem (if there is a
>> problem)?
>>
>> [1] https://bugs.launchpad.net/fuel/+bug/1398817
>> --
>> Mike Scherbakov
>> #mihgen
>>
> 


-- 
Best regards,
Bogdan Dobrelya,
Skype #bogdando_at_yahoo.com
Irc #bogdando

__
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] [openstack-operators][Rally][HA-testing][multi-scenarios-load-gen] Proposal to change Rally input task format

[Mikhail Dubov]

Hi Boris,

nice job! I like how this new task format looks like. I have commented your
patch with a couple of suggestions to make it even easier to understand.

Best regards,
Mikhail Dubov

Engineering OPS
Mirantis, Inc.
E-Mail: mdu...@mirantis.com
Skype: msdubov

On Thu, Feb 26, 2015 at 12:24 AM, Boris Pavlovic  wrote:

> Hi stackers,
>
>
> When we started Rally we have a just small idea to make some tool that
> generates load and measures performance. During almost 2 years a lot of
> changed in Rally, so now it's quite common testing framework that allows to
> cover various topics like: stress, load, volume, performance, negative,
> functional testing. Since the begging we have idea of "scenario" centric
> approach, where scenario method that is called multiple times
> simultaneously to generate load and duration of it is collected.
>
> This is huge limitation that doesn't allow us to easily generate real life
> load. (e.g. loading simultaneously few components) or HA testing (where we
> need during the load generation to disable/kill process, reboot or power
> off physical nodes). To make this possible we should just run multiple
> scenarios in parallel, but this change will require change in input task
> format.
>
> I made proposal of new Rally task input format in this patch:
>
> https://review.openstack.org/#/c/159065/3/specs/new_rally_input_task_format.yaml
>
> Please review it. Let's try to resolve all UX issues before starting
> working on it.
>
> P.S. I hope this will be the last big change in Rally input task format..
>
>
> Best regards,
> Boris Pavlovic
>
> __
> 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] [openstack-operators][Rally][HA-testing][multi-scenarios-load-gen] Proposal to change Rally input task format

[Aleksandr Maretskiy]

Hi

Patch set #3 looks good for me (but I have a proposal about `description'
field).

Thanks!

On Fri, Feb 27, 2015 at 2:02 PM, Mikhail Dubov  wrote:

> Hi Boris,
>
> nice job! I like how this new task format looks like. I have commented
> your patch with a couple of suggestions to make it even easier to
> understand.
>
> Best regards,
> Mikhail Dubov
>
> Engineering OPS
> Mirantis, Inc.
> E-Mail: mdu...@mirantis.com
> Skype: msdubov
>
> On Thu, Feb 26, 2015 at 12:24 AM, Boris Pavlovic 
> wrote:
>
>> Hi stackers,
>>
>>
>> When we started Rally we have a just small idea to make some tool that
>> generates load and measures performance. During almost 2 years a lot of
>> changed in Rally, so now it's quite common testing framework that allows to
>> cover various topics like: stress, load, volume, performance, negative,
>> functional testing. Since the begging we have idea of "scenario" centric
>> approach, where scenario method that is called multiple times
>> simultaneously to generate load and duration of it is collected.
>>
>> This is huge limitation that doesn't allow us to easily generate real
>> life load. (e.g. loading simultaneously few components) or HA testing
>> (where we need during the load generation to disable/kill process, reboot
>> or power off physical nodes). To make this possible we should just run
>> multiple scenarios in parallel, but this change will require change in
>> input task format.
>>
>> I made proposal of new Rally task input format in this patch:
>>
>> https://review.openstack.org/#/c/159065/3/specs/new_rally_input_task_format.yaml
>>
>> Please review it. Let's try to resolve all UX issues before starting
>> working on it.
>>
>> P.S. I hope this will be the last big change in Rally input task format..
>>
>>
>> Best regards,
>> Boris Pavlovic
>>
>> __
>> 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
>
>
__
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] [api][all] - Openstack.error common library

[Eugeniya Kudryashova]

Thanks for the replies!

> Could you elaborate bit what you want to have in the headers and why? Our
plan has been so > far having the error code in the message payload so that
it?s easily available for users and

> operators.  What this library you?re proposing would be actually doing?

I’ve already read specs, proposed in glance about error codes.Actually I
don’t prefer leave such content in message payload at least due to the fact
error messages is translated, and can be changed while transmitting. Also,
as far as I remember in some openstack projects (can’t say more precisely
where) error messages is generated in the strange way, and put something
new in it will be hard, also some problems will appear while extracting.

> We?re more than happy to take extra hands on this so please follow up the
[log] discussion

> and feel free to contact me (IRC: jokke_) or Rockyg (in cc as well)
 around what has been

> done and planned in case you need more clarification.

Thanks, I’ll contact you via IRC.

> I'm not sure a single library as a home to all of the various error

> messages is the right approach. I thought, based on re-reading the

> thread you link to, that the idea was to come up with a standard schema

> for error payloads and then let the projects fill in the details. We

> might need a library for utility functions, but that wouldn't actually

> include the error messages.

Sure, maybe I wrongly spoke it. Library definitely shouldn’t contain  error
messages, errors or something like this - if so it will make managing
errors much more difficult. it should have stuff to put/extract header from
response and, you are right, other needed utilities.

On Wed, Feb 25, 2015 at 4:33 PM, Eugeniya Kudryashova <
ekudryash...@mirantis.com> wrote:

> Hi, stackers!
>
> As was suggested in topic [1], using an HTTP header was a good solution
> for communicating common/standardized OpenStack API error codes.
>
> So I’d like to begin working on a common library, which will collect all
> openstack HTTP API errors, and assign them string error codes. My suggested
> name for library is openstack.error, but please feel free to propose
> something different.
>
> The other question is where we should allocate such project, in openstack
> or stackforge, or maybe oslo-incubator? I think such project will be too
> massive (due to dealing with lots and lots of exceptions)  to allocate it
> as a part of oslo, so I propose developing the project on Stackforge and
> then eventually have it moved into the openstack/ code namespace when the
> other projects begin using the library.
>
> Let me know your feedback, please!
>
>
> [1] -
> http://lists.openstack.org/pipermail/openstack-dev/2015-January/055549.html
>
__
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 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

https://MYSERVER:5000/Shibboleth";>

https://idp.testshib.org/idp/shibboleth"; ECP="true">
SAML2 SAML1


SAML2 Local














https://MYSERVER:5000/Shibboleth";>


https://portal4.mss.internalidp.com/idp/shibboleth"; ECP="true">
SAML2 SAML1

SAML2 Local


https://portal4.mss.internalidp.com/idp/shibboleth";
 backingFilePath="/tmp/tata.xml" reloadInterval="18" />


https://MYSERVER:5000/Shibboleth";>

https://idp.testshib.org/idp/shibboleth"; 
ECP="true">
SAML2 SAML1


SAML2 Local


https://idp.testshib.org/idp/shibboleth";  
backingFilePath="/tmp/testshib.xml" reloadInterval="18"/>





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   
  __
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

[Marek Denis]

Hi again,

Did you upload Metadata generated by your Service Provider (Keystone) to 
testshib Identity Providers?

How did you generate /etc/shibboleth2/shibboleth2.xml file?

Did you read http://testshib.org/register.html ?

cheers,

Marek

__
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] [neutron] OpenFlow security groups (pre-benchmarking plan)

[Miguel Ángel Ajo]

Ok, I moved the document here [1], and I will eventually submit another patch
with the testing scripts when those are ready.

Let’s move the discussion to the review!,


Best,
Miguel Ángel Ajo
[1] https://review.openstack.org/#/c/159840/


On Friday, 27 de February de 2015 at 7:03, Kevin Benton wrote:

> Sounds promising. We'll have to evaluate it for feature parity when the time 
> comes.
>  
> On Thu, Feb 26, 2015 at 8:21 PM, Ben Pfaff  (mailto:b...@nicira.com)> wrote:
> > This sounds quite similar to the planned support in OVN to "gateway" a
> > logical network to a particular VLAN on a physical port, so perhaps it
> > will be sufficient.
> >  
> > On Thu, Feb 26, 2015 at 05:58:40PM -0800, Kevin Benton wrote:
> > > If a port is bound with a VLAN segmentation type, it will get a VLAN id 
> > > and
> > > a name of a physical network that it corresponds to. In the current 
> > > plugin,
> > > each agent is configured with a mapping between physical networks and OVS
> > > bridges. The agent takes the bound port information and sets up rules to
> > > forward traffic from the VM port to the OVS bridge corresponding to the
> > > physical network. The bridge usually then has a physical interface added 
> > > to
> > > it for the tagged traffic to use to reach the rest of the network.
> > >
> > > On Thu, Feb 26, 2015 at 4:19 PM, Ben Pfaff  > > (mailto:b...@nicira.com)> wrote:
> > >
> > > > What kind of VLAN support would you need?
> > > >
> > > > On Thu, Feb 26, 2015 at 02:05:41PM -0800, Kevin Benton wrote:
> > > > > If OVN chooses not to support VLANs, we will still need the current 
> > > > > OVS
> > > > > reference anyway so it definitely won't be wasted work.
> > > > >
> > > > > On Thu, Feb 26, 2015 at 2:56 AM, Miguel Angel Ajo Pelayo <
> > > > > majop...@redhat.com (mailto:majop...@redhat.com)> wrote:
> > > > >
> > > > > >
> > > > > > Sharing thoughts that I was having:
> > > > > >
> > > > > > May be during the next summit it???s worth discussing the future of 
> > > > > > the
> > > > > > reference agent(s), I feel we???ll be replicating a lot of work 
> > > > > > across
> > > > > > OVN/OVS/RYU(ofagent) and may be other plugins,
> > > > > >
> > > > > > I guess until OVN and it???s integration are ready we can???t stop, 
> > > > > > so
> > > > it makes
> > > > > > sense to keep development at our side, also having an independent
> > > > plugin
> > > > > > can help us iterate faster for new features, yet I expect that OVN
> > > > will be
> > > > > > more fluent at working with OVS and OpenFlow, as their designers 
> > > > > > have
> > > > > > a very deep knowledge of OVS under the hood, and it???s C. ;)
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > On 26/2/2015, at 7:57, Miguel ??ngel Ajo  > > > > > (mailto:majop...@redhat.com)> wrote:
> > > > > >
> > > > > > On Thursday, 26 de February de 2015 at 7:48, Miguel ??ngel Ajo 
> > > > > > wrote:
> > > > > >
> > > > > >  Inline comments follow after this, but I wanted to respond to Brian
> > > > > > questionwhich has been cut out:
> > > > > > We???re talking here of doing a preliminary analysis of the 
> > > > > > networking
> > > > > > performance,before writing any real code at neutron level.
> > > > > >
> > > > > > If that looks right, then we should go into a preliminary (and
> > > > orthogonal
> > > > > > to iptables/LB)implementation. At that moment we will be able to
> > > > examine
> > > > > > the scalability of the solutionin regards of switching openflow 
> > > > > > rules,
> > > > > > which is going to be severely affectedby the way we use to handle OF
> > > > rules
> > > > > > in the bridge:
> > > > > >* via OpenFlow, making the agent a ???real" OF controller, with 
> > > > > > the
> > > > > > current effort to use  the ryu framework plugin to do that.   * 
> > > > > > via
> > > > > > cmdline (would be alleviated with the current rootwrap work, but the
> > > > former
> > > > > > one would be preferred).
> > > > > > Also, ipset groups can be moved into conjunctive groups in OF 
> > > > > > (thanks
> > > > Ben
> > > > > > Pfaff for theexplanation, if you???re reading this ;-))
> > > > > > Best,Miguel ??ngel
> > > > > >
> > > > > >
> > > > > > On Wednesday, 25 de February de 2015 at 20:34, Tapio Tallgren wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > The RFC2544 with near zero packet loss is a pretty standard 
> > > > > > performance
> > > > > > benchmark. It is also used in the OPNFV project (
> > > > > >
> > > > https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases
> > > > > > ).
> > > > > >
> > > > > > Does this mean that OpenStack will have stateful firewalls (or 
> > > > > > security
> > > > > > groups)? Any other ideas planned, like ebtables type filtering?
> > > > > >
> > > > > > What I am proposing is in the terms of maintaining the statefulness 
> > > > > > we
> > > > > > have nowregards security groups (RELATED/ESTABLISHED connections are
> > > > > > allowed back on open ports) whil

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

[Akshik DBK]

Hi,
I did upload the Metadata generated by keystone by accessing 
https://115.112.68.53:5000/Shibboleth.sso/Metadata
have attached the copy of it, and did uploaded it to the 
http://testshib.org/register.html
Regards,Akshik

> Date: Fri, 27 Feb 2015 14:31:36 +0100
> From: marek.de...@cern.ch
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] Need help in configuring keystone
> 
> Hi again,
> 
> Did you upload Metadata generated by your Service Provider (Keystone) to 
> testshib Identity Providers?
> How did you generate /etc/shibboleth2/shibboleth2.xml file?
> 
> Did you read http://testshib.org/register.html ?
> 
> cheers,
> 
> Marek
> 
> __
> 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
  

115.112.68.53
Description: Binary data
__
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

[Marco Fargetta]

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 
>   

> __
> 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





smime.p7s
Description: S/MIME cryptographic signature
__
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/op

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle [metrics]

[Kyle Mestery]

On Fri, Feb 27, 2015 at 4:02 AM, Daniel P. Berrange 
wrote:

> On Fri, Feb 27, 2015 at 09:51:34AM +1100, Michael Still wrote:
> > On Fri, Feb 27, 2015 at 9:41 AM, Stefano Maffulli 
> wrote:
> >
> > > Does it make sense to purge old stuff regularly so we have a better
> > > overview? Or maybe we should chart a distribution of age of proposed
> > > changesets, too in order to get a better understanding of where the
> > > outliers are?
> >
> > Given the abandon of a review isn't binding (a proposer can easily
> > unabandon), I do think we should abandon more than we do now. The
> > problem at the moment being that its a manual process which isn't much
> > fun for the person doing the work.
> >
> > Another factor to consider here is that abandoned patches against bugs
> > make the bug look like someone is working on a fix, which probably
> > isn't the case.
> >
> > Nova has been trying some very specific things to try and address
> > these issues, and I think we're improving. Those things are:
> >
> > * specs
> > * priority features
>
> This increased level of process in Nova has actually made the negative
> effects of the 6 month cycle noticably worse on balance. If you aren't
> able to propose your feature in the right window of the dev cycle your
> chances of getting stuff merged has gone down significantly and the time
> before users are likely to see your feature has correspondingly gone up.
> Previously people could come along with simple features at the end of
> the cycle and we had the flexibility to be pragmmatic and review and
> approve them. Now we're lacking them that ability even if we have the
> spare review cycles to consider it. The processes adopted have merely
> made us more efficient at disappointing contributors earlier in the
> cycle. There's been no changes made that would  solve the bigger problem
> of the fact that Nova is far too large vs the size of the core review
> team, so we have a ongoing major bottleneck in our development. That,
> bottleneck combined with the length of the 6 month cycle is an ongoing
> disaster for our contributors.
>
> This is part of the reason we have moved to split Neutron into smaller,
bite-sized chunk repositories with sometimes overlapping core reviewer
teams. It's also why we're spinning out the backend logic from in-tree
drivers and plugins to allow faster iteration for the maintainers. Early
evidence indicates this has been succesful, we'll see how it looks once we
get into the Liberty development cycle.

For a bit more context, you can see the blog I wrote on this [1].

Thanks,
Kyle

[1]
http://www.siliconloons.com/posts/2015-02-26-scaling-openstack-neutron-development/

Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
> :|
>
> __
> 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] Ideas about Openstack Cinder for GSOC 2015

[Anne Gentle]

Hi Harry,
I don't see a cinder mentor listed but you could certainly contact the
Project Technical Lead for Cinder, Mike Perez, and see if he knows of a
mentor and possible project.
Anne

On Fri, Feb 27, 2015 at 3:50 AM, harryxiyou  wrote:

> Hi all,
>
> I cannot find the proper idea about Openstack Cinder for GSOC 2015
> here[1]. Could anyone please give me some clues?
>
> [1] https://wiki.openstack.org/wiki/GSoC2015
>
>
> Thanks, Harry
>
> __
> 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
>



-- 
Anne Gentle
annegen...@justwriteclick.com
__
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] Ideas about Openstack Cinder for GSOC 2015

[Davanum Srinivas]

Harry,

hop on to #openstack-gsoc and  #openstack-cinder as well.

-- dims

On Fri, Feb 27, 2015 at 9:26 AM, Anne Gentle
 wrote:
> Hi Harry,
> I don't see a cinder mentor listed but you could certainly contact the
> Project Technical Lead for Cinder, Mike Perez, and see if he knows of a
> mentor and possible project.
> Anne
>
> On Fri, Feb 27, 2015 at 3:50 AM, harryxiyou  wrote:
>>
>> Hi all,
>>
>> I cannot find the proper idea about Openstack Cinder for GSOC 2015
>> here[1]. Could anyone please give me some clues?
>>
>> [1] https://wiki.openstack.org/wiki/GSoC2015
>>
>>
>> Thanks, Harry
>>
>> __
>> 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
>
>
>
>
> --
> Anne Gentle
> annegen...@justwriteclick.com
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [Keystone] How to check admin authentication?

[Dmitry Tantsur]

Hi all!

This (presumably) pretty basic question tortures me for several months 
already, so I kindly seek for help here.


I'm working on a Flask-based service [1] and I'd like to use Keystone 
tokens for authentication. This is an admin-only API, so we need to 
check for an admin role. We ended up with code [2] first accessing 
Keystone with a given token and (configurable) admin tenant name, then 
checking 'admin' role. Things went well for a while.


Now I'm writing an Ironic driver accessing API of [1]. Pretty naively I 
was trying to use an Ironic service user credentials, that we use for 
accessing all other services. For TripleO-based installations it's a 
user with name 'ironic' and a special tenant 'service'. Here is where 
problems are. Our code perfectly authenticates a mere user (that has 
tenant 'admin'), but asks Ironic to go away.


We've spent some time researching documentation and keystone middleware 
source code, but didn't find any more clues. Neither did we find a way 
to use keystone middleware without rewriting half of project. What we 
need is 2 simple things in a simple Flask application:

1. validate a token
2. make sure it belongs to admin

I'll thankfully appreciate any ideas how to fix our situation.
Thanks in advance!

Dmitry.

[1] https://github.com/stackforge/ironic-discoverd
[2] 
https://github.com/stackforge/ironic-discoverd/blob/master/ironic_discoverd/utils.py#L50-L65


__
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] [Congress][Delegation] Initial workflow design

[ruby.krishnaswamy]

My first suggestion: why don’t we set up call together with Ramki, Yathi, Debo, 
as soon as possible ?

-  How to go forward concretely with the 8 steps for the PoC (details 
within each step),

oIncluding nova integration points

-  Identify “friction points” in the details above to resolve for  
beyond PoC


Tim: Where does the rest of the program originate?  I’m not saying the entire 
LP program is generated from the Datalog constraints; some of it is generated 
by the solver independent of the Datalog.  In the text, I gave the example of 
defining hMemUse[j].
Tim: The VM-placement engine does 2 things: (I) translates Datalog to LP and 
(ii) generates additional LP constraints.  (Both work items could leverage any 
constraints that are builtin to a specific solver, e.g. the solver-scheduler.  
The point is that there are 2 distinct, conceptual origins of the LP 
constraints: those that represent the Datalog and those that codify the domain.
Tim: Each domain-specific solver can do whatever it wants, so it’s not clear to 
me what the value of choosing a modeling language actually is—unless we want to 
build a library of common functionality that makes the construction of 
domain-specific engine (wrappers) easier.  I’d prefer to spend our energy 
understanding whether the proposed workflow/interface works for a couple of 
different domain-specific policy engines OR to flush this one out and build it.




ð  The value of choosing a modeling language is related to how “best to 
automate translations” from Datalog constraints (to LP)?

oWe can have look for one unique way of generation, and not, “some of it is 
generated by the VM-placement engine solver independent of the Datalog”.

oDatalog imposes most constraints (== policies)

oTwo constraints are not “policies”

§  A VM is allocated to only one host.

§  Host capacity is not exceeded.

· Over subscription

ð  Otherwise what was your suggestion?  As follows?

oUse framework (extend) the nova-solver-scheduler currently implements 
(itself using PuLP). This framework specifies an API to write constraints and 
cost functions (in a domain specific way). Modifying this framework:

§  To read data in from DSE

§  To obtain the cost function from Datalog (e.g. minimize Y[host1]…)

§  To obtain Datalog constraints (e.g. <75% memory allocation constraint for 
hosts of special zone)

oWe need to specify the “format” for this? It will likely to be a string of 
the form (?)

§  “hMemUse[0] – 0.75*hMemCap[0] < 100*y[0], “ Memory allocation constraint on 
Host 0“,









ð  From your doc (page 5, section 4)


warning(id) :-
nova:host(id, name, service, zone, memory_capacity),
legacy:special_zone(zone),
ceilometer:statistics(id, "memory", avg, count, duration,
durstart, durend, max, min, period, perstart, perend,
sum, unit),
avg > 0.75 * memory_capacity


Notice that this is a soft constraint, identified by the use of warning instead 
of error.  When compiling to LP, the VM-placement engine will attempt to 
minimize the number of rows in the warning table.  That is, for each possible 
row r it will create a variable Y[r] and assign it True if the row is a warning 
and False otherwise


The policy (warning) : when will it be evaluated? This should be done 
periodically? Then if the table has even one True entry, then the action should 
be to generate the LP, solve, activate the migrations etc.

ð  The “LP” cannot be generated when the VM-placement engine receives the 
policy snippet.


Ruby


De : Tim Hinrichs [mailto:thinri...@vmware.com]
Envoyé : jeudi 26 février 2015 19:17
À : OpenStack Development Mailing List (not for usage questions)
Objet : Re: [openstack-dev] [Congress][Delegation] Initial workflow design

Inline.

From: "ruby.krishnasw...@orange.com" 
mailto:ruby.krishnasw...@orange.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, February 25, 2015 at 8:53 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Congress][Delegation] Initial workflow design

Hi Tim, All,


1)  Step 3: The VM-placement engine is also a “datalog engine” . Right?

When policies are delegated:

when policies are inserted? When the VM-placement engine has already registered 
itself all policies are given to it?




“In our example, this would mean the domain-specific policy engine executes the 
following API call over the DSE”

ð  “domain-agnostic” ….



Done.


2)  Step 4:



Ok

But finally: if Congress will likely “delegate”



Not sure what you’re suggesting here.


3)  Step 5:  Compilation of subpolicy to LP in VM-placement engine



For the PoC, it is likely that the LP program ( in PuLP or some other ML) is 
*not* completely generated by compiler/translator.

ð  Right?

Where does the res

[openstack-dev] [sahara] Feedback on default-templates implementation

[Trevor McKay]

Hi Sahara folks,

  please checkout

https://review.openstack.org/#/c/159872/

and respond there in comments, or here on the email thread. We have some
things to figure out for this new CLI, and I want to make sure that we
make
sane choices and set a good precedent.

Once we have a consensus we can go back and extend the spec with more
detail and merge approved changes.  The original spec did not get into
this
kind of detail (because nobody had sat down and tried to do it :) )

The only other CLI we have at this point that touches Sahara components
(other than the python-saharaclient) is sahara-db-manage, but that uses
alembic commands to drive the database directly.  It doesn't really
touch
Sahara in any semantic way, it just drives migration.  It is blissfully
ignorant
of any Sahara object relationships and semantics outside of the table
definitions.

The default-templates CLI will be a new kind of tool, I believe, that we
don't
have yet. It will be tightly integrated with sahara-all and horizon. So
how it
is designed matters a lot imho.

Best,

Trevor

__
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] [DevStack] Adding PUBLIC_INTERFACE to OVS_PHYSICAL_BRIDGE by default

[Kyle Mestery]

On Thu, Feb 26, 2015 at 9:12 AM, Sean M. Collins  wrote:

> Hi,
>
> I have proposed a recent patch, that when using Neutron as the
> networking component in DevStack, the PUBLIC_INTERFACE that has been set
> should automatically be added to the OVS_PHYSICAL_BRIDGE.
>
> https://review.openstack.org/#/c/158424/
>
> Thanks for taking this work on Sean!


> There are a couple motivations for this patch. The first is that in my
> Vagrant project, I've been using chef[0] to attach the public interface
> to the OVS bridge, so that when a floating IP is NAT'd traffic flows
> from the interface attached to the router where the floating IP range is
> advertised, into the L3 agent.
>
> This is basically the same step documented for setting up a production
> Neutron install[1]. The fact that we are not doing this for DevStack
> installations is an oversight that should be corrected.
>
> The second motivation for this patch is to help transition DevStack
> users from Nova-Networking. Recently, we tried to move Neutron to being
> the default, but the lack of code to configure DevStack on machines with
> a single network interface caused a lot of issues and had to be
> reverted.
>
> In cases where DevStack is being run on a developer machine, where only
> one physical interface is present, DevStack will remove the IP address
> that has been assigned to the machine and adds it to the
> OVS_PHSYICAL_BRIDGE, so that the machine as well as the OpenStack APIs
> are reachable, while also allowing the usage of floating IPs.
>

This all sounds good to me. I'll review the patch in more detail and
provide specific comments there.


> An example local.conf shows how this is configured. On this machine, we
> have a router that advertises the 192.168.27.0/24 prefix. The DevStack
> machine will be assigned 192.168.27.2 from DHCP, and the remaining IPs
> in the /24 will be used for floating IP addresses.
>
> HOST_IP=192.168.27.2
> FLAT_INTERFACE=eth0
> PUBLIC_INTERFACE=eth0
> FIXED_RANGE=10.0.0.0/24
> FLOATING_RANGE=192.168.27.0/24
> PUBLIC_NETWORK_GATEWAY=192.168.27.1
>
> disable_service n-net
> enable_service q-svc
> enable_service q-agt
> enable_service q-dhcp
> enable_service q-meta
> enable_service q-l3
>
> Q_USE_SECGROUP=True
> ENABLE_TENANT_VLANS=True
> TENANT_VLAN_RANGE=3001:4000
> OVS_PHYSICAL_BRIDGE=br-ex
> Q_L3_ENABLED=True
> Q_FLOATING_ALLOCATION_POOL=start=192.168.27.3,end=192.168.27.254
>
> I'd be interested in feedback from everyone about my thought process,
> code, and if I'm on the right track.
>
> [0]:
> https://github.com/sc68cal/chef-devstack/blob/master/recipes/default.rb#L50
> [1]:
> http://docs.openstack.org/admin-guide-cloud/content/install_neutron-l3.html
> [2]: https://review.openstack.org/#/c/153208/
>
> --
> Sean M. Collins
>
> __
> 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] [neutron][oslo] plan till end-of-Kilo

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Some update on oslo/neutron patches in Kilo.

On 01/20/2015 03:17 PM, Kyle Mestery wrote:
> 
> 
> On Mon, Jan 19, 2015 at 10:54 AM, Ihar Hrachyshka
> mailto:ihrac...@redhat.com>> wrote:
> 
> Hi Kyle/all,
> 
> (we were going to walk thru that on Mon, but since US is on
> vacation today, sending it via email to openstack-dev@.)
> 
> Great, thanks Ihar!
> 
> 
> So I've talked to Doug Hellmann from oslo, and here is what we
> have in our oslo queue to consider:
> 
> 1. minor oslo.concurrency cleanup for *aas repos (we need to drop 
> lockutils-wrapper usage now that base test class sets lockutils 
> fixture);

In review:
https://review.openstack.org/#/q/I2a82504ad19f6daddd24a3c2254e8feefc9399ca,n,z

(vpnaas is already fixed)

> 2. migration to namespace-less oslo libraries (this is blocked by 
> pending oslo.messaging release scheduled this week, will revive 
> patches for all four branches the end of the week) [1];

Done.

> 3. oslo/kilo-2: graduation of oslo.policy;

For this one, some obstacles were found. Specifically, neutron uses
symbols from the module that are now considered private by oslo team.
Neutron implements sub-attribute checks by using private API, so to
migrate to the library, we'll need to move the sub-attr feature to the
library first, and this will require going thru proper oslo-specs
process. So not in this cycle.

Also of potential interest in Kilo scope is oslo.log that was released
recently. I have patches for all four repos. If we think it's still a
good time to do the switch to it, then I'm happy to see reviews at:

https://review.openstack.org/#/q/I310e059a815377579de6bb2aa204de168e72571e,n,z

Cheers,
/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU8JMCAAoJEC5aWaUY1u57iKQH/jz1cUhJJT2hhie5E1oQcInV
9I14wL630HE0jiC7h5Y5P2Zt4psB0+9JLyEBp4dt/J+YySpU0ztwlCp8q8lTJcjF
KRgM0nlXmN5UOxu3xhEyP1xgGwTGkjzDxLc28vj70W/sFppj/D5SDfIjgm7L7c55
aVThT3aiI4f7sY4dyzoPQr9oQXWZVuAWvIUuyI1gtvd9J11gJF259wV/GKPQeczj
cR31YThP/wf3a38uHDo9wJiXCRUIJLWFDZoLvw63torY+kb5y/T3YsQ+yBR3+tT+
QRtu6v/BguYXqCiRY1UoKLx29+dsxykP2/nchtzE9DsXwZdCWTIVpxvZi/Bh9d8=
=tze1
-END PGP SIGNATURE-

__
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] [Keystone] How to check admin authentication?

[Dolph Mathews]

On Fri, Feb 27, 2015 at 8:39 AM, Dmitry Tantsur  wrote:

> Hi all!
>
> This (presumably) pretty basic question tortures me for several months
> already, so I kindly seek for help here.
>
> I'm working on a Flask-based service [1] and I'd like to use Keystone
> tokens for authentication. This is an admin-only API, so we need to check
> for an admin role. We ended up with code [2] first accessing Keystone with
> a given token and (configurable) admin tenant name, then checking 'admin'
> role. Things went well for a while.
>
> Now I'm writing an Ironic driver accessing API of [1]. Pretty naively I
> was trying to use an Ironic service user credentials, that we use for
> accessing all other services. For TripleO-based installations it's a user
> with name 'ironic' and a special tenant 'service'. Here is where problems
> are. Our code perfectly authenticates a mere user (that has tenant
> 'admin'), but asks Ironic to go away.
>
> We've spent some time researching documentation and keystone middleware
> source code, but didn't find any more clues. Neither did we find a way to
> use keystone middleware without rewriting half of project. What we need is
> 2 simple things in a simple Flask application:
> 1. validate a token
> 2. make sure it belongs to admin
>

I'm not really clear on what problem you're having, because I'm not sure if
you care about an "admin" username, "admin" tenant name, or "admin" role
name. If you're implementing RBAC, you only really need to care about the
user have an "admin" role in their list of roles.

You can wrap your flask application with a configured instance of
auth_token middleware; this is about the simplest way to do it, and this
also demos the environment variables exposed to your application that you
can use to validation authorization:


https://github.com/dolph/keystone-deploy/blob/master/playbooks/roles/http/templates/echo.py#L33-L41


>
> I'll thankfully appreciate any ideas how to fix our situation.
> Thanks in advance!
>
> Dmitry.
>
> [1] https://github.com/stackforge/ironic-discoverd
> [2] https://github.com/stackforge/ironic-discoverd/blob/master/
> ironic_discoverd/utils.py#L50-L65
>
> __
> 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

[openstack-dev] [nova] Nova compute will delete all your instances if you change its hostname

[Matthew Booth]

Gary Kotton originally posted this bug against the VMware driver:

https://bugs.launchpad.net/nova/+bug/1419785

I posted a proposed patch to fix this here:

https://review.openstack.org/#/c/158269/1

However, Dan Smith pointed out that the bug can actually be triggered
against any driver in a manner not addressed by the above patch alone. I
have confirmed this against a libvirt setup as follows:

1. Create some instances
2. Shutdown n-cpu
3. Change hostname
4. Restart n-cpu

Nova compute will delete all instances in libvirt, but continue to
report them as ACTIVE and Running.

There are 2 parts to this issue:

1. _destroy_evacuated_instances() should do a better job of sanity
checking before performing such a drastic action.

2. The underlying issue is the definition and use of instance.host,
instance.node, compute_node.host and compute_node.hypervisor_hostname.

(1) is belt and braces. It's very important, but I want to focus on (2)
here. Instantly you'll notice some inconsistent naming here, so to clarify:

* instance.host == compute_node.host == Nova compute's 'host' value.
* instance.node == compute_node.hypervisor_hostname == an identifier
which represents a hypervisor.

Architecturally, I'd argue that these mean:

* Host: A Nova communication endpoint for a hypervisor.
* Hypervisor: The physical location of a VM.

Note that in the above case the libvirt driver changed the hypervisor
identifier despite the fact that the hypervisor had not changed, only
its communication endpoint. I propose the following:

* ComputeNode describes 1 hypervisor.
* ComputeNode maps 1 hypervisor to 1 compute host.
* A ComputeNode is identified by a hypervisor_id.
* hypervisor_id represents the physical location of running VMs,
independent of a compute host.

We've renamed compute_node.hypervisor_hostname to
compute_node.hypervisor_id. This resolves some confusion, because it
asserts that the identity of the hypervisor is tied to the data
describing VMs, not the host which is running it. In fact, for the
VMware and Ironic drivers it has never been a hostname.

VMware[1] and Ironic don't require any changes here. Other drivers will
need to be modified so that get_available_nodes() returns a persistent
value rather than just the hostname. A reasonable default implementation
of this would be to write a uuid to a file which lives with VM data and
return its contents. If the hypervisor has a native concept of a
globally unique identifier, that should be used instead.

ComputeNode.hypervisor_id is unique. The hypervisor is unique (there is
physically only 1 of it) so it does not make sense to have multiple
representations of it and its associated resources.

An Instance's location is its hypervisor, whereever that may be, so
Instance.host could be removed. This isn't strictly necessary, but it is
redundant as the communication endpoint is available via ComputeNode. If
we wanted to support the possibility of changing a communication
endpoint at some point, it would also make that operation trivial.
Thinking blue sky, it would also open the future possibility for
multiple communication endpoints for a single hypervisor.

There is a data migration issue associated with changing a driver's
reported hypervisor id. The bug linked below fudges it, but if we were
doing it for all drivers I believe it could be handled efficiently by
passing the instance list already collected by ComputeManager.init_host
to the driver at startup.

My proposed patch above fixes a potentially severe issue for users of
the VMware and Ironic drivers. In conjunction with a move to a
persistent hypervisor id for other drivers, it also fixes the related
issue described above across the board. I would like to go forward with
my proposed fix as it has an immediate benefit, and I'm happy to work on
the persistent hypervisor id for other drivers.

Matt

[1] Modulo bugs: https://review.openstack.org/#/c/159481/
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

__
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] [tempest] UUID Tagging Requirement and "Big Bang" Patch

[Chris Hoge]

This work has landed. New tests will now be gated against existence of an 
idempotent_id.
If you have open submissions to Tempest there’s a good possibility you’ll have 
to rebase.

-Chris

> On Feb 26, 2015, at 2:30 PM, Chris Hoge  
> wrote:
> 
> Update on this:
> 
> The tools for checking for and adding UUIDs has been completed and reviewed.
> 
> https://review.openstack.org/#/c/157273 
> 
> 
> A new patch has been sent up that adds UUIDs to all tests
> 
> https://review.openstack.org/#/c/159633 
> 
> 
> Note that after discussion with the openstack-qa team the decorator has
> changed to be of the form
> 
> @test.idempotent_id('12345678-1234-5678-1234-123456789abc’)
> 
> Once the second patch lands you will most certainly need to rebase your work
> and include ids in all new tests. When refactoring tests, please preserve the
> id value so that various projects (Defcore, Refstack, Rally) can track the 
> actual
> location of tests for capability testing.
> 
> Thanks,
> Chris Hoge
> Interop Engineer
> OpenStack Foundation
> 
>> On Feb 22, 2015, at 11:47 PM, Chris Hoge > > wrote:
>> 
>> Once the gate settles down this week I’ll be sending up a major 
>> “big bang” patch to Tempest that will tag all of the tests with unique
>> identifiers, implementing this spec: 
>> 
>> https://github.com/openstack/qa-specs/blob/master/specs/meta-data-and-uuid-for-tests.rst
>>  
>> 
>> 
>> The work in progress is here, and includes a change to the gate that
>> every test developer should be aware of.
>> 
>> https://review.openstack.org/#/c/157273/
>> 
>> All tests will now require a UUID metadata identifier, generated from the
>> uuid.uuid4 function. The form of the identifier is a decorator like:
>> 
>> @test.meta(uuid='12345678-1234-5678-1234-567812345678')
>> 
>> To aid in hacking rules, the @test.meta decorator must be directly before the
>> function definition and after the @test.services decorator, which itself
>> must appear after all other decorators.
>> 
>> The gate will now require that every test have a uuid that is indeed
>> unique.
>> 
>> This work is meant to give a stable point of reference to tests that will
>> persist through test refactoring and moving.
>> 
>> Thanks,
>> Chris Hoge
>> Interop Engineer
>> OpenStack Foundation
> 
> __
> 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] [nova] Nova compute will delete all your instances if you change its hostname

[Dan Smith]

Did we really need another top-level thread for this?

> 1. _destroy_evacuated_instances() should do a better job of sanity 
> checking before performing such a drastic action.

I agree, and no amount of hostname checking will actually address this
problem. If we don't have a record of an evacuate having been scheduled
for the host, then there is no legitmate reason to delete data, IMHO.

> 2. The underlying issue is the definition and use of instance.host, 
> instance.node, compute_node.host and compute_node.hypervisor_hostname.

I disagree. I think the underlying issues are:

1. Evacuate assumes too much
2. Nova has a model of one compute per hypervisor and we have some
   drivers that make it easy to violate that in dangerous ways, and
   which don't do their due diligence to avoid catastrophe.

> Note that in the above case the libvirt driver changed the hypervisor
> identifier despite the fact that the hypervisor had not changed, only
> its communication endpoint.

I'd argue they're one and the same, and that's just fine. We just
shouldn't erroneously delete things when that happens unexpectedly.

> VMware[1] and Ironic don't require any changes here.

But they're broken! If they are managing things from another point that
can be duplicated and they don't provide assurances that it's not being
done twice, then that's a problem. I (and others) have argued that
nova's model is one compute per hypervisor. I don't think it should be
up to nova to ensure that, I think it should be up to the driver.

Nova needs to stop deleting things based on cheap guessing. However, if
two hypervisor drivers claim they're different and that they have
deleted running instances (which is what is going on here), I have
little sympathy.

> Other drivers will need to be modified so that get_available_nodes() 
> returns a persistent value rather than just the hostname.

-1 on making the non-problematic drivers (potentially) maintain state
and leaving the problematic ones unchanged.

> A reasonable default implementation of this would be to write a uuid
> to a file which lives with VM data and return its contents. If the 
> hypervisor has a native concept of a globally unique identifier,
> that should be used instead.

Those drivers shouldn't have to maintain state. And they already have a
unique identifier: the hostname.

--Dan



signature.asc
Description: OpenPGP digital signature
__
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] [nova] Nova compute will delete all your instances if you change its hostname

[Daniel P. Berrange]

On Fri, Feb 27, 2015 at 04:24:36PM +, Matthew Booth wrote:
> Gary Kotton originally posted this bug against the VMware driver:
> 
> https://bugs.launchpad.net/nova/+bug/1419785
> 
> I posted a proposed patch to fix this here:
> 
> https://review.openstack.org/#/c/158269/1
> 
> However, Dan Smith pointed out that the bug can actually be triggered
> against any driver in a manner not addressed by the above patch alone. I
> have confirmed this against a libvirt setup as follows:
> 
> 1. Create some instances
> 2. Shutdown n-cpu
> 3. Change hostname
> 4. Restart n-cpu
> 
> Nova compute will delete all instances in libvirt, but continue to
> report them as ACTIVE and Running.
> 
> There are 2 parts to this issue:
> 
> 1. _destroy_evacuated_instances() should do a better job of sanity
> checking before performing such a drastic action.
> 
> 2. The underlying issue is the definition and use of instance.host,
> instance.node, compute_node.host and compute_node.hypervisor_hostname.
> 
> (1) is belt and braces. It's very important, but I want to focus on (2)
> here. Instantly you'll notice some inconsistent naming here, so to clarify:
> 
> * instance.host == compute_node.host == Nova compute's 'host' value.
> * instance.node == compute_node.hypervisor_hostname == an identifier
> which represents a hypervisor.
> 
> Architecturally, I'd argue that these mean:
> 
> * Host: A Nova communication endpoint for a hypervisor.
> * Hypervisor: The physical location of a VM.
> 
> Note that in the above case the libvirt driver changed the hypervisor
> identifier despite the fact that the hypervisor had not changed, only
> its communication endpoint. I propose the following:
> 
> * ComputeNode describes 1 hypervisor.
> * ComputeNode maps 1 hypervisor to 1 compute host.
> * A ComputeNode is identified by a hypervisor_id.
> * hypervisor_id represents the physical location of running VMs,
> independent of a compute host.
> 
> We've renamed compute_node.hypervisor_hostname to
> compute_node.hypervisor_id. This resolves some confusion, because it
> asserts that the identity of the hypervisor is tied to the data
> describing VMs, not the host which is running it. In fact, for the
> VMware and Ironic drivers it has never been a hostname.
> 
> VMware[1] and Ironic don't require any changes here. Other drivers will
> need to be modified so that get_available_nodes() returns a persistent
> value rather than just the hostname. A reasonable default implementation
> of this would be to write a uuid to a file which lives with VM data and
> return its contents. If the hypervisor has a native concept of a
> globally unique identifier, that should be used instead.

I don't think there's any need to write state in that way. Every hypervisor
I've come across has a way to report a gloally unique identifier, which is
typically the host UUID coming from the BIOS, or some equivalent. For libvirt
you can get the host UUID from the capabilities XML, so we could pretty
easily handle that.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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,
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 
>   
 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.op

Re: [openstack-dev] [devstack] [Cinder-GlusterFS CI] centos7 gate job abrupt failures

[Deepak Shetty]

On Fri, Feb 27, 2015 at 4:02 PM, Deepak Shetty  wrote:

>
>
> On Wed, Feb 25, 2015 at 11:48 PM, Deepak Shetty 
> wrote:
>
>>
>>
>> On Wed, Feb 25, 2015 at 8:42 PM, Deepak Shetty 
>> wrote:
>>
>>>
>>>
>>> On Wed, Feb 25, 2015 at 6:34 PM, Jeremy Stanley 
>>> wrote:
>>>
 On 2015-02-25 17:02:34 +0530 (+0530), Deepak Shetty wrote:
 [...]
 > Run 2) We removed glusterfs backend, so Cinder was configured with
 > the default storage backend i.e. LVM. We re-created the OOM here
 > too
 >
 > So that proves that glusterfs doesn't cause it, as its happening
 > without glusterfs too.

 Well, if you re-ran the job on the same VM then the second result is
 potentially contaminated. Luckily this hypothesis can be confirmed
 by running the second test on a fresh VM in Rackspace.

>>>
>>> Maybe true, but we did the same on hpcloud provider VM too and both time
>>> it ran successfully with glusterfs as the cinder backend. Also before
>>> starting
>>> the 2nd run, we did unstack and saw that free memory did go back to 5G+
>>> and then re-invoked your script, I believe the contamination could
>>> result in some
>>> additional testcase failures (which we did see) but shouldn't be related
>>> to
>>> whether system can OOM or not, since thats a runtime thing.
>>>
>>> I see that the VM is up again. We will execute the 2nd run afresh now
>>> and update
>>> here.
>>>
>>
>> Ran tempest with configured with default backend i.e. LVM and was able to
>> recreate
>> the OOM issue, so running tempest without gluster against a fresh VM
>> reliably
>> recreates the OOM issue, snip below from syslog.
>>
>> Feb 25 16:58:37 devstack-centos7-rax-dfw-979654 kernel: glance-api
>> invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
>>
>> Had a discussion with clarkb on IRC and given that F20 is discontinued,
>> F21 has issues with tempest (under debug by ianw)
>> and centos7 also has issues on rax (as evident from this thread), the
>> only option left is to go with ubuntu based CI job, which
>> BharatK is working on now.
>>
>
> Quick Update:
>
> Cinder-GlusterFS CI job on ubuntu was added (
> https://review.openstack.org/159217)
>
> We ran it 3 times against our stackforge repo patch @
> https://review.openstack.org/159711
> and it works fine (2 testcase failures, which are expected and we're
> working towards fixing them)
>
> For the logs of the 3 experimental runs, look @
>
> http://logs.openstack.org/11/159711/1/experimental/gate-tempest-dsvm-full-glusterfs/
>
> Of the 3 jobs, 1 was schedued on rax and 2 on hpcloud, so its working
> nicely across
> the different cloud providers.
>

Clarkb, Fungi,
  Given that the ubuntu job is stable, I would like to propose to add it as
experimental to the
openstack cinder while we work on fixing the 2 failed test cases in parallel

thanx,
deepak
__
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] [nova] Nova compute will delete all your instances if you change its hostname

[Daniel P. Berrange]

On Fri, Feb 27, 2015 at 08:57:53AM -0800, Dan Smith wrote:
> > Note that in the above case the libvirt driver changed the hypervisor
> > identifier despite the fact that the hypervisor had not changed, only
> > its communication endpoint.
> 
> I'd argue they're one and the same, and that's just fine. We just
> shouldn't erroneously delete things when that happens unexpectedly.

[snip]

> > A reasonable default implementation of this would be to write a uuid
> > to a file which lives with VM data and return its contents. If the 
> > hypervisor has a native concept of a globally unique identifier,
> > that should be used instead.
> 
> Those drivers shouldn't have to maintain state. And they already have a
> unique identifier: the hostname.

The hostname is a unique identifier, however, it isn't a /stable/ unique
identifier because it is determined at the whim of the administrator. We
could instead use the host UUID which is both unique and stable. That
would avoid nova having to worry about administrator reconfigurations in
this respect.  IMHO if we can make nova more robust against admin changes
like this, it'd be a good thing.  I agree that we don't want to maintain
state and indeed this is not needed - every HV I know of has a concept of
a host UUID it can report that'd do the job just fine.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] [all] creating a unified developer reference manual

[Ben Nemec]

On 02/27/2015 03:54 AM, Thierry Carrez wrote:
> Doug Hellmann wrote:
>> Maybe some of the folks in the meeting who felt more strongly that it
>> should be a separate document can respond with their thoughts?
> 
> I don't feel very strongly and could survive this landing in
> openstack-specs. My objection was the following:
> 
> - Specs are for designing the solution and implementation plan to a
> specific problem. They are mainly used by developers and reviewers
> during implementation as a clear reference rationale for change and
> approved plan. Once they are fully implemented, they are kept for
> history purpose, not for constant reference.
> 
> - Guidelines/developer doc are for all developers (old and new) to
> converge on best practices on topics that are not directly implemented
> as hacking rules. They are constantly used by everyone (not just
> developers/reviewers of a given feature) and never become "history".
> 
> Putting guidelines doc in the middle of specs makes it a bit less
> discoverable imho, especially by our new developers. It's harder to
> determine which are still current and you should read. An "OpenStack
> developer doc" sounds like a much better entry point.
> 
> That said, the devil is in the details, and some efforts start as specs
> (for existing code to catch up with the recommendation) and become
> guidelines (for future code being written). That is the case of the log
> levels spec: it is both a spec and a guideline. Personally I wouldn't
> object if that was posted in both areas, or if the relevant pieces were
> copied, once the current code has caught up, from the spec to a dev
> guideline.
> 
> In the eventlet case, it's only a set of best practices / guidelines:
> there is no specific problem to solve, no catch-up plan for existing
> code to implement. Only a collection of recommendations if you get to
> write future eventlet-based code. Those won't start or end. Which is why
> I think it should go straight to a developer doc.
> 

Well, this whole spec arose because we found out there was existing code
that was doing bad things with eventlet monkey patching that needed to
be fixed.  The specific problem is actually being worked concurrently
with the spec because everyone involved has agreed on a solution, which
became one of the guidelines in the spec.  I'd be surprised if there
aren't other projects that need similar changes to be in line with the
new recommendations though.  I'd hope that future projects will follow
the guidelines, but they were actually written for the purpose of
eliminating as many potential eventlet gotchas in our _current_ code as
possible.  Coming up with a specific list of changes needed is tough
until we have agreement on the best practices though, which is why the
first work item is a somewhat vague "audit and fix all the things" point.

Personally, I would expect most best practice/guideline type specs to be
similar.  Nobody's going to take the time to write up a spec about
something everyone's already doing - they're going to do it because one
or a few projects have found something that works well and they think
everyone should be doing it.  So I think your point about most of these
things moving from spec to guideline throughout their lifetime is spot
on, I'm just wondering if it's worth complicating the workflow for that
process.  Herding the cats for something big like the log guidelines is
hard enough without requiring two separate documents for the immediate
work and the long-term information.

That said, I agree with the points about publishing this stuff under a
developer reference doc rather than specs, and if that can't be done in
a single repo maybe we do have to split.  I'd still prefer to keep it
all in one repo though - moving a doc between directories is a lot
simpler than moving it between repos (and also doesn't lose any previous
discussion in Gerrit).

-Ben

__
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] [nova] Nova compute will delete all your instances if you change its hostname

[Dan Smith]

> The hostname is a unique identifier, however, it isn't a /stable/ 
> unique identifier because it is determined at the whim of the 
> administrator.

Honestly, I think it's as stable as the administrator wants it to be. At
the level of automation that any reasonable deployment will be running,
I think it's the right thing to use, personally.

> We could instead use the host UUID which is both unique and stable. 
> That would avoid nova having to worry about administrator 
> reconfigurations in this respect.

Assuming you're talking about the DMI UUID, this is a problem if I have
a failing DIMM, swap the disks out of a box into an identical box (which
will have a different UUID) and reboot. If not, then it's an OS-level
UUID, which is persisted state, and which would change if I re-install
my boxes (puppet run) and expect my instances to remain because I
persist images, config, etc.

> IMHO if we can make nova more robust against admin changes like this,
> it'd be a good thing.  I agree that we don't want to maintain state
> and indeed this is not needed - every HV I know of has a concept of a
> host UUID it can report that'd do the job just fine.

The hostname is the unique identifier that is under the control of the
administrator. It's easily adjustable if need-be, it's as static as it
needs to be, and it's well-understood.

--Dan



signature.asc
Description: OpenPGP digital signature
__
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] [Congress][Delegation] Initial workflow design

[Yathiraj Udupi (yudupi)]

Hi,

It will be good to simplify the PoC scenario.  In terms of policies and other 
constraints related to VM Placement,  I guess we agree that not all 
policies/constraints have to originate from the policy framework such as 
Congress.  The existing placement engine logic that is present in the default 
Nova scheduler or say the Nova solver scheduler will be adding its own set of 
constraints to the placement calculations.

My idea would be make the Nova placement engine,  (for e.g., solver scheduler) 
talk to Congress to get the Datalog rules / translated LP constraints, based on 
the defined policies pertaining to a particular tenant/user.  This of course 
needs to be worked out in terms of translation logic, constraint 
specifications, etc.  Also, this workflow will be part of the 
scheduling/Placement workflow as part of the Nova boot instance API call (for 
the initial placement).

As the next phase, for migrations scenario, Congress can periodically trigger a 
check, if any of the violations/warnings are triggered, (corresponding tables 
getting populated, as you show in your example),  if so, then trigger 
migrations, which will have to go through another round of placement decisions  
for figuring out the best destinations, without violating the policies and 
other existing constraints.

Happy to discuss more and simplify a PoC scenario.

Thanks,
Yathi.


On 2/27/15, 6:40 AM, 
"ruby.krishnasw...@orange.com" 
mailto:ruby.krishnasw...@orange.com>> wrote:

My first suggestion: why don’t we set up call together with Ramki, Yathi, Debo, 
as soon as possible ?

-  How to go forward concretely with the 8 steps for the PoC (details 
within each step),

oIncluding nova integration points

-  Identify “friction points” in the details above to resolve for  
beyond PoC


Tim: Where does the rest of the program originate?  I’m not saying the entire 
LP program is generated from the Datalog constraints; some of it is generated 
by the solver independent of the Datalog.  In the text, I gave the example of 
defining hMemUse[j].
Tim: The VM-placement engine does 2 things: (I) translates Datalog to LP and 
(ii) generates additional LP constraints.  (Both work items could leverage any 
constraints that are builtin to a specific solver, e.g. the solver-scheduler.  
The point is that there are 2 distinct, conceptual origins of the LP 
constraints: those that represent the Datalog and those that codify the domain.
Tim: Each domain-specific solver can do whatever it wants, so it’s not clear to 
me what the value of choosing a modeling language actually is—unless we want to 
build a library of common functionality that makes the construction of 
domain-specific engine (wrappers) easier.  I’d prefer to spend our energy 
understanding whether the proposed workflow/interface works for a couple of 
different domain-specific policy engines OR to flush this one out and build it.




ð  The value of choosing a modeling language is related to how “best to 
automate translations” from Datalog constraints (to LP)?

oWe can have look for one unique way of generation, and not, “some of it is 
generated by the VM-placement engine solver independent of the Datalog”.

oDatalog imposes most constraints (== policies)

oTwo constraints are not “policies”

§  A VM is allocated to only one host.

§  Host capacity is not exceeded.

· Over subscription

ð  Otherwise what was your suggestion?  As follows?

oUse framework (extend) the nova-solver-scheduler currently implements 
(itself using PuLP). This framework specifies an API to write constraints and 
cost functions (in a domain specific way). Modifying this framework:

§  To read data in from DSE

§  To obtain the cost function from Datalog (e.g. minimize Y[host1]…)

§  To obtain Datalog constraints (e.g. <75% memory allocation constraint for 
hosts of special zone)

oWe need to specify the “format” for this? It will likely to be a string of 
the form (?)

§  “hMemUse[0] – 0.75*hMemCap[0] < 100*y[0], “ Memory allocation constraint on 
Host 0“,









ð  From your doc (page 5, section 4)


warning(id) :-
nova:host(id, name, service, zone, memory_capacity),
legacy:special_zone(zone),
ceilometer:statistics(id, "memory", avg, count, duration,
durstart, durend, max, min, period, perstart, perend,
sum, unit),
avg > 0.75 * memory_capacity


Notice that this is a soft constraint, identified by the use of warning instead 
of error.  When compiling to LP, the VM-placement engine will attempt to 
minimize the number of rows in the warning table.  That is, for each possible 
row r it will create a variable Y[r] and assign it True if the row is a warning 
and False otherwise


The policy (warning) : when will it be evaluated? This should be done 
periodically? Then if the table has even one True entry, then the action should 
be to generate the LP, solve, activate the migrations etc.

ð  The “LP” cann

Re: [openstack-dev] [Congress][Delegation] Initial workflow design

[Ramki Krishnan]

@Ramki:  VM size, could we say that only the in-memory state is migrated? The 
VM’s disk resides on a network-attached storage. Disk will not be migrated.

That is exactly right Ruby.

Thanks,
Ramki

From: ruby.krishnasw...@orange.com [mailto:ruby.krishnasw...@orange.com]
Sent: Thursday, February 26, 2015 11:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress][Delegation] Initial workflow design

Tim:“So you’re saying we won’t have fresh enough data to make policy decisions? 
 If the data changes so frequently that we can’t get an accurate view, then I’m 
guessing we shouldn’t be migrating based on that data anyway.”

Ramki: We have to keep in mind that VM migration could be an expensive 
operation depending on the size of the VM and various other factors; such an 
operation cannot be performed frequently.

I do not know at what frequency data may change.
@Ramki:  VM size, could we say that only the in-memory state is migrated? The 
VM’s disk resides on a network-attached storage. Disk will not be migrated.
In any case I agree that migration (probably) cannot be performed frequently.



De : Tim Hinrichs [mailto:thinri...@vmware.com]
Envoyé : jeudi 26 février 2015 19:17
À : OpenStack Development Mailing List (not for usage questions)
Objet : Re: [openstack-dev] [Congress][Delegation] Initial workflow design

Inline.

From: "ruby.krishnasw...@orange.com" 
mailto:ruby.krishnasw...@orange.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, February 25, 2015 at 8:53 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Congress][Delegation] Initial workflow design

Hi Tim, All,


1) Step 3: The VM-placement engine is also a “datalog engine” . Right?

When policies are delegated:

when policies are inserted? When the VM-placement engine has already registered 
itself all policies are given to it?




“In our example, this would mean the domain-specific policy engine executes the 
following API call over the DSE”

ð “domain-agnostic” ….



Done.


2) Step 4:



Ok

But finally: if Congress will likely “delegate”



Not sure what you’re suggesting here.


3) Step 5:  Compilation of subpolicy to LP in VM-placement engine



For the PoC, it is likely that the LP program ( in PuLP or some other ML) is 
*not* completely generated by compiler/translator.

ð Right?

Where does the rest of the program originate?  I’m not saying the entire LP 
program is generated from the Datalog constraints; some of it is generated by 
the solver independent of the Datalog.  In the text, I gave the example of 
defining hMemUse[j].


 You also indicate that some category of constraints (“the LP solver 
doesn’t know what the relationship between assign[i][j], hMemUse[j], and 
vMemUse[i] actually is, so the VM-placement engine must also include 
constraints”) .
 These constraints must be “explicitly” written?  (e.g. max_ram_allocation 
etc that are constraints used in the solver-scheduler’s package).

The VM-placement engine does 2 things: (I) translates Datalog to LP and (ii) 
generates additional LP constraints.  (Both work items could leverage any 
constraints that are builtin to a specific solver, e.g. the solver-scheduler.  
The point is that there are 2 distinct, conceptual origins of the LP 
constraints: those that represent the Datalog and those that codify the domain.



 So what “parts” will be generated:
Cost function :
Constraint from Policy : memory usage < 75%

 Then the rest should be “filled” up?

 Could we convene on an intermediary “modeling language”?
@Yathi: do you think we could use some thing like AMPL ? Is this 
proprietary?


A detail: the example “Y[host1] = hMemUse[host1] > 0.75 * hMemCap[host1]”


ð To be changed to a linear form (mi – Mi > 0 then Yi = 1 else Yi = 0) so 
something like (mi – Mi) < 100 yi

Each domain-specific solver can do whatever it wants, so it’s not clear to me 
what the value of choosing a modeling language actually is—unless we want to 
build a library of common functionality that makes the construction of 
domain-specific engine (wrappers) easier.  I’d prefer to spend our energy 
understanding whether the proposed workflow/interface works for a couple of 
different domain-specific policy engines OR to flush this one out and build it.



4) Step 6: This is completely internal to the VM-placement engine (and we 
could say this is “transparent” to Congress)



We should allow configuration of a solver (this itself could be a policy ☺ )

How to invoke the solver API ?



The domain-specific placement engine could send out to DSE (action_handler: 
data)?



I had always envisioned the solver being just a library of code—not an entity 
that

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle [metrics]

[Stefano Maffulli]

On Thu, 2015-02-26 at 16:44 -0800, James E. Blair wrote:
> It is good to recognize the impact of this, however, I would suggest
> that if having open changes that are not "actively being worked" is a
> problem for statistics,

I don't think it's a problem for the statistics per se. The reports are
only a tool to analyze complex phenomenons and translate them into
manageable items. In fact, we keep adding more stats as we go because
every chart and table leaves us with more questions.

>  let's change the statistics calculation.  Please do not abandon the
> work of contributors to improve the appearance of
> these metrics.  Instead, simply decide what criteria you think should
> apply and exclude those changes from your calculations.

I'm currently thinking that it would be informative to plot the
distribution of the efficiency metrics, instead of simply come up with a
filter to ignore long standing changes with slow/null activity over some
arbitrary amount of time. I think it would be more interesting to see
how many 'inactive' vs 'active' there are at a given time.

In any case, since Sean said that nova (and other projects) already
remove unmergeable changesets regularly, I think the data are already
"clean enough" to give us food for thoughts.

Why owners seem to be getting slower and slower to provide new patches,
despite the fact that the number of patches per changeset is fairly
stable? I'll look into the data more carefully with Daniel Izquierdo as
I think there are huge outliers skewing the data (the diff between
median and average is huge).

/stef


__
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] [kolla] Meeting on March 2nd, 2015 cancelled

[Steven Dake (stdake)]

Hi,

The IRC meeting f or kolla for March 2dn is canceled.  Some folks in the kolla 
core will be at the Magnum midcycle meetup, so I doubt we would have a quorum.  
Meetings will continue on the next week.

Regards
-steve

__
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] H302 considered harmful

[Felipe Reyes]

On Wed, 25 Feb 2015 15:47:46 -0500
Doug Hellmann  wrote:
> I think the rule originally came from the way mock works. If you
> import a thing in your module and then a test tries to mock where it
> came from, your module still uses the version it imported because the
> name lookup isn't done again at the point when the test runs. If all
> external symbols are accessed through the module that contains them,
> then the lookup is done at runtime instead of import time and mocks
> can replace the symbols. The same benefit would apply to monkey
> patching like what eventlet does, though that's less likely to come
> up in our own code than it is for third-party and stdlib modules.

I strongly agree, when source code does "from module import SomeClass"
is a nightmare patch it at runtime.

Those were my 2 cents to the discussion :)
-- 
Felipe Reyes (GPG:0x9B1FFF39)
http://tty.cl
lp:~freyes | freyes@freenode | freyes@github

__
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] [Heat] Stepping down from core

[Jeff Peeler]

As discussed during the previous Heat meeting, I'm going to be stepping 
down from core on the Heat project. My day to day focus is going to be 
more focused on TripleO for the foreseeable future, and I hope to be 
able to soon focus on reviews there.


Being part of Heat core since day 0 has been a good experience, but 
keeping up with multiple projects is a lot to manage. I don't know how 
some of you do it!


Jeff

__
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] H302 considered harmful

[Clay Gerrard]

So, Swift doesn't enforce H302 - and our imports are sorta messy frankly -
but it doesn't really bother me, and I do rather enjoy the terseness of not
having to spell out the module name.  It's not really a chore to maintain,
if you don't know where a name came from split the window (or drop a
marker) and pop up to the top of the file and there it is - mystery solved.
  But I've been living in the code base to long to say if hurts new-comers
trying to grok where things are coming from.  I'd be willing to entertain
feedback on this.

But one thing that I'd really love to hear feedback on is if people using
H302 ever find it's inconvenient to enforce the rule *all the time*?
Particularly in stdlib where it'd be *such* bad form to collide with a
common name like `defaultdict` or `datetime` anyway, if you see on of those
names without the module - you *know* where it came from (hopefully?):

 * `collections.defaultdict(collections.defaultdict(list))` - no thank you
 * `datetime.datetime - meh

Anyway, every time I start some project greenfield I try to make myself
H302, (i *do* get so sick of "is it time.time() or time() in this file?") -
but I normally break down as soon as I get to a name I'd rather just be be
in my right there in my globals... @contextlib.contextmanager,
functools.partial, itertools.ifilter - maybe it's just stdlib names?

Not sure if there's any compromise, probably better to either *just import
modules*, or live with the inconsistency (you eventually get nose-blind to
do it ;P)

-Clay

On Wed, Feb 25, 2015 at 10:51 AM, Duncan Thomas 
wrote:

> Hi
>
> So a review [1] was recently submitted to cinder to fix up all of the H302
> violations, and turn on the automated check for them. This is certainly a
> reasonable suggestion given the number of manual reviews that -1 for this
> issue, however I'm far from convinced it actually makes the code more
> readable,
>
> Is there anybody who'd like to step forward in defence of this rule and
> explain why it is an improvement? I don't discount for a moment the
> possibility I'm missing something, and welcome the education in that case
>
> Thanks
>
>
> [1] https://review.openstack.org/#/c/145780/
> --
> Duncan Thomas
>
> __
> 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] [Heat] Stepping down from core

[Randall Burt]

Sorry to see you go. Thanks so much for your contribution and best of luck on 
your new project!

On Feb 27, 2015, at 2:23 PM, Jeff Peeler 
 wrote:

> As discussed during the previous Heat meeting, I'm going to be stepping down 
> from core on the Heat project. My day to day focus is going to be more 
> focused on TripleO for the foreseeable future, and I hope to be able to soon 
> focus on reviews there.
> 
> Being part of Heat core since day 0 has been a good experience, but keeping 
> up with multiple projects is a lot to manage. I don't know how some of you do 
> it!
> 
> Jeff
> 
> __
> 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] olso.db 1.5.0 release

[Matt Riedemann]

On 2/26/2015 3:22 AM, Victor Sergeyev wrote:

Hi folks!

The Oslo team is pleased to announce the release of: oslo.db - OpenStack
common DB library

Changes from the previous release:

$ git log --oneline --no-merges 1.4.1..1.5.0
7bfdb6a Make DBAPI class work with mocks correctly
96cabf4 Updated from global requirements
a3a1bdd Imported Translations from Transifex
ab20754 Fix PyMySQL reference error detection
99e2ab6 Updated from global requirements
6ccea34 Organize provisioning to use testresources
eeb7ea2 Add retry decorator allowing to retry DB operations on request
d78e3aa Imported Translations from Transifex
dcd137a Implement backend-specific drop_all_objects for provisioning.
3fb5098 Refactor database migration manager to use given engine
afcc3df Fix 0 version handling in migration_cli manager
f81653b Updated from global requirements
efdefa9 Fix PatchStacktraceTest for pypy
c0a4373 Update Oslo imports to remove namespace package
1b7c295 Retry query if db deadlock error is received
046e576 Ensure DBConnectionError is raised on failed revalidate


Please report issues through launchpad:
http://bugs.launchpad.net/oslo.db


__
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



Looks like something here might be related to a spike in DBDeadlock 
errors in neutron in the last 24 hours:


https://bugs.launchpad.net/neutron/+bug/1426543

--

Thanks,

Matt Riedemann


__
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] [stable][all] Revisiting the 6 month release cycle [metrics]

[James E. Blair]

Stefano Maffulli  writes:

> In any case, since Sean said that nova (and other projects) already
> remove unmergeable changesets regularly, I think the data are already
> "clean enough" to give us food for thoughts.

I am asking you to please independently remove changes that you don't
think should be considered from your metrics.  If you rely on Sean or
others to abandon changes, then you are, in essence, relying on core
reviewers abandoning changes for the purposes of providing "clean" (as
you put it) input to a metrics system.

I think abandoning changes so that the metrics look the way we want is a
terrible experience for contributors.

Especially as it appears some projects, such as nova, are in a position
where they are actually leaving -2 votes on changes which will not be
lifted for 2 or 3 months.  That means that if someone runs a script like
Sean's, these changes will be abandoned, yet there is nothing that the
submitter can do to progress the change in the mean time.  Abandoning
such a review is making an already bad experience for contributors even
worse.

-Jim

__
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] Ideas about Openstack Cinder for GSOC 2015

[Ivan Kolodyazhny]

Hi Harry,

Please, ping me in IRC (e0ne) if you are still in Cinder as a part of GSoC.

Regards,
Ivan Kolodyazhny.

On Fri, Feb 27, 2015 at 4:34 PM, Davanum Srinivas  wrote:

> Harry,
>
> hop on to #openstack-gsoc and  #openstack-cinder as well.
>
> -- dims
>
> On Fri, Feb 27, 2015 at 9:26 AM, Anne Gentle
>  wrote:
> > Hi Harry,
> > I don't see a cinder mentor listed but you could certainly contact the
> > Project Technical Lead for Cinder, Mike Perez, and see if he knows of a
> > mentor and possible project.
> > Anne
> >
> > On Fri, Feb 27, 2015 at 3:50 AM, harryxiyou 
> wrote:
> >>
> >> Hi all,
> >>
> >> I cannot find the proper idea about Openstack Cinder for GSOC 2015
> >> here[1]. Could anyone please give me some clues?
> >>
> >> [1] https://wiki.openstack.org/wiki/GSoC2015
> >>
> >>
> >> Thanks, Harry
> >>
> >>
> __
> >> 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
> >
> >
> >
> >
> > --
> > Anne Gentle
> > annegen...@justwriteclick.com
> >
> >
> __
> > 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
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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] Ideas about Openstack Cinder for GSOC 2015

[Jay Bryant]

Fyi ...

This is something that Mike Perez was thinking about so you can ping
thingee on irc if you can't find e0ne.

Jay
On Feb 27, 2015 3:51 AM, "harryxiyou"  wrote:

> Hi all,
>
> I cannot find the proper idea about Openstack Cinder for GSOC 2015
> here[1]. Could anyone please give me some clues?
>
> [1] https://wiki.openstack.org/wiki/GSoC2015
>
>
> Thanks, Harry
>
> __
> 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

[openstack-dev] [devstack]Failure retrieving TENANT_ID for demo

[Guo, Ruijing]

1.   Probem description (compute/network node without keystone service is 
unsuccessfully deployed)

I use devstack to deploy mini-cluster. In controller node, keystone service is 
enabled and in compute/network node, keystone service is not enabled.

Controller node is deployed and compute/ successfully network is unsuccessfully 
deployed with following failure:

2015-02-27 06:32:20.337 | ERROR: openstack Authentication type must be selected 
with --os-auth-type
2015-02-27 06:32:20.355 | + TENANT_ID=
2015-02-27 06:32:20.359 | + die_if_not_set 530 TENANT_ID 'Failure retrieving 
TENANT_ID for demo'
2015-02-27 06:32:20.359 | + local exitcode=0
2015-02-27 06:32:20.366 | [Call Trace]
2015-02-27 06:32:20.366 | ./stack.sh:1203:create_neutron_initial_network
2015-02-27 06:32:20.366 | /opt/stack/devstack/lib/neutron:530:die_if_not_set
2015-02-27 06:32:20.366 | /opt/stack/devstack/functions-common:308:die
2015-02-27 06:32:20.363 | [ERROR] /opt/stack/devstack/functions-common:530 
Failure retrieving TENANT_ID for demo


2.   Root-cause



a.   The following variables are exported when keystone is enable.
if is_service_enabled keystone; then
…
 export OS_AUTH_URL=$SERVICE_ENDPOINT
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=$ADMIN_PASSWORD
export OS_REGION_NAME=$REGION_NAME
fi


b.  Neutron use the above exported varables:

function create_neutron_initial_network {

TENANT_ID=$(openstack project list | grep " demo " | get_field 1)

die_if_not_set $LINENO TENANT_ID "Failure retrieving TENANT_ID for demo"


3.   Solutions

Solution 1: enable keystone for all nodes when using devstack.


Solution 2: export the above variables if keystone is not enabled.

Solution 3: fix in devstack as:

--- stack.sh.orig   2015-02-28 00:24:31.784321431 +
+++ stack.sh2015-02-28 00:26:22.594307057 +
@@ -973,13 +973,14 @@
 # Begone token-flow auth
 unset OS_TOKEN OS_URL

-# Set up password-flow auth creds now that keystone is bootstrapped
-export OS_AUTH_URL=$SERVICE_ENDPOINT
-export OS_TENANT_NAME=admin
-export OS_USERNAME=admin
-export OS_PASSWORD=$ADMIN_PASSWORD
-export OS_REGION_NAME=$REGION_NAME
fi
+
+# Set up password-flow auth creds now that keystone is bootstrapped
+export OS_AUTH_URL=$SERVICE_ENDPOINT
+export OS_TENANT_NAME=admin
+export OS_USERNAME=admin
+export OS_PASSWORD=$ADMIN_PASSWORD
+export OS_REGION_NAME=$REGION_NAME

I’d like to create bug in devstack and provide patch for it. Any thought?

Thanks,
-Ruijing


__
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] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

[Stefano Maffulli]

I'm not expressing myself cleary enough. I don't advocate for the
removal of anything because I like pretty charts. I'm changing the
subject to be even more clear.

On Fri, 2015-02-27 at 13:26 -0800, James E. Blair wrote:
> I am asking you to please independently remove changes that you don't
> think should be considered from your metrics.  

I'm saying that the reports have indicators that seem to show struggle.
In a previous message Kevin hinted that probably a reason for those bad
looking numbers was due to "a lot of reviews that appear to have been
abandoned". This doesn't seem the case because some projects have a
habit of 'purging'. 

I have never explicitly ordered developers to purge anything. If their
decision to purge is due to the numbers they may have seen on the
reports I'd like to know. 

That said, the problem that the reports highlight remains confirmed so
far: contributors seem to be left in some cases hanging, for many many
days, *after a comment* and they don't come back.

> I think abandoning changes so that the metrics look the way we want is a
> terrible experience for contributors.

I agree, that should not be a motivator. Also, after chatting with you
on IRC I tend to think that instead of abandoning the review we should
highlight them and have humans act on them. Maybe build a dashboard of
'old stuff' to periodically sift through and see if there are things
worth picking up again or to ping the owner or something else managed by
humans. 

I happened to have found one of such review automatically closed that
could have been fixed with a trivial edit in commit message instead:

https://review.openstack.org/#/c/98735/

(that owner had a bunch of auto-abandoned patches 
https://review.openstack.org/#/q/owner:%22Mh+Raies+%253Craiesmh08%
2540gmail.com%253E%22,n,z). I have made a note to reach out to him and
get more anecdotes.

> Especially as it appears some projects, such as nova, are in a position
> where they are actually leaving -2 votes on changes which will not be
> lifted for 2 or 3 months.  That means that if someone runs a script like
> Sean's, these changes will be abandoned, yet there is nothing that the
> submitter can do to progress the change in the mean time.  Abandoning
> such a review is making an already bad experience for contributors even
> worse.

this sounds like a different issue :(


__
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] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

[John Griffith]

On Fri, Feb 27, 2015 at 5:40 PM, Stefano Maffulli 
wrote:

> I'm not expressing myself cleary enough. I don't advocate for the
> removal of anything because I like pretty charts. I'm changing the
> subject to be even more clear.
>
> On Fri, 2015-02-27 at 13:26 -0800, James E. Blair wrote:
> > I am asking you to please independently remove changes that you don't
> > think should be considered from your metrics.
>
> I'm saying that the reports have indicators that seem to show struggle.
> In a previous message Kevin hinted that probably a reason for those bad
> looking numbers was due to "a lot of reviews that appear to have been
> abandoned". This doesn't seem the case because some projects have a
> habit of 'purging'.
>
> I have never explicitly ordered developers to purge anything. If their
> decision to purge is due to the numbers they may have seen on the
> reports I'd like to know.
>
> That said, the problem that the reports highlight remains confirmed so
> far: contributors seem to be left in some cases hanging, for many many
> days, *after a comment* and they don't come back.
>
> > I think abandoning changes so that the metrics look the way we want is a
> > terrible experience for contributors.
>
> I agree, that should not be a motivator. Also, after chatting with you
> on IRC I tend to think that instead of abandoning the review we should
> highlight them and have humans act on them. Maybe build a dashboard of
> 'old stuff' to periodically sift through and see if there are things
> worth picking up again or to ping the owner or something else managed by
> humans.
>
> I happened to have found one of such review automatically closed that
> could have been fixed with a trivial edit in commit message instead:
>
> https://review.openstack.org/#/c/98735/
>
> (that owner had a bunch of auto-abandoned patches
> https://review.openstack.org/#/q/owner:%22Mh+Raies+%253Craiesmh08%
> 2540gmail.com%253E%22,n,z). I have made a note to reach out to him and
> get more anecdotes.
>
> > Especially as it appears some projects, such as nova, are in a position
> > where they are actually leaving -2 votes on changes which will not be
> > lifted for 2 or 3 months.  That means that if someone runs a script like
> > Sean's, these changes will be abandoned, yet there is nothing that the
> > submitter can do to progress the change in the mean time.  Abandoning
> > such a review is making an already bad experience for contributors even
> > worse.
>
> this sounds like a different issue :(
>
>
> __
> 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
>
​
For what it's worth, at one point the Cinder project setup an auto-abandon
job that did purge items that had a negative mark either from a reviewer or
from Jenkins and had not been updated in over two weeks.  This had
absolutely nothing to do with metrics or statistical analysis of the
project.  We simply had a hard time dealing with patches that the submitter
"didn't care about".  If somebody takes the time to review a patch, then I
don't think it's too much to ask that the submitter respond to questions or
comments within a two week period.  Note, the auto purge in our case only
purged items that had no updates or activity at all.

We were actually in a position where we had patches that were submitted,
failed unit tests in the gate (valid failures that occurred 100% of the
time) and had sat for an entire release without the submitter ever updating
the patch. I don't think it's unreasonable at all to abandon these and
remove them from the queue.  I don't think this is a bad thing, I think
it's worse to leave them as active when they're bit-rotted and the
submitter doesn't even care about them any longer.  The other thing is,
those patches are "still there", they can still be accessed and reinstated.

There's a lot of knocks against core teams regarding time to review and
keeping up with the work load.. that's fine, but at the same time if you
submit something you should follow through on it and respond to comments or
test failures in a timely manner.  Also there should be some scaling factor
here; if a patch that needs updating should be expected to be able to sit
in the queue for a month for example, then we should give one month for
each reviewer; so minimum of three months for a +1, +2 and +A.

I don't think it's reasonable to say "hey, you all have to review faster
and get more done" and then also say "by the way, you need to babysit and
reach out and contact owners of patches that have been idle for long
periods".  Especially considering MANY of the patches in Cinder at least
that end up falling into this category are from folks that aren't on IRC
and do not have public email addresses in LaunchPad.

Just providing another perspective.
__

[openstack-dev] [openstack-docs] Question about the patch of QoS configuration to commit

[liuxinguo]

Recently I have commit a patch in 
"openstack-manuals/doc/config-reference/block-storage/drivers/huawei-storage-driver.xml"
 contains the QoS configuration and the reviewers said that I should not put 
the QoS configuration as Huawei specific information but in the Cloud Admin 
Guide.

The problem is I think the QoS configuration I want to commit in the patch 
might be really Huawei specific information. For example, I described how to 
create "minIOPS" QoS in the patch because the name "minIOPS" is the exactly 
name the user should use in Huawei driver. So I think these configuration is 
really Huawei specific information and I think maybe it is not appropriate to 
put these information in "Cloud Admin Guide".

I am confused where to put the QoS configuration and I would be very 
appreciative if anyone can give me some ideas.

Thanks and 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

Re: [openstack-dev] [Congress][Delegation] Initial workflow design

[Huangyong (Oliver)]

Hi Ruby,

  I agree with you on your point below
  The policy (warning) : when will it be evaluated? This should be done 
periodically? Then if the table has even one True entry, then the action should 
be to generate the LP, solve, activate the migrations etc.

ð  The “LP” cannot be generated when the VM-placement engine receives the 
policy snippet

 When we give multiple constraints and want get out solutions which meet 
all the constraints,  for example VM-Placement, there may cause a large amount 
of choices to be checked and filter.  In theory, this kind of problem belongs 
to NPC/NP hard.   Normally, quite a lot methods use SAT solver to do the work.
 I want to introduce Rule-X BP proposal of congress a little here. It is 
some kind of enhanced SAT solver which designed to solve this kind of problem.
https://blueprints.launchpad.net/congress/+spec/rule-x
We are planning give a presentation on the upcoming openstack summit in 
May,vancouver.  Present by John Strassner. Hope you are interest in it.

Best Regards,
Oliver
---
Huangyong (Oliver)
Network research, Huawei

From: ruby.krishnasw...@orange.com [mailto:ruby.krishnasw...@orange.com]
Sent: Friday, February 27, 2015 10:41 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress][Delegation] Initial workflow design

My first suggestion: why don’t we set up call together with Ramki, Yathi, Debo, 
as soon as possible ?

-How to go forward concretely with the 8 steps for the PoC (details 
within each step),

o   Including nova integration points

-Identify “friction points” in the details above to resolve for  beyond 
PoC


Tim: Where does the rest of the program originate?  I’m not saying the entire 
LP program is generated from the Datalog constraints; some of it is generated 
by the solver independent of the Datalog.  In the text, I gave the example of 
defining hMemUse[j].
Tim: The VM-placement engine does 2 things: (I) translates Datalog to LP and 
(ii) generates additional LP constraints.  (Both work items could leverage any 
constraints that are builtin to a specific solver, e.g. the solver-scheduler.  
The point is that there are 2 distinct, conceptual origins of the LP 
constraints: those that represent the Datalog and those that codify the domain.
Tim: Each domain-specific solver can do whatever it wants, so it’s not clear to 
me what the value of choosing a modeling language actually is—unless we want to 
build a library of common functionality that makes the construction of 
domain-specific engine (wrappers) easier.  I’d prefer to spend our energy 
understanding whether the proposed workflow/interface works for a couple of 
different domain-specific policy engines OR to flush this one out and build it.




ð  The value of choosing a modeling language is related to how “best to 
automate translations” from Datalog constraints (to LP)?

o   We can have look for one unique way of generation, and not, “some of it is 
generated by the VM-placement engine solver independent of the Datalog”.

o   Datalog imposes most constraints (== policies)

o   Two constraints are not “policies”

§  A VM is allocated to only one host.

§  Host capacity is not exceeded.

·Over subscription

ð  Otherwise what was your suggestion?  As follows?

o   Use framework (extend) the nova-solver-scheduler currently implements 
(itself using PuLP). This framework specifies an API to write constraints and 
cost functions (in a domain specific way). Modifying this framework:

§  To read data in from DSE

§  To obtain the cost function from Datalog (e.g. minimize Y[host1]…)

§  To obtain Datalog constraints (e.g. <75% memory allocation constraint for 
hosts of special zone)

o   We need to specify the “format” for this? It will likely to be a string of 
the form (?)

§  “hMemUse[0] – 0.75*hMemCap[0] < 100*y[0], “ Memory allocation constraint on 
Host 0“,











ð  From your doc (page 5, section 4)


warning(id) :-
nova:host(id, name, service, zone, memory_capacity),
legacy:special_zone(zone),
ceilometer:statistics(id, "memory", avg, count, duration,
durstart, durend, max, min, period, perstart, perend,
sum, unit),
avg > 0.75 * memory_capacity


Notice that this is a soft constraint, identified by the use of warning instead 
of error.  When compiling to LP, the VM-placement engine will attempt to 
minimize the number of rows in the warning table.  That is, for each possible 
row r it will create a variable Y[r] and assign it True if the row is a warning 
and False otherwise


The policy (warning) : when will it be evaluated? This should be done 
periodically? Then if the table has even one True entry, then the action should 
be to generate the LP, solve, activate the migrations etc.

ð  The “LP” cannot be generated when the VM-placement engine receives the 
policy snippet.


Ruby


De : Tim Hinrichs [mailto:thinri...@vmware.com]
Envoyé : jeudi 

Re: [openstack-dev] [Heat] Stepping down from core

[Qiming Teng]

On Fri, Feb 27, 2015 at 03:23:13PM -0500, Jeff Peeler wrote:
> As discussed during the previous Heat meeting, I'm going to be
> stepping down from core on the Heat project. My day to day focus is
> going to be more focused on TripleO for the foreseeable future, and
> I hope to be able to soon focus on reviews there.
> 
> Being part of Heat core since day 0 has been a good experience, but
> keeping up with multiple projects is a lot to manage. I don't know
> how some of you do it!
> 
> Jeff

Best wishes to you, Jeff.  Thanks for your contributions and your
mentoring during the past!

Regards,
 Qiming
> __
> 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

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

[liuxinguo]

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

Re: [openstack-dev] [openstack-docs] Question about the patch of QoS configuration to commit

[Anne Gentle]

On Fri, Feb 27, 2015 at 8:12 PM, liuxinguo  wrote:

>  Recently I have commit a patch in “openstack-manuals/
> doc/config-reference/block-storage/drivers/huawei-storage-driver.xml
> ”
> contains the QoS configuration and the reviewers said that I should not put
> the QoS configuration as Huawei specific information but in the Cloud Admin
> Guide.
>
>
>
> The problem is I think the QoS configuration I want to commit in the patch
> might be really Huawei specific information. For example, I described how
> to create “minIOPS” QoS in the patch because the name “minIOPS” is the
> exactly name the user should use in Huawei driver. So I think these
> configuration is really Huawei specific information and I think maybe it is
> not appropriate to put these information in “Cloud Admin Guide”.
>
>
>

I looked through the patch at
https://review.openstack.org/#/c/150761/2/doc/config-reference/block-storage/drivers/huawei-storage-driver.xml
to try to determine the concern Andreas had.

Is Quality of Service policy only used for the Huawei storage driver? Even
if so, there are examples of QoS drivers for networking here:

http://docs.openstack.org/admin-guide-cloud/content/section_plugin_specific_extensions.html

With that as a pattern, please patch here to add QoS information for
storage drivers.

New file like this one:
https://github.com/openstack/openstack-manuals/blob/master/doc/admin-guide-cloud/blockstorage/section_consistency_groups.xml

with an xi:include statement in this file:

https://github.com/openstack/openstack-manuals/blob/master/doc/admin-guide-cloud/ch_blockstorage.xml

Hope this direction makes sense.
Anne


>  I am confused where to put the QoS configuration and I would be very
> appreciative if anyone can give me some ideas.
>
>
>
> Thanks and 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
>
>


-- 
Anne Gentle
annegen...@justwriteclick.com
__
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] [Devstack] Can't start service nova-novncproxy

[Li, Chen]

Hi all,

I'm trying to install a fresh all-in-one openstack environment by devstack.
After the installation, all services looks well, but I can't open instance 
console in Horizon.

I did a little check, and found service nova-novncproxy was not started !
Anyone has idea why this happened ?

Here is my local.conf : http://paste.openstack.org/show/183344/

My os is:
Ubuntu 14.04 trusty
3.13.0-24-generic

Thanks.
-chen

__
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] [Ironic] Adding vendor drivers in Ironic

[Ramakrishnan G]

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).

Let me know all of your thoughts on this.  If we agree, I feel we should
have some documentation on it in our Ironic docs directory.

Thanks for reading :)

Regards,
Ramesh
__
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

[Weidong Shao]

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

On Mon, Jan 26, 2015 at 3:54 PM Adrian Otto 
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  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] [all] creating a unified developer reference manual

[Clint Byrum]

Excerpts from Ben Nemec's message of 2015-02-27 09:25:37 -0800:
> On 02/27/2015 03:54 AM, Thierry Carrez wrote:
> > Doug Hellmann wrote:
> >> Maybe some of the folks in the meeting who felt more strongly that it
> >> should be a separate document can respond with their thoughts?
> > 
> > I don't feel very strongly and could survive this landing in
> > openstack-specs. My objection was the following:
> > 
> > - Specs are for designing the solution and implementation plan to a
> > specific problem. They are mainly used by developers and reviewers
> > during implementation as a clear reference rationale for change and
> > approved plan. Once they are fully implemented, they are kept for
> > history purpose, not for constant reference.
> > 
> > - Guidelines/developer doc are for all developers (old and new) to
> > converge on best practices on topics that are not directly implemented
> > as hacking rules. They are constantly used by everyone (not just
> > developers/reviewers of a given feature) and never become "history".
> > 
> > Putting guidelines doc in the middle of specs makes it a bit less
> > discoverable imho, especially by our new developers. It's harder to
> > determine which are still current and you should read. An "OpenStack
> > developer doc" sounds like a much better entry point.
> > 
> > That said, the devil is in the details, and some efforts start as specs
> > (for existing code to catch up with the recommendation) and become
> > guidelines (for future code being written). That is the case of the log
> > levels spec: it is both a spec and a guideline. Personally I wouldn't
> > object if that was posted in both areas, or if the relevant pieces were
> > copied, once the current code has caught up, from the spec to a dev
> > guideline.
> > 
> > In the eventlet case, it's only a set of best practices / guidelines:
> > there is no specific problem to solve, no catch-up plan for existing
> > code to implement. Only a collection of recommendations if you get to
> > write future eventlet-based code. Those won't start or end. Which is why
> > I think it should go straight to a developer doc.
> > 
> 
> Well, this whole spec arose because we found out there was existing code
> that was doing bad things with eventlet monkey patching that needed to
> be fixed.  The specific problem is actually being worked concurrently
> with the spec because everyone involved has agreed on a solution, which
> became one of the guidelines in the spec.  I'd be surprised if there
> aren't other projects that need similar changes to be in line with the
> new recommendations though.  I'd hope that future projects will follow
> the guidelines, but they were actually written for the purpose of
> eliminating as many potential eventlet gotchas in our _current_ code as
> possible.  Coming up with a specific list of changes needed is tough
> until we have agreement on the best practices though, which is why the
> first work item is a somewhat vague "audit and fix all the things" point.
> 
> Personally, I would expect most best practice/guideline type specs to be
> similar.  Nobody's going to take the time to write up a spec about
> something everyone's already doing - they're going to do it because one
> or a few projects have found something that works well and they think
> everyone should be doing it.  So I think your point about most of these
> things moving from spec to guideline throughout their lifetime is spot
> on, I'm just wondering if it's worth complicating the workflow for that
> process.  Herding the cats for something big like the log guidelines is
> hard enough without requiring two separate documents for the immediate
> work and the long-term information.
> 
> That said, I agree with the points about publishing this stuff under a
> developer reference doc rather than specs, and if that can't be done in
> a single repo maybe we do have to split.  I'd still prefer to keep it
> all in one repo though - moving a doc between directories is a lot
> simpler than moving it between repos (and also doesn't lose any previous
> discussion in Gerrit).
> 

There are numerous wiki pages that have a wealth of knowledge, but
very poor history attached. Such as:

  * https://wiki.openstack.org/wiki/Python3
  * https://wiki.openstack.org/wiki/GitCommitMessages
  * https://wiki.openstack.org/wiki/Gerrit_Workflow
  * https://wiki.openstack.org/wiki/Getting_The_Code
  * https://wiki.openstack.org/wiki/Testr

Just having these in git would be useful, and having the full change
history with the same care given to commit messages and with reviewers
would I think improve the content and usability of these.

Since these are not even close to "specs", but make excellent static
documents, I think having them in a cross-project developer
documentation repository makes a lot of sense.

That said, I do think that we would need to have a much lower bar for
reviews (maybe just 1 * +2, but let it sit at least 3 days or something
to allow for exposur