Re: [openstack-dev] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

2016-03-20 Thread Mike Perez
On 12:50 Mar 21, Tony Breeds wrote:
> On Sun, Mar 20, 2016 at 12:48:43PM -0400, Doug Hellmann wrote:
> > I won't be able to make the TC meeting this week because of travel,
> > so I wanted to lay out my thoughts on the three PTL-less projects
> > based on the outcome of the recent election (EC2-API, Winstackers,
> > and Stable Maintenance).
> > 
> > The EC2-API project doesn't appear to be very actively worked on.
> > There is one very recent commit from an Oslo team member, another
> > couple from a few days before, and then the next one is almost a
> > month old. Given the lack of activity, if no team member has
> > volunteered to be PTL I think we should remove the project from the
> > official list for lack of interest.
> 
> I don't like disclosing private communications but in this case I feel it's
> appropriate.
> 
> The Current PTL contacted the Election officials after the nomination period
> closed and was instructed to reach out to the TC and community.
> 
> > The Winstackers project is much more active in the repository, but
> > there doesn't seem to be much traffic on the mailing list. It's not
> > clear why no one signed up to be PTL, and I couldn't find a notice
> > that the current PTL is not running. I'm tempted to suggest removing
> > Winstackers from the official project list for lack of participation
> > in project governance, but perhaps a probation period is in order
> > since it's a relatively new team. Probation would depend on having
> > the team find a PTL volunteer, of course.

I think it's unfortunate that EC2-API and Winstackers are out of touch enough
from the community to miss important dates like this. With things like the
weekly dev mailing list digest that cover this [1], keeping up with the dev
list is not a great excuse. Keeping in mind things were first announced March
7th [2], and this has been in the Mitaka release schedule [3] for so long.

[1] - 
http://www.openstack.org/blog/2016/03/openstack-developer-mailing-list-digest-20160311/
[2] - http://lists.openstack.org/pipermail/openstack-dev/2016-March/088558.html
[3] - http://releases.openstack.org/mitaka/schedule.html

-- 
Mike Perez

__
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] [kolla][release] Announcement of release of Mitaka rc1!

2016-03-20 Thread Daneyon Hansen (danehans)

For sure.

Regards,
Daneyon

On Mar 19, 2016, at 1:52 PM, Steven Dake (stdake) 
> wrote:

Thanks - although it wasn't me that made it happen, it was the team.

Regards,
-steve


From: "Daneyon Hansen (danehans)" 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, March 18, 2016 at 1:57 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla][release] Announcement of release of Mitaka 
rc1!

Steve,

Congratulations on the release!!!

Regards,
Daneyon

On Mar 17, 2016, at 9:32 AM, Steven Dake (stdake) 
> wrote:


The Kolla community is pleased to announce the release of Mitaka

milestone RC1.  This may look like a large list of features, but really

it was finishing the job on 1 or 2 services that were missing for each

of our major blueprints for Mitaka.


Mitaka RC1 Features:

  *   MariaDB lights out recovery
  *   Full upgrades of all OpenStack services
  *   Full upgrades of all OpenStack infrastructure
  *   Full reconfiguration of all OpenStack services
  *   Full reconfiguration of all OpenStack infrastructureAll containers now 
run as non-root user
  *   Added support for Docker IPC host namespace
  *   Cleaned up false haproxy warning about reource unavailability
  *   Improved Vagrant scripts
  *   Mesos DNS container
  *   Ability to use a local archive or directory for source build
  *   Mesos has new per service cli to make deployment and upgrades more 
flexible
  *   Mesos has better constraints to deal with multi-host deployment
  *   Mesos has better depedencies for nova and neutron (inter-host 
dependencies)
  *

For more details, check out our blueprint feature and bug tracker here:


https://launchpad.net/kolla/+milestone/mitaka-rc1


We are super excited about the release of Kolla Mitaka-rc1!  We did some really

impressive output in 12 days, implementing solutions for 4

blueprints and 46 bugs.  This cycle our core team grew by one member

Alicja Kwasniewska.  Our community continues to remain extremely diverse

and is growing with 203 IC interactions and 40 corporate affiliations.  Check

out our stackalytics page at:


http://stackalytics.com/?module=kolla-group=person-day

__
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


[openstack-dev] [release][stable][glance] glance_store 0.9.2 release (liberty)

2016-03-20 Thread no-reply
We are content to announce the release of:

glance_store 0.9.2: OpenStack Image Service Store Library

This release is part of the liberty stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/glance_store

With package available at:

https://pypi.python.org/pypi/glance_store

Please report issues through launchpad:

http://bugs.launchpad.net/glance-store

For more details, please see below.

Changes in glance_store 0.9.1..0.9.2


7b13ce6 Add backend tests from glance
af44b6e Change Swift zero-size chunk behaviour
a0572ef Swift store: do not send a 0 byte chunk
fc61c21 Add list of supported stores to help
156ac63 Updated from global requirements
2ecc714 vmware: check for response body in error conditions
f5b34ba Improving GlanceStoreException
21ddd7f Catch InvalidURL when requesting store size
844e08e Updated from global requirements
399547f Fix swift store tests for latest swiftclient
51fb41f Update .gitreview for stable/liberty

Diffstat (except docs and test files)
-

.gitreview   |   1 +
glance_store/_drivers/http.py|   9 +++
glance_store/_drivers/swift/store.py |  24 +++---
glance_store/_drivers/vmware_datastore.py|   2 +-
glance_store/backend.py  |   4 +-
glance_store/exceptions.py   |  28 +--
requirements.txt |   2 +-
setup.py |   2 +-
14 files changed, 295 insertions(+), 30 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 374e315..7a506e1 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ oslo.serialization>=1.4.0 # Apache-2.0
-oslo.utils>=2.0.0 # Apache-2.0
+oslo.utils!=2.6.0,>=2.0.0 # Apache-2.0



__
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] Visa Invitation Letter doesn't contain attachment

2016-03-20 Thread Zhi Chang
hi, guys.
 
I received Visa Invitation Letter a few days ago. But the letter doesn't 
contain attachment. What should I do?




Thanks
Zhi Chang__
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] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

2016-03-20 Thread Dan Smith
> Just clarifying:
> For Nova: Yes.  Matt's the only candidate I think that's a preety save 
> assumption.

Sorry, I meant for Nova.

I guess since the nomination period is over (right), I'm not sure how
it's not more than an assumption...but okay :)

--Dan

__
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] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

2016-03-20 Thread Tony Breeds
On Sun, Mar 20, 2016 at 04:14:02PM -0700, Dan Smith wrote:
> > The EC2-API project doesn't appear to be very actively worked on.
> > There is one very recent commit from an Oslo team member, another
> > couple from a few days before, and then the next one is almost a
> > month old. Given the lack of activity, if no team member has
> > volunteered to be PTL I think we should remove the project from the
> > official list for lack of interest.
> 
> Nova just removed ec2 support from tree in Mitaka, dependent on this
> project being a replacement for that functionality. It is troubling that
> nobody stepped up to be PTL, but as recent as Tokyo there was active
> participation from them in getting things settled in Nova so that the
> project could be a suitable replacement. Aside from the practical
> problem of not having a PTL, it seems like dropping EC2-API from the
> official project list right as Mitaka requires people to use it sends a
> bad (or at least unfortunate) message.
> 
> Has anyone approached some of the principal folks involved to find out
> what is up?
> 
> > The situation with the Stable Maintenance team is ironically shaky.
> > The outgoing PTL has entered the Nova PTL election, though he has
> > said he would take up the Stable team work again if he does not
> > become Nova PTL. That election will not be over until 24 March, so
> > I think we should wait before taking any action. If Matt becomes
> > Nova PTL, and no other volunteer steps forward, I will take on the
> > responsibilities, though I do want to keep the Stable team separate
> > from the Release team. That said, I would very much prefer to have
> > someone else be the Stable team PTL so I hope we can find a volunteer.
> 
> Correct me if I'm wrong, but Matt is PTL by default now right?

Just clarifying:
For Nova: Yes.  Matt's the only candidate I think that's a preety save 
assumption.
For Stable: No. It's up to the TC to select a new canidate[1]

Yours Tony.

[1] 
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html


signature.asc
Description: 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] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

2016-03-20 Thread Tony Breeds
On Sun, Mar 20, 2016 at 12:48:43PM -0400, Doug Hellmann wrote:
> I won't be able to make the TC meeting this week because of travel,
> so I wanted to lay out my thoughts on the three PTL-less projects
> based on the outcome of the recent election (EC2-API, Winstackers,
> and Stable Maintenance).
> 
> The EC2-API project doesn't appear to be very actively worked on.
> There is one very recent commit from an Oslo team member, another
> couple from a few days before, and then the next one is almost a
> month old. Given the lack of activity, if no team member has
> volunteered to be PTL I think we should remove the project from the
> official list for lack of interest.

I don't like disclosing private communications but in this case I feel it's
appropriate.

The Current PTL contacted the Election officials after the nomination period
closed and was instructed to reach out to the TC and community.

> The Winstackers project is much more active in the repository, but
> there doesn't seem to be much traffic on the mailing list. It's not
> clear why no one signed up to be PTL, and I couldn't find a notice
> that the current PTL is not running. I'm tempted to suggest removing
> Winstackers from the official project list for lack of participation
> in project governance, but perhaps a probation period is in order
> since it's a relatively new team. Probation would depend on having
> the team find a PTL volunteer, of course.
> 
> The situation with the Stable Maintenance team is ironically shaky.
> The outgoing PTL has entered the Nova PTL election, though he has
> said he would take up the Stable team work again if he does not
> become Nova PTL.  That election will not be over until 24 March, so
> I think we should wait before taking any action. If Matt becomes
> Nova PTL, 

Given he's the only candidate I think it's reasonable to assume he'll become
the PTL in ~3 days  :)

> , and no other volunteer steps forward, I will take on the
> responsibilities, though I do want to keep the Stable team separate
> from the Release team. That said, I would very much prefer to have
> someone else be the Stable team PTL so I hope we can find a volunteer.

So cards on the table, I'm interested in taking on the role.  I didn't nominate
because I thought that might be a little complex given I'm also acting as an
election official.

Clearly[1] the TC can select a candidate, whomever that is I'm confident Stable
Maintenance will continue to build momentum.

Yours Tony.

[1] 
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html


signature.asc
Description: 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


[openstack-dev] [Sahara][QA] Notes about the move of the Sahara Tempest API test to sahara-tests

2016-03-20 Thread Luigi Toscano
Hi,

as discussed in the last (two) Sahara meetings, I'm working on moving the 
Tempest API tests from the Tempest repository to the new sahara-tests 
repository, which contains only (non-tempest) scenario tests and it's 
branchless as well.
The move is a natural consequence of the Tempest focus on the "core six" 
(removing the burden of additional reviews from core Tempest), and of the 
existence of the Tempest Plugin interface.

So far, nothing new. The difference from that past is that I'd like to keep the 
history of the imported code.

I've the feeling that there is a bit of resistance to the idea of importing the 
history, but talking around it seems that it is feasible. It requires few 
additional steps, which I'm going to describe here for the posterity and to 
gather feedback, and which I'm going to execute in the next days if there are 
no blocking concerns.


== Extract tempest/api/data_processing from Tempest and filter it
Easy with git-split (https://github.com/ajdruff/git-splits, thanks Evgeny 
Sikachev) and a bit of cleanup (removal of the first empty commit with `git 
rebase -i --root`). This code should then be merged in a detached branch of 
sahara-tests (created with `git checkout --orphan `).
-> See a preview here: 
https://github.com/ltoscano-rh/sahara-tests/commits/tempest-sahara-api


== Push the sanitized history to a detached branch of sahara-tests
It's really two substeps:

= Temporarily exclude a specific branch from the CI 
Change to openstack-infra/project-config and openstack/sahara-ci-config
-> Requires reviews from infra and Sahara cores

= Merge the content of the imported, detached branch to sahara-tests
Ninja-approval of all the commits of the imported branch (38 commits). Without 
tests and use of tools like gertty it can be fast.
-> It will require the help of a (patient) Sahara core, but I think I could 
volunteer some of them :)


== Merge the imported branch into sahara-tests master
Again, two substeps:

= Change the ACLs for sahara-tests to allow a merge commit
-> Requires review from infra (project-config, gerrit/acls)

= Push the merge commit of the imported branch to sahara-tests master to gerrit
Preview available here: 
https://github.com/ltoscano-rh/sahara-tests/commits/master
-> Requires normal review from Sahara cores.


== Adapt the imported code to use the Tempest Plugin interface
Preview available here: 
https://github.com/ltoscano-rh/sahara-tests/commits/tempestapi-intree
-> Requires normal review from Sahara cores.


== Undo all the temporarily hacks introduced before
-> Requires normal review from Sahara cores.


I hope that it could be useful.

-- 
Luigi

__
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-stable-maint][stable/liberty][trove] stable/liberty changes in Trove that are ready for merge

2016-03-20 Thread Tony Breeds
On Sun, Mar 20, 2016 at 08:00:07PM -0400, Luigi Toscano wrote:

> No one said that there will be other backports, at this time. It would have
> made sense if the reviews would have been merged when they have been
> proposed. It would be nice thought to backports one or two other patches for
> the integration tests, provided that the two disscused here are merged, but
> let's focus on them first.
> 
> Without the code from the two reviews, the code for scenario tests _shipped_
> in Liberty is unusable.
> Scenario tests are the new tests which are going to replace the current
> integration tests. Scenario tests are not used on the CI right now (which
> also means that the backport is not going to break anything), the plan was to
> switch to them in Mitaka, but most likely now in Newton.
> 
> Now, the integration tests currently used on the CI makes it very difficult,
> if not impossible, to test any datastore which is not MySQL - including for
> example MariaDB. Merging the two reviews would make the life a bit easier for
> people which use Liberty (which is for a while still the stable release, and
> it will be supported for other few months).
> 
> My summary is:
> Does they break some code? No.
> Does they fix broken code? Yes.
> Does this open a can of worm? IMHO no, there is no impact on the
> functionalities even in the "worst" case of other reviews being merged.

As an extra data point I ran the experimental queue over the reviews in
question.  The results aren't good.

In order to gatehr more data I'm running a no-op change through the
experimental queue.  This will help us dtermine if we're just making work for
ourselves.

Yours Tony.


signature.asc
Description: 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] [Openstack-stable-maint][stable/liberty][trove] stable/liberty changes in Trove that are ready for merge

2016-03-20 Thread Luigi Toscano
- Original Message -
> On 03/19/2016 01:43 AM, Tony Breeds wrote:
> > On Sun, Mar 13, 2016 at 12:15:23PM +, Amrith Kumar wrote:
> >> Hi,
> >>
> >> Sorry for the blast mail, this is targeted at the stable-maint team. The
> >> following five changes are now ready to merge. Two of them are changes
> >> proposed by the bot and three of them are clearly identified as
> >> cherry-picks
> >> from changes that went into master.
> > 
> >
> >> Add instance create int-tests
> >> Add MySQL int-test helper client
> > It looks like it's down to just those 2 which are testing only backports.
> >
> > From a stable POV I'm a little on the fence about applicability.
> >
> > Ignoring that right now both reviews seem to be focused around "scenarios"
> > testing but trove doesn't run gate-trove-scenario-functional-dsvm* on
> > stable
> > and on master they seem to be non-voting experimental jobs.
> >
> > Did I misunderstand what these reviews are doing?
> 
> Tony, your understanding is correct. These requests led to a lot of
> discussion and the fact that these are non-voting experimental jobs was
> discussed at length. It was felt that these would be useful for people
> who have to support stable/liberty. But, as one of the reviewers points
> out, this request opens a can of worms. Are we implying that over time
> there are going to be more fixes to get these tests working? And I don't
> think any of us is comfortable with the answer to that being "yes".

No one said that there will be other backports, at this time. It would have 
made sense if the reviews would have been merged when they have been proposed. 
It would be nice thought to backports one or two other patches for the 
integration tests, provided that the two disscused here are merged, but let's 
focus on them first.

Without the code from the two reviews, the code for scenario tests _shipped_ in 
Liberty is unusable.
Scenario tests are the new tests which are going to replace the current 
integration tests. Scenario tests are not used on the CI right now (which also 
means that the backport is not going to break anything), the plan was to switch 
to them in Mitaka, but most likely now in Newton.

Now, the integration tests currently used on the CI makes it very difficult, if 
not impossible, to test any datastore which is not MySQL - including for 
example MariaDB. Merging the two reviews would make the life a bit easier for 
people which use Liberty (which is for a while still the stable release, and it 
will be supported for other few months).

My summary is:
Does they break some code? No.
Does they fix broken code? Yes.
Does this open a can of worm? IMHO no, there is no impact on the 
functionalities even in the "worst" case of other reviews being merged.

Hope this helps.

Ciao
-- 
Luigi

__
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] [TripleO] propose EmilienM for core

2016-03-20 Thread Richard Megginson


+1

 Original message 
From: Dan Prince  
Date: 03/20/2016  12:23 PM  (GMT-07:00) 
To: openstack-dev  
Subject: [openstack-dev] [TripleO] propose EmilienM for core 

I'd like to propose that we add Emilien Macchi to the TripleO core
review team. Emilien has been getting more involved with TripleO during
this last release. In addition to help with various Puppet things he
also has experience in building OpenStack installation tooling,
upgrades, and would be a valuable prospective to the core team. He has
also added several new features around monitoring into instack-
undercloud.

Emilien is currently acting as the Puppet PTL. Adding him to the
TripleO core review team could help us move faster towards some of the
upcoming features like composable services, etc.

If you agree please +1. If there is no negative feedback I'll add him
next Monday.

Dan

__
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] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

2016-03-20 Thread Dan Smith
> The EC2-API project doesn't appear to be very actively worked on.
> There is one very recent commit from an Oslo team member, another
> couple from a few days before, and then the next one is almost a
> month old. Given the lack of activity, if no team member has
> volunteered to be PTL I think we should remove the project from the
> official list for lack of interest.

Nova just removed ec2 support from tree in Mitaka, dependent on this
project being a replacement for that functionality. It is troubling that
nobody stepped up to be PTL, but as recent as Tokyo there was active
participation from them in getting things settled in Nova so that the
project could be a suitable replacement. Aside from the practical
problem of not having a PTL, it seems like dropping EC2-API from the
official project list right as Mitaka requires people to use it sends a
bad (or at least unfortunate) message.

Has anyone approached some of the principal folks involved to find out
what is up?

> The situation with the Stable Maintenance team is ironically shaky.
> The outgoing PTL has entered the Nova PTL election, though he has
> said he would take up the Stable team work again if he does not
> become Nova PTL. That election will not be over until 24 March, so
> I think we should wait before taking any action. If Matt becomes
> Nova PTL, and no other volunteer steps forward, I will take on the
> responsibilities, though I do want to keep the Stable team separate
> from the Release team. That said, I would very much prefer to have
> someone else be the Stable team PTL so I hope we can find a volunteer.

Correct me if I'm wrong, but Matt is PTL by default now right?

--Dan

__
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] [tc][ec2-api] EC2 API Future

2016-03-20 Thread Bias, Randy
Hello,


   First of all, let me apologize for answering on Alex Levine's behalf, but 
it's late night/early morning in Moscow, so I'm taking the liberty.

   Second, Alex Levine was recently made PTL of the EC2-API project when it was 
formally accepted as an official project, but failed to understand that he 
would need to nominate himself again during the election process, since there 
was such a short gap.

   Third, as Tim points out, there is still significant usage of the EC2 APIs 
in OpenStack.  In fact, usage has been increasing.  We have also begun to see 
greater participation in the development process.

   Finally, it is true that my team has not been as active on the APIs 
recently; however, there is a very good reason for that.  We are small and 
recently focused on working with the RefStack team on adding new capabilities 
to RefStack and new tests to Tempest to create a way to test for EC2 API 
interoperability and compatibility.  While this isn't work on the EC2 APIs 
themselves, it is adjacent and important for their uptake, usage, and 
evaluation, particularly by teams who want to integrate them into their 
products.

   My team is small, 5 people, but we're focused exclusively on OpenStack at 
EMC, and the EC2 APIs will continue to be a top 3 priority for us for the 
foreseeable future.

   Ideally what we would do is put Alex in as PTL for the EC2 APIs and give us 
some more time to make progress.  From our perspective, things in this area 
have actually been going swimmingly lately.


Best,


--Randy



From: Tim Bell [tim.b...@cern.ch]
Sent: Sunday, March 20, 2016 12:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc][ec2-api] EC2 API Future

Doug,

Given that the EC2 functionality is currently in use by at least 1/6th of 
production clouds 
(https://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf page 
34), this is a worrying situation.

The EC2 functionality was recently deprecated from Nova on the grounds that the 
EC2 API project was the correct way to proceed. With the proposal now to not 
have an EC2 API project at all, this will leave many in the community confused.

Tim




On 20/03/16 17:48, "Doug Hellmann"  wrote:

>...
>
>The EC2-API project doesn't appear to be very actively worked on.
>There is one very recent commit from an Oslo team member, another
>couple from a few days before, and then the next one is almost a
>month old. Given the lack of activity, if no team member has
>volunteered to be PTL I think we should remove the project from the
>official list for lack of interest.
>
__
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] [magnum] High Availability

2016-03-20 Thread Hongbin Lu
The Magnum team discussed Anchor several times (in the design summit/midcycle). 
According to what I remembered, the conclusion is to leverage Anchor though 
Barbican (presumably there is an Anchor backend for Barbican). Is Anchor 
support in Barbican still in the roadmap?

Best regards,
Hongbin

> -Original Message-
> From: Clark, Robert Graham [mailto:robert.cl...@hpe.com]
> Sent: March-20-16 1:57 AM
> To: maishsk+openst...@maishsk.com; OpenStack Development Mailing List
> (not for usage questions)
> Subject: Re: [openstack-dev] [magnum] High Availability
> 
> At the risk of muddying the waters further, I recently chatted with
> some of you about Anchor, it's an ephemeral PKI system setup to provide
> private community PKI - certificate services for internal systems, a
> lot like k8 pods.
> 
> An overview of why revocation doesn't work very well in many cases and
> how ephemeral PKI helps: https://openstack-
> security.github.io/tooling/2016/01/20/ephemeral-pki.html
> 
> First half of a threat analysis on Anchor, the Security Project's
> implementation of ephemeral PKI: https://openstack-
> security.github.io/threatanalysis/2016/02/07/anchorTA.html
> 
> This might not solve your problem, it's certainly not a direct drop in
> for Barbican (and it never will be) but if your primary concern is
> Certificate Management for internal systems (not presenting
> certificates over the edge of the cloud) you might find some of it's
> properties valuable. Not least, it's trivial to HA being stateless and
> it's trivial to deploy being a single Pecan service.
> 
> There's a reasonably complete deck on Anchor here:
> https://docs.google.com/presentation/d/1HDyEiSA5zp6HNdDZcRAYMT5GtxqkHrx
> brqDRzITuSTc/edit?usp=sharing
> 
> And of course, code over here:
> http://git.openstack.org/cgit/openstack/anchor
> 
> Cheers
> -Rob
> 
> > -Original Message-
> > From: Maish Saidel-Keesing [mailto:mais...@maishsk.com]
> > Sent: 19 March 2016 18:10
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [magnum] High Availability
> >
> > Forgive me for the top post and also for asking the obvious (with my
> > Operator hat on)
> >
> > Relying on an external service for certificate store - is the best
> > option - assuming of course that the certificate store is actually
> > also highly available.
> >
> > Is that the case today with Barbican?
> >
> > According to the architecture docs [1] I see that they are using a
> > relational database. MySQL? PostgreSQL? Does that now mean we have an
> > additional database to maintain, backup, provide HA for as an
> Operator?
> >
> > The only real reference I can see to anything remotely HA is this [2]
> > and this [3]
> >
> > An overall solution is highly available *only* if all of the parts it
> > relies are also highly available as well.
> >
> >
> > [1]
> >
> http://docs.openstack.org/developer/barbican/contribute/architecture.h
> > tml#overall-architecture [2]
> > https://github.com/cloudkeep-ops/barbican-vagrant-zero
> > [3]
> > http://lists.openstack.org/pipermail/openstack/2014-March/006100.html
> >
> > Some food for thought
> >
> > --
> > Best Regards,
> > Maish Saidel-Keesing
> >
> >
> > On 03/18/16 17:18, Hongbin Lu wrote:
> > > Douglas,
> > >
> > > I am not opposed to adopt Barbican in Magnum (In fact, we already
> > > adopted Barbican). What I am opposed to is a Barbican lock-in,
> which
> > already has a negative impact on Magnum adoption based on our
> > feedback. I also want to see an increase of Barbican adoption in the
> future, and all our users have Barbican installed in their clouds. If
> that happens, I have no problem to have a hard dependency on Barbican.
> > >
> > > Best regards,
> > > Hongbin
> > >
> > > -Original Message-
> > > From: Douglas Mendizábal [mailto:douglas.mendiza...@rackspace.com]
> > > Sent: March-18-16 9:45 AM
> > > To: openstack-dev@lists.openstack.org
> > > Subject: Re: [openstack-dev] [magnum] High Availability
> > >
> > > Hongbin,
> > >
> > > I think Adrian makes some excellent points regarding the adoption
> of
> > > Barbican.  As the PTL for Barbican, it's frustrating to me to
> > constantly hear from other projects that securing their sensitive
> data
> > is a requirement but then turn around and say that deploying Barbican
> is a problem.
> > >
> > > I guess I'm having a hard time understanding the operator persona
> > > that is willing to deploy new services with security features but
> > unwilling to also deploy the service that is meant to secure
> sensitive data across all of OpenStack.
> > >
> > > I understand one barrier to entry for Barbican is the high cost of
> > > Hardware Security Modules, which we recommend as the best option
> for
> > the Storage and Crypto backends for Barbican.  But there are also
> > other options for securing Barbican using open source software like
> DogTag or SoftHSM.
> > >
> > > I also expect Barbican adoption to increase in the future, and 

Re: [openstack-dev] [magnum] High Availability

2016-03-20 Thread Hongbin Lu
Thanks for your inputs. It sounds like we have no other option besides Barbican 
as long as we need to store credentials in Magnum. Then I have a new proposal: 
switch to an alternative authentication mechanism that doesn't require to store 
credentials in Magnum. For example, the following options are available in 
Kubernetes [1]:

· Client certificate authentication

· Token File

· OpenID Connect ID Token

· Basic authentication

· Keystone authentication

Could we pick one of those?

[1] http://kubernetes.io/docs/admin/authentication/

Best regards,
Hongbin

From: Dave McCowan (dmccowan) [mailto:dmcco...@cisco.com]
Sent: March-19-16 10:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] High Availability


The most basic requirement here for Magnum is that it needs a safe place to 
store credentials.  A safe place can not be provided by just a library or even 
by just a daemon.  Secure storage is provided by either hardware solution (an 
HSM) or a software solution (SoftHSM, DogTag, IPA, IdM).  A project should give 
a variety of secure storage options to the user.

On this, we have competing requirements.  Devs need a turnkey option for easy 
testing locally or in the gate.  Users kicking the tires want a realistic 
solution they try out easily with DevStack.  Operators who already have secure 
storage deployed for their cloud want an option that plugs into their existing 
HSMs.

Any roll-your-own option is not going to meet all of these requirements.

A good example, that does meet all of these requirements, is the key manager 
implementation in Nova and Cinder. [1] [2]

Nova and Cinder work together to provide volume encryption, and like Magnum, 
have a need to store and share keys securely.  Using a plugin architecture, and 
the Barbican API, they implement a variety of key storage options:
- Fixed key allows for insecure stand alone operation, running only Nova and 
Cinder
- Barbican with static key, allows for easy deployment that can be started 
within DevStack by few lines of config.
- Barbican with a secure backend, allows for production grade secure storage of 
keys that has been tested on a variety of HSMs and software options.

Barbican's adoption is growing.  Nova, Cinder, Neutron LBaaS, Sahara, and 
Magnum all have implementations using Barbican.  Swift and DNSSec also have use 
cases.  There are both RPM and Debian packages available for Barbican.  There 
are (at least tech preview)  versions of puppet modules, Ansible playbooks, and 
DevStack plugins to deploy Barbican.

In summary, I think using Barbican absorbs the complexity of doing secure 
storage correctly.  It gives operators production grade secure storage options, 
while giving devs easier options.

--Dave McCowan

[1] https://github.com/openstack/nova/tree/master/nova/keymgr
[2] https://github.com/openstack/cinder/tree/master/cinder/keymgr

From: Hongbin Lu >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, March 18, 2016 at 10:52 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [magnum] High Availability

OK. If using Keystone is not acceptable, I am going to propose a new approach:

? Store data in Magnum DB

? Encrypt data before writing it to DB

? Decrypt data after loading it from DB

? Have the encryption/decryption key stored in config file

? Use encryption/decryption algorithm provided by a library

The approach above is the exact approach used by Heat to protect hidden 
parameters [1]. Compared to the Barbican option, this approach is much lighter 
and simpler, and provides a basic level of data protection. This option is a 
good supplement to the Barbican option, which is heavy but provides advanced 
level of protection. It will fit into the use cases that users don't want to 
install Barbican but want a basic protection.

If you disagree, I would request you to justify why this approach works for 
Heat but not for Magnum. Also, I also wonder if Heat has a plan to set a hard 
dependency on Barbican for just protecting the hidden parameters.

If you don't like code duplication between Magnum and Heat, I would suggest to 
move the implementation to a oslo library to make it DRY. Thoughts?

[1] 
https://specs.openstack.org/openstack/heat-specs/specs/juno/encrypt-hidden-parameters.html

Best regards,
Hongbin

From: David Stanek [mailto:dsta...@dstanek.com]
Sent: March-18-16 4:12 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] High Availability


On Fri, Mar 18, 2016 at 4:03 PM Douglas Mendizábal 

Re: [openstack-dev] [oslo][all] What would you like changed/fixed/new in oslo??

2016-03-20 Thread Joshua Harlow

On 03/20/2016 10:00 AM, Adam Young wrote:

I started with a blog post here:

http://adam.younglogic.com/2016/03/what-can-talk-to-what-on-the-openstack-message-broker/


and did a brief spike here:

http://adam.younglogic.com/2016/03/tie-your-rabbit-down/

We made the mistake of pursuing HMAC back several releases ago.  It lead
to Kite.  We don't need that yet.


Nice I like the big table @ 
http://adam.younglogic.com/2016/03/what-can-talk-to-what-on-the-openstack-message-broker/


As for HMAC several years/releases ago, what was the issue (just 
wondering)? Just to much load on controller nodes to do verification? 
Not enough adoption, something else...?


-Josh

__
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] [Horizon] How do we move forward with xstatic releases?

2016-03-20 Thread Christopher Aedo
On Sun, Mar 20, 2016 at 1:26 PM, Richard Jones  wrote:
> Unfortunately none of this discussion solves the substantive issue which is
> that we cannot release an xstatic package without breaking the gate.
>
> We currently have one solution that's a close to viable as we've been able
> to get: move the version pinning for xstatic packages out of
> upper-constraints and into Horizon's repository, and hope that the
> app-catalog server and Horizon stay in step or that they're never installed
> on the same debian/redhat system (or if they *are* then one of them is
> installed in a virtualenv).

The Horizon plugin for the app catalog[1] should have no problem
staying in step with Horizon.  Ultimately our intention is to make
this plugin so desirable it becomes a native part of Horizon so
enabling in a cloud becomes as simple as a config switch.  We're not
ready for that yet of course, so please don't let that comment
distract the thread :)  I am looking forward to discussing this with
more people in Austin though!

Regardless, we will work with you to make sure our efforts proceed to
be tightly coupled to Horizon.  This approach makes the most sense to
me.

[1]: http://git.openstack.org/cgit/openstack/app-catalog-ui/

-Christopher

__
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] [TripleO] propose EmilienM for core

2016-03-20 Thread Juan Antonio Osorio
+1
On 20 Mar 2016 20:27, "Dan Prince"  wrote:

> I'd like to propose that we add Emilien Macchi to the TripleO core
> review team. Emilien has been getting more involved with TripleO during
> this last release. In addition to help with various Puppet things he
> also has experience in building OpenStack installation tooling,
> upgrades, and would be a valuable prospective to the core team. He has
> also added several new features around monitoring into instack-
> undercloud.
>
> Emilien is currently acting as the Puppet PTL. Adding him to the
> TripleO core review team could help us move faster towards some of the
> upcoming features like composable services, etc.
>
> If you agree please +1. If there is no negative feedback I'll add him
> next Monday.
>
> Dan
>
> __
> 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] [Horizon] How do we move forward with xstatic releases?

2016-03-20 Thread Richard Jones
Unfortunately none of this discussion solves the substantive issue which is
that we cannot release an xstatic package without breaking the gate.

We currently have one solution that's a close to viable as we've been able
to get: move the version pinning for xstatic packages out of
upper-constraints and into Horizon's repository, and hope that the
app-catalog server and Horizon stay in step or that they're never installed
on the same debian/redhat system (or if they *are* then one of them is
installed in a virtualenv).


 Richard


On 17 March 2016 at 19:00, Thomas Goirand  wrote:

> On 03/17/2016 07:23 AM, Richard Jones wrote:
> > There's a basic difference here though. Your traditional "installed
> > components" are pieces of software and data used *by programs on that
> > system.*
> >
> > The components we're talking about here are, as far as the system is
> > concerned, opaque data to be transmitted over HTTP(S) to a web browser
> > client which then makes use of that data in some manner.
> >
> > There are no cross-program compatibility issues stemming from having
> > multiple different versioned copies of such client-side files on a
> > system
>
> The same way, we could have multiple version of fonts, tzdata, SSL root
> certificates and so on. There wouldn't be any compatibility issues.
> Though it's still not the right thing to do at a distribution level.
>
> Have you noticed also that in the Windows world, each program carries
> its .dll, which are supposed to be shared object, but in fact, they
> aren't shared? Yes, it is easier to do so.
>
> > - this is why the web development world has standardised on
> > tooling that *makes it easy to do so*. Different client-side web
> > applications *should* be able to use different versions of components.
>
> The same was as for shared .so libraries, that's not the correct way to
> do things. Even though the JavaScript objects aren't executed by the
> system (well, if we forget that nodejs exists), there's still potential
> bugs and security problems with them, and they may require maintenance.
>
> > xstatic shoe-horns that freedom of client-side application component
> > usage into a one-size-must-fit-all world that fundamentally only exists
> > because programs on a system can get confused when multiple versions are
> > installed on that system[1].
>
> I wouldn't say it this way. To me, they are just tools which makes it
> easy for us to stop the duplication madness of the same files.
>
> Have a look:
> # apt-file search jquery.js | grep -v doc | wc -l
> 128
>
> This is 127 bugs which should be fixed currently with the embedded
> jquery. I hardly see how one could argue this is a good thing. I hope we
> can be better citizens than this.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __
> 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] [TripleO] propose EmilienM for core

2016-03-20 Thread Qasim Sarfraz
+1

On Sunday, March 20, 2016, Dan Prince  wrote:

> I'd like to propose that we add Emilien Macchi to the TripleO core
> review team. Emilien has been getting more involved with TripleO during
> this last release. In addition to help with various Puppet things he
> also has experience in building OpenStack installation tooling,
> upgrades, and would be a valuable prospective to the core team. He has
> also added several new features around monitoring into instack-
> undercloud.
>
> Emilien is currently acting as the Puppet PTL. Adding him to the
> TripleO core review team could help us move faster towards some of the
> upcoming features like composable services, etc.
>
> If you agree please +1. If there is no negative feedback I'll add him
> next Monday.
>
> Dan
>
> __
> 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
>


-- 
Regards,
Qasim Sarfraz
__
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] [TripleO] propose EmilienM for core

2016-03-20 Thread Adam Young

On 03/20/2016 02:22 PM, Dan Prince wrote:

I'd like to propose that we add Emilien Macchi to the TripleO core
review team. Emilien has been getting more involved with TripleO during
this last release. In addition to help with various Puppet things he
also has experience in building OpenStack installation tooling,
upgrades, and would be a valuable prospective to the core team. He has
also added several new features around monitoring into instack-
undercloud.

Emilien is currently acting as the Puppet PTL. Adding him to the
TripleO core review team could help us move faster towards some of the
upcoming features like composable services, etc.

If you agree please +1. If there is no negative feedback I'll add him
next Monday.

Dan

__
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
I'm a big fan of Emilien.  He's been great at helping iron out the 
intersection between Keystone, Tripleo, and Puppet.  Big +1 from me.


__
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] [tc][ec2-api] EC2 API Future

2016-03-20 Thread Tim Bell

Doug,

Given that the EC2 functionality is currently in use by at least 1/6th of 
production clouds 
(https://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf page 
34), this is a worrying situation.

The EC2 functionality was recently deprecated from Nova on the grounds that the 
EC2 API project was the correct way to proceed. With the proposal now to not 
have an EC2 API project at all, this will leave many in the community confused.

Tim




On 20/03/16 17:48, "Doug Hellmann"  wrote:

>...
>
>The EC2-API project doesn't appear to be very actively worked on.
>There is one very recent commit from an Oslo team member, another
>couple from a few days before, and then the next one is almost a
>month old. Given the lack of activity, if no team member has
>volunteered to be PTL I think we should remove the project from the
>official list for lack of interest.
>
__
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] [TripleO] propose trown for core

2016-03-20 Thread Dan Prince
I'd like to propose that we add John Trowbridge to the TripleO core
review team. John has become one of the goto guys in helping to chase
down upstream trunk chasing issues. He has contributed a lot to helping
keep general CI issues running and been involved with several new
features over the past year around node introspection, etc. His
involvement with the RDO team also gives him a healthy prospective
about sane releasing practices, etc.

John doesn't have the highest TripleO review stats ATM but I expect his
stats to continue to climb. Especially with his work on upcoming
improvements like tripleo-quickstart, etc. Having John on board the
core team would help drive these projects and it would also be great to
have him able to land fixes related to trunk chasing, etc. I expect
he'll gradually jump into helping with other TripleO projects as well.

If you agree please +1. If there is no negative feedback I'll add him
next Monday.

Dan

__
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] [TripleO] propose EmilienM for core

2016-03-20 Thread Dan Prince
I'd like to propose that we add Emilien Macchi to the TripleO core
review team. Emilien has been getting more involved with TripleO during
this last release. In addition to help with various Puppet things he
also has experience in building OpenStack installation tooling,
upgrades, and would be a valuable prospective to the core team. He has
also added several new features around monitoring into instack-
undercloud.

Emilien is currently acting as the Puppet PTL. Adding him to the
TripleO core review team could help us move faster towards some of the
upcoming features like composable services, etc.

If you agree please +1. If there is no negative feedback I'll add him
next Monday.

Dan

__
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] working on bug reports; what blocks you?

2016-03-20 Thread Kashyap Chamarthy
On Fri, Mar 18, 2016 at 07:01:34PM +0100, Markus Zoeller wrote:
> Kashyap Chamarthy  wrote on 03/18/2016 07:28:09 AM:

[...]

> > Writing a thoughtful report is hard and time-taking.
> 
> Yeah, and I assume that's the reason many bug reports lack that
> information. I have the hope to dig deeper into the logging
> capabilities of Nova during the P cycle, to figure out how much we
> internally already know but don't offer easily enough. 

As you know, we have some bits in place:

  - Guru Meditation Reports[1].  E.g. `kill -s USR1 `pgrep nova-compute`

  - General logging/tracing of API calls via 

  - For Virt drivers, server-side libvirt/QEMU logging.  We have the
relevant log filters enabled in DevStack[2], so Gate machines have
these enabled.  For external bugs being reported in this area,
people have to enable these explicitly and repeat their tests.

  - General logging/tracing of API calls via 'debug|verbose = True'

[1] http://docs.openstack.org/developer/nova/gmr.html
[2] 
http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/nova_plugins/functions-libvirt#n104

> In some bug reports I suggested to use sosreport and attach the file
> then, but I didn't see that happen.

Yeah, that's a good idea, if people could remember to do that, as it
adds far more context from the system than merely OpenStack or its
immediate relevant logs, reducing the reporter <-> triager roundtrip.

> In my head there would be openstack CLI commands like these two:
> 
> $ openstack report-bug 
> $ openstack report-bug --last 10m 
> 
> That should then result in an upstream bug report which answers the
> usual questions we have. Don't ask me details how this would happen.

[...]
 
> In an ideal world with unlimited resources we could do that on our own
> without asking the reporter, but I guess we should do the "please 
> recheck if it's in master" thing more often.

We could certainly try.

-- 
/kashyap

__
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] report from Brno code sprint, Mar 14-16

2016-03-20 Thread Sean M. Collins
Ihar Hrachyshka wrote:
> 
> One thing that we discussed on the event is updating networking-guide with
> detailed description of the upgrade process for neutron. We already have
> some pieces scattered there [f.e. we have some coverage for
> neutron-db-manage tool] but it’s nothing complete or deep enough. That’s
> something we will look into improving at the start of the N cycle.

If I can make a suggestion, let's put it in the operations guide. I
think we can add a Neutron specific chapter - and I have a review up as
WIP to remind myself:

https://review.openstack.org/291785

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


Re: [openstack-dev] [oslo][all] What would you like changed/fixed/new in oslo??

2016-03-20 Thread Adam Young

On 03/19/2016 11:33 PM, Joshua Harlow wrote:

Howday all,

Just to start some conversation for the next cycle,

I wanted to start thinking about what folks may like to see in oslo 
(or yes, even what u dislike in any of the oslo libraries).


For those who don't know, oslo[1] is a lot of libraries (27+) so one 
of my complaints (and one I will try to help make better) is that most 
people probably don't know what the different 'offerings' of these 
libraries are or how to use them (docs, tutorials, docs, and more docs).


I'll pick another pet-peeve of mine as a second one to get people 
thinking.


2) The lack of oslo.messaging having a good security scheme (even 
something basic as a hmac or signature that can be verified, this 
scares the heck out of me what is possible over RPC) turned on by 
default so I'd like to start figuring out how to get *something* 
(basic == HMAC signature, or maybe advanced == barbican or ???)


Red Herring.  We don't need HMAC. We need to make better use of the 
tools in Rabbit.


1.  Split the vhosts between notifications and control plan.  The code 
is in place to do this already, but we need to update the configuration 
tools to make use of that.


2.  Drop the default login and password.  All services, and all compute 
nodes should get their own Rabbit user and an autogenerated password.  
Even better would be to use Client Certificate validaltion, but that 
requires a CA.


3. We desperately need a CA story.

4.  ACLs set up aroun the reply queus.  If I send a message to 
openstack-compute-15, only that compute should be able to rite to the 
resposne queue.  This could be done with a naming scheme and regex in 
the ACL.



HMAC is crypto, and is going to put a load on the CPUs.  While this is 
acceptable in the generation of messages from the Compute nodes 
(distributed load) validation and generation of HMAC on the controller 
nodes is just an additional requirement.



What I would like to see, before we engineer anything else, is a map of 
the components that talk via the Broker, the topics and queues they 
should have access to, and the paths of messages between them.


I started with a blog post here:

http://adam.younglogic.com/2016/03/what-can-talk-to-what-on-the-openstack-message-broker/

and did a brief spike here:

http://adam.younglogic.com/2016/03/tie-your-rabbit-down/

We made the mistake of pursuing HMAC back several releases ago.  It lead 
to Kite.  We don't need that yet.







What other thoughts do people have?

Good, bad, crazy (just keep it PG-13) thoughts are ok ;)

-Josh

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


__ 


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] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

2016-03-20 Thread Doug Hellmann
I won't be able to make the TC meeting this week because of travel,
so I wanted to lay out my thoughts on the three PTL-less projects
based on the outcome of the recent election (EC2-API, Winstackers,
and Stable Maintenance).

The EC2-API project doesn't appear to be very actively worked on.
There is one very recent commit from an Oslo team member, another
couple from a few days before, and then the next one is almost a
month old. Given the lack of activity, if no team member has
volunteered to be PTL I think we should remove the project from the
official list for lack of interest.

The Winstackers project is much more active in the repository, but
there doesn't seem to be much traffic on the mailing list. It's not
clear why no one signed up to be PTL, and I couldn't find a notice
that the current PTL is not running. I'm tempted to suggest removing
Winstackers from the official project list for lack of participation
in project governance, but perhaps a probation period is in order
since it's a relatively new team. Probation would depend on having
the team find a PTL volunteer, of course.

The situation with the Stable Maintenance team is ironically shaky.
The outgoing PTL has entered the Nova PTL election, though he has
said he would take up the Stable team work again if he does not
become Nova PTL. That election will not be over until 24 March, so
I think we should wait before taking any action. If Matt becomes
Nova PTL, and no other volunteer steps forward, I will take on the
responsibilities, though I do want to keep the Stable team separate
from the Release team. That said, I would very much prefer to have
someone else be the Stable team PTL so I hope we can find a volunteer.

Doug

__
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] [TaskFlow] TaskFlow persistence

2016-03-20 Thread Joshua Harlow

Lingxian Kong wrote:

Kanthi, sorry for chiming in, I suggest you may have a chance to take
a look at Mistral[1], which is the workflow as a service in
OpenStack(or without OpenStack).


Out of curiosity, why? Seems the ML post was about 'TaskFlow 
persistence' not mistral, just saying (unsure how it is relevant to 
mention mistral in this)...


Back to getting more coffee...

-Josh


__
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] [all][api] New API Guidelines Ready for Cross Project Review

2016-03-20 Thread Chris Dent


The following proposed API guidelines are available for broader
review by interested parties.

* https://review.openstack.org/#/c/281511/
  Delete multiple metadata items with a single request

* https://review.openstack.org/#/c/260292/
  Add unexpected attribute guideline

* https://review.openstack.org/#/c/286253
  Avoid redundancy in header values

* https://review.openstack.org/#/c/276709
  Added tags restrictions to the tagging guidelines

* https://review.openstack.org/#/c/243429
  Add version discover guideline for API microversions


--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
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] [release][manila] Manila Mitaka RC1 available

2016-03-20 Thread Doug Hellmann
Hello everyone,

The release candidate for Manila for the end of the Mitaka cycle
is available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/manila/manila-2.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final
Mitaka Manila release on April 7th. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/mitaka release
branch at:

http://git.openstack.org/cgit/openstack/manila/log/?h=stable/mitaka

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/manila/+filebug

and tag it *mitaka-rc-potential* to bring it to the Manila release
crew's attention.

Note that the "master" branch of Manila is now open for Newton
development, and feature freeze restrictions no longer apply there!

Doug

__
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] [release][telemetry] Aodh Mitaka RC1 available

2016-03-20 Thread Doug Hellmann
Hello everyone,

The Telemetry team's release candidate for Aodh for the end
of the Mitaka cycle is available!  You can find the RC1 source code
tarball at:

https://tarballs.openstack.org/aodh/aodh-2.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final
Mitaka Aodh release on April 7th. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/mitaka release
branch at:

http://git.openstack.org/cgit/openstack/aodh/log/?h=stable/mitaka

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/ceilometer/+filebug

and tag it *mitaka-rc-potential* to bring it to the Telemetry release
crew's attention.

Note that the "master" branch of Aodh is now open for Newton
development, and feature freeze restrictions no longer apply there!

Doug

__
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] [release][telemetry] Ceilometer Mitaka RC1 available

2016-03-20 Thread Doug Hellmann
Hello everyone,

The Telemetry team's release candidate for Ceilometer for the end
of the Mitaka cycle is available!  You can find the RC1 source code
tarball at:

https://tarballs.openstack.org/ceilometer/ceilometer-6.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final
Mitaka Ceilometer release on April 7th. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/mitaka release
branch at:

http://git.openstack.org/cgit/openstack/ceilometer/log/?h=stable/mitaka

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/ceilometer/+filebug

and tag it *mitaka-rc-potential* to bring it to the Telemetry release
crew's attention.

Note that the "master" branch of Ceilometer is now open for Newton
development, and feature freeze restrictions no longer apply there!

Doug

__
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] Packaging CI for Fuel

2016-03-20 Thread Aleksandra Fedorova
Hi, everyone,

we'd like to announce Packaging CI for Fuel.

For now there are no extended tests, just package builds.
Package-based test will be added later in Newton development cycle.

Current workflow:

* for every request we build a package and publish it to temporary
repository, which you can use in local tests

http://packages.fuel-infra.org/review/

* on merge we build package and publish to main repo at:

http://packages.fuel-infra.org/repositories/

Links and description is available at:

https://wiki.openstack.org/wiki/Fuel/CI#Packaging_CI_Overview

We plan to enable voting for this CI by the end of the week. It will
vote as "Fuel Packaging CI".

-- 
Aleksandra Fedorova
CI Team Lead
bookwar

__
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] [QA][all] Propose to remove negative tests from Tempest

2016-03-20 Thread Kairat Kushaev

Also curious about this. It seems weird to separate the 'positive' and
the 'negative' ones, assuming those patches are mostly contributed by
the same group of developers.


Yeah, agree. This approach leads to situation when I need to look at two
places to observe test coverage for each component.
Also when I would like to add some tests I need to contribute to two places
which is not convenient for reviewers for contributors IMO.


Best regards,
Kairat Kushaev

On Thu, Mar 17, 2016 at 8:31 AM, Qiming Teng 
wrote:

> >
> > I'd love to see this idea explored further. What happens if Tempest
> > ends up without tests, as a library for shared code as well as a
> > centralized place to run tests from via plugins?
> >
>
> Also curious about this. It seems weird to separate the 'positive' and
> the 'negative' ones, assuming those patches are mostly contributed by
> the same group of developers.
>
> 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] [trove] We're open for business on Newton

2016-03-20 Thread Amrith Kumar
This morning, Craig tagged RC1 on trove[1] and a short while ago I tagged RC1 
on trove-dashboard[2]. The python-troveclient for Mitaka was tagged some days 
ago[3].

At this point, changes merged into master will be headed for Newton.

Any changes that are required for Mitaka RC2 will have to be backported to 
stable/mitaka.

Thanks,

-amrith

[1] https://review.openstack.org/294454
[2] https://review.openstack.org/294547
[3] https://review.openstack.org/291162

__
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] [tc] Question about electorate for project without gerrit contribution

2016-03-20 Thread Hayes, Graham
On 16/03/2016 04:47, Tony Breeds wrote:
> On Tue, Mar 15, 2016 at 09:41:41PM +, Hayes, Graham wrote:
>> I do not see the time frame for defining an electorate there.
>>
>> PTL seats are completely renewed every 6 months. A separate election is
>> run for
>> each project team. These elections are collectively held 5 weeks prior
>> to each
>> design summit, with nominations due 6 weeks prior to the summit and
>> elections
>> held open for no less than five business days.
>>
>> The way the rules are currently worded if the extra ATC patch merged
>> before the deadline for PTL nomination anyone in that patch would be
>> able to run.
>>
>> Where do we define the cut off date for electorate definition?
>
> [1] roughly defines it as "committed a change to a repository of a project 
> over
> the last two 6-month release cycles"

Actually the way that reads is that for mitaka APCs would be based on 
Kilo and Liberty - it should probably read

"committed a change to a repository of a project over the last 6-month 
release cycle and the current 6-month release cycle"

But, that is a digression.

> For the sake of generating the full APC roles we (the election officials) 
> define
> the exact range and communicate that[2].  At approximately the same time the
> governance repo is tagged and used for reference[3].  There are no extra-ATCs
> for Packaging-deb[4].

That is what I was looking for.

Is this recorded, or is there a list on rules that are passed on?

If there is no current place I would suggest that a section called
"Defining the Electorate" is added to the Charter, in the interests of
Openness - the way the charter is currently written does not indicate
that there is a cut off date during the cycle.


> That is how we define the electorate, changing that mid-election is not an 
> option.

Why not? A lot of elections (both for Governments and in NGOs) allow
for a "supplemental register" - to allow for this exact thing.

> Yours Tony.
> [1] 
> http://governance.openstack.org/reference/charter.html#voters-for-ptl-seats-apc
> [2] https://wiki.openstack.org/wiki/PTL_Elections_March_2016#Electorate
> [3] 
> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=march-2016-elections
> [4] 
> https://github.com/openstack/governance/blob/march-2016-elections/reference/projects.yaml#L3147-L3282
>


__
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] purplerbot irc bot for logs and transclusion

2016-03-20 Thread Chris Dent

On Fri, 18 Mar 2016, Anita Kuno wrote:


On 03/16/2016 10:45 AM, Paul Belanger wrote:

I would like to see it added to openstack-infra so we can properly
manage it.


I agree with Paul here.


purpler (which includes the bot) is now packaged and on pypi:

   https://pypi.python.org/pypi/purpler

I tried to:

* package it in a way that ought to make it relatively straightforward
  to run in a variety of environments
* remove my little hacks that I put it in "just to get it working"

It doesn't have good tests, but has been running for a while,
reasonably well.


To that end I have added an item on next week's infra meeting agenda
about IRC Bots with the aim of discussing this, as this isnot the only
bot folks seem to want to run.
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting


I've put this on my calendar so will attend. I'll also hang out in
#openstack-infra so if anybody wants to discuss it ping me there.

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
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] Proposing Tony Breeds for stable-maint-core

2016-03-20 Thread Gary Kotton
+1

From: Dave Walker >
Reply-To: OpenStack List 
>
Date: Sunday, March 20, 2016 at 12:27 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [stable] Proposing Tony Breeds for 
stable-maint-core


On 18 Mar 2016 20:11, "Matt Riedemann" 
> wrote:
>
> I'd like to propose tonyb for stable-maint-core.

> Please respond with ack/nack.

+1, Great work Tony.

--
Kind Regards,
Dave Walker
__
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] [manila] FFE for update_access implementation for Ganesha lib and GlusterFS

2016-03-20 Thread Doug Hellmann
Excerpts from Csaba Henk's message of 2016-03-16 15:02:40 +0100:
> Hi,
> 
> I'm asking for a Feature Free Exception for the update_access code for
> Ganesha library and the two GlusterFS drivers (glusterfs, glusterfs-native).
> 
> This benefits the whole project in terms of getting closer to the point
> when the backward compatiblitly hooks for the old driver access API can be
> retired. There is no change in functionality, except for one thing: the new
> code takes advantage of the new semantic feature of update_access, that is,
> recovery situation is explicit; thus with Ganesha, where actually a
> reset/restore operation can be performed, we can trigger this mechanism
> only if really that's what's being asked for (contrary to the earlier
> practice where reset/restore was done on each m-shr startup).
> 
> The impact of the change is limited to the GlusterFS drivers (Ganesha
> library currently is used only for these drivers).
> 
> The following changes are proposed:
> 
> https://review.openstack.org/282602 ("ganesha: implement update_access")
> https://review.openstack.org/291151 ("glusterfs: Implement update_access()
> method")
> 
> Thanks,
> Csaba

The feature freeze deadline was March 4, over a week ago. This week
projects are supposed to be preparing their release candidates and only
critical bugs should trigger another release after that and before the
final release on Apr 7. Please consider strongly delaying this work
until Newton opens.

Doug

__
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][Neutron] Mitaka RC1 available

2016-03-20 Thread Armando M.
On 18 March 2016 at 00:16, Jeremy Stanley  wrote:

> On 2016-03-17 09:44:59 +0530 (+0530), Armando M. wrote:
> > Unfortunately, Neutron is also going to need an RC2 due to
> > upstream CI issues triggered by infra change [1] that merged right
> > about the same time RC1 was being cut.
>
> Do you have any details on the impact that caused for Neutron? I
> don't think I heard about it. Was there another ML thread I missed?
>

No, I didn't think a discussion was necessary. We did file bugs though:

https://bugs.launchpad.net/neutron/+bug/1558289
https://bugs.launchpad.net/neutron/+bug/1558397
https://bugs.launchpad.net/neutron/+bug/1558355

Thanks,
Armando


> --
> Jeremy Stanley
>
> __
> 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] [Magnum] COE drivers spec

2016-03-20 Thread Jamie Hannaford
Hi all,


I'm writing the spec for the COE drivers, and I wanted some feedback about what 
it should include. I'm trying to reconstruct some of the discussion that was 
had at the mid-cycle meet-up, but since I wasn't there I need to rely on people 
who were :)


>From my perspective, the spec should recommend the following:


1. Change the BayModel `coe` attribute to `bay_driver`, the value of which will 
correspond to the name of the directory where the COE code will reside, i.e. 
drivers/{driver_name}


2. Introduce a base Driver class that each COE driver extends. This would 
reside in the drivers dir too. This base driver will specify the interface for 
interacting with a Bay. The following operations would need to be defined by 
each COE driver: Get, Create, List, List detailed, Update, Delete. Each COE 
driver would implement each operation differently depending on their needs, but 
would satisfy the base interface. The base class would also contain common 
logic to avoid code duplication. Any operations that fall outside this 
interface would not exist in the COE driver class, but rather an extension 
situated elsewhere. The JSON payloads for requests would differ from COE to COE.


Cinder already uses this approach to great effect for volume drivers:


https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/lvm.py

https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py


Question: Is this base class a feasible idea for Magnum? If so, do we need any 
other operations in the base class that I haven't mentioned?


3. Each COE driver would have its own Heat template for creating a bay node. It 
would also have a template definition that lists the JSON parameters which are 
fed into the Heat template.


Question: From a very top-level POV, what logic or codebase changes would 
Magnum need Heat templates in the above way?


4. Removal of all old code that does not fit the above paradigm.


?---


Any custom COE operations that are not common Bay operations (i.e. the six 
listed in #2) would reside in a COE extension. This is outside of the scope of 
the COE drivers spec and would require an entirely different spec that utilizes 
a common paradigm for extensions in OpenStack. Such a spec would also need to 
cover how the conductor would link off to each COE. Is this summary correct?


Does Magnum already have a scale manager? If not, should this be introduced as 
a separate BP/spec?


Is there anything else that a COE drivers spec need to cover which I have not 
mentioned??


Jamie



Rackspace International GmbH a company registered in the Canton of Zurich, 
Switzerland (company identification number CH-020.4.047.077-1) whose registered 
office is at Pfingstweidstrasse 60, 8005 Zurich, Switzerland. Rackspace 
International GmbH privacy policy can be viewed at 
www.rackspace.co.uk/legal/swiss-privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
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] Proposing Tony Breeds for stable-maint-core

2016-03-20 Thread Dave Walker
On 18 Mar 2016 20:11, "Matt Riedemann"  wrote:
>
> I'd like to propose tonyb for stable-maint-core.

> Please respond with ack/nack.

+1, Great work Tony.

--
Kind Regards,
Dave Walker
__
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] Proposing Tony Breeds for stable-maint-core

2016-03-20 Thread Ihar Hrachyshka

Matt Riedemann  wrote:

I'd like to propose tonyb for stable-maint-core. Tony is pretty much my  
day to day guy on stable, he's generally in every stable team meeting  
(which is not attended well so I appreciate it), and he's as proactive as  
ever on staying on top of gate issues when they come up, so he's well  
deserving of it in my mind.


Here are review stats for stable for the last 90 days (as defined in the  
reviewstats repo):


http://paste.openstack.org/show/491155/

Tony is also the latest nova-stable-maint core and he's done a great job  
there (as expected) and is very active, which is again much appreciated.


Please respond with ack/nack.


Absolute ack.

Ihar

__
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] [cross-project] [all] Quotas -- service vs. library

2016-03-20 Thread Fox, Kevin M
As an Op, I've seen quota's in the db get out of sync all the time I'm sure 
some of my clouds right now have some stuff out of sync :/

With my dev hat on:
The code is really hard to get right.

There are also a lot of places quota's are missing. quota's per host aggregate, 
quota's for floating ips per external network.

Also hierarchical quota's are going to be important and that will touch a 
million projects too.

Then there's lots of projects that don't implement but the most basic of 
quota's.

Really, centralizing it will be a lot of work initially, but long term, I think 
will pay off in that there will be only one place to fix bugs and add important 
features. It will allow each project to easily add quota's to the places they 
need to be in, since they won't have to write a whole quota system themselves.

With an op hat on again, putting them all in one place will also make it easier 
to administer. "floating ip's on this cloud are ... neutron, so I need to use 
the neutron command to set the quota for that" can be a thing of the past.

Thanks,
Kevin


From: Joshua Harlow [harlo...@fastmail.com]
Sent: Wednesday, March 16, 2016 9:58 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cross-project] [all] Quotas -- service vs. library

On 03/16/2016 05:22 AM, Julien Danjou wrote:
> On Wed, Mar 16 2016, Attila Fazekas wrote:
>
>> The quota usage handling MUST happen in the same DB transaction as the
>> resource record (volume, server..) create/update/delete  .
>
> […]
>
>> We have a transaction capable DB, to help us,
>> not using it would be lame.
>
> Amen to that.

Double amen!

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


[openstack-dev] [neutron] Upgrading from Kilo to Liberty, missing database entries

2016-03-20 Thread Nolan Brubaker
Hello,

Recently when testing neutron upgrades for openstack-ansible, I ran into an 
existing bug [1] where the networksecuritybindings and portsecuritybindings 
tables were not populated after an upgrade from Kilo to Liberty. Updating the 
table manually resolved the issue, as mentioned in the bug, but there’s been no 
further activity since that discovery.

Also mentioned in the bug is a migration [2] that should fix this. From my 
investigation, it appears this migration runs on Kilo install, where the 
networksecuritybindings and portsecuritybindings tables don’t exist. Then, when 
upgrading to Liberty, it is skipped by Alembic as it’s already run. Manually 
running neutron-db-manage again skips this migration because the database is 
already current.

Based on the above, I have 2 main questions:


1) Is this a known issue, or is there possibly a step I’m missing?
2) Is my understanding of the migrations correct, that the migration only runs 
in Kilo then is skipped in Liberty?

Thanks,
Nolan

[1] https://bugs.launchpad.net/neutron/+bug/1509312
[2] 
https://github.com/openstack/neutron/blob/stable/liberty/neutron/db/migration/alembic_migrations/versions/35a0f3365720_add_port_security_in_ml2.py#L46-L54
__
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] [TaskFlow] TaskFlow persistence

2016-03-20 Thread Lingxian Kong
Kanthi, sorry for chiming in, I suggest you may have a chance to take
a look at Mistral[1], which is the workflow as a service in
OpenStack(or without OpenStack).

[1]: http://docs.openstack.org/developer/mistral/

On Sun, Mar 20, 2016 at 5:35 AM, pnkk  wrote:
> Filed it at https://bugs.launchpad.net/taskflow/+bug/1559496
>
> Thanks,
> Kanthi
>
> On Sat, Mar 19, 2016 at 9:30 PM, Joshua Harlow 
> wrote:
>>
>> Interesting error, that could be a bug and perhaps we should ensure
>> upgrade is more thread-safe (with a lock on upgrade); can u open a bug @
>> bugs.launchpad.net/taskflow for that and we can try to add said lock (that
>> should hopefully resolve what u are seeing, although if it doesn't then the
>> bug lies somewhere else).
>>
>> Thanks much!
>>
>> -Josh
>>
>>
>> On 03/19/2016 08:45 AM, pnkk wrote:
>>>
>>> Hi Joshua,
>>>
>>> Thanks for all your inputs.
>>> We are using this feature successfully. But I rarely see an issue
>>> related to concurrency.
>>>
>>> To give you a brief, we use eventlets and every job runs in a separate
>>> eventlet thread.
>>>
>>> In the job execution part, we use taskflow functionality and persist all
>>> the details of the job.
>>>
>>> There we try to get the backend as below. We do upgrade everytime when a
>>> job is executed.
>>>
>>>  backend_uri = cfg.CONF.db.sqlalchemy_url
>>>  conf = {
>>>  'connection': backend_uri,
>>>  }
>>>  self.backend = backends.fetch(conf)
>>>  with contextlib.closing(self.backend.get_connection()) as conn:
>>>  conn.upgrade()
>>>
>>> Now when two jobs start executing at the same time, I see below error.
>>> Failed upgrading database version
>>>DBAPIError: (exceptions.RuntimeError) reentrant call inside
>>> <_io.BufferedReader name=14>
>>>
>>> We have monkey patched eventlet, is it not supposed to take care of
>>> these concurrency issues?
>>>
>>> Below are the versions for related modules in use:
>>> eventlet==0.17.4
>>> taskflow==1.26.0
>>> SQLAlchemy==1.0.9
>>>
>>> Thanks,
>>> Kanthi
>>>
>>> On Fri, Feb 12, 2016 at 1:29 PM, Joshua Harlow >> > wrote:
>>>
>>> pn kk wrote:
>>>
>>> Hi Joshua,
>>>
>>> Yes, sure will do that once I get some window out of my work.
>>>
>>> One last query(hopefully :) ) , can the factory method be an
>>> instance
>>> method of a class?
>>>
>>>
>>> Instance methods are particularly hard to use (since they require an
>>> instance of an object to be useful); so I think the check u have hit
>>> is making sure that if the flow-factory is called to recreate the
>>> flow that it can do so without having import issues. Currently I
>>> believe it doesn't handle instance methods (due to the complexity of
>>> needing an instance attached to that method).
>>>
>>> Perhaps what u want is to provide a function that can be found like:
>>>
>>> def make_flow_factory():
>>> return FlowFactory().flow_factory
>>>
>>> Or make flow_factory a class or static method, which should have the
>>> same/similar effect.
>>>
>>> Hope that makes sense (more queries are fine and welcome!)
>>>
>>>
>>> I tried giving it as "FlowFactory().flow_factory", where
>>> FlowFactory is
>>> my class name. It failed with below error:
>>> ValueError: Flow factory >> of
>>> <__main__.FlowFactory instance at 0x2b43b48>> is not reimportable
>>> by
>>> name __builtin__.instance.flow_factory
>>>
>>> Thanks again
>>> -Kanthi
>>>
>>>
>>> On Thu, Jan 28, 2016 at 12:29 AM, Joshua Harlow
>>> 
>>> >>
>>> wrote:
>>>
>>>  pn kk wrote:
>>>
>>>  Hi,
>>>
>>>  Thanks for the responses. Putting it in a small example
>>>
>>>  def flow_factory(tmp):
>>>return lf.Flow('resume from backend example').add(
>>>TestTask(name='first', test=tmp),
>>>InterruptTask(name='boom'),
>>>TestTask(name='second', test="second task"))
>>>
>>>
>>>  class TestTask(task.Task):
>>>def __init__(self, name, provides=None, test,
>>> **kwargs):
>>>self.test=test
>>>super(TestTask, self).__init__(name,
>>> provides, **kwargs)
>>>def execute(self, *args, **kwargs):
>>>print('executing %s' % self)
>>>return 'ok'
>>>
>>>  class InterruptTask(task.Task):
>>>def execute(self, *args, **kwargs):
>>># DO NOT TRY THIS AT HOME
>>>  

Re: [openstack-dev] [QA][all] Propose to remove negative tests from Tempest

2016-03-20 Thread GHANSHYAM MANN
On Thu, Mar 17, 2016 at 3:24 PM, Kairat Kushaev  wrote:
> 
> Also curious about this. It seems weird to separate the 'positive' and
> the 'negative' ones, assuming those patches are mostly contributed by
> the same group of developers.
> 
>
> Yeah, agree. This approach leads to situation when I need to look at two
> places to observe test coverage for each component.
> Also when I would like to add some tests I need to contribute to two places
> which is not convenient for reviewers for contributors IMO.

But currently also it is same situation where some negative tests are
in tempest and some are in project repo either as functional tests or
unit  [1].
Whenever we review new negative test patch, we have to check whether
that already exist in respective project or not if not then we can
consider it to add in tempest.

This could have valid if projects does not have any negative testing
in their tree and all reply on tempest tests for that.

Note- I am considering the surface level negative tests here, but yea
if that negative tests covers larger scope than just negative input
testing then, yes it should be in one place always.

[1]: 
https://github.com/openstack/keystone/blob/master/keystone/tests/unit/test_v3_identity.py

>
>
> Best regards,
> Kairat Kushaev
>
> On Thu, Mar 17, 2016 at 8:31 AM, Qiming Teng 
> wrote:
>>
>> >
>> > I'd love to see this idea explored further. What happens if Tempest
>> > ends up without tests, as a library for shared code as well as a
>> > centralized place to run tests from via plugins?
>> >
>>
>> Also curious about this. It seems weird to separate the 'positive' and
>> the 'negative' ones, assuming those patches are mostly contributed by
>> the same group of developers.
>>
>> 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 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] Wishlist bugs == (trivial) blueprint?

2016-03-20 Thread Matt Riedemann



On 3/17/2016 1:26 PM, Tim Bell wrote:



On 17/03/16 18:29, "Sean Dague"  wrote:


On 03/17/2016 11:57 AM, Markus Zoeller wrote:


Suggested action items:

1. I close the open wish list items older than 6 months (=138 reports)
and explain in the closing comment that they are outdated and the
ML should be used for future RFEs (as described above).
2. I post on the openstack-ops ML to explain why we do this
3. I change the Nova bug report template to explain this to avoid more
RFEs in the bug report list in the future.
4. In 6 months I double-check the rest of the open wishlist bugs
if they found developers, if not I'll close them too.
5. Continously double-check if wishlist bug reports get created

Doubts? Thoughts? Concerns? Agreements?


This sounds like a very reasonable plan to me. Thanks for summarizing
all the concerns and coming up with a pretty balanced plan here. +1.

-Sean


I’d recommend running it by the -ops* list along with the RFE proposal. I think 
many of the cases
had been raised since people did not have the skills/know how to proceed.

Engaging with the ops list would also bring in the product working group who 
could potentially
help out on the next step (i.e. identifying the best places to invest for RFEs) 
and the other
topical working groups (e.g. Telco, scientific) who could help with 
prioritisation/triage.

I don’t think that a launchpad account on its own is a big problem. Thus, I 
could also see an approach
where a blueprint was created in launchpad with some reasonably structured set 
of chapters. My
personal experience was that the challenges came more later on trying to get 
the review matched up and
the right bp directories.

There is a big benefit to good visibility in the -ops community for RFEs 
though. Quite often, the
features are implemented but people did not know how to find them in the doc 
(or maybe its a doc bug).
Equally, the OSops scripts repo can give people workarounds while the requested 
feature is in the
priority queue.

It would be a very interesting topic to kick off in the ops list and then have 
a further review in
Austin to agree how to proceed.

Tim


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

__
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



I agree with Tim and Sean. As noted in my PTL candidacy email, I want an 
ops CPL for the nova team, someone that can attend the ops meeting(s?) 
and bring back issues.


I try to add known ops people that are involved in nova to specs for 
their input when possible, but a lot of the time this ends up being Chet 
Burgess for everything (Mr Nova Ops!).  But we need to get a better 
communication channel going with the ops list/channel/meetings and RFE 
bugs aren't cutting it.


I like the idea of starting in the ML (dev or ops) since, as noted, if 
it's already done, or someone has already implemented it out of tree and 
just haven't had the time to push it to nova (which is more common than 
you'd think), it can be noted quickly. It would also foster early 
discussion on the idea before it shows up in gerrit as a spec review 
where only a small handful of spec reviewers are going to see it (which 
is also a reason things move slowly). If something was a bad idea, or 
just didn't get much enthusiasm, then it kind of dies on the vine 
naturally in the ML rather than a bitrot spec review in gerrit that we 
just end up abandoning every 6 months.


--

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] [cross-project] [all] Quotas -- service vs. library

2016-03-20 Thread Chris Dent

On Wed, 16 Mar 2016, Salvatore Orlando wrote:


- Looking at quotas it is worth distinguishing between management (eg::
resource limits per tenant and/or users), and enforcement (eg.: can the
bakery service give me 4 cookies or did I already eat too many?)
 While for the reasons listed throughout this thread the latter should
really happen in the same context where the request is going to served,
quota management instead might be its own service, or however being done in
a common endpoint for all OpenStack resources.


Thanks. I've been reading through this thread getting increasingly
confused. The proposed openstack-spec[1] does a pretty good job of
keeping management and enforcement separate but this thread, it's
not too clear. So somebody help me out, is the following in the
realm of right?

As stated by a few other people, enforcement is in the domain of
authZ: entity X has a "quota", or is a member of something that has
a "quota". Does their request + their existing use fit within that
quota? No, sorry, computer says no. That quota could be a fairly static
statement of a limit, however the information that needs to be expressed
there is probably complex.

The accounting of "their existing use" is the hard part, right? It is
also a generic problem we have in much of OpenStack:

* how much stuff is there?
* how much of it is used?
* who/what has used it?

Quota enforcement needs that information, schedulers/placers needs that
information. If that information were available as a service,
everybody would find it helpful.

If there are going to be services, there are two of them:

* accounting
* quota enforcement

Is that right?


- It has also been raised a good point about securing a chunk of resources
across project, that is also related to John's point about business
quotas... I'm not sure it is necessary, but Blazar [1] kind of achieves
this - even if it was conceived with different purposes.


I believe this is described as 'reservations' in the spec and I
agree with John Garbutt that it greatly raises the complexity. If we
have a system where we're having to do claims, instead of just
reflecting reality (i.e. real usage), things will go wrong, quickly.

We're much better figuring out a simpler system that includes the
possibility to fail fast.

[1] The proposed spec: https://review.openstack.org/#/c/284454/

--
Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
freenode: cdent tw: @anticdent__
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] Nomination Oleksii Chuprykov to Heat core reviewer

2016-03-20 Thread Rico Lin
+1!

2016-03-16 20:13 GMT+08:00 Pavlo Shchelokovskyy <
pshchelokovs...@mirantis.com>:

> +1 :)
>
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
>
> On Wed, Mar 16, 2016 at 1:18 PM, Rabi Mishra  wrote:
>
>> > Hi Heaters,
>> >
>> > The Mitaka release is close to finish, so it's good time for reviewing
>> > results of work.
>> > One of this results is analyze contribution results for the last release
>> > cycle.
>> > According to the data [1] we have one good candidate for nomination to
>> > core-review team:
>> > Oleksii Chuprykov.
>> > During this release he showed significant value of review metric.
>> > His review were valuable and useful. Also He has enough level of
>> > expertise in Heat code.
>> > So I think he is worthy to join to core-reviewers team.
>> >
>> > I ask you to vote and decide his destiny.
>> >  +1 - if you agree with his candidature
>> >  -1  - if you disagree with his candidature
>> >
>> > [1] http://stackalytics.com/report/contribution/heat-group/120
>>
>> +1
>>
>> > --
>> > Regards,
>> > Sergey.
>> >
>> >
>> __
>> > 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
>
>


-- 
Best regards,

*Rico Lin*

迎棧科技股份有限公司
│ 886-963-612-021
│ ric...@inwinstack.com
│ 886-2-7738-6804 #7754
│ 新北市220板橋區遠東路3號5樓C室
Rm.C, 5F., No.3, Yuandong Rd.,
Banqiao Dist., New Taipei City 220, Taiwan (R.O.C)
__
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] [FFE] LCM readiness for all deployment tasks

2016-03-20 Thread Szymon Banka
Hi,

Feature has been merged. QA is in progress.


Thanks,
Szymon

On 4 March, 2016 at 1:31:55, Dmitry Borodaenko (dborodae...@mirantis.com) wrote:

Granted, merge deadline March 15.

--  
Dmitry Borodaenko


On Tue, Mar 01, 2016 at 05:03:11PM +0100, Szymon Banka wrote:
> Hi All,
>  
> I’d like to request a Feature Freeze Exception for "LCM readiness for all 
> deployment tasks” [1] until Mar 11.
>  
> We need additional 1.5 week to finish and merge necessary changes which will 
> fix tasks in Fuel to be idempotent. That will be foundation and will enable 
> further development of LCM features.
>  
> More details about work being done: [2]
>  
> [1] https://blueprints.launchpad.net/fuel/+spec/granular-task-lcm-readiness
> [2] https://review.openstack.org/#/q/topic:bp/granular-task-idempotency,n,z
>  
> --
> Thanks,
> Szymon Bańka
> Mirantis
> http://www.mirantis.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 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] [Neutron] PTL Candidacy

2016-03-20 Thread Armando M.
I would like to propose my candidacy for the Neutron PTL.

I have been the Neutron PTL for the Mitaka release, and I would like to
continue the journey on which I have embarked upon a little over six months
ago.

Back then, I had a number of objectives which I wanted to achieve with the
help of the Neutron team, and with this candidacy statement I would like to
take the opportunity to look back and see what we have accomplished and
what else is waiting ahead of us:

   - Stability is the priority: I have introduced a rotation mechanism for
   triaging and staying on top of bugs; with that, we have a very little
   percentage of bugs that go unacknowledged, and even though we only managed
   to fix only 60% of all bugs reported in the Mitaka timeframe, some might
   regard this as a remarkable achievement. I also made sure the Neutron
   projects was amongst the most stable one, by aggressively addressing
   intermittent failures, and by ensuring that failures did not impact the
   integrated gate. As of today, the success rate for Neutron (alone) is at
   >98%. We also worked hard to extend test coverage to DVR, Linuxbridge and
   Grenade multinode. Going forward, I'd like to focus on improving the
   stability of multinode jobs, and look at how we can do more reliable and
   exhaustive performance testing on a more regular basis.
   - Narrow the focus: we all know by now my attempt to address the needs
   and the issues of the Stadium, and the team effort aimed at standing up
   neutron-lib to allow for Neutron projects to loosely couple together. The
   journey is far from being over and I will continue to work towards a
   resolution that strikes a good compromise for everybody. On the other end,
   I worked hard with the rest of the drivers team members to ensure a
   coherent strategy and vision when assessing and approving RFE's. I proposed
   process changes to ensure that reviewers and contributors can be more
   focussed and work together towards a well defined goal.
   - Consistency is paramount: promoting the documentation of our practices
   (like our deputy, blueprint/rfe guidelines and release postmortem), as well
   as starting the 'Effective Neutron' guide have been two key areas that
   allowed our developers to have a common understanding on how we operate,
   review, develop and manage our project. More needs to be done to ensure we
   become 'more predictable' in terms of the software we produce and the
   quality associated with it, including end-user facing documentation.
   - Define long term strategy: when I started looking at this area,
   Neutron had 400+ blueprints targeted. I tried to put some sanity back into
   the feature submission process by limiting who can actually submit feature
   proposals (the drivers team) and by cleaning up the huge backlog of
   blueprints we had (currently we have 15 blueprints and 19 RFEs). That said
   this is an area where I feel I have not made enough of a dent to be
   satisfied. This is somewhat tangential to the needs of the Stadium, but I
   think we need more time to execute a plan of action that can yield positive
   results.
   - Keep developers and reviewers _aware_: I worked relentlessly to remind
   our reviewers to stay focussed and review what matters for a given release.
   I think we have achieved this with mixed success, and I know that some of
   us worked hard to give us the tools to help us stay more aware.
   - I would like to promote a 'you merge it, you own it' type of
   mentality: this is typically done by leading by example, and I am pleased
   to see that many of us take great pride in the code they review and merge.
   We need to continue to promote this attitude.

And last but not least:

   - Improve the relationships with other projects: Nova and QA primarily.
   I personally feel that we went a long way to improve these relationships,
   from the technical front (for example by improving the provisioning
   workflow of networking resources for Nova instances - aka get-me-a-network,
   and by tackling the testing issues affecting Neutron) to the the social
   front, by having a good representation of contributors across multiple
   projects at the various mid-cycle events. There is always room for
   improvement, of course!

If you liked what I did/said, then allow me to continue.

Thanks for reading and, as usual, forgive the typos!
Armando Migliaccio (aka armax)
__
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] Upgrading from Kilo to Liberty, missing database entries

2016-03-20 Thread Ihar Hrachyshka

Nolan Brubaker  wrote:


Hello,

Recently when testing neutron upgrades for openstack-ansible, I ran into  
an existing bug [1] where the networksecuritybindings and  
portsecuritybindings tables were not populated after an upgrade from Kilo  
to Liberty. Updating the table manually resolved the issue, as mentioned  
in the bug, but there’s been no further activity since that discovery.


Also mentioned in the bug is a migration [2] that should fix this. From  
my investigation, it appears this migration runs on Kilo install, where  
the networksecuritybindings and portsecuritybindings tables don’t exist.  
Then, when upgrading to Liberty, it is skipped by Alembic as it’s already  
run. Manually running neutron-db-manage again skips this migration  
because the database is already current.


Based on the above, I have 2 main questions:


1) Is this a known issue, or is there possibly a step I’m missing?


Yeah. To trigger the bug, you don’t need to upgrade. Just create a  
network/port without the extension enabled; then enable the extension; then  
try to start an instance using the network/port.


2) Is my understanding of the migrations correct, that the migration only  
runs in Kilo then is skipped in Liberty?


I don’t believe the alembic migration was the right way to go. Instead,  
port security db code should be resilient against bindings not being  
present in db (for resources created before extension was enabled). If  
binding is not in db, we should assume True for the boolean value; and if  
it’s not present in db when update is requested, then we should create a  
new binding.


I posted a patch that should solve it: https://review.openstack.org/294132

I believe the patch should be backported back to the first release that  
introduced the extension (Kilo). Also, with the patch, alembic script is  
redundant and only adds to downtime during upgrade, so we could probably  
kill it in stable branches in addition to this patch.


Ihar

__
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] High Availability

2016-03-20 Thread Clark, Robert Graham
At the risk of muddying the waters further, I recently chatted with some of you 
about Anchor, it's an ephemeral PKI system setup to provide private community 
PKI - certificate services for internal systems, a lot like k8 pods.

An overview of why revocation doesn't work very well in many cases and how 
ephemeral PKI helps: 
https://openstack-security.github.io/tooling/2016/01/20/ephemeral-pki.html

First half of a threat analysis on Anchor, the Security Project's 
implementation of ephemeral PKI: 
https://openstack-security.github.io/threatanalysis/2016/02/07/anchorTA.html

This might not solve your problem, it's certainly not a direct drop in for 
Barbican (and it never will be) but if your primary concern is Certificate 
Management for internal systems (not presenting certificates over the edge of 
the cloud) you might find some of it's properties valuable. Not least, it's 
trivial to HA being stateless and it's trivial to deploy being a single Pecan 
service.

There's a reasonably complete deck on Anchor here:
https://docs.google.com/presentation/d/1HDyEiSA5zp6HNdDZcRAYMT5GtxqkHrxbrqDRzITuSTc/edit?usp=sharing

And of course, code over here:
http://git.openstack.org/cgit/openstack/anchor

Cheers
-Rob

> -Original Message-
> From: Maish Saidel-Keesing [mailto:mais...@maishsk.com]
> Sent: 19 March 2016 18:10
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum] High Availability
> 
> Forgive me for the top post and also for asking the obvious (with my
> Operator hat on)
> 
> Relying on an external service for certificate store - is the best
> option - assuming of course that the certificate store is actually also
> highly available.
> 
> Is that the case today with Barbican?
> 
> According to the architecture docs [1] I see that they are using a
> relational database. MySQL? PostgreSQL? Does that now mean we have an
> additional database to maintain, backup, provide HA for as an Operator?
> 
> The only real reference I can see to anything remotely HA is this [2]
> and this [3]
> 
> An overall solution is highly available *only* if all of the parts it
> relies are also highly available as well.
> 
> 
> [1]
> http://docs.openstack.org/developer/barbican/contribute/architecture.html#overall-architecture
> [2] https://github.com/cloudkeep-ops/barbican-vagrant-zero
> [3] http://lists.openstack.org/pipermail/openstack/2014-March/006100.html
> 
> Some food for thought
> 
> --
> Best Regards,
> Maish Saidel-Keesing
> 
> 
> On 03/18/16 17:18, Hongbin Lu wrote:
> > Douglas,
> >
> > I am not opposed to adopt Barbican in Magnum (In fact, we already adopted 
> > Barbican). What I am opposed to is a Barbican lock-in, which
> already has a negative impact on Magnum adoption based on our feedback. I 
> also want to see an increase of Barbican adoption in the
> future, and all our users have Barbican installed in their clouds. If that 
> happens, I have no problem to have a hard dependency on Barbican.
> >
> > Best regards,
> > Hongbin
> >
> > -Original Message-
> > From: Douglas Mendizábal [mailto:douglas.mendiza...@rackspace.com]
> > Sent: March-18-16 9:45 AM
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [magnum] High Availability
> >
> > Hongbin,
> >
> > I think Adrian makes some excellent points regarding the adoption of 
> > Barbican.  As the PTL for Barbican, it's frustrating to me to
> constantly hear from other projects that securing their sensitive data is a 
> requirement but then turn around and say that deploying Barbican
> is a problem.
> >
> > I guess I'm having a hard time understanding the operator persona that is 
> > willing to deploy new services with security features but
> unwilling to also deploy the service that is meant to secure sensitive data 
> across all of OpenStack.
> >
> > I understand one barrier to entry for Barbican is the high cost of Hardware 
> > Security Modules, which we recommend as the best option for
> the Storage and Crypto backends for Barbican.  But there are also other 
> options for securing Barbican using open source software like
> DogTag or SoftHSM.
> >
> > I also expect Barbican adoption to increase in the future, and I was hoping 
> > that Magnum would help drive that adoption.  There are also
> other projects that are actively developing security features like Swift 
> Encryption, and DNSSEC support in Desginate.  Eventually these
> features will also require Barbican, so I agree with Adrian that we as a 
> community should be encouraging deployers to adopt the best
> security practices.
> >
> > Regarding the Keystone solution, I'd like to hear the Keystone team's 
> > feadback on that.  It definitely sounds to me like you're trying to put
> a square peg in a round hole.
> >
> > - Doug
> >
> > On 3/17/16 8:45 PM, Hongbin Lu wrote:
> >> Thanks Adrian,
> >>
> >>
> >>
> >> I think the Keystone approach will work. For others, please speak up
> >> if it doesn't work for you.
>