[openstack-dev] New comer to Openstack.

[akula nagaraj reddy]

Hi All,

Please let someone give how to start the things. I have moderate experience
in Python .



*Thanks and Regards*

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

Re: [openstack-dev] [glance] priorities for the coming week (12/09-12/15)

[Andrey Pavlov]

Hello,

Can you also review this - https://review.openstack.org/#/c/401277/
for bug - https://bugs.launchpad.net/glance-store/+bug/1644177

And please consider backport to Newton.

This bug is very annoying for deployments with several controllers and
glance over cinder...

On Fri, Dec 9, 2016 at 3:14 PM, Brian Rosmaita 
wrote:

> As discussed at the Glance weekly meeting yesterday, the priorities for
> 12/1 through 12/8, unfortunately look very similar to last week's
> priorities.  Some core reviewers need to step up.  The priorities are:
>
> Highest priority
> 
>
> (1) database strategy for rolling upgrades:
> https://review.openstack.org/#/c/331740/
> This one has a video to enhance your reviewing pleasure and demonstrate
> that the approach described actually is workable:
> https://www.youtube.com/watch?v=Z4iwJRlPqOw
>
> (2) glance expand/contract migrations with alembic:
> https://review.openstack.org/#/c/374278/
> We need another +2 on this one, preferably from a non-Rackspace person.
>
> (3) community images spec update:
> https://review.openstack.org/#/c/396919/
> New to the list.  The latest patch includes the migration strategy for
> which Erno said indicated on the patch he'd change his -2 to a +2, so
> don't let the -2 on the patch stop you from reviewing it.
>
> The above three specs need to be reviewed as soon as possible.  We are
> blocking Alex and Hemanth, because the Ocata database migration will
> handle the community images changes.
>
>
> Really high priority
> 
> (would be highest if the specs were already approved)
>
> (4) Patch to fix a glance_store regression:
> https://review.openstack.org/#/c/387719/
> and patch to prevent a related backend misconfiguration:
> https://review.openstack.org/#/c/388944/
>
> (5) Patch to enable better request-id tracking:
> https://review.openstack.org/#/c/352892/
> This will be nice for operators, let's get it reviewed and merged!
>
> (6) Request for some insights and opinions for bug
> https://bugs.launchpad.net/glance/+bug/1585917
>
>
> Please take a look
> ==
>
> (7) glanceclient problem: https://review.openstack.org/#/c/319960/
>
> thanks,
> brian
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [neutron] trunk api performance and scale measurments

[Armando M.]

On 8 December 2016 at 20:55, Armando M.  wrote:

>
>
> On 5 December 2016 at 07:59, Bence Romsics 
> wrote:
>
>> Hi,
>>
>> I measured how the new trunk API scales with lots of subports. You can
>> find the results here:
>>
>> https://wiki.openstack.org/wiki/Neutron_Trunk_API_Performance_and_Scaling
>>
>> Hope you find it useful. There are several open ends, let me know if
>> you're interested in following up some of them.
>>
>
> I looked into [1] a little bit as it bothered me :)
>
> Here's my findings:
>
>
>- openstack port list is slower than neutron port-list as it looks
>like the command goes to Nova first [2], which is where the overhead comes
>from.
>- when you have subports the port-list response gets bigger because of
>the bigger response due to the trunk-details extension.
>- However, the bulk of the time is spent in [3], when building the
>payload for a port involved as a parent port. In no other case you will see
>the overhead as in no other case the loop over subports is executed.
>
> The hook should be optimized!
>

Follow up: Kevin and I put together a couple of patches [1,2] to fix and
validate how to speed up the lookup. We'll dig into why sqlalchemy is
acting differently when listing ports with or without filters, but this
should do for now.

Cheers,
Armando

[1] https://review.openstack.org/#/c/409267/
[2] https://review.openstack.org/#/c/408983/


> [1] https://wiki.openstack.org/wiki/Neutron_Trunk_API_Performanc
> e_and_Scaling#surprise_effect_on_filtered_port_listings
> [2] http://paste.openstack.org/show/591882/
> [3] https://github.com/openstack/neutron/blob/master/
> neutron/services/trunk/plugin.py#L42
>
>
>> Cheers,
>> Bence Romsics
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Requirements] [Horizon] upper-constraints shenanigans and development milestones

[Ian Cordasco]

> On Dec 9, 2016, at 4:47 PM, Richard Jones  wrote:
> 
> Hi folks,
> 
> We in Horizon land are looking to update to a new version of one of
> our dependencies, Angular Bootstrap version 2.2.0. We do this through
> xstatic packaging, so the release we'll be making is actually
> xstatic-angular-bootstrap 2.2.0.0
> 
> This release is backward incompatible and breaks Horizon in many ways.
> We already have a compatibility patch in review to get us up to speed
> in Ocata, but prior versions of Horizon would break without
> upper-constraints protections. We've recently pushed through several
> changes to stable Mitaka to get those protections in place - Newton
> was already protected.
> 
> The problem is that we'll have two Ocata milestone releases out when
> 2.2.0.0 is released, and those will break because we currently pull in
> *master* upper-constraints for the milestone releases, rather than a
> stable/ocata branch of upper-constraints - there is no stable/ocata
> branch of upper-constraints yet.
> 
> Has the idea of branching at development milestones been raised previously?

Hi Richard :)

I'm not sure it has, but I'm rather certain it's not tenable. Now that you 
bring this up, Horizon isn't the only project that will get bit by this - 
Glance will too. (Until recently Glance's tests were not happy with the newest 
version(s) of oslo.log)

I don't think *branching* is the solution here, but perhaps tagging/releasing 
the requirements repository like we do other projects would be. That said, this 
introduces a significant amount more work for milestone releases. Here's how I 
imagine it would have to work:

openstack/requirements enters a freeze period leading up to a milestone. It 
tags it's Pike-1 milestone. This triggers the Requirements Bot to go around and 
update the constraints URL to the Pike-1 tag instead of "master". Once those 
are successfully merged, other projects releasing following the 
cycle-with-milestones release tag would then be able to create they own Pike-1 
tag. After a successful release, cores would have to update their tox.ini files 
to go back to master's constraints.

(And I'm not entirely certain we could get the proposal bot to ignore us 
switching constraints URLs back so that part may have to be manual too.)

The root of this discussion, however, seems to be around the idea that there 
are downstream consumers who are deploying OpenStack without 
distribution-provided packages (or using a deployment project) and who are 
using a rather naïve approach to dependency management. This is something that 
has come up within Glance as well recently (that each milestone needs to have 
certain restrictions).

Is there good evidence of this behavior anywhere? We've had trouble finding 
evidence of this happening in the real world with Glance and there's nothing in 
the project team guide that indicates the same level of support for milestone 
releases as for cycle releases.

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

[openstack-dev] [Horizon] End of week wrap-up

[Richard Jones]

Hi folks,

Ocata-2 will be released next week and we've had little success
getting the priority patches reviewed, unfortunately. We have had some
wins though, getting the upper-constraints stability patches into
stable Mitaka, which means we can be more confident releasing the
angular-bootstrap 2.2.0 xstatic library, and getting us out of the
dark ages of angular-bootstrap! We've also seen the profiler developer
panel get added, which will help us nail down some of the performance
issues that have been difficult to diagnose.

So yes, we're planning on tagging Horizon Ocata-2 (b2) next week, and
very shortly afterwards we'll be releasing xstatic-angular-bootstrap
2.2.0.0, and rolling in the compatibility patch for that into Horizon.
Horizon will be broken for a few days while compatibility is merged,
appropriate files are released and upper-constraints is updated.
Apologies, but that's just how backwards-incompatibility rolls,
sometimes!

This week's meeting[1] saw us discussing some of the patches under
review, but mostly, we discussed what to do with the languishing
integration test suite. David Lyle, PTL of many cycles, argued
strongly that they were a lost cause, and there was general support
for removing them completely, and migrating UI / full stack level
tests over to tempest. We have a couple of folks who will be looking
into that.

We also talked a little about our microversions approach, and Rob and
I have been nutting through the design of the approach in the
microversions etherherpad[2] to come up with an approach described in
the blueprint[3]. There's some ground-work to be done (pulling in
min/max version information, matching it to the config), and then
patches like instance description support can start using that version
support check facility.

There was also a request to be more fine-grained in attaching
blueprints to patches - the old "angularlise identity panels"
blueprint was widely abused, and it's good to see the individual panel
work being divided up now, thanks everyone!

Finally, we had a short talk about the mascot, and how to send
feedback on it (which you need to do ASAP if you haven't already). The
feedback link is [4]


Have a great weekend!

Richard

[1] 
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-12-07-20.00.html
[2] https://etherpad.openstack.org/p/horizon-microversion-support
[3] https://blueprints.launchpad.net/horizon/+spec/microversion-support
[4] http://www.tinyurl.com/OSmascot

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