Re: [openstack-dev] Mitaka Infra Sprint

[Elizabeth K. Joseph]

On Thu, Dec 10, 2015 at 3:24 AM, Joshua Hesketh
 wrote:
> Information + RSVP:
> https://wiki.openstack.org/wiki/Sprints/InfraMitakaSprint

Quick update:

HPE will be ordering catered lunches while we're there, so I've added
a "dietary restrictions" column to the wiki. Also, if you have
suggestions as to *what* cuisine of food should be catered or what
specifically should not be, I can pass those notes along.

I also added a hotel column. If you're comfortable sharing which one
you're staying at (it's ok if you're not!), it may make it easier to
coordinate rides to the office in the morning.

Finally, I propose a sign up cutoff of Friday, January 29th for sign
ups so we have enough time to place orders, etc.

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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] [Smaug]- IRC Meeting tomorrow (12/22) - 1400 UTC

[Eran Gampel]

We will have our first IRC meeting tomorrow (Tuesday, 12/22) at 1400 UTC in
#openstack-meeting

Please review the proposed meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/smaug

Please add to the agenda any subject you would like to discuss.

Project brief:

Smaug is a new OpenStack project, aiming at providing a full Cloud
Application Data Protection (e.g DR), including all OpenStack resources.

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

Re: [openstack-dev] [Cinder][DRBD] questions about pep8/flake8 etc.

[Walter A. Boring IV]

On 12/21/2015 06:40 AM, Philipp Marek wrote:

Hi everybody,

in the current patch https://review.openstack.org/#/c/259973/1 the test
script needs to use a lot of the constant definitions of the backend driver
it's using (DRBDmanage).

As the DRBDmanage libraries need not be installed on the CI nodes, I'm
providing a minimum of upstream files, accumulated in a separate directory
- they get imported and "fixed" to the expected location, so that the
driver that should be tested runs as if DRBDmanage is installed.


My problem is now that the upstream project doesn't accept all the pep8
conventions like Openstack does; so the CI run
 
http://logs.openstack.org/73/259973/1/check/gate-cinder-pep8/5032b16/console.html
gives a lot of messages like "E221 multiple spaces before operator" and
similar. (It even crashes during AST parsing ;)


So, I can see these options now:

   * Make pep8 ignore these files - they're only used by one test script,
 and are never used in production anyway.
 + Simple
 + New upstream files can simply be dropped in as needed
 - bad example?
   
   * Reformat the files to conform to pep8

 - some work for every new version that needs to be incorporated
 - can't be compared for equality with upstream any more
 - might result in mismatches later on, ie. production code uses
   different values from test code
I would suggest this option.  We don't want to allow code in cinder that 
bypasses the pep8 checks.  Since you are trying to get drbd support into 
Cinder, it then falls upon you to make sure the code you are submitting 
follows the same standards as the rest of the project.


Walt



   * Throw upstream files away, and do "manual" fakes
 - A lot of work
 - Work needed for every new needed constant
 - lots of duplicated code
 - might result in mismatches later on, ie. production code uses
   different values from test code
 + whole checkout still "clean" for pep8

   * Require DRBDmanage to be installed
 + uses same values as upstream and production
 - Need to get it upstream into PyPi
 - Meaning delay
 - delay for every new release of DRBDmanage
 - Might not even be compatible with every used distribution/CI
   out there


I would prefer the first option - make pep8 ignore these files.
But I'm only a small player here, what's the opinion of the Cinder cores?
Would that be acceptable?


Regards,

Phil

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




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

Re: [openstack-dev] [oslo][nova][all] timeutils deprecation removals will break Nova

[Matt Riedemann]

On 12/21/2015 1:22 PM, Davanum Srinivas wrote:

Rob,

Can we set some goals for the server projects too?

Say anything deprecated in liberty timeframe in oslo libs or any other
libs we consume should be fixed by milestone2 in mitaka? At the moment
the burden is entirely on oslo and hence unfair.

Thanks,
Dims

On Mon, Dec 21, 2015 at 2:15 PM, Robert Collins
 wrote:

On 21 December 2015 at 04:57, Davanum Srinivas  wrote:

Nova folks,

We have this review in oslo.utils:
https://review.openstack.org/#/c/252898/

There were failed effort in the past to cleanup in Nova:
https://review.openstack.org/#/c/164753/
https://review.openstack.org/#/c/197601/

What do we do? Suggestions please.


We don't remove it yet. Not till liberty-eol at the earliest, or if we
don't get users migrated early enough, mitaka-eol.

We would benefit from an automated thing in place to tell projects
like Nova that they are using deprecated things during CI (without
bloating deployer logs) -  whether a keystone API, an oslo config
option or function, or $whatever. We would also benefit from a thing
to rollup such information from consuming projects back to the
deprecating project, so we can tell whether we're ready to cleanup old
things.

I think in general that there needs to be a balance around effort on
migrations: if oslo deprecates something - anything - we're creating
work for consumers of oslo. Its unfair for us to do that unilaterally.
Conversely, if projects don't migrate away from poor APIs onto newer
better ones, they create long term maintenance work for oslo: so we
all need to work together to coordinate such things.

https://review.openstack.org/#/c/226157/12 is part of this - it is an
effort to bring consistency in expectations and process/patterns here.

-Rob

--
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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






Nova also needs an Oslo liaison [1]. That used to be Joe Gordon, but 
he's gone now. That would really be the person in Nova driving the Oslo 
changes and review priorities.


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

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Sender Auth Failure] Re: [Sender Auth Failure] Re: [neutron] How could an L2 agent extension access agent methods ?

[Frances, Margaret]

Hello Ihar,

On 12/17/15, 11:00 AM, "Ihar Hrachyshka"  wrote:

>Margaret  wrote:
>
>>Hello Ihar,
>>
>>I have some comments and questions about your proposal.  My apologies if
>>any of what I say here results from misunderstandings on my part.
>
>Thanks a lot for the reply. I will try to clear up below.
>
>>
>>1. I believe there are two sorts of redirection at play here.  The first
>>involves inter-table traversal while the second allows a frame to exit
>>the
>>OF pipeline either by being sent to a different port or by being dropped.
>>Some of what I say next makes use of this distinction.
>>
>
>I am not sure I understand what is inter-table traversal. My assumption
>was  
>that extension tables defined for modification actions don’t redirect
>anywhere except back into table0 (using default flow rules we add to each
> 
>table on its bootstrapping).

OpenFlow’s Goto instruction and OvS’ resubmit action both result in
inter-table traversal in the sense I meant above.  This is as opposed to
what you've called a 'redirection flow table,' which sends the packet out
of the pipeline altogether.  I wanted to distinguish these two things in
part because the proposal describes table 0 flow entries ‘redirecting'
frames to another OF table and vice versa.

>
>>2. OpenFlow¹s Goto instruction directs a frame from one table to the
>>next.
>>  A redirection in this sense must be to a higher-numbered table, which
>>is
>>to say that OF pipeline processing can only go forward (see p.18, para.2
>>of the 1.4.1 spec
>>>f-
>>specifications/openflow/openflow-switch-v1.4.1.pdf>).  However, OvS (at
>>least v2.0.2) implements a resubmit action, which re-searches another
>>table‹higher-, lower-, or even same-numbered‹and executes any actions
>>found there in addition to any subsequent actions in the current flow
>>entry.  It is by using resubmit that the proposed design could work, as
>>shown in the ovs-ofctl command posted here
>>>y>
>>.  (Maybe there are other ways, too.)  The resubmit action is a Nicira
>>vendor extension that at least at one point, and maybe still, was known
>>to
>>be implemented only by OvS.  I mention this because I wonder if the
>>proposed design (and my sample command) calls for flow traversal in a
>>manner not explicitly supported by OpenFlow and so may not work in future
>>versions of OvS.
>>
>
>Thanks for directions to specific OF features we can utilize! I believe
>we  
>may assume some implementation of resubmit can be safely expected to be
>present in the OVS. We may refine API we rely on later if we see it
>deprecated.
>
>>3. Regarding the idea of sorting feature flows by kind: I believe that
>>what is meant by a 'redirection flow table' is a table that could
>>possibly
>>remove the frame from OF pipeline processing‹i.e., by forwarding or
>>dropping it.  Can you correct/confirm?
>>
>
>Yes, that’s the intent. I feel I need to dig OF documentation a bit so
>that  
>I make myself more in line with terminology used there. Sorry for
>misunderstandings occurring due to vague terms used.
>
>>4. Even though the design promotes playing nice by means of feature flow
>>kinds, I think that features might nevertheless still step on each
>>others¹
>>toes due to assumptions made about field content.  I¹m thinking, for
>>instance, of two features whose in-place frame modifications should be
>>done in a particular order.  Because of this, I¹m not sure that the
>>granularity of the proposed design can guarantee feature cooperation.
>>Maybe it would help to prioritize feature flows as ingress-processing
>>(that is, the flow should be exercised as early as possible in the
>>pipeline) versus egress-processing (the opposite) in addition to kind‹or
>>maybe that is just what  the notion of feature flow kind calls for, at
>>least in part.  Tied (tangential?) to this is the distinction that
>>OpenFlow makes between an action list and an action set: the former is a
>>series of actions that is applied to the frame immediately and in the
>>order specified in the flow entry; the latter is a proper set of actions
>>that is applied to the frame only upon its exit from the OF pipeline and
>>in an order specified by protocol.  (Action set content is modified as
>>the
>>frame traverses the OF pipeline.)  Should action sets be disallowed?
>
>I learned a bit more from you, again. :) Thanks!
>
>I am not sure I completely follow the suggestion with prioritizing as
>ingress-processing. Can you elaborate?

You and Rosella have had a subsequent conversation that I think addresses
my concerns.  But to continue my earlier thought: if multiple extensions
actually might modify the same frame elements, and in a way that would
change behavior based on ordering: I was thinking that within the category
of frame-modifying flows, for example, feature 

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,

We are eager to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- (no diff)
- Ironic: 143 bugs + 149 wishlist items. 18 new, 89 in progress, 0
critical, 14 high and 9 incomplete
- Inspector: 12 bugs + 14 wishlist items. 0 new, 5 in progress, 0 critical,
7 high and 0 incomplete
- Nova bugs with Ironic tag: 26. 1 new, 0 critical, 0 high
- dashboard updated to count wishlist items separately

Network isolation (Neutron/Ironic work) (jroll)
===
- no update, patches in review failing all tests :(

Multiple compute hosts (jroll, devananda)
=
- Time to push forward

ironic-lib adoption (rloo)
==
- Done! patch was merged: https://review.openstack.org/#/c/184443/

Nova Liaisons (jlvillal & mrda)
===
- mrda & jlvillal conducted bug scrub
- 3 bugs considered since last meeting
- Total of 25 bugs outstanding

Doc (jroll, liliars)

- Official docs install guide
- Discussion going over on docs ML
-
http://lists.openstack.org/pipermail/openstack-docs/2015-December/008113.html
- folks seem more open to include some other guides for mitaka,
lets see how it goes
- Versioned in-tree docs
-
http://lists.openstack.org/pipermail/openstack-dev/2015-December/082207.html
- solved!

Inspector (dtansur)
===
- gate is down right now: https://review.openstack.org/#/c/259393/

webclient (krotscheck / betherly)
=
- krotscheck is back from vacation.
- New info on getting a server for UX things while HPCloud shuts down.

.

Until next year,
--ruby

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

Re: [openstack-dev] [TripleO] tripleoclient/tripleo-common backwards compatibility

[Steven Hardy]

Ok, looked into this a little today, apologies for replying to my own
thread:

On Mon, Dec 21, 2015 at 01:35:54PM +, Steven Hardy wrote:
> Hi all,
> 
> So I've recently had several discussions related to $subject.
> 
> In summary - there's a requirement to enable underclouds to support
> deploying/updating previous versions of OpenStack overclouds.
> 
> So, say I upgrade my liberty undercloud to master/mitaka, I'd like to
> ensure the following is possible:
> 
> 1. Maintain any existing (liberty) overcloud without being forced to
> immediately upgrade to Mitaka (updating the undercloud can pull in features
> required to enable this upgrade however).
>
> 2. Deploy a new overcloud, with the choice between either liberty or mitaka
> 
> This has some implications related to distributing tripleo-heat-templates
> (need to allow for packaging to either install both versions of t-h-t, or
> always install all versions via one package), and then there are related
> requirements related to tripleoclient (and potentially tripleo-common), so
> we maintain backwards compatiblity wrt overcloud deployment/update.
> 
> So, some questions:
> 
> - Do we actually want stable branches for tripleoclient (or even
>   tripleo-common?) if we have to maintain backwards compatibility?
> 
> - Can we add features to tripleoclient now, to make it easier to
>   pre-configure known locations for specific releases (this should be
>   configurable via a config file IMO, not hard-coded)?
> 
> - How might we effectively test this in CI?  Have a job which deploys e.g
>   a stable/liberty overcloud with a master undercloud?
> 
> - How hard would it be to wire in image-building for a previous release
>   (Mitaka/master undercloud building liberty overcloud-full) - would it be
>   reasonable to assume existing images and say the undercloud only supports
>   building images for one release version?

Turns out this is pretty easy:

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

This shows how to build a liberty overcloud-full (on a master/mitaka
undercloud), then deploy a stable/liberty overcloud.

I've not heavily tested, but basically it seems to work OK, I had to apply
this pending stable/liberty backport:

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

I think the tripleo.sh patch (and steps outlined in the commit message) may
serve as a starting point for CI of this, and I do think we need to remove
the stable/liberty branch at least for tripleoclient.

Steve

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

Re: [openstack-dev] [oslo][nova][all] timeutils deprecation removals will break Nova

[Robert Collins]

On 21 December 2015 at 04:57, Davanum Srinivas  wrote:
> Nova folks,
>
> We have this review in oslo.utils:
> https://review.openstack.org/#/c/252898/
>
> There were failed effort in the past to cleanup in Nova:
> https://review.openstack.org/#/c/164753/
> https://review.openstack.org/#/c/197601/
>
> What do we do? Suggestions please.

We don't remove it yet. Not till liberty-eol at the earliest, or if we
don't get users migrated early enough, mitaka-eol.

We would benefit from an automated thing in place to tell projects
like Nova that they are using deprecated things during CI (without
bloating deployer logs) -  whether a keystone API, an oslo config
option or function, or $whatever. We would also benefit from a thing
to rollup such information from consuming projects back to the
deprecating project, so we can tell whether we're ready to cleanup old
things.

I think in general that there needs to be a balance around effort on
migrations: if oslo deprecates something - anything - we're creating
work for consumers of oslo. Its unfair for us to do that unilaterally.
Conversely, if projects don't migrate away from poor APIs onto newer
better ones, they create long term maintenance work for oslo: so we
all need to work together to coordinate such things.

https://review.openstack.org/#/c/226157/12 is part of this - it is an
effort to bring consistency in expectations and process/patterns here.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [oslo][nova][all] timeutils deprecation removals will break Nova

[Davanum Srinivas]

Rob,

Can we set some goals for the server projects too?

Say anything deprecated in liberty timeframe in oslo libs or any other
libs we consume should be fixed by milestone2 in mitaka? At the moment
the burden is entirely on oslo and hence unfair.

Thanks,
Dims

On Mon, Dec 21, 2015 at 2:15 PM, Robert Collins
 wrote:
> On 21 December 2015 at 04:57, Davanum Srinivas  wrote:
>> Nova folks,
>>
>> We have this review in oslo.utils:
>> https://review.openstack.org/#/c/252898/
>>
>> There were failed effort in the past to cleanup in Nova:
>> https://review.openstack.org/#/c/164753/
>> https://review.openstack.org/#/c/197601/
>>
>> What do we do? Suggestions please.
>
> We don't remove it yet. Not till liberty-eol at the earliest, or if we
> don't get users migrated early enough, mitaka-eol.
>
> We would benefit from an automated thing in place to tell projects
> like Nova that they are using deprecated things during CI (without
> bloating deployer logs) -  whether a keystone API, an oslo config
> option or function, or $whatever. We would also benefit from a thing
> to rollup such information from consuming projects back to the
> deprecating project, so we can tell whether we're ready to cleanup old
> things.
>
> I think in general that there needs to be a balance around effort on
> migrations: if oslo deprecates something - anything - we're creating
> work for consumers of oslo. Its unfair for us to do that unilaterally.
> Conversely, if projects don't migrate away from poor APIs onto newer
> better ones, they create long term maintenance work for oslo: so we
> all need to work together to coordinate such things.
>
> https://review.openstack.org/#/c/226157/12 is part of this - it is an
> effort to bring consistency in expectations and process/patterns here.
>
> -Rob
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

[Carl Baldwin]

On Fri, Dec 18, 2015 at 12:54 PM, Vladimir Eremin  wrote:
> Hi Carl,
>
> As far as I understand Address Scopes, end user’s algorithm will be next:
> 1. Administrator creates an address scope and associate an IPv6 subnet pool 
> with it.
> 2. Administrator creates Public shared network’s subnet from this subnet pool.
> 3. Tenant user creates tenant network from this subnet pool and connect it to 
> Public shared network with router
> 4. OpenStack advertises prefix to the external interface of the router.

Yes, this sounds like the right way to do it.  As long as we implement
step 4 to be address scope aware, what you describe here will work.

There is some flexibility to attach multiple subnet pools to the same
address scope.  This would allow a particular tenant to have exclusive
access to a pool under the right scope.

Carl

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

[openstack-dev] [ironic] no meeting December 28

[Jim Rollenhagen]

Hey all,

Most people won't be around next week, December 28, so we're canceling
that meeting. A few of us will be around in #openstack-ironic if you've
got something you want to chat about, though. :)

// jim

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

[openstack-dev] [Infra] Meeting Tuesday December 22nd at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is not skipping meetings
through the end of month holidays, so we are having our next weekly
meeting as scheduled on Tuesday December 22nd, at 19:00 UTC in
#openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting

Anyone is welcome to to add agenda items and everyone interested in
the project infrastructure and process surrounding automated testing
and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last meeting are available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-12-15-19.03.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-12-15-19.03.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-12-15-19.03.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

[openstack-dev] [Neutron][networking-sfc] - No service chaining project IRC Meeting on 12/24 and 12/31

[Cathy Zhang]

Hi everyone,

We will cancel 12/24 and 12/31 1700 UTC IRC meetings for service chaining 
project since quite some people will be on vacation.
We will resume the project meeting on 1/7/2016.

Happy Holiday!

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

Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources

[Vilobh Meshram]

As mentioned by Hongbin we might have these 3 cases. Hongbin and I did
discuss about these in the Magnum IRC.

The interestring case being the #2 one. Where in case enough resources are
not available at the IaaS layer, and Magnum is in the process of creating a
Bay; Magnum needs to be more descriptive about the failure so that the
operator or user can be aware what exactly happened i.e. did the request
failed because of resource constraints at the PaaS layer, at the IaaS layer
etc.

Having the Quota layer at magnum will abstract out the underlying layer and
would impose quota on objects that Magnum understands. But again it would
be nice to know what operators think about it and would it be something
that they will find useful.

-Vilobh

On Mon, Dec 21, 2015 at 2:58 PM, Hongbin Lu  wrote:

> If we decide to support quotas in CaaS layer (i.e. limit the # of bays),
> its implementation doesn’t have to be redundant to IaaS layer (from Nova,
> Cinder, etc.). The implementation could be a layer on top of IaaS, in which
> requests need to pass two layers of quotas to succeed. There would be three
> cases:
>
> 1.   A request exceeds CaaS layer quota. Then, magnum rejects the
> request.
>
> 2.   A request is within CaaS layer quota, and accepted by magnum.
> Magnum calls Heat to create a stack, which will fail if the stack exceeds
> IaaS layer quota. In this case, magnum catch and re-throw the exception to
> users.
>
> 3.   A request is within both CaaS and IaaS layer quota, and the
> request succeeds.
>
>
>
> I think the debate here is whether it would be useful to implement an
> extra layer of quota management system in Magnum. My guess is “yes”, if
> operators want to hide the underline infrastructure, and expose a pure CaaS
> solution to its end-users. If the operators don’t use Magnum in this way,
> then I will vote for “no”.
>
>
>
> Also, we can reference other platform-level services (like Trove and
> Sahara) to see if they implemented an extra layer of quota management
> system, and we could use it as a decision point.
>
>
>
> Best regards,
>
> Honbgin
>
>
>
> *From:* Adrian Otto [mailto:adrian.o...@rackspace.com]
> *Sent:* December-20-15 12:50 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
>
> *Subject:* Re: [openstack-dev] [openstack][magnum] Quota for Magnum
> Resources
>
>
>
> This sounds like a source-of-truth concern. From my perspective the
> solution is not to create redundant quotas. Simply quota the Magnum
> resources. Lower level limits *could* be queried by magnum prior to acting
> to CRUD the lower level resources. In the case we could check the maximum
> allowed number of (or access rate of) whatever lower level resource before
> requesting it, and raising an understandable error. I see that as an
> enhancement rather than a must-have. In all honesty that feature is
> probably more complicated than it's worth in terms of value.
>
> --
>
> Adrian
>
>
> On Dec 20, 2015, at 6:36 AM, Jay Lau  wrote:
>
> I also have the same concern with Lee, as Magnum depend on HEAT  and HEAT
> need call nova, cinder, neutron to create the Bay resources. But both Nova
> and Cinder has its own quota policy, if we define quota again in Magnum,
> then how to handle the conflict? Another point is that limiting the Bay by
> quota seems a bit coarse-grainded as different bays may have different
> configuration and resource request. Comments? Thanks.
>
>
>
> On Thu, Dec 17, 2015 at 4:10 AM, Lee Calcote  wrote:
>
> Food for thought - there is a cost to FIPs (in the case of public IP
> addresses), security groups (to a lesser extent, but in terms of the
> computation of many hundreds of them), etc. Administrators may wish to
> enforce quotas on a variety of resources that are direct costs or indirect
> costs (e.g. # of bays, where a bay consists of a number of multi-VM /
> multi-host pods and services, which consume CPU, mem, etc.).
>
>
>
> If Magnum quotas are brought forward, they should govern (enforce quota)
> on Magnum-specific constructs only, correct? Resources created by Magnum
> COEs should be governed by existing quota policies governing said resources
> (e.g. Nova and vCPUs).
>
>
>
> Lee
>
>
>
> On Dec 16, 2015, at 1:56 PM, Tim Bell  wrote:
>
>
>
> -Original Message-
> From: Clint Byrum [mailto:cl...@fewbar.com ]
> Sent: 15 December 2015 22:40
> To: openstack-dev 
> Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum
> Resources
>
> Hi! Can I offer a counter point?
>
> Quotas are for _real_ resources.
>
>
> The CERN container specialist agrees with you ... it would be good to
> reflect on the needs given that ironic, neutron and nova are policing the
> resource usage. Quotas in the past have been used for things like key pairs
> which are not really real.
>
>
> Memory, CPU, disk, bandwidth. These are all _closely_ 

Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources

[Hongbin Lu]

If we decide to support quotas in CaaS layer (i.e. limit the # of bays), its 
implementation doesn't have to be redundant to IaaS layer (from Nova, Cinder, 
etc.). The implementation could be a layer on top of IaaS, in which requests 
need to pass two layers of quotas to succeed. There would be three cases:

1.   A request exceeds CaaS layer quota. Then, magnum rejects the request.

2.   A request is within CaaS layer quota, and accepted by magnum. Magnum 
calls Heat to create a stack, which will fail if the stack exceeds IaaS layer 
quota. In this case, magnum catch and re-throw the exception to users.

3.   A request is within both CaaS and IaaS layer quota, and the request 
succeeds.

I think the debate here is whether it would be useful to implement an extra 
layer of quota management system in Magnum. My guess is "yes", if operators 
want to hide the underline infrastructure, and expose a pure CaaS solution to 
its end-users. If the operators don't use Magnum in this way, then I will vote 
for "no".

Also, we can reference other platform-level services (like Trove and Sahara) to 
see if they implemented an extra layer of quota management system, and we could 
use it as a decision point.

Best regards,
Honbgin

From: Adrian Otto [mailto:adrian.o...@rackspace.com]
Sent: December-20-15 12:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources

This sounds like a source-of-truth concern. From my perspective the solution is 
not to create redundant quotas. Simply quota the Magnum resources. Lower level 
limits *could* be queried by magnum prior to acting to CRUD the lower level 
resources. In the case we could check the maximum allowed number of (or access 
rate of) whatever lower level resource before requesting it, and raising an 
understandable error. I see that as an enhancement rather than a must-have. In 
all honesty that feature is probably more complicated than it's worth in terms 
of value.

--
Adrian

On Dec 20, 2015, at 6:36 AM, Jay Lau 
> wrote:
I also have the same concern with Lee, as Magnum depend on HEAT  and HEAT need 
call nova, cinder, neutron to create the Bay resources. But both Nova and 
Cinder has its own quota policy, if we define quota again in Magnum, then how 
to handle the conflict? Another point is that limiting the Bay by quota seems a 
bit coarse-grainded as different bays may have different configuration and 
resource request. Comments? Thanks.

On Thu, Dec 17, 2015 at 4:10 AM, Lee Calcote 
> wrote:
Food for thought - there is a cost to FIPs (in the case of public IP 
addresses), security groups (to a lesser extent, but in terms of the 
computation of many hundreds of them), etc. Administrators may wish to enforce 
quotas on a variety of resources that are direct costs or indirect costs (e.g. 
# of bays, where a bay consists of a number of multi-VM / multi-host pods and 
services, which consume CPU, mem, etc.).

If Magnum quotas are brought forward, they should govern (enforce quota) on 
Magnum-specific constructs only, correct? Resources created by Magnum COEs 
should be governed by existing quota policies governing said resources (e.g. 
Nova and vCPUs).

Lee

On Dec 16, 2015, at 1:56 PM, Tim Bell 
> wrote:

-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com]
Sent: 15 December 2015 22:40
To: openstack-dev 
>
Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum
Resources

Hi! Can I offer a counter point?

Quotas are for _real_ resources.

The CERN container specialist agrees with you ... it would be good to
reflect on the needs given that ironic, neutron and nova are policing the
resource usage. Quotas in the past have been used for things like key pairs
which are not really real.


Memory, CPU, disk, bandwidth. These are all _closely_ tied to things that
cost

real money and cannot be conjured from thin air. As such, the user being
able to allocate 1 billion or 2 containers is not limited by Magnum, but
by real

things that they must pay for. If they have enough Nova quota to allocate
1

billion tiny pods, why would Magnum stop them? Who actually benefits from
that limitation?

So I suggest that you not add any detailed, complicated quota system to
Magnum. If there are real limitations to the implementation that Magnum
has chosen, such as we had in Heat (the entire stack must fit in memory),
then make that the limit. Otherwise, let their vcpu, disk, bandwidth, and
memory quotas be the limit, and enjoy the profit margins that having an
unbound force multiplier like Magnum in your cloud gives you and your
users!

Excerpts from Vilobh Meshram's message of 2015-12-14 16:58:54 -0800:

Hi All,

Currently, it is possible to create 

Re: [openstack-dev] [doc] DocImpact vs. reno

[Doug Hellmann]

Excerpts from Andreas Jaeger's message of 2015-12-18 20:31:04 +0100:
> On 12/18/2015 07:45 PM, Sean Dague wrote:
> > On 12/18/2015 01:34 PM, Andreas Jaeger wrote:
> >> On 12/18/2015 07:03 PM, Sean Dague wrote:
> >>> Recently noticed that a new job ended up on all nova changes that was
> >>> theoertically processing commit messages for DocImpact. It appears to be
> >>> part of this spec -
> >>> http://specs.openstack.org/openstack/docs-specs/specs/mitaka/review-docimpact.html
> >>>
> >>
> >> Lana talked with John Garbutt about this and announced this also in
> >> several 'What's up' newsletters like
> >> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081522.html
> >>
> >>
> >>> First, a heads up would be good. Nova burns a lot of nodes (i.e. has a
> >>> lot of patch volume), so this just decreased everyone's CI capacity
> >>> noticably.
> >>
> >> I understand this reasoning and Joshua worked on a superior solution,
> >> see
> >> https://review.openstack.org/#/q/status:open+project:openstack-infra/zuul+branch:master+topic:skip-commit,n,z
> >>
> >>
> >>>
> >>> Secondly, this all seems like the wrong direction. We've got reno now,
> >>> which is extremely useful for documenting significant changes in the
> >>> code base that need to be reflected up. We've dropped UpgradeImpact for
> >>> an upgrade comment in reno, which is *so* much better.
> >>>
> >>> It seems like using reno instead of commit message tags would be much
> >>> better for everyone here.
> >>
> >> The goal of DocImpact is to notify the Documentation team about changes
> >> - currently done via bugs in launchpad so that manuals can be easily
> >> updated. How would this tracking work with docimpact?
> >
> > Because the current concern seems to be that naked DocImpact tag leaves
> > people guessing what is important. And I understand that. There is a
> > whole job now to just check that DocImpact containts a reason after it.
> >
> > We now have a very detailed system in reno to describe changes that will
> > impact people using the code. It lets you do that with the commit and
> > provide an arbitrarily large amount of content in it describing what and
> > why you think that's important to reflect up.
> >
> > I think it effectively deprecates all *Impact flags. Now we have a place
> > for that payload.
> 
> 
> We - Sean, Anne Gentle, and Jeremy Stanley - just discussed this on 
> #openstack-infra, let me summarize my understanding:
> 
> Some flags are used for checking before a merge the changes, especially 
> SecurityImpact and APIImpact. These are used for reviewing the changes. 
> This would be nice for DocImpact as well. SecurityImpact creates emails 
> for merged changes, DocImpact creates bugs for merged changes.
> 
> When the docimpact spec was written, reno was not in use - and later 
> nobody brought it up as alternative idea.
> 
> The idea going forward is instead of checking the commit message, is to 
> add a special section using reno that explains the changes that are 
> needed. A post-job would run and create bugs or sends out emails like 
> today whenever a new entry gets added. But this would be triggered by 
> special sections in the release-notes and not in the commit message. We 
> also expect/hope that release notes get a good review and thus the 
> quality of these notifications would be improved.

So you want to add a special section to the reno note file, similar to
"upgrade" and "fixes" but to replace documentation impact notes? What
would use the contents?

Doug

> 
> Let's look on how exactly we can do this next year,
> 
> Andreas

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

[openstack-dev] [Fuel] Removal of support for nova-network

[Sheena Gregson]

Hey guys –



I know this has been a topic of a lot of discussion – Adrian informed me on
Friday that QA has confirmed the multi-hypervisor use case has been tested
successfully without nova-network, so we can finally deprecate it!



Users who want to deploy multiple hypervisors will need to use the Fuel DVS
plugin (Neutron ML2 driver) to support their vCenter computes and the
KVM/QEMU computes can use Neutron + GRE/VXLAN.



I’ve created a kind of “cover all the things” bug here:
https://bugs.launchpad.net/fuel/+bug/1528407.  Given the state of
nova-network right now in Fuel, I have marked it as Critical.



Let’s start the conversation on here and make sure all the bases are
covered – if additional bugs need to be logged or there’s administrative
overhead, let me know and I’ll be happy to help out!



Sheena Gregson | Sr. Product Manager | Mirantis 

p: +1 650 646 3302 | e: sgreg...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

[Carl Baldwin]

I noticed a couple of things today while reviewing a largish page [1].
First, when I search for something using the browser's builtin search
(Chrome, Mac OSX Yosemite), it doesn't seem to find occurrences that
are not in the visible portion of the page.  For example, when I
search for DNSDOMAIN, I get 1 hit from the top of the file.  The file
actually has almost 30 hits for this string.  For example, scroll down
to about L310 in the file.  You'll see them all over the place (and
now Chrome's search finds these hits if you try again).  I use to use
search within a file with the old gerrit and never noticed this
problem.

The other thing that I found annoying is when I scroll the page with
my trackpad, it now jumps around sometimes to a different part of the
page.  For example, I'll scroll up to find a spot in the file and when
I think I've arrived, it will jump back down the file a bit.  It is
disorienting.  Of course, now it isn't doing it anymore so it doesn't
seem to be all the time.  It was behaving this way for a good 20
minutes trying to get through this file.

Carl

Carl

[1] https://review.openstack.org/#/c/212213/36/neutron/db/dns_db.py

On Thu, Dec 17, 2015 at 8:17 PM, Brian Haley  wrote:
> On 2015-12-16 16:24, openstack-dev-requ...@lists.openstack.org wrote:
>>
>> Thanks to everyone for their patience while we upgraded to Gerrit
>> 2.11.  I'm happy to announce that we were able to successfully
>> completed this task at around 21:00 UTC.  You may hack away once more.
>>
>> If you encounter any problems, please let us know here or in
>> #openstack-infra on Freenode.
>
>
> I'm still undecided on 2.11, have to give it more time, but I have noticed
> one thing that's annoying...
>
> Trying to copy text from a review no longer works easily.  When I highlight
> text there's a little "bubble" pop-up of {press c to comment}, which seems
> to interfere with both my three-button mouse copy buffer, as well as Ctrl-C.
> Call me a nitpicker, but having to highlight text, right-button click, Copy,
> right-button click, Paste, is a pain.
>
> Maybe someone has a simple work-around for that.
>
> -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

__
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] Cross-Project Meeting SKIPPED Until January 5

[Mike Perez]

Hi all! 

We will be skipping the cross-project meeting until January 5th since a lot of 
people will be out for holidays.

Please use the meeting page to propose an agenda item for the next meeting [1].

We also have a new meeting channel which is #openstack-meeting-cp where the 
cross-project meeting will take place at it's usual time Tuesdays at 2100 UTC 
when there are agenda items.


[1] - https://wiki.openstack.org/wiki/Meetings/CrossProjectM

-- 
Mike Perez 

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

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

[Carl Baldwin]

I also really miss being able to pull up the list of files in diff
view with the 'f' key.  Any equivalent?

Carl

On Mon, Dec 21, 2015 at 4:07 PM, Carl Baldwin  wrote:
> I noticed a couple of things today while reviewing a largish page [1].
> First, when I search for something using the browser's builtin search
> (Chrome, Mac OSX Yosemite), it doesn't seem to find occurrences that
> are not in the visible portion of the page.  For example, when I
> search for DNSDOMAIN, I get 1 hit from the top of the file.  The file
> actually has almost 30 hits for this string.  For example, scroll down
> to about L310 in the file.  You'll see them all over the place (and
> now Chrome's search finds these hits if you try again).  I use to use
> search within a file with the old gerrit and never noticed this
> problem.
>
> The other thing that I found annoying is when I scroll the page with
> my trackpad, it now jumps around sometimes to a different part of the
> page.  For example, I'll scroll up to find a spot in the file and when
> I think I've arrived, it will jump back down the file a bit.  It is
> disorienting.  Of course, now it isn't doing it anymore so it doesn't
> seem to be all the time.  It was behaving this way for a good 20
> minutes trying to get through this file.
>
> Carl
>
> Carl
>
> [1] https://review.openstack.org/#/c/212213/36/neutron/db/dns_db.py
>
> On Thu, Dec 17, 2015 at 8:17 PM, Brian Haley  wrote:
>> On 2015-12-16 16:24, openstack-dev-requ...@lists.openstack.org wrote:
>>>
>>> Thanks to everyone for their patience while we upgraded to Gerrit
>>> 2.11.  I'm happy to announce that we were able to successfully
>>> completed this task at around 21:00 UTC.  You may hack away once more.
>>>
>>> If you encounter any problems, please let us know here or in
>>> #openstack-infra on Freenode.
>>
>>
>> I'm still undecided on 2.11, have to give it more time, but I have noticed
>> one thing that's annoying...
>>
>> Trying to copy text from a review no longer works easily.  When I highlight
>> text there's a little "bubble" pop-up of {press c to comment}, which seems
>> to interfere with both my three-button mouse copy buffer, as well as Ctrl-C.
>> Call me a nitpicker, but having to highlight text, right-button click, Copy,
>> right-button click, Paste, is a pain.
>>
>> Maybe someone has a simple work-around for that.
>>
>> -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

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

Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources

[Hongbin Lu]

Jay,

I think we should agree on a general direction before asking for a spec. It is 
bad to have contributors spend time working on something that might not be 
accepted.

Best regards,
Hongbin

From: Jay Lau [mailto:jay.lau@gmail.com]
Sent: December-20-15 6:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources

Thanks Adrian and Tim, I saw that @Vilobh already uploaded a patch 
https://review.openstack.org/#/c/259201/ here, perhaps we can first have a spec 
and discuss there. ;-)

On Mon, Dec 21, 2015 at 2:44 AM, Tim Bell 
> wrote:
Given the lower level quotas in Heat, Neutron, Nova etc., the error feedback is 
very important. A Magnum “cannot create” message requires a lot of debugging 
whereas a “Floating IP quota exceeded” gives a clear root cause.

Whether we quota Magnum resources or not, some error scenarios and appropriate 
testing+documentation would be a great help for operators.

Tim

From: Adrian Otto 
[mailto:adrian.o...@rackspace.com]
Sent: 20 December 2015 18:50
To: OpenStack Development Mailing List (not for usage questions) 
>

Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources

This sounds like a source-of-truth concern. From my perspective the solution is 
not to create redundant quotas. Simply quota the Magnum resources. Lower level 
limits *could* be queried by magnum prior to acting to CRUD the lower level 
resources. In the case we could check the maximum allowed number of (or access 
rate of) whatever lower level resource before requesting it, and raising an 
understandable error. I see that as an enhancement rather than a must-have. In 
all honesty that feature is probably more complicated than it's worth in terms 
of value.

--
Adrian

On Dec 20, 2015, at 6:36 AM, Jay Lau 
> wrote:
I also have the same concern with Lee, as Magnum depend on HEAT  and HEAT need 
call nova, cinder, neutron to create the Bay resources. But both Nova and 
Cinder has its own quota policy, if we define quota again in Magnum, then how 
to handle the conflict? Another point is that limiting the Bay by quota seems a 
bit coarse-grainded as different bays may have different configuration and 
resource request. Comments? Thanks.

On Thu, Dec 17, 2015 at 4:10 AM, Lee Calcote 
> wrote:
Food for thought - there is a cost to FIPs (in the case of public IP 
addresses), security groups (to a lesser extent, but in terms of the 
computation of many hundreds of them), etc. Administrators may wish to enforce 
quotas on a variety of resources that are direct costs or indirect costs (e.g. 
# of bays, where a bay consists of a number of multi-VM / multi-host pods and 
services, which consume CPU, mem, etc.).

If Magnum quotas are brought forward, they should govern (enforce quota) on 
Magnum-specific constructs only, correct? Resources created by Magnum COEs 
should be governed by existing quota policies governing said resources (e.g. 
Nova and vCPUs).

Lee

On Dec 16, 2015, at 1:56 PM, Tim Bell 
> wrote:

-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com]
Sent: 15 December 2015 22:40
To: openstack-dev 
>
Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum
Resources

Hi! Can I offer a counter point?

Quotas are for _real_ resources.

The CERN container specialist agrees with you ... it would be good to
reflect on the needs given that ironic, neutron and nova are policing the
resource usage. Quotas in the past have been used for things like key pairs
which are not really real.

Memory, CPU, disk, bandwidth. These are all _closely_ tied to things that
cost
real money and cannot be conjured from thin air. As such, the user being
able to allocate 1 billion or 2 containers is not limited by Magnum, but
by real
things that they must pay for. If they have enough Nova quota to allocate
1
billion tiny pods, why would Magnum stop them? Who actually benefits from
that limitation?

So I suggest that you not add any detailed, complicated quota system to
Magnum. If there are real limitations to the implementation that Magnum
has chosen, such as we had in Heat (the entire stack must fit in memory),
then make that the limit. Otherwise, let their vcpu, disk, bandwidth, and
memory quotas be the limit, and enjoy the profit margins that having an
unbound force multiplier like Magnum in your cloud gives you and your
users!

Excerpts from Vilobh Meshram's message of 2015-12-14 16:58:54 -0800:
Hi All,

Currently, it is possible to create unlimited number of resource like
bay/pod/service/. In Magnum, there should be a 

[openstack-dev] [puppet] deprecation warning everywhere issue

[Emilien Macchi]

Hello,

I just reported [1] which affects puppet-keystone but also *all* modules.
Since [2], you now have a lot of warnings about the new way to declare
keystone_endpoint resource.

This is not really acceptable and provides a poor end-user experience to
have (by default) a lot of warnings.

The patch that will fix it in puppet-keystone is [3] (please review it).
To fix all other modules, we need to update unit tests and sometimes
keystone/auth.pp in the module. It will requires a Depends-On the
puppet-keystone patch, which means puppet-keystone patch will fail
integration tests (circular dependency). Ex with [4] (puppet-glance)

So here is the plan:
* let's review [3] but do not merge it.
* let's review [4] and other that will follow (on same Gerrit topic).
* Once all patches have been submitted, I'll send a patch to
puppet-openstack-integration with Depends-On of all other patches and
see Integration testing, so we don't break our CI.

You can follow all this work on the "endpoint/warnings" Gerrit topic [5].

Any other suggestion is welcome,
Please review,

[1] https://bugs.launchpad.net/puppet-keystone/+bug/1528308
[2]
http://git.openstack.org/cgit/openstack/puppet-keystone/commit/?id=0a4e06abb0f5b3f324464ff5219d2885816311ce
[3] https://review.openstack.org/#/c/259996/
[4] https://review.openstack.org/#/c/260044/
[5] https://review.openstack.org/#/q/topic:endpoint/warnings
-- 
Emilien Macchi



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

Re: [openstack-dev] [puppet] deprecation warning everywhere issue

[Emilien Macchi]

On 12/21/2015 06:48 PM, Emilien Macchi wrote:
> Hello,
> 
> I just reported [1] which affects puppet-keystone but also *all* modules.
> Since [2], you now have a lot of warnings about the new way to declare
> keystone_endpoint resource.
> 
> This is not really acceptable and provides a poor end-user experience to
> have (by default) a lot of warnings.
> 
> The patch that will fix it in puppet-keystone is [3] (please review it).
> To fix all other modules, we need to update unit tests and sometimes
> keystone/auth.pp in the module. It will requires a Depends-On the
> puppet-keystone patch, which means puppet-keystone patch will fail
> integration tests (circular dependency). Ex with [4] (puppet-glance)
> 
> So here is the plan:
> * let's review [3] but do not merge it.
> * let's review [4] and other that will follow (on same Gerrit topic).
> * Once all patches have been submitted, I'll send a patch to
> puppet-openstack-integration with Depends-On of all other patches and
> see Integration testing, so we don't break our CI.
> 
> You can follow all this work on the "endpoint/warnings" Gerrit topic [5].

Err: https://review.openstack.org/#/q/topic:bug/1528308

> Any other suggestion is welcome,
> Please review,
> 
> [1] https://bugs.launchpad.net/puppet-keystone/+bug/1528308
> [2]
> http://git.openstack.org/cgit/openstack/puppet-keystone/commit/?id=0a4e06abb0f5b3f324464ff5219d2885816311ce
> [3] https://review.openstack.org/#/c/259996/
> [4] https://review.openstack.org/#/c/260044/
> [5] https://review.openstack.org/#/q/topic:endpoint/warnings
> 
> 
> 
> __
> 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
> 

-- 
Emilien Macchi



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

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Lukasz Oles]

On Mon, Dec 21, 2015 at 1:43 PM, Igor Kalnitsky  wrote:
> What about hypervisor "Qemu", and checkbox option on Settings tab -
> "Use KVM extension"?
Qemu is not a hypervisor This will be even more confusing.
I think "Libvirt" + some tooltip which says "Qemu and KVM" will be ok.

Regarfs


>
> On Mon, Dec 21, 2015 at 1:22 PM, Andrey Danin  wrote:
>> Hi,
>>
>> Let's call this hypervisor type "Qemu-KVM". So it will be a separate HV like
>> vCenter, Xen, or HyperV. The actual selection between qemu and kvm will be a
>> HV specific option in this case.
>>
>> On Mon, Dec 21, 2015 at 1:24 PM, Igor Kalnitsky 
>> wrote:
>>>
>>> Hello,
>>>
>>> Agree with Kevin. libvirt itself isn't a hypervisor. It's an API (or
>>> single entry point) for dealing with other hypervisors, including qemu
>>> and kvm.
>>>
>>> So it's kinda confusing, I'd prefer to find another solution.
>>>
>>> Thanks,
>>> Igor
>>>
>>> On Fri, Dec 18, 2015 at 7:24 PM, Fox, Kevin M  wrote:
>>> > I think it may be confusing to a fair number of the users you are
>>> > targeting.
>>> > libvirt supports more then just qemu/kvm. xen, virtualbox, and others.
>>> > saying libvirt makes people have to know that when you say libvirt you
>>> > mean
>>> > just the qemu/kvm that nova supports using the implementation detail of
>>> > using libvirt.
>>> >
>>> > Thanks,
>>> > Kevin
>>> > 
>>> > From: Aleksandr Didenko [adide...@mirantis.com]
>>> > Sent: Friday, December 18, 2015 4:16 AM
>>> > To: OpenStack Development Mailing List (not for usage questions)
>>> > Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt
>>> > on
>>> > Wizard
>>> >
>>> > Hi,
>>> >
>>> > looks good to me.
>>> >
>>> > Regards,
>>> > Alex
>>> >
>>> > On Fri, Dec 18, 2015 at 10:17 AM, Andriy Popovych
>>> > 
>>> > wrote:
>>> >>
>>> >> Hi fuelers,
>>> >>
>>> >> We want to throw KVM/QEMU options from Wizard and instead of them leave
>>> >> only one: Libvirt [0]. Libvirt option enables QEMU by default and there
>>> >> are
>>> >> still be possibility to change it on KVM in settings. It looks more
>>> >> logically because both QEMU\KVM are options for libvirt which manage
>>> >> them.
>>> >>
>>> >> What are you think about it?
>>> >>
>>> >> [0] https://review.openstack.org/#/c/258690
>>> >>
>>> >>
>>> >> __
>>> >> OpenStack Development Mailing List (not for usage questions)
>>> >> Unsubscribe:
>>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >>
>>> >
>>> >
>>> >
>>> > __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>> Andrey Danin
>> ada...@mirantis.com
>> skype: gcon.monolake
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Łukasz Oleś

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

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Bob Ball]

> On Mon, Dec 21, 2015 at 1:43 PM, Igor Kalnitsky 
> wrote:
> > What about hypervisor "Qemu", and checkbox option on Settings tab -
> > "Use KVM extension"?
> Qemu is not a hypervisor This will be even more confusing.
> I think "Libvirt" + some tooltip which says "Qemu and KVM" will be ok.

Libvirt isn't a hypervisor either.  Note that Xen, Virtuozzo CT, Virtuozzo VM, 
LXC and KVM on ppc64 and s390x are all valid hypervisors to use with Libvirt 
and OpenStack (taken from 
http://docs.openstack.org/developer/nova/support-matrix.html)

Bob
 
__
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] [Ceilometer][Gnocchi] inconsistent instanceattributes cause infinite update

[gord chung]

shall we try to synchronise the two datapoints more than? i think that'd 
be the better route since pollster and notification values are 
attempting to meter the same thing.


On 21/12/2015 8:33 AM, Luo Gangyi wrote:

gord, I have looked your link, seems related.
But still, image_ref is a problem.


--
gord


__
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] [ThirdParty][CI] [patch] Status page at http://ci-watch.tintri.com/project

[Philipp Marek]

Hi all,

I quite like the page at http://ci-watch.tintri.com/project - it gives 
a very quick overview about the failures one should look into, and which to 
ignore ;)


Please let me state before anything else that I don't know any of the 
restrictions that may have led into the current design - it's very likely 
that I'm just missing a few points, and that some or all of my comments 
below are invalid anyway. As always, take enough salt!


One thing about that page that is bothering me is the performance... my 
(current) Firefox asks me several times whether I'd like to stop the JS,
or whether it should be allowed to continue.

With this patch (and a local exported copy of the page) I don't get asked 
about that any more; it seems to give me a speedup of ~200, as no 
intermediate lists need to be built and filtered any more:

$ diff -u verified.js.orig verified.js
--- verified.js.orig2015-12-21 15:03:45.614529924 +0100
+++ verified.js 2015-12-21 15:03:36.114432601 +0100
@@ -33,9 +33,9 @@
 $(document).ready(function () {
   $("colgroup").each(function (i, elem) {
 if ($(elem).hasClass("verified-1")) {
-  $("#results").find("td").filter(":nth-child(" + (i + 1) + 
")").addClass("verified-1");
+  $("#results td:nth-child(" + (i + 1) + ")").addClass("verified-1");
 } else if ($(elem).hasClass("verified1")) {
-  $("#results").find("td").filter(":nth-child(" + (i + 1) + 
")").addClass("verified1");
+  $("#results td:nth-child(" + (i + 1) + ")").addClass("verified1");
 }
   });
   $("#verified1-button").on("click", toggle_verified_plus);


Furthermore, I'm wondering whether







couldn't be simplified to






with the rest being done via CSS? Perhaps a  would be needed within 
the  to get the vertical size right, but everything else should be 
possible via CSS, I believe.

This change should reduce the size of the generated HTML big some 50% or 
so, too.



Thanks for listening - if you disagree, please ignore and continue working 
on something else ;)


Regards,

Phil


__
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] [Kuryr] IRC Meeting - Monday 1500 UTC (#openstack-meeting-4)

[Gal Sagie]

Hello All,

I have updated the agenda for the upcoming Kuryr IRC meeting [1]
Please review and add any additional topics you might want to cover.

Last meeting action items can be seen here [2]

I personally wont be able to attend the meeting and we expect low
participant volume
due to holidays but apuimedo still suppose to come :)

[1] https://wiki.openstack.org/wiki/Meetings/Kuryr
[2]
http://eavesdrop.openstack.org/meetings/kuryr/2015/kuryr.2015-12-15-03.00.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Igor Kalnitsky]

> Qemu is not a hypervisor This will be even more confusing.

It looks like hypervisor much more than libvirt. Moreover, according
to Wikipedia [1] (don't blame me guys) Qemu is Type-2 hypervisor.

[1] https://en.wikipedia.org/wiki/Hypervisor

> Today, when a user selects KVM, Fuel attempts to use KVM acceleration and
> defaults to QEMU in the case that KVM acceleration is not possible.

Sheena, are you sure it works this way? Some time ago we didn't
support this. However, I fully support this idea and believe this is
the way to go. In this case the hypervisor entry could be called
something like  "Qemu (+ KVM if available)".


On Mon, Dec 21, 2015 at 4:04 PM, Sheena Gregson  wrote:
> We should collapse this into one entry - I don't have any preference on
> the naming convention, but as Fuel checks to see whether the hardware is
> capable of performing KVM acceleration, there's no reason to continue
> giving a selection to the user regarding KVM.
>
> Today, when a user selects KVM, Fuel attempts to use KVM acceleration and
> defaults to QEMU in the case that KVM acceleration is not possible.  We
> should keep this behavior and make the entry a single KVM/QEMU selection
> to eliminate the false perception of choice (and the ability for users to
> select the incorrect option).
>
> -Original Message-
> From: Bob Ball [mailto:bob.b...@citrix.com]
> Sent: Monday, December 21, 2015 7:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt
> on Wizard
>
>> On Mon, Dec 21, 2015 at 1:43 PM, Igor Kalnitsky
>> 
>> wrote:
>> > What about hypervisor "Qemu", and checkbox option on Settings tab -
>> > "Use KVM extension"?
>> Qemu is not a hypervisor This will be even more confusing.
>> I think "Libvirt" + some tooltip which says "Qemu and KVM" will be ok.
>
> Libvirt isn't a hypervisor either.  Note that Xen, Virtuozzo CT, Virtuozzo
> VM, LXC and KVM on ppc64 and s390x are all valid hypervisors to use with
> Libvirt and OpenStack (taken from
> http://docs.openstack.org/developer/nova/support-matrix.html)
>
> Bob
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

[Evgeniy L]

Hi Oleg,

I understand the concern, but in case of integration specifically with
Solar,
I don't see any reasons to add ConfigDB, because Solar by itself is a
ConfigDB.
At the same time I would agree that there might be a case, when user uses
Zookeeper/Puppet Master/CMDB as a data store, in this case we should store
the data directly in those services, without keeping them in yet another
storage.

So the flow will look like this:
Components ->
Data get polled by data processors ->
| Solar data processor puts the data into Solar in its format
| Zookeeper data processor puts the data into Zookeeper in its format
| Custom CMDB data processor puts the data into CMDB in its own format

Thanks,

On Fri, Dec 18, 2015 at 7:00 PM, Oleg Gelbukh  wrote:

> Hi,
>
> The idea behind configdb is that it is independent component that defines
> data flows between other components of the system. It has no knowledge
> about those components or specifics of their data. Data formats are defined
> by components themselves via schemas/templates and can be changed at any
> time (i.e. don't require code changes).
>
> Important 'pro' having ConfigDB separate from Solar is that it will
> simplify transition from current Fuel architecture by breaking it into more
> definite stages and reducing the number of components Solar have to be
> integrated with.
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Wed, Dec 16, 2015 at 4:38 PM, Evgeniy L  wrote:
>
>> Hi Dmitry,
>>
>> I also don't think that we should duplicate the data in configdb,
>> because in this case there will be +2 additional interfaces which
>> will require to covert the data into configdb and after that from
>> configdb to Solar, which seems redundant overhead.
>>
>> But we should be able to put the data directly to user's
>> CMDB/ZooKeeper/Puppet Master/etc.
>>
>> Thanks,
>>
>> On Wed, Dec 16, 2015 at 2:03 AM, Dmitriy Shulyak 
>> wrote:
>>
>>> Hello folks,
>>>
>>> This topic is about configuration storage which will connect data
>>> sources (nailgun/bareon/others) and orchestration. And right now we are
>>> developing two projects that will overlap a bit.
>>>
>>> I understand there is not enough context to dive into this thread right
>>> away, but i will appreciate if those people, who participated in design,
>>> will add their opinions/clarifications on this matter.
>>>
>>> Main disagreements
>>> ---
>>> 1. configdb should be passive, writing to configdb is someone else
>>> responsibility
>>> + simpler implementation, easier to use
>>> - we will need another component that will do writing, or split this
>>> responsibility somehow
>>>
>>> 2. can be used without other solar components
>>> + clear inteface between solar components and storage layer
>>> - additional work required to design/refactor communication layer
>>> between modules in solar
>>> - some data will be duplicated between solar orchestrator layer and
>>> configdb
>>>
>>> 3. templates for output
>>> technical detail, can be added on top of solardb if required
>>>
>>> Similar functionality
>>> --
>>> 1. Hierachical storage
>>> 2. Versioning of changes
>>> 3. Possibility to overwrite config values
>>> 4. Schema for inputs
>>>
>>> Overall it seems that we share same goals for both services,
>>> the difference lies in organizational and technical implementation
>>> details.
>>>
>>> Possible solutions
>>> 
>>> 1. develop configdb and solar with duplicated functionality
>>> - at least 2 additional components will be added to the picture,
>>> one is configdb, another one will need to sync data between configdb and
>>> solar
>>> - in some cases data in solar and configdb will be 100% duplicated
>>> - different teams will work on same functionality
>>> - integration of additional component for fuel will require integration
>>> with
>>> configdb and with solar
>>> + configdb will be independent from solar orchestration/other components
>>>
>>> 2. make service out of solardb, allign with configdb use cases
>>> + solardb will be independent from solar orchestration/other solar
>>> components
>>> + integration of fuel component will be easier than in 1st version
>>> + clarity about components responsibility and new architecture
>>> - redesign/refactoring communication between components in solar
>>>
>>> 3. do not use configdb/no extraction of solardb
>>> - inproc communication, which can lead to coupled components (not the
>>> case currently)
>>> + faster implementation (no major changes required for integration with
>>> fuel)
>>> + clarity about components responsibility and new architecture
>>>
>>> Summary
>>> -
>>> For solar it makes no difference where data will come from: configdb or
>>> data sources, but in overall fuel architecture it will lead to
>>> significant
>>> complexity increase.
>>> It would be the best to follow 2nd path, because in long term we don't
>>> want 

Re: [openstack-dev] [tripleo] Pin some puppet dependencies on git clone

[Jaume Devesa]

My bet is first solve the problem, and then discuss how to improve the
solution.

Specifying the DIB_REPOREF variables by hand on the puppet-module element
in t-p-e will be an immediate
improvement in stability terms.

Then, it is fair to discuss how to automate the process to syncrhonise with
puppet-openstack dependencies.

Regards,


On 16 December 2015 at 16:40, Jiří Stránský  wrote:

> On 15.12.2015 19:12, Emilien Macchi wrote:
>
>>
>>
>> On 12/15/2015 12:23 PM, Jiří Stránský wrote:
>>
>>> On 15.12.2015 17:46, Emilien Macchi wrote:
>>>
 For information, Puppet OpenStack CI is consistent for unit & functional
 tests, we use a single (versionned) Puppetfile:

 https://github.com/openstack/puppet-openstack-integration/blob/master/Puppetfile


 TripleO folks might want to have a look at this to follow the
 dependencies actually supported by upstream OR if you prefer surfing on
 the edge and risk to break CI every morning.

 Let me know if you're interested to support that in TripleO Puppet
 elements, I can help with that.

>>>
>>> Syncing tripleo-puppet-elements with puppet-openstack-integration is a
>>> good idea i think, to prevent breakages like the puppet-mysql one
>>> mentioned before.
>>>
>>> One thing to keep in mind is that the module sets in t-p-e and p-o-i are
>>> not the same. E.g. recently we added the timezone module to t-p-e, and
>>> it's not in the p-o-i Puppetfile.
>>>
>>> Also, sometimes we do have to go to non-openstack puppet modules to fix
>>> things for TripleO (i don't recall a particular example but i think we
>>> did a couple of fixes in non-openstack modules to allow us to deploy HA
>>> with Pacemaker). In cases like this it would be helpful if we still had
>>> the possibility to pin to something different than what's in
>>> puppet-openstack-integration perhaps.
>>>
>>>
>>> Considering the above, if we could figure out a way to have t-p-e behave
>>> like this:
>>>
>>> * install the module set listed in t-p-e, not p-o-i.
>>>
>>> * if there's a ref/branch specified directly in t-p-e, use that
>>>
>>> * if t-p-e doesn't have a ref/branch specified, use ref/branch from p-o-i
>>>
>>> * if t-p-e doesn't have a ref/branch specified, and the module is not
>>> present in p-o-i, use master
>>>
>>> * still honor DIB_REPOREF_* variables to pin individual puppet modules
>>> to whatever wanted at time of building the image -- very useful for
>>> temporary workarounds done either manually or in tripleo.sh.
>>>
>>> ...then i think this would be very useful. Not sure at the moment what
>>> would be the best way to meet these points though, these are just some
>>> immediate thoughts on the matter.
>>>
>>
>> I think we shout not use puppet-openstack-integration per-se, it was
>> just an example.
>>
>> Though we can take this project as reference to build a tool that
>> prepare Puppet modules in TripleO CI.
>>
>> If you look at puppet-openstack-integration, we have some scripts that
>> allow or not to use zuul-cloner with r10k, that's nice because it allows
>> us to:
>> * use depends-on puppet patches
>> * if the end-user does not have zuul, it will git-clone, in tripleo case
>> I think if DIB_REPOREF_* is set, let's use it
>> * otherwise use git clone master.
>>
>> I would suggest also TripleO CI having a Puppetfile that would be gated
>> (maybe in tripleo-ci repo?).
>>
>
> We should probably put the pins somewhere else than tripleo-ci, because
> we'd want dev environments to use the pinned versions too. Perhaps t-p-e is
> the right place.
>
> The more i think about this the more i like the approach in Dan's patch --
> an extra element which will pin modules the DIB way. What we're lacking
> here is a tool which could take a Puppetfile (specifically the Puppetfile
> from puppet-openstack-integration) and produce the DIB_REPOREF variables
> (perhaps ignoring all :ref => 'master' ones), so that we don't have to
> track and update them by hand.
>
> I'm not sure if we absolutely need a Puppetfile for TripleO. The value
> added is more in the pins themselves, not so much in syntax (Puppetfile vs.
> DIB-style-file). We could use Puppetfile format too, but since we'll not be
> able to use the one from puppet-openstack-integration directly (it's a
> different set of modules), i don't see much value in switching over.
>
> Jirka
>
>
>
>> What do you think?
>>
>>
>>> Jirka
>>>
>>>
 On 12/14/2015 02:25 PM, Dan Prince wrote:

> On Fri, 2015-12-11 at 21:50 +0100, Jaume Devesa wrote:
>
>> Hi all,
>>
>> Today TripleO CI jobs failed because a new commit introduced on
>> puppetlabs-mysql[1].
>> Mr. Jiri Stransky solved it as a temporally fix by pinning the puppet
>> module clone to a previous
>> commit in the tripleo-common project[2].
>>
>> source-repositories puppet element[3] allows you to pin the puppet
>> module clone as well by
>> adding a reference commit in the source-repository-

Re: [openstack-dev] [Fuel] Nominate Bulat Gaifulin for fuel-web & fuel-mirror cores

[Bulat Gaifullin]

Thank you.

Regards,
Bulat Gaifullin
Mirantis Inc.



> On 21 Dec 2015, at 13:11, Igor Kalnitsky  wrote:
> 
> Well, the agreement is reached. I added Bulat to both fuel-web-core
> and fuel-mirror-core groups.
> 
> Bulat, congratulations! Will be happy to see even more thorough
> reviews from you!
> 
> On Tue, Dec 15, 2015 at 11:49 AM, Evgeniy L  wrote:
>> +1
>> 
>> On Tue, Dec 15, 2015 at 12:33 PM, Anastasia Urlapova
>>  wrote:
>>> 
>>> +1
>>> 
>>> On Mon, Dec 14, 2015 at 3:20 PM, Roman Vyalov 
>>> wrote:
 
 +1
 
 On Mon, Dec 14, 2015 at 3:05 PM, Aleksey Kasatkin
  wrote:
> 
> +1.
> 
> 
> Aleksey Kasatkin
> 
> 
> On Mon, Dec 14, 2015 at 12:49 PM, Vladimir Sharshov
>  wrote:
>> 
>> Hi,
>> 
>> +1 from me to Bulat.
>> 
>> On Mon, Dec 14, 2015 at 1:03 PM, Igor Kalnitsky
>>  wrote:
>>> 
>>> Hi Fuelers,
>>> 
>>> I'd like to nominate Bulat Gaifulin [1] for
>>> 
>>> * fuel-web-core [2]
>>> * fuel-mirror-core [3]
>>> 
>>> Bulat's doing a really good review with detailed feedback and he's a
>>> regular participant in IRC. He's co-author of packetary and
>>> fuel-mirror projects, and he made valuable contribution to fuel-web
>>> (e.g. task-based deployment engine).
>>> 
>>> Fuel Cores, please reply back with +1/-1.
>>> 
>>> - Igor
>>> 
>>> [1] http://stackalytics.com/?module=fuel-web_id=bgaifullin
>>> [2] http://stackalytics.com/report/contribution/fuel-web/90
>>> [3] http://stackalytics.com/report/contribution/fuel-mirror/90
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

[Oleg Gelbukh]

The problem with this approach is that we can't manage the interfaces
between components without changing the code of 2+ components (i.e. one
that provides the data and all that consume it).

I also don't like polling model for data processors. In my understanding,
components should push their changes through the pipeline. Although this is
pure implementation detail and is not really important ATM.

The point is that for Solar integration, we still need integration points,
and the less of them we have, the more simple the transition is going to
be..

--
Best regards,
Oleg Gelbukh

On Mon, Dec 21, 2015 at 11:32 AM, Evgeniy L  wrote:

> Hi Oleg,
>
> I understand the concern, but in case of integration specifically with
> Solar,
> I don't see any reasons to add ConfigDB, because Solar by itself is a
> ConfigDB.
> At the same time I would agree that there might be a case, when user uses
> Zookeeper/Puppet Master/CMDB as a data store, in this case we should store
> the data directly in those services, without keeping them in yet another
> storage.
>
> So the flow will look like this:
> Components ->
> Data get polled by data processors ->
> | Solar data processor puts the data into Solar in its format
> | Zookeeper data processor puts the data into Zookeeper in its format
> | Custom CMDB data processor puts the data into CMDB in its own format
>
> Thanks,
>
> On Fri, Dec 18, 2015 at 7:00 PM, Oleg Gelbukh 
> wrote:
>
>> Hi,
>>
>> The idea behind configdb is that it is independent component that defines
>> data flows between other components of the system. It has no knowledge
>> about those components or specifics of their data. Data formats are defined
>> by components themselves via schemas/templates and can be changed at any
>> time (i.e. don't require code changes).
>>
>> Important 'pro' having ConfigDB separate from Solar is that it will
>> simplify transition from current Fuel architecture by breaking it into more
>> definite stages and reducing the number of components Solar have to be
>> integrated with.
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Wed, Dec 16, 2015 at 4:38 PM, Evgeniy L  wrote:
>>
>>> Hi Dmitry,
>>>
>>> I also don't think that we should duplicate the data in configdb,
>>> because in this case there will be +2 additional interfaces which
>>> will require to covert the data into configdb and after that from
>>> configdb to Solar, which seems redundant overhead.
>>>
>>> But we should be able to put the data directly to user's
>>> CMDB/ZooKeeper/Puppet Master/etc.
>>>
>>> Thanks,
>>>
>>> On Wed, Dec 16, 2015 at 2:03 AM, Dmitriy Shulyak 
>>> wrote:
>>>
 Hello folks,

 This topic is about configuration storage which will connect data
 sources (nailgun/bareon/others) and orchestration. And right now we are
 developing two projects that will overlap a bit.

 I understand there is not enough context to dive into this thread right
 away, but i will appreciate if those people, who participated in design,
 will add their opinions/clarifications on this matter.

 Main disagreements
 ---
 1. configdb should be passive, writing to configdb is someone else
 responsibility
 + simpler implementation, easier to use
 - we will need another component that will do writing, or split this
 responsibility somehow

 2. can be used without other solar components
 + clear inteface between solar components and storage layer
 - additional work required to design/refactor communication layer
 between modules in solar
 - some data will be duplicated between solar orchestrator layer and
 configdb

 3. templates for output
 technical detail, can be added on top of solardb if required

 Similar functionality
 --
 1. Hierachical storage
 2. Versioning of changes
 3. Possibility to overwrite config values
 4. Schema for inputs

 Overall it seems that we share same goals for both services,
 the difference lies in organizational and technical implementation
 details.

 Possible solutions
 
 1. develop configdb and solar with duplicated functionality
 - at least 2 additional components will be added to the picture,
 one is configdb, another one will need to sync data between configdb
 and solar
 - in some cases data in solar and configdb will be 100% duplicated
 - different teams will work on same functionality
 - integration of additional component for fuel will require integration
 with
 configdb and with solar
 + configdb will be independent from solar orchestration/other components

 2. make service out of solardb, allign with configdb use cases
 + solardb will be independent from solar orchestration/other solar
 components
 + integration of 

Re: [openstack-dev] [Ceilometer][Gnocchi] inconsistentinstanceattributes cause infinite update

[Luo Gangyi]

Yes, it will be better if we can synchronise them.
  
 But to achieve this, we have to do some modification in nova side which seems 
not easy :( 
  
  --
 Luo Gangyi   luogan...@cmss.chinamobile.com



  
  

 

 -- Original --
  From:  "gord chung";;
 Date:  Mon, Dec 21, 2015 10:17 PM
 To:  "openstack-dev"; 
 
 Subject:  Re: [openstack-dev] [Ceilometer][Gnocchi] 
inconsistentinstanceattributes cause infinite update

 

shall we try to synchronise the two datapoints more than? i think that'd 
be the better route since pollster and notification values are 
attempting to meter the same thing.

On 21/12/2015 8:33 AM, Luo Gangyi wrote:
> gord, I have looked your link, seems related.
> But still, image_ref is a problem.

-- 
gord


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

[openstack-dev] tacker

[Demo]

dear you??
I have installed tacker in my ubuntu system,and  binded to an openstack 
instance ,but I did't find the way to add an VNFD  in tacker.  using this 
command," tacker vnfd-create --name ${VNFD_NAME}  --vnfd-file 
${VNFD_TOSCA_YAML-FILE}"  where should I place the YAML  file.  further,I want 
to set up the whole system,including tacker and  openstack, I am confused How 
to make tacker perform in right way. such  as ,create VDU , minitor VM.sorry 
for my poor English and bad  logical.appriciate your reply.

   a tacker learner

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

Re: [openstack-dev] [Infra][nova][magnum] Jenkins failed quite often for "Cannot set up guest memory 'pc.ram': Cannot allocate memory"

[Jeremy Stanley]

On 2015-12-20 12:35:34 -0800 (-0800), Clark Boylan wrote:
> Looking at the dstat logs for a recent fail [0], it did help in that
> more memory is available. You now have over 1GB available but still less
> than 2GB.
[...]

As Clark also pointed out in IRC, the workers where this is failing
lack a swap memory device. I have a feeling if you swapoff before
this point in the job you'll see it fail everywhere.

For consistency, we probably should make sure that our workers have
similarly sized swap devices (using a swapfile on the rootfs if
necessary).
-- 
Jeremy Stanley

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

[openstack-dev] [TripleO] tripleoclient/tripleo-common backwards compatibility

[Steven Hardy]

Hi all,

So I've recently had several discussions related to $subject.

In summary - there's a requirement to enable underclouds to support
deploying/updating previous versions of OpenStack overclouds.

So, say I upgrade my liberty undercloud to master/mitaka, I'd like to
ensure the following is possible:

1. Maintain any existing (liberty) overcloud without being forced to
immediately upgrade to Mitaka (updating the undercloud can pull in features
required to enable this upgrade however).

2. Deploy a new overcloud, with the choice between either liberty or mitaka

This has some implications related to distributing tripleo-heat-templates
(need to allow for packaging to either install both versions of t-h-t, or
always install all versions via one package), and then there are related
requirements related to tripleoclient (and potentially tripleo-common), so
we maintain backwards compatiblity wrt overcloud deployment/update.

So, some questions:

- Do we actually want stable branches for tripleoclient (or even
  tripleo-common?) if we have to maintain backwards compatibility?

- Can we add features to tripleoclient now, to make it easier to
  pre-configure known locations for specific releases (this should be
  configurable via a config file IMO, not hard-coded)?

- How might we effectively test this in CI?  Have a job which deploys e.g
  a stable/liberty overcloud with a master undercloud?

- How hard would it be to wire in image-building for a previous release
  (Mitaka/master undercloud building liberty overcloud-full) - would it be
  reasonable to assume existing images and say the undercloud only supports
  building images for one release version?

Thoughts and feedback and volunteers appreciated, thanks!

Steve

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

Re: [openstack-dev] [Ceilometer][Gnocchi] inconsistent instanceattributes cause infinite update

[Luo Gangyi]

@gord, I have looked your link, seems related. 
  
 But still, image_ref is a problem.
  
  --
 Luo Gangyi   luogan...@cmss.chinamobile.com



  
  

 

 -- Original --
  From:  "gord chung";;
 Date:  Mon, Dec 21, 2015 09:12 PM
 To:  "openstack-dev"; 
 
 Subject:  Re: [openstack-dev] [Ceilometer][Gnocchi] inconsistent 
instanceattributes cause infinite update

 

we actually looked at this problem here: 
https://review.openstack.org/#/c/235702/

i think we should add support of new attribute instead.

 On 20/12/2015 10:52 AM, Luo Gangyi wrote:

  Hi devs,
  
 I found a problem which may cause infinite update of instance's attributes in 
gnocchi.
  
 Let's see the resource definition of instance.
  
   - resource_type: instance
metrics:
  - 'instance'
  - 'memory'
  - 'memory.usage'
  - 'memory.resident'
  - 'vcpus'
  - 'cpu'
  - 'cpu_util'
  - 'disk.root.size'
 ...
 attributes:
  host: resource_metadata.host
  image_ref: resource_metadata.image_ref_url
 ...

 Here is the problem, although they have same  attributes, they are *not* same.
  
 Some of them came from nova's notifications and the others are came from 
ceilometer-compute-agent.
  
 1) Those came from notifications, their attributes looks like
  
 image_ref :http://10.133.12.125:9292/images/  
 host: compute.lgy-openstack-kilo.novalocal 
  
 2) Those came from ceilometer-compute-agent, 
 image_ref : 
http://10.133.12.125:8774/4994e42421a04beda56fff7d817e810e/images/8d6a9cd9-48ae-4a41-bd13-262a46c93d72
 
 host:ea8f8e465d9caff06e80a0fda6f30d02725e0b55dc0fd940954cb55c
  
 Such difference will cause alternately and infinitely update of a instance's 
attributes if we enable nova audit.
  
 So I suggest we seperate these meters which came from notifications to another 
resource type like "instance_from_notification".
  
 Any other idea?
 
 
  --
 Luo Gangyi   luogan...@chinamobile.com



  

  
__ 
OpenStack Development Mailing List (not for usage questions) Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
--  gord__
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] [telemetry] cancelling upcoming meetings (24th and 31st)

[gord chung]

hi folks,

before i forget, we'll be skipping meetings the next two weeks (24th and 
31st).  we'll resume regularly scheduled meetings on Jan 7th.


please raise anything important to the mailing list (as normal).

have a nice holidays.

cheers,

--
gord


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

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Sheena Gregson]

We should collapse this into one entry - I don't have any preference on
the naming convention, but as Fuel checks to see whether the hardware is
capable of performing KVM acceleration, there's no reason to continue
giving a selection to the user regarding KVM.

Today, when a user selects KVM, Fuel attempts to use KVM acceleration and
defaults to QEMU in the case that KVM acceleration is not possible.  We
should keep this behavior and make the entry a single KVM/QEMU selection
to eliminate the false perception of choice (and the ability for users to
select the incorrect option).

-Original Message-
From: Bob Ball [mailto:bob.b...@citrix.com]
Sent: Monday, December 21, 2015 7:32 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt
on Wizard

> On Mon, Dec 21, 2015 at 1:43 PM, Igor Kalnitsky
> 
> wrote:
> > What about hypervisor "Qemu", and checkbox option on Settings tab -
> > "Use KVM extension"?
> Qemu is not a hypervisor This will be even more confusing.
> I think "Libvirt" + some tooltip which says "Qemu and KVM" will be ok.

Libvirt isn't a hypervisor either.  Note that Xen, Virtuozzo CT, Virtuozzo
VM, LXC and KVM on ppc64 and s390x are all valid hypervisors to use with
Libvirt and OpenStack (taken from
http://docs.openstack.org/developer/nova/support-matrix.html)

Bob

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

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

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Sheena Gregson]

According to Andrew Woodward (xarses), this is the current implementation.


-Original Message-
From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com]
Sent: Monday, December 21, 2015 8:23 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt
on Wizard

> Qemu is not a hypervisor This will be even more confusing.

It looks like hypervisor much more than libvirt. Moreover, according to
Wikipedia [1] (don't blame me guys) Qemu is Type-2 hypervisor.

[1] https://en.wikipedia.org/wiki/Hypervisor

> Today, when a user selects KVM, Fuel attempts to use KVM acceleration
> and defaults to QEMU in the case that KVM acceleration is not possible.

Sheena, are you sure it works this way? Some time ago we didn't support
this. However, I fully support this idea and believe this is the way to
go. In this case the hypervisor entry could be called something like
"Qemu (+ KVM if available)".


On Mon, Dec 21, 2015 at 4:04 PM, Sheena Gregson 
wrote:
> We should collapse this into one entry - I don't have any preference
> on the naming convention, but as Fuel checks to see whether the
> hardware is capable of performing KVM acceleration, there's no reason
> to continue giving a selection to the user regarding KVM.
>
> Today, when a user selects KVM, Fuel attempts to use KVM acceleration
> and defaults to QEMU in the case that KVM acceleration is not
> possible.  We should keep this behavior and make the entry a single
> KVM/QEMU selection to eliminate the false perception of choice (and
> the ability for users to select the incorrect option).
>
> -Original Message-
> From: Bob Ball [mailto:bob.b...@citrix.com]
> Sent: Monday, December 21, 2015 7:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave
> Libvirt on Wizard
>
>> On Mon, Dec 21, 2015 at 1:43 PM, Igor Kalnitsky
>> 
>> wrote:
>> > What about hypervisor "Qemu", and checkbox option on Settings tab -
>> > "Use KVM extension"?
>> Qemu is not a hypervisor This will be even more confusing.
>> I think "Libvirt" + some tooltip which says "Qemu and KVM" will be ok.
>
> Libvirt isn't a hypervisor either.  Note that Xen, Virtuozzo CT,
> Virtuozzo VM, LXC and KVM on ppc64 and s390x are all valid hypervisors
> to use with Libvirt and OpenStack (taken from
> http://docs.openstack.org/developer/nova/support-matrix.html)
>
> Bob
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

[openstack-dev] [Cinder][DRBD] questions about pep8/flake8 etc.

[Philipp Marek]

Hi everybody,

in the current patch https://review.openstack.org/#/c/259973/1 the test 
script needs to use a lot of the constant definitions of the backend driver 
it's using (DRBDmanage).

As the DRBDmanage libraries need not be installed on the CI nodes, I'm 
providing a minimum of upstream files, accumulated in a separate directory 
- they get imported and "fixed" to the expected location, so that the 
driver that should be tested runs as if DRBDmanage is installed.


My problem is now that the upstream project doesn't accept all the pep8 
conventions like Openstack does; so the CI run 

http://logs.openstack.org/73/259973/1/check/gate-cinder-pep8/5032b16/console.html
 
gives a lot of messages like "E221 multiple spaces before operator" and 
similar. (It even crashes during AST parsing ;)


So, I can see these options now:

  * Make pep8 ignore these files - they're only used by one test script,
and are never used in production anyway.
+ Simple
+ New upstream files can simply be dropped in as needed
- bad example?
  
  * Reformat the files to conform to pep8
- some work for every new version that needs to be incorporated
- can't be compared for equality with upstream any more
- might result in mismatches later on, ie. production code uses
  different values from test code

  * Throw upstream files away, and do "manual" fakes
- A lot of work
- Work needed for every new needed constant
- lots of duplicated code
- might result in mismatches later on, ie. production code uses
  different values from test code
+ whole checkout still "clean" for pep8

  * Require DRBDmanage to be installed
+ uses same values as upstream and production
- Need to get it upstream into PyPi
- Meaning delay
- delay for every new release of DRBDmanage
- Might not even be compatible with every used distribution/CI
  out there


I would prefer the first option - make pep8 ignore these files.
But I'm only a small player here, what's the opinion of the Cinder cores?
Would that be acceptable?


Regards,

Phil

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

[openstack-dev] [Neutron] Drivers meeting cancelled for the next three occurences

[Armando M.]

Folks,

Please look at [1] to be aware of the current backlog.

Cheers,
Armando

[1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
__
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] send what

[葛志伟]

发自我的iPhone__
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] [Artifacts] [app-catalog] Proposed pre-holiday Artifacts virtual meetup.

[Nikhil Komawar]

I would like to close the poll now and call the meeting at 1530UTC on
Wednesday 23rd December for around 90 mins.

If there are more additions to the call please let me know by tomorrow
(Tuesday Dec 22nd 2100UTC) to identify the need for a different
communication platform. Else we will be using the hangout link given in
the poll ( http://doodle.com/poll/adq4y5ppiy4hqcww ).

Please find the tentative agenda proposed here (
https://etherpad.openstack.org/p/mitaka-glare-preholiday-sync ). We may
have more items closer to the meeting and you are encouraged to add sub
topics as appropriate.

Again, please let me know if you have concerns.

On 12/20/15 10:49 PM, Nikhil Komawar wrote:
> Hi all,
>
> Sorry to send this last minute; but as informally decided and having had
> some momentum on Artifacts with a few decision items to be taken, it
> would be nice to have a virtual sync before the holiday season begins.
>
> I have created a poll for the same. Please vote on the doodle as soon as
> possible ( http://doodle.com/poll/adq4y5ppiy4hqcww ). Attached is the
> hangout link for participation however, we may utilize other video
> conference media if large number of participants show up. The meeting
> time would be 60-90 minutes and is likely to happen either this Tuesday
> or Wednesday (as shown on doodle) if poll is successful.
>
> Please let me know if anyone has concerns.
>

-- 

Thanks,
Nikhil


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

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

[Zaro]

Hit '?' and it says '/' is find, give that a try.

Looks like in Gerrit 2.11 the 'f' to get a popup of the list of files
is only available in unified diff view.  I don't remember if it was
available in side-by-side view on Gerrit 2.8.

-Khai


On Mon, Dec 21, 2015 at 5:04 PM, Carl Baldwin  wrote:
> I also really miss being able to pull up the list of files in diff
> view with the 'f' key.  Any equivalent?
>
> Carl
>
> On Mon, Dec 21, 2015 at 4:07 PM, Carl Baldwin  wrote:
>> I noticed a couple of things today while reviewing a largish page [1].
>> First, when I search for something using the browser's builtin search
>> (Chrome, Mac OSX Yosemite), it doesn't seem to find occurrences that
>> are not in the visible portion of the page.  For example, when I
>> search for DNSDOMAIN, I get 1 hit from the top of the file.  The file
>> actually has almost 30 hits for this string.  For example, scroll down
>> to about L310 in the file.  You'll see them all over the place (and
>> now Chrome's search finds these hits if you try again).  I use to use
>> search within a file with the old gerrit and never noticed this
>> problem.
>>
>> The other thing that I found annoying is when I scroll the page with
>> my trackpad, it now jumps around sometimes to a different part of the
>> page.  For example, I'll scroll up to find a spot in the file and when
>> I think I've arrived, it will jump back down the file a bit.  It is
>> disorienting.  Of course, now it isn't doing it anymore so it doesn't
>> seem to be all the time.  It was behaving this way for a good 20
>> minutes trying to get through this file.
>>
>> Carl
>>
>> Carl
>>
>> [1] https://review.openstack.org/#/c/212213/36/neutron/db/dns_db.py
>>
>> On Thu, Dec 17, 2015 at 8:17 PM, Brian Haley  wrote:
>>> On 2015-12-16 16:24, openstack-dev-requ...@lists.openstack.org wrote:

 Thanks to everyone for their patience while we upgraded to Gerrit
 2.11.  I'm happy to announce that we were able to successfully
 completed this task at around 21:00 UTC.  You may hack away once more.

 If you encounter any problems, please let us know here or in
 #openstack-infra on Freenode.
>>>
>>>
>>> I'm still undecided on 2.11, have to give it more time, but I have noticed
>>> one thing that's annoying...
>>>
>>> Trying to copy text from a review no longer works easily.  When I highlight
>>> text there's a little "bubble" pop-up of {press c to comment}, which seems
>>> to interfere with both my three-button mouse copy buffer, as well as Ctrl-C.
>>> Call me a nitpicker, but having to highlight text, right-button click, Copy,
>>> right-button click, Paste, is a pain.
>>>
>>> Maybe someone has a simple work-around for that.
>>>
>>> -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
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [OpenStack-dev][Neutron] Is there a tool of generating network topology?

[Hong Hui Xiao]

Hi,
 
    I remember there was discussion about it. I have these[1-2] in my bookmark, maybe they are what you want.
 
[1] http://leoh0.github.io/blog/2015/04/03/draw-openstack-l2-network-architecture-automatically/
[2] https://github.com/larsks/neutron-diag
 
---
Hong Hui Xiao(肖宏辉)
 
- Original message -From: Gareth To: OpenStack Development Mailing List Cc:Subject: [openstack-dev] [OpenStack-dev][Neutron] Is there a tool of generating network topology?Date: Tue, Dec 22, 2015 12:28 PM 
Hi, networking guys,For example, we could use it to generate a png file or print ascii incommand line. Is there something like this?--GarethCloud Computing, OpenStack, Distributed Storage, Fitness, BasketballOpenStack contributor, kun_huang@freenodeMy promise: if you find any spelling or grammar mistakes in my emailfrom Mar 1 2013, notify meand I'll donate $1 or ￥1 to an open organization you specify.__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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

Re: [openstack-dev] [OpenStack-dev][Neutron] Is there a tool of generating network topology?

[Gal Sagie]

Depends what you mean "Network topology" , Horizon UI has virtual network
topology
graph/diagram.
If you mean the physical topology, thats a bit harder but i remember there
was a talk
proposal for the previous summit on that area (i think garyk (CCed) was one
of the proposed talkers so maybe
he can shade some more light on this)

On Tue, Dec 22, 2015 at 6:36 AM, Hong Hui Xiao  wrote:

> Hi,
>
> I remember there was discussion about it. I have these[1-2] in my
> bookmark, maybe they are what you want.
>
> [1]
> http://leoh0.github.io/blog/2015/04/03/draw-openstack-l2-network-architecture-automatically/
> [2] https://github.com/larsks/neutron-diag
>
> ---
> Hong Hui Xiao(肖宏辉)
>
>
> - Original message -
> From: Gareth 
> To: OpenStack Development Mailing List 
> Cc:
> Subject: [openstack-dev] [OpenStack-dev][Neutron] Is there a tool of
> generating network topology?
> Date: Tue, Dec 22, 2015 12:28 PM
>
> Hi, networking guys,
>
> For example, we could use it to generate a png file or print ascii in
> command line. Is there something like this?
>
> --
> Gareth
>
> Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball
> OpenStack contributor, kun_huang@freenode
> My promise: if you find any spelling or grammar mistakes in my email
> from Mar 1 2013, notify me
> and I'll donate $1 or ￥1 to an open organization you specify.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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

Re: [openstack-dev] [Openstack-Dev][Manila] - Need design decision help - - https://bugs.launchpad.net/manila/+bug/1503390

[Ben Swartzlander]

On 12/22/2015 12:26 AM, nidhi.h...@wipro.com wrote:

Hi all.

I am working on bug 1503390. (status=None while delete is in progress

)

I was doing analysis of problem and found that yes its there.

I reproduced it.

Now the two solutions proposed..

1)Either say the status as deleting for such snapshots ?

2)lets not list such snapshots in list ..

I see that

If we implement solution1 .. then it doesn’t work as …..

we reach the same Situation of (snapshot present but snapshot_instance
absent)

in two cases

When snapshot is deleted and when snapshot is created …

Now if I set status as deleting(to be shown in list for snapshots with
no snapshot_instances)

it will be a wrong information when we are creating the snapshot.

And list function – can not differentiate state (snapshot present but
snapshot_instance absent)

whether its due to creation or deletion.  PCIIMW…

Another way to do this is .. let create delete path set the status to a
special state .

which if list operation obtains .. can understand how to interpret it …

But setting status also is not possible as status resides in
snapshot_instances table ..

row for which is not created yet in create path .. we can not set staus …!!!

Do you think that

STATUS_NEW = 'new'

STATUS_CREATING = 'creating'

STATUS_DELETING = 'deleting'

STATUS_DELETED = 'deleted'

STATUS_ERROR = 'error'

STATUS_ERROR_DELETING = 'error_deleting'

STATUS_AVAILABLE = 'available'

STATUS_ACTIVE = 'active'

STATUS_INACTIVE = 'inactive'>

STATUS_MANAGING = 'manage_starting'

STATUS_MANAGE_ERROR = 'manage_error'

STATUS_UNMANAGING = 'unmanage_starting'

STATUS_UNMANAGE_ERROR = 'unmanage_error'

STATUS_UNMANAGED = 'unmanaged'

STATUS_EXTENDING = 'extending'

Do you think that setting state as *_some neutral state like
state_inactive .._*

will help?

it will be same in both creation and deletion path ?

so should we go with 2^nd solution ? lets not show such shares in list ?


I like the second solution. Rather than making up a neutral state, just 
don't list snapshots with no instances. If the snapshot was getting 
deleted, then very soon there won't be anything to show, and if the 
snapshot was just getting created, the client can retry the query later 
and see the snapshot after a short time.


-Ben



Thanks

Nidhi

The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain proprietary, confidential or privileged information. If
you are not the intended recipient, you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments. WARNING:
Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The
company accepts no liability for any damage caused by any virus
transmitted by this email. www.wipro.com


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




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

[openstack-dev] [neutron] How to make deb and rpm packages for a networking-* project?

[P. Ramanjaneya Reddy]

Hi All,

Can someone help on..
How to make rpm and deb packages for a networking-* project?

Thanks & Regards,
Ramanji.
__
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] tacker

[Sripriya Seetharam]

Hello Yeping Liu,

You can create a VNFD template using the command:

tacker vnfd-create --vnfd-name sample_vnfd --vnfd-file 
~/tacker/devstack/samples/sample-vnfd-monitor.yaml

Here, --vnfd-file argument takes the template yaml file as an input

You can find more templates at 
https://github.com/openstack/tacker/tree/master/devstack/samples

Monitoring can be enabled in the VNFD template using the 'monitoring_policy' 
section in VNFD template. We support 'ping' and http_ping' monitoring drivers

You can deploy VNF using the created VNFD template with the command:
vnf-create --vnf-name test_vnf --vnfd-name sample_vnfd

Feel free to ping us on #tacker IRC channel or drop a question on 
https://answers.launchpad.net/tacker .

Cheers,
Sripriya


From: Demo [mailto:290564...@qq.com]
Sent: Monday, December 21, 2015 6:41 AM
To: openstack-dev 
Subject: [openstack-dev] tacker

dear you：
I have installed tacker in my ubuntu system,and binded to an openstack 
instance ,but I did't find the way to add an VNFD in tacker.  using this 
command," tacker vnfd-create --name ${VNFD_NAME} --vnfd-file 
${VNFD_TOSCA_YAML-FILE}"  where should I place the YAML file.  further,I want 
to set up the whole system,including tacker and openstack, I am confused How to 
make tacker perform in right way. such as ,create VDU , minitor VM.sorry for my 
poor English and bad logical.appriciate your reply.

  a tacker learner

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

Re: [openstack-dev] [neutron] How to make deb and rpm packages for a networking-* project?

[Fawad Khaliq]

There is one example [1] in review and may be incomplete but might help. It
only adds the scripts to build. Publishing part is different.

[1] https://review.openstack.org/#/c/248239/

Fawad Khaliq


On Tue, Dec 22, 2015 at 11:15 AM, P. Ramanjaneya Reddy  wrote:

>
> Hi All,
>
> Can someone help on..
> How to make rpm and deb packages for a networking-* project?
>
> Thanks & Regards,
> Ramanji.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Removal of support for nova-network

[Sergii Golovatiuk]

Hi,

Finally we can deprecate nova-network ...
We should remove it from UI, nailgun logic and tests to have less technical
debt.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Mon, Dec 21, 2015 at 5:01 PM, Sheena Gregson 
wrote:

> Hey guys –
>
>
>
> I know this has been a topic of a lot of discussion – Adrian informed me
> on Friday that QA has confirmed the multi-hypervisor use case has been
> tested successfully without nova-network, so we can finally deprecate it!
>
>
>
> Users who want to deploy multiple hypervisors will need to use the Fuel
> DVS plugin (Neutron ML2 driver) to support their vCenter computes and the
> KVM/QEMU computes can use Neutron + GRE/VXLAN.
>
>
>
> I’ve created a kind of “cover all the things” bug here:
> https://bugs.launchpad.net/fuel/+bug/1528407.  Given the state of
> nova-network right now in Fuel, I have marked it as Critical.
>
>
>
> Let’s start the conversation on here and make sure all the bases are
> covered – if additional bugs need to be logged or there’s administrative
> overhead, let me know and I’ll be happy to help out!
>
>
>
> Sheena Gregson | Sr. Product Manager | Mirantis 
>
> p: +1 650 646 3302 | e: sgreg...@mirantis.com
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][nova][all] timeutils deprecation removals will break Nova

[ChangBo Guo]

2015-12-22 3:42 GMT+08:00 Matt Riedemann :

>
>
> On 12/21/2015 1:22 PM, Davanum Srinivas wrote:
>
>> Rob,
>>
>> Can we set some goals for the server projects too?
>>
>> Say anything deprecated in liberty timeframe in oslo libs or any other
>> libs we consume should be fixed by milestone2 in mitaka? At the moment
>> the burden is entirely on oslo and hence unfair.
>>
>> Thanks,
>> Dims
>>
>> On Mon, Dec 21, 2015 at 2:15 PM, Robert Collins
>>  wrote:
>>
>>> On 21 December 2015 at 04:57, Davanum Srinivas 
>>> wrote:
>>>
 Nova folks,

 We have this review in oslo.utils:
 https://review.openstack.org/#/c/252898/

 There were failed effort in the past to cleanup in Nova:
 https://review.openstack.org/#/c/164753/
 https://review.openstack.org/#/c/197601/

 What do we do? Suggestions please.

>>>
>>> We don't remove it yet. Not till liberty-eol at the earliest, or if we
>>> don't get users migrated early enough, mitaka-eol.
>>>
>>> We would benefit from an automated thing in place to tell projects
>>> like Nova that they are using deprecated things during CI (without
>>> bloating deployer logs) -  whether a keystone API, an oslo config
>>> option or function, or $whatever. We would also benefit from a thing
>>> to rollup such information from consuming projects back to the
>>> deprecating project, so we can tell whether we're ready to cleanup old
>>> things.
>>>
>>> I think in general that there needs to be a balance around effort on
>>> migrations: if oslo deprecates something - anything - we're creating
>>> work for consumers of oslo. Its unfair for us to do that unilaterally.
>>> Conversely, if projects don't migrate away from poor APIs onto newer
>>> better ones, they create long term maintenance work for oslo: so we
>>> all need to work together to coordinate such things.
>>>
>>> https://review.openstack.org/#/c/226157/12 is part of this - it is an
>>> effort to bring consistency in expectations and process/patterns here.
>>>
>>> -Rob
>>>
>>> --
>>> Robert Collins 
>>> Distinguished Technologist
>>> HP Converged Cloud
>>>
>>>
>>> __
>>> 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
>>>
>>
>>
>>
>>
> Nova also needs an Oslo liaison [1]. That used to be Joe Gordon, but he's
> gone now. That would really be the person in Nova driving the Oslo changes
> and review priorities.
>
> [1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Oslo
>
> --
>

  Matt, I would like to take the liaison for Nova,  I worked on both Nova
and Oslo,  as Oslo core reviewer I attend  Oslo weekly meeting and will
  help Nova and Oslo team work together smoothly.   I would like to submit
new commit to  removing  deprecated method for Nova.

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



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

Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources

[Jay Lau]

For case 2), can we talk this with HEAT team? This seems to be a issue
related to HEAT quota, why HEAT do not add quota support?

On Tue, Dec 22, 2015 at 7:42 AM, Vilobh Meshram <
vilobhmeshram.openst...@gmail.com> wrote:

> As mentioned by Hongbin we might have these 3 cases. Hongbin and I did
> discuss about these in the Magnum IRC.
>
> The interestring case being the #2 one. Where in case enough resources are
> not available at the IaaS layer, and Magnum is in the process of creating a
> Bay; Magnum needs to be more descriptive about the failure so that the
> operator or user can be aware what exactly happened i.e. did the request
> failed because of resource constraints at the PaaS layer, at the IaaS layer
> etc.
>
> Having the Quota layer at magnum will abstract out the underlying layer
> and would impose quota on objects that Magnum understands. But again it
> would be nice to know what operators think about it and would it be
> something that they will find useful.
>
> -Vilobh
>
> On Mon, Dec 21, 2015 at 2:58 PM, Hongbin Lu  wrote:
>
>> If we decide to support quotas in CaaS layer (i.e. limit the # of bays),
>> its implementation doesn’t have to be redundant to IaaS layer (from Nova,
>> Cinder, etc.). The implementation could be a layer on top of IaaS, in which
>> requests need to pass two layers of quotas to succeed. There would be three
>> cases:
>>
>> 1.   A request exceeds CaaS layer quota. Then, magnum rejects the
>> request.
>>
>> 2.   A request is within CaaS layer quota, and accepted by magnum.
>> Magnum calls Heat to create a stack, which will fail if the stack exceeds
>> IaaS layer quota. In this case, magnum catch and re-throw the exception to
>> users.
>>
>> 3.   A request is within both CaaS and IaaS layer quota, and the
>> request succeeds.
>>
>>
>>
>> I think the debate here is whether it would be useful to implement an
>> extra layer of quota management system in Magnum. My guess is “yes”, if
>> operators want to hide the underline infrastructure, and expose a pure CaaS
>> solution to its end-users. If the operators don’t use Magnum in this way,
>> then I will vote for “no”.
>>
>>
>>
>> Also, we can reference other platform-level services (like Trove and
>> Sahara) to see if they implemented an extra layer of quota management
>> system, and we could use it as a decision point.
>>
>>
>>
>> Best regards,
>>
>> Honbgin
>>
>>
>>
>> *From:* Adrian Otto [mailto:adrian.o...@rackspace.com]
>> *Sent:* December-20-15 12:50 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>>
>> *Subject:* Re: [openstack-dev] [openstack][magnum] Quota for Magnum
>> Resources
>>
>>
>>
>> This sounds like a source-of-truth concern. From my perspective the
>> solution is not to create redundant quotas. Simply quota the Magnum
>> resources. Lower level limits *could* be queried by magnum prior to acting
>> to CRUD the lower level resources. In the case we could check the maximum
>> allowed number of (or access rate of) whatever lower level resource before
>> requesting it, and raising an understandable error. I see that as an
>> enhancement rather than a must-have. In all honesty that feature is
>> probably more complicated than it's worth in terms of value.
>>
>> --
>>
>> Adrian
>>
>>
>> On Dec 20, 2015, at 6:36 AM, Jay Lau  wrote:
>>
>> I also have the same concern with Lee, as Magnum depend on HEAT  and HEAT
>> need call nova, cinder, neutron to create the Bay resources. But both Nova
>> and Cinder has its own quota policy, if we define quota again in Magnum,
>> then how to handle the conflict? Another point is that limiting the Bay by
>> quota seems a bit coarse-grainded as different bays may have different
>> configuration and resource request. Comments? Thanks.
>>
>>
>>
>> On Thu, Dec 17, 2015 at 4:10 AM, Lee Calcote 
>> wrote:
>>
>> Food for thought - there is a cost to FIPs (in the case of public IP
>> addresses), security groups (to a lesser extent, but in terms of the
>> computation of many hundreds of them), etc. Administrators may wish to
>> enforce quotas on a variety of resources that are direct costs or indirect
>> costs (e.g. # of bays, where a bay consists of a number of multi-VM /
>> multi-host pods and services, which consume CPU, mem, etc.).
>>
>>
>>
>> If Magnum quotas are brought forward, they should govern (enforce quota)
>> on Magnum-specific constructs only, correct? Resources created by Magnum
>> COEs should be governed by existing quota policies governing said resources
>> (e.g. Nova and vCPUs).
>>
>>
>>
>> Lee
>>
>>
>>
>> On Dec 16, 2015, at 1:56 PM, Tim Bell  wrote:
>>
>>
>>
>> -Original Message-
>> From: Clint Byrum [mailto:cl...@fewbar.com ]
>> Sent: 15 December 2015 22:40
>> To: openstack-dev 
>> Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum
>> Resources
>>
>> Hi! Can I offer a 

[openstack-dev] [OpenStack-dev][Neutron] Is there a tool of generating network topology?

[Gareth]

Hi, networking guys,

For example, we could use it to generate a png file or print ascii in
command line. Is there something like this?

-- 
Gareth

Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball
OpenStack contributor, kun_huang@freenode
My promise: if you find any spelling or grammar mistakes in my email
from Mar 1 2013, notify me
and I'll donate $1 or ￥1 to an open organization you specify.

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

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

[Evgeniy L]

Comments inline.

On Mon, Dec 21, 2015 at 1:42 PM, Oleg Gelbukh  wrote:

> The problem with this approach is that we can't manage the interfaces
> between components without changing the code of 2+ components (i.e. one
> that provides the data and all that consume it).
>

I'm not sure if understand you correctly, none of these approaches
require to change the components, we will have change a single
place, which is specific data processor.


>
> I also don't like polling model for data processors. In my understanding,
> components should push their changes through the pipeline. Although this is
> pure implementation detail and is not really important ATM.
>

We don't have any other choice, we don't control components, configuration
components are not going to implement Fuel specific logic, so Fuel has
to pool the data.


>
> The point is that for Solar integration, we still need integration points,
> and the less of them we have, the more simple the transition is going to
> be..
>

As described above, there will be a single integration point, data
processor.

>
> --
> Best regards,
> Oleg Gelbukh
>
> On Mon, Dec 21, 2015 at 11:32 AM, Evgeniy L  wrote:
>
>> Hi Oleg,
>>
>> I understand the concern, but in case of integration specifically with
>> Solar,
>> I don't see any reasons to add ConfigDB, because Solar by itself is a
>> ConfigDB.
>> At the same time I would agree that there might be a case, when user uses
>> Zookeeper/Puppet Master/CMDB as a data store, in this case we should store
>> the data directly in those services, without keeping them in yet another
>> storage.
>>
>> So the flow will look like this:
>> Components ->
>> Data get polled by data processors ->
>> | Solar data processor puts the data into Solar in its format
>> | Zookeeper data processor puts the data into Zookeeper in its format
>> | Custom CMDB data processor puts the data into CMDB in its own format
>>
>> Thanks,
>>
>> On Fri, Dec 18, 2015 at 7:00 PM, Oleg Gelbukh 
>> wrote:
>>
>>> Hi,
>>>
>>> The idea behind configdb is that it is independent component that
>>> defines data flows between other components of the system. It has no
>>> knowledge about those components or specifics of their data. Data formats
>>> are defined by components themselves via schemas/templates and can be
>>> changed at any time (i.e. don't require code changes).
>>>
>>> Important 'pro' having ConfigDB separate from Solar is that it will
>>> simplify transition from current Fuel architecture by breaking it into more
>>> definite stages and reducing the number of components Solar have to be
>>> integrated with.
>>>
>>> --
>>> Best regards,
>>> Oleg Gelbukh
>>>
>>> On Wed, Dec 16, 2015 at 4:38 PM, Evgeniy L  wrote:
>>>
 Hi Dmitry,

 I also don't think that we should duplicate the data in configdb,
 because in this case there will be +2 additional interfaces which
 will require to covert the data into configdb and after that from
 configdb to Solar, which seems redundant overhead.

 But we should be able to put the data directly to user's
 CMDB/ZooKeeper/Puppet Master/etc.

 Thanks,

 On Wed, Dec 16, 2015 at 2:03 AM, Dmitriy Shulyak  wrote:

> Hello folks,
>
> This topic is about configuration storage which will connect data
> sources (nailgun/bareon/others) and orchestration. And right now we are
> developing two projects that will overlap a bit.
>
> I understand there is not enough context to dive into this thread
> right away, but i will appreciate if those people, who participated in
> design, will add their opinions/clarifications on this matter.
>
> Main disagreements
> ---
> 1. configdb should be passive, writing to configdb is someone else
> responsibility
> + simpler implementation, easier to use
> - we will need another component that will do writing, or split this
> responsibility somehow
>
> 2. can be used without other solar components
> + clear inteface between solar components and storage layer
> - additional work required to design/refactor communication layer
> between modules in solar
> - some data will be duplicated between solar orchestrator layer and
> configdb
>
> 3. templates for output
> technical detail, can be added on top of solardb if required
>
> Similar functionality
> --
> 1. Hierachical storage
> 2. Versioning of changes
> 3. Possibility to overwrite config values
> 4. Schema for inputs
>
> Overall it seems that we share same goals for both services,
> the difference lies in organizational and technical implementation
> details.
>
> Possible solutions
> 
> 1. develop configdb and solar with duplicated functionality
> - at 

Re: [openstack-dev] [neutron][stable] proactive backporting

[Ihar Hrachyshka]

Rossella Sblendido  wrote:


Hi,

thanks Ihar for the etherpad and for raising this point.
.


On 12/18/2015 06:18 PM, Ihar Hrachyshka wrote:

Hi all,

just wanted to note that the etherpad page [1] with backport candidates
has a lot of work for those who have cycles for backporting relevant
pieces to Liberty (and Kilo for High+ bugs), so please take some on your
plate and propose backports, then clean up from the page. And please
don’t hesitate to check the page for more worthy patches in the future.

It can’t be a one man army if we want to run the initiative in long term.


I completely agree, it can't be one man army.
I was thinking that maybe we can be even more proactive.
How about adding as requirement for a bug fix to be merged to have the  
backport to relevant branches? I think that could help


I don’t think it will work. First, not everyone should be required to care  
about stable branches. It’s my belief that we should avoid formal  
requirements that mechanically offload burden from stable team to those who  
can’t possible care less about master. Open source works when there is  
personal motivation for contribution. Put the bar too high, and you will  
loose valuable contributions.


Second, it would be a waste of time for patch authors to sync all those  
backports with master patch while review is ongoing.


Ihar

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

Re: [openstack-dev] [neutron][stable] proactive backporting

[Rossella Sblendido]

Hi,

thanks Ihar for the etherpad and for raising this point.
.


On 12/18/2015 06:18 PM, Ihar Hrachyshka wrote:

Hi all,

just wanted to note that the etherpad page [1] with backport candidates
has a lot of work for those who have cycles for backporting relevant
pieces to Liberty (and Kilo for High+ bugs), so please take some on your
plate and propose backports, then clean up from the page. And please
don’t hesitate to check the page for more worthy patches in the future.

It can’t be a one man army if we want to run the initiative in long term.


I completely agree, it can't be one man army.
I was thinking that maybe we can be even more proactive.
How about adding as requirement for a bug fix to be merged to have the 
backport to relevant branches? I think that could help




[1]: https://etherpad.openstack.org/p/stable-bug-candidates-from-master

Thanks in advance,
Ihar

Miguel Angel Ajo  wrote:


I thought that may be, some of the work Ihar is proposing, could be
automated.


Yes indeed! We can do that.

cheers,

Rossella



Like, for example, checking if bug fixes are backportable as-is to the
previous stable
branches, and if they pass testing.

If that's the case, the bot could automatically automatically add the
bug to the list, or
flag it with some sort of specific flag, so, we humans could verify it
does make sense
to backport such bug, and if it actually meets the "backportable"
guidelines.



Kuvaja, Erno wrote:

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Friday, October 16, 2015 1:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][stable] proactive backporting

Hi all,

I’d like to introduce a new initiative around stable branches for
neutron
official projects (neutron, neutron-*aas, python-neutronclient) that is
intended to straighten our backporting process and make us more
proactive
in fixing bugs in stable branches. ‘Proactive' meaning: don’t wait
until a
known bug hits a user that consumes stable branches, but backport
fixes in
advance quickly after they hit master.

The idea is simple: every Fri I walk thru the new commits merged
into master
since last check; produce lists of bugs that are mentioned in Related-
Bug/Closes-Bug; paste them into:

https://etherpad.openstack.org/p/stable-bug-candidates-from-master

Then I click thru the bug report links to determine whether it’s
worth a
backport and briefly classify them. If I have cycles, I also request
backports
where it’s easy (== a mere 'Cherry-Pick to' button click).

After that, those interested in maintaining neutron stable branches
can take
those bugs one by one and handle them, which means: checking where it
really applies for backport; creating backport reviews (solving
conflicts,
making tests pass). After it’s up for review for all branches
affected and
applicable, the bug is removed from the list.

I started on that path two weeks ago, doing initial swipe thru all
commits
starting from stable/liberty spin off. If enough participants join
the process,
we may think of going back into git history to backport interesting
fixes from
stable/liberty into stable/kilo.

Don’t hesitate to ask about details of the process, and happy
backporting,

Ihar


Hi,

This looks like neat way to do it. In Glance we're doing constantly
proactive backporting and I have been nominating bugs for series' and
approving backports for a while now. We prefer not to have user
coming to us and telling that they hit to bug in "stable" we had
known already for ages, just didn't bother to backport the fix.  It
has worked out really well and people are learning to propose these
without me needing to read every single commit message.

Good luck, has worked great for us!

- Erno
__

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



__

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



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


__
OpenStack 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] - availability zone performance regression and discussion about added network field

[Hirofumi Ichihara]

On 2015/12/16 17:16, Kevin Benton wrote:
What will the availability zones API tell the user about the zones? 
Are they just opaque strings that the user doesn't really understand?

They shows available zones in the time.



What I'm a little worried about is that it seems like we are having 
the user doing the work of the scheduler.
I understand your worry. However, I think that AZ feature includes a use 
case that users can specify zone which their resource is scheduled.




Is this is for getting affinity or anti-affinity with resources for 
another network? If so, why not just have the user explicitly say in 
the API request 'anti-affinity=network_id' or 'affinity=network_id'. 
Then the scheduler would use the zones info to either place resources 
on a different zone or the same zone, depending on which was requested.



I like it. But we may have other issues, for example,

1. We have NW1(with anti-affinity=NW2) and NW2(with anti-affinity=NW1)
2. We delete NW1 and then create NW3(with anti-affinity=NW2) instead of NW1
3. NW2(with anti-affinity=NW1) is rescheduled because of some reasons
4. Neutron cannot find NW1 in anti-affinit of NW2. How does neutron also 
schedule NW2 to a zone which doesn't have NW3?


Of course, we can find a way of solving this issue itself. But the 
similar issue may happen.


I think that we must remove the filed if it always happens performance 
issue.
However, we should find out another solution for the issue as long as 
there are use cases that are needed by operators and users.


On Sun, Dec 13, 2015 at 11:25 PM, Hirofumi Ichihara 
> wrote:




On 2015/12/14 15:58, Kevin Benton wrote:

What decision would lead the user to request AZ1 and AZ2 in the
first place? Especially since when it fails to get AZ2, they just
request again with AZ1 and AZ3 instead.

I expected that user gets AZ1 and AZ2 (and AZ3) via GET
Availability zones API first. There is a gap between the time user
threw and the time his resource is scheduled. After user threw API
request with AZ1 and AZ2, if all agents of AZ2 are dead before
scheduling, the resource is scheduled in AZ1 only.





On Sun, Dec 13, 2015 at 10:31 PM, Hirofumi Ichihara
> wrote:



On 2015/12/14 14:52, Kevin Benton wrote:

I see, so regular users are supposed to use this information
as well. But how are they supposed to use it? For example,
if they see that their network has availability zones 1 and
4, but their instance is hosted in zone 3, what are they
supposed to do?

I don't think that there is what they should do in the case
because Neutron AZ is different from Nova AZ. For example,
there may be a case like the following.

1. User throws POST Network API and Subnet API with
availability_zone_hints [AZ1, AZ2]
2. Neutron server tries to schedule the resource on both AZ1
and AZ2 but the resource are scheduled on AZ1 only by some
reasons
3. User confirms via GET Network API where his resource is
hosted and he knows it's AZ1 only
4. User also can know AZ is ready via GET Availability zones
API: AZ1, AZ3
5. User deletes previous resource and he recreates his
resource with availability_zone_hints [AZ1, AZ3]




On Sun, Dec 13, 2015 at 8:57 PM, Hirofumi Ichihara
> wrote:

Hi Kevin,

On 2015/12/14 11:10, Kevin Benton wrote:

Hi all,

The availability zone code added a new field to the
network API that shows the availability zones of a
network. This caused a pretty big performance impact to
get_networks calls because it resulted in a database
lookup for every network.[1]

I already put a patch up to join the information ahead
of time in the network model.[2]

I agree with your suggestion. I believe that the patch
can solve the performance issue.


However, before we go forward with that, I think we
should consider the removal of that field from the API.

Having to always join to the DHCP agents table to
lookup which zones a network has DHCP agents on is
expensive and is duplicating information available with
other API calls.

Additionally, the field is just called
'availability_zones' but it's being derived solely from
AZ definitions in DHCP agent bindings for that network.
To me that doesn't represent where the network is
available, it just says which zones its scheduled DHCP
instances live in. If that's the 

Re: [openstack-dev] [Fuel] Nominate Bulat Gaifulin for fuel-web & fuel-mirror cores

[Igor Kalnitsky]

Well, the agreement is reached. I added Bulat to both fuel-web-core
and fuel-mirror-core groups.

Bulat, congratulations! Will be happy to see even more thorough
reviews from you!

On Tue, Dec 15, 2015 at 11:49 AM, Evgeniy L  wrote:
> +1
>
> On Tue, Dec 15, 2015 at 12:33 PM, Anastasia Urlapova
>  wrote:
>>
>> +1
>>
>> On Mon, Dec 14, 2015 at 3:20 PM, Roman Vyalov 
>> wrote:
>>>
>>> +1
>>>
>>> On Mon, Dec 14, 2015 at 3:05 PM, Aleksey Kasatkin
>>>  wrote:

 +1.


 Aleksey Kasatkin


 On Mon, Dec 14, 2015 at 12:49 PM, Vladimir Sharshov
  wrote:
>
> Hi,
>
> +1 from me to Bulat.
>
> On Mon, Dec 14, 2015 at 1:03 PM, Igor Kalnitsky
>  wrote:
>>
>> Hi Fuelers,
>>
>> I'd like to nominate Bulat Gaifulin [1] for
>>
>> * fuel-web-core [2]
>> * fuel-mirror-core [3]
>>
>> Bulat's doing a really good review with detailed feedback and he's a
>> regular participant in IRC. He's co-author of packetary and
>> fuel-mirror projects, and he made valuable contribution to fuel-web
>> (e.g. task-based deployment engine).
>>
>> Fuel Cores, please reply back with +1/-1.
>>
>> - Igor
>>
>> [1] http://stackalytics.com/?module=fuel-web_id=bgaifullin
>> [2] http://stackalytics.com/report/contribution/fuel-web/90
>> [3] http://stackalytics.com/report/contribution/fuel-mirror/90
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

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

Re: [openstack-dev] [nova][api] does validation bug-fix require microversion bump?

[Sylvain Bauza]

Le 21/12/2015 08:25, Ken'ichi Ohmichi a écrit :

Hi nova-api team,

I'd like to get a feedback about the way to bump a microversion.

Short version:
   We found a validation bug on Nova v2.1 API.
   To fix the bug, do we need to bump a new microversion?

Long version:
As LP bug report[1], nova v2.0 API allows a list of server-IDs on
scheduler_hint "different_host" like

 "os:scheduler_hints": {
 "different_host": [
 "099b8bee-9264-48fe-a745-45b22f7ff79f",
 "99644acc-8893-4656-9481-0114efdbc9b6"
 ]
 }

on "create a server" API.
However, nova v2.1 API is handling this request as invalid because the
validation implementation way is wrong now.
Nova v2.1 API should allow the list of server-IDs for backwards compatibility.

We are trying to fix this bug on
https://review.openstack.org/#/c/259247/ , and we have a question to
fix it.
This fix is API change even if fixing the bug, so do we need to bump a
microversion?

The one usage of microversions is notification of API change.
If bumping it, nova can notify the fixing with a microversion.

This fix should be applied to stable branches also because of helping
the existing users.
So if bumping a microversion on stable branch also, the microversion
number meanings become different between clouds which are deployed
with different nova releases.
So we(John, Alex, me) are guessing we should not bump a microversion
on stable branches. but if doing that, nova cannot notify the fixing
on stable branches.

Now I am feeling this fixing will be applied without a microversion
bump because it is nice to avoid different microversion meanings of
master/stable branches.
Is it fine for us?


It looks like a regression for the list, but the operator can still 
provide only one uuid if needed.
Providing a microversion for that would mean that V2.0 on v2.1 would 
have a different behaviour vs. the legacy /v2.0, which is bad IMHO.


Also, like you said, backporting the microversion to stable/liberty is 
bad too.



Those above points make me agree with you, we just need to fix the bug 
without creating a microversion IMHO.


-Sylvain



Thanks
Ken Ohmichi

---
[1]: https://launchpad.net/bugs/1521928

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



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

Re: [openstack-dev] [nova] proposed new compute review dashboard

[Markus Zoeller]

Sylvain Bauza  wrote on 12/18/2015 03:47:21 PM:

> From: Sylvain Bauza 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 12/18/2015 03:49 PM
> Subject: Re: [openstack-dev] [nova] proposed new compute review 
dashboard
> 
> 
> 
> Le 18/12/2015 15:20, Sean Dague a écrit :
> > With Gerrit 2.11 upgrade in place, we get access to a few new query
> > parameters. I've retooled the compute review dashboard in
> > gerrit-dash-creator (https://github.com/openstack/gerrit-dash-creator)
> > to take advantage of it.
> >
> > The url is - https://goo.gl/1vTS0Z
> >
> > The contents are:
> >
> > [dashboard]
> > title = Nova Review Inbox (master branch only)
> > description = Review Inbox
> > foreach = (project:openstack/nova OR
> > project:openstack/python-novaclient) status:open NOT owner:self NOT
> > label:Workflow<=-1 label:Verified>=1,jenkins NOT
> > label:Code-Review>=-2,self branch:master is:mergeable
> >
> > [section "Needs final +2"]
> > query = NOT label:Code-Review<=-1,nova-core label:Code-Review>=2
> >
> > [section "Small Patches"]
> > query = NOT label:Code-Review<=-1,nova-core delta:<=10
> >
> > [section "Needs Feedback (Changes older than 5 days that have not been
> > reviewed by anyone)"]
> > query = NOT label:Code-Review<=2 age:5d
> >
> > [section "You are a reviewer, but haven't voted in the current 
revision"]
> > query = reviewer:self
> >
> > [section "Bug fix, Passed Jenkins, No Negative Core Feedback"]
> > query = NOT label:Code-Review<=-1,nova-core message:"Closes-Bug: "
> >
> > [section "Passed Jenkins, No Negative Core Feedback"]
> > query = NOT label:Code-Review<=-1,nova-core NOT message:"Closes-Bug: "
> >
> > [section "Wayward Changes (Changes with no code review in the last 5 
days)"]
> > query = label:Code-Review<=2 NOT label:Code-Review<=-1,nova-core 
age:5d
> >
> >
> > No one has to use this dashboard, I realize we all have slightly
> > different ways of looking at the review queue to find the right stuff.
> > I'll explain the logic of this ordering below and why I've found it
> > works well for me.
> >
> >
> > The logic of this is to only review code that is mergable (has passing
> > tests, is not in merge conflict, doesn't have a -2 block on it)
> >
> > The top items are code that currently has a core +2 and no core -1
> > feedback. Trying to keep this list small I think is important. Either
> > the code is ready to go, or you have a reason why it is not. Either is
> > valid, but lets not leave folks with code with one +2 in limbo for 
some
> > long chunk of time.
> >
> > Next up is very small patches (<= 10 lines of change). These *often*
> > (but no always) are quite easy to turn around. Minor typos or bug 
fixes.
> > Hopefully many of these move up into slot 1.
> >
> > The rest is basically the way the old dashboard was.
> >
> > If you find this dashboard useful, enjoy. If not, hopefully you take
> > some ideas out of it for your own review pattern.
> 
> Going further, it's now possible to add that above dash into the Gerrit 
> menu. For that, just go to 
> https://review.openstack.org/#/settings/preferences and add the above 
> query string, it will add a new entry to your top menu.
> 
> -Sylvain

That's quite nice actually! Thanks for the tip Sylvain.
And thanks to Sean for the dashboard. 

Regards, Markus Zoeller (markus_z)


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

Re: [openstack-dev] [Horizon] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

[Timur Sufiev]

Hello, Matt

Just checked it, nova quota-show command just shows current quota limits
for a given tenant, below is an output for may Devstack admin tenant:

timur@devstack:~/devstack$ nova quota-show --tenant
9f6cc244fd9d41668d49c00f12b70219
+-+---+
| Quota   | Limit |
+-+---+
| instances   | 10|
| cores   | 20|
| ram | 51200 |
| floating_ips| 10|
| fixed_ips   | -1|
| metadata_items  | 128   |
| injected_files  | 5 |
| injected_file_content_bytes | 10240 |
| injected_file_path_bytes| 255   |
| key_pairs   | 100   |
| security_groups | 10|
| security_group_rules| 20|
| server_groups   | 10|
| server_group_members| 10|
+-+---+


On Sat, Dec 19, 2015 at 5:58 PM Matt Riedemann 
wrote:

>
>
> On 12/18/2015 12:35 PM, Timur Sufiev wrote:
> > Matt,
> >
> > actually Ivan (Ivan, thanks a lot!) showed me the exact cinderclient
> > call that I needed. Now I know how to retrieve Cinder quota usage info
> > per-tenant, seems that to retrieve the same info cloud-wide I should sum
> > up all the available tenant usages.
> >
> > With Cinder quota usages being sorted out, my next goal is Nova and
> > Neutron. As for Neutron, there are plenty of quota-related calls I'm
> > going to play with next week, perhaps there is something suitable for my
> > use case. But as for Nova, I haven't found something similar to 'usage'
> > of cinderclient call, so help from someone familiar with Nova is very
> > appreciated :).
> >
> > [0]
> >
> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L36
> >
> > On Fri, Dec 18, 2015 at 5:17 PM Matt Riedemann
> > > wrote:
> >
> >
> >
> > On 12/17/2015 2:40 PM, Ivan Kolodyazhny wrote:
> >  > Hi Timur,
> >  >
> >  > Did you try this Cinder API [1]?  Here [2] is cinderclient output.
> >  >
> >  >
> >  >
> >  > [1]
> >  >
> >
> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L33
> >  > [2] http://paste.openstack.org/show/482225/
> >  >
> >  > Regards,
> >  > Ivan Kolodyazhny,
> >  > http://blog.e0ne.info/
> >  >
> >  > On Thu, Dec 17, 2015 at 8:41 PM, Timur Sufiev
> > 
> >  > >>
> wrote:
> >  >
> >  > Hello, folks!
> >  >
> >  > I'd like to initiate a discussion of the feature request I'm
> > going
> >  > to make on behalf of Horizon to every core OpenStack service
> > which
> >  > supports Quota feature, namely Cinder, Nova and Neutron.
> >  >
> >  > Although all three services' APIs support special calls to get
> >  > current quota limitations (Nova and Cinder allows to get and
> > update
> >  > both per-tenant and default cloud-wide limitations, Neutron
> > allows
> >  > to do it only for per-tenant limitations), there is no
> > special call
> >  > in any of these services to get current per-tenant usage of
> > quota.
> >  > Because of that Horizon needs to get, say for 'volumes'
> quota, a
> >  > list of Cinder volumes in the current tenant and then just
> > calculate
> >  > its length [1]. When there are really a lot of entities in
> > tenant -
> >  > instances/volumes/security groups/whatever - all this calls
> > sum up
> >  > and make rendering pages in Horizon much more slower than it
> > could
> >  > be. Is it possible to provide special API calls to alleviate
> > this?
> >  >
> >  > [1]
> >  >
> >
> https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350
> >  >
> >  >
> >
>  __
> >  > OpenStack Development Mailing List (not for usage questions)
> >  > Unsubscribe:
> >  > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> >  >
> >   <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> >  > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >  >
> >  >
> >  >
> >  >
> >  >
> >
>  __
> >  > OpenStack Development Mailing List (not for usage questions)
> >  > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> 

[openstack-dev] [nova][RFC] A base patch for live migration(list/show/cancel/pause)

[少合冯]

Now,

I have notice:

https://review.openstack.org/#/c/258771/  (list/show migration)
https://review.openstack.org/#/c/245921/   (pause migration)

introduce the a new controller:  ServerMigrationsController.
As we all know, the following  cancel patch will also need it.

Also the above patches are not a small patch, so it will take some times to
be well reviewed.

In order to avoid duplicated code, and one depends on others to long.

So I suggest to split the ServerMigrationsController as separated

And it's better simple.

So the define  list/show/cancel/pause as HTTPNotImplemented. as follow link:
http://paste.openstack.org/show/482387/
It is a good way to sync our work.

Notes: in both list and pause migration patch, they define:
ALIAS = 'os-server-migrations'
policy:
"os_compute_api:os-server-migrations:force_complete": "rule:admin_or_owner",


They are not right.

'os_compute_api:servers:migrations:show', and the default permission is
admin only.

please see this spec.
https://review.openstack.org/#/c/255122/8/specs/mitaka/approved/live-migration-progress-report.rst

we should know migrations is the sub-collection of servers.
And only Admin care  migration.
Owner should not care which host their VM is on.

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

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

[Jedrzej Nowak]

I definitely agree with what Evgeniy said.

@Oleg could you make a step-by-step how do you imagine this
integration (with separate ConfigDB) ? To me this adds at least one
component / integration point.


> The point is that for Solar integration, we still need integration points, 
> and the less of them we have, the more simple the transition is going to be..

With DR+DP you will have exactly one integration point.

> I also don't like polling model for data processors. In my understanding, 
> components should push their changes through the pipeline. Although this is 
> pure implementation detail and is not really important ATM.

Push is problematic because:
1) if you don't own all components then you're in troubles
2) you never know how valid are data of component (you could add some
time based markers, but still it's not enough), you basically loose
control about data. With pull model you know more about context etc.

On Mon, Dec 21, 2015 at 11:49 AM, Evgeniy L  wrote:
> Comments inline.
>
> On Mon, Dec 21, 2015 at 1:42 PM, Oleg Gelbukh  wrote:
>>
>> The problem with this approach is that we can't manage the interfaces
>> between components without changing the code of 2+ components (i.e. one that
>> provides the data and all that consume it).
>
>
> I'm not sure if understand you correctly, none of these approaches
> require to change the components, we will have change a single
> place, which is specific data processor.
>
>>
>>
>> I also don't like polling model for data processors. In my understanding,
>> components should push their changes through the pipeline. Although this is
>> pure implementation detail and is not really important ATM.
>
>
> We don't have any other choice, we don't control components, configuration
> components are not going to implement Fuel specific logic, so Fuel has
> to pool the data.
>
>>
>>
>> The point is that for Solar integration, we still need integration points,
>> and the less of them we have, the more simple the transition is going to
>> be..
>
>
> As described above, there will be a single integration point, data
> processor.
>>
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Mon, Dec 21, 2015 at 11:32 AM, Evgeniy L  wrote:
>>>
>>> Hi Oleg,
>>>
>>> I understand the concern, but in case of integration specifically with
>>> Solar,
>>> I don't see any reasons to add ConfigDB, because Solar by itself is a
>>> ConfigDB.
>>> At the same time I would agree that there might be a case, when user uses
>>> Zookeeper/Puppet Master/CMDB as a data store, in this case we should
>>> store
>>> the data directly in those services, without keeping them in yet another
>>> storage.
>>>
>>> So the flow will look like this:
>>> Components ->
>>> Data get polled by data processors ->
>>> | Solar data processor puts the data into Solar in its format
>>> | Zookeeper data processor puts the data into Zookeeper in its format
>>> | Custom CMDB data processor puts the data into CMDB in its own format
>>>
>>> Thanks,
>>>
>>> On Fri, Dec 18, 2015 at 7:00 PM, Oleg Gelbukh 
>>> wrote:

 Hi,

 The idea behind configdb is that it is independent component that
 defines data flows between other components of the system. It has no
 knowledge about those components or specifics of their data. Data formats
 are defined by components themselves via schemas/templates and can be
 changed at any time (i.e. don't require code changes).

 Important 'pro' having ConfigDB separate from Solar is that it will
 simplify transition from current Fuel architecture by breaking it into more
 definite stages and reducing the number of components Solar have to be
 integrated with.

 --
 Best regards,
 Oleg Gelbukh

 On Wed, Dec 16, 2015 at 4:38 PM, Evgeniy L  wrote:
>
> Hi Dmitry,
>
> I also don't think that we should duplicate the data in configdb,
> because in this case there will be +2 additional interfaces which
> will require to covert the data into configdb and after that from
> configdb to Solar, which seems redundant overhead.
>
> But we should be able to put the data directly to user's
> CMDB/ZooKeeper/Puppet Master/etc.
>
> Thanks,
>
> On Wed, Dec 16, 2015 at 2:03 AM, Dmitriy Shulyak
>  wrote:
>>
>> Hello folks,
>>
>> This topic is about configuration storage which will connect data
>> sources (nailgun/bareon/others) and orchestration. And right now we are
>> developing two projects that will overlap a bit.
>>
>> I understand there is not enough context to dive into this thread
>> right away, but i will appreciate if those people, who participated in
>> design, will add their opinions/clarifications on this matter.
>>
>> Main disagreements
>> ---
>> 1. configdb should be 

Re: [openstack-dev] [Tacker] Mitaka midcycle meetup - RSVP / etherpad

[Zhipeng Huang]

Hi Sridhar,

Do we have means of virtual participant ?

On Thu, Dec 17, 2015 at 8:44 AM, Sridhar Ramaswamy 
wrote:

> Tacker team is planning to host a 2-day mid-cycle meetup in San Jose, CA
> around end of January. Please RSVP if you are interested to join with your
> preferred dates in this google form,
>
> http://goo.gl/forms/oHUfS0Q7X8
>
> We are gathering topics in this etherpad,
>
> https://etherpad.openstack.org/p/tacker-mitaka-midcycle
>
> - Sridhar
>
> __
> 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
>
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

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

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Igor Kalnitsky]

Hello,

Agree with Kevin. libvirt itself isn't a hypervisor. It's an API (or
single entry point) for dealing with other hypervisors, including qemu
and kvm.

So it's kinda confusing, I'd prefer to find another solution.

Thanks,
Igor

On Fri, Dec 18, 2015 at 7:24 PM, Fox, Kevin M  wrote:
> I think it may be confusing to a fair number of the users you are targeting.
> libvirt supports more then just qemu/kvm. xen, virtualbox, and others.
> saying libvirt makes people have to know that when you say libvirt you mean
> just the qemu/kvm that nova supports using the implementation detail of
> using libvirt.
>
> Thanks,
> Kevin
> 
> From: Aleksandr Didenko [adide...@mirantis.com]
> Sent: Friday, December 18, 2015 4:16 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on
> Wizard
>
> Hi,
>
> looks good to me.
>
> Regards,
> Alex
>
> On Fri, Dec 18, 2015 at 10:17 AM, Andriy Popovych 
> wrote:
>>
>> Hi fuelers,
>>
>> We want to throw KVM/QEMU options from Wizard and instead of them leave
>> only one: Libvirt [0]. Libvirt option enables QEMU by default and there are
>> still be possibility to change it on KVM in settings. It looks more
>> logically because both QEMU\KVM are options for libvirt which manage them.
>>
>> What are you think about it?
>>
>> [0] https://review.openstack.org/#/c/258690
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [neutron][stable] proactive backporting

[Ihar Hrachyshka]

Ihar Hrachyshka  wrote:


Rossella Sblendido  wrote:


Hi,

thanks Ihar for the etherpad and for raising this point.
.


On 12/18/2015 06:18 PM, Ihar Hrachyshka wrote:

Hi all,

just wanted to note that the etherpad page [1] with backport candidates
has a lot of work for those who have cycles for backporting relevant
pieces to Liberty (and Kilo for High+ bugs), so please take some on your
plate and propose backports, then clean up from the page. And please
don’t hesitate to check the page for more worthy patches in the future.

It can’t be a one man army if we want to run the initiative in long term.


I completely agree, it can't be one man army.
I was thinking that maybe we can be even more proactive.
How about adding as requirement for a bug fix to be merged to have the  
backport to relevant branches? I think that could help


I don’t think it will work. First, not everyone should be required to  
care about stable branches. It’s my belief that we should avoid formal  
requirements that mechanically offload burden from stable team to those  
who can’t possible care less about master.


Of course I meant ‘about stable branches’.

Ihar

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

Re: [openstack-dev] [neutron][taas] neutron ovs-agent deletes taas flows

[SUZUKI, Kazuhiro]

Hi,

I submited a modified patch set as follows.
In addition, I added test codes for this patch.

>   1. Set an integer cookie value to taas flows.
>  Maybe all "1" for short term tentative value.
>   2. Modify the cleanup logic in ovs-agent not to delete flows
>  which have a reserved integer cookie value.

https://review.openstack.org/#/c/257285/
https://review.openstack.org/#/c/257286/

Thanks,
KAZ


From: Soichi Shigeta 
Subject: Re: [openstack-dev] [neutron][taas] neutron ovs-agent deletes taas 
flows
Date: Thu, 17 Dec 2015 09:28:10 +0900

> 
>  Thank you for your helpful comments.
> 
>  I'd like to update my proposal as follows:
> 
>   1. Set an integer cookie value to taas flows.
>  Maybe all "1" for short term tentative value.
>   2. Modify the cleanup logic in ovs-agent not to delete flows
>  which have a reserved integer cookie value.
> 
> 
>> Sorry, that I don't see this earlier. Yes, cookies have integer
>> values, so
>> we won't be able to set string there. May be we can have a reserved
>> integer
>> cookie value for a project like all "1".
>>
>> I won't support idea of modifying cleanup logic not to drop 0x0
>> cookies.
>> During implementation of graceful restart it was not dropped at first,
>> but
>> I get rid of it as having a lot of flows not related to anything was
>> not
>> desirable, so we should try to avoid it here, too.
>>
>> On Wed, Dec 16, 2015 at 7:46 AM, Soichi Shigeta <
>> shigeta.soi...@jp.fujitsu.com> wrote:
>>
>>>
>>> o) An idea to fix:

1. Set "taas" stamp(*) to taas flows.
2. Modify the cleanup logic in ovs-agent not to delete entries
   stamped as "taas".

* Maybe a static string.
  If we need to use a string which generated dynamically
  (e.g. uuid), API to interact with ovs-agent is required.


>>>Last week I proposed to set a static string (e.g. "taas") as cookie
>>>of flows created by taas agent.
>>>
>>>But I found that the value of a cookie should not be a string,
>>>but an integer.
>>>
>>>At line 187 in
>>> "neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py":
>>>self.agent_uuid_stamp = uuid.uuid4().int & UINT64_BITMASK
>>>
>>>In case of we set an integer value to cookie, coordination
>>>(reservation of range) is required to avoid conflict of cookies with
>>>other neutron sub-projects.
>>>
>>>As an alternative (*** short term ***) solution, my idea is:
>>>Modify the clean up logic in ovs agent not to delete flows whose
>>>"cookie = 0x0".
>>>Because old flows created by ovs agent have an old stamp, "cookie =
>>>0x0" means it was created by other than ovs agent.
>>>
>>># But, this idea has a disadvantage:
>>>  If there are flows which have been created by older version of ovs
>>>  agent, they can not be cleaned.
>>>
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [Openstack-Dev][Manila] - Need design decision help - - https://bugs.launchpad.net/manila/+bug/1503390

[nidhi.hada]

Hi all.



I am working on bug 1503390. (status=None while delete is in progress

)



I was doing analysis of problem and found that yes its there.

I reproduced it.



Now the two solutions proposed..

1)Either say the status as deleting for such snapshots ?

2)lets not list such snapshots in list ..



I see that

If we implement solution1 .. then it doesn't work as .

we reach the same Situation of (snapshot present but snapshot_instance absent)

in two cases

When snapshot is deleted and when snapshot is created ...



Now if I set status as deleting(to be shown in list for snapshots with no 
snapshot_instances)

it will be a wrong information when we are creating the snapshot.

And list function - can not differentiate state (snapshot present but 
snapshot_instance absent)

whether its due to creation or deletion.  PCIIMW...





Another way to do this is .. let create delete path set the status to a special 
state .

which if list operation obtains .. can understand how to interpret it ...

But setting status also is not possible as status resides in snapshot_instances 
table ..

row for which is not created yet in create path .. we can not set staus ...!!!




Do you think that


STATUS_NEW = 'new'
STATUS_CREATING = 'creating'
STATUS_DELETING = 'deleting'
STATUS_DELETED = 'deleted'
STATUS_ERROR = 'error'
STATUS_ERROR_DELETING = 'error_deleting'
STATUS_AVAILABLE = 'available'
STATUS_ACTIVE = 'active'
STATUS_INACTIVE = 'inactive'>
STATUS_MANAGING = 'manage_starting'
STATUS_MANAGE_ERROR = 'manage_error'
STATUS_UNMANAGING = 'unmanage_starting'
STATUS_UNMANAGE_ERROR = 'unmanage_error'
STATUS_UNMANAGED = 'unmanaged'
STATUS_EXTENDING = 'extending'

Do you think that setting state as some neutral state like state_inactive ..
will help?
it will be same in both creation and deletion path ?




so should we go with 2nd solution ? lets not show such shares in list ?





Thanks

Nidhi



The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [vitrage] Next vitrage meeting

[AFEK, Ifat (Ifat)]

Hi,

The next two Vitrage meetings (this week and next week) are canceled. 
We will meet again on Wednesday January 6 at 9:00 UTC, on #openstack-meeting-3 
channel.

Thanks, 
Ifat.



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

Re: [openstack-dev] [Fuel] Removal of support for nova-network

[Aleksey Kasatkin]

Sergii,

We could remove it completely from nailgun if support for 7.0 and earlier
is not required.


Aleksey Kasatkin


On Tue, Dec 22, 2015 at 3:27 AM, Sergii Golovatiuk  wrote:

> Hi,
>
> Finally we can deprecate nova-network ...
> We should remove it from UI, nailgun logic and tests to have less
> technical debt.
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Mon, Dec 21, 2015 at 5:01 PM, Sheena Gregson 
> wrote:
>
>> Hey guys –
>>
>>
>>
>> I know this has been a topic of a lot of discussion – Adrian informed me
>> on Friday that QA has confirmed the multi-hypervisor use case has been
>> tested successfully without nova-network, so we can finally deprecate it!
>>
>>
>>
>> Users who want to deploy multiple hypervisors will need to use the Fuel
>> DVS plugin (Neutron ML2 driver) to support their vCenter computes and the
>> KVM/QEMU computes can use Neutron + GRE/VXLAN.
>>
>>
>>
>> I’ve created a kind of “cover all the things” bug here:
>> https://bugs.launchpad.net/fuel/+bug/1528407.  Given the state of
>> nova-network right now in Fuel, I have marked it as Critical.
>>
>>
>>
>> Let’s start the conversation on here and make sure all the bases are
>> covered – if additional bugs need to be logged or there’s administrative
>> overhead, let me know and I’ll be happy to help out!
>>
>>
>>
>> Sheena Gregson | Sr. Product Manager | Mirantis
>> 
>>
>> p: +1 650 646 3302 | e: sgreg...@mirantis.com
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][api] does validation bug-fix require microversion bump?

[GHANSHYAM MANN]

On Mon, Dec 21, 2015 at 4:25 PM, Ken'ichi Ohmichi  wrote:
> Hi nova-api team,
>
> I'd like to get a feedback about the way to bump a microversion.
>
> Short version:
>   We found a validation bug on Nova v2.1 API.
>   To fix the bug, do we need to bump a new microversion?
>
> Long version:
> As LP bug report[1], nova v2.0 API allows a list of server-IDs on
> scheduler_hint "different_host" like
>
> "os:scheduler_hints": {
> "different_host": [
> "099b8bee-9264-48fe-a745-45b22f7ff79f",
> "99644acc-8893-4656-9481-0114efdbc9b6"
> ]
> }
>
> on "create a server" API.
> However, nova v2.1 API is handling this request as invalid because the
> validation implementation way is wrong now.
> Nova v2.1 API should allow the list of server-IDs for backwards compatibility.
>
> We are trying to fix this bug on
> https://review.openstack.org/#/c/259247/ , and we have a question to
> fix it.
> This fix is API change even if fixing the bug, so do we need to bump a
> microversion?
>
> The one usage of microversions is notification of API change.
> If bumping it, nova can notify the fixing with a microversion.
>
> This fix should be applied to stable branches also because of helping
> the existing users.
> So if bumping a microversion on stable branch also, the microversion
> number meanings become different between clouds which are deployed
> with different nova releases.
> So we(John, Alex, me) are guessing we should not bump a microversion
> on stable branches. but if doing that, nova cannot notify the fixing
> on stable branches.
>
> Now I am feeling this fixing will be applied without a microversion
> bump because it is nice to avoid different microversion meanings of
> master/stable branches.
> Is it fine for us?

+1, IMO too it is fine to fix it as bug as long as it does not break
any existing v2.1 users (it still allow UUID only as valid one).
And we have to fix it for V2.1 comp mode too so microversion does not
fit here in my opinion too.
I am +1 to fix it as bug and backport to stable/branches also.


>
> Thanks
> Ken Ohmichi
>
> ---
> [1]: https://launchpad.net/bugs/1521928
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards
Ghanshyam Mann
+81-8084200646

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

[openstack-dev] [Neutron] [FwaaS] No meeting this week

[Sean M. Collins]

No FwaaS meeting this week. I will be on PTO the week after. I'm OK with
skipping that week too, and starting back up the first week of January
if there are no objections.

-- 
Sean M. Collins

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

Re: [openstack-dev] [Fuel] Removal of support for nova-network

[Igor Kalnitsky]

I don't think it's a good idea to drop support of 7.0 nova-network
setup in 8.0. We should keep compatibility for at least one release.

On Tue, Dec 22, 2015 at 9:15 AM, Aleksey Kasatkin
 wrote:
> Sergii,
>
> We could remove it completely from nailgun if support for 7.0 and earlier is
> not required.
>
>
> Aleksey Kasatkin
>
>
> On Tue, Dec 22, 2015 at 3:27 AM, Sergii Golovatiuk
>  wrote:
>>
>> Hi,
>>
>> Finally we can deprecate nova-network ...
>> We should remove it from UI, nailgun logic and tests to have less
>> technical debt.
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Mon, Dec 21, 2015 at 5:01 PM, Sheena Gregson 
>> wrote:
>>>
>>> Hey guys –
>>>
>>>
>>>
>>> I know this has been a topic of a lot of discussion – Adrian informed me
>>> on Friday that QA has confirmed the multi-hypervisor use case has been
>>> tested successfully without nova-network, so we can finally deprecate it!
>>>
>>>
>>>
>>> Users who want to deploy multiple hypervisors will need to use the Fuel
>>> DVS plugin (Neutron ML2 driver) to support their vCenter computes and the
>>> KVM/QEMU computes can use Neutron + GRE/VXLAN.
>>>
>>>
>>>
>>> I’ve created a kind of “cover all the things” bug here:
>>> https://bugs.launchpad.net/fuel/+bug/1528407.  Given the state of
>>> nova-network right now in Fuel, I have marked it as Critical.
>>>
>>>
>>>
>>> Let’s start the conversation on here and make sure all the bases are
>>> covered – if additional bugs need to be logged or there’s administrative
>>> overhead, let me know and I’ll be happy to help out!
>>>
>>>
>>>
>>> Sheena Gregson | Sr. Product Manager | Mirantis
>>>
>>> p: +1 650 646 3302 | e: sgreg...@mirantis.com
>>>
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [Fuel] Getting ready for SCF - please review version bumps

[Aleksandra Fedorova]

Hi, everyone,

SCF is coming [1], and while we are working on infrastructure changes
required for branching, Fuel Build team prepared set of version bumps
patches, see [2] for explanation:

  https://review.openstack.org/#/q/topic:8.0-scf

These patches are tested via custom ISO build and we'll need to merge
them to master on Wednesday, right after stable/8.0 branch is cut.
Please review in advance.

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-December/082655.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-December/082293.html


-- 
Aleksandra Fedorova
Fuel CI Team Lead
bookwar

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

[openstack-dev] FW: Manila Bug - Need design decision help - - https://bugs.launchpad.net/manila/+bug/1503390

[nidhi.hada]

Hi all.



I am working on bug 1503390. (status=None while delete is in progress

)



I was doing analysis of problem and found that yes its there.

I reproduced it.



Now the two solutions proposed..

1)Either say the status as deleting for such snapshots ?

2)lets not list such snapshots in list ..



I see that

If we implement solution1 .. then it doesn't work as .

we reach the same Situation of (snapshot present but snapshot_instance absent)

in two cases

When snapshot is deleted and when snapshot is created ...



Now if I set status as deleting(to be shown in list for snapshots with no 
snapshot_instances)

it will be a wrong information when we are creating the snapshot.

And list function - can not differentiate state (snapshot present but 
snapshot_instance absent)

whether its due to creation or deletion.  PCIIMW...





Another way to do this is .. let create delete path set the status to a special 
state .

which if list operation obtains .. can understand how to interpret it ...

But setting status also is not possible as status resides in snapshot_instances 
table ..

row for which is not created yet in create path .. we can not set staus ...!!!




Do you think that


STATUS_NEW = 'new'
STATUS_CREATING = 'creating'
STATUS_DELETING = 'deleting'
STATUS_DELETED = 'deleted'
STATUS_ERROR = 'error'
STATUS_ERROR_DELETING = 'error_deleting'
STATUS_AVAILABLE = 'available'
STATUS_ACTIVE = 'active'
STATUS_INACTIVE = 'inactive'>
STATUS_MANAGING = 'manage_starting'
STATUS_MANAGE_ERROR = 'manage_error'
STATUS_UNMANAGING = 'unmanage_starting'
STATUS_UNMANAGE_ERROR = 'unmanage_error'
STATUS_UNMANAGED = 'unmanaged'
STATUS_EXTENDING = 'extending'

Do you think that setting state as some neutral state like state_inactive ..
will help?
it will be same in both creation and deletion path ?




so should we go with 2nd solution ? lets not show such shares in list ?





Thanks

Nidhi



The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Andrey Danin]

Hi,

Let's call this hypervisor type "Qemu-KVM". So it will be a separate HV
like vCenter, Xen, or HyperV. The actual selection between qemu and kvm
will be a HV specific option in this case.

On Mon, Dec 21, 2015 at 1:24 PM, Igor Kalnitsky 
wrote:

> Hello,
>
> Agree with Kevin. libvirt itself isn't a hypervisor. It's an API (or
> single entry point) for dealing with other hypervisors, including qemu
> and kvm.
>
> So it's kinda confusing, I'd prefer to find another solution.
>
> Thanks,
> Igor
>
> On Fri, Dec 18, 2015 at 7:24 PM, Fox, Kevin M  wrote:
> > I think it may be confusing to a fair number of the users you are
> targeting.
> > libvirt supports more then just qemu/kvm. xen, virtualbox, and others.
> > saying libvirt makes people have to know that when you say libvirt you
> mean
> > just the qemu/kvm that nova supports using the implementation detail of
> > using libvirt.
> >
> > Thanks,
> > Kevin
> > 
> > From: Aleksandr Didenko [adide...@mirantis.com]
> > Sent: Friday, December 18, 2015 4:16 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt
> on
> > Wizard
> >
> > Hi,
> >
> > looks good to me.
> >
> > Regards,
> > Alex
> >
> > On Fri, Dec 18, 2015 at 10:17 AM, Andriy Popovych <
> apopov...@mirantis.com>
> > wrote:
> >>
> >> Hi fuelers,
> >>
> >> We want to throw KVM/QEMU options from Wizard and instead of them leave
> >> only one: Libvirt [0]. Libvirt option enables QEMU by default and there
> are
> >> still be possibility to change it on KVM in settings. It looks more
> >> logically because both QEMU\KVM are options for libvirt which manage
> them.
> >>
> >> What are you think about it?
> >>
> >> [0] https://review.openstack.org/#/c/258690
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Andrey Danin
ada...@mirantis.com
skype: gcon.monolake
__
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] [Ceilometer][Gnocchi] inconsistent instance attributes cause infinite update

[gord chung]

we actually looked at this problem here: 
https://review.openstack.org/#/c/235702/


i think we should add support of new attribute instead.

On 20/12/2015 10:52 AM, Luo Gangyi wrote:

Hi devs,
I found a problem which may cause infinite update of instance's 
attributes in gnocchi.

Let's see the resource definition of instance.
  - resource_type: instance
metrics:
  - 'instance'
  - 'memory'
  - 'memory.usage'
  - 'memory.resident'
  - 'vcpus'
  - 'cpu'
  - 'cpu_util'
  - 'disk.root.size'
...
attributes:
  host: resource_metadata.host
  image_ref: resource_metadata.image_ref_url
...
Here is the problem, although they have same  attributes, they are 
*not* same.
Some of them came from nova's notifications and the others are came 
from ceilometer-compute-agent.

1) Those came from notifications, their attributes looks like
image_ref :http://10.133.12.125:9292/images/
host: compute.lgy-openstack-kilo.novalocal
2) Those came from ceilometer-compute-agent,
image_ref : 
http://10.133.12.125:8774/4994e42421a04beda56fff7d817e810e/images/8d6a9cd9-48ae-4a41-bd13-262a46c93d72 


host:ea8f8e465d9caff06e80a0fda6f30d02725e0b55dc0fd940954cb55c
Such difference will cause alternately and infinitely update of a 
instance's attributes if we enable nova audit.
So I suggest we seperate these meters which came from notifications to 
another resource type like "instance_from_notification".

Any other idea?

--
Luo Gangyi
luogan...@chinamobile.com


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


--
gord

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

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Igor Kalnitsky]

What about hypervisor "Qemu", and checkbox option on Settings tab -
"Use KVM extension"?

On Mon, Dec 21, 2015 at 1:22 PM, Andrey Danin  wrote:
> Hi,
>
> Let's call this hypervisor type "Qemu-KVM". So it will be a separate HV like
> vCenter, Xen, or HyperV. The actual selection between qemu and kvm will be a
> HV specific option in this case.
>
> On Mon, Dec 21, 2015 at 1:24 PM, Igor Kalnitsky 
> wrote:
>>
>> Hello,
>>
>> Agree with Kevin. libvirt itself isn't a hypervisor. It's an API (or
>> single entry point) for dealing with other hypervisors, including qemu
>> and kvm.
>>
>> So it's kinda confusing, I'd prefer to find another solution.
>>
>> Thanks,
>> Igor
>>
>> On Fri, Dec 18, 2015 at 7:24 PM, Fox, Kevin M  wrote:
>> > I think it may be confusing to a fair number of the users you are
>> > targeting.
>> > libvirt supports more then just qemu/kvm. xen, virtualbox, and others.
>> > saying libvirt makes people have to know that when you say libvirt you
>> > mean
>> > just the qemu/kvm that nova supports using the implementation detail of
>> > using libvirt.
>> >
>> > Thanks,
>> > Kevin
>> > 
>> > From: Aleksandr Didenko [adide...@mirantis.com]
>> > Sent: Friday, December 18, 2015 4:16 AM
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt
>> > on
>> > Wizard
>> >
>> > Hi,
>> >
>> > looks good to me.
>> >
>> > Regards,
>> > Alex
>> >
>> > On Fri, Dec 18, 2015 at 10:17 AM, Andriy Popovych
>> > 
>> > wrote:
>> >>
>> >> Hi fuelers,
>> >>
>> >> We want to throw KVM/QEMU options from Wizard and instead of them leave
>> >> only one: Libvirt [0]. Libvirt option enables QEMU by default and there
>> >> are
>> >> still be possibility to change it on KVM in settings. It looks more
>> >> logically because both QEMU\KVM are options for libvirt which manage
>> >> them.
>> >>
>> >> What are you think about it?
>> >>
>> >> [0] https://review.openstack.org/#/c/258690
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Andrey Danin
> ada...@mirantis.com
> skype: gcon.monolake
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

[Bogdan Dobrelya]

On 21.12.2015 11:42, Oleg Gelbukh wrote:
> The problem with this approach is that we can't manage the interfaces
> between components without changing the code of 2+ components (i.e. one
> that provides the data and all that consume it).

What code is supposed to be changed in an example LDAP data source?
Otherwise, the only place I see shall require code changes is a data
processor for it, if one may want to support new (or very old) version
of the ldap with another database schema.

> 
> I also don't like polling model for data processors. In my
> understanding, components should push their changes through the
> pipeline. Although this is pure implementation detail and is not really
> important ATM.

What do you think the example LDAP data source shall push? IIUC, for
most auth cases, it shall be only pulled and processed.

> 
> The point is that for Solar integration, we still need integration
> points, and the less of them we have, the more simple the transition is
> going to be..

Data processors may be the only integration point, as they are supposed
to "know" how-to get and how-to shape data from sources

> 
> --
> Best regards,
> Oleg Gelbukh
> 
> On Mon, Dec 21, 2015 at 11:32 AM, Evgeniy L  > wrote:
> 
> Hi Oleg,
> 
> I understand the concern, but in case of integration specifically
> with Solar,
> I don't see any reasons to add ConfigDB, because Solar by itself is
> a ConfigDB.
> At the same time I would agree that there might be a case, when user
> uses
> Zookeeper/Puppet Master/CMDB as a data store, in this case we should
> store
> the data directly in those services, without keeping them in yet
> another storage.
> 
> So the flow will look like this:
> Components ->
> Data get polled by data processors ->
> | Solar data processor puts the data into Solar in its format
> | Zookeeper data processor puts the data into Zookeeper in its format
> | Custom CMDB data processor puts the data into CMDB in its own format
> 
> Thanks,
> 
> On Fri, Dec 18, 2015 at 7:00 PM, Oleg Gelbukh  > wrote:
> 
> Hi,
> 
> The idea behind configdb is that it is independent component
> that defines data flows between other components of the system.
> It has no knowledge about those components or specifics of their
> data. Data formats are defined by components themselves via
> schemas/templates and can be changed at any time (i.e. don't
> require code changes).
> 
> Important 'pro' having ConfigDB separate from Solar is that it
> will simplify transition from current Fuel architecture by
> breaking it into more definite stages and reducing the number of
> components Solar have to be integrated with.
> 
> --
> Best regards,
> Oleg Gelbukh
> 
> On Wed, Dec 16, 2015 at 4:38 PM, Evgeniy L  > wrote:
> 
> Hi Dmitry,
> 
> I also don't think that we should duplicate the data in
> configdb,
> because in this case there will be +2 additional interfaces
> which
> will require to covert the data into configdb and after that
> from
> configdb to Solar, which seems redundant overhead.
> 
> But we should be able to put the data directly to user's
> CMDB/ZooKeeper/Puppet Master/etc.
> 
> Thanks,
> 
> On Wed, Dec 16, 2015 at 2:03 AM, Dmitriy Shulyak
> > wrote:
> 
> Hello folks,
> 
> This topic is about configuration storage which will
> connect data sources (nailgun/bareon/others) and
> orchestration. And right now we are developing two
> projects that will overlap a bit.
> 
> I understand there is not enough context to dive into
> this thread right away, but i will appreciate if those
> people, who participated in design, will add their
> opinions/clarifications on this matter.
> 
> Main disagreements
> ---
> 1. configdb should be passive, writing to configdb is
> someone else responsibility
> + simpler implementation, easier to use
> - we will need another component that will do writing,
> or split this responsibility somehow
> 
> 2. can be used without other solar components
> + clear inteface between solar components and storage layer
> - additional work required to design/refactor
> communication layer between modules in solar
>   

[openstack-dev] [mistral] Team meeting - 12/21/2015

[Renat Akhmerov]

Hi,

This is a reminder that we’ll have a team meeting today at #openstack-meeting 
at 16.00 UTC

Agenda:
Review action items
Current status (progress, issues, roadblocks, further plans)
"Work queue" pattern in oslo.messaging 
(https://review.openstack.org/#/c/256342/ 
)
Open discussion

Feel free to bring up your our topics.

Renat Akhmerov
@ Mirantis Inc.



__
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] [cloudkitty] Meeting canceled for week 52 and 53

[Stéphane Albert]

Hi,

Most of the guys are currently in vacations, we are canceling meetings
for the next 2 weeks. We'll be back at the beginning of January.

Happy holidays

__
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] [ThirdParty][CI] [patch] Status page at http://ci-watch.tintri.com/project

[Asselin, Ramy]

Hi Phillip,

Yes, please offer a patch to that repo Anita suggested. There's a small group 
of us actively working on improving the code and eventually getting ci-watch 
deployed in openstack.org. Your patch and help would be very much appreciated.

We also meet bi-weekly in the 3rd party ci working group: 
https://wiki.openstack.org/wiki/Meetings/ThirdParty
We also discuss some issues in #openstack-third-party-ci

Thanks!
Ramy

-Original Message-
From: Anita Kuno [mailto:ante...@anteaya.info] 
Sent: Monday, December 21, 2015 6:52 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [ThirdParty][CI] [patch] Status page at 
http://ci-watch.tintri.com/project

On 12/21/2015 09:20 AM, Philipp Marek wrote:
> Hi all,
> 
> I quite like the page at http://ci-watch.tintri.com/project - it gives 
> a very quick overview about the failures one should look into, and 
> which to ignore ;)
> 
> 
> Please let me state before anything else that I don't know any of the 
> restrictions that may have led into the current design - it's very 
> likely that I'm just missing a few points, and that some or all of my 
> comments below are invalid anyway. As always, take enough salt!
> 
> 
> One thing about that page that is bothering me is the performance... 
> my
> (current) Firefox asks me several times whether I'd like to stop the 
> JS, or whether it should be allowed to continue.
> 
> With this patch (and a local exported copy of the page) I don't get 
> asked about that any more; it seems to give me a speedup of ~200, as 
> no intermediate lists need to be built and filtered any more:
> 
> $ diff -u verified.js.orig verified.js
> --- verified.js.orig2015-12-21 15:03:45.614529924 +0100
> +++ verified.js 2015-12-21 15:03:36.114432601 +0100
> @@ -33,9 +33,9 @@
>  $(document).ready(function () {
>$("colgroup").each(function (i, elem) {
>  if ($(elem).hasClass("verified-1")) {
> -  $("#results").find("td").filter(":nth-child(" + (i + 1) + 
> ")").addClass("verified-1");
> +  $("#results td:nth-child(" + (i + 1) + 
> + ")").addClass("verified-1");
>  } else if ($(elem).hasClass("verified1")) {
> -  $("#results").find("td").filter(":nth-child(" + (i + 1) + 
> ")").addClass("verified1");
> +  $("#results td:nth-child(" + (i + 1) + 
> + ")").addClass("verified1");
>  }
>});
>$("#verified1-button").on("click", toggle_verified_plus);
> 
> 
> Furthermore, I'm wondering whether
> 
> 
> 
> 
> 
> 
> 
> couldn't be simplified to
> 
> 
> 
> 
> 
> 
> with the rest being done via CSS? Perhaps a  would be needed 
> within the  to get the vertical size right, but everything else 
> should be possible via CSS, I believe.
> 
> This change should reduce the size of the generated HTML big some 50% 
> or so, too.
> 
> 
> 
> Thanks for listening - if you disagree, please ignore and continue 
> working on something else ;)
> 
> 
> Regards,
> 
> Phil
> 
> 
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

The repo is here if you would like to offer your patch via Gerrit.
http://git.openstack.org/cgit/openstack-infra/ciwatch/

Thanks Philipp,
Anita.

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

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

[openstack-dev] [Neutron][L3-Subteam]

[Miguel Lavalle]

Dear Neutron L3 Subteam,

Our weekly IRC meetings on December 24th and 31st are canceled. Next
meeting will take place on January 7th at the usual time, 1500 UTC.

Enjoy the time off and thanks for your hard work
__
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] [Infra][magnum] Jenkins failed quite often for "Cannot set up guest memory 'pc.ram': Cannot allocate memory"

[Hongbin Lu]

Hi Jeremy,

If you can make the swap size consistent, that would be terrific. Consistent 
settings across test nodes can improve the predictability of the test results. 
Thanks for the assistant from infra team to locate the cause of this error. We 
greatly appreciate it.

Best regards,
Hongbin

-Original Message-
From: Jeremy Stanley [mailto:fu...@yuggoth.org] 
Sent: December-21-15 9:49 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Infra][nova][magnum] Jenkins failed quite often 
for "Cannot set up guest memory 'pc.ram': Cannot allocate memory"

On 2015-12-20 12:35:34 -0800 (-0800), Clark Boylan wrote:
> Looking at the dstat logs for a recent fail [0], it did help in that 
> more memory is available. You now have over 1GB available but still 
> less than 2GB.
[...]

As Clark also pointed out in IRC, the workers where this is failing lack a swap 
memory device. I have a feeling if you swapoff before this point in the job 
you'll see it fail everywhere.

For consistency, we probably should make sure that our workers have similarly 
sized swap devices (using a swapfile on the rootfs if necessary).
--
Jeremy Stanley

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

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

[openstack-dev] [puppet] weekly meeting #64

[Emilien Macchi]

For Christmas survivors, we can handle a weekly meeting tomorrow:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151222

If you have topics or reviews, go ahead in the etherpad.
Otherwise, we can chat on IRC and make triage during this week.

I take the opportunity to wish Merry Christmas, Happy New Year 2016 to
all OpenStack contributors, I wish you good time with your family and
friends,
Take care,
-- 
Emilien Macchi



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

[openstack-dev] [neutron][upgrade] next meeting Jan 11th

[Ihar Hrachyshka]

Hi all,

as per latest meeting discussion, we will have the next one Jan 11th.

See you all next year!

Ihar

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

Re: [openstack-dev] [oslo][nova][all] timeutils deprecation removals will break Nova

[ChangBo Guo]

Thanks Dims for raising  this up,  It seems the two commits got negative
scores due to Nova release schedule.
So can we restore abandoned commits, before that still would like to get
feedback from Nova guys.

2015-12-20 23:57 GMT+08:00 Davanum Srinivas :

> Nova folks,
>
> We have this review in oslo.utils:
> https://review.openstack.org/#/c/252898/
>
> There were failed effort in the past to cleanup in Nova:
> https://review.openstack.org/#/c/164753/
> https://review.openstack.org/#/c/197601/
>
> What do we do? Suggestions please.
>
> Thanks,
> Dims
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
ChangBo Guo(gcb)
__
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] [ThirdParty][CI] [patch] Status page at http://ci-watch.tintri.com/project

[Anita Kuno]

On 12/21/2015 09:20 AM, Philipp Marek wrote:
> Hi all,
> 
> I quite like the page at http://ci-watch.tintri.com/project - it gives 
> a very quick overview about the failures one should look into, and which to 
> ignore ;)
> 
> 
> Please let me state before anything else that I don't know any of the 
> restrictions that may have led into the current design - it's very likely 
> that I'm just missing a few points, and that some or all of my comments 
> below are invalid anyway. As always, take enough salt!
> 
> 
> One thing about that page that is bothering me is the performance... my 
> (current) Firefox asks me several times whether I'd like to stop the JS,
> or whether it should be allowed to continue.
> 
> With this patch (and a local exported copy of the page) I don't get asked 
> about that any more; it seems to give me a speedup of ~200, as no 
> intermediate lists need to be built and filtered any more:
> 
> $ diff -u verified.js.orig verified.js
> --- verified.js.orig2015-12-21 15:03:45.614529924 +0100
> +++ verified.js 2015-12-21 15:03:36.114432601 +0100
> @@ -33,9 +33,9 @@
>  $(document).ready(function () {
>$("colgroup").each(function (i, elem) {
>  if ($(elem).hasClass("verified-1")) {
> -  $("#results").find("td").filter(":nth-child(" + (i + 1) + 
> ")").addClass("verified-1");
> +  $("#results td:nth-child(" + (i + 1) + ")").addClass("verified-1");
>  } else if ($(elem).hasClass("verified1")) {
> -  $("#results").find("td").filter(":nth-child(" + (i + 1) + 
> ")").addClass("verified1");
> +  $("#results td:nth-child(" + (i + 1) + ")").addClass("verified1");
>  }
>});
>$("#verified1-button").on("click", toggle_verified_plus);
> 
> 
> Furthermore, I'm wondering whether
> 
> 
> 
> 
> 
> 
> 
> couldn't be simplified to
> 
> 
> 
> 
> 
> 
> with the rest being done via CSS? Perhaps a  would be needed within 
> the  to get the vertical size right, but everything else should be 
> possible via CSS, I believe.
> 
> This change should reduce the size of the generated HTML big some 50% or 
> so, too.
> 
> 
> 
> Thanks for listening - if you disagree, please ignore and continue working 
> on something else ;)
> 
> 
> Regards,
> 
> Phil
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

The repo is here if you would like to offer your patch via Gerrit.
http://git.openstack.org/cgit/openstack-infra/ciwatch/

Thanks Philipp,
Anita.

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

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Sheena Gregson]

+1 as well – this makes intuitive sense to me as a user, we should include
something in the mouseover text explaining that KVM acceleration will be
used if possible based on hardware capabilities



*From:* Vladimir Kuklin [mailto:vkuk...@mirantis.com]
*Sent:* Monday, December 21, 2015 9:35 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt
on Wizard



+1 to Andrey



On Mon, Dec 21, 2015 at 6:12 PM, Andrey Danin  wrote:

I suggest to call this item in the Wizard as "QEMU-KVM" with the following
description:
"Select this option if you want to use QEMU as a hypervisor with capability
of KVM acceleration."



On Mon, Dec 21, 2015 at 5:22 PM, Igor Kalnitsky 
wrote:

> Qemu is not a hypervisor This will be even more confusing.

It looks like hypervisor much more than libvirt. Moreover, according
to Wikipedia [1] (don't blame me guys) Qemu is Type-2 hypervisor.

[1] https://en.wikipedia.org/wiki/Hypervisor

> Today, when a user selects KVM, Fuel attempts to use KVM acceleration and
> defaults to QEMU in the case that KVM acceleration is not possible.

Sheena, are you sure it works this way? Some time ago we didn't
support this. However, I fully support this idea and believe this is
the way to go. In this case the hypervisor entry could be called
something like  "Qemu (+ KVM if available)".



On Mon, Dec 21, 2015 at 4:04 PM, Sheena Gregson 
wrote:
> We should collapse this into one entry - I don't have any preference on
> the naming convention, but as Fuel checks to see whether the hardware is
> capable of performing KVM acceleration, there's no reason to continue
> giving a selection to the user regarding KVM.
>
> Today, when a user selects KVM, Fuel attempts to use KVM acceleration and
> defaults to QEMU in the case that KVM acceleration is not possible.  We
> should keep this behavior and make the entry a single KVM/QEMU selection
> to eliminate the false perception of choice (and the ability for users to
> select the incorrect option).
>
> -Original Message-
> From: Bob Ball [mailto:bob.b...@citrix.com]
> Sent: Monday, December 21, 2015 7:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt
> on Wizard
>
>> On Mon, Dec 21, 2015 at 1:43 PM, Igor Kalnitsky
>> 
>> wrote:
>> > What about hypervisor "Qemu", and checkbox option on Settings tab -
>> > "Use KVM extension"?
>> Qemu is not a hypervisor This will be even more confusing.
>> I think "Libvirt" + some tooltip which says "Qemu and KVM" will be ok.
>
> Libvirt isn't a hypervisor either.  Note that Xen, Virtuozzo CT, Virtuozzo
> VM, LXC and KVM on ppc64 and s390x are all valid hypervisors to use with
> Libvirt and OpenStack (taken from
> http://docs.openstack.org/developer/nova/support-matrix.html)
>
> Bob
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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



-- 

Andrey Danin
ada...@mirantis.com
skype: gcon.monolake


__
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





-- 

Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][stable] Circular dependancy to resolve

[Matt Riedemann]

On 12/20/2015 5:35 PM, Tony Breeds wrote:

Hi all (Actually I'mm really looking a Dan, Sean and Matt)

We have a 2 changes in stable/liberty

https://review.openstack.org/#/c/248505 Add -constraints sections for CI jobs ; 
and
https://review.openstack.org/#/c/248877 Remove the TestRemoteObject class

If you grab 248505 and look at the git DAG you get:
$ git log --oneline --decorate  -3
83ca84a (HEAD -> review/sachi_king/bp/Requirements-Management) Add -constraints 
sections for CI jobs
6e2da82 Remove the TestRemoteObject class
94d6b69 (origin/stable/liberty, gerrit/stable/liberty) Omnibus stable fix for 
upstream requirements breaks

so 248877 is based on stable/liberty and 248505 is based on 248877

The problem is that 248877 Depends-On 248505[1]

I think the correct solution is to remove the Depends-On directive from 248877.

I didn't do that thing as:
1. I don't understand whay that there and could be missing something
2. Doing so would loose th 2+2's and +W anyway so wont really help.


Yours Tony.
[1] Well it Depends on Icbbb78cfcd074b0050e60c54557637af723f9b92 which maps to
 the same change in master and stable/liberty 



__
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



https://review.openstack.org/#/c/248505 depends on 
https://review.openstack.org/#/c/248877 because without it the unit 
tests fail in the constraints job, which we wanted to see passing before 
landing 248505, so they are stacked such that we could see the unit 
tests passing in the constraints job in 248877 when it's on top of the 
stack. I'm not sure why the depends-on was added to 248877, Sean added 
that I think.


We could remove the depends-on and I could fast approve, that's not a 
problem, but now the tempest job is failing on both so I'll have to 
check that out first.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Andrey Danin]

I suggest to call this item in the Wizard as "QEMU-KVM" with the following
description:
"Select this option if you want to use QEMU as a hypervisor with capability
of KVM acceleration."

On Mon, Dec 21, 2015 at 5:22 PM, Igor Kalnitsky 
wrote:

> > Qemu is not a hypervisor This will be even more confusing.
>
> It looks like hypervisor much more than libvirt. Moreover, according
> to Wikipedia [1] (don't blame me guys) Qemu is Type-2 hypervisor.
>
> [1] https://en.wikipedia.org/wiki/Hypervisor
>
> > Today, when a user selects KVM, Fuel attempts to use KVM acceleration and
> > defaults to QEMU in the case that KVM acceleration is not possible.
>
> Sheena, are you sure it works this way? Some time ago we didn't
> support this. However, I fully support this idea and believe this is
> the way to go. In this case the hypervisor entry could be called
> something like  "Qemu (+ KVM if available)".
>
>
> On Mon, Dec 21, 2015 at 4:04 PM, Sheena Gregson 
> wrote:
> > We should collapse this into one entry - I don't have any preference on
> > the naming convention, but as Fuel checks to see whether the hardware is
> > capable of performing KVM acceleration, there's no reason to continue
> > giving a selection to the user regarding KVM.
> >
> > Today, when a user selects KVM, Fuel attempts to use KVM acceleration and
> > defaults to QEMU in the case that KVM acceleration is not possible.  We
> > should keep this behavior and make the entry a single KVM/QEMU selection
> > to eliminate the false perception of choice (and the ability for users to
> > select the incorrect option).
> >
> > -Original Message-
> > From: Bob Ball [mailto:bob.b...@citrix.com]
> > Sent: Monday, December 21, 2015 7:32 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt
> > on Wizard
> >
> >> On Mon, Dec 21, 2015 at 1:43 PM, Igor Kalnitsky
> >> 
> >> wrote:
> >> > What about hypervisor "Qemu", and checkbox option on Settings tab -
> >> > "Use KVM extension"?
> >> Qemu is not a hypervisor This will be even more confusing.
> >> I think "Libvirt" + some tooltip which says "Qemu and KVM" will be ok.
> >
> > Libvirt isn't a hypervisor either.  Note that Xen, Virtuozzo CT,
> Virtuozzo
> > VM, LXC and KVM on ppc64 and s390x are all valid hypervisors to use with
> > Libvirt and OpenStack (taken from
> > http://docs.openstack.org/developer/nova/support-matrix.html)
> >
> > Bob
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Andrey Danin
ada...@mirantis.com
skype: gcon.monolake
__
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] [ThirdParty][CI] [patch] Status page at http://ci-watch.tintri.com/project

[Mikhail Medvedev]

On Dec 21, 2015 10:19 AM, "Asselin, Ramy"  wrote:
>
> Hi Phillip,
>
> Yes, please offer a patch to that repo Anita suggested. There's a small
group of us actively working on improving the code and eventually getting
ci-watch deployed in openstack.org. Your patch and help would be very much
appreciated.

+1

>
> We also meet bi-weekly in the 3rd party ci working group:
https://wiki.openstack.org/wiki/Meetings/ThirdParty
> We also discuss some issues in #openstack-third-party-ci
>
> Thanks!
> Ramy
>
> -Original Message-
> From: Anita Kuno [mailto:ante...@anteaya.info]
> Sent: Monday, December 21, 2015 6:52 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [ThirdParty][CI] [patch] Status page at
http://ci-watch.tintri.com/project
>
> On 12/21/2015 09:20 AM, Philipp Marek wrote:
> > Hi all,
> >
> > I quite like the page at http://ci-watch.tintri.com/project - it gives
> > a very quick overview about the failures one should look into, and
> > which to ignore ;)
> >
> >
> > Please let me state before anything else that I don't know any of the
> > restrictions that may have led into the current design - it's very
> > likely that I'm just missing a few points, and that some or all of my
> > comments below are invalid anyway. As always, take enough salt!
> >
> >
> > One thing about that page that is bothering me is the performance...
> > my
> > (current) Firefox asks me several times whether I'd like to stop the
> > JS, or whether it should be allowed to continue.
> >
> > With this patch (and a local exported copy of the page) I don't get
> > asked about that any more; it seems to give me a speedup of ~200, as
> > no intermediate lists need to be built and filtered any more:
> >
> > $ diff -u verified.js.orig verified.js
> > --- verified.js.orig2015-12-21 15:03:45.614529924 +0100
> > +++ verified.js 2015-12-21 15:03:36.114432601 +0100
> > @@ -33,9 +33,9 @@
> >  $(document).ready(function () {
> >$("colgroup").each(function (i, elem) {
> >  if ($(elem).hasClass("verified-1")) {
> > -  $("#results").find("td").filter(":nth-child(" + (i + 1) +
")").addClass("verified-1");
> > +  $("#results td:nth-child(" + (i + 1) +
> > + ")").addClass("verified-1");
> >  } else if ($(elem).hasClass("verified1")) {
> > -  $("#results").find("td").filter(":nth-child(" + (i + 1) +
")").addClass("verified1");
> > +  $("#results td:nth-child(" + (i + 1) +
> > + ")").addClass("verified1");
> >  }
> >});
> >$("#verified1-button").on("click", toggle_verified_plus);
> >
> >
> > Furthermore, I'm wondering whether
> >
> > 
> > 
> > 
> > 
> > 
> >
> > couldn't be simplified to
> >
> > 
> > 
> > 
> > 
> >
> > with the rest being done via CSS? Perhaps a  would be needed
> > within the  to get the vertical size right, but everything else
> > should be possible via CSS, I believe.
> >
> > This change should reduce the size of the generated HTML big some 50%
> > or so, too.
> >
> >
> >
> > Thanks for listening - if you disagree, please ignore and continue
> > working on something else ;)
> >
> >
> > Regards,
> >
> > Phil
> >
> >
> > __
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> The repo is here if you would like to offer your patch via Gerrit.
> http://git.openstack.org/cgit/openstack-infra/ciwatch/
>
> Thanks Philipp,
> Anita.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][stable] Circular dependancy to resolve

[Matt Riedemann]

On 12/21/2015 9:26 AM, Matt Riedemann wrote:



On 12/20/2015 5:35 PM, Tony Breeds wrote:

Hi all (Actually I'mm really looking a Dan, Sean and Matt)

We have a 2 changes in stable/liberty

https://review.openstack.org/#/c/248505 Add -constraints sections for
CI jobs ; and
https://review.openstack.org/#/c/248877 Remove the TestRemoteObject class

If you grab 248505 and look at the git DAG you get:
$ git log --oneline --decorate  -3
83ca84a (HEAD -> review/sachi_king/bp/Requirements-Management) Add
-constraints sections for CI jobs
6e2da82 Remove the TestRemoteObject class
94d6b69 (origin/stable/liberty, gerrit/stable/liberty) Omnibus stable
fix for upstream requirements breaks

so 248877 is based on stable/liberty and 248505 is based on 248877

The problem is that 248877 Depends-On 248505[1]

I think the correct solution is to remove the Depends-On directive
from 248877.

I didn't do that thing as:
1. I don't understand whay that there and could be missing something
2. Doing so would loose th 2+2's and +W anyway so wont really help.


Yours Tony.
[1] Well it Depends on Icbbb78cfcd074b0050e60c54557637af723f9b92 which
maps to
 the same change in master and stable/liberty 



__

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



https://review.openstack.org/#/c/248505 depends on
https://review.openstack.org/#/c/248877 because without it the unit
tests fail in the constraints job, which we wanted to see passing before
landing 248505, so they are stacked such that we could see the unit
tests passing in the constraints job in 248877 when it's on top of the
stack. I'm not sure why the depends-on was added to 248877, Sean added
that I think.

We could remove the depends-on and I could fast approve, that's not a
problem, but now the tempest job is failing on both so I'll have to
check that out first.



We should be good now. I removed the bad depends-on and re-approved. 
Dan's change is merged and the -constraints change is rechecked so that 
should go through now.


Thanks for bringing this up Tony.

--

Thanks,

Matt Riedemann


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

[openstack-dev] [neutron][bgpvpn] Meetings canceled

[Mathieu Rohon]

Hi,

tmorin and myself won't be available for the next two meetings.
The next weekly meeting for the networking-bgpvpn project will be on
tuesday, the 5th of january, at 15:00 UTC on #openstack-meeting-alt.

Thanks

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

Re: [openstack-dev] [oslo][nova][all] timeutils deprecation removals will break Nova

[Matt Riedemann]

On 12/20/2015 9:57 AM, Davanum Srinivas wrote:

Nova folks,

We have this review in oslo.utils:
https://review.openstack.org/#/c/252898/

There were failed effort in the past to cleanup in Nova:
https://review.openstack.org/#/c/164753/
https://review.openstack.org/#/c/197601/

What do we do? Suggestions please.

Thanks,
Dims



I have a -1 on the change, will state the same reason here. Without a 
cap on oslo.utils in stable/liberty g-r, this will break at least nova 
in stable/liberty since it's a backward incompatible change.


As with most things now, I think the path forward is getting nova onto 
the new code, raise the min required version of oslo.utils in mitaka to 
where the new methods were added (that's probably already the case if 
the deprecation happened awhile ago), and then the deprecated functions 
can't be removed until liberty-eol.


--

Thanks,

Matt Riedemann


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

[openstack-dev] [mistral] Team meeting minutes - 12/21/2015

[Renat Akhmerov]

Thanks for joining our meeting today!

Meeting minutes: 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-12-21-16.00.html
 

Meeting 
log:http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-12-21-16.00.log.html
 


Renat Akhmerov
@ Mirantis Inc.



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

[openstack-dev] [Neutron] Team meeting on Monday at 2100UTC

[Armando M.]

Hi neutrinos,

To spread some holiday cheer, we'll host the usual meeting, today at
2100UTC [1]

The meeting for Tuesday 29th will be cancelled.

Cheers,
Armando

[1] https://wiki.openstack.org/wiki/Network/Meetings
__
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