date:20131204

Hi Morgan!

Stackforge projects can be configured to make the CLA optional. I am willing to 
speak to the HTTPretty maintainers about the benefits of stackforge. Do we 
happen to know any of them? If not I can track them down through email.

Adrian

--
Adrian

 Original message 
From: Morgan Fainberg
Date:12/04/2013 6:17 PM (GMT-08:00)
To: Jamie Lennox ,"OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last released 
version of keystoneclient does not work with python33

On December 4, 2013 at 18:05:07, Jamie Lennox 
(jamielen...@redhat.com) wrote:

On Wed, 2013-12-04 at 20:48 -0500, David Stanek wrote:
> On Wed, Dec 4, 2013 at 6:44 PM, Adrian Otto
>  wrote:
> Jamie,
>
> Thanks for the guidance here. I am checking to see if any of
> our developers might take an interest in helping with the
> upstream work. At the very least, it might be nice to have
> some understanding of how much work there is to be done in
> HTTPretty.
>
>
> (Dolph correct me if I am wrong, but...)
>
>
> I don't think that there is much work to be done beyond getting that
> pull request merged upstream. Dolph ran the tests using the code from
> the pull request somewhat successfully. The errors that we saw were
> just in keystoneclient code.

But I don't think that there own test suite runs under py33 with that
branch. So they've hit the main issues, but we won't get a release in
that state.

Should we offer to bring HTTPretty under something like stackforge and leverage 
our CI infrastructure?  Not sure how open the owner/maintainers would be to 
this, but it would help to solve that issue… downside is that pull-requests are 
no longer (gerrit instead) used and IIRC CLA is still required for stackforge 
projects (might be a detractor).  Just a passing thought (that might be 
irrelevant depending on the owner/maintainer’s point of view).

—Morgan

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

Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last released version of keystoneclient does not work with python33

Excerpts from Adrian Otto's message of 2013-12-04 16:53:16 -0800:
> Clint,
> 
> On Dec 4, 2013, at 4:06 PM, Clint Byrum 
>  wrote:
> 
> > Excerpts from Adrian Otto's message of 2013-12-04 15:44:45 -0800:
> >> Jamie,
> >> 
> >> Thanks for the guidance here. I am checking to see if any of our 
> >> developers might take an interest in helping with the upstream work. At 
> >> the very least, it might be nice to have some understanding of how much 
> >> work there is to be done in HTTPretty.
> >> 
> > 
> > Seems to me that we're still too early in the process for a downstream
> > application like Solum to gate on py3k. It will be more productive to
> > focus efforts on getting upstreams in-line and making sure they stay
> > in-line.
> 
> The py33 work is going to need to get done at some point. If we are py33 
> compatible from the start, there is less work to do later. I am suggesting 
> that we clean up the upstreams. Keystone, and by association HTTPretty are 
> Solum's upstreams for our auth feature. That's where I am suggesting we take 
> a look.

I totally agree, if you can do it now, fantastic. But you already depend
on python-keystoneclient, which has not done it yet. And they cannot do
it because HTTPretty has not done it. So upstream is where the effort
must happen at the moment.

Don't get me wrong, downstream applications like Solum are the driving
force behind the upstream library work. Solum should be pushing, always,
for py33 compliance. However, gating on it at this point would be ill
advised.

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

Re: [openstack-dev] [Neutron][IPv6] Webex Recording of IPv6 / Neutron Sync-up

2013-12-04 Thread Yang XY Yu

Hi Shi Xiong,

Did you attend to the IPv6 sub-team IRC meeting? We can not attend to that 
meeting because the time is so early for us, but we did not see the 
meeting log till now, we need to know some discussion result about IPv6 
tempest.

Thanks & Best Regards,

Yang Yu(于杨)




Shixiong Shang  
2013-12-05 10:48
Please respond to
"OpenStack Development Mailing List \(not for usage questions\)" 



To
"OpenStack Development Mailing List (not for usage questions)" 

cc
Tuttle Randy 
Subject
Re: [openstack-dev] [Neutron][IPv6] Webex Recording of IPv6 /   Neutron 
Sync-up






Hi, Ian:

For this brainstorming session, we had IBM team in Beijing and other guys 
on east coast of US. In order to cover two time zones 13-hr apart, we 
chose 9pm EST time for the convenience of us. Didn’t realize you are in 
Europe and next time if we have this kind of casual discussion, we will 
definitely send invite to the broader team on the mailer earlier and try 
to find a time suitable for everybody.

Thanks!

Shixiong



On Dec 4, 2013, at 10:47 AM, Ian Wells  wrote:

Next time, could you perhaps do it (a) with a bit more notice and (b) at a 
slightly more amenable time for us Europeans?




On Tue, Dec 3, 2013 at 11:30 PM, Shixiong Shang <
sparkofwisdom.cl...@gmail.com> wrote:
Hi, guys:

We had a great discussion tonight with stackers from Comcast, IBM, HP, 
Cisco and Nephos6! Here is the debrief of what we discussed during this 
1-hr session:

1) Sean from Comcast provided clarification of his short-term and mid-term 
goals in the proposed blueprint.
2) Da Zhao, Yu Yang, and Xu Han from IBM went throughout the patches and 
bug fixes they submitted.
3) Brian from HP shared his view to support IPv6 and HA in the near 
future.
4) Shixiong from Nephos6 and Randy from Cisco presented a slide to 
summarize the issues they encountered during POC together with the 
solutions.
5) We reached consensus to leverage the work Sean, Da Zhao have done 
previously and integrate it with the L3 agent efforts brought by Shixiong 
and Randy.


Please see below for Webex recording.

https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=73520027&rKey=8e508b63604bb9d0


IPv6 / Neutron synch-up-20131204 0204-1 
Tuesday, December 3, 2013 9:04 pm New York Time 
1 Hour 4 Minutes 

Thanks!

Shixiong

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



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


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


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

Re: [openstack-dev] [heat] Heater Proposal

On 5 December 2013 15:55, Steve Baker  wrote:

> Yes, point taken.
>
> heat-core does a reasonable job of keeping up with review load, so there is
> not yet a bottleneck. However the load is taken by a small team which would
> definitely need to grow if we were to take on a new project.

Yup.

> There are certainly some reviewers who will be ready for nomination soon if
> they continue increasing their review volume:
> http://russellbryant.net/openstack-stats/heat-reviewers-30.txt
>
> It may be appropriate to relax the core review approval to a single +2 on
> heatr in the early stages of the project.

I think thats ultimately counterproductive. Folk can build on
in-progress patches when they really need to - gerrit supports that.

http://russellbryant.net/openstack-stats/heat-openreviews.html

Stats since the last revision without -1 or -2 :

Average wait time: 1 days, 11 hours, 41 minutes
1rd quartile wait time: 0 days, 18 hours, 47 minutes
Median wait time: 1 days, 1 hours, 23 minutes
3rd quartile wait time: 1 days, 16 hours, 6 minutes

So, 75% of patches are sitting for more than a day before being looked
at at all : thats says to me that Heat could use more core reviewers
(many hands, light work) - ideally with a distributed project like us,
most things would be looked at in 9-12 hours or less; however these
figures are much happier than nova, and nova still achieves pretty
good velocity!

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

2013-12-04 Thread Matt Riedemann




On 12/4/2013 10:16 AM, Nikola Đipanov wrote:

On 11/19/2013 05:52 PM, Peter Feiner wrote:

On Tue, Nov 19, 2013 at 11:19 AM, Chuck Short  wrote:

Hi


On Tue, Nov 19, 2013 at 10:43 AM, Peter Feiner  wrote:


A substantive reason for switching from mox to mock is the derelict
state of mox releases. There hasn't been a release of mox in three
years: the latest, mox-0.5.3, was released in 2010 [1, 2]. Moreover,
in the past 3 years, substantial bugs have been fixed in upstream mox.
For example, with the year-old fix to
https://code.google.com/p/pymox/issues/detail?id=16, a very nasty bug
in nova would have been caught by an existing test [3].

Alternatively, a copy of the upstream mox code could be added in-tree.


Please no, I think we are in an agreement with mox3 and mock.


That's cool. As long as the mox* is phased out, the false-positive
test results will be fixed.

Of course, there's _another_ alternative, which is to retrofit mox3
with the upstream mox fixes (e.g., the bug I cited above exists in
mox3). However, the delta between mox3 and upstream mox is pretty huge
(I just checked), so effort is probably better spent switching to
mock. To that end, I plan on changing the tests I cited above.



Resurrecting this thread because of an interesting review that came up
yesterday [1].

It seems that our lack of a firm decision on what to do with the mocking
framework has left people confused. In hope to help - I'll give my view
of where things are now and what we should do going forward, and
hopefully we'll reach some consensus on this.

Here's the breakdown:

We should abandon mox:
* It has not had a release in over 3 years [2] and a patch upstream for 2
* There are bugs that are impacting the project with it (see above)
* It will not be ported to python 3

Proposed path forward options:
1) Port nova to mock now:
   * Literally unmanageable - huge review overhead and regression risk
for not so much gain (maybe) [1]

2) Opportunistically port nova (write new tests using mock, when fixing
tests, move them to mock):
  * Will take a really long time to move to mock, and is not really a
solution since we are stuck with mock for an undetermined period of time
- it's what we are doing now (kind of).

3) Same as 2) but move current codebase to mox3
  * Buys us py3k compat, and fresher code
  * Mox3 and mox have diverged and we would need to backport mox fixes
onto the mox3 three and become de-facto active maintainers (as per Peter
Feiner's last email - that may not be so easy).

I think we should follow path 3) if we can, but we need to:

1) Figure out what is the deal with mox3 and decide if owning it will
really be less trouble than porting nova. To be hones - I was unable to
even find the code repo for it, only [3]. If anyone has more info -
please weigh in. We'll also need volunteers

2) Make better testing guidelines when using mock, and maybe add some
testing helpers (like we do already have for mox) that will make porting
existing tests easier. mreidem already put this on this weeks nova
meeting agenda - so that might be a good place to discuss all the issues
mentioned here as well.


For anyone interested in seeing the nova meeting agenda notes before the 
actual meeting (since it covers more than just mock/mox), here you go:


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

Copying here for reference later if necessary:

- Testing Guides - we need some guide on using mox vs mock; previously 
we were forcing all new tests to use mock but then mox3 was pointed out 
and that seemed to go away, but is anyone using mox3 yet 
(ceilomerclient, heatclient and ironicclient are all moving to mox3).
  - ML on stubs vs mox vs mock: 
http://lists.openstack.org/pipermail/openstack-dev/2013-November/018501.html
  - nova/tests/README.rst is outdated; lots of TBD and last update was 
on 2013/05/16: 
https://github.com/openstack/nova/blob/master/nova/tests/README.rst
- Note keystone bug 1252454 where the keystone docs were 
referencing the nova testing README
  - Ultimately it seems the best guide is Horizon's: 
http://docs.openstack.org/developer/horizon/topics/testing.html
  - We should have something like the Horizon guide in the overall 
OpenStack hacking guide so the projects can point to a single location, 
http://docs.openstack.org/developer/hacking/, but even that is sparse on 
details for writing unit tests (should almost merge or point to the 
horizon guide), and then the single guide should have notes on stubs vs 
mox vs mock with pros/cons and best practices / pitfalls.


===

The net problem is we have a lot of various testing guides throughout 
the projects, including hacking guides, readmes, wikis, and devref 
pages, we should really consolidate that into the universal hacking 
guide (IMO) and then integrate Horizon's excellent guide into that along 
with whatever rules we have for mox/mox3/mock.




We should really take a stronger stance on this soon IMHO, as this comes
up with literally

Re: [openstack-dev] [Neutron][IPv6] Webex Recording of IPv6 / Neutron Sync-up

2013-12-04 Thread Richard Woo

Shixiong,

Thanks for the updating.

Richard


On Thu, Dec 5, 2013 at 10:44 AM, Shixiong Shang <
sparkofwisdom.cl...@gmail.com> wrote:

> Hi, Richard:
>
> Sorry it took me a while to reply your email. I was swamped today to
> prepare for the presentation that Randy and I jointly delivered tonight to
> local OpenStack community in the meet-up sponsored by Cisco. As matter of
> fact, we used the same slide and you can find a copy at:
>
> http://www.slideshare.net/shixiongshang1/openstack-havana-over-ipv6
>
> Please don’t feel hesitate to let us know if you have any questions. We
> will be more than happy to help.
>
> Thanks for showing the interests in our work!
>
> Shixiong
>
>
>
>
>
>
> On Dec 4, 2013, at 10:27 AM, Richard Woo  wrote:
>
> Shixiong,
>
> Thank you for the updates, do you mind to share the slide to the openstack
> mailing list?
>
> Richard
>
>
> On Tue, Dec 3, 2013 at 11:30 PM, Shixiong Shang <
> sparkofwisdom.cl...@gmail.com> wrote:
>
>> Hi, guys:
>>
>> We had a great discussion tonight with stackers from Comcast, IBM, HP,
>> Cisco and Nephos6! Here is the debrief of what we discussed during this
>> 1-hr session:
>>
>> 1) Sean from Comcast provided clarification of his short-term and
>> mid-term goals in the proposed blueprint.
>> 2) Da Zhao, Yu Yang, and Xu Han from IBM went throughout the patches and
>> bug fixes they submitted.
>> 3) Brian from HP shared his view to support IPv6 and HA in the near
>> future.
>> 4) Shixiong from Nephos6 and Randy from Cisco presented a slide to
>> summarize the issues they encountered during POC together with the
>> solutions.
>> 5) We reached consensus to leverage the work Sean, Da Zhao have done
>> previously and integrate it with the L3 agent efforts brought by Shixiong
>> and Randy.
>>
>>
>> Please see below for Webex recording.
>>
>>
>> https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=73520027&rKey=8e508b63604bb9d0
>>
>> IPv6 / Neutron synch-up-20131204 0204-1
>> Tuesday, December 3, 2013 9:04 pm New York Time
>> 1 Hour 4 Minutes
>>
>> Thanks!
>>
>> Shixiong
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] Moving the QA meeting time

2013-12-04 Thread Christopher Yeoh

On Thu, Dec 5, 2013 at 11:06 AM, Kenichi Oomichi
wrote:

>
> Hi Matthew,
>
> Thank you for picking this up.
>
> > -Original Message-
> > From: Matthew Treinish [mailto:mtrein...@kortar.org]
> > Sent: Thursday, December 05, 2013 6:04 AM
> > To: openstack-dev@lists.openstack.org
> > Subject: [openstack-dev] [qa] Moving the QA meeting time
> >
> > Hi everyone,
> >
> > I'm looking at changing our weekly QA meeting time to make it more
> globally
> > attendable. Right now the current time of 17:00 UTC doesn't really work
> for
> > people who live in Asia Pacific timezones. (which includes a third of the
> > current core review team) There are 2 approaches that I can see taking
> here:
> >
> >  1. We could either move the meeting time later so that it makes it
> easier for
> > people in the Asia Pacific region to attend.
> >
> >  2. Or we move to a alternating meeting time, where every other week the
> meeting
> > time changes. So we keep the current slot and alternate with
> something more
> > friendly for other regions.
> >
> > I think trying to stick to a single meeting time would be a better call
> just for
> > simplicity. But it gets difficult to appease everyone that way which is
> where the
> > appeal of the 2nd approach comes in.
> >
> > Looking at the available time slots here:
> https://wiki.openstack.org/wiki/Meetings
> > there are plenty of open slots before 1500 UTC which would be early for
> people in
> > the US and late for people in the Asia Pacific region. There are plenty
> of slots
> > starting at 2300 UTC which is late for people in Europe.
> >
> > Would something like 2200 UTC on Wed. or Thurs work for everyone?
> >
> > What are people's opinions on this?
>
> I am in JST.
> Is Chris in CST, and Marc in CET?
>
> Here is timezone difference.
> 15:00 UTC -> 07:00 PST -> 01:30 CST -> 16:00 CET - 24:00 JST
> 22:00 UTC -> 14:00 PST -> 08:30 CST -> 23:00 CET - 07:00 JST
> 23:00 UTC -> 15:00 PST -> 09:30 CST -> 24:00 CET - 08:00 JST
>
> I feel 22:00 would be nice.
>
>
22:00 UTC would be fine with me. I have another meeting on at 22:00 UTC on
Wednesdays (as does Matt now),
so Thursday is probably better if possible. Otherwise it may be possible to
move the meeting that Matt and I need to attend.

Regards,

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

Re: [openstack-dev] [heat] Heater Proposal

2013-12-04 Thread Steve Baker

On 12/05/2013 02:47 PM, Robert Collins wrote:
> On 5 December 2013 12:34, Tim Schnell  wrote:
>> Hi Heaters,
> ...
>
> So, I'm very glad someone is going to work on this; I believe there
> may be use for it in Tuskar too.
>
>> Start Heater as a Stackforge project with a different core team that is
>> dedicated to actively working on Heater
> This would silo the folk working on the repository from those working
> on Heat. -1000 on that proposition.
>
>> Incubate Heater within the Orchestration umbrella using the existing Heat
>> Core team
>> Incubate Heater with the Orchestration umbrella, but create a sub-project
>> team responsible for reviewing and +2s
> This would reduce the siloing effect, but you'd still have siloed core
> reviewers.
>
>> The idea behind creating a separate core team either via Stackforge or an
>> Orchestration sub-project is so that the people actively working on Heater
>> can review and iterate more quickly through code revisions than dumping
>> Heater code through the already strained Heat review pipeline.
> So, I understand the motivation, but this is really really really
> really bad thinking.
>
> If Heat is suffering velocity problems due to not enough core reviewers do 
> you:
>
> A) start a related project, which all the Heat core are going to have
> to be up to speed on at some point
>
> or
>
> B) add people onto Heat with the explicit goal of providing more
> review bandwidth until the problem is solved ?
>
> If you answer A, we need to talk.
>
> Seriously.
>
> Where there is a bottleneck - such as not enough reviewers -
> /anything/ we do that makes the bottleneck better makes everything
> better. Anything else we do has pretty much no effect, other than
> costing time and effort to do it, whatever it is.
>
Yes, point taken.

heat-core does a reasonable job of keeping up with review load, so there
is not yet a bottleneck. However the load is taken by a small team which
would definitely need to grow if we were to take on a new project.

There are certainly some reviewers who will be ready for nomination soon
if they continue increasing their review volume:
http://russellbryant.net/openstack-stats/heat-reviewers-30.txt

It may be appropriate to relax the core review approval to a single +2
on heatr in the early stages of the project.

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

Re: [openstack-dev] [Neutron][IPv6] Webex Recording of IPv6 / Neutron Sync-up

2013-12-04 Thread Jeremy Stanley

On 2013-12-04 21:44:53 -0500 (-0500), Shixiong Shang wrote:
[...]
> I was swamped today to prepare for the presentation that Randy and
> I jointly delivered tonight to local OpenStack community in the
> meet-up sponsored by Cisco.
[...]

Also, just wanted to congratulate you--the presentation was
excellent, and I'm quite impressed to see the awesome things you're
doing with IPv6 and OpenStack (locally, no less!).
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Neutron][IPv6] Webex Recording of IPv6 / Neutron Sync-up

2013-12-04 Thread Shixiong Shang

Hi, Ian:

For this brainstorming session, we had IBM team in Beijing and other guys on 
east coast of US. In order to cover two time zones 13-hr apart, we chose 9pm 
EST time for the convenience of us. Didn’t realize you are in Europe and next 
time if we have this kind of casual discussion, we will definitely send invite 
to the broader team on the mailer earlier and try to find a time suitable for 
everybody.

Thanks!

Shixiong



On Dec 4, 2013, at 10:47 AM, Ian Wells  wrote:

> Next time, could you perhaps do it (a) with a bit more notice and (b) at a 
> slightly more amenable time for us Europeans?
> 
> 
> 
> 
> On Tue, Dec 3, 2013 at 11:30 PM, Shixiong Shang 
>  wrote:
> Hi, guys:
> 
> We had a great discussion tonight with stackers from Comcast, IBM, HP, Cisco 
> and Nephos6! Here is the debrief of what we discussed during this 1-hr 
> session:
> 
> 1) Sean from Comcast provided clarification of his short-term and mid-term 
> goals in the proposed blueprint.
> 2) Da Zhao, Yu Yang, and Xu Han from IBM went throughout the patches and bug 
> fixes they submitted.
> 3) Brian from HP shared his view to support IPv6 and HA in the near future.
> 4) Shixiong from Nephos6 and Randy from Cisco presented a slide to summarize 
> the issues they encountered during POC together with the solutions.
> 5) We reached consensus to leverage the work Sean, Da Zhao have done 
> previously and integrate it with the L3 agent efforts brought by Shixiong and 
> Randy.
> 
> 
> Please see below for Webex recording.
> 
> https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=73520027&rKey=8e508b63604bb9d0
> 
> IPv6 / Neutron synch-up-20131204 0204-1 
> Tuesday, December 3, 2013 9:04 pm New York Time 
> 1 Hour 4 Minutes 
> 
> Thanks!
> 
> Shixiong
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Neutron][IPv6] Webex Recording of IPv6 / Neutron Sync-up

2013-12-04 Thread Shixiong Shang

Hi, Richard:

Sorry it took me a while to reply your email. I was swamped today to prepare 
for the presentation that Randy and I jointly delivered tonight to local 
OpenStack community in the meet-up sponsored by Cisco. As matter of fact, we 
used the same slide and you can find a copy at:

http://www.slideshare.net/shixiongshang1/openstack-havana-over-ipv6

Please don’t feel hesitate to let us know if you have any questions. We will be 
more than happy to help.

Thanks for showing the interests in our work!

Shixiong






On Dec 4, 2013, at 10:27 AM, Richard Woo  wrote:

> Shixiong,
> 
> Thank you for the updates, do you mind to share the slide to the openstack 
> mailing list?
> 
> Richard
> 
> 
> On Tue, Dec 3, 2013 at 11:30 PM, Shixiong Shang 
>  wrote:
> Hi, guys:
> 
> We had a great discussion tonight with stackers from Comcast, IBM, HP, Cisco 
> and Nephos6! Here is the debrief of what we discussed during this 1-hr 
> session:
> 
> 1) Sean from Comcast provided clarification of his short-term and mid-term 
> goals in the proposed blueprint.
> 2) Da Zhao, Yu Yang, and Xu Han from IBM went throughout the patches and bug 
> fixes they submitted.
> 3) Brian from HP shared his view to support IPv6 and HA in the near future.
> 4) Shixiong from Nephos6 and Randy from Cisco presented a slide to summarize 
> the issues they encountered during POC together with the solutions.
> 5) We reached consensus to leverage the work Sean, Da Zhao have done 
> previously and integrate it with the L3 agent efforts brought by Shixiong and 
> Randy.
> 
> 
> Please see below for Webex recording.
> 
> https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=73520027&rKey=8e508b63604bb9d0
> 
> IPv6 / Neutron synch-up-20131204 0204-1 
> Tuesday, December 3, 2013 9:04 pm New York Time 
> 1 Hour 4 Minutes 
> 
> Thanks!
> 
> Shixiong
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last released version of keystoneclient does not work with python33

2013-12-04 Thread Morgan Fainberg

On December 4, 2013 at 18:05:07, Jamie Lennox (jamielen...@redhat.com) wrote:

On Wed, 2013-12-04 at 20:48 -0500, David Stanek wrote: 
> On Wed, Dec 4, 2013 at 6:44 PM, Adrian Otto 
>  wrote: 
> Jamie, 
> 
> Thanks for the guidance here. I am checking to see if any of 
> our developers might take an interest in helping with the 
> upstream work. At the very least, it might be nice to have 
> some understanding of how much work there is to be done in 
> HTTPretty. 
> 
> 
> (Dolph correct me if I am wrong, but...) 
> 
> 
> I don't think that there is much work to be done beyond getting that 
> pull request merged upstream. Dolph ran the tests using the code from 
> the pull request somewhat successfully. The errors that we saw were 
> just in keystoneclient code. 

But I don't think that there own test suite runs under py33 with that 
branch. So they've hit the main issues, but we won't get a release in 
that state. 
Should we offer to bring HTTPretty under something like stackforge and leverage 
our CI infrastructure?  Not sure how open the owner/maintainers would be to 
this, but it would help to solve that issue… downside is that pull-requests are 
no longer (gerrit instead) used and IIRC CLA is still required for stackforge 
projects (might be a detractor).  Just a passing thought (that might be 
irrelevant depending on the owner/maintainer’s point of view).

—Morgan

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

Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last released version of keystoneclient does not work with python33

2013-12-04 Thread Jamie Lennox


On Wed, 2013-12-04 at 20:48 -0500, David Stanek wrote:
> On Wed, Dec 4, 2013 at 6:44 PM, Adrian Otto
>  wrote:
> Jamie,
> 
> Thanks for the guidance here. I am checking to see if any of
> our developers might take an interest in helping with the
> upstream work. At the very least, it might be nice to have
> some understanding of how much work there is to be done in
> HTTPretty.
> 
> 
> (Dolph correct me if I am wrong, but...)
> 
> 
> I don't think that there is much work to be done beyond getting that
> pull request merged upstream.  Dolph ran the tests using the code from
> the pull request somewhat successfully.  The errors that we saw were
> just in keystoneclient code.

But I don't think that there own test suite runs under py33 with that
branch. So they've hit the main issues, but we won't get a release in
that state. 

> -- 
> David
> blog: http://www.traceback.org
> twitter: http://twitter.com/dstanek
> www: http://dstanek.com
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

Re: [openstack-dev] [Tempest] Which is the best way for skipping tests?

On 5 December 2013 03:24, Joe Hakim Rahme  wrote:
> I am in favor of class level exceptions for the obvious reasons:
...
> If proper fixtures are meant to replace setUpClass in the future (something I
> would really love to see in Tempest), we still need to take into account that
> setUpClass might do more than just fixtures, and certain guards are expected 
> to
> be found in there.

So the point is to remove setUpClass use entirely. Please bear that in
mind in whatever you come up with.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [heat] Heater Proposal

2013-12-04 Thread Monty Taylor

Why not just use glance?

On 12/04/2013 06:34 PM, Tim Schnell wrote:
> Hi Heaters,
> 
> We would like to start a dialog on the general direction of the proposed
> Heater project:
> blueprint: https://blueprints.launchpad.net/heat/+spec/heat-template-repo
> wiki: https://wiki.openstack.org/wiki/Heat/htr
> 
> It is important to us to start the discussion early but please note that
> the wiki is still very much a work-in-progress. I am actively working to
> clean up the use cases and the API spec is just to generate discussion,
> I expect it to change based on general consensus.
> 
> We currently have 3 options for starting the Heater project:
> 
>  1. Start Heater as a Stackforge project with a different core team that
> is dedicated to actively working on Heater
>  2. Incubate Heater within the Orchestration umbrella using the existing
> Heat Core team
>  3. Incubate Heater with the Orchestration umbrella, but create a
> sub-project team responsible for reviewing and +2s
> 
> The idea behind creating a separate core team either via Stackforge or
> an Orchestration sub-project is so that the people actively working on
> Heater can review and iterate more quickly through code revisions than
> dumping Heater code through the already strained Heat review pipeline.
> 
> We are still ironing out the definition of a schema for Heater based on
> the existing use cases in the wiki and we would very much appreciate any
> input with regards to the existing use cases or proposed API spec. In
> particular, it is starting to become apparent that a few of the defined
> schema are not necessarily related to Heater specifically and may make
> good candidates to start a separate discussion on inclusion in the HOT
> specification.
> 
> The following things, specifically, would add value to the HOT
> specification in general (copied from the wiki if you need further context):
> 
> application:
>name: Wordpress
>version: 3.6.1
>flavor: Single Linux server with WordPress 3.6.1 and MySQL 5.5
>weight: 3
>  icons: 
>  - href: 
> https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-tattoo.png
>type: default
>  - href: 
> https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-icon-20x20.png
>type: small
>  keywords:
>  - wordpress
>  - mysql
> 
> documentation:
>abstract: 
>  some abstract...
>guide:
>  This blueprint includes a single server running Wordpress with Varnish..
>  This blueprint's performance has not been measured.
>instructions:
>  If you're new to WordPress, the
>  documentation will step you through the process of logging into the
>  admin panel, customizing your blog, and changing your theme.
> 
> Keywords has already been the subject of another mailing list
> conversation so let's ignore that one for the moment. If there is
> general consensus that we should at least discuss application, icons,
> and documentation as possible candidates for the HOT syntax then I will
> start a separate mailing list thread to detail out the use cases.
> 
> The original thought was, other things like template versioning
> information and keystone roles for permissions are very obviously
> related to Heater. Heater will use those things to make decisions about
> how it works. But application information, icons and documentation are
> not things that Heater cares about. Heat also does not care about these
> things but the downstream user interface does care about these things
> and a human looking at the Heat template would be able to gather
> valuable information from these things as well.
> 
> Obviously, the actual structure and use cases for these things would
> need to be vetted before inclusion in the HOT syntax but let's discuss
> the more general idea that the HOT syntax should include things that
> Heat (or Heater) does not care about but can prove to add real value to
> the user experience at some point in a user's interaction with Heat.
> 
> Thanks,
> Tim
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [Tempest] Which is the best way for skipping tests?

2013-12-04 Thread Daisuke Morita

Thanks for your suggestion, Brant. And, I experimented multiple
approaches like that in Tempest, annotating testtools.skipIf above
setUp() method can deliver a similar result.

How about this annotation approach, Joe? This approach can meet both
requirements we said, avoiding code duplications and accurately logging
what are skipped. The demerit of this approach seems less intuitive than
annotating above setUpClass method, but you do not need to spend any
time to implement additional annotation.

Best Regards,
Daisuke Morita

(2013/12/05 8:59), Brant Knudson wrote:

In Keystone, we've got some tests that "raise self.skipTest('...')" in
the test class setUp() method (not setUpClass). My testing shows that if
there's several tests in the class then it shows all of those tests as
skipped (not just 1 skip). Does this do what you want?

Here's an example:
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/test_ipv6.py?id=73dbc00e6ac049f19d0069ecb07ca8ed75627dd5#n30

http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/core.py?id=73dbc00e6ac049f19d0069ecb07ca8ed75627dd5#n500

- Brant

On Wed, Dec 4, 2013 at 5:46 AM, Daisuke Morita
mailto:morita.dais...@lab.ntt.co.jp>> wrote:

Hi, everyone.

Which do you think is the best way of coding test skipping, "writing
cls.skipException statement in setUpClass method" or "skipIf annotation
for each test method" ?

This question comes to me in reviewing
https://review.openstack.org/#/c/59759/ . I think that work itself is
great and I hope this patch is merged to Tempest. I just want to focus
on coding styles and explicitness of test outputs.

If skipIf annotation is used, test output of Swift is as follows.

---
tempest.api.object_storage.test_account_quotas.AccountQuotasTest
test_admin_modify_quota[gate,smoke]
SKIP 1.15
test_upload_large_object[gate,negative,smoke]
SKIP 0.03
test_upload_valid_object[gate,smoke]
SKIP 0.03
test_user_modify_quota[gate,negative,smoke]
SKIP 0.03
tempest.api.object_storage.test_account_services.AccountTest
test_create_and_delete_account_metadata[gate,smoke]
OK
0.32
test_list_account_metadata[gate,smoke]
OK
0.02
test_list_containers[gate,smoke]
OK
0.02

...(SKIP)...

Ran 54 tests in 85.977s

OK
---

On the other hand, if cls.skipException is used, an output is changed as
follows.

---
setUpClass (tempest.api.object_storage.test_account_quotas
AccountQuotasTest)
SKIP 0.00
tempest.api.object_storage.test_account_services.AccountTest
test_create_and_delete_account_metadata[gate,smoke]
OK
0.48
test_list_account_metadata[gate,smoke]
OK
0.02
test_list_containers[gate,smoke]
OK
0.02

...(SKIP)...

Ran 49 tests in 81.475s

OK
---

I believe the output of the code using skipIf annotation is better.
Since the coverage of tests is displayed more definitely, it is easier
to find out what tests are really skipped.

I scanned the whole code of Tempest. The count of cls.skipException
statements is 63, and the count of skipIf annotations is 24. Replacing
them is not trivial task, but I think the most impportant for testing is
to output consistent and accurate log.

Am I missing something? Or, this kind of discussion has been done
already in the past? If so, could you let me know?

Best Regards,

--
Daisuke Morita mailto:morita.dais...@lab.ntt.co.jp>>
NTT Software Innovation Center, NTT Corporation

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

--
Daisuke Morita
NTT Software Innovation Center, NTT Corporation

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

Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last released version of keystoneclient does not work with python33

2013-12-04 Thread David Stanek

On Wed, Dec 4, 2013 at 6:44 PM, Adrian Otto wrote:

> Jamie,
>
> Thanks for the guidance here. I am checking to see if any of our
> developers might take an interest in helping with the upstream work. At the
> very least, it might be nice to have some understanding of how much work
> there is to be done in HTTPretty.

(Dolph correct me if I am wrong, but...)

I don't think that there is much work to be done beyond getting that pull
request merged upstream.  Dolph ran the tests using the code from the pull
request somewhat successfully.  The errors that we saw were just in
keystoneclient code.

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Heater Proposal

On 5 December 2013 12:34, Tim Schnell  wrote:
> Hi Heaters,
...

So, I'm very glad someone is going to work on this; I believe there
may be use for it in Tuskar too.

> Start Heater as a Stackforge project with a different core team that is
> dedicated to actively working on Heater

This would silo the folk working on the repository from those working
on Heat. -1000 on that proposition.

> Incubate Heater within the Orchestration umbrella using the existing Heat
> Core team
> Incubate Heater with the Orchestration umbrella, but create a sub-project
> team responsible for reviewing and +2s

This would reduce the siloing effect, but you'd still have siloed core
reviewers.

> The idea behind creating a separate core team either via Stackforge or an
> Orchestration sub-project is so that the people actively working on Heater
> can review and iterate more quickly through code revisions than dumping
> Heater code through the already strained Heat review pipeline.

So, I understand the motivation, but this is really really really
really bad thinking.

If Heat is suffering velocity problems due to not enough core reviewers do you:

A) start a related project, which all the Heat core are going to have
to be up to speed on at some point

or

B) add people onto Heat with the explicit goal of providing more
review bandwidth until the problem is solved ?

If you answer A, we need to talk.

Seriously.

Where there is a bottleneck - such as not enough reviewers -
/anything/ we do that makes the bottleneck better makes everything
better. Anything else we do has pretty much no effect, other than
costing time and effort to do it, whatever it is.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [Keystoneclient] [Keystone] Last released version of keystoneclient does not work with python33

2013-12-04 Thread Chuck Short

On Wed, Dec 4, 2013 at 6:29 PM, Jamie Lennox  wrote:

> Adrian,
>
> The main blocker for the time being with keystoneclient and py3 is our
> use of a library called HTTPretty in our testing - on which there is a
> very recent thread. There is upstream work to make this py3 compatible
> but i'm not sure how quickly it's moving.
>
> Any code in keystoneclient itself that is not py33 compatible should be
> considered a bug - but obviously due to the missed testing we don't pick
> this up very often.
>
> There is no timeline at the moment, however anyone with py33 experience
> looking to make this happen faster could contribute to this branch on
> github: https://github.com/gabrielfalcao/HTTPretty/pull/124 and help
> upstream. Once there is a py33 release available keystoneclient will not
> be far behind.
>
> Jamie
>
>
I have been working on getting python-keystoneclient compatible with py33,
and there has some work been done. However getting httpretty py33
compatible is just the first step , there is a whole bunch of fixes that
need to be done before the tests pass with py33. The differences for hmac
in python-keystoneclient comes to mind.

>
> On Wed, 2013-12-04 at 20:59 +, Adrian Otto wrote:
> > Dolph,
> >
> >
> > Is anyone already focusing on py33 compatibility for
> > python-keystoneclient? Has that effort been scoped? I'd like to judge
> > whether it's reasonable to expect us to patch it up to be compatible
> > in the near term, or relax our expectations. For Solum, we are trying
> > to make all our code py33 compatible from the start, so we take it
> > seriously when the py33 gate fails. Please advise.
> >
> >
> > Thanks,
> >
> >
> > Adrian
> >
> > On Dec 4, 2013, at 12:24 PM, Dolph Mathews 
> >  wrote:
> >
> > >
> > > On Wed, Dec 4, 2013 at 1:26 PM, Georgy Okrokvertskhov
> > >  wrote:
> > > Hi,
> > >
> > >
> > > I have failed tests in gate-solum-python33 because
> > > kesytoneclient fails to import xmlrpclib.
> > > The exact error is:
> > > "File
> > >
> "/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/keystoneclient/openstack/common/jsonutils.py",
> line 42, in 
> > > 2013-11-28 18:27:12.655 | import xmlrpclib
> > > 2013-11-28 18:27:12.655 | ImportError: No module named
> > > 'xmlrpclib
> > > "
> > > This issue appeared because of xmlrpclib was renamed in
> > > python33.
> > > Is there any plan to release a new version
> > > of keystoneclient with the fix for that issue? As I see it
> > > is fixed in master.
> > >
> > >
> > > If there is no new release for keystoneclient can you
> > > recommend any workaround for this issue?
> > >
> > >
> > >
> > >
> > > I'd be happy to make a release keystoneclient, but I don't believe
> > > that's the only issue with python 3 at the moment (at least on the
> > > CLI?). For example:
> > >
> > >
> > >   https://bugs.launchpad.net/python-keystoneclient/+bug/1249165
> > >
> > >
> > > In the current master, the above issue is only reproducible after
> > > syncing oslo (otherwise it fails on yet another python 3
> > > incompatibility).
> > >
> > >
> > > Thanks
> > > Georgy
> > >
> > > ___
> > > OpenStack-dev mailing list
> > > OpenStack-dev@lists.openstack.org
> > >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > OpenStack-dev mailing list
> > > OpenStack-dev@lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] Heater Proposal

2013-12-04 Thread Steven Dake

On 12/04/2013 04:34 PM, Tim Schnell wrote:

Hi Heaters,

We would like to start a dialog on the general direction of the
proposed Heater project:

blueprint: https://blueprints.launchpad.net/heat/+spec/heat-template-repo
wiki: https://wiki.openstack.org/wiki/Heat/htr

It is important to us to start the discussion early but please note
that the wiki is still very much a work-in-progress. I am actively
working to clean up the use cases and the API spec is just to generate
discussion, I expect it to change based on general consensus.

We currently have 3 options for starting the Heater project:

1. Start Heater as a Stackforge project with a different core team
that is dedicated to actively working on Heater
2. Incubate Heater within the Orchestration umbrella using the
existing Heat Core team
3. Incubate Heater with the Orchestration umbrella, but create a
sub-project team responsible for reviewing and +2s

The idea behind creating a separate core team either via Stackforge or
an Orchestration sub-project is so that the people actively working on
Heater can review and iterate more quickly through code revisions than
dumping Heater code through the already strained Heat review pipeline.

You likely want the current heat-core on this team as well, to help
provide guidance about how we operate in the Orchestration program. But
yes, the core team is strained already processing existing review
workloads and can't handle a high-velocity change new code base very
easily. The long term solution to this problem is for more folks to
provide reviews and join the heat core team. But that doesn't help the
heatrr case.

Regards
-steve

We are still ironing out the definition of a schema for Heater based
on the existing use cases in the wiki and we would very much
appreciate any input with regards to the existing use cases or
proposed API spec. In particular, it is starting to become apparent
that a few of the defined schema are not necessarily related to Heater
specifically and may make good candidates to start a separate
discussion on inclusion in the HOT specification.

The following things, specifically, would add value to the HOT
specification in general (copied from the wiki if you need further
context):

application:
name: Wordpress
version: 3.6.1
flavor: Single Linux server with WordPress 3.6.1 and MySQL 5.5
weight: 3
icons:
-
href:https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-tattoo.png
type: default
-
href:https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-icon-20x20.png
type: small
keywords:
- wordpress
- mysql
documentation:
abstract:
some abstract...
guide:
This blueprint includes a single server running Wordpress with Varnish.
This blueprint's performance has not been measured.
instructions:
If you're new to WordPress, the
documentation will step you through the process of logging into the
admin panel, customizing your blog, and changing your theme.
Keywords has already been the subject of another mailing list
conversation so let's ignore that one for the moment. If there is
general consensus that we should at least discuss application, icons,
and documentation as possible candidates for the HOT syntax then I
will start a separate mailing list thread to detail out the use cases.

The original thought was, other things like template versioning
information and keystone roles for permissions are very obviously
related to Heater. Heater will use those things to make decisions
about how it works. But application information, icons and
documentation are not things that Heater cares about. Heat also does
not care about these things but the downstream user interface does
care about these things and a human looking at the Heat template would
be able to gather valuable information from these things as well.

Obviously, the actual structure and use cases for these things would
need to be vetted before inclusion in the HOT syntax but let's discuss
the more general idea that the HOT syntax should include things that
Heat (or Heater) does not care about but can prove to add real value
to the user experience at some point in a user's interaction with Heat.

Thanks,
Tim

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

Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last released version of keystoneclient does not work with python33

2013-12-04 Thread Jamie Lennox

Adrian, 

I had a look a little while ago and I don't *think* it's too bad.
Because it's hooking into sockets and dealing with web requests though
there is a lot of messing with what is unicode vs ascii and the py2 vs
py3 differences. 

I'm sure it's doable, but i hate those kind of problems :) 

>From a dev point of view it's a good library and i recommend the various
clients look at it rather than our home grown client stubbing. 

Internally he's done some interesting things like maintaining his own
compat rather than just using six, and it's tested using an unknown
framework that does a hook into PyObject * (CPython) which is just
wrong. But we don't need to fix the whole project, just py33.

Jamie


On Wed, 2013-12-04 at 23:44 +, Adrian Otto wrote:
> Jamie,
> 
> Thanks for the guidance here. I am checking to see if any of our developers 
> might take an interest in helping with the upstream work. At the very least, 
> it might be nice to have some understanding of how much work there is to be 
> done in HTTPretty.
> 
> Cheers,
> 
> Adrian
> 
> On Dec 4, 2013, at 3:29 PM, Jamie Lennox 
>  wrote:
> 
> > Adrian, 
> > 
> > The main blocker for the time being with keystoneclient and py3 is our
> > use of a library called HTTPretty in our testing - on which there is a
> > very recent thread. There is upstream work to make this py3 compatible
> > but i'm not sure how quickly it's moving. 
> > 
> > Any code in keystoneclient itself that is not py33 compatible should be
> > considered a bug - but obviously due to the missed testing we don't pick
> > this up very often.
> > 
> > There is no timeline at the moment, however anyone with py33 experience
> > looking to make this happen faster could contribute to this branch on
> > github: https://github.com/gabrielfalcao/HTTPretty/pull/124 and help
> > upstream. Once there is a py33 release available keystoneclient will not
> > be far behind. 
> > 
> > Jamie 
> > 
> > On Wed, 2013-12-04 at 20:59 +, Adrian Otto wrote:
> >> Dolph, 
> >> 
> >> 
> >> Is anyone already focusing on py33 compatibility for
> >> python-keystoneclient? Has that effort been scoped? I'd like to judge
> >> whether it's reasonable to expect us to patch it up to be compatible
> >> in the near term, or relax our expectations. For Solum, we are trying
> >> to make all our code py33 compatible from the start, so we take it
> >> seriously when the py33 gate fails. Please advise.
> >> 
> >> 
> >> Thanks,
> >> 
> >> 
> >> Adrian
> >> 
> >> On Dec 4, 2013, at 12:24 PM, Dolph Mathews 
> >> wrote:
> >> 
> >>> 
> >>> On Wed, Dec 4, 2013 at 1:26 PM, Georgy Okrokvertskhov
> >>>  wrote:
> >>>Hi, 
> >>> 
> >>> 
> >>>I have failed tests in gate-solum-python33 because
> >>>kesytoneclient fails to import xmlrpclib. 
> >>>The exact error is:
> >>>"File
> >>>
> >>> "/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/keystoneclient/openstack/common/jsonutils.py",
> >>>  line 42, in 
> >>>2013-11-28 18:27:12.655 | import xmlrpclib
> >>>2013-11-28 18:27:12.655 | ImportError: No module named
> >>>'xmlrpclib
> >>>"
> >>>This issue appeared because of xmlrpclib was renamed in
> >>>python33.
> >>>Is there any plan to release a new version
> >>>of keystoneclient with the fix for that issue? As I see it
> >>>is fixed in master.
> >>> 
> >>> 
> >>>If there is no new release for keystoneclient can you
> >>>recommend any workaround for this issue?
> >>> 
> >>> 
> >>> 
> >>> 
> >>> I'd be happy to make a release keystoneclient, but I don't believe
> >>> that's the only issue with python 3 at the moment (at least on the
> >>> CLI?). For example:
> >>> 
> >>> 
> >>>  https://bugs.launchpad.net/python-keystoneclient/+bug/1249165
> >>> 
> >>> 
> >>> In the current master, the above issue is only reproducible after
> >>> syncing oslo (otherwise it fails on yet another python 3
> >>> incompatibility).
> >>> 
> >>> 
> >>>Thanks
> >>>Georgy
> >>> 
> >>>___
> >>>OpenStack-dev mailing list
> >>>OpenStack-dev@lists.openstack.org
> >>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> ___
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev@lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> 
> >> 
> >> 
> > 
> > 
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___

Re: [openstack-dev] [heat] Heater Proposal

On Dec 4, 2013, at 4:06 PM, "Fox, Kevin M" 
 wrote:

> What is the difference between Heater, Cloudify 
> (http://appcatalog.cloudifysource.org/#/?tumblr)

Cloudify is a Java based open source cloud management tool from Gigaspaces. 
Cloudify developers are part of the Solum project as well, and are supporting 
the effort.

> and Murano (https://wiki.openstack.org/wiki/Murano)

Murano is a Stackforge project that has recently pivoted into something I would 
describe as an app catalog system. I am interested in it from a Solum 
perspective.

> If Heater is intended to be a subset of Cloudify/Murano

I think that Heater and Murano are complimentary, and that Murano could 
potentially leverage Heater when it takes form. This possibility should be 
discussed with the Murano contributors prior to drawing any further conclusions.

Note that Heater's focus in much more narrow than Murano's.

> that they both would use, it might be good to start off like the Solum folks 
> are?

I have participated in leading Solum through a process similar to the #1 option 
proposed below by Tim Schnell. That may be a bit more foolling around than is 
really needed for this. My vote would be for starting with option #2 (the 
easiest one), and transitioning to #3 if the code review process seems 
restrictive, or if the core team for Heat feels it's too much of a burden to do 
the reviews.

Adrian

> 
> Thanks,
> Kevin
> 
> From: Tim Schnell [tim.schn...@rackspace.com]
> Sent: Wednesday, December 04, 2013 3:34 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [heat] Heater Proposal
> 
> Hi Heaters,
> 
> We would like to start a dialog on the general direction of the proposed 
> Heater project:
> blueprint: https://blueprints.launchpad.net/heat/+spec/heat-template-repo
> wiki: https://wiki.openstack.org/wiki/Heat/htr
> 
> It is important to us to start the discussion early but please note that the 
> wiki is still very much a work-in-progress. I am actively working to clean up 
> the use cases and the API spec is just to generate discussion, I expect it to 
> change based on general consensus.
> 
> We currently have 3 options for starting the Heater project:
> 
> 1.  Start Heater as a Stackforge project with a different core team that is 
> dedicated to actively working on Heater
> 2.  Incubate Heater within the Orchestration umbrella using the existing Heat 
> Core team
> 3.  Incubate Heater with the Orchestration umbrella, but create a sub-project 
> team responsible for reviewing and +2s
> 
> The idea behind creating a separate core team either via Stackforge or an 
> Orchestration sub-project is so that the people actively working on Heater 
> can review and iterate more quickly through code revisions than dumping 
> Heater code through the already strained Heat review pipeline.
> 
> We are still ironing out the definition of a schema for Heater based on the 
> existing use cases in the wiki and we would very much appreciate any input 
> with regards to the existing use cases or proposed API spec. In particular, 
> it is starting to become apparent that a few of the defined schema are not 
> necessarily related to Heater specifically and may make good candidates to 
> start a separate discussion on inclusion in the HOT specification.
> 
> The following things, specifically, would add value to the HOT specification 
> in general (copied from the wiki if you need further context):
> 
> application:
>   name: Wordpress
>   version: 3.6.1
>   flavor: Single Linux server with WordPress 3.6.1 and MySQL 5.5
>   weight: 3
> icons:
> - href: 
> https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-tattoo.png
>   type: default
> - href: 
> https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-icon-20x20.png
>   type: small
> keywords:
> - wordpress
> - mysql
> 
> documentation:
>   abstract:
> some abstract...
>   guide:
> This blueprint includes a single server running Wordpress with Varnish.
> This blueprint's performance has not been measured.
>   instructions:
> If you're new to WordPress, the
> documentation will step you through the process of logging into the
> admin panel, customizing your blog, and changing your theme.
> 
> Keywords has already been the subject of another mailing list conversation so 
> let's ignore that one for the moment. If there is general consensus that we 
> should at least discuss application, icons, and documentation as possible 
> candidates for the HOT syntax then I will start a separate mailing list 
> thread to detail out the use cases.
> 
> The original thought was, other things like template versioning information 
> and keystone roles for permissions are very obviously related to Heater. 
> Heater will use those things to make decisions about how it works. But 
> application information, icons and documentation are

[openstack-dev] [State-Management] Agenda for tomorrow meeting at 2000 UTC

2013-12-04 Thread Joshua Harlow

Hi all,

The [state-management] project team holds a weekly meeting in 
#openstack-meeting on thursdays, 2000 UTC. The next meeting is tomorrow, 
2013-12-05!!!

As usual, everyone is welcome :-)

Link: https://wiki.openstack.org/wiki/Meetings/StateManagement
Taskflow: https://wiki.openstack.org/TaskFlow

## Agenda (30-60 mins):

- Discuss any action items from last meeting.
- Discuss current integration progress/blockers.
- Discuss new taskflow features progress/blockers.
  - Discuss worker-engine prototype 
[https://etherpad.openstack.org/p/TaskFlowWorkerBasedEngine]
- Get feedback on me doing a demo of zookeeper code (screencast?).
  - Anyone else like to demo anything?
- Discuss about any other potential new use-cases for said library.
- Discuss about any other ideas, problems, open-reviews, issues, solutions, 
questions (and more!).

Any other topics are welcome :-)

See you all soon!

--

Joshua Harlow

It's openstack, relax... | harlo...@yahoo-inc.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Calling a controller from within a session in the plugin

2013-12-04 Thread Aaron Rosen

In my experience doing any kind of http request inside a of a db
transaction kills performance vastly (and can lead to situations where
deadlock often occurs due to eventlet+sqlalchemly). This topic also was
recently discussed here:
http://lists.openstack.org/pipermail/openstack-dev/2013-November/019624.html

Best,

Aaron


On Wed, Dec 4, 2013 at 9:15 AM, Mohammad Banikazemi  wrote:

> Have a question regarding calling an external SDN controller in a plugin.
> The ML2 model brings up the fact that it is preferred not to call an
> external controller within a database session by splitting up each call
> into two calls: *_precommit and *_postcommit. Makes sense.
>
> Looking at the existing monolithic plugins, I see some plugins that do not
> follow this approach and have the call to the controller from within a
> session. The obvious benefit of this approach would be a simpler cleanup
> code segment for cases where the call to controller fails. So my question
> is whether it is still OK to use this simpler approach in monolithic
> plugins. As we move to the ML2 model, we will be using the ML2 approach but
> in the meantime, we leave the option of calling the controller within a
> session as an OK option. Would that be reasonable?
>
> -Mohammad
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last released version of keystoneclient does not work with python33

Clint,

On Dec 4, 2013, at 4:06 PM, Clint Byrum 
 wrote:

> Excerpts from Adrian Otto's message of 2013-12-04 15:44:45 -0800:
>> Jamie,
>> 
>> Thanks for the guidance here. I am checking to see if any of our developers 
>> might take an interest in helping with the upstream work. At the very least, 
>> it might be nice to have some understanding of how much work there is to be 
>> done in HTTPretty.
>> 
> 
> Seems to me that we're still too early in the process for a downstream
> application like Solum to gate on py3k. It will be more productive to
> focus efforts on getting upstreams in-line and making sure they stay
> in-line.

The py33 work is going to need to get done at some point. If we are py33 
compatible from the start, there is less work to do later. I am suggesting that 
we clean up the upstreams. Keystone, and by association HTTPretty are Solum's 
upstreams for our auth feature. That's where I am suggesting we take a look.

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

Re: [openstack-dev] [qa] Moving the QA meeting time

2013-12-04 Thread Kenichi Oomichi


Hi Matthew,

Thank you for picking this up.

> -Original Message-
> From: Matthew Treinish [mailto:mtrein...@kortar.org]
> Sent: Thursday, December 05, 2013 6:04 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [qa] Moving the QA meeting time
> 
> Hi everyone,
> 
> I'm looking at changing our weekly QA meeting time to make it more globally
> attendable. Right now the current time of 17:00 UTC doesn't really work for
> people who live in Asia Pacific timezones. (which includes a third of the
> current core review team) There are 2 approaches that I can see taking here:
> 
>  1. We could either move the meeting time later so that it makes it easier for
> people in the Asia Pacific region to attend.
> 
>  2. Or we move to a alternating meeting time, where every other week the 
> meeting
> time changes. So we keep the current slot and alternate with something 
> more
> friendly for other regions.
> 
> I think trying to stick to a single meeting time would be a better call just 
> for
> simplicity. But it gets difficult to appease everyone that way which is where 
> the
> appeal of the 2nd approach comes in.
> 
> Looking at the available time slots here: 
> https://wiki.openstack.org/wiki/Meetings
> there are plenty of open slots before 1500 UTC which would be early for 
> people in
> the US and late for people in the Asia Pacific region. There are plenty of 
> slots
> starting at 2300 UTC which is late for people in Europe.
> 
> Would something like 2200 UTC on Wed. or Thurs work for everyone?
> 
> What are people's opinions on this?

I am in JST.
Is Chris in CST, and Marc in CET?

Here is timezone difference.
15:00 UTC -> 07:00 PST -> 01:30 CST -> 16:00 CET - 24:00 JST
22:00 UTC -> 14:00 PST -> 08:30 CST -> 23:00 CET - 07:00 JST
23:00 UTC -> 15:00 PST -> 09:30 CST -> 24:00 CET - 08:00 JST

I feel 22:00 would be nice.

Thanks
Ken'ichi Ohmichi


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

Re: [openstack-dev] [heat] Heater Proposal

2013-12-04 Thread Fox, Kevin M

What is the difference between Heater, Cloudify 
(http://appcatalog.cloudifysource.org/#/?tumblr) and Murano 
(https://wiki.openstack.org/wiki/Murano)

If Heater is intended to be a subset of Cloudify/Murano that they both would 
use, it might be good to start off like the Solum folks are?

Thanks,
Kevin

From: Tim Schnell [tim.schn...@rackspace.com]
Sent: Wednesday, December 04, 2013 3:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [heat] Heater Proposal

Hi Heaters,

We would like to start a dialog on the general direction of the proposed Heater 
project:
blueprint: https://blueprints.launchpad.net/heat/+spec/heat-template-repo
wiki: https://wiki.openstack.org/wiki/Heat/htr

It is important to us to start the discussion early but please note that the 
wiki is still very much a work-in-progress. I am actively working to clean up 
the use cases and the API spec is just to generate discussion, I expect it to 
change based on general consensus.

We currently have 3 options for starting the Heater project:

 1.  Start Heater as a Stackforge project with a different core team that is 
dedicated to actively working on Heater
 2.  Incubate Heater within the Orchestration umbrella using the existing Heat 
Core team
 3.  Incubate Heater with the Orchestration umbrella, but create a sub-project 
team responsible for reviewing and +2s

The idea behind creating a separate core team either via Stackforge or an 
Orchestration sub-project is so that the people actively working on Heater can 
review and iterate more quickly through code revisions than dumping Heater code 
through the already strained Heat review pipeline.

We are still ironing out the definition of a schema for Heater based on the 
existing use cases in the wiki and we would very much appreciate any input with 
regards to the existing use cases or proposed API spec. In particular, it is 
starting to become apparent that a few of the defined schema are not 
necessarily related to Heater specifically and may make good candidates to 
start a separate discussion on inclusion in the HOT specification.

The following things, specifically, would add value to the HOT specification in 
general (copied from the wiki if you need further context):

application:
   name: Wordpress
   version: 3.6.1
   flavor: Single Linux server with WordPress 3.6.1 and MySQL 5.5
   weight: 3
 icons:
 - href: 
https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-tattoo.png
   type: default
 - href: 
https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-icon-20x20.png
   type: small
 keywords:
 - wordpress
 - mysql

documentation:
   abstract:
 some abstract...
   guide:
 This blueprint includes a single server running Wordpress with Varnish.
 This blueprint's performance has not been measured.
   instructions:
 If you're new to WordPress, the
 documentation will step you through the process of logging into the
 admin panel, customizing your blog, and changing your theme.

Keywords has already been the subject of another mailing list conversation so 
let's ignore that one for the moment. If there is general consensus that we 
should at least discuss application, icons, and documentation as possible 
candidates for the HOT syntax then I will start a separate mailing list thread 
to detail out the use cases.

The original thought was, other things like template versioning information and 
keystone roles for permissions are very obviously related to Heater. Heater 
will use those things to make decisions about how it works. But application 
information, icons and documentation are not things that Heater cares about. 
Heat also does not care about these things but the downstream user interface 
does care about these things and a human looking at the Heat template would be 
able to gather valuable information from these things as well.

Obviously, the actual structure and use cases for these things would need to be 
vetted before inclusion in the HOT syntax but let's discuss the more general 
idea that the HOT syntax should include things that Heat (or Heater) does not 
care about but can prove to add real value to the user experience at some point 
in a user's interaction with Heat.

Thanks,
Tim


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

Re: [openstack-dev] Printing to stdout

2013-12-04 Thread Kevin L. Mitchell

On Wed, 2013-12-04 at 14:59 -0800, Abhishek Chanda wrote:
> I am a new contributor. While poking around, I thought that a standard
> way to print information to stdout is necessary in a number of places.
> Is there a plan to put this into oslo? I could not find any existing
> blueprint on this. I'd be happy to take care of this.

Can you be a little more specific?  In what context do you want to print
to stdout?  That is, which client?  (Servers should never print to
stdout; use the logging infrastructure for output.)
-- 
Kevin L. Mitchell 
Rackspace


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

Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last released version of keystoneclient does not work with python33

Excerpts from Adrian Otto's message of 2013-12-04 15:44:45 -0800:
> Jamie,
> 
> Thanks for the guidance here. I am checking to see if any of our developers 
> might take an interest in helping with the upstream work. At the very least, 
> it might be nice to have some understanding of how much work there is to be 
> done in HTTPretty.
> 

Seems to me that we're still too early in the process for a downstream
application like Solum to gate on py3k. It will be more productive to
focus efforts on getting upstreams in-line and making sure they stay
in-line.

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

Re: [openstack-dev] [Tempest] Which is the best way for skipping tests?

2013-12-04 Thread Brant Knudson

In Keystone, we've got some tests that "raise self.skipTest('...')" in the
test class setUp() method (not setUpClass). My testing shows that if
there's several tests in the class then it shows all of those tests as
skipped (not just 1 skip). Does this do what you want?

Here's an example:
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/test_ipv6.py?id=73dbc00e6ac049f19d0069ecb07ca8ed75627dd5#n30

http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/core.py?id=73dbc00e6ac049f19d0069ecb07ca8ed75627dd5#n500

 - Brant

On Wed, Dec 4, 2013 at 5:46 AM, Daisuke Morita  wrote:

> Hi, everyone.
>
> Which do you think is the best way of coding test skipping, "writing
> cls.skipException statement in setUpClass method" or "skipIf annotation
> for each test method" ?
>
> This question comes to me in reviewing
> https://review.openstack.org/#/c/59759/ . I think that work itself is
> great and I hope this patch is merged to Tempest. I just want to focus
> on coding styles and explicitness of test outputs.
>
> If skipIf annotation is used, test output of Swift is as follows.
>
> ---
> tempest.api.object_storage.test_account_quotas.AccountQuotasTest
> test_admin_modify_quota[gate,smoke]
> SKIP  1.15
> test_upload_large_object[gate,negative,smoke]
> SKIP  0.03
> test_upload_valid_object[gate,smoke]
> SKIP  0.03
> test_user_modify_quota[gate,negative,smoke]
> SKIP  0.03
> tempest.api.object_storage.test_account_services.AccountTest
> test_create_and_delete_account_metadata[gate,smoke]   OK
>  0.32
> test_list_account_metadata[gate,smoke]OK
>  0.02
> test_list_containers[gate,smoke]  OK
>  0.02
>
> ...(SKIP)...
>
> Ran 54 tests in 85.977s
>
> OK
> ---
>
>
> On the other hand, if cls.skipException is used, an output is changed as
> follows.
>
> ---
> setUpClass (tempest.api.object_storage.test_account_quotas
> AccountQuotasTest)
> SKIP  0.00
> tempest.api.object_storage.test_account_services.AccountTest
> test_create_and_delete_account_metadata[gate,smoke]   OK
>  0.48
> test_list_account_metadata[gate,smoke]OK
>  0.02
> test_list_containers[gate,smoke]  OK
>  0.02
>
> ...(SKIP)...
>
> Ran 49 tests in 81.475s
>
> OK
> ---
>
>
> I believe the output of the code using skipIf annotation is better.
> Since the coverage of tests is displayed more definitely, it is easier
> to find out what tests are really skipped.
>
> I scanned the whole code of Tempest. The count of cls.skipException
> statements is 63, and the count of skipIf annotations is 24. Replacing
> them is not trivial task, but I think the most impportant for testing is
> to output consistent and accurate log.
>
>
> Am I missing something? Or, this kind of discussion has been done
> already in the past? If so, could you let me know?
>
>
> Best Regards,
>
> --
> Daisuke Morita 
> NTT Software Innovation Center, NTT Corporation
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last released version of keystoneclient does not work with python33

Jamie,

Thanks for the guidance here. I am checking to see if any of our developers 
might take an interest in helping with the upstream work. At the very least, it 
might be nice to have some understanding of how much work there is to be done 
in HTTPretty.

Cheers,

Adrian

On Dec 4, 2013, at 3:29 PM, Jamie Lennox 
 wrote:

> Adrian, 
> 
> The main blocker for the time being with keystoneclient and py3 is our
> use of a library called HTTPretty in our testing - on which there is a
> very recent thread. There is upstream work to make this py3 compatible
> but i'm not sure how quickly it's moving. 
> 
> Any code in keystoneclient itself that is not py33 compatible should be
> considered a bug - but obviously due to the missed testing we don't pick
> this up very often.
> 
> There is no timeline at the moment, however anyone with py33 experience
> looking to make this happen faster could contribute to this branch on
> github: https://github.com/gabrielfalcao/HTTPretty/pull/124 and help
> upstream. Once there is a py33 release available keystoneclient will not
> be far behind. 
> 
> Jamie 
> 
> On Wed, 2013-12-04 at 20:59 +, Adrian Otto wrote:
>> Dolph, 
>> 
>> 
>> Is anyone already focusing on py33 compatibility for
>> python-keystoneclient? Has that effort been scoped? I'd like to judge
>> whether it's reasonable to expect us to patch it up to be compatible
>> in the near term, or relax our expectations. For Solum, we are trying
>> to make all our code py33 compatible from the start, so we take it
>> seriously when the py33 gate fails. Please advise.
>> 
>> 
>> Thanks,
>> 
>> 
>> Adrian
>> 
>> On Dec 4, 2013, at 12:24 PM, Dolph Mathews 
>> wrote:
>> 
>>> 
>>> On Wed, Dec 4, 2013 at 1:26 PM, Georgy Okrokvertskhov
>>>  wrote:
>>>Hi, 
>>> 
>>> 
>>>I have failed tests in gate-solum-python33 because
>>>kesytoneclient fails to import xmlrpclib. 
>>>The exact error is:
>>>"File
>>>
>>> "/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/keystoneclient/openstack/common/jsonutils.py",
>>>  line 42, in 
>>>2013-11-28 18:27:12.655 | import xmlrpclib
>>>2013-11-28 18:27:12.655 | ImportError: No module named
>>>'xmlrpclib
>>>"
>>>This issue appeared because of xmlrpclib was renamed in
>>>python33.
>>>Is there any plan to release a new version
>>>of keystoneclient with the fix for that issue? As I see it
>>>is fixed in master.
>>> 
>>> 
>>>If there is no new release for keystoneclient can you
>>>recommend any workaround for this issue?
>>> 
>>> 
>>> 
>>> 
>>> I'd be happy to make a release keystoneclient, but I don't believe
>>> that's the only issue with python 3 at the moment (at least on the
>>> CLI?). For example:
>>> 
>>> 
>>>  https://bugs.launchpad.net/python-keystoneclient/+bug/1249165
>>> 
>>> 
>>> In the current master, the above issue is only reproducible after
>>> syncing oslo (otherwise it fails on yet another python 3
>>> incompatibility).
>>> 
>>> 
>>>Thanks
>>>Georgy
>>> 
>>>___
>>>OpenStack-dev mailing list
>>>OpenStack-dev@lists.openstack.org
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [heat] Heater Proposal

2013-12-04 Thread Tim Schnell

Hi Heaters,

We would like to start a dialog on the general direction of the proposed Heater 
project:
blueprint: https://blueprints.launchpad.net/heat/+spec/heat-template-repo
wiki: https://wiki.openstack.org/wiki/Heat/htr

It is important to us to start the discussion early but please note that the 
wiki is still very much a work-in-progress. I am actively working to clean up 
the use cases and the API spec is just to generate discussion, I expect it to 
change based on general consensus.

We currently have 3 options for starting the Heater project:

  1.  Start Heater as a Stackforge project with a different core team that is 
dedicated to actively working on Heater
  2.  Incubate Heater within the Orchestration umbrella using the existing Heat 
Core team
  3.  Incubate Heater with the Orchestration umbrella, but create a sub-project 
team responsible for reviewing and +2s

The idea behind creating a separate core team either via Stackforge or an 
Orchestration sub-project is so that the people actively working on Heater can 
review and iterate more quickly through code revisions than dumping Heater code 
through the already strained Heat review pipeline.

We are still ironing out the definition of a schema for Heater based on the 
existing use cases in the wiki and we would very much appreciate any input with 
regards to the existing use cases or proposed API spec. In particular, it is 
starting to become apparent that a few of the defined schema are not 
necessarily related to Heater specifically and may make good candidates to 
start a separate discussion on inclusion in the HOT specification.

The following things, specifically, would add value to the HOT specification in 
general (copied from the wiki if you need further context):

application:
   name: Wordpress
   version: 3.6.1
   flavor: Single Linux server with WordPress 3.6.1 and MySQL 5.5
   weight: 3
 icons:
 - href: 
https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-tattoo.png
   type: default
 - href: 
https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-icon-20x20.png
   type: small
 keywords:
 - wordpress
 - mysql

documentation:
   abstract:
 some abstract...
   guide:
 This blueprint includes a single server running Wordpress with Varnish.
 This blueprint's performance has not been measured.
   instructions:
 If you're new to WordPress, the
 documentation will step you through the process of logging into the
 admin panel, customizing your blog, and changing your theme.

Keywords has already been the subject of another mailing list conversation so 
let's ignore that one for the moment. If there is general consensus that we 
should at least discuss application, icons, and documentation as possible 
candidates for the HOT syntax then I will start a separate mailing list thread 
to detail out the use cases.

The original thought was, other things like template versioning information and 
keystone roles for permissions are very obviously related to Heater. Heater 
will use those things to make decisions about how it works. But application 
information, icons and documentation are not things that Heater cares about. 
Heat also does not care about these things but the downstream user interface 
does care about these things and a human looking at the Heat template would be 
able to gather valuable information from these things as well.

Obviously, the actual structure and use cases for these things would need to be 
vetted before inclusion in the HOT syntax but let's discuss the more general 
idea that the HOT syntax should include things that Heat (or Heater) does not 
care about but can prove to add real value to the user experience at some point 
in a user's interaction with Heat.

Thanks,
Tim

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

Re: [openstack-dev] [Keystoneclient] [Keystone] Last released version of keystoneclient does not work with python33

2013-12-04 Thread Jamie Lennox

Adrian, 

The main blocker for the time being with keystoneclient and py3 is our
use of a library called HTTPretty in our testing - on which there is a
very recent thread. There is upstream work to make this py3 compatible
but i'm not sure how quickly it's moving. 

Any code in keystoneclient itself that is not py33 compatible should be
considered a bug - but obviously due to the missed testing we don't pick
this up very often.

There is no timeline at the moment, however anyone with py33 experience
looking to make this happen faster could contribute to this branch on
github: https://github.com/gabrielfalcao/HTTPretty/pull/124 and help
upstream. Once there is a py33 release available keystoneclient will not
be far behind. 

Jamie 

On Wed, 2013-12-04 at 20:59 +, Adrian Otto wrote:
> Dolph, 
> 
> 
> Is anyone already focusing on py33 compatibility for
> python-keystoneclient? Has that effort been scoped? I'd like to judge
> whether it's reasonable to expect us to patch it up to be compatible
> in the near term, or relax our expectations. For Solum, we are trying
> to make all our code py33 compatible from the start, so we take it
> seriously when the py33 gate fails. Please advise.
> 
> 
> Thanks,
> 
> 
> Adrian
> 
> On Dec 4, 2013, at 12:24 PM, Dolph Mathews 
>  wrote:
> 
> > 
> > On Wed, Dec 4, 2013 at 1:26 PM, Georgy Okrokvertskhov
> >  wrote:
> > Hi, 
> > 
> > 
> > I have failed tests in gate-solum-python33 because
> > kesytoneclient fails to import xmlrpclib. 
> > The exact error is:
> > "File
> > 
> > "/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/keystoneclient/openstack/common/jsonutils.py",
> >  line 42, in 
> > 2013-11-28 18:27:12.655 | import xmlrpclib
> > 2013-11-28 18:27:12.655 | ImportError: No module named
> > 'xmlrpclib
> > "
> > This issue appeared because of xmlrpclib was renamed in
> > python33.
> > Is there any plan to release a new version
> > of keystoneclient with the fix for that issue? As I see it
> > is fixed in master.
> > 
> > 
> > If there is no new release for keystoneclient can you
> > recommend any workaround for this issue?
> > 
> > 
> > 
> > 
> > I'd be happy to make a release keystoneclient, but I don't believe
> > that's the only issue with python 3 at the moment (at least on the
> > CLI?). For example:
> > 
> > 
> >   https://bugs.launchpad.net/python-keystoneclient/+bug/1249165
> > 
> > 
> > In the current master, the above issue is only reproducible after
> > syncing oslo (otherwise it fails on yet another python 3
> > incompatibility).
> >  
> > 
> > Thanks
> > Georgy
> > 
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > 
> > 
> > 
> > 
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 


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

Re: [openstack-dev] [neutron] Creating "recipes" for mimicking behavior of nova-networking network managers.

2013-12-04 Thread Tom Fifield

On 05/12/13 01:14, Brent Eagles wrote:
> Hi,
> 
> As part of the Icehouse nova-networking parity effort, we need to
> describe how nova-networking managers work and how the behavior is
> mapped to neutron. The benefits are:
> 
> 1. It aides migration: deployers who are nova-network savvy can see how
> functionality maps from one to the other.
> 
> 2. It aides implementation: if we cannot provide a mapping, there is a
> breakage in parity and it needs to be addressed somehow.
> 
> 3. It aides testing (and debugging): by illuminating points where the
> implementations differ, it makes it easier to design and implement tests
> that can be expected to function the same for each networking
> implementation.
> 
> 4. It aides acceptance: at some point, the proverbial *we* are going to
> decide whether neutron is ready to replace nova. The existence of
> working recipes is a pretty strong set of acceptance criteria.  Another
> way to look at it is that the recipes are essentially a high level
> description of how to go about manually testing parity.
> 
> 5. It aides support and documentation efforts: nearly any point in the
> openstack user "spectrum" (casual experimenter to hard-core
> developer/implementer) who has anything to do with legacy deployments or
> parity itself will benefit from having these recipes on hand. NOT to
> mention the "rtfm" option when somebody asks "I'm using FlatManager in
> nova-network and want to do the same in neutron, how does that work?" (I
> love being able to write "rtfm", don't you?)
> 
> Sounds great!?! Cool! Do you want to help or know someone who does (or
> should - third-person volunteering not discouraged!)? We need
> nova-networking savvy and neutron savvy folks alike, though you need not
> necessarily be both at the same time.
> 
> As some of the aforementioned benefits are directly relevant to the
> Icehouse development cycle AND the holiday season is upon us, it is
> important to get the ball rolling ASAP. To be specific, working recipes
> are most valuable if they are available for Icehouse-2 (see reasons 2, 3
> and most importantly 4).
> 
> Please respond if interested, want to volunteer someone or have comments
> and suggestions.

I think that's a great idea.

What kind of format would you like to see the recepies in?

Regards,

Tom


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

Re: [openstack-dev] [Solum] Unicode strings in Python3

Gregory and Ben,

Awesome, thanks!!

Adrian

On Dec 4, 2013, at 2:01 PM, Georgy Okrokvertskhov 
mailto:gokrokvertsk...@mirantis.com>>
 wrote:

I opened a bug https://bugs.launchpad.net/solum/+bug/1257929 for that issue.

Ben, thank you for a quick fix proposal.

Thanks
Georgy


On Wed, Dec 4, 2013 at 1:41 PM, Ben Nemec 
mailto:openst...@nemebean.com>> wrote:

I don't think so.  It looks like ./solum/api/controllers/v1/assembly.py is 
calling unicode().  It will need to be changed to six.text_type() for Python 3 
compat.

-Ben

On 2013-12-04 15:41, Adrian Otto wrote:

Am I interpreting this to mean that WSME is calling unicode()?

On Dec 4, 2013, at 1:32 PM, Georgy Okrokvertskhov 
mailto:gokrokvertsk...@mirantis.com>>
 wrote:

Hi,

I am working on unit tests for Solum as a side effect of new unit tests I found 
that we use unicode strings in the way which is not compatible with python3.

Here is an exception form python3 gate:
Server-side error: "global name 'unicode' is not defined". Detail: 2013-12-04 
Traceback (most recent call last): File 
"/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/wsmeext/pecan.py"
 result = f(self, *args, **kwargs)
 File "./solum/api/controllers/v1/assembly.py", line 59, in get
raise wsme.exc.ClientSideError(unicode(error))
NameError: global name 'unicode' is not defined

Here is a documentation for python3: 
http://docs.python.org/3.0/whatsnew/3.0.html

Quick summary: you can't use unicode() function and u' ' strings in Pyhton3.

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


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





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




--
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Solumn] Suggestion about usage of mailing lists

Boris,

On Dec 4, 2013, at 2:53 PM, Boris Pavlovic 
mailto:bpavlo...@mirantis.com>>
 wrote:

All,

Thank you guys for your opinion.

As a conclusion of this thread, I think that I shouldn't hesitate to raise all 
discussion about Rally in mailing list also.. Right?

Yes, if your team feels that it would benefit from using the ML for 
collaboration, then thou should use it. If you prefer to use other tools, you 
can do that too.

Adrian

Best regards,
Boris Pavlovic

On Thu, Dec 5, 2013 at 2:42 AM, Robert Collins 
mailto:robe...@robertcollins.net>> wrote:
On 5 December 2013 11:39, Boris Pavlovic 
mailto:bpavlo...@mirantis.com>> wrote:
> Russell,
>
> Actually what I said is not only related to Solumn or any other project.
>
> Main "idea" of it was that, well structured etherpads are much better
> instrument for such discussions.
>
> Do you disagree with this also?

I disagree with it.

I think /discussion/ in a mailing list is a great way to get broad input.
IRC gets narrow - whoever is on at the time - input
etherpads get very little input *unless* you reach out over IRC and
lists to get the input

Etherpads are very good for *assembling* the result of discussions and
debugging plans and so forth.

Wiki pages are great for doing adhoc manuals and living
google-searchable reference material.

IMNSHO.

-Rob

--
Robert Collins mailto:rbtcoll...@hp.com>>
Distinguished Technologist
HP Converged Cloud

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

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

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

Re: [openstack-dev] [ceilometer][qa] Punting ceilometer from whitelist

2013-12-04 Thread Gordon Chung

> As a developer think about the fact that when you log something as
> ERROR, you are expecting a cloud operator to be woken up in the middle
> of the night with an email alert to go fix the cloud immediately. You
> are intentionally ruining someone's weekend to fix this issue - RIGHT 
NOW!

was going to ask what CRITICAL level was for... good thing i googled 
first: http://docs.python.org/2/howto/logging.html seems like a good 
enough definition for each level.

cheers,
gordon chung

openstack, ibm software standards
email: chungg [at] ca.ibm.com___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Printing to stdout

2013-12-04 Thread Abhishek Chanda

Hi all,

I am a new contributor. While poking around, I thought that a standard way
to print information to stdout is necessary in a number of places. Is there
a plan to put this into oslo? I could not find any existing blueprint on
this. I'd be happy to take care of this.

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

Re: [openstack-dev] [Solumn] Suggestion about usage of mailing lists

2013-12-04 Thread Boris Pavlovic

All,

Thank you guys for your opinion.

As a conclusion of this thread, I think that I shouldn't hesitate to raise
all discussion about Rally in mailing list also.. Right?


Best regards,
Boris Pavlovic



On Thu, Dec 5, 2013 at 2:42 AM, Robert Collins wrote:

> On 5 December 2013 11:39, Boris Pavlovic  wrote:
> > Russell,
> >
> > Actually what I said is not only related to Solumn or any other project.
> >
> > Main "idea" of it was that, well structured etherpads are much better
> > instrument for such discussions.
> >
> > Do you disagree with this also?
>
> I disagree with it.
>
> I think /discussion/ in a mailing list is a great way to get broad input.
> IRC gets narrow - whoever is on at the time - input
> etherpads get very little input *unless* you reach out over IRC and
> lists to get the input
>
> Etherpads are very good for *assembling* the result of discussions and
> debugging plans and so forth.
>
> Wiki pages are great for doing adhoc manuals and living
> google-searchable reference material.
>
> IMNSHO.
>
> -Rob
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] New API requirements, review of GCE

2013-12-04 Thread Ian Wells

On 20 November 2013 00:22, Robert Collins  wrote:

> On 20 November 2013 13:00, Sean Dague  wrote:
> > So we recently moved devstack gate to do con fig drive instead of
> metadata
> > service, and life was good (no one really noticed). In what ways is
> > configdrive insufficient compared to metadata service? And is that
> something
> > that we should be tackling?
>
> * The metadata service can be trivially updated live - and Heat wants
> to use this to get rid of it's own metadata service... whereas config
> drive requires unplugging the device, updating the data and replugging
> - and thats a bit more invasive.
>
> * Nova baremetal doesn't support config-drive today, and it's an open
> question as to whether we ever will - and if we do we can't do the hot
> unplug thing, so anyone using it would suffer downtime to update data.
>
> * config drive permits no-control-plane-visibility for instances,
> which some secure environments consider to be super important.
>
> So I think we'll have both indefinitely at this point - they serve
> overlapping but differing audiences.
>
> We should be testing both.
>

Since we've drifted off topic:

Metadata doesn't work with ipv6, because there's no well known ipv6 address
to go talk to (unless someone's made one up since I last looked).  Metadata
doesn't work if you have no IP address (!).  Metadata has certain
limitations with Neutron (you need a router on your network or you get no
data).

I think all the above things are fixable, and the only really concerning
one would be ipv6 + baremetal where apparently we have no solution that
works at present.
-- 
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solumn] Suggestion about usage of mailing lists

On 5 December 2013 11:39, Boris Pavlovic  wrote:
> Russell,
>
> Actually what I said is not only related to Solumn or any other project.
>
> Main "idea" of it was that, well structured etherpads are much better
> instrument for such discussions.
>
> Do you disagree with this also?

I disagree with it.

I think /discussion/ in a mailing list is a great way to get broad input.
IRC gets narrow - whoever is on at the time - input
etherpads get very little input *unless* you reach out over IRC and
lists to get the input

Etherpads are very good for *assembling* the result of discussions and
debugging plans and so forth.

Wiki pages are great for doing adhoc manuals and living
google-searchable reference material.

IMNSHO.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [Solumn] Suggestion about usage of mailing lists

2013-12-04 Thread Boris Pavlovic

Russell,

Actually what I said is not only related to Solumn or any other project.

Main "idea" of it was that, well structured etherpads are much better
instrument for such discussions.

Do you disagree with this also?


Best regards,
Boris Pavlovic


On Thu, Dec 5, 2013 at 2:12 AM, Russell Bryant  wrote:

> On 12/04/2013 05:07 PM, Boris Pavlovic wrote:
> > Guys,
> >
> > I really appreciate that all discussion are real open, and you are doing
> > a great job, discussing all arch stuff of the project. But for such
> > things there are:
> > 1) IRC chats
> > 2) WIKI pages
> > 3) ehterpads
> >
> > E.g. in Rally we have 1 page:
> > https://etherpad.openstack.org/p/Rally_Main that contains all important
> > information about:
> > 1) RoadMaps
> > 2) Links to active discussions
> > 3) Current Active and Open Tasks
> > So everybody is able to discuss what he want with the rest of the
> > project community, without tons of emails..
> >
> > Could I ask you guys to send emails only about:
> > 1) Releases
> > 2) Major changes and news
> > 3) Questions
> > 4) Incubation stuff
> > 5) Integration with other projects
> >
> > And avoid discussing every piece of arch in mailing list. Because if
> >  each project will start to discuss all arch stuff in mailing list, we
> > will have billions of emails per minute in openstack-dev.
> >
> >
> > Sorry for this email, and thank you for understanding.
>
> I have pretty much the exact opposite opinion of what you expressed here.
>
> If you don't want to see it, please use filters or only subscribe to the
> topics you care about.
>
> Thanks,
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solumn] Suggestion about usage of mailing lists

Boris,

Thanks for expressing your concern about this. For those reading the Solum 
topic on this list, we really want this to be a community building resource 
were we are free to discuss ideas and as a primary mechanism for gauging 
consensus. Applying restrictions to how the list is used by project 
contributors will actually limit discussion and reduce our level of engagement. 
That's just bad.

Solum is in a rapid growth phase, and lots of discussion is required, including 
coordination of our design efforts. There are many divisions to be made, and 
even with three hours of scheduled meetings every week, there is just not 
enough time to make them all on IRC. We are treating the ML as a first class 
resource to make decisions that are not practical to make interactively in our 
regularly scheduled meetings. This is one of the peculiarities of starting a 
widely collaborative project from scratch, and sourcing input from a very 
diverse team.

We do have a wiki page where people can find recurring meeting times, and the 
schedule for things once scheduled. Please recognize that schedules have been 
changing as new working groups are forming, which is requiring us to coordinate 
them by email.

If what you really want is to ignore everything but major project 
announcements, I suggest you filter out [Solum] on openstack-dev and look for 
announcement messages on the regular openstack mailing list when we begin to 
engage the user community. That way you can clue in from time to time. We can 
also post a project status section on the wiki so you can get a sense of it at 
a glance. That's on my to-do list.

Lot's of meaty email on this topic is a good thing, not a bad thing.

Adrian

On Dec 4, 2013, at 2:07 PM, Boris Pavlovic 
mailto:bpavlo...@mirantis.com>>
 wrote:

Guys,

I really appreciate that all discussion are real open, and you are doing a 
great job, discussing all arch stuff of the project. But for such things there 
are:
1) IRC chats
2) WIKI pages
3) ehterpads

E.g. in Rally we have 1 page:
https://etherpad.openstack.org/p/Rally_Main that contains all important 
information about:
1) RoadMaps
2) Links to active discussions
3) Current Active and Open Tasks
So everybody is able to discuss what he want with the rest of the project 
community, without tons of emails..

Could I ask you guys to send emails only about:
1) Releases
2) Major changes and news
3) Questions
4) Incubation stuff
5) Integration with other projects

And avoid discussing every piece of arch in mailing list. Because if  each 
project will start to discuss all arch stuff in mailing list, we will have 
billions of emails per minute in openstack-dev.


Sorry for this email, and thank you for understanding.

Best regards,
Boris Pavlovic
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [TripleO] capturing build details in images

This is a follow up to https://review.openstack.org/59621 to get
broader discussion..

So at the moment we capture a bunch of details in the image - what
parameters the image was built with and some environment variables.

Last week we were capturing everything, which there is broad consensus
was too much, but it seems to me that that is based on two things:
 - the security ramifications of unanticipated details being baked
into the image
 - many variables being irrelevant most of the time

I think those are both good points. But... the problem with diagnostic
information is you don't know that you need it until you don't have
it.

I'm particularly worried that things like bad http proxies, and third
party elements that need variables we don't know about will be
undiagnosable. Forcing everything through a DIB_FOO variable thunk
seems like just creating work for ourselves - I'd like to avoid that.

Further, some variables we should capture (like http_proxy) have
passwords embedded in them, so even whitelisting what variables to
capture doesn't solve the general problem.

So - what about us capturing this information outside the image: we
can create a uuid for the build, and write a file in the image with
that uuid, and outside the image we can write:
 - all variables (no security ramifications now as this file can be
kept by whomever built the image)
 - command line args
 - version information for the toolchain etc.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Clous

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

Re: [openstack-dev] When should things get added to Oslo.Incubator

2013-12-04 Thread Doug Hellmann

On Wednesday, December 4, 2013, Flavio Percoco wrote:

> On 04/12/13 01:13 +, Adrian Otto wrote:
>
>> Jay is right. What we have is probably close enough to what's in Nova to
>> qualify for oslo-incubator. The simplifications seem to me to have general
>> appeal so this code would be more attractive to other projects. One worry I
>> have is that there is still a good deal of magic behavior in this code, as
>> reviewers have made clear notes about in the code review. I'd like to try
>> it and see if there are further simplifications we could entertain to make
>> this code easier to debug and maintain. It would be great if such
>> iterations happened in a place where other projects could easily leverage
>> them.
>>
>> I will remind us that Solum is not currently an incubated project. Should
>> we address this concern now, or during an incubation phase?
>>
>
> This is not just a Solum issue but a general issue throughout
> OpenStack. The sooner we sort this out, the better.
>
>
>> Some approaches for us to consider:
>>
>> 1) Merge this code in Solum, open a bug against it to move it back into
>> oslo-incubation, open a stub project in oslo-incubation with a read me that
>> references the bug, and continue iterate on it in Solum until we are
>> reasonably happy with it. Then during an incubation phase, we can resolve
>> that bug by putting the code into oslo-incubation, and achieve the goal of
>> making more reusable work between projects.
>>
>> We could also address that bug at such time as any other ecosystem
>> project is looking for a similar solution, and finds the stub project in
>> oslo-incubation.
>>
>> 2) Just plunk all of this code into oslo-incubation as-is and do all
>> iterating there. That might cause a bit more copying around of code during
>> the simplification process, but would potentially achieve the reusability
>> goal sooner, possibly by a couple of months.
>>
>> 3) Use pypi. In all honesty we have enough new developers (about half the
>> engineers on this project) coming up to speed with how things work in the
>> OpenStack ecosystem that I'm reluctant to throw that into the mix too.
>>
>> What do you all prefer?
>>
>
>
> I'd personally prefer number 2. Besides the reasons already raised in
> this thread we should also add the fact that having it in
> oslo-incubator will make it easier for people from other projects to
> contribute, review and improve that code.


>
Exactly. This sounds like a feature we want to live in a common library,
but without a currently stable API. That's exactly what the incubator is
for.

Doug


>
>
>> On Dec 3, 2013, at 2:58 PM, Mark McLoughlin 
>> wrote:
>>
>>  On Tue, 2013-12-03 at 22:44 +, Joshua Harlow wrote:
>>>
 Sure sure, let me not make that assumption (can't speak for them), but
 even libraries on pypi have to deal with API instability.

>>>
>>> Yes, they do ... either by my maintaining stability, bumping their major
>>> version number to reflect an incompatible change ... or annoying the
>>> hell out of their users!
>>>
>>>  Just more of suggesting, might as well bite the bullet (if objects folks
 feel ok with this) and just learn to deal with the pypi method for
 dealing
 with API instability (versions, deprecation...). Since code copying
 around
 is just creating a miniature version of the same 'learning experience'
 except u lose the other parts (versioning, deprecation, ...) which comes
 along with pypi and libraries.

>>>
>>> Yes, if the maintainers of the API are prepared to deal with the demands
>>> of API stability, publishing the API as a standalone library would be
>>> far more preferable.
>>>
>>> Failing that, oslo-incubator offers a halfway house which sucks, but not
>>> as as much as the alternative - projects copying and pasting each
>>> other's code and evolving their copies independently.
>>>
>>
> Agreed. Also, as mentioned above, keeping the code in oslo will bring
> more eyeballs to the review, which helps a lot when designing APIs and
> seeking for stability.
>
> Projects throughout OpenStack look for re-usable code in Oslo first -
> or at least I think they should - and then elsewhere. Putting things
> in oslo-incubator has also a community impact, not just technical
> benefits. IMHO.
>
> FF
>
> --
> @flaper87
> Flavio Percoco
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solumn] Suggestion about usage of mailing lists

2013-12-04 Thread Russell Bryant

On 12/04/2013 05:07 PM, Boris Pavlovic wrote:
> Guys, 
> 
> I really appreciate that all discussion are real open, and you are doing
> a great job, discussing all arch stuff of the project. But for such
> things there are:
> 1) IRC chats
> 2) WIKI pages
> 3) ehterpads 
> 
> E.g. in Rally we have 1 page:
> https://etherpad.openstack.org/p/Rally_Main that contains all important
> information about:
> 1) RoadMaps
> 2) Links to active discussions
> 3) Current Active and Open Tasks
> So everybody is able to discuss what he want with the rest of the
> project community, without tons of emails..
> 
> Could I ask you guys to send emails only about:
> 1) Releases
> 2) Major changes and news
> 3) Questions 
> 4) Incubation stuff 
> 5) Integration with other projects
> 
> And avoid discussing every piece of arch in mailing list. Because if
>  each project will start to discuss all arch stuff in mailing list, we
> will have billions of emails per minute in openstack-dev.  
> 
> 
> Sorry for this email, and thank you for understanding. 

I have pretty much the exact opposite opinion of what you expressed here.

If you don't want to see it, please use filters or only subscribe to the
topics you care about.

Thanks,

-- 
Russell Bryant

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

[openstack-dev] [Solumn] Suggestion about usage of mailing lists

2013-12-04 Thread Boris Pavlovic

Guys,

I really appreciate that all discussion are real open, and you are doing a
great job, discussing all arch stuff of the project. But for such things
there are:
1) IRC chats
2) WIKI pages
3) ehterpads

E.g. in Rally we have 1 page:
https://etherpad.openstack.org/p/Rally_Main that contains all important
information about:
1) RoadMaps
2) Links to active discussions
3) Current Active and Open Tasks
So everybody is able to discuss what he want with the rest of the project
community, without tons of emails..

Could I ask you guys to send emails only about:
1) Releases
2) Major changes and news
3) Questions
4) Incubation stuff
5) Integration with other projects

And avoid discussing every piece of arch in mailing list. Because if  each
project will start to discuss all arch stuff in mailing list, we will have
billions of emails per minute in openstack-dev.


Sorry for this email, and thank you for understanding.

Best regards,
Boris Pavlovic
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Unicode strings in Python3

I opened a bug https://bugs.launchpad.net/solum/+bug/1257929 for that issue.

Ben, thank you for a quick fix proposal.

Thanks
Georgy


On Wed, Dec 4, 2013 at 1:41 PM, Ben Nemec  wrote:

>  I don't think so.  It looks like ./solum/api/controllers/v1/assembly.py
> is calling unicode().  It will need to be changed to six.text_type() for
> Python 3 compat.
>
> -Ben
>
> On 2013-12-04 15:41, Adrian Otto wrote:
>
> Am I interpreting this to mean that WSME is calling unicode()?
>
>  On Dec 4, 2013, at 1:32 PM, Georgy Okrokvertskhov <
> gokrokvertsk...@mirantis.com>
>  wrote:
>
>  Hi,
>
> I am working on unit tests for Solum as a side effect of new unit tests I
> found that we use unicode strings in the way which is not compatible with
> python3.
>
> Here is an exception form python3 gate:
> Server-side error: "global name 'unicode' is not defined". Detail:
> 2013-12-04 Traceback (most recent call last): File
> "/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/wsmeext/pecan.py"
>  result = f(self, *args, **kwargs)
>  File "./solum/api/controllers/v1/assembly.py", line 59, in get
> raise wsme.exc.ClientSideError(unicode(error))
> NameError: global name 'unicode' is not defined
>
> Here is a documentation for python3:
> http://docs.python.org/3.0/whatsnew/3.0.html
>
> Quick summary: you can't use unicode() function and u' ' strings in
> Pyhton3.
>
> Thanks
> Georgy
>  ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing 
> listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Unicode strings in Python3

2013-12-04 Thread Ben Nemec

 

I don't think so. It looks like ./solum/api/controllers/v1/assembly.py
is calling unicode(). It will need to be changed to six.text_type() for
Python 3 compat. 

-Ben 

On 2013-12-04 15:41, Adrian Otto wrote: 

> Am I interpreting this to mean that WSME is calling unicode()? 
> 
> On Dec 4, 2013, at 1:32 PM, Georgy Okrokvertskhov 
>  
> wrote: 
> 
>> Hi, 
>> 
>> I am working on unit tests for Solum as a side effect of new unit tests I 
>> found that we use unicode strings in the way which is not compatible with 
>> python3. 
>> 
>> Here is an exception form python3 gate: 
>> Server-side error: "global name 'unicode' is not defined". Detail: 
>> 2013-12-04 Traceback (most recent call last): File 
>> "/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/wsmeext/pecan.py"
>>  
>> result = f(self, *args, **kwargs) 
>> File "./solum/api/controllers/v1/assembly.py", line 59, in get 
>> raise wsme.exc.ClientSideError(unicode(error)) 
>> NameError: global name 'unicode' is not defined 
>> 
>> Here is a documentation for python3: 
>> http://docs.python.org/3.0/whatsnew/3.0.html [1] 
>> 
>> Quick summary: you can't use unicode() function and u' ' strings in Pyhton3. 
>> 
>> Thanks 
>> Georgy ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [2]

 

Links:
--
[1] http://docs.python.org/3.0/whatsnew/3.0.html
[2] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] Moving the QA meeting time

2013-12-04 Thread Miguel Lavalle

Matt,

2200 UTC Wed. or Thurs. is fine with me

Cheers


On Wed, Dec 4, 2013 at 3:04 PM, Matthew Treinish wrote:

> Hi everyone,
>
> I'm looking at changing our weekly QA meeting time to make it more globally
> attendable. Right now the current time of 17:00 UTC doesn't really work for
> people who live in Asia Pacific timezones. (which includes a third of the
> current core review team) There are 2 approaches that I can see taking
> here:
>
>  1. We could either move the meeting time later so that it makes it easier
> for
> people in the Asia Pacific region to attend.
>
>  2. Or we move to a alternating meeting time, where every other week the
> meeting
> time changes. So we keep the current slot and alternate with something
> more
> friendly for other regions.
>
> I think trying to stick to a single meeting time would be a better call
> just for
> simplicity. But it gets difficult to appease everyone that way which is
> where the
> appeal of the 2nd approach comes in.
>
> Looking at the available time slots here:
> https://wiki.openstack.org/wiki/Meetings
> there are plenty of open slots before 1500 UTC which would be early for
> people in
> the US and late for people in the Asia Pacific region. There are plenty of
> slots
> starting at 2300 UTC which is late for people in Europe.
>
> Would something like 2200 UTC on Wed. or Thurs work for everyone?
>
> What are people's opinions on this?
>
> -Matt Treinish
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Unicode strings in Python3

No,

This is Solum code:
https://github.com/stackforge/solum/blob/master/solum/api/controllers/v1/assembly.py#L59

Thanks
Georgy


On Wed, Dec 4, 2013 at 1:41 PM, Adrian Otto wrote:

>  Am I interpreting this to mean that WSME is calling unicode()?
>
>  On Dec 4, 2013, at 1:32 PM, Georgy Okrokvertskhov <
> gokrokvertsk...@mirantis.com>
>  wrote:
>
>  Hi,
>
>  I am working on unit tests for Solum as a side effect of new unit tests
> I found that we use unicode strings in the way which is not compatible with
> python3.
>
>  Here is an exception form python3 gate:
> Server-side error: "global name 'unicode' is not defined". Detail:
> 2013-12-04 Traceback (most recent call last): File
> "/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/wsmeext/pecan.py"
>  result = f(self, *args, **kwargs)
>  File "./solum/api/controllers/v1/assembly.py", line 59, in get
> raise wsme.exc.ClientSideError(unicode(error))
> NameError: global name 'unicode' is not defined
>
>  Here is a documentation for python3:
> http://docs.python.org/3.0/whatsnew/3.0.html
>
>  Quick summary: you can't use unicode() function and u' ' strings in
> Pyhton3.
>
>  Thanks
> Georgy
>  ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] DHCP Agent Reliability

2013-12-04 Thread Carl Baldwin

I have offered up https://review.openstack.org/#/c/60082/ as a
backport to Havana.  Interest was expressed in the blueprint for doing
this even before this thread.  If there is consensus for this as the
stop-gap then it is there for the merging.  However, I do not want to
discourage discussion of other stop-gap solutions like what Maru
proposed in the original post.

Carl

On Wed, Dec 4, 2013 at 9:12 AM, Ashok Kumaran  wrote:
>
>
>
> On Wed, Dec 4, 2013 at 8:30 PM, Maru Newby  wrote:
>>
>>
>> On Dec 4, 2013, at 8:55 AM, Carl Baldwin  wrote:
>>
>> > Stephen, all,
>> >
>> > I agree that there may be some opportunity to split things out a bit.
>> > However, I'm not sure what the best way will be.  I recall that Mark
>> > mentioned breaking out the processes that handle API requests and RPC
>> > from each other at the summit.  Anyway, it is something that has been
>> > discussed.
>> >
>> > I actually wanted to point out that the neutron server now has the
>> > ability to run a configurable number of sub-processes to handle a
>> > heavier load.  Introduced with this commit:
>> >
>> > https://review.openstack.org/#/c/37131/
>> >
>> > Set api_workers to something > 1 and restart the server.
>> >
>> > The server can also be run on more than one physical host in
>> > combination with multiple child processes.
>>
>> I completely misunderstood the import of the commit in question.  Being
>> able to run the wsgi server(s) out of process is a nice improvement, thank
>> you for making it happen.  Has there been any discussion around making the
>> default for api_workers > 0 (at least 1) to ensure that the default
>> configuration separates wsgi and rpc load?  This also seems like a great
>> candidate for backporting to havana and maybe even grizzly, although
>> api_workers should probably be defaulted to 0 in those cases.
>
>
> +1 for backporting the api_workers feature to havana as well as Grizzly :)
>>
>>
>> FYI, I re-ran the test that attempted to boot 75 micro VM's simultaneously
>> with api_workers = 2, with mixed results.  The increased wsgi throughput
>> resulted in almost half of the boot requests failing with 500 errors due to
>> QueuePool errors (https://bugs.launchpad.net/neutron/+bug/1160442) in
>> Neutron.  It also appears that maximizing the number of wsgi requests has
>> the side-effect of increasing the RPC load on the main process, and this
>> means that the problem of dhcp notifications being dropped is little
>> improved.  I intend to submit a fix that ensures that notifications are sent
>> regardless of agent status, in any case.
>>
>>
>> m.
>>
>> >
>> > Carl
>> >
>> > On Tue, Dec 3, 2013 at 9:47 AM, Stephen Gran
>> >  wrote:
>> >> On 03/12/13 16:08, Maru Newby wrote:
>> >>>
>> >>> I've been investigating a bug that is preventing VM's from receiving
>> >>> IP
>> >>> addresses when a Neutron service is under high load:
>> >>>
>> >>> https://bugs.launchpad.net/neutron/+bug/1192381
>> >>>
>> >>> High load causes the DHCP agent's status updates to be delayed,
>> >>> causing
>> >>> the Neutron service to assume that the agent is down.  This results in
>> >>> the
>> >>> Neutron service not sending notifications of port addition to the DHCP
>> >>> agent.  At present, the notifications are simply dropped.  A simple
>> >>> fix is
>> >>> to send notifications regardless of agent status.  Does anybody have
>> >>> any
>> >>> objections to this stop-gap approach?  I'm not clear on the
>> >>> implications of
>> >>> sending notifications to agents that are down, but I'm hoping for a
>> >>> simple
>> >>> fix that can be backported to both havana and grizzly (yes, this bug
>> >>> has
>> >>> been with us that long).
>> >>>
>> >>> Fixing this problem for real, though, will likely be more involved.
>> >>> The
>> >>> proposal to replace the current wsgi framework with Pecan may increase
>> >>> the
>> >>> Neutron service's scalability, but should we continue to use a 'fire
>> >>> and
>> >>> forget' approach to notification?  Being able to track the success or
>> >>> failure of a given action outside of the logs would seem pretty
>> >>> important,
>> >>> and allow for more effective coordination with Nova than is currently
>> >>> possible.
>> >>
>> >>
>> >> It strikes me that we ask an awful lot of a single neutron-server
>> >> instance -
>> >> it has to take state updates from all the agents, it has to do
>> >> scheduling,
>> >> it has to respond to API requests, and it has to communicate about
>> >> actual
>> >> changes with the agents.
>> >>
>> >> Maybe breaking some of these out the way nova has a scheduler and a
>> >> conductor and so on might be a good model (I know there are things
>> >> people
>> >> are unhappy about with nova-scheduler, but imagine how much worse it
>> >> would
>> >> be if it was built into the API).
>> >>
>> >> Doing all of those tasks, and doing it largely single threaded, is just
>> >> asking for overload.
>> >>
>> >> Cheers,
>> >> --
>> >> Stephen Gran
>> >> Senior Systems Integrator - theguar

Re: [openstack-dev] [Solum] Unicode strings in Python3

Am I interpreting this to mean that WSME is calling unicode()?

On Dec 4, 2013, at 1:32 PM, Georgy Okrokvertskhov 
mailto:gokrokvertsk...@mirantis.com>>
 wrote:

Hi,

I am working on unit tests for Solum as a side effect of new unit tests I found 
that we use unicode strings in the way which is not compatible with python3.

Here is an exception form python3 gate:
Server-side error: "global name 'unicode' is not defined". Detail: 2013-12-04 
Traceback (most recent call last): File 
"/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/wsmeext/pecan.py"
 result = f(self, *args, **kwargs)
 File "./solum/api/controllers/v1/assembly.py", line 59, in get
raise wsme.exc.ClientSideError(unicode(error))
NameError: global name 'unicode' is not defined

Here is a documentation for python3: 
http://docs.python.org/3.0/whatsnew/3.0.html

Quick summary: you can't use unicode() function and u' ' strings in Pyhton3.

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

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

Re: [openstack-dev] [Solum] MySQL Storage Engine

2013-12-04 Thread Clayton Coleman

- Original Message -
> With the comments that we've received, I would recommend that Clayton
> remove the option to select the MySQL storage engine from Oslo config and
> just "hardcode" InnoDB.  I believe it entails just removing a few lines of
> code.  It doesn't sound like anyone has a reason to use any other storage
> engine at this point.  Sound good?  I can update my review if that is the
> path that we want to take.
> 
> (You can see the area in the code at this link under my comment:
> https://review.openstack.org/#/c/57024/7/solum/objects/sqlalchemy/models.py
> )
> 

Will do.  I also need to force table_args() to be actually used.  When 
reviewing new models we just need to ensure table_args is set.

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

Re: [openstack-dev] [Neutron] DHCP Agent Reliability

2013-12-04 Thread Carl Baldwin

Sorry to have taken the discussion on a slight tangent.  I meant only
to offer the solution as a stop-gap.  I agree that the fundamental
problem should still be addressed.

On Tue, Dec 3, 2013 at 8:01 PM, Maru Newby  wrote:
>
> On Dec 4, 2013, at 1:47 AM, Stephen Gran  wrote:
>
>> On 03/12/13 16:08, Maru Newby wrote:
>>> I've been investigating a bug that is preventing VM's from receiving IP 
>>> addresses when a Neutron service is under high load:
>>>
>>> https://bugs.launchpad.net/neutron/+bug/1192381
>>>
>>> High load causes the DHCP agent's status updates to be delayed, causing the 
>>> Neutron service to assume that the agent is down.  This results in the 
>>> Neutron service not sending notifications of port addition to the DHCP 
>>> agent.  At present, the notifications are simply dropped.  A simple fix is 
>>> to send notifications regardless of agent status.  Does anybody have any 
>>> objections to this stop-gap approach?  I'm not clear on the implications of 
>>> sending notifications to agents that are down, but I'm hoping for a simple 
>>> fix that can be backported to both havana and grizzly (yes, this bug has 
>>> been with us that long).
>>>
>>> Fixing this problem for real, though, will likely be more involved.  The 
>>> proposal to replace the current wsgi framework with Pecan may increase the 
>>> Neutron service's scalability, but should we continue to use a 'fire and 
>>> forget' approach to notification?  Being able to track the success or 
>>> failure of a given action outside of the logs would seem pretty important, 
>>> and allow for more effective coordination with Nova than is currently 
>>> possible.
>>
>> It strikes me that we ask an awful lot of a single neutron-server instance - 
>> it has to take state updates from all the agents, it has to do scheduling, 
>> it has to respond to API requests, and it has to communicate about actual 
>> changes with the agents.
>>
>> Maybe breaking some of these out the way nova has a scheduler and a 
>> conductor and so on might be a good model (I know there are things people 
>> are unhappy about with nova-scheduler, but imagine how much worse it would 
>> be if it was built into the API).
>>
>> Doing all of those tasks, and doing it largely single threaded, is just 
>> asking for overload.
>
> I'm sorry if it wasn't clear in my original message, but my primary concern 
> lies with the reliability rather than the scalability of the Neutron service. 
>  Carl's addition of multiple workers is a good stop-gap to minimize the 
> impact of blocking IO calls in the current architecture, and we already have 
> consensus on the need to separate RPC and WSGI functions as part of the Pecan 
> rewrite.  I am worried, though, that we are not being sufficiently diligent 
> in how we manage state transitions through notifications.  Managing 
> transitions and their associate error states is needlessly complicated by the 
> current ad-hoc approach, and I'd appreciate input on the part of distributed 
> systems experts as to how we could do better.
>
>
> m.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Solum] Unicode strings in Python3

Hi,

I am working on unit tests for Solum as a side effect of new unit tests I
found that we use unicode strings in the way which is not compatible with
python3.

Here is an exception form python3 gate:
Server-side error: "global name 'unicode' is not defined". Detail:
2013-12-04 Traceback (most recent call last): File
"/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/wsmeext/pecan.py"
 result = f(self, *args, **kwargs)
 File "./solum/api/controllers/v1/assembly.py", line 59, in get
raise wsme.exc.ClientSideError(unicode(error))
NameError: global name 'unicode' is not defined

Here is a documentation for python3:
http://docs.python.org/3.0/whatsnew/3.0.html

Quick summary: you can't use unicode() function and u' ' strings in Pyhton3.

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

Re: [openstack-dev] [Solum] MySQL Storage Engine

2013-12-04 Thread Paul Montgomery

With the comments that we've received, I would recommend that Clayton
remove the option to select the MySQL storage engine from Oslo config and
just "hardcode" InnoDB.  I believe it entails just removing a few lines of
code.  It doesn't sound like anyone has a reason to use any other storage
engine at this point.  Sound good?  I can update my review if that is the
path that we want to take.

(You can see the area in the code at this link under my comment:
https://review.openstack.org/#/c/57024/7/solum/objects/sqlalchemy/models.py
)

On 12/4/13 3:06 PM, "Adrian Otto"  wrote:

>
>On Dec 4, 2013, at 12:32 PM, Monty Taylor  wrote:
>
>> On 12/04/2013 03:25 PM, Clint Byrum wrote:
>>> Excerpts from Paul Montgomery's message of 2013-12-04 12:04:06 -0800:
 TLDR: Should Solum log a warning if operators do not use the InnoDB
 storage engine with MySQL in Solum's control plane?

 Details:

 I was looking at: https://review.openstack.org/#/c/57024/
 Models.py to be specific.

 The default storage engine is InnoDB for MySQL which is good.  I took
a
 quick look at the storage engines and only InnoDB seems reasonable
for the
 Solum control plane (it is ACID complaint).  I assume that we'll all
be
 coding towards an ACID compliant database for performance (not having
to
 revalidate database writes and consistency and such) and ease of
 development.

 If all of that is true, should we log a warning to the operator that
they
 are using an untested and potentially problematic storage engine
(which in
 a worst case scenario can corrupt their data)?  Should we even enable
an
 operator to change the storage engine through configuration?  I think
 enabling that configuration is fine as long as we make sure that the
 operator knows that they are on their own with this unsupported
 configuration but I welcome thoughts from the group on this topic.

>>> 
>>> Just assume MyISAM _does not exist_. It is 2013 for crying out loud.
>>> 
>>> If somebody accidentally uses MyISAM, point at them and laugh, but then
>>> do help them pick up the pieces when it breaks.
>>> 
>>> In all seriousness, if you can force the engine to InnoDB, do that.
>>> Otherwise, just ignore this. We are all consenting adults here and if
>>> people cant' RTFM on MySQL, they shouldn't be storing data in it.
>> 
>> +1000
>
>So are you suggesting we have a bit of database code in Solum that would
>quickly check the Engine of each table upon startup. Something like:
>
>SHOT TABLE STATUS LIKE '%solum%';
>
>Šand iterate the Engine column looking for anything not InnoDB, and
>logging a warning error if other values are found?
>
>Or, are you suggesting that we just trust people not to be fools, and
>leave this subject alone completely?
>
>Thanks,
>
>Adrian
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Solum] MySQL Storage Engine

2013-12-04 Thread Paul Czarkowski

On 12/4/13 3:06 PM, "Adrian Otto"  wrote:

>
>On Dec 4, 2013, at 12:32 PM, Monty Taylor  wrote:
>
>> On 12/04/2013 03:25 PM, Clint Byrum wrote:
>>> Excerpts from Paul Montgomery's message of 2013-12-04 12:04:06 -0800:
 TLDR: Should Solum log a warning if operators do not use the InnoDB
 storage engine with MySQL in Solum's control plane?

 Details:

 I was looking at: https://review.openstack.org/#/c/57024/
 Models.py to be specific.

 The default storage engine is InnoDB for MySQL which is good.  I took
a
 quick look at the storage engines and only InnoDB seems reasonable
for the
 Solum control plane (it is ACID complaint).  I assume that we'll all
be
 coding towards an ACID compliant database for performance (not having
to
 revalidate database writes and consistency and such) and ease of
 development.

 If all of that is true, should we log a warning to the operator that
they
 are using an untested and potentially problematic storage engine
(which in
 a worst case scenario can corrupt their data)?  Should we even enable
an
 operator to change the storage engine through configuration?  I think
 enabling that configuration is fine as long as we make sure that the
 operator knows that they are on their own with this unsupported
 configuration but I welcome thoughts from the group on this topic.

>>> 
>>> Just assume MyISAM _does not exist_. It is 2013 for crying out loud.
>>> 
>>> If somebody accidentally uses MyISAM, point at them and laugh, but then
>>> do help them pick up the pieces when it breaks.
>>> 
>>> In all seriousness, if you can force the engine to InnoDB, do that.
>>> Otherwise, just ignore this. We are all consenting adults here and if
>>> people cant' RTFM on MySQL, they shouldn't be storing data in it.
>> 
>> +1000
>
>So are you suggesting we have a bit of database code in Solum that would
>quickly check the Engine of each table upon startup. Something like:
>
>SHOT TABLE STATUS LIKE '%solum%';
>
>Šand iterate the Engine column looking for anything not InnoDB, and
>logging a warning error if other values are found?
>
>Or, are you suggesting that we just trust people not to be fools, and
>leave this subject alone completely?
>
>Thanks,
>
>Adrian
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I think if we're abstracting the database via a library like SQLAlchemy
then we should assume the person at the other end knows how to configure a
database.  Otherwise do we have to do the same for every database
supported by that library.

If an Operator can manage to install and run and production openstack,
plus solum,  we should be fairly confident they're able to set up a good
mysql.

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

[openstack-dev] [qa] Moving the QA meeting time

2013-12-04 Thread Matthew Treinish

Hi everyone,

I'm looking at changing our weekly QA meeting time to make it more globally
attendable. Right now the current time of 17:00 UTC doesn't really work for
people who live in Asia Pacific timezones. (which includes a third of the
current core review team) There are 2 approaches that I can see taking here:

 1. We could either move the meeting time later so that it makes it easier for
people in the Asia Pacific region to attend.

 2. Or we move to a alternating meeting time, where every other week the meeting
time changes. So we keep the current slot and alternate with something more
friendly for other regions.

I think trying to stick to a single meeting time would be a better call just for
simplicity. But it gets difficult to appease everyone that way which is where 
the
appeal of the 2nd approach comes in.

Looking at the available time slots here: 
https://wiki.openstack.org/wiki/Meetings
there are plenty of open slots before 1500 UTC which would be early for people 
in
the US and late for people in the Asia Pacific region. There are plenty of slots
starting at 2300 UTC which is late for people in Europe.

Would something like 2200 UTC on Wed. or Thurs work for everyone?

What are people's opinions on this?

-Matt Treinish

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

Re: [openstack-dev] [Solum] MySQL Storage Engine


On Dec 4, 2013, at 12:32 PM, Monty Taylor  wrote:

> On 12/04/2013 03:25 PM, Clint Byrum wrote:
>> Excerpts from Paul Montgomery's message of 2013-12-04 12:04:06 -0800:
>>> TLDR: Should Solum log a warning if operators do not use the InnoDB
>>> storage engine with MySQL in Solum's control plane?
>>> 
>>> 
>>> Details:
>>> 
>>> I was looking at: https://review.openstack.org/#/c/57024/
>>> Models.py to be specific.
>>> 
>>> The default storage engine is InnoDB for MySQL which is good.  I took a
>>> quick look at the storage engines and only InnoDB seems reasonable for the
>>> Solum control plane (it is ACID complaint).  I assume that we'll all be
>>> coding towards an ACID compliant database for performance (not having to
>>> revalidate database writes and consistency and such) and ease of
>>> development.
>>> 
>>> If all of that is true, should we log a warning to the operator that they
>>> are using an untested and potentially problematic storage engine (which in
>>> a worst case scenario can corrupt their data)?  Should we even enable an
>>> operator to change the storage engine through configuration?  I think
>>> enabling that configuration is fine as long as we make sure that the
>>> operator knows that they are on their own with this unsupported
>>> configuration but I welcome thoughts from the group on this topic.
>>> 
>> 
>> Just assume MyISAM _does not exist_. It is 2013 for crying out loud.
>> 
>> If somebody accidentally uses MyISAM, point at them and laugh, but then
>> do help them pick up the pieces when it breaks.
>> 
>> In all seriousness, if you can force the engine to InnoDB, do that.
>> Otherwise, just ignore this. We are all consenting adults here and if
>> people cant' RTFM on MySQL, they shouldn't be storing data in it.
> 
> +1000

So are you suggesting we have a bit of database code in Solum that would 
quickly check the Engine of each table upon startup. Something like:

SHOT TABLE STATUS LIKE '%solum%';

…and iterate the Engine column looking for anything not InnoDB, and logging a 
warning error if other values are found?

Or, are you suggesting that we just trust people not to be fools, and leave 
this subject alone completely?

Thanks,

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

Re: [openstack-dev] [keystone][py3] Usage of httpretty

2013-12-04 Thread Dolph Mathews

Looks like there's some recent progress here:

  https://github.com/gabrielfalcao/HTTPretty/pull/124

On Wed, Nov 20, 2013 at 9:30 PM, Morgan Fainberg  wrote:

> I'd be more willing to toss in and help to maintain/fix appropriately
> on StackForge if that is needed.  Though I am very much hoping
> upstream can be used.
>
> Cheers,
> Morgan Fainberg
>
> On Wed, Nov 20, 2013 at 7:21 PM, Chuck Short 
> wrote:
> > Hi,
> >
> > So maybe if it gets to the point where it gets too be much of a porblem
> we
> > should just put it on stackforge.
> >
> > Regards
> > chuck
> >
> >
> > On Wed, Nov 20, 2013 at 9:08 PM, Jamie Lennox 
> > wrote:
> >>
> >> Chuck,
> >>
> >> So it is being used to handle stubbing returns from requests and httplib
> >> rather than having to having fake handlers in place in our testing code,
> >> or stubbing out the request library and continually having to update the
> >> arguments being passed to keep the mocks working. From my looking around
> >> it is the best library for this sort of job.
> >>
> >> When i evalutated it for keystoneclient upstream
> >> (https://github.com/gabrielfalcao/HTTPretty/ ) was quickly responsive
> >> and had CI tests that seemed to be checking python 3 support. I haven't
> >> seen as much happening recently as there are pull requests upstream for
> >> python 3 fixes that just don't seem to be moving anywhere. The CI for
> >> python 3 was also commented out at some point.
> >>
> >> It also turns out to be a PITA to package correctly. I attempted this
> >> for fedora, and i know there was someone attempting the same for gentoo.
> >> I have a pull request upstream that would at least get the dependencies
> >> under control.
> >>
> >> I do not want to go back to stubbing the request library, or having a
> >> fake client path that is only used in testing. However I have also
> >> noticed it is the cause of at least some of our python 3 problems.
> >>
> >> If there are other libraries out there that can do the same job we
> >> should consider them though i am holding some hope for upstream.
> >>
> >>
> >> Jamie
> >>
> >>
> >> On Wed, 2013-11-20 at 14:27 -0800, Morgan Fainberg wrote:
> >> > Chuck,
> >> >
> >> > The reason to use httpretty is that it handles everything at the
> >> > socket layer, this means if we change out urllib for requests or some
> >> > other transport to make HTTP requests to we don't need to refactor
> >> > every one of the mock/mox subouts to match the exact set of parameters
> >> > to be passed.  Httpretty makes managing this significantly easier
> >> > (hence was the reasoning to move towards it).  Though, I'm sure Jamie
> >> > Lennox can provide more insight into deeper specifics as he did most
> >> > of the work to convert it.
> >> >
> >> > At least the above is my understanding of the reasoning.
> >> >
> >> > --Morgan
> >> >
> >> > On Wed, Nov 20, 2013 at 2:08 PM, Dolph Mathews <
> dolph.math...@gmail.com>
> >> > wrote:
> >> > > I don't have a great answer -- do any projects depend on it other
> than
> >> > > python-keystoneclient? I'm happy to see it removed -- I see the
> >> > > immediate
> >> > > benefit but it's obviously not significant relative to python 3
> >> > > support.
> >> > >
> >> > > BTW, this exact issue is being tracked here-
> >> > > https://bugs.launchpad.net/python-keystoneclient/+bug/1249165
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On Wed, Nov 20, 2013 at 3:28 PM, Chuck Short
> >> > > 
> >> > > wrote:
> >> > >>
> >> > >> Hi,
> >> > >>
> >> > >> I was wondering for the reason behind the usage httpretty in
> >> > >> python-keystoneclient. It seems to me like a total overkill for a
> >> > >> test. It
> >> > >> also has some problems with python3 support that is currently
> >> > >> blocking
> >> > >> python3 porting as well.
> >> > >>
> >> > >> Regards
> >> > >> chuck
> >> > >>
> >> > >> ___
> >> > >> OpenStack-dev mailing list
> >> > >> OpenStack-dev@lists.openstack.org
> >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > >>
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > >
> >> > > -Dolph
> >> > >
> >> > > ___
> >> > > OpenStack-dev mailing list
> >> > > OpenStack-dev@lists.openstack.org
> >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > >
> >> >
> >> > ___
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev@lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __

Re: [openstack-dev] [keystone] Service scoped role definition

2013-12-04 Thread Adam Young


On 12/04/2013 12:40 PM, David Chadwick wrote:

Hi Adam

I understand your problem: having projects and services which have the
same name, then the lineage of a role containing this name is not
deterministically known without some other rule or syntax that can
differentiate between the two.

Since domains contain projects which contain services then isnt the
containment hierarchy already known and predetermined? If it is then:

4 name components mean it is a service specified role
3 name components mean it is a project specified role
2 name components mean it is a domain specified role
1 name component means it is globally named role (from the default domain)

a null string means the default domain or all projects in a domain. You
would never have null for a service name.

admin means the global admin role
/admin ditto
x/admin means the admin of the X domain
x/y/admin means the admin role for the y project in domain x
//x/admin means admin for service x from the default domain
etc.

will that work?

Very clean.  Yes. That will work.



regards

David


On 04/12/2013 15:04, Adam Young wrote:

On 12/04/2013 04:08 AM, David Chadwick wrote:

I am happy with this as far as it goes. I would like to see it being
made more general, where domains, services and projects can also own and
name roles

Domains should be OK, but services would confuse the matter.  You'd have
to end up with something like LDAP

role=  domain=default,service=glance

vs

role=  domain=default,project=glance

unless we have unambiguous implicit ordering, we'll need to make it
explicit, which is messy.

I'd rather do:

One segment: globally defined roles.  These could also be considered
roles defined in the default domain.
Two segments service defined roles in the default domain
Three Segments, service defined roles from non-default domain

To do domain scoped roles we could do something like:

domX//admin


But It seems confusing.

Perhaps a better approach for project roles is to have the rule that the
default domain can show up as an empty string.  Thus, project scoped
roles from the default domain  would be:

\glance\admin

and from a non default domain

domX\glance\admin








regards

David


On 04/12/2013 01:51, Adam Young wrote:

I've been thinking about your comment that "nested roles are confusing"


What if we backed off and said the following:


"Some role-definitions are owned by services.  If a Role definition is
owned by a service, in role assignment lists in tokens, those roles we
be prefixd by the service name.  / is a reserved cahracter and weill be
used as the divider between segments of the role definition "

That drops arbitrary nesting, and provides a reasonable namespace.  Then
a role def would look like:

"glance/admin"  for the admin role on the glance project.



In theory, we could add the domain to the namespace, but that seems
unwieldy.  If we did, a role def would then look like this


"default/glance/admin"  for the admin role on the glance project.

Is that clearer than the nested roles?



On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:

Hi Adam,

Based on our discussion over IRC, I have updated the below etherpad
with proposal for nested role definition

https://etherpad.openstack.org/p/service-scoped-role-definition

Please take a look @ "Proposal (Ayoung) - Nested role definitions", I
am sorry if I could not catch your idea.

Feel free to update the etherpad.

Regards,
Arvind


-Original Message-
From: Tiwari, Arvind
Sent: Tuesday, November 26, 2013 4:08 PM
To: David Chadwick; OpenStack Development Mailing List
Subject: Re: [openstack-dev] [keystone] Service scoped role definition

Hi David,

Thanks for your time and valuable comments. I have replied to your
comments and try to explain why I am advocating to this BP.

Let me know your thoughts, please feel free to update below etherpad
https://etherpad.openstack.org/p/service-scoped-role-definition

Thanks again,
Arvind

-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Monday, November 25, 2013 12:12 PM
To: Tiwari, Arvind; OpenStack Development Mailing List
Cc: Henry Nash; ayo...@redhat.com; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition

Hi Arvind

I have just added some comments to your blueprint page

regards

David


On 19/11/2013 00:01, Tiwari, Arvind wrote:

Hi,

   Based on our discussion in design summit , I have redone the
service_id
binding with roles BP
.


I have added a new BP (link below) along with detailed use case to
support this BP.

https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition



Below etherpad link has some proposals for Role REST representation
and
pros and cons analysis

   https://etherpad.openstack.org/p/service-scoped-role-definition

   Please take look and let me know your thoughts.

   It would be awesome

Re: [openstack-dev] [Keystoneclient] [Keystone] Last released version of keystoneclient does not work with python33

Dolph,

Is anyone already focusing on py33 compatibility for python-keystoneclient? Has
that effort been scoped? I'd like to judge whether it's reasonable to expect us
to patch it up to be compatible in the near term, or relax our expectations.
For Solum, we are trying to make all our code py33 compatible from the start,
so we take it seriously when the py33 gate fails. Please advise.

Thanks,

Adrian

On Dec 4, 2013, at 12:24 PM, Dolph Mathews
mailto:dolph.math...@gmail.com>>
wrote:

On Wed, Dec 4, 2013 at 1:26 PM, Georgy Okrokvertskhov
mailto:gokrokvertsk...@mirantis.com>> wrote:
Hi,

I have failed tests in gate-solum-python33 because kesytoneclient fails to
import xmlrpclib.
The exact error is:
"File
"/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/keystoneclient/openstack/common/jsonutils.py",
line 42, in
2013-11-28 18:27:12.655 | import xmlrpclib
2013-11-28 18:27:12.655 | ImportError: No module named 'xmlrpclib
"
This issue appeared because of xmlrpclib was renamed in python33.
Is there any plan to release a new version of keystoneclient with the fix for
that issue? As I see it is fixed in master.

If there is no new release for keystoneclient can you recommend any workaround
for this issue?

I'd be happy to make a release keystoneclient, but I don't believe that's the
only issue with python 3 at the moment (at least on the CLI?). For example:

https://bugs.launchpad.net/python-keystoneclient/+bug/1249165

In the current master, the above issue is only reproducible after syncing oslo
(otherwise it fails on yet another python 3 incompatibility).

Thanks
Georgy

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

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

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

[openstack-dev] recheck bug # for the django fail

2013-12-04 Thread Sean Dague

For people who's patches got killed earlier today because django 1.6 was
allowed into global requirements, please use the following bug for
recheck - https://bugs.launchpad.net/horizon/+bug/1257885

The horizon team is working towards 1.6 compatibility, but it's not
there yet. This will be a good tracking artifact for us getting there.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] MySQL Storage Engine

2013-12-04 Thread Monty Taylor



On 12/04/2013 03:25 PM, Clint Byrum wrote:
> Excerpts from Paul Montgomery's message of 2013-12-04 12:04:06 -0800:
>> TLDR: Should Solum log a warning if operators do not use the InnoDB
>> storage engine with MySQL in Solum's control plane?
>>
>>
>> Details:
>>
>> I was looking at: https://review.openstack.org/#/c/57024/
>> Models.py to be specific.
>>
>> The default storage engine is InnoDB for MySQL which is good.  I took a
>> quick look at the storage engines and only InnoDB seems reasonable for the
>> Solum control plane (it is ACID complaint).  I assume that we'll all be
>> coding towards an ACID compliant database for performance (not having to
>> revalidate database writes and consistency and such) and ease of
>> development.
>>
>> If all of that is true, should we log a warning to the operator that they
>> are using an untested and potentially problematic storage engine (which in
>> a worst case scenario can corrupt their data)?  Should we even enable an
>> operator to change the storage engine through configuration?  I think
>> enabling that configuration is fine as long as we make sure that the
>> operator knows that they are on their own with this unsupported
>> configuration but I welcome thoughts from the group on this topic.
>>
> 
> Just assume MyISAM _does not exist_. It is 2013 for crying out loud.
> 
> If somebody accidentally uses MyISAM, point at them and laugh, but then
> do help them pick up the pieces when it breaks.
> 
> In all seriousness, if you can force the engine to InnoDB, do that.
> Otherwise, just ignore this. We are all consenting adults here and if
> people cant' RTFM on MySQL, they shouldn't be storing data in it.

+1000

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

Re: [openstack-dev] [Keystoneclient] [Keystone] Last released version of keystoneclient does not work with python33

2013-12-04 Thread Dolph Mathews

On Wed, Dec 4, 2013 at 1:26 PM, Georgy Okrokvertskhov <
gokrokvertsk...@mirantis.com> wrote:

> Hi,
>
> I have failed tests in gate-solum-python33 because kesytoneclient fails to
> import xmlrpclib.
> The exact error is:
> "File
> "/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/
> keystoneclient/openstack/common/jsonutils.py", line 42, in 
> 2013-11-28 18:27:12.655 | import xmlrpclib
> 2013-11-28 18:27:12.655 | ImportError: No module named 'xmlrpclib
> "
> This issue appeared because of xmlrpclib was renamed in python33.
> Is there any plan to release a new version of keystoneclient with the fix
> for that issue? As I see it is fixed in master.
>
> If there is no new release for keystoneclient can you recommend any
> workaround for this issue?
>
>
I'd be happy to make a release keystoneclient, but I don't believe that's
the only issue with python 3 at the moment (at least on the CLI?). For
example:

  https://bugs.launchpad.net/python-keystoneclient/+bug/1249165

In the current master, the above issue is only reproducible after syncing
oslo (otherwise it fails on yet another python 3 incompatibility).


> Thanks
> Georgy
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

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

Re: [openstack-dev] [Solum] MySQL Storage Engine

Excerpts from Paul Montgomery's message of 2013-12-04 12:04:06 -0800:
> TLDR: Should Solum log a warning if operators do not use the InnoDB
> storage engine with MySQL in Solum's control plane?
> 
> 
> Details:
> 
> I was looking at: https://review.openstack.org/#/c/57024/
> Models.py to be specific.
> 
> The default storage engine is InnoDB for MySQL which is good.  I took a
> quick look at the storage engines and only InnoDB seems reasonable for the
> Solum control plane (it is ACID complaint).  I assume that we'll all be
> coding towards an ACID compliant database for performance (not having to
> revalidate database writes and consistency and such) and ease of
> development.
> 
> If all of that is true, should we log a warning to the operator that they
> are using an untested and potentially problematic storage engine (which in
> a worst case scenario can corrupt their data)?  Should we even enable an
> operator to change the storage engine through configuration?  I think
> enabling that configuration is fine as long as we make sure that the
> operator knows that they are on their own with this unsupported
> configuration but I welcome thoughts from the group on this topic.
> 

Just assume MyISAM _does not exist_. It is 2013 for crying out loud.

If somebody accidentally uses MyISAM, point at them and laugh, but then
do help them pick up the pieces when it breaks.

In all seriousness, if you can force the engine to InnoDB, do that.
Otherwise, just ignore this. We are all consenting adults here and if
people cant' RTFM on MySQL, they shouldn't be storing data in it.

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

Re: [openstack-dev] [Tripleo] Core reviewer update Dec

2013-12-04 Thread Keith Basil

On Dec 4, 2013, at 2:44 PM, Lyle, David wrote:

> On 5 December 2013 12:10, Robert Collins  wrote:
> 
> -snip-
> 
>> 
>> That said, perhaps we should review these projects.
>> 
>> Tuskar as an API to drive deployment and ops clearly belongs in
>> TripleO - though we need to keep pushing features out of it into more
>> generalised tools like Heat, Nova and Solum. TuskarUI though, as far
>> as I know all the other programs have their web UI in Horizon itself -
>> perhaps TuskarUI belongs in the Horizon program as a separate code
>> base for now, and merge them once Tuskar begins integration?
>> 
> 
> This sounds reasonable to me.  The code base for TuskarUI is building on 
> Horizon and we are planning on integrating TuskarUI into Horizon once TripleO 
> is part of the integrated release.  The review skills and focus for TuskarUI 
> is certainly more consistent with Horizon than the rest of the TripleO 
> program.

Focus is needed on the Horizon bits to ensure that we have something to build on
for the "operator" side of a deployment.  One possible concern here is that the 
Horizon
folk won't understand what's driving the UI need for Tuskar.

-k


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

Re: [openstack-dev] [Solum] MySQL Storage Engine

2013-12-04 Thread Clayton Coleman



- Original Message -
> TLDR: Should Solum log a warning if operators do not use the InnoDB
> storage engine with MySQL in Solum's control plane?
> 
> 
> Details:
> 
> I was looking at: https://review.openstack.org/#/c/57024/
> Models.py to be specific.
> 
> The default storage engine is InnoDB for MySQL which is good.  I took a
> quick look at the storage engines and only InnoDB seems reasonable for the
> Solum control plane (it is ACID complaint).  I assume that we'll all be
> coding towards an ACID compliant database for performance (not having to
> revalidate database writes and consistency and such) and ease of
> development.
> 
> If all of that is true, should we log a warning to the operator that they
> are using an untested and potentially problematic storage engine (which in
> a worst case scenario can corrupt their data)?  Should we even enable an
> operator to change the storage engine through configuration?  I think
> enabling that configuration is fine as long as we make sure that the
> operator knows that they are on their own with this unsupported
> configuration but I welcome thoughts from the group on this topic.
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

I'd be a +1 to InnoDB only until such a time as someone demonstrates a need.

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

Re: [openstack-dev] [Neutron][LBaaS] Vendor feedback needed

2013-12-04 Thread Ivar Lazzaro

Hi Eugene,

Right now (before the model change discussed during the summit) our 
implementation, in regards to your question, can be summarized as follows:


-  Whenever a Pool is created, a port on the specific subnet/network is 
created and associated to it;

-  Whenever a VIP is associated to the Pool, our Service Manager places 
the interfaces of a newly created appliance based on the information got from 
the VIP's and Pool's port (i.e. network_type and segmentation_id);

-  In order to wire the VIP with an external network, a Floating IP can 
be associated to its port (or the VIP created ON the external network itself);

-  VIP and Pool on the same network/subnet is supported as well.


The new model (LoadBalancer object) would change how and when the Load Balancer 
appliance is created, but the way the interfaces are placed into the networks 
remains the same.
I hope this answers your question.

Regards,
Ivar.

From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Wednesday, December 04, 2013 7:11 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Vendor feedback needed

Hi Eugene,

We currently support out-of-the-box VIP and Nodes on the same network.
The VIP can be associated with a floating IP if need to access from the 
"external" network.

We are considering other options but will address as we get to this.

Regards,
-Sam.


From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Wednesday, December 04, 2013 1:14 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron][LBaaS] Vendor feedback needed

Hi load balancing vendors!

I have specific question: how drivers for your solutions 
(devices/vms/processes) are going to wire a VIP with external and tenant 
networks?
As we're working on creating a suite for third-party testing, we would like to 
make sure that scenarios that we create fits usage pattern of all providers, if 
it is possible at all.
If it is not possible, we need to think of more comprehensive LBaaS API and 
tests.

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

[openstack-dev] [Solum] MySQL Storage Engine

2013-12-04 Thread Paul Montgomery

TLDR: Should Solum log a warning if operators do not use the InnoDB
storage engine with MySQL in Solum's control plane?


Details:

I was looking at: https://review.openstack.org/#/c/57024/
Models.py to be specific.

The default storage engine is InnoDB for MySQL which is good.  I took a
quick look at the storage engines and only InnoDB seems reasonable for the
Solum control plane (it is ACID complaint).  I assume that we'll all be
coding towards an ACID compliant database for performance (not having to
revalidate database writes and consistency and such) and ease of
development.

If all of that is true, should we log a warning to the operator that they
are using an untested and potentially problematic storage engine (which in
a worst case scenario can corrupt their data)?  Should we even enable an
operator to change the storage engine through configuration?  I think
enabling that configuration is fine as long as we make sure that the
operator knows that they are on their own with this unsupported
configuration but I welcome thoughts from the group on this topic.


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

Re: [openstack-dev] creating a default for oslo config variables within a project?

Excerpts from Sean Dague's message of 2013-12-04 10:51:16 -0800:
> On 12/04/2013 11:56 AM, Ben Nemec wrote:
> > On 2013-12-04 06:07, Sean Dague wrote:
> >> On 12/03/2013 11:21 PM, Clint Byrum wrote:
> >>> Excerpts from Sean Dague's message of 2013-12-03 16:05:47 -0800:
>  On 12/03/2013 06:13 PM, Ben Nemec wrote:
> > On 2013-12-03 17:09, Sean Dague wrote:
> >> On 12/03/2013 05:50 PM, Mark McLoughlin wrote:
> >>> On Tue, 2013-12-03 at 16:23 -0600, Ben Nemec wrote:
>  On 2013-12-03 15:56, Sean Dague wrote:
> > This cinder patch - https://review.openstack.org/#/c/48935/
> >
> > Is blocked on failing upgrade because the updated oslo
> > lockutils won't
> > function until there is a specific configuration variable added
> > to the
> > cinder.conf.
> >
> > That work around is proposed here -
> > https://review.openstack.org/#/c/52070/3
> >
> > However I think this is exactly the kind of forward breaks that we
> > want
> > to prevent with grenade, as cinder failing to function after a
> > rolling
> > upgrade because a config item wasn't added is exactly the kind
> > of pain
> > we are trying to prevent happening to ops.
> >
> > So the question is, how is this done correctly so that a default
> > can be
> > set in the cinder code for this value, and it not require a config
> > change to work?
> >>>
> >>> You're absolutely correct, in principle - if the default value for
> >>> lock_path worked for users before, we should absolutely continue to
> >>> support it.
> >>>
>  I don't know that I have a good answer on how to handle this,
>  but for
>  context this change is the result of a nasty bug in lockutils that
>  meant
>  external locks were doing nothing if lock_path wasn't set. 
>  Basically
>  it's something we should never have allowed in the first place.
> 
>  As far as setting this in code, it's important that all of the
>  processes
>  for a service are using the same value to avoid the same bad
>  situation
>  we were in before.  For tests, we have a lockutils wrapper
>  (https://github.com/openstack/oslo-incubator/blob/master/openstack/common/lockutils.py#L282)
> 
>  that sets an environment variable to address this, but that only
>  works if all of the processes are going to be spawned from within
>  the same wrapper, and I'm not sure how secure that is for
>  production
>  deployments since it puts all of the lock files in a temporary
>  directory.
> >>>
> >>> Right, I don't think the previous default really "worked" - if
> >>> you used
> >>> the default, then external locking was broken.
> >>>
> >>> I suspect most distros do set a default - I see RDO has this in its
> >>> default nova.conf:
> >>>
> >>>   lock_path = /var/lib/nova/tmp
> >>>
> >>> So, yes - this is all terrible.
> >>>
> >>> IMHO, rather than raise an exception we should log a big fat warning
> >>> about relying on the default and perhaps just treat the lock as an
> >>> in-process lock in that case ... since that's essentially what it
> >>> was
> >>> before, right?
> >>
> >> So a default of lock_path = /tmp will work (FHS says that path has
> >> to be
> >> there), even if not optimal. Could we make it a default value like
> >> that
> >> instead of the current default which is null (and hence the problem).
> >
> > IIRC, my initial fix was something similar to that, but it got shot
> > down
> > because putting the lock files in a known world writeable location
> > was a
> > security issue.
> >
> > Although maybe if we put them in a subdirectory of /tmp and ensured
> > that
> > the permissions were such that only the user running the service could
> > use that directory, it might be acceptable?  We could still log a
> > warning if we wanted.
> >
> > This seems like it would have implications for people running services
> > on Windows too, but we can probably find a way to make that work if we
> > decide on a solution.
> 
>  How is that a security issue? Are the lock files being written with
>  some
>  sensitive data in them and have g or o permissions on? The sticky bit
>  (+t) on /tmp will prevent other users from deleting the file.
> 
> >>>
> >>> Right, but it won't prevent users from creating a symlink with the same
> >>> name.
> >>>
> >>> ln -s /var/lib/nova/instances/x/image.raw /tmp/well.known.location
> >>>
> >>> Now when you do
> >>>
> >>> with open('/tmp/well.known.location', 'w') as lockfile:
> >>>   lockfile.write('Stuff')
> >>>
> >>> Nova has just truncated the i

Re: [openstack-dev] [keystone] Service scoped role definition

Thanks David,

Appended line # 119 with my reply. "endpoint" sounds perfect to me.

In a nutshell we are agreeing on following new data model for role-def. 

{
  "role": {
"id": "76e72a",
"name": "admin", (you can give whatever name you like)
"scope": {
  "id": "---id--", (ID should be  1 to 1 mapped with resource in type and 
must be immutable value)
  "type": "service | file | domain etc.", (Type can be any type of resource 
which explains the scoping context)
  "endpoint":"-- endpoint--"  (An optional field to indicate the interface 
of the resource (endpoint for service, path for File,) for which the 
role-def is created.)
}
  }
}

If other community members are cool with this, I will start drafting the API 
specs?


Regards,
Arvind


-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] 
Sent: Wednesday, December 04, 2013 11:42 AM
To: Tiwari, Arvind; Adam Young
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] Service scoped role definition



On 04/12/2013 17:28, Tiwari, Arvind wrote:
> Hi David,
> 
> Thanks for your valuable comments.
> 
> I have updated
> https://etherpad.openstack.org/p/service-scoped-role-definition line
> #118 explaining the rationale behind the field.

#119 for my reply

> 
> I wd also appreciate your thoughts on
> https://etherpad.openstack.org/p/1Uiwcbfpxq too,

I have added a comment to the original bug report -
https://bugs.launchpad.net/keystone/+bug/968696

I think you should be going for simplifying Keystone's RBAC model rather
than making it more complex. In essence this would mean that assigning
permissions to roles and users to roles are separate and independent
processes and that roles on creation do not have to have any baggage or
restrictions tied to them. Here are my suggestions:

1. Allow different entities to create roles, and use hierarchical role
naming to maintain global uniqueness and to show which entity created
(owns) the role definition. Creating a role does not imply anything
about a role's subsequent permissions unless a scope field is included
in the definition.

2. When a role is created allow the creator to optionally add a scope
field which will limit the permissions that can be assigned to the role
to the prescribed scope.

3. Permissions will be assigned to roles in policy files by resource
owners. The can assign any permissions to their resources to the role
that they want to, except that they cannot override the scope field (ie.
grant permissions to resources which are out of the role's scope).

4. Remove any linkage of roles to tenants/projects on creation. This is
unnecessary baggage and only complicates the model for no good
functional reason.

regards

David


 which is support
> https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens
> BP.
> 
> 
> Thanks, Arvind
> 
> -Original Message- From: David Chadwick
> [mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday, December 04, 2013
> 2:16 AM To: Tiwari, Arvind; OpenStack Development Mailing List (not
> for usage questions); Adam Young Subject: Re: [openstack-dev]
> [keystone] Service scoped role definition
> 
> I have added comments 111 to 122
> 
> david
> 
> On 03/12/2013 23:58, Tiwari, Arvind wrote:
>> Hi David,
>> 
>> I have added my comments underneath line # 97 till line #110, it is
>> mostly aligned with your proposal with some modification.
>> 
>> https://etherpad.openstack.org/p/service-scoped-role-definition
>> 
>> 
>> Thanks for your time, Arvind
>> 
>> 
>> 
>> -Original Message- From: Tiwari, Arvind Sent: Monday,
>> December 02, 2013 4:22 PM To: Adam Young; OpenStack Development
>> Mailing List (not for usage questions); David Chadwick Subject: Re:
>> [openstack-dev] [keystone] Service scoped role definition
>> 
>> Hi Adam and David,
>> 
>> Thank you so much for all the great comments, seems we are making
>> good progress.
>> 
>> I have replied to your comments and also added some to support my
>> proposal
>> 
>> https://etherpad.openstack.org/p/service-scoped-role-definition
>> 
>> David, I like your suggestion for role-def scoping which can fit in
>> my Plan B and I think Adam is cool with plan B.
>> 
>> Please let me know if David's proposal for role-def scoping is cool
>> for everybody?
>> 
>> 
>> Thanks, Arvind
>> 
>> -Original Message- From: Adam Young
>> [mailto:ayo...@redhat.com] Sent: Wednesday, November 27, 2013 8:44
>> AM To: Tiwari, Arvind; OpenStack Development Mailing List (not for
>> usage questions) Cc: Henry Nash; dolph.math...@gmail.com; David
>> Chadwick Subject: Re: [openstack-dev] [keystone] Service scoped
>> role definition
>> 
>> 
>> 
>> On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:
>>> Hi Adam,
>>> 
>>> Based on our discussion over IRC, I have updated the below
>>> etherpad with proposal for nested role definition
>> 
>> Updated.  I made my changes Green.  It isn't easy being green.
>> 
>>> 
>>> https://etherpad.o

Re: [openstack-dev] [Tripleo] Core reviewer update Dec

2013-12-04 Thread Lyle, David

On 5 December 2013 12:10, Robert Collins  wrote:

-snip-

> 
> That said, perhaps we should review these projects.
> 
> Tuskar as an API to drive deployment and ops clearly belongs in
> TripleO - though we need to keep pushing features out of it into more
> generalised tools like Heat, Nova and Solum. TuskarUI though, as far
> as I know all the other programs have their web UI in Horizon itself -
> perhaps TuskarUI belongs in the Horizon program as a separate code
> base for now, and merge them once Tuskar begins integration?
>

This sounds reasonable to me.  The code base for TuskarUI is building on 
Horizon and we are planning on integrating TuskarUI into Horizon once TripleO 
is part of the integrated release.  The review skills and focus for TuskarUI is 
certainly more consistent with Horizon than the rest of the TripleO program.
 
> -Rob
> 
> 
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-David

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

[openstack-dev] [Keystoneclient] [Keystone] Last released version of keystoneclient does not work with python33

Hi,

I have failed tests in gate-solum-python33 because kesytoneclient fails to
import xmlrpclib.
The exact error is:
"File
"/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/
keystoneclient/openstack/common/jsonutils.py", line 42, in 
2013-11-28 18:27:12.655 | import xmlrpclib
2013-11-28 18:27:12.655 | ImportError: No module named 'xmlrpclib
"
This issue appeared because of xmlrpclib was renamed in python33.
Is there any plan to release a new version of keystoneclient with the fix
for that issue? As I see it is fixed in master.

If there is no new release for keystoneclient can you recommend any
workaround for this issue?

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

Re: [openstack-dev] creating a default for oslo config variables within a project?

2013-12-04 Thread Ben Nemec

On 2013-12-04 12:51, Sean Dague wrote:

On 12/04/2013 11:56 AM, Ben Nemec wrote:

On 2013-12-04 06:07, Sean Dague wrote:

On 12/03/2013 11:21 PM, Clint Byrum wrote:

Excerpts from Sean Dague's message of 2013-12-03 16:05:47 -0800:

On 12/03/2013 06:13 PM, Ben Nemec wrote:

On 2013-12-03 17:09, Sean Dague wrote:

On 12/03/2013 05:50 PM, Mark McLoughlin wrote:

On Tue, 2013-12-03 at 16:23 -0600, Ben Nemec wrote:

On 2013-12-03 15:56, Sean Dague wrote:

This cinder patch - https://review.openstack.org/#/c/48935/

Is blocked on failing upgrade because the updated oslo
lockutils won't
function until there is a specific configuration variable
added

to the
cinder.conf.

That work around is proposed here -
https://review.openstack.org/#/c/52070/3

However I think this is exactly the kind of forward breaks
that we

want
to prevent with grenade, as cinder failing to function after a
rolling
upgrade because a config item wasn't added is exactly the kind
of pain
we are trying to prevent happening to ops.

So the question is, how is this done correctly so that a
default

can be
set in the cinder code for this value, and it not require a
config

change to work?

You're absolutely correct, in principle - if the default value
for
lock_path worked for users before, we should absolutely continue
to

support it.

I don't know that I have a good answer on how to handle this,
but for
context this change is the result of a nasty bug in lockutils
that

meant
external locks were doing nothing if lock_path wasn't set.
Basically
it's something we should never have allowed in the first place.

As far as setting this in code, it's important that all of the
processes
for a service are using the same value to avoid the same bad
situation
we were in before. For tests, we have a lockutils wrapper
(https://github.com/openstack/oslo-incubator/blob/master/openstack/common/lockutils.py#L282)

that sets an environment variable to address this, but that
only
works if all of the processes are going to be spawned from
within

the same wrapper, and I'm not sure how secure that is for
production
deployments since it puts all of the lock files in a temporary
directory.

Right, I don't think the previous default really "worked" - if
you used
the default, then external locking was broken.

I suspect most distros do set a default - I see RDO has this in
its

default nova.conf:

lock_path = /var/lib/nova/tmp

So, yes - this is all terrible.

IMHO, rather than raise an exception we should log a big fat
warning
about relying on the default and perhaps just treat the lock as
an
in-process lock in that case ... since that's essentially what
it

was
before, right?

So a default of lock_path = /tmp will work (FHS says that path
has

to be
there), even if not optimal. Could we make it a default value
like

that
instead of the current default which is null (and hence the
problem).

IIRC, my initial fix was something similar to that, but it got
shot

down
because putting the lock files in a known world writeable location
was a
security issue.

Although maybe if we put them in a subdirectory of /tmp and
ensured

that
the permissions were such that only the user running the service
could

use that directory, it might be acceptable? We could still log a
warning if we wanted.

This seems like it would have implications for people running
services
on Windows too, but we can probably find a way to make that work
if we

decide on a solution.

How is that a security issue? Are the lock files being written with
some
sensitive data in them and have g or o permissions on? The sticky
bit

(+t) on /tmp will prevent other users from deleting the file.

Right, but it won't prevent users from creating a symlink with the
same

name.

ln -s /var/lib/nova/instances/x/image.raw
/tmp/well.known.location

Now when you do

with open('/tmp/well.known.location', 'w') as lockfile:
lockfile.write('Stuff')

Nova has just truncated the image file and written 'Stuff' to it.

So that's the generic case (and the way people often write this). But
the oslo lockutils code doesn't work that way. While it does open the
file for write, it does not actually write, it's using fcntl to hold
locks. That's taking a data structure on the fd in kernel memory
(IIRC),

so it correctly gives it up if the process crashes.

I'm not saying there isn't some other possible security vulnerability
here as well, but it's not jumping out at me. So I'd love to
understand

that, because if we can close that exposure we can provide a working
default, plus a strong recommendation for how to do that *right*. I'd
be
totally happy with printing WARNING level at startup if lock_path =
/tmp

that this should be adjusted.

Full disclosure: I don't claim to be a security expert, so take my
thoughts on this with a grain of salt.

tldr: I still don't see a way to do this without breaking _something_.

Unfortunately, while we don't actually write to the file, just opening
it for w

Re: [openstack-dev] [Tripleo] Core reviewer update Dec

On 5 December 2013 06:55, James Slagle  wrote:
> On Wed, Dec 4, 2013 at 2:12 AM, Robert Collins
>> Jan, Jordan, Martyn, Jiri and Jaromir are still actively contributing
>> to TripleO and OpenStack, but I don't think they are tracking /
>> engaging in the code review discussions enough to stay in -core: I'd
>> be delighted if they want to rejoin as core - as we discussed last
>> time, after a shorter than usual ramp up period if they get stuck in.
>
> What's the shorter than usual ramp up period?

You know, we haven't actually put numbers on it. But I'd be
comfortable with a few weeks of sustained involvement.

> In general, I agree with your points about removing folks from core.
>
> We do have a situation though where some folks weren't reviewing as
> frequently when the Tuskar UI/API development slowed a bit post-merge.
>  Since that is getting ready to pick back up, my concern with removing
> this group of folks, is that it leaves less people on core who are
> deeply familiar with that code base.  Maybe that's ok, especially if
> the fast track process to get them back on core is reasonable.

Well, I don't think we want a situation where when a single org
decides to tackle something else for a bit, that noone can comfortably
fix bugs in e.g. Tuskar / or worse the whole thing stalls - thats why
I've been so keen to get /everyone/ in Tripleo-core familiar with the
entire collection of codebases we're maintaining.

So I think after 3 months that other cores should be reasonably familiar too ;).

That said, perhaps we should review these projects.

Tuskar as an API to drive deployment and ops clearly belongs in
TripleO - though we need to keep pushing features out of it into more
generalised tools like Heat, Nova and Solum. TuskarUI though, as far
as I know all the other programs have their web UI in Horizon itself -
perhaps TuskarUI belongs in the Horizon program as a separate code
base for now, and merge them once Tuskar begins integration?

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [keystone] Service scoped role definition

Hi David,

The biggest problems in my opinion are, 

1. We are overloading and adding extra complexities on role name to maintain 
the generalization for role-def data model. 
2. Name spacing the role name is not going to resolve all the issues listed in 
BP.
3. All the namespaces are derived from mutable string  (domain name, project 
name, service name etc...) which makes the role name fragile.

I think it is time to break generic role-def data model to accommodate more 
specialized use cases.


Thanks,
Arvind

-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] 
Sent: Wednesday, December 04, 2013 10:41 AM
To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing List (not for 
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com
Subject: Re: [openstack-dev] [keystone] Service scoped role definition

Hi Adam

I understand your problem: having projects and services which have the
same name, then the lineage of a role containing this name is not
deterministically known without some other rule or syntax that can
differentiate between the two.

Since domains contain projects which contain services then isnt the
containment hierarchy already known and predetermined? If it is then:

4 name components mean it is a service specified role
3 name components mean it is a project specified role
2 name components mean it is a domain specified role
1 name component means it is globally named role (from the default domain)

a null string means the default domain or all projects in a domain. You
would never have null for a service name.

admin means the global admin role
/admin ditto
x/admin means the admin of the X domain
x/y/admin means the admin role for the y project in domain x
//x/admin means admin for service x from the default domain
etc.

will that work?

regards

David


On 04/12/2013 15:04, Adam Young wrote:
> On 12/04/2013 04:08 AM, David Chadwick wrote:
>> I am happy with this as far as it goes. I would like to see it being
>> made more general, where domains, services and projects can also own and
>> name roles
> Domains should be OK, but services would confuse the matter.  You'd have
> to end up with something like LDAP
> 
> role=  domain=default,service=glance
> 
> vs
> 
> role=  domain=default,project=glance
> 
> unless we have unambiguous implicit ordering, we'll need to make it
> explicit, which is messy.
> 
> I'd rather do:
> 
> One segment: globally defined roles.  These could also be considered
> roles defined in the default domain.
> Two segments service defined roles in the default domain
> Three Segments, service defined roles from non-default domain
> 
> To do domain scoped roles we could do something like:
> 
> domX//admin
> 
> 
> But It seems confusing.
> 
> Perhaps a better approach for project roles is to have the rule that the
> default domain can show up as an empty string.  Thus, project scoped
> roles from the default domain  would be:
> 
> \glance\admin
> 
> and from a non default domain
> 
> domX\glance\admin
> 
> 
> 
> 
> 
> 
> 
>>
>> regards
>>
>> David
>>
>>
>> On 04/12/2013 01:51, Adam Young wrote:
>>> I've been thinking about your comment that "nested roles are confusing"
>>>
>>>
>>> What if we backed off and said the following:
>>>
>>>
>>> "Some role-definitions are owned by services.  If a Role definition is
>>> owned by a service, in role assignment lists in tokens, those roles we
>>> be prefixd by the service name.  / is a reserved cahracter and weill be
>>> used as the divider between segments of the role definition "
>>>
>>> That drops arbitrary nesting, and provides a reasonable namespace.  Then
>>> a role def would look like:
>>>
>>> "glance/admin"  for the admin role on the glance project.
>>>
>>>
>>>
>>> In theory, we could add the domain to the namespace, but that seems
>>> unwieldy.  If we did, a role def would then look like this
>>>
>>>
>>> "default/glance/admin"  for the admin role on the glance project.
>>>
>>> Is that clearer than the nested roles?
>>>
>>>
>>>
>>> On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:
 Hi Adam,

 Based on our discussion over IRC, I have updated the below etherpad
 with proposal for nested role definition

 https://etherpad.openstack.org/p/service-scoped-role-definition

 Please take a look @ "Proposal (Ayoung) - Nested role definitions", I
 am sorry if I could not catch your idea.

 Feel free to update the etherpad.

 Regards,
 Arvind


 -Original Message-
 From: Tiwari, Arvind
 Sent: Tuesday, November 26, 2013 4:08 PM
 To: David Chadwick; OpenStack Development Mailing List
 Subject: Re: [openstack-dev] [keystone] Service scoped role definition

 Hi David,

 Thanks for your time and valuable comments. I have replied to your
 comments and try to explain why I am advocating to this BP.

 Let me know your thoughts, please feel free to update below etherpad
 https://etherpad.openstack

Re: [openstack-dev] {TripleO] UI Wireframes - close to implementation start

2013-12-04 Thread Liz Blanchard


On Dec 3, 2013, at 9:30 AM, Tzu-Mainn Chen  wrote:

> Hey folks,
> 
> I opened 2 issues on UX discussion forum with TripleO UI topics:
> 
> Resource Management:
> http://ask-openstackux.rhcloud.com/question/95/tripleo-ui-resource-management/
> - this section was already reviewed before, there is not much surprises, just 
> smaller updates
> - we are about to implement this area
> 
> http://ask-openstackux.rhcloud.com/question/96/tripleo-ui-deployment-management/
> - these are completely new views and they need a lot of attention so that in 
> time we don't change direction drastically
> - any feedback here is welcome
> 
> We need to get into implementation ASAP. It doesn't mean that we have 
> everything perfect from the very beginning, but that we have direction and we 
> move forward by enhancements.
> 
> Therefor implementation of above mentioned areas should start very soon.
> 
> If all possible, I will try to record walkthrough with further explanations. 
> If you have any questions or feedback, please follow the threads on 
> ask-openstackux.
> 
> Thanks
> -- Jarda
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> These wireframes look really good!  However, would it be possible to get the 
> list of requirements driving them?  For example, something on the level of:
> 
> 1) removal of resource classes and racks
> 2) what happens behind the scenes when deployment occurs
> 3) the purpose of "compute class"
> 4) etc
> 
I completely agree with Mainn on this. It would be also be great to see use 
cases built from requirements that we can consider while reviewing wireframes. 
These would allow us to think in terms of how the user would come to the UI and 
perform the actions needed to complete their task.

Here are some additional thoughts/questions regarding the current designs:

Deployment Management

Slide 3
- I like that we are making it clear to the user which types of nodes they 
could add to their deployment and how many of each node will be added, but why 
aren't we continuing to use this method as the user may want to scale out their 
deployment? It seems very inconsistent to use this design just for this one use 
case.
- The section is labeled "Resource distribution" but the user is has a number 
of "unallocated nodes". I think we should try to make these terms consistent. 
Either "Resource distribution" and "Undistributed resources" or "Node 
Allocation" and "Unallocated Nodes". This would limit the terminology that a 
user would need to try to learn.
- Would the "More details" link bring up a description of the type of node? If 
so, should this just be a ? next to the title that the user could roll over? 
Okay. After reviewing the youtube video I understand the point of this link 
now. I think this should be labeled accordingly. The controller link should 
probably read "Controller" to match up with the navigation section. It might be 
better to label these both "Controller Nodes".
- Somehow, we should make it easier for the user to walk through these details 
steps. It's great that this initial screen allows them to just assign nodes and 
then quickly deploy, but when they want to dive into the details I think we 
need to make it much clearer how to do this without the user needing to 
remember that they have to select each node type section and click "Deploy". 
Maybe a wizard would work better?
- Would the user be able to click on the text and enter a number of nodes into 
the text box rather than have to click the up or down arrow?

Slide 5
- It might be a helpful hint to the user to maybe list the number of nodes that 
need action in each section next to the navigation item. I'm just trying to 
think of better ways to walk the user through if they want to look at more 
details on each of the nodes (or types of nodes) before deploying.
- Would there be other states that a node could be in within the "Nodes waiting 
for action" section? If not, this could just be the "Nodes waiting to be 
deployed" section.
- I like that the stacked representation of the nodes will save space, but will 
the user be able to perform the actions that they would need to quickly on this 
page? It's also inconsistent with the original first use design used in Slide 
3. Maybe we could repeat this interaction and allow the user to add/remove the 
number of nodes quickly here? We could still use this stacked representation to 
monitor like nodes as you are showing in Slide 11.

Slide 6
-The addition of "Create New Compute Class" makes it seem like the user will be 
able to deploy these 27 nodes without being attached to a class. Or is this 
initial group a default resource class? How would the user move nodes from one 
class to another?

Slide 7
- This icon seems to be a way of telling the user that they've added all of 
these nodes to their "plan" and now they need to act on i

Re: [openstack-dev] creating a default for oslo config variables within a project?

2013-12-04 Thread Sean Dague

On 12/04/2013 11:56 AM, Ben Nemec wrote:
> On 2013-12-04 06:07, Sean Dague wrote:
>> On 12/03/2013 11:21 PM, Clint Byrum wrote:
>>> Excerpts from Sean Dague's message of 2013-12-03 16:05:47 -0800:
 On 12/03/2013 06:13 PM, Ben Nemec wrote:
> On 2013-12-03 17:09, Sean Dague wrote:
>> On 12/03/2013 05:50 PM, Mark McLoughlin wrote:
>>> On Tue, 2013-12-03 at 16:23 -0600, Ben Nemec wrote:
 On 2013-12-03 15:56, Sean Dague wrote:
> This cinder patch - https://review.openstack.org/#/c/48935/
>
> Is blocked on failing upgrade because the updated oslo
> lockutils won't
> function until there is a specific configuration variable added
> to the
> cinder.conf.
>
> That work around is proposed here -
> https://review.openstack.org/#/c/52070/3
>
> However I think this is exactly the kind of forward breaks that we
> want
> to prevent with grenade, as cinder failing to function after a
> rolling
> upgrade because a config item wasn't added is exactly the kind
> of pain
> we are trying to prevent happening to ops.
>
> So the question is, how is this done correctly so that a default
> can be
> set in the cinder code for this value, and it not require a config
> change to work?
>>>
>>> You're absolutely correct, in principle - if the default value for
>>> lock_path worked for users before, we should absolutely continue to
>>> support it.
>>>
 I don't know that I have a good answer on how to handle this,
 but for
 context this change is the result of a nasty bug in lockutils that
 meant
 external locks were doing nothing if lock_path wasn't set. 
 Basically
 it's something we should never have allowed in the first place.

 As far as setting this in code, it's important that all of the
 processes
 for a service are using the same value to avoid the same bad
 situation
 we were in before.  For tests, we have a lockutils wrapper
 (https://github.com/openstack/oslo-incubator/blob/master/openstack/common/lockutils.py#L282)

 that sets an environment variable to address this, but that only
 works if all of the processes are going to be spawned from within
 the same wrapper, and I'm not sure how secure that is for
 production
 deployments since it puts all of the lock files in a temporary
 directory.
>>>
>>> Right, I don't think the previous default really "worked" - if
>>> you used
>>> the default, then external locking was broken.
>>>
>>> I suspect most distros do set a default - I see RDO has this in its
>>> default nova.conf:
>>>
>>>   lock_path = /var/lib/nova/tmp
>>>
>>> So, yes - this is all terrible.
>>>
>>> IMHO, rather than raise an exception we should log a big fat warning
>>> about relying on the default and perhaps just treat the lock as an
>>> in-process lock in that case ... since that's essentially what it
>>> was
>>> before, right?
>>
>> So a default of lock_path = /tmp will work (FHS says that path has
>> to be
>> there), even if not optimal. Could we make it a default value like
>> that
>> instead of the current default which is null (and hence the problem).
>
> IIRC, my initial fix was something similar to that, but it got shot
> down
> because putting the lock files in a known world writeable location
> was a
> security issue.
>
> Although maybe if we put them in a subdirectory of /tmp and ensured
> that
> the permissions were such that only the user running the service could
> use that directory, it might be acceptable?  We could still log a
> warning if we wanted.
>
> This seems like it would have implications for people running services
> on Windows too, but we can probably find a way to make that work if we
> decide on a solution.

 How is that a security issue? Are the lock files being written with
 some
 sensitive data in them and have g or o permissions on? The sticky bit
 (+t) on /tmp will prevent other users from deleting the file.

>>>
>>> Right, but it won't prevent users from creating a symlink with the same
>>> name.
>>>
>>> ln -s /var/lib/nova/instances/x/image.raw /tmp/well.known.location
>>>
>>> Now when you do
>>>
>>> with open('/tmp/well.known.location', 'w') as lockfile:
>>>   lockfile.write('Stuff')
>>>
>>> Nova has just truncated the image file and written 'Stuff' to it.
>>
>> So that's the generic case (and the way people often write this). But
>> the oslo lockutils code doesn't work that way. While it does open the
>> file for write, it does not actually write, it's using fcntl to hold
>> locks. That's taking a data struct

Re: [openstack-dev] [keystone] Service scoped role definition

2013-12-04 Thread David Chadwick



On 04/12/2013 17:28, Tiwari, Arvind wrote:
> Hi David,
> 
> Thanks for your valuable comments.
> 
> I have updated
> https://etherpad.openstack.org/p/service-scoped-role-definition line
> #118 explaining the rationale behind the field.

#119 for my reply

> 
> I wd also appreciate your thoughts on
> https://etherpad.openstack.org/p/1Uiwcbfpxq too,

I have added a comment to the original bug report -
https://bugs.launchpad.net/keystone/+bug/968696

I think you should be going for simplifying Keystone's RBAC model rather
than making it more complex. In essence this would mean that assigning
permissions to roles and users to roles are separate and independent
processes and that roles on creation do not have to have any baggage or
restrictions tied to them. Here are my suggestions:

1. Allow different entities to create roles, and use hierarchical role
naming to maintain global uniqueness and to show which entity created
(owns) the role definition. Creating a role does not imply anything
about a role's subsequent permissions unless a scope field is included
in the definition.

2. When a role is created allow the creator to optionally add a scope
field which will limit the permissions that can be assigned to the role
to the prescribed scope.

3. Permissions will be assigned to roles in policy files by resource
owners. The can assign any permissions to their resources to the role
that they want to, except that they cannot override the scope field (ie.
grant permissions to resources which are out of the role's scope).

4. Remove any linkage of roles to tenants/projects on creation. This is
unnecessary baggage and only complicates the model for no good
functional reason.

regards

David


 which is support
> https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens
> BP.
> 
> 
> Thanks, Arvind
> 
> -Original Message- From: David Chadwick
> [mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday, December 04, 2013
> 2:16 AM To: Tiwari, Arvind; OpenStack Development Mailing List (not
> for usage questions); Adam Young Subject: Re: [openstack-dev]
> [keystone] Service scoped role definition
> 
> I have added comments 111 to 122
> 
> david
> 
> On 03/12/2013 23:58, Tiwari, Arvind wrote:
>> Hi David,
>> 
>> I have added my comments underneath line # 97 till line #110, it is
>> mostly aligned with your proposal with some modification.
>> 
>> https://etherpad.openstack.org/p/service-scoped-role-definition
>> 
>> 
>> Thanks for your time, Arvind
>> 
>> 
>> 
>> -Original Message- From: Tiwari, Arvind Sent: Monday,
>> December 02, 2013 4:22 PM To: Adam Young; OpenStack Development
>> Mailing List (not for usage questions); David Chadwick Subject: Re:
>> [openstack-dev] [keystone] Service scoped role definition
>> 
>> Hi Adam and David,
>> 
>> Thank you so much for all the great comments, seems we are making
>> good progress.
>> 
>> I have replied to your comments and also added some to support my
>> proposal
>> 
>> https://etherpad.openstack.org/p/service-scoped-role-definition
>> 
>> David, I like your suggestion for role-def scoping which can fit in
>> my Plan B and I think Adam is cool with plan B.
>> 
>> Please let me know if David's proposal for role-def scoping is cool
>> for everybody?
>> 
>> 
>> Thanks, Arvind
>> 
>> -Original Message- From: Adam Young
>> [mailto:ayo...@redhat.com] Sent: Wednesday, November 27, 2013 8:44
>> AM To: Tiwari, Arvind; OpenStack Development Mailing List (not for
>> usage questions) Cc: Henry Nash; dolph.math...@gmail.com; David
>> Chadwick Subject: Re: [openstack-dev] [keystone] Service scoped
>> role definition
>> 
>> 
>> 
>> On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:
>>> Hi Adam,
>>> 
>>> Based on our discussion over IRC, I have updated the below
>>> etherpad with proposal for nested role definition
>> 
>> Updated.  I made my changes Green.  It isn't easy being green.
>> 
>>> 
>>> https://etherpad.openstack.org/p/service-scoped-role-definition
>>> 
>>> Please take a look @ "Proposal (Ayoung) - Nested role
>>> definitions", I am sorry if I could not catch your idea.
>>> 
>>> Feel free to update the etherpad.
>>> 
>>> Regards, Arvind
>>> 
>>> 
>>> -Original Message- From: Tiwari, Arvind Sent: Tuesday,
>>> November 26, 2013 4:08 PM To: David Chadwick; OpenStack
>>> Development Mailing List Subject: Re: [openstack-dev] [keystone]
>>> Service scoped role definition
>>> 
>>> Hi David,
>>> 
>>> Thanks for your time and valuable comments. I have replied to
>>> your comments and try to explain why I am advocating to this BP.
>>> 
>>> Let me know your thoughts, please feel free to update below
>>> etherpad 
>>> https://etherpad.openstack.org/p/service-scoped-role-definition
>>> 
>>> Thanks again, Arvind
>>> 
>>> -Original Message- From: David Chadwick
>>> [mailto:d.w.chadw...@kent.ac.uk] Sent: Monday, November 25, 2013
>>> 12:12 PM To: Tiwari, Arvind; OpenStack Development Mailing List 
>>> Cc: Henry Nash; ayo...@redhat.com; dolph.math...@gmail.co

Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

2013-12-04 Thread Chuck Short

On Wed, Dec 4, 2013 at 11:16 AM, Nikola Đipanov  wrote:

> On 11/19/2013 05:52 PM, Peter Feiner wrote:
> > On Tue, Nov 19, 2013 at 11:19 AM, Chuck Short 
> wrote:
> >> Hi
> >>
> >>
> >> On Tue, Nov 19, 2013 at 10:43 AM, Peter Feiner 
> wrote:
> >>>
> >>> A substantive reason for switching from mox to mock is the derelict
> >>> state of mox releases. There hasn't been a release of mox in three
> >>> years: the latest, mox-0.5.3, was released in 2010 [1, 2]. Moreover,
> >>> in the past 3 years, substantial bugs have been fixed in upstream mox.
> >>> For example, with the year-old fix to
> >>> https://code.google.com/p/pymox/issues/detail?id=16, a very nasty bug
> >>> in nova would have been caught by an existing test [3].
> >>>
> >>> Alternatively, a copy of the upstream mox code could be added in-tree.
> >>>
> >> Please no, I think we are in an agreement with mox3 and mock.
> >
> > That's cool. As long as the mox* is phased out, the false-positive
> > test results will be fixed.
> >
> > Of course, there's _another_ alternative, which is to retrofit mox3
> > with the upstream mox fixes (e.g., the bug I cited above exists in
> > mox3). However, the delta between mox3 and upstream mox is pretty huge
> > (I just checked), so effort is probably better spent switching to
> > mock. To that end, I plan on changing the tests I cited above.
> >
>
> Resurrecting this thread because of an interesting review that came up
> yesterday [1].
>
> It seems that our lack of a firm decision on what to do with the mocking
> framework has left people confused. In hope to help - I'll give my view
> of where things are now and what we should do going forward, and
> hopefully we'll reach some consensus on this.
>
> Here's the breakdown:
>
> We should abandon mox:
> * It has not had a release in over 3 years [2] and a patch upstream for 2
> * There are bugs that are impacting the project with it (see above)
> * It will not be ported to python 3
>
> Proposed path forward options:
> 1) Port nova to mock now:
>   * Literally unmanageable - huge review overhead and regression risk
> for not so much gain (maybe) [1]
>
> 2) Opportunistically port nova (write new tests using mock, when fixing
> tests, move them to mock):
>  * Will take a really long time to move to mock, and is not really a
> solution since we are stuck with mock for an undetermined period of time
> - it's what we are doing now (kind of).
>
> 3) Same as 2) but move current codebase to mox3
>  * Buys us py3k compat, and fresher code
>  * Mox3 and mox have diverged and we would need to backport mox fixes
> onto the mox3 three and become de-facto active maintainers (as per Peter
> Feiner's last email - that may not be so easy).
>
>
So I thought we cleared this up already. We convert the current codebase
over to mox3, new tests should be done in mock. Eventually we start
converting over code to use mock.



> I think we should follow path 3) if we can, but we need to:
>
> 1) Figure out what is the deal with mox3 and decide if owning it will
> really be less trouble than porting nova. To be hones - I was unable to
> even find the code repo for it, only [3]. If anyone has more info -
> please weigh in. We'll also need volunteers
>
>
Monty and I did this last cycle, its apart of the openstack project,
although its not available in gerrit. Which should be fixed so we can start
getting bug fixes in for it.


> 2) Make better testing guidelines when using mock, and maybe add some
> testing helpers (like we do already have for mox) that will make porting
> existing tests easier. mreidem already put this on this weeks nova
> meeting agenda - so that might be a good place to discuss all the issues
> mentioned here as well.
>
> We should really take a stronger stance on this soon IMHO, as this comes
> up with literally every commit.
>

totally


>
> Cheers,
>
> Nikola
>
> [1] https://review.openstack.org/#/c/59694/
> [2] https://pypi.python.org/pypi/mox
> [3] https://pypi.python.org/pypi/mox3/0.7.0
>
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Tripleo] Core reviewer update Dec

2013-12-04 Thread James Slagle

On Wed, Dec 4, 2013 at 2:12 AM, Robert Collins
 wrote:
> In this months review:
>  - Ghe Rivero for -core

+1.  Has been doing very good reviews.

>  - Jan Provaznik for removal from -core
>  - Jordan O'Mara for removal from -core
>  - Martyn Taylor for removal from -core
>  - Jiri Tomasek for removal from -core
>  - Jamomir Coufal for removal from -core
>
> Jan, Jordan, Martyn, Jiri and Jaromir are still actively contributing
> to TripleO and OpenStack, but I don't think they are tracking /
> engaging in the code review discussions enough to stay in -core: I'd
> be delighted if they want to rejoin as core - as we discussed last
> time, after a shorter than usual ramp up period if they get stuck in.

What's the shorter than usual ramp up period?

In general, I agree with your points about removing folks from core.

We do have a situation though where some folks weren't reviewing as
frequently when the Tuskar UI/API development slowed a bit post-merge.
 Since that is getting ready to pick back up, my concern with removing
this group of folks, is that it leaves less people on core who are
deeply familiar with that code base.  Maybe that's ok, especially if
the fast track process to get them back on core is reasonable.

-- 
-- James Slagle
--

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

Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

2013-12-04 Thread Nikola Đipanov

On 12/04/2013 06:15 PM, Peter Feiner wrote:
> On Wed, Dec 4, 2013 at 11:16 AM, Nikola Đipanov  wrote:
>> 1) Figure out what is the deal with mox3 and decide if owning it will
>> really be less trouble than porting nova. To be hones - I was unable to
>> even find the code repo for it, only [3]. If anyone has more info -
>> please weigh in. We'll also need volunteers
>>
>> [3] https://pypi.python.org/pypi/mox3/0.7.0
> 
> That's all I was able to find.
> 

The package seems to be owned by people from the community - so maybe
someone will respond on this thread. Or if anyone knows who is behind
the package - let us know - it would be good to start figuring this out
sooner rather than later.

N.

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


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

Re: [openstack-dev] [keystone] Service scoped role definition

2013-12-04 Thread David Chadwick

Hi Adam

I understand your problem: having projects and services which have the
same name, then the lineage of a role containing this name is not
deterministically known without some other rule or syntax that can
differentiate between the two.

Since domains contain projects which contain services then isnt the
containment hierarchy already known and predetermined? If it is then:

4 name components mean it is a service specified role
3 name components mean it is a project specified role
2 name components mean it is a domain specified role
1 name component means it is globally named role (from the default domain)

a null string means the default domain or all projects in a domain. You
would never have null for a service name.

admin means the global admin role
/admin ditto
x/admin means the admin of the X domain
x/y/admin means the admin role for the y project in domain x
//x/admin means admin for service x from the default domain
etc.

will that work?

regards

David


On 04/12/2013 15:04, Adam Young wrote:
> On 12/04/2013 04:08 AM, David Chadwick wrote:
>> I am happy with this as far as it goes. I would like to see it being
>> made more general, where domains, services and projects can also own and
>> name roles
> Domains should be OK, but services would confuse the matter.  You'd have
> to end up with something like LDAP
> 
> role=  domain=default,service=glance
> 
> vs
> 
> role=  domain=default,project=glance
> 
> unless we have unambiguous implicit ordering, we'll need to make it
> explicit, which is messy.
> 
> I'd rather do:
> 
> One segment: globally defined roles.  These could also be considered
> roles defined in the default domain.
> Two segments service defined roles in the default domain
> Three Segments, service defined roles from non-default domain
> 
> To do domain scoped roles we could do something like:
> 
> domX//admin
> 
> 
> But It seems confusing.
> 
> Perhaps a better approach for project roles is to have the rule that the
> default domain can show up as an empty string.  Thus, project scoped
> roles from the default domain  would be:
> 
> \glance\admin
> 
> and from a non default domain
> 
> domX\glance\admin
> 
> 
> 
> 
> 
> 
> 
>>
>> regards
>>
>> David
>>
>>
>> On 04/12/2013 01:51, Adam Young wrote:
>>> I've been thinking about your comment that "nested roles are confusing"
>>>
>>>
>>> What if we backed off and said the following:
>>>
>>>
>>> "Some role-definitions are owned by services.  If a Role definition is
>>> owned by a service, in role assignment lists in tokens, those roles we
>>> be prefixd by the service name.  / is a reserved cahracter and weill be
>>> used as the divider between segments of the role definition "
>>>
>>> That drops arbitrary nesting, and provides a reasonable namespace.  Then
>>> a role def would look like:
>>>
>>> "glance/admin"  for the admin role on the glance project.
>>>
>>>
>>>
>>> In theory, we could add the domain to the namespace, but that seems
>>> unwieldy.  If we did, a role def would then look like this
>>>
>>>
>>> "default/glance/admin"  for the admin role on the glance project.
>>>
>>> Is that clearer than the nested roles?
>>>
>>>
>>>
>>> On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:
 Hi Adam,

 Based on our discussion over IRC, I have updated the below etherpad
 with proposal for nested role definition

 https://etherpad.openstack.org/p/service-scoped-role-definition

 Please take a look @ "Proposal (Ayoung) - Nested role definitions", I
 am sorry if I could not catch your idea.

 Feel free to update the etherpad.

 Regards,
 Arvind


 -Original Message-
 From: Tiwari, Arvind
 Sent: Tuesday, November 26, 2013 4:08 PM
 To: David Chadwick; OpenStack Development Mailing List
 Subject: Re: [openstack-dev] [keystone] Service scoped role definition

 Hi David,

 Thanks for your time and valuable comments. I have replied to your
 comments and try to explain why I am advocating to this BP.

 Let me know your thoughts, please feel free to update below etherpad
 https://etherpad.openstack.org/p/service-scoped-role-definition

 Thanks again,
 Arvind

 -Original Message-
 From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
 Sent: Monday, November 25, 2013 12:12 PM
 To: Tiwari, Arvind; OpenStack Development Mailing List
 Cc: Henry Nash; ayo...@redhat.com; dolph.math...@gmail.com; Yee, Guang
 Subject: Re: [openstack-dev] [keystone] Service scoped role definition

 Hi Arvind

 I have just added some comments to your blueprint page

 regards

 David


 On 19/11/2013 00:01, Tiwari, Arvind wrote:
> Hi,
>
>   Based on our discussion in design summit , I have redone the
> service_id
> binding with roles BP
> .
>
>
> I

Re: [openstack-dev] Multidomain User Ids

2013-12-04 Thread Henry Nash


On 4 Dec 2013, at 13:28, Dolph Mathews  wrote:

> 
> On Sun, Nov 24, 2013 at 9:39 PM, Adam Young  wrote:
> The #1 pain point I hear from people in the field is that they need to 
> consume read only  LDAP but have service users in something Keystone 
> specific.  We are close to having this, but we have not closed the loop.  
> This was something that was Henry's to drive home to completion.  Do we have 
> a plan?  Federation depends on this, I think, but this problem stands alone.
> 
> I'm still thinking through the idea of having keystone natively federate to 
> itself out of the box, where keystone presents itself as an IdP (primarily 
> for service users). It sounds like a simpler architectural solution than 
> having to shuffle around code paths for both federated identities and local 
> identities.
>  
> 
> Two Solutions:
> 1 always require domain ID along with the user id for role assignments.
> 
> From an API perspective, how? (while still allowing for cross-domain role 
> assignments)
>  
> 2 provide some way to parse from the user ID what domain it is.
> 
> I think you meant this one the other way around: Determine the domain given 
> the user ID.
>  
> 
> I was thinking that we could do something along the lines of 2 where we 
> provide  "domain specific user_id prefix"  for example, if there is just one 
> ldpa service, and they wanted to prefix anyting out of ldap with "ldap@", 
> then an id would be  "prefix"  "field from LDAP".  And would be configured on 
> a per domain basis.  THis would be optional.
> 
> The weakness is that itbe Log N to determine which Domain a user_id came 
> from.  A better approach would be to use a divider, like '@' and then prefix 
> would be the key for a hashtable lookup.  Since it is optional, domains could 
> still be stored in SQL and user_ids could be uuids.
> 
> One problem is if someone comes by later an "must" use email address as the 
> userid, the @ would mess them up.  So The default divider should be something 
> URL safe but no likely to be part of a userid. I realize that it might be 
> impossible to match this criterion.
> 
I know this sounds a bit like "back to the future', but how about we make a 
user_id passed via the API a structured binary field, containing a 
concatenation of domain_id and (the actual) user_id, but rather than have a 
separator, encode the start positions in the first few digits, e.g. something 
like:

Digit # Meaning
0-1 Start position of domain_id, (e.g. this will usually be 4)
2-3 Start position of user_id
4-N domain_id
M-end   user_id

We would run a migration that would convert all existing mappings.  Further, we 
would ensure (with padding if necessary) that this "new" user_id is ALWAYS 
larger than 64chars - hence we could easily detect which type of ID we had.

> For usernames, sure... but I don't know why anyone would care to use email 
> addresses as ID's.
>  
> 
> Actually, there might be other reasons to forbid @ signs from IDs, as they 
> look like phishing attempts in URLs.
> 
> Phishing attempts?? They need to be encoded anyway...
>  
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> 
> -Dolph
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [keystone] Service scoped role definition

Hi David, 

Thanks for your valuable comments. 

I have updated https://etherpad.openstack.org/p/service-scoped-role-definition 
line #118 explaining the rationale behind the field.

I wd also appreciate your thoughts on 
https://etherpad.openstack.org/p/1Uiwcbfpxq too, which is support 
https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP.


Thanks,
Arvind

-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] 
Sent: Wednesday, December 04, 2013 2:16 AM
To: Tiwari, Arvind; OpenStack Development Mailing List (not for usage 
questions); Adam Young
Subject: Re: [openstack-dev] [keystone] Service scoped role definition

I have added comments 111 to 122

david

On 03/12/2013 23:58, Tiwari, Arvind wrote:
> Hi David,
> 
> I have added my comments underneath line # 97 till line #110, it is mostly 
> aligned with your proposal with some modification.
>  
> https://etherpad.openstack.org/p/service-scoped-role-definition
> 
> 
> Thanks for your time,
> Arvind
> 
> 
> 
> -Original Message-
> From: Tiwari, Arvind 
> Sent: Monday, December 02, 2013 4:22 PM
> To: Adam Young; OpenStack Development Mailing List (not for usage questions); 
> David Chadwick
> Subject: Re: [openstack-dev] [keystone] Service scoped role definition
> 
> Hi Adam and David,
> 
> Thank you so much for all the great comments, seems we are making good 
> progress.
> 
> I have replied to your comments and also added some to support my proposal
> 
> https://etherpad.openstack.org/p/service-scoped-role-definition
> 
> David, I like your suggestion for role-def scoping which can fit in my Plan B 
> and I think Adam is cool with plan B.
> 
> Please let me know if David's proposal for role-def scoping is cool for 
> everybody?
> 
> 
> Thanks,
> Arvind
> 
> -Original Message-
> From: Adam Young [mailto:ayo...@redhat.com] 
> Sent: Wednesday, November 27, 2013 8:44 AM
> To: Tiwari, Arvind; OpenStack Development Mailing List (not for usage 
> questions)
> Cc: Henry Nash; dolph.math...@gmail.com; David Chadwick
> Subject: Re: [openstack-dev] [keystone] Service scoped role definition
> 
> 
> 
> On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:
>> Hi Adam,
>>
>> Based on our discussion over IRC, I have updated the below etherpad with 
>> proposal for nested role definition
> 
> Updated.  I made my changes Green.  It isn't easy being green.
> 
>>
>> https://etherpad.openstack.org/p/service-scoped-role-definition
>>
>> Please take a look @ "Proposal (Ayoung) - Nested role definitions", I am 
>> sorry if I could not catch your idea.
>>
>> Feel free to update the etherpad.
>>
>> Regards,
>> Arvind
>>
>>
>> -Original Message-
>> From: Tiwari, Arvind
>> Sent: Tuesday, November 26, 2013 4:08 PM
>> To: David Chadwick; OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition
>>
>> Hi David,
>>
>> Thanks for your time and valuable comments. I have replied to your comments 
>> and try to explain why I am advocating to this BP.
>>
>> Let me know your thoughts, please feel free to update below etherpad
>> https://etherpad.openstack.org/p/service-scoped-role-definition
>>
>> Thanks again,
>> Arvind
>>
>> -Original Message-
>> From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
>> Sent: Monday, November 25, 2013 12:12 PM
>> To: Tiwari, Arvind; OpenStack Development Mailing List
>> Cc: Henry Nash; ayo...@redhat.com; dolph.math...@gmail.com; Yee, Guang
>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition
>>
>> Hi Arvind
>>
>> I have just added some comments to your blueprint page
>>
>> regards
>>
>> David
>>
>>
>> On 19/11/2013 00:01, Tiwari, Arvind wrote:
>>> Hi,
>>>
>>>   
>>>
>>> Based on our discussion in design summit , I have redone the service_id
>>> binding with roles BP
>>> .
>>> I have added a new BP (link below) along with detailed use case to
>>> support this BP.
>>>
>>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
>>>
>>> Below etherpad link has some proposals for Role REST representation and
>>> pros and cons analysis
>>>
>>>   
>>>
>>> https://etherpad.openstack.org/p/service-scoped-role-definition
>>>
>>>   
>>>
>>> Please take look and let me know your thoughts.
>>>
>>>   
>>>
>>> It would be awesome if we can discuss it in tomorrow's meeting.
>>>
>>>   
>>>
>>> Thanks,
>>>
>>> Arvind
>>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org

Re: [openstack-dev] [keystone] Service scoped role definition