[openstack-dev] [gerrit] dell-afc-ci disabled but constantly connecting to gerrit

[Ian Wienand]

Hi,

There's a zombie account "dell-afc-ci" which was disabled in April [1]
that has been trying to connect to gerrit every 5 seconds since

 ...
 [2016-12-15 06:27:44,223 +] 946a4473 dell-afc-ci - AUTH FAILURE FROM 
143.166.116.138 inactive-account
 [2016-12-15 06:27:49,544 +] 9497a4aa dell-afc-ci - AUTH FAILURE FROM 
143.166.116.138 inactive-account
 [2016-12-15 06:27:54,766 +] 794789ee dell-afc-ci - AUTH FAILURE FROM 
143.166.116.138 inactive-account
 [2016-12-15 06:28:00,030 +] 0fac03fa dell-afc-ci - AUTH FAILURE FROM 
143.166.116.138 inactive-account
 [2016-12-15 06:28:05,329 +] 205ebb27 dell-afc-ci - AUTH FAILURE FROM 
143.166.116.138 inactive-account
 ...

That IP appears to be in Texas (maybe) if that helps.

If somebody Dell-ish could stop this, that would be great.

-i

[1] 
http://lists.openstack.org/pipermail/third-party-announce/2016-April/000301.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] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

[Joshua Hesketh]

On Thu, Dec 15, 2016 at 12:48 AM, Ian Cordasco 
wrote:

> -Original Message-
> From: Joshua Hesketh 
> Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Date: December 14, 2016 at 06:56:22
> To: OpenStack Development Mailing List ,
> openstack-infra 
> Subject:  Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls]
> Tagging liberty as EOL
>
> > The repos listed[0] have had stable/liberty branch removed and replaced
> > with a liberty-eol tag. Any open reviews have been abandoned.
> >
> > Please let me know if there are any mistakes or latecomers to the list.
> >
> > Cheers,
> > Josh
> >
> > [0]
> > https://gist.githubusercontent.com/tbreeds/
> 93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
>
> Glance was late to the party, but it should have had its liberty branches
> EOL'd as well.
>


Tony's comment on https://review.openstack.org/#/c/410536/ implies there
may be some steps to do first. I'll wait on confirmation from Tony before
retiring the branch.

Cheers,
Josh



>
> --
> Ian Cordasco
>
>
> __
> OpenStack Development Mailing 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-Infra] [all][stable][ptls] Tagging liberty as EOL

[Joshua Hesketh]

Hi Sumit,

That's fine. That repo wasn't marked for removal.

Cheers,
Josh

On Thu, Dec 15, 2016 at 3:28 PM, Sumit Naiksatam 
wrote:

> On Wed, Dec 14, 2016 at 4:54 AM, Joshua Hesketh
>  wrote:
> > The repos listed[0] have had stable/liberty branch removed and replaced
> with
> > a liberty-eol tag. Any open reviews have been abandoned.
> >
> > Please let me know if there are any mistakes or latecomers to the list.
>
> Hi Joshua, Apologies for chiming in late, but we request that the
> openstack/group-based-policy repo’s stable/liberty branch be _not_
> removed/EOL’ed and the currently open patches not be abandoned. We
> have consumers of this branch and we do backport bug fixes. Thanks in
> advance!
>
> ~Sumit.
>
> >
> > Cheers,
> > Josh
> >
> > [0]
> > https://gist.githubusercontent.com/tbreeds/
> 93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
> >
> > On Fri, Dec 9, 2016 at 3:55 PM, Joshua Hesketh  >
> > wrote:
> >>
> >> Hey Tony and all,
> >>
> >> I'm happy to take care of these retirements. However I probably can't
> get
> >> to it until Tuesday next week. So assuming no other infra root beats me
> to
> >> it I'll look at it then.
> >>
> >> Cheers,
> >> Josh
> >>
> >> On Thu, Dec 8, 2016 at 3:58 PM, Tony Breeds 
> >> wrote:
> >>>
> >>> On Tue, Nov 22, 2016 at 01:35:48PM +1100, Tony Breeds wrote:
> >>>
> >>> > I'll batch the removal of the stable/liberty branches between Nov
> 28th
> >>> > and Dec
> >>> > 3rd (UTC+1100).  Then during Decemeber I'll attempt to cleanup
> >>> > zuul/layout.yaml
> >>> > to remove liberty exclusions and jobs.
> >>>
> >>> This took longer as there are a few repos that are scheduled for EOL
> that
> >>> were a
> >>> little problematic during the kilo cycle.  I've updated the list at [1]
> >>>
> >>> Can the infra team please run eol_branch.sh [2] over the repos listed
> at
> >>> that
> >>> URL [1] and flagged with 'Please EOL'.  The others will need to be done
> >>> later.
> >>>
> >>> eol_branch.sh needs just the repo names what can be generated with
> >>> something like:
> >>>
> >>> URL=https://gist.githubusercontent.com/tbreeds/
> 93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
> >>> eol_branch.sh REPOS=$(curl -s $URL | awk '/Please EOL/ {print $1}')
> >>>
> >>> The data format is a balance between human and machine readable.
> >>>
> >>> Yours Tony.
> >>>
> >>> [1]
> >>> https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4
> ac#file-liberty_eol_data-txt
> >>> [2]
> >>> http://git.openstack.org/cgit/openstack-infra/release-tools/
> tree/eol_branch.sh
> >>>
> >>> ___
> >>> OpenStack-Infra mailing list
> >>> openstack-in...@lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> >>
> >>
> >
> >
> > ___
> > OpenStack-Infra mailing list
> > openstack-in...@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
__
OpenStack Development Mailing 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] [all][stable][ptls] Tagging liberty as EOL

[Sumit Naiksatam]

On Wed, Dec 14, 2016 at 4:54 AM, Joshua Hesketh
 wrote:
> The repos listed[0] have had stable/liberty branch removed and replaced with
> a liberty-eol tag. Any open reviews have been abandoned.
>
> Please let me know if there are any mistakes or latecomers to the list.

Hi Joshua, Apologies for chiming in late, but we request that the
openstack/group-based-policy repo’s stable/liberty branch be _not_
removed/EOL’ed and the currently open patches not be abandoned. We
have consumers of this branch and we do backport bug fixes. Thanks in
advance!

~Sumit.

>
> Cheers,
> Josh
>
> [0]
> https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
>
> On Fri, Dec 9, 2016 at 3:55 PM, Joshua Hesketh 
> wrote:
>>
>> Hey Tony and all,
>>
>> I'm happy to take care of these retirements. However I probably can't get
>> to it until Tuesday next week. So assuming no other infra root beats me to
>> it I'll look at it then.
>>
>> Cheers,
>> Josh
>>
>> On Thu, Dec 8, 2016 at 3:58 PM, Tony Breeds 
>> wrote:
>>>
>>> On Tue, Nov 22, 2016 at 01:35:48PM +1100, Tony Breeds wrote:
>>>
>>> > I'll batch the removal of the stable/liberty branches between Nov 28th
>>> > and Dec
>>> > 3rd (UTC+1100).  Then during Decemeber I'll attempt to cleanup
>>> > zuul/layout.yaml
>>> > to remove liberty exclusions and jobs.
>>>
>>> This took longer as there are a few repos that are scheduled for EOL that
>>> were a
>>> little problematic during the kilo cycle.  I've updated the list at [1]
>>>
>>> Can the infra team please run eol_branch.sh [2] over the repos listed at
>>> that
>>> URL [1] and flagged with 'Please EOL'.  The others will need to be done
>>> later.
>>>
>>> eol_branch.sh needs just the repo names what can be generated with
>>> something like:
>>>
>>> URL=https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
>>> eol_branch.sh REPOS=$(curl -s $URL | awk '/Please EOL/ {print $1}')
>>>
>>> The data format is a balance between human and machine readable.
>>>
>>> Yours Tony.
>>>
>>> [1]
>>> https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4ac#file-liberty_eol_data-txt
>>> [2]
>>> http://git.openstack.org/cgit/openstack-infra/release-tools/tree/eol_branch.sh
>>>
>>> ___
>>> OpenStack-Infra mailing list
>>> openstack-in...@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>>
>
>
> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

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

Re: [openstack-dev] [kolla][kolla-kubernetes] Call for Kolla-kubernetes use cases contribution

[Pete Birley]

duonghq,

Thanks for kicking this process off, it really fits in with the point
was raising about us needing to define the user experience that we are
looking to get with Kolla Kubernetes. However, I think before we jump
straight into composing a document on gerrit it may make morse sense
to have the initial discussion here?

>From my perspective, the project has really taken off on the
development front since Barcelona, with several new contributors,
including myself having jumped on board. In my opinion, this project
has a huge amount of potential for OpenStack, and Kubernetes alike, as
we aim to provide the building blocks that make it easy to consume
OpenStack services in harmony with the Kubernetes ecosystem.

I believe that Kolla was originally intended to use Kubernetes to
provide OpenStack services, but instead, moved towards a more
operator-friendly Ansible model as at the time the feature set that
Kubernetes provided was not sufficient to enable OpenStack operation
without serious compromise. Since then Kubernetes has come on leaps
and bounds and in addition to the Kolla-Kubernetes effort, several
other projects have appeared including Stackinetes[1], SAPCC OpenStack
Helm[2], AIC-Helm[3], and my own much smaller Harbor[4]. Each of these
has implemented OpenStack above Kubernetes in different ways, each
with merits and detractors, to meet the needs of their operators and
users. It's also worth noting the Hypernetes[5] project that took a
vastly different tack and built a Kuberentes distribution that
utilized OpenStack services to provide multi-tenancy.

In Barcelona is was decided that we (Kolla-Kubernetes), would move
from the original proprietary Jinja2 templating engine, to adopt the
Helm[6] tooling from Kubernetes to package OpenStack services. Helm is
also being used by both SAPCC OpenStack Helm, and AIC-Helm, to meet
their organization's needs.

There has been great progress on making this transition, taking the
original templates and converting them into individual Helm charts[6],
using a build methodology that we developed to facilitate this
conversion. This has meant that we have been able to make the
transition with no loss of service continuity but means that we are
probably not taking full advantage of the tooling that is now
available from our upstream vendor (Kubernetes).

This last point has become a point of contention at times within the
development team as we charge full tilt into developing technical
solutions following a technical specification[7] written to solve a
problem that, it is apparent to me at least, is not as well defined as
it could be. Leading to differing options to the direction we should
move in, though we all broadly share the same goals. As a result of
this, I would really appreciate it if we could spend a short amount of
time, most likely via this thread in the mailing list, trying to
define the experience we want our users to have (UX). I feel that if
this activity is going to be worthwhile it is really important that
for a minute we step back from discussing technical detail but define
the experience that we want our users to have.

It is also vital that we look to build bridges with the wider
OpenStack, and Kubernetes community for this project to be successful,
as we are so heavily invested in the tools they provide us with, and
we can mutually benefit from the with the experience that we both have
in terms of infrastructure lifecycle management.

I am also aware that there have been efforts in the past for groups to
get involved in Kolla-Kubernetes that have been unsuccessful. This has
been either because they have not been able to adapt to the OpenStack
way of working or, and much more concerningly because they have felt
significant resistance to their input, of which I myself have
certainly been guilty (eg Stackinetes kubernetes-entrypoint). This
potentially explains the number of projects that have a similar aim
that has sprung up outside of the OpenStack governance, and we should
try to learn as much from them as possible: why they exist, what
use-case they serve, and if it is possible for us to meet those aims
and collaborate in a way that is beneficial for both parties.

I personally feel that we should adopt Kubernetes tooling as much as
possible. Fuel-CCP[9], which is also under OpenStack Governance is a
project that utilises Kubernetes, but with their own tooling around
it, and I don't think that we should be looking to provide an
alternate, and potentially competing, implementation of this approach
if we are to be widely useful to a large number of stakeholders.

I was planning on taking on the work in the blueprint[8] that Brandon
(v1k0d3n) has proposed, though if you would like to take this on it
would be fantastic. I think this is particularly important at this
juncture as we begin the process of creating service layer
components[10] for Kolla-Kubernetes from the Microservice packages we
have produced.

I think that potentially the best way 

[openstack-dev] [kolla][kolla-kubernetes] Call for Kolla-kubernetes use cases contribution

[duon...@vn.fujitsu.com]

Dear Kollish,

As consensus from last weekly meeting [1], we need to define use cases for 
kolla-kubernetes,
so we can have more concrete ideas about what we should do next for Ocata cycle 
and next cycles.

After discussed on IRC [2], I created a patchset [3] for tracking use cases 
evolving. If you have ideas, please submit or comment to
this patchset.

[1] 
http://eavesdrop.openstack.org/meetings/kolla/2016/kolla.2016-12-14-16.00.log.html
[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/%23openstack-kolla.2016-12-15.log.html#t2016-12-15T02:48:07
[3] https://review.openstack.org/#/c/411043/


Thank you,

duonghq
PODC - Fujitsu Vietnam Ltd.



__
OpenStack Development Mailing 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] [vpnaas] vpnaas no longer part of the neutron governance

[Lingxian Kong]

On Wed, Dec 14, 2016 at 4:34 PM, Takashi Yamamoto 
wrote:

> hi,
>
> which driver are you using?
>

neutron.services.vpn.device_drivers.ipsec.OpenSwanDriver
__
OpenStack Development Mailing 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] Let's kill quota classes (again)

[joehuang]

If we don't update the default quota configuration at the same time for Nova 
services in different
physical nodes, then there is a chance for the quota control in dis-order 
period: for example, 
30 cores qutoa limit in one node, 20 cores quota limit in the other node.

Best Regards
Chaoyi Huang (joehuang)


From: Matt Riedemann [mrie...@linux.vnet.ibm.com]
Sent: 15 December 2016 10:42
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Let's kill quota classes (again)

On 7/18/2016 6:36 PM, Sean Dague wrote:
> On 07/14/2016 08:07 AM, Kevin L. Mitchell wrote:
>> The original concept of quota classes was to allow the default quotas
>> applied to a tenant to be a function of the type of tenant.  That is,
>> say you have a tiered setup, where you have gold-, silver-, and
>> bronze-level customers, with gold having lots of free quota and bronze
>> having a small amount of quota.  Rather than having to set the quotas
>> individually for each tenant you created, the idea is that you set the
>> _class_ of the tenant, and have quotas associated with the classes.
>> This also has the advantage that, if someone levels up (or down) to
>> another class of service, all you do is change the tenant's class, and
>> the new quotas apply immediately.
>>
>> (By the way, the turnstile integration was not part of turnstile itself;
>> there's a turnstile plugin to allow it to integrate with nova that's
>> quota_class-aware, so you could also apply rate limits this way.)
>>
>> Personally, it wouldn't break my heart if quota classes went away; I
>> think this level of functionality, if it seems reasonable to include,
>> should become part of a more unified quota API (which we're still
>> struggling to come up with anyway) so that everyone gets the benefit…or
>> perhaps shares the pain? ;)  Anyway, I'm not aware of anyone using this
>> functionality, though it might be worth asking about on the operators
>> list—for curiosity's sake, if nothing else.  It would be interesting to
>> see if anyone would be interested in the original idea, even if the
>> current implementation doesn't make sense :)
>
> We've already dropped the hook turnstile was using, so I don't see any
> reason not to drop this bit as well. I don't think it will work for
> anyone with the current code.
>
> I agree that this probably makes way more sense in common quota code
> then buried inside of Nova.
>
> -Sean
>

Following up on this, I missed the boat for Ocata, but got to talking
with melwitt about this again today and while I had it all in my head
again I've written a spec for Pike to deprecate the os-quota-class-sets API:

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

This essentially means no more custom quota classes (they aren't
functional today anyway), and no more controlling global default quota
limits via the REST API - that has to be done via the configuration
(after the microversion).

--

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 Development Mailing 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] [ci]

[Emilien Macchi]

On Wed, Dec 14, 2016 at 7:22 PM, Wesley Hayutin  wrote:
>
>
> On Fri, Dec 2, 2016 at 12:04 PM, Wesley Hayutin  wrote:
>>
>> Greetings,
>>
>> I wanted to send a status update on the quickstart based containerized
>> compute ci.
>>
>> The work is here:
>> https://review.openstack.org/#/c/393348/
>>
>> I had two passes on the morning of Nov 30 in a row, then later that day
>> the deployment started to fail due the compute node loosing it's networking
>> and became unpingable.   After poking around and talking to a few folks its
>> likely that we're hitting at least one of two possible bugs [1-2]
>>
>> I am on pto next week but will periodically check in and can easily retest
>> if these resolve.
>>
>> Thank you!
>>
>> [1] https://bugs.launchpad.net/ironic/+bug/1646477
>> [2] https://bugs.launchpad.net/tripleo/+bug/1646897 just filed
>>
>>
>
> Just a quick update,
> The container CI is successfully deploying the overcloud with the
> containerized compute node.

Do we have the job in place in tripleo CI? I might have missed the
info, but I don't see it yet.
Thanks!

Once we have it, we might want to run it for every patch in THT that
touch docker/* files.

> I need to update the instructions a bit so you may want to hold off on
> trying it out until you see an update.
>
> The heat ping test is failing, but this is progress and we're back on track
> :)
> The environment is running and logs are available, ping me personally if you
> need access.
>
> Thanks..
>
>
> Ping test failure:
>
> | stack_name| pingtest_stack
> | stack_owner   | None
> | stack_status  | CREATE_FAILED
> | stack_status_reason   | Resource CREATE failed: ResourceInError:
> |   | resources.server1: Went to status ERROR due to
> |   | "Message: No valid host was found. There are not
> enough
> |   | hosts available., Code: 500"
> | stack_user_project_id | e5fcd903a5004d59b8d3ad22aba0ae27
>



-- 
Emilien Macchi

__
OpenStack Development Mailing 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] Let's kill quota classes (again)

[Matt Riedemann]

On 7/18/2016 6:36 PM, Sean Dague wrote:

On 07/14/2016 08:07 AM, Kevin L. Mitchell wrote:

The original concept of quota classes was to allow the default quotas
applied to a tenant to be a function of the type of tenant.  That is,
say you have a tiered setup, where you have gold-, silver-, and
bronze-level customers, with gold having lots of free quota and bronze
having a small amount of quota.  Rather than having to set the quotas
individually for each tenant you created, the idea is that you set the
_class_ of the tenant, and have quotas associated with the classes.
This also has the advantage that, if someone levels up (or down) to
another class of service, all you do is change the tenant's class, and
the new quotas apply immediately.

(By the way, the turnstile integration was not part of turnstile itself;
there's a turnstile plugin to allow it to integrate with nova that's
quota_class-aware, so you could also apply rate limits this way.)

Personally, it wouldn't break my heart if quota classes went away; I
think this level of functionality, if it seems reasonable to include,
should become part of a more unified quota API (which we're still
struggling to come up with anyway) so that everyone gets the benefit…or
perhaps shares the pain? ;)  Anyway, I'm not aware of anyone using this
functionality, though it might be worth asking about on the operators
list—for curiosity's sake, if nothing else.  It would be interesting to
see if anyone would be interested in the original idea, even if the
current implementation doesn't make sense :)


We've already dropped the hook turnstile was using, so I don't see any
reason not to drop this bit as well. I don't think it will work for
anyone with the current code.

I agree that this probably makes way more sense in common quota code
then buried inside of Nova.

-Sean



Following up on this, I missed the boat for Ocata, but got to talking 
with melwitt about this again today and while I had it all in my head 
again I've written a spec for Pike to deprecate the os-quota-class-sets API:


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

This essentially means no more custom quota classes (they aren't 
functional today anyway), and no more controlling global default quota 
limits via the REST API - that has to be done via the configuration 
(after the microversion).


--

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] [QA] Meeting Thursday Dec 15th at 9:00 UTC

[GHANSHYAM MANN]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Dec 15th at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_December_15th_2016_.280900_UTC.29


Anyone is welcome to add an item to the agenda.

To help people figure out what time 9:00 UTC is in other timezones the next
meeting will be at:

04:00 EST

18:00 JST

18:30 ACST

11:00 CEST

04:00 CDT

02:00 PDT

-gmann
__
OpenStack Development Mailing 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] parameter validation for GET /servers - current concensus from the Nova API meeting

[Matt Riedemann]

On 12/14/2016 8:54 AM, Sean Dague wrote:

We spent most of the Nova API meeting today to try to get to a concensus
space on https://review.openstack.org/#/c/393205/ which is about
validating the parameters passed for sorting / filtering on the servers
resource. Today, we pretty much take whatever you throw in there and jam
it in the sql filters so we're bleeding out internal details, and
letting you do weird things like sort on join tables which causes
potential major performance issues.

The solution is be explicit about the filters that we support. The
challenge is going from weird grey space where none of this is well
defined, to a well defined space.

We all AGREED that we need to be explicit about what's supported, the
current state of the world is madness.

We still need final agreement on what that whitelist is. John and Alex
are going to validate that over the next day or so. The intent is to
keep this pretty wide to anything sensible in the REST representation
that's not going to kill us on the join tables side.

One of the sticking points on the spec was the idea that everything in
the filter/sort whitelist needed performant indexes. This was going to
make the whitelist smaller, then got push back from ops that really want
some of those other things.

We all AGREED to *drop* that requirement on indexing everything. With
Cells v2 coming, searchlight going to be needed for efficient full cloud
searching of instances, the entire performance profile of a lot of these
are going to change over the next couple of cycles. Instead of focusing
on tightening those up now, we should just include documentation on how
to performance tune your db if your users are regularly using filters we
don't optimize for.

This REMOVES the need for the policy point which was going to allow
these things, as we'll keep the whitelist large. It means every cloud
has the same behavior.

Lastly, there was the question of admin vs. non admin allowed parameters.

We AGREED that the only things we'd make admin only are things that leak
cloud internals, which is node/host attributes. In an ideal future we'd
like non admin users to be able to operate on the hashed versions of
these (currently a sha(project_id + host)), however that's all done
python side now for display, so it's not really an option today.

This would make things like `project_id` and `all_tenants` valid filters
for regular users. However, if we interpret them within the user's
context, that's fine. `all_tenants` means "All tenants that I am allowed
to see". For a Nova admin, that's everyone. In a future with
hierarchical multi tenancy, this might be a subtree. project_id is fine
as long as it's filtered by the project_id's you have access to in your
context. Mostly it will be a noop for normal users, but there is no
reason not to allow it. Plus it does create a soft roll into
hierarchical multi tenancy.


We also AGREED that we really need to get the spec into a merge state by
Friday, and that folks would start working on code under the assumption
that the agreement above is where we are headed. The only really
remaining sticking point is the exact content of the whitelist, which
John and Alex are going to focus on. Then clean up language in the spec.

For folks not in this meeting, please make sure we didn't miss anything
here. Hopefully we can get this closed shortly.

Thanks a bunch,

-Sean



This all sounds good to me. I'm glad we're keeping the non-joined-column 
whitelist open to things that we already represent in the server details 
response, and that we're removing the part about the policy config for 
the whitelist. And I like that we don't have to obsess over what is 
indexed and what isn't. I think there is some low hanging fruit that we 
could index as obvious things a lot of people probably already filter 
on, which we could actually just handle independently of the spec. We 
actually did something like that already [1] as a result of an earlier 
review on this spec.


I could see the all_tenants stuff being a bit confusing at first just 
because people are probably so used to that being admin-only with no 
exceptions for so long. But I think as long as non-admins only see 
servers in their tenant by default, that's fine and backward compatible.


Thanks for recapping the discussion here and moving this forward as I've 
admittedly not been very involved in reviewing this spec and have 
probably muddied the waters when I did.


[1] 
https://github.com/openstack/nova/commit/887cc5243eeef7028aafb393948abd320893179b


--

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] [tricircle]Discussion on VxLAN L2 networking across Neutron

[joehuang]

Hello,

As we discussed yesterday in the weekly meeting, we'd like to have one online 
etherpad discussion on VxLAN L2 networking across Neutron.

The etherpad link is : 
https://etherpad.openstack.org/p/TricircleVxLANL2Networking
Time: start from UTC2:00am(China 10:00am, Korea/Japan 11:00am), 1 hour meeting
Date: Dec.15, 2016

Best Regards
Chaoyi Huang (joehuang)
__
OpenStack Development Mailing 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] [ci]

[Wesley Hayutin]

On Fri, Dec 2, 2016 at 12:04 PM, Wesley Hayutin  wrote:

> Greetings,
>
> I wanted to send a status update on the quickstart based containerized
> compute ci.
>
> The work is here:
> https://review.openstack.org/#/c/393348/
>
> I had two passes on the morning of Nov 30 in a row, then later that day
> the deployment started to fail due the compute node loosing it's networking
> and became unpingable.   After poking around and talking to a few folks its
> likely that we're hitting at least one of two possible bugs [1-2]
>
> I am on pto next week but will periodically check in and can easily retest
> if these resolve.
>
> Thank you!
>
> [1] https://bugs.launchpad.net/ironic/+bug/1646477
> [2] https://bugs.launchpad.net/tripleo/+bug/1646897 just filed
>
>
>
Just a quick update,
The container CI is successfully deploying the overcloud with the
containerized compute node.
I need to update the instructions a bit so you may want to hold off on
trying it out until you see an update.

The heat ping test is failing, but this is progress and we're back on track
:)
The environment is running and logs are available, ping me personally if
you need access.

Thanks..


Ping test failure:

| stack_name| pingtest_stack

| stack_owner   | None

| stack_status  | CREATE_FAILED

| stack_status_reason   | Resource CREATE failed: ResourceInError:

|   | resources.server1: Went to status ERROR due to

|   | "Message: No valid host was found. There are not
enough
|   | hosts available., Code: 500"

| stack_user_project_id | e5fcd903a5004d59b8d3ad22aba0ae27
__
OpenStack Development Mailing 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] [requirements] No meetings until January 2017

[Tony Breeds]

Hi all,

Given the upcoming holidays, there will not be any requirements meetings for
the remainder of the year. That puts the next one at January 4, 2017.

Thanks for a great year.

Yours Tony.


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

Re: [openstack-dev] Golang technical requirements

[Monty Taylor]

On 12/14/2016 09:56 AM, Doug Hellmann wrote:
> Excerpts from Dean Troyer's message of 2016-12-14 08:15:08 -0600:
>> On Wed, Dec 14, 2016 at 7:46 AM, Doug Hellmann  wrote:
>>> FWIW, some of the deployment tool communities (ansible and puppet,
>>> I think) rely on git repos without external artifacts, and we're
>>> supporting them in our release tools today. I'm not sure how
>>> downstream packagers feel about the lack of external artifacts.
>>
>> I recall zigo working hard for the Debian packaging to come strictly
>> from Git repo tags but do not recall seeing opinions from other
>> packagers.
>>
>>> Were you thinking of files other than the tarball when you say
>>> "generated files"?
>>
>> Yes, in particular, files like AUTHORS and sample config files, which
>> IIRC are generated and included in tarballs.
> 
> OK, those should be easy enough to deal with if we publish tarballs
> of golang source. Perhaps someone from one of our other projects
> that uses git tags as releases can comment on how they handle those
> things?

In oaktree, which has golang bindings, and also because of gRPC/protobuf
has generated files -  I have followed what I could see of other folks
and ... checked the generated files into git, along with a gate job to
ensure that patches that change the source of those generated files are
always accompanied by changes to the generated files (and that the
generated file content is the same)

It makes me feel dirty - but with the gate check it doesn't bother me as
much as it would have in times past. Other people theoretically wanting
to consume those go bindings as a library need to be able to do so with
go get - and that means the files need to be there.

For things we generate in pbr - like AUTHORS and ChangeLog - assuming we
want to do the same thing in go, we could likely come up with something
similar. I also think we should consider that perhaps those two files
are not needed if the primary expectation for distribution is git.

__
OpenStack Development Mailing 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] [release][ptl][all] self-service branch management

[Tony Breeds]

On Wed, Dec 14, 2016 at 08:51:29AM -0500, Ian Cordasco wrote:

> I do have one question, will creating the branch's end-of-life
> eventually work the same way? For example, Glance's projects were
> missed in the recent liberty end of life work. Could we submit a

For the record glance repos were deliberately pushed to phase 2 as when I
generated the list there was an open review to tag the EOL release and then
once that was done it' was only partially successful and I wanted to allow for
any corrective action required.

> review to do that work so Josh & Tony don't have to or is that
> something that isn't planned to work through openstack/releases?

As Jeremy and Doug have explained that's the plan but it'll be pike before most
of the tools are written and then we'll be blocked on the 2.14 (possibly 2.13)
gerrit release and deployment to our infrastructure.

Yours Tony.


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

Re: [openstack-dev] Golang technical requirements

[Monty Taylor]

On 12/13/2016 04:45 PM, Dean Troyer wrote:
> On Tue, Dec 13, 2016 at 4:26 PM, Jay Pipes  wrote:
>> Not sure if it's already been brought up, but I really like govendor:
> 
> Govendor and glide are the two most promising candidates at this
> point.  I just read today's summary of the Package Management
> Committee [0] and that sounds _really_ promising, if further out than
> we can wait on, but there will be migration paths from many of the
> existing tools.  Both govendor and glide have devs in the Advisory
> Group to the committee.

Yup - looked at govendor, glide and godep back in May:

https://review.openstack.org/315200 - glide
https://review.openstack.org/315196 - govendor
https://review.openstack.org/315029 - godep

>> More than the decision between dependency management toolkits, though, is
>> the decision over whether to have *any* vendored source code in the primary
>> project's source tree itself (as opposed to only storing the
>> vendor.json/glide.yaml|lock file that lists dependent library versions and
>> locations). Please let's have a policy of keeping vendored source code *out*
>> of the primary project source tree.
> 
> This is the intention and I see no reason why it is not achievable.
> It totally depends (ha!) on having better (any!) dependency management
> in place.

++

I think we're all fairly well agreed on not vendoring code in OpenStack.
IANAL but I also think our CLA would make a patch to vendor code into an
OpenStack repo particularly legally strange. (a contributor quite simply
does not have the legal standing to apply the terms of our CLA to the
vendored code) I don't know for a fact that this is strictly
problematic, but given that it does seem at best grey, and the fact that
vendoring code is a TERRIBLE engineering decision, I'm pretty sure we
can steer clear of it.

I will be happy to write up such a policy if we think it would be good
to have one on the books?

> One thing that I have been pondering is resurrecting the old technique
> of embedding version info into binaries so they can be examined to
> discover which library versions were used in its build.  This was
> totally a thing when I was using rcs ($Id$ and ident(1) FTW) but that
> particular technique is messy with distributed version control, and
> may not be needed at all in a packaged distro environment.  This may,
> however, help ease the concerns many have around static linking of
> libs.
> 
> dt
> 
> [0] https://blog.gopheracademy.com/advent-2016/saga-go-dependency-management/
> 


__
OpenStack Development Mailing 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] multi-attach-volume for rbd

[Matt Riedemann]

On 12/14/2016 3:53 PM, Shane Peters wrote:

Hello all,

Per https://review.openstack.org/#/c/283695/ multi-attach was disabled
for rbd volumes.

Does anyone know what features are missing or aren't compatible in rbd
for it to support multi-attach?

Thanks
Shane


__
OpenStack Development Mailing 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 doesn't support multiattach volumes for any Cinder backend. That's 
being worked by the Nova and Cinder teams but won't be something that's 
implemented on the Nova side in the Ocata release, and will be a stretch 
probably for Pike. There are weekly meetings about this though, see:


http://eavesdrop.openstack.org/#Cinder,_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

[openstack-dev] devstack with neutron, OVS and sfc?

[Michael Gale]

Hello,

I used posted this on the openstack user list but it might be a better
question for this group.

Does anyone know if neutron-sfc is working in devstack?

I started to follow the instructions here:
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining#
Single_Host_networking-sfc_installation_steps_and_testbed_setup

I ended up with a working devstack instance using:
- Ubuntu 16.04
- newton stable branches for devstack and networking-sfc
- I set an environment var to disable OVS recompile since 16.04 comes with
OVS 2.5.0 and the recompil was failing during the build.

I could build VM's, networks and I believe I setup a sfc implementation
correctly (portpairs, portgroups, portclassification, etc). I created a
ServiceVM on the same internal network as my source VM and used an neutron
router to access the outside world. I tried to route all outbound traffic
on port 80 through my ServiceVM.

The issue I ran into was that my ServiceVM would only see the initial
outbound SYN's after that the return traffic and data packets would always
go between the source VM and the external web server only.

>From the different test scenarios I ran, I could always see the initial
outbound SYN packets however it always seems that the neutron router would
route the return packets back via the normal routing rules and ignore my
sfc setup

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

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Michał Jastrzębski]

I agree that meeting notes are crucial to this type of meeting.I just say
that gerrit PoC/demo is valid form of 'notes' if meeting was about some
implementional detail, which I assume is the case for this type of meetings.

Do we agree that as hoc hangout meetings are acceptable form of cooperation
if invitation is own and notes are published?

On Dec 14, 2016 12:57 PM, "Jeremy Stanley"  wrote:

> On 2016-12-14 14:37:26 -0600 (-0600), Ian Cordasco wrote:
> > From: Michał Jastrzębski 
> [...]
> > > Ian, you mentioned that gerrit as outcome of hangout violates 4
> > > opens...how?
> >
> > The artifacts of any meeting should include meeting notes. IRC
> > meetings have this autogenerated for us.
> [...]
>
> Another excellent example of this is design summit sessions. Not
> everyone can manage to attend in person, and remote involvement of
> more than one or two additional participants can be extremely
> challenging. We do, however, have an expectation that there are
> summaries of those discussions published to our mailing lists so
> that those who were excluded from the initial conversation can see
> what was discussed and follow up with feedback of their own there.
> --
> 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

Re: [openstack-dev] [tripleo] release status

[Jason Rist]

On 12/14/2016 03:21 PM, Emilien Macchi wrote:
> On Tue, Dec 13, 2016 at 5:02 PM, Emilien Macchi  wrote:
> > I thought it would be useful to share our roadmap for TripleO releases.
> > As a reminder, this is the official source of trust for OpenStack
> > releases schedule:
> > https://releases.openstack.org/ocata/schedule.html
> >
> > Over the last weeks, we discussed about how TripleO project would
> > produce better releases without stressing people at pushing for
> > features late in cycles.
> >
> > - tripleo-specs for Ocata need to be merged by ocata-2 or will be
> > postponed to Pike.
> > - blueprints scheduled for ocata-2 with good progress will be
> > postponed to ocata-3.
>
> done. Though I found 44 blueprints for ocata-3 too big, we'll review
> them and eventually postpone some of them, as this number doesn't
> sound realistic.
>
> > - blueprints scheduled for ocata-2 with zero or low progress will be
> > postponed to pike-1.
>
> I did that operation today. Please let me know if you disagree if your
> blueprint moved to pike-1 and we can discuss about it.
>
> > - we'll release ocata-2 end of this week.
>
> done: https://review.openstack.org/#/c/410958/
>
> > - we'll release a new Newton release next week.
> > - by the end of ocata-3, we'll stop pushing for features except
> > Composable Upgrades which is our critical thing during this cycle.
> > Anything else will be frozen and postponed to Pike.
> > - we'll threat FFE case by case but if the FFE is not related to a
> > blueprint that was targeted for ocata-3, no need to ask, it will be
> > rejected.
> > - between end of ocata-3 and final ocata release, we have 5 weeks. We
> > might want to spend time on stabilization, bug fixing (we currently
> > have more than 100 bugs open, just for ocata-2) and keep CI stable
> > until final release. The last thing we want is to push for last
> > features and stress people because it breaks all the things.
> >
> > Please provide any feedback, it's highly welcome.
> > --
> > Emilien Macchi
>
>
>
I'll be going through and moving a bunch to Pike soon as well.

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
OpenStack Development Mailing 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] release status

[Emilien Macchi]

On Tue, Dec 13, 2016 at 5:02 PM, Emilien Macchi  wrote:
> I thought it would be useful to share our roadmap for TripleO releases.
> As a reminder, this is the official source of trust for OpenStack
> releases schedule:
> https://releases.openstack.org/ocata/schedule.html
>
> Over the last weeks, we discussed about how TripleO project would
> produce better releases without stressing people at pushing for
> features late in cycles.
>
> - tripleo-specs for Ocata need to be merged by ocata-2 or will be
> postponed to Pike.
> - blueprints scheduled for ocata-2 with good progress will be
> postponed to ocata-3.

done. Though I found 44 blueprints for ocata-3 too big, we'll review
them and eventually postpone some of them, as this number doesn't
sound realistic.

> - blueprints scheduled for ocata-2 with zero or low progress will be
> postponed to pike-1.

I did that operation today. Please let me know if you disagree if your
blueprint moved to pike-1 and we can discuss about it.

> - we'll release ocata-2 end of this week.

done: https://review.openstack.org/#/c/410958/

> - we'll release a new Newton release next week.
> - by the end of ocata-3, we'll stop pushing for features except
> Composable Upgrades which is our critical thing during this cycle.
> Anything else will be frozen and postponed to Pike.
> - we'll threat FFE case by case but if the FFE is not related to a
> blueprint that was targeted for ocata-3, no need to ask, it will be
> rejected.
> - between end of ocata-3 and final ocata release, we have 5 weeks. We
> might want to spend time on stabilization, bug fixing (we currently
> have more than 100 bugs open, just for ocata-2) and keep CI stable
> until final release. The last thing we want is to push for last
> features and stress people because it breaks all the things.
>
> Please provide any feedback, it's highly welcome.
> --
> Emilien Macchi



-- 
Emilien Macchi

__
OpenStack Development Mailing 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] [release] Does the Ocata short cycle have an impact on planned EOL dates ?

[Davanum Srinivas]

On Wed, Dec 14, 2016 at 5:11 PM, Jeremy Stanley  wrote:
> On 2016-12-14 16:42:05 -0500 (-0500), David Moreau Simard wrote:
> [...]
>> This would lead upstream OpenStack (and downstream distros) to
>> support 3 stable releases for a good while.
> [...]
>
> We (upstream) supported stable/newton, stable/mitaka and
> stable/liberty branches concurrently for a span of roughly 3 months
> (from Newton rc1 until Liberty EOL), so it's not as if it's
> impossible for us to do the same thing for an additional month or so
> beyond that to accommodate the shorter Ocata development cycle.

+1 Jeremy!

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



-- 
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] [release] Does the Ocata short cycle have an impact on planned EOL dates ?

[Jeremy Stanley]

On 2016-12-14 16:42:05 -0500 (-0500), David Moreau Simard wrote:
[...]
> This would lead upstream OpenStack (and downstream distros) to
> support 3 stable releases for a good while.
[...]

We (upstream) supported stable/newton, stable/mitaka and
stable/liberty branches concurrently for a span of roughly 3 months
(from Newton rc1 until Liberty EOL), so it's not as if it's
impossible for us to do the same thing for an additional month or so
beyond that to accommodate the shorter Ocata development cycle.
-- 
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

Re: [openstack-dev] [release][ptl][all] self-service branch management

[Doug Hellmann]

Excerpts from Emilien Macchi's message of 2016-12-14 15:34:27 -0500:
> On Wed, Dec 14, 2016 at 8:45 AM, Doug Hellmann  wrote:
> > [Sending again due to mail delivery issues.]
> >
> > The release team is pleased to announce that the branch automation
> > work is now complete, and that teams can now manage feature and
> > stable branch creation through the openstack/releases repository.
> >
> > Creating a branch is very similar to creating a release: Edit the
> > appropriate file in the releases repo to add the branch information,
> > let the release team review it, and then when the patch is approved
> > the bots make your branch. New branches come with patches to update
> > .gitreview, reno, and constraint settings where needed.
> >
> > For the complete details about how to format a branch request, see
> > the README.rst file in the repo [1].
> >
> > Thanks, as always, to the Infra team for their help in implementing
> > this automation.
> 
> That's awesome, and we were looking forward to it.
> Regarding schedule, it's not clear to me when we *have to* propose the 
> branches.
> 
> For example in TripleO, we've noticed that our work on upgrades
> usually happens more at the end of a cycle so we would like to wait
> for the last time before branching our repos.
> Example with Ocata, when would you suggest to start branching?

We will expect most teams following the cycle-with-milestones model
to branch at RC1, as part of the usual milestone-centric process.

Projects following-the cycle-with-intermediary or cycle-trailing
models should branch when the equivalent of their first release
candidate is ready. It's going to be up to the individual teams to
decide that, because you're better placed to know when it's too
early to branch. Keep in mind that the reason the milestone-based
projects use release candidates is to have a stable version of the
project ready to be tested before being marked as a final release.

Based on that criteria, when development (feature and bug fixing)
slows down toward the end of the cycle, start thinking about
branching.

Doug

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

[openstack-dev] multi-attach-volume for rbd

[Shane Peters]

Hello all,

Per https://review.openstack.org/#/c/283695/ multi-attach was disabled for
rbd volumes.

Does anyone know what features are missing or aren't compatible in rbd for
it to support multi-attach?

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

[openstack-dev] [nova] No cells meetings until 2017

[Dan Smith]

Hi all,

Given the upcoming holidays, there will not be nova cells meetings for
the remainder of the year. That puts the next one at January 4, 2017.

--Dan

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

[openstack-dev] [release] Does the Ocata short cycle have an impact on planned EOL dates ?

[David Moreau Simard]

Hello,

Typically, OpenStack releases have EOL'd approximately one year after
being released [1].
Another way to look at it is that OpenStack has usually kept no more
than 2 stable releases going at a time, deprecating the oldest one
once the newest release was shipped.

With the Ocata short cycle and it's release due in February, I was
wondering if this had an impact on the Mitaka or Newton planned EOL
dates.
Mitaka is slated for an April 2017 EOL while Newton doesn't really
have one yet but one could guess with the existing pattern it'd be in
October 2017.

This would lead upstream OpenStack (and downstream distros) to support
3 stable releases for a good while.

So, $subject ?

[1]: https://releases.openstack.org/

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

__
OpenStack Development Mailing 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] [octavia] Meeting time and cancellations

[Michael Johnson]

Hello Octavia folks!

I wanted to remind folks to enter their timezone information in the
etherpad to help us come up with a meeting time that works for
everyone.  Please do so here:
https://etherpad.openstack.org/p/octavia-weekly-meeting-time

At the octavia IRC meeting today we agreed to take a break from our
weekly IRC meetings for the next two weeks.  Many of us are taking
some vacation time.

Octavia IRC meetings will resume on January 4th.

Michael

__
OpenStack Development Mailing 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] [octavia] Re: [infra][neutron] RADWARE CI voting permission in Neutron

[Michael Johnson]

I have talked with Izik on IRC and have started work to get this fixed.

I will be setting up the octavia-ci group and fixing the permissions.

Michael

On Wed, Dec 14, 2016 at 12:49 AM, Ihar Hrachyshka  wrote:
> Izik Penso  wrote:
>
>> Hi Neutron, Infra Cores,
>>
>> Radware CI  would like to acquire voting (+/-1 Verified) permission.
>>
>> We voted before but we had to install a new CI and also changed our old
>> gerrit user with a new user because ssh key issues.
>>
>> We are triggered by neutron-lbaas changes.
>> https://wiki.openstack.org/wiki/ThirdPartySystems/Radware_CI
>>
>> Old user: radware3rdpartytesting
>> New user: radware3rdparty
>> email : openstack3rdpartytest...@radware.com
>>
>> See our comments :
>> https://review.openstack.org/#/c/343963/
>> https://review.openstack.org/#/c/28/
>> https://review.openstack.org/#/c/408534/
>> https://review.openstack.org/#/c/408105/
>
>
> So the CI is for LBaaS repo only? Then I believe you should talk to Octavia
> team that now maintains neutron-lbaas. Adding [octavia] to the topic.
>
> 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

__
OpenStack Development Mailing 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] [fuxi][kuryr][cinder][manila][all] Introduce the Fuxi project

[Hongbin Lu]

Hi all,

I wrote this email to introduce Fuxi [1], a Kuryr sub-project for providing 
container persistency by leveraging existing OpenStack infrastructure (i.e. 
Cinder, Manila, etc.). As a brief introduction, Fuxi is for bridging container 
storage models to existing OpenStack storage abstractions (As you might know, 
Kuryr is for bridging container networking models to OpenStack networking 
abstractions. You could consider Fuxi is the storage equivalent). At current 
stage, the Fuxi team wanted to get more inputs from the broader community to 
shape its roadmap. If you have any use cases about container persistency on 
OpenStack, we would love to hear. You are welcome to write down your inputs to 
the etherpad below or reply to this thread.

https://etherpad.openstack.org/p/container-storage-openstack

tldr;
The Fuxi team was found at 2016-03-04, and joined OpenStack as a Kuryr 
sub-project at 2016-08-02. Thanks to the hard work of our team members, we 
implemented a basic Docker volume plugin that interfaces with Cinder. In the 
review queue, there is a patch that adds support for Manila as Cinder 
alternative. Generally speaking, how Fuxi works is to implement a remote Docker 
volume plugin API. As a result, once the Docker daemon wanted to 
create/mount/remove a data volume, it will invoke the API of the Fuxi-provided 
plugin. The plugin will receive the request from Docker daemon and translate it 
to a set of API calls to Cinder (or others). Fuxi has two important concepts: 
volume provider and volume connector. A volume provider represents a backend 
service who provides the volumes. Currently, Cinder is the only supported 
volume provider. Volume connector is the framework to connect to the created 
volume. There are two implementation of volume connector: os-brick connector 
and OpenStack connector. The os-brick connector leverages the os-brick library 
to connect apparently. The OpenStack connector leverages the standard APIs of 
OpenStack services (i.e. Cinder, Nova, etc.) to attach volumes to container 
hosts.

At current stage, the Fuxi team is committed to enhance the existing 
implementations. At the mean time, we would like to collect more feedback from 
community to decide the roadmap. In particular, there are several ideas that 
have been brainstormed by different people:
* Implement an OpenStack volume plugin for Kubernetes (it seems k8s already 
talked to Cinder so we need to revisit if this is a good idea).
* Implement an OpenStack volume plugin for Mesos.
* Implement volume plugin for other container runtimes (i.e. rkt, oci 
containers, etc.).
* Support external volume providers (i.e. AWS EBS).

We would like to hear your feedback to determinate if the above ideas fits into 
the project roadmap. In addition, you are more than welcome to contribute more 
ideas, use cases, or comments. Last but not least, the Fuxi team is looking for 
more contributors. You are welcome to join the team if you find this project 
exciting. There will be a lot of items that need an owner.

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

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

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Jeremy Stanley]

On 2016-12-14 14:37:26 -0600 (-0600), Ian Cordasco wrote:
> From: Michał Jastrzębski 
[...]
> > Ian, you mentioned that gerrit as outcome of hangout violates 4
> > opens...how?
> 
> The artifacts of any meeting should include meeting notes. IRC
> meetings have this autogenerated for us.
[...]

Another excellent example of this is design summit sessions. Not
everyone can manage to attend in person, and remote involvement of
more than one or two additional participants can be extremely
challenging. We do, however, have an expectation that there are
summaries of those discussions published to our mailing lists so
that those who were excluded from the initial conversation can see
what was discussed and follow up with feedback of their own there.
-- 
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

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Ian Cordasco]

 

-Original Message-
From: Michał Jastrzębski 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: December 14, 2016 at 09:58:33
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

> OK, I think we had some grave misunderstandings here.
>  
> 1. ad-hoc meetings *are not* and *were never meant to be* replacement
> for weekly meetings. Kolla community is single community across all
> its deliverables and we hold common meetings, chats and mailing list.
> Also, as long as I'm PTL, I'm unwilling to change that.

Unwilling to change holding video meetings that appear to be exclusive to 
members of your own community? If you're taking exclusionary actions as PTL, 
that seems like you're actively discouraging community involvement in the 
subject(s) of those meetings.

> 2. Hangouts were never exclusive purposefully. Meeting link was always
> posted on irc, and nobody were excluded apart from people not present
> on irc at given time.

Intent is not magical. The reality is that people have found them to be 
exclusive. So regardless of your intent, you need to find a better way to work 
around the communication problems or to make the results of the meeting more 
accessible.

> 3. Language barrier is something to acknowledge. I would say if we
> find ourselves in situation where one of hangout users has problem
> communicating, we either move to IRC or try hard to accommodate his or
> hers language barrier. But on few hangouts I was on, that was not the
> case. If somebody didn't join because they were ashamed, please, feel
> free to approach me on private message (or if I'm not around, hangout
> organizer) and let me know. That would be reason enough to stick to
> IRC in my book
> 4. Hangouts were never exclusive to core team. Just happened that core
> reviewers were majority of it - not planned or enforced.
> 5. Only "exclusiveness" I can think of in context of ad hoc meetings
> are that people who aren't around irc cannot have voice on this
> meeting. Simply because they aren't around and meeting was unplanned.
> That's the case with *any* discussion outside of dedicated 1hr every
> week. Granted, irc has logs. Hangouts can have notes, or outcome could
> be reflected as PoC in gerrit for example (which was the case of
> hangout in question..).
>  
> Ian, you mentioned that gerrit as outcome of hangout violates 4 opens...how?

The artifacts of any meeting should include meeting notes. IRC meetings have 
this autogenerated for us. Even if you send a summary to the mailing list saying

"Steve, Bob, and Michal were all on a call discussing this feature. We were 
having trouble agreeing between options x, y, and z. After chatting for 20 
minutes, we decided on this because of reasons a, b, and c. Review: 
https://review.openstack.org/:review_id has the final code details. Feel free 
to ping us on irc or the review with further questions."

--  
Ian Cordasco


__
OpenStack Development Mailing 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] [release][ptl][all] self-service branch management

[Emilien Macchi]

On Wed, Dec 14, 2016 at 8:45 AM, Doug Hellmann  wrote:
> [Sending again due to mail delivery issues.]
>
> The release team is pleased to announce that the branch automation
> work is now complete, and that teams can now manage feature and
> stable branch creation through the openstack/releases repository.
>
> Creating a branch is very similar to creating a release: Edit the
> appropriate file in the releases repo to add the branch information,
> let the release team review it, and then when the patch is approved
> the bots make your branch. New branches come with patches to update
> .gitreview, reno, and constraint settings where needed.
>
> For the complete details about how to format a branch request, see
> the README.rst file in the repo [1].
>
> Thanks, as always, to the Infra team for their help in implementing
> this automation.

That's awesome, and we were looking forward to it.
Regarding schedule, it's not clear to me when we *have to* propose the branches.

For example in TripleO, we've noticed that our work on upgrades
usually happens more at the end of a cycle so we would like to wait
for the last time before branching our repos.
Example with Ocata, when would you suggest to start branching?

> Doug
>
> [1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n63
>
> __
> OpenStack Development Mailing 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

__
OpenStack Development Mailing 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] respecting glance priorities

[Ian Cordasco]

 

-Original Message-
From: Brian Rosmaita 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: December 14, 2016 at 14:18:23
To: openstack-dev@lists.openstack.org 
Subject:  Re: [openstack-dev] [glance] respecting glance priorities

> Hello Glancers,
>  
> I realize that the weekly priority mailing is a new thing for us, so
> here's a quick reminder of how it works/what it's for.
>  
> Priorities are discussed and set at the weekly meeting and that gives us
> all some focus for what to do in the coming week.
>  
> If you're a glance core: please attend to these items first, before
> reviewing other items or merging other patches.
>  
> If you're not a glance core: priority items are important for the
> project, so a high quality review on them is a good way to get yourself
> noticed as an up-and-coming glance contributor.
>  
> These are called "priorities", not because they're the only things we're
> working on, but because we want to get them completed *first*.
>  
> If you have a patch that didn't make the list, keep in mind that
> OpenStack development is a community effort. If you review other
> people's patches, other people are more likely to review yours.
>  
> (And yes, what prompted this mailing is that I saw some patches merged
> while many of the items below have been languishing for want of
> attention. There are about 18 hours until the weekly Glance meeting, it
> would be nice to see them addressed. :) )
>  
> Here endeth the lesson.
>  
> cheers,
> brian
>  
>  
> On 12/9/16 7:14 AM, Brian Rosmaita wrote:
> > As discussed at the Glance weekly meeting yesterday, the priorities for
> > 12/1 through 12/8, unfortunately look very similar to last week's
> > priorities. Some core reviewers need to step up. The priorities are:
> >
> > Highest priority
> > 
> >
> > (1) database strategy for rolling upgrades:
> > https://review.openstack.org/#/c/331740/
> > This one has a video to enhance your reviewing pleasure and demonstrate
> > that the approach described actually is workable:
> > https://www.youtube.com/watch?v=Z4iwJRlPqOw
> >
> > (2) glance expand/contract migrations with alembic:
> > https://review.openstack.org/#/c/374278/
> > We need another +2 on this one, preferably from a non-Rackspace person.
> >
> > (3) community images spec update:
> > https://review.openstack.org/#/c/396919/
> > New to the list. The latest patch includes the migration strategy for
> > which Erno said indicated on the patch he'd change his -2 to a +2, so
> > don't let the -2 on the patch stop you from reviewing it.
> >
> > The above three specs need to be reviewed as soon as possible. We are
> > blocking Alex and Hemanth, because the Ocata database migration will
> > handle the community images changes.
> >
> >
> > Really high priority
> > 
> > (would be highest if the specs were already approved)
> >
> > (4) Patch to fix a glance_store regression:
> > https://review.openstack.org/#/c/387719/
> > and patch to prevent a related backend misconfiguration:
> > https://review.openstack.org/#/c/388944/
> >
> > (5) Patch to enable better request-id tracking:
> > https://review.openstack.org/#/c/352892/
> > This will be nice for operators, let's get it reviewed and merged!
> >
> > (6) Request for some insights and opinions for bug
> > https://bugs.launchpad.net/glance/+bug/1585917
> >
> >
> > Please take a look
> > ==
> >
> > (7) glanceclient problem: https://review.openstack.org/#/c/319960/
> >
> > thanks,
> > brian

Also worth noting that for community members with bugs/patches that are a 
priority to them, the correct place to lobby for that is in the weekly meeting. 

--  
Ian Cordasco
Release CPL/Czar

__
OpenStack Development Mailing 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] Propose Steve Lewis for Glance core

[Fei Long Wang]

+1 Steve has done a great job, nice to have him in the team.


On 14/12/16 11:05, Brian Rosmaita wrote:
> I'd like to propose Steve Lewis (stevelle on IRC) for Glance core.  Take
> a look at any of his reviews, and you can see that he's thorough and
> comprehensive in his reviewing.  He's knowledgeable about Python,
> Glance, and software engineering in general.  He's gained a lot of
> experience in various OpenStack projects (including experience as a core
> reviewer), and will be a great addition to the Glance core reviewers team.
>
> If you have any concerns, please let me know.  I plan to add Steve to
> the core list after this week's Glance meeting.
>
> thanks,
> brian
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Cheers & Best regards,
FeiLong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
OpenStack Development Mailing 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] respecting glance priorities

[Brian Rosmaita]

Hello Glancers,

I realize that the weekly priority mailing is a new thing for us, so
here's a quick reminder of how it works/what it's for.

Priorities are discussed and set at the weekly meeting and that gives us
all some focus for what to do in the coming week.

If you're a glance core: please attend to these items first, before
reviewing other items or merging other patches.

If you're not a glance core: priority items are important for the
project, so a high quality review on them is a good way to get yourself
noticed as an up-and-coming glance contributor.

These are called "priorities", not because they're the only things we're
working on, but because we want to get them completed *first*.

If you have a patch that didn't make the list, keep in mind that
OpenStack development is a community effort.  If you review other
people's patches, other people are more likely to review yours.

(And yes, what prompted this mailing is that I saw some patches merged
while many of the items below have been languishing for want of
attention.  There are about 18 hours until the weekly Glance meeting, it
would be nice to see them addressed. :) )

Here endeth the lesson.

cheers,
brian


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


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

Re: [openstack-dev] [glance] Propose Steve Lewis for Glance core

[Sabari Murugesan]

+2 for Steve!

On Wed, Dec 14, 2016 at 3:36 AM, Ian Cordasco 
wrote:

> +2 from me as well
>
> On Dec 14, 2016 3:16 AM, "Erno Kuvaja"  wrote:
>
>> On Tue, Dec 13, 2016 at 10:05 PM, Brian Rosmaita
>>  wrote:
>> > I'd like to propose Steve Lewis (stevelle on IRC) for Glance core.  Take
>> > a look at any of his reviews, and you can see that he's thorough and
>> > comprehensive in his reviewing.  He's knowledgeable about Python,
>> > Glance, and software engineering in general.  He's gained a lot of
>> > experience in various OpenStack projects (including experience as a core
>> > reviewer), and will be a great addition to the Glance core reviewers
>> team.
>> >
>> > If you have any concerns, please let me know.  I plan to add Steve to
>> > the core list after this week's Glance meeting.
>> >
>> > thanks,
>> > brian
>> >
>>
>>
>> Steve has been doing great job: +100!
>>
>> - jokke
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Kolla-k8s core nominations

[Fox, Kevin M]

+1 to portdirect and srwilkers. both are doing a great job!

Thanks,
Kevin

From: Steven Dake (stdake) [std...@cisco.com]
Sent: Wednesday, December 14, 2016 10:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] Kolla-k8s core nominations

portdirect +1
srwilkers +1

Doing a fantastic job reviewing and writing code and participating in team 
meetings/irc conversations.

Regards
-steve


-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, December 14, 2016 at 10:06 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [kolla] Kolla-k8s core nominations

I'm happy to start nomination process for our 2 colleagues:

srwilkers and portdirect

to kolla-k8s core team!
This nomination will is open for 1 week. Kolla-k8s core team, please vote:)
Consider this email as vote +1 from me.

Regards,
Michal

__
OpenStack Development Mailing 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] [kolla][tc] Video Meetings - input requested

[Doug Hellmann]

Excerpts from Michał Jastrzębski's message of 2016-12-14 11:14:01 -0600:
> So if one of potential attendees cannot join for that reason, again I
> would consider this to be reason enough to move meeting back to irc.
> IRC is and keep being our default communication channel. Hangouts
> would only be mitigation of "typing is too slow for this flame"
> problem. With constant brainstorm mode that kolla-k8s currently is,
> this is the case sometimes. That's why we even had this few hangout
> meetings:)

That's good to hear.

Back to the original post, it seems that at least one Kolla team
member is feeling that the way these discussions are being handled
is leaving them out of important parts of the development process.
That says to me that either the meetings are happening too often,
or that the discussions are not being documented well after the
fact, or both.

Maybe it would be constructive to brainstorm ways to address the
complaints.

Doug

> 
> Still waiting for "punch other person in the face over IP" device...
> 
> On 14 December 2016 at 11:05, Doug Hellmann  wrote:
> > Excerpts from Michał Jastrzębski's message of 2016-12-14 09:56:46 -0600:
> >> OK, I think we had some grave misunderstandings here.
> >>
> >> 1. ad-hoc meetings *are not* and *were never meant to be* replacement
> >> for weekly meetings. Kolla community is single community across all
> >> its deliverables and we hold common meetings, chats and mailing list.
> >> Also, as long as I'm PTL, I'm unwilling to change that.
> >> 2. Hangouts were never exclusive purposefully. Meeting link was always
> >> posted on irc, and nobody were excluded apart from people not present
> >> on irc at given time.
> >> 3. Language barrier is something to acknowledge. I would say if we
> >> find ourselves in situation where one of hangout users has problem
> >> communicating, we either move to IRC or try hard to accommodate his or
> >> hers language barrier. But on few hangouts I was on, that was not the
> >> case. If somebody didn't join because they were ashamed, please, feel
> >> free to approach me on private message (or if I'm not around, hangout
> >> organizer) and let me know. That would be reason enough to stick to
> >> IRC in my book
> >> 4. Hangouts were never exclusive to core team. Just happened that core
> >> reviewers were majority of it - not planned or enforced.
> >> 5. Only "exclusiveness" I can think of in context of ad hoc meetings
> >> are that people who aren't around irc cannot have voice on this
> >> meeting. Simply because they aren't around and meeting was unplanned.
> >> That's the case with *any* discussion outside of dedicated 1hr every
> >> week. Granted, irc has logs. Hangouts can have notes, or outcome could
> >> be reflected as PoC in gerrit for example (which was the case of
> >> hangout in question..).
> >
> > As has been pointed out elsewhere in this thread, the Google Hangout
> > service itself is *blocked* in some countries. It is therefore by
> > definition not something we can call a fully open meeting venue. Which
> > is not to say it can never be used, but we all need to be aware of the
> > fact that choosing it means we exclude participation from other team
> > members (or potential team members).
> >
> > Doug
> >
> >>
> >> Ian, you mentioned that gerrit as outcome of hangout violates 4 
> >> opens...how?
> >>
> >> Cheers,
> >> Michal
> >>
> >> On 14 December 2016 at 09:07, Ian Cordasco  wrote:
> >> >
> >> >
> >> > -Original Message-
> >> > From: Ed Leafe 
> >> > Reply: OpenStack Development Mailing List (not for usage questions) 
> >> > 
> >> > Date: December 14, 2016 at 08:08:33
> >> > To: OpenStack Development Mailing List (not for usage questions) 
> >> > 
> >> > Subject:  Re: [openstack-dev] [kolla][tc] Video Meetings - input 
> >> > requested
> >> >
> >> >> On Dec 14, 2016, at 7:45 AM, Ian Cordasco wrote:
> >> >> >
> >> >> > Taking you to the extreme of your statement, it seems there are 
> >> >> > several of these "ad hoc"
> >> >> meetings a week (by inc0's admission). The video meetings seem to 
> >> >> replace the time that
> >> >> sub-team is missing in the weekly IRC meeting, which Jeffrey has a plan 
> >> >> to solve for.
> >> >> >
> >> >> > Also, based on inc0's email, it seems that these meetings 
> >> >> > consistently are made up primarily
> >> >> (if not singularly) of "cores". So they seem to be violating the open's 
> >> >> in that they're
> >> >> effectively (even if not intentionally) creating a place where only 
> >> >> sub-groups of people
> >> >> working on kolla (k8s) can collaborate.
> >> >> >
> >> >> > Further, the kolla team seems to think that code submissions sent 
> >> >> > after a meeting are
> >> >> sufficient artifacts from the meeting, which there seems to be a 
> >> >> majority who feel otherwise.
> >> >> Based on Jeffrey's descriptions, inc0's 

Re: [openstack-dev] [kolla] Kolla-k8s core nominations

[Steven Dake (stdake)]

portdirect +1
srwilkers +1

Doing a fantastic job reviewing and writing code and participating in team 
meetings/irc conversations.

Regards
-steve


-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, December 14, 2016 at 10:06 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [kolla] Kolla-k8s core nominations

I'm happy to start nomination process for our 2 colleagues:

srwilkers and portdirect

to kolla-k8s core team!
This nomination will is open for 1 week. Kolla-k8s core team, please vote:)
Consider this email as vote +1 from me.

Regards,
Michal

__
OpenStack Development Mailing 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] [keystone][nova]Quotas: Store resources and limits in the Keystone

[Sajeesh Cimson Sasi]

Hi,
I also feel that quota as a service is the best approach.It is justified as 
well, since we have multiple projects(Nova,Cinder,Neutron) now ,having the 
concept of quotas.Keeping it under a single umbrella, paves the way for lesser 
code duplication and easier feature enhancement like adoption of hierarchical 
quotas, and also better code management.
best regards,
 sajeesh


From: Andrey Volkov [avol...@mirantis.com]
Sent: 14 December 2016 17:00:32
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone][nova]Quotas: Store resources and
limits in the Keystone

Hi,

I think one of the issues we're trying to solve here is duplication
reducing. Quotas in OpenStack commonly contain two parts: limits
management and limits enforcement.

If we're talking about library (delimiter) vs service (keystone or quota
service) for a duplication reducing in a limits management then IMO service is
more appropriate way because:

- Now we have API endpoint for limits
  management for the end user and we will need it in the future. Library can
  reduce an amount of code for such endpoint but can't totally eliminate it.
- Besides the code in services, we have api-ref, docs, and clients also
  and library can't reduce an effort for supporting those.
- Centralized limits management service can provide fresh and
  consistent API (see quota_class, quota_sets).

If we're talking about limits enforcement then it's more subtle thing.
I really agree with Jay that problem can be related to the cache for
usages. And I don't see the way how we can skip saving into reservation
table because we can easily define a moment of reservation with
reservation table but it can be hard with "real" objects like instance
as they have its own logic of creating.

I think a library can be appropriate if services like nova or cinder
have a possibility to deeply integrate external libraries (like django
apps). I mean if a library has own DB tables, cli commands, etc. it
can be seamlessly integrated to the main app. I'm not sure it's the
case for nova, for example. Therefore, for me, separate service
is the winner here too.

Sajeesh Cimson Sasi writes:

> Hi,
> There was an ongoing project of delimiter for Cross Project Quota 
> Management.
> But I don't know the current status.
> Kindly have a look at it.
> https://review.openstack.org/#/c/284454/
> More discussions are required on this.As more and more  projects or 
> services are having the concept ofquotas,Quota as a service can also be 
> thought of.Anyway more discussions are required on this topic.
>best regards,
> sajeesh
> 
> From: Jay Pipes [jaypi...@gmail.com]
> Sent: 13 December 2016 18:55:14
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [keystone][nova]Quotas: Store resources and 
> limits in the Keystone
>
> On 12/13/2016 08:09 AM, Kseniya Tychkova wrote:
>> Hi,
>> I would like to share a spec [1] with you.
>> The main idea of this spec is to start a discussion about quota
>> management in the OpenStack.
>>
>> Quotas are scattered across OpenStack services. Each service defines
>> it's own model and API for
>> managing resource's limits. Because of that, there are several problems:
>>
>>   * Names of the resources and resource-service mapping  are hardcoded.
>> They are hardcoded in the service code (Nova, for example) and it
>> should be hardcoded in the client code (Horizon, for example).
>>
>>   * There is no centralized quota management for OpenStack projects.
>>   * Cinder, Nova and Neutron support (or going to support) hierarchical
>> quotas in different ways.
>>
>> There should be a single point of managing quotas in OpenStack.
>> Keystone looks like a proper place to store resource's limits because:
>>
>>   * Keystone stores projects
>>   * Limits are belong to project.
>
> Another excellent reason to store quota limits in Keystone is because
> virtually all non-list operations require some interaction with quota
> limits, and requiring Nova (or Cinder or Neutron) to call out to yet
> another service each time the user makes one of those non-list
> operations is sub-optimal when Nova is already making a call to Keystone
> for authentication.
>
> The alternative is to have a separate REST API service just for storing
> and returning the quota limits and have Nova, Cinder and Neutron call
> this new service each time a non-list operation is made. While this is
> possible, it's just yet another service that needs to be managed and
> deployed by all installations of OpenStack.
>
> Best,
> -jay
>
>> There are a lot of possible issues with “store limits in Keystone”
>> approach. But all of them can be discussed
>> and such discussion should lead to the good solution for quotas
>> management  in Openstack.
>>
>> Please take a look at the spec when you have time and share 

[openstack-dev] [nova] Reminder that ocata-2 milestone is tagged tomorrow (Dec 15)

[Matt Riedemann]

This is just a reminder that we'll be tagging the o-2 tag for nova 
tomorrow (Thursday Dec 15th). There is generally no science to this, 
it's just the HEAD of the nova master branch whenever I decide to create 
the release request (probably end of day today for me).


If there are critical bugs/upgrade issues that I should hold up for this 
though, please let me know today.


--

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] [release] Release management team draft logo

[Matt Riedemann]

On 12/2/2016 7:52 AM, Doug Hellmann wrote:

Excerpts from Steve Martinelli's message of 2016-12-02 08:04:51 -0500:

A bit of colour should will go a long way here, black and brown would help
make it more obvious (IMO).


Yes, Heidi's email does say this is the version without color. There are
some very subtle grey patches that line up with what I expect to see for
markings on a border collie, so I'm tentatively OK with this pending
seeing the color version.

Doug



On Fri, Dec 2, 2016 at 4:05 AM, Thierry Carrez 
wrote:


Doug Hellmann wrote:

Release team, please take a look at the attached logo and let me know
what you think.


It's not immediately obvious to me it's a shepherd dog, but then I don't
exactly know how to make that more obvious.

--
Thierry Carrez (ttx)

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



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



Have it biting someone's ankle, that would be a tell-tale sign.

--

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] [kolla][tc] Video Meetings - input requested

[Michał Jastrzębski]

So if one of potential attendees cannot join for that reason, again I
would consider this to be reason enough to move meeting back to irc.
IRC is and keep being our default communication channel. Hangouts
would only be mitigation of "typing is too slow for this flame"
problem. With constant brainstorm mode that kolla-k8s currently is,
this is the case sometimes. That's why we even had this few hangout
meetings:)

Still waiting for "punch other person in the face over IP" device...

On 14 December 2016 at 11:05, Doug Hellmann  wrote:
> Excerpts from Michał Jastrzębski's message of 2016-12-14 09:56:46 -0600:
>> OK, I think we had some grave misunderstandings here.
>>
>> 1. ad-hoc meetings *are not* and *were never meant to be* replacement
>> for weekly meetings. Kolla community is single community across all
>> its deliverables and we hold common meetings, chats and mailing list.
>> Also, as long as I'm PTL, I'm unwilling to change that.
>> 2. Hangouts were never exclusive purposefully. Meeting link was always
>> posted on irc, and nobody were excluded apart from people not present
>> on irc at given time.
>> 3. Language barrier is something to acknowledge. I would say if we
>> find ourselves in situation where one of hangout users has problem
>> communicating, we either move to IRC or try hard to accommodate his or
>> hers language barrier. But on few hangouts I was on, that was not the
>> case. If somebody didn't join because they were ashamed, please, feel
>> free to approach me on private message (or if I'm not around, hangout
>> organizer) and let me know. That would be reason enough to stick to
>> IRC in my book
>> 4. Hangouts were never exclusive to core team. Just happened that core
>> reviewers were majority of it - not planned or enforced.
>> 5. Only "exclusiveness" I can think of in context of ad hoc meetings
>> are that people who aren't around irc cannot have voice on this
>> meeting. Simply because they aren't around and meeting was unplanned.
>> That's the case with *any* discussion outside of dedicated 1hr every
>> week. Granted, irc has logs. Hangouts can have notes, or outcome could
>> be reflected as PoC in gerrit for example (which was the case of
>> hangout in question..).
>
> As has been pointed out elsewhere in this thread, the Google Hangout
> service itself is *blocked* in some countries. It is therefore by
> definition not something we can call a fully open meeting venue. Which
> is not to say it can never be used, but we all need to be aware of the
> fact that choosing it means we exclude participation from other team
> members (or potential team members).
>
> Doug
>
>>
>> Ian, you mentioned that gerrit as outcome of hangout violates 4 opens...how?
>>
>> Cheers,
>> Michal
>>
>> On 14 December 2016 at 09:07, Ian Cordasco  wrote:
>> >
>> >
>> > -Original Message-
>> > From: Ed Leafe 
>> > Reply: OpenStack Development Mailing List (not for usage questions) 
>> > 
>> > Date: December 14, 2016 at 08:08:33
>> > To: OpenStack Development Mailing List (not for usage questions) 
>> > 
>> > Subject:  Re: [openstack-dev] [kolla][tc] Video Meetings - input requested
>> >
>> >> On Dec 14, 2016, at 7:45 AM, Ian Cordasco wrote:
>> >> >
>> >> > Taking you to the extreme of your statement, it seems there are several 
>> >> > of these "ad hoc"
>> >> meetings a week (by inc0's admission). The video meetings seem to replace 
>> >> the time that
>> >> sub-team is missing in the weekly IRC meeting, which Jeffrey has a plan 
>> >> to solve for.
>> >> >
>> >> > Also, based on inc0's email, it seems that these meetings consistently 
>> >> > are made up primarily
>> >> (if not singularly) of "cores". So they seem to be violating the open's 
>> >> in that they're
>> >> effectively (even if not intentionally) creating a place where only 
>> >> sub-groups of people
>> >> working on kolla (k8s) can collaborate.
>> >> >
>> >> > Further, the kolla team seems to think that code submissions sent after 
>> >> > a meeting are
>> >> sufficient artifacts from the meeting, which there seems to be a majority 
>> >> who feel otherwise.
>> >> Based on Jeffrey's descriptions, inc0's emails, and the rest of this 
>> >> thread, it seems
>> >> quite clear that kolla isn't obeying one of the 4 opens.
>> >>
>> >> Sorry, the conversation seems to have forked. The original issue was 
>> >> Kolla’s practices,
>> >> which then forked into a more general discussion. I was responding to the 
>> >> general side
>> >> of things: you can’t say that hangouts or hallway conversations are never 
>> >> good things.
>> >> But when they are misused, as is described in the Kolla case, then yes, 
>> >> that should not
>> >> be allowed to continue.
>> >
>> > No worries. I was trying to bring us back to the Kolla case. If we want to 
>> > discuss more general guidelines around this stuff, I'd rather not 

[openstack-dev] [kolla] Kolla-k8s core nominations

[Michał Jastrzębski]

I'm happy to start nomination process for our 2 colleagues:

srwilkers and portdirect

to kolla-k8s core team!
This nomination will is open for 1 week. Kolla-k8s core team, please vote:)
Consider this email as vote +1 from me.

Regards,
Michal

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

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Doug Hellmann]

Excerpts from Michał Jastrzębski's message of 2016-12-14 09:56:46 -0600:
> OK, I think we had some grave misunderstandings here.
> 
> 1. ad-hoc meetings *are not* and *were never meant to be* replacement
> for weekly meetings. Kolla community is single community across all
> its deliverables and we hold common meetings, chats and mailing list.
> Also, as long as I'm PTL, I'm unwilling to change that.
> 2. Hangouts were never exclusive purposefully. Meeting link was always
> posted on irc, and nobody were excluded apart from people not present
> on irc at given time.
> 3. Language barrier is something to acknowledge. I would say if we
> find ourselves in situation where one of hangout users has problem
> communicating, we either move to IRC or try hard to accommodate his or
> hers language barrier. But on few hangouts I was on, that was not the
> case. If somebody didn't join because they were ashamed, please, feel
> free to approach me on private message (or if I'm not around, hangout
> organizer) and let me know. That would be reason enough to stick to
> IRC in my book
> 4. Hangouts were never exclusive to core team. Just happened that core
> reviewers were majority of it - not planned or enforced.
> 5. Only "exclusiveness" I can think of in context of ad hoc meetings
> are that people who aren't around irc cannot have voice on this
> meeting. Simply because they aren't around and meeting was unplanned.
> That's the case with *any* discussion outside of dedicated 1hr every
> week. Granted, irc has logs. Hangouts can have notes, or outcome could
> be reflected as PoC in gerrit for example (which was the case of
> hangout in question..).

As has been pointed out elsewhere in this thread, the Google Hangout
service itself is *blocked* in some countries. It is therefore by
definition not something we can call a fully open meeting venue. Which
is not to say it can never be used, but we all need to be aware of the
fact that choosing it means we exclude participation from other team
members (or potential team members).

Doug

> 
> Ian, you mentioned that gerrit as outcome of hangout violates 4 opens...how?
> 
> Cheers,
> Michal
> 
> On 14 December 2016 at 09:07, Ian Cordasco  wrote:
> >
> >
> > -Original Message-
> > From: Ed Leafe 
> > Reply: OpenStack Development Mailing List (not for usage questions) 
> > 
> > Date: December 14, 2016 at 08:08:33
> > To: OpenStack Development Mailing List (not for usage questions) 
> > 
> > Subject:  Re: [openstack-dev] [kolla][tc] Video Meetings - input requested
> >
> >> On Dec 14, 2016, at 7:45 AM, Ian Cordasco wrote:
> >> >
> >> > Taking you to the extreme of your statement, it seems there are several 
> >> > of these "ad hoc"
> >> meetings a week (by inc0's admission). The video meetings seem to replace 
> >> the time that
> >> sub-team is missing in the weekly IRC meeting, which Jeffrey has a plan to 
> >> solve for.
> >> >
> >> > Also, based on inc0's email, it seems that these meetings consistently 
> >> > are made up primarily
> >> (if not singularly) of "cores". So they seem to be violating the open's in 
> >> that they're
> >> effectively (even if not intentionally) creating a place where only 
> >> sub-groups of people
> >> working on kolla (k8s) can collaborate.
> >> >
> >> > Further, the kolla team seems to think that code submissions sent after 
> >> > a meeting are
> >> sufficient artifacts from the meeting, which there seems to be a majority 
> >> who feel otherwise.
> >> Based on Jeffrey's descriptions, inc0's emails, and the rest of this 
> >> thread, it seems
> >> quite clear that kolla isn't obeying one of the 4 opens.
> >>
> >> Sorry, the conversation seems to have forked. The original issue was 
> >> Kolla’s practices,
> >> which then forked into a more general discussion. I was responding to the 
> >> general side
> >> of things: you can’t say that hangouts or hallway conversations are never 
> >> good things.
> >> But when they are misused, as is described in the Kolla case, then yes, 
> >> that should not
> >> be allowed to continue.
> >
> > No worries. I was trying to bring us back to the Kolla case. If we want to 
> > discuss more general guidelines around this stuff, I'd rather not hijack 
> > this thread because it highlights serious problems in how Kolla is 
> > operating that a member of its team has brought up. I don't want us to 
> > side-track that conversation too severely. :)
> >
> > --
> > Ian Cordasco
> >
> >
> > __
> > OpenStack Development Mailing 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 

Re: [openstack-dev] [openstack][nova][nova-api] index() method in InstanceUsageAuditLogController return an object rather than a list

[Matt Riedemann]

On 12/13/2016 8:43 PM, int32bit wrote:

Hi, all. As we know, the "index()" method usually return object list and
the "show()" method return an object for detail in api's controller. But
I found in our InstanceUsageAuditLogController[1], the 'index' method
return an object, I'm really not sure that index() is buggy, and I
wonder what it is intended to do and what might be needed to fix it.

Some discussion about this topic:
https://review.openstack.org/#/c/409413/ .

Thanks for your attention.


[1]
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/instance_usage_audit_log.py#L43


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



It's different but I'm not sure it's a bug, it's probably just a hacky 
way to override GET for different things, i.e. we have GET without the 
id parameter which is the index() implementation, and then we have the 
GET with the id parameter which is the show() implementation and also 
does some filtering (audit logs before the given timestamp). If 
anything, abusing the id parameter for GET is more of a bug as we aren't 
using it as a resource id to show details about a given resource, it's a 
timestamp filter.


Ideally we'd just have a single index() for GET with an optional 
'before' query parameter to toggle the behavior. Chris Dent (cdent in 
IRC) might have an opinion on this from the API working group point of view.


From a pragmatic standpoint, I question how many deployments are 
actually leveraging this feature. It looks like it was originally added 
for Ceilometer but I wonder how many admins are really enabling it and 
using it for gathering audit data. By default it's disabled, and we 
don't test it anywhere in our CI system beyond unit tests. My point 
being, yeah this is gross, but how much do we really care about fixing 
this right now?


--

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] FW: FW: No Relevant flows in br-int after SFC Creation

[Mohan Kumar]

Hi Anirudh,

 Yes, SFC flow_rules are not downloaded.  Could you check q-agt timeout
errors?  My suggestion is to recheck flow_classifer fields like protocol
ports. If possible please find me over IRC #openstack-neutron in IST.

Thanks.,
Mohankumar.N


On Wed, Dec 14, 2016 at 5:14 PM, Anirudh Gupta 
wrote:

> Hi Mohan,
>
>
>
> Request you to further extend your support in order to resolve the issue.
>
>
>
> Regards
>
> Anirudh Gupta
>
>
>
> *From:* Anirudh Gupta
> *Sent:* Tuesday, December 13, 2016 5:25 PM
> *To:* 'nmohankumar1...@gmail.com' 
> *Cc:* Mohit Gupta ; Lovelesh Pandya <
> lovelesh.pan...@aricent.com>
> *Subject:* RE: FW: No Relevant flows in br-int after SFC Creation
>
>
>
> Hi Mohan,
>
>
>
> Thanks for your valuable inputs.
>
>
>
> We have deleted the previous port chain and flow classifier.
>
>
>
> As suggested, again created the port chain and flow classifier using vm1
> and vm3.
>
>
>
> · *neutron flow-classifier-create --ethertype IPv4  --description
> "HTTP traffic from 10.0.0.8 to 10.10.10.6"  --ethertype IPv4
> --source-ip-prefix 10.10.10.8/32 
> --destination-ip-prefix 10.10.10.6/32  --protocol tcp
> --source-port 1000:1000--destination-port 80:80 FC1
> --logical_source_port 3064d8be-2c14-4c3c-8e51-d1ed38be9cbf*
>
>
>
> · *neutron port-chain-create   --port-pair-group PPG1
> --port-pair-group PPG2   --flow-classifier FC1 PC1*
>
>
>
> But still we are facing the issue that no dump-groups are getting created
> and no relevant flows are observed in the br-int.
>
>
>
> I have also captured specific q-agt and q-svc logs of scenarios where only
> the flow classifier and port chain is getting created.
>
>
>
> q-agt.log_specific and q-svc.log_specific corresponds to logs of only
> creation of flow classifier and port chain.
>
> q-agt.log_all and q-svc.log_all contains all the logs.
>
>
>
> I am sharing you new Br-int dump-flows and updated SFC Command List as
> well.
>
>
>
> Request you to extend your support in order to resolve the issue.
>
>
>
> Regards
>
> Anirudh Gupta
>
>
>
> *From:* Mohan Kumar [mailto:nmohankumar1...@gmail.com
> ]
> *Sent:* Tuesday, December 13, 2016 4:19 PM
> *To:* Anirudh Gupta 
> *Cc:* Mohit Gupta ; Lovelesh Pandya <
> lovelesh.pan...@aricent.com>
> *Subject:* Re: FW: No Relevant flows in br-int after SFC Creation
>
>
>
> Hi Anirudh,
>
>
>
> The Flow Classifier fields are not matching with port chain created.
>
>
>
> In SFC commands you've shared , The port_chain formed  with vm1 , vm2, and
> vm3 . But flow _classifier fields pointing vm4 ingress as source_ip  and
> logical_source_port and vm5 egress_port as the destination.
>
>
>
> Request you to change flow_classifer fields as  "vm1" as source and "vm3"
>  as the destination and try again.
>
>
>
> *P.S: *Request you always include  for
> widespread and fast response :)
>
>
>
>
>
> Thanks.,
>
> Mohankumar.N
>
>
>
> On Tue, Dec 13, 2016 at 2:59 PM, Anirudh Gupta 
> wrote:
>
> Hi Mohan,
>
>
>
> I saw one of your mail chain http://lists.openstack.org/
> pipermail/openstack-dev/2016-August/101755.html  , in which Openstack SFC
> was created.
>
>
>
> We are trying to create Networking SFC using Newton Devstack setup using
> Openflow13, but facing some issues.
>
>
>
> After creating the port chain by the command list (attached in the mail),
> we are facing 2 issues :-
>
>
>
> · No relevant flows in br-int (also attached in the mail)
>
> · Empty dump-groups
>
>
>
> Setup Details :-
>
>
>
> · Openstack Newton
>
> · Kernel version - 3.19.0-25-generic
>
> · ovs version – 2.4.0
>
>
>
>
>
> We have configured all the configurational files using the link
> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining   and
> created SFC following the link http://docs.openstack.org/
> newton/networking-guide/config-sfc.html
>
>
>
> The command executed for dump-flows is :-
>
>
>
> *stack@Newton-VM:~$ sudo ovs-ofctl -O openflow13 dump-groups br-int*
>
> *OFPST_GROUP_DESC reply (OF1.3) (xid=0x2):*
>
>
>
> We are currently stuck in the issue that there are no dump-groups and no
> relevant flows in br-int.
>
>
>
> Can you share some pointers to resolve this issue.
>
>
>
> The following files are attached in the mail :-
>
> · local.conf
>
> · /etc/neutron/plugins/ml2/ml2_conf.ini
>
> · /etc/neutron/l3_agent.ini
>
> · /etc/neutron/dhcp_agent.ini
>
> · q-svc
>
> · q-agt
>
> · Br-int Flows
>
> · SFC Command List
>
>
>
>
>
> With Regards
>
>
>
> Anirudh Gupta
>
> Software Engineer
>
> anirudh2.gu...@aricent.com | Extension – 4908
>
> 
>
>
>
>
>
>
>
>
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended 

Re: [openstack-dev] Changes to DNS integration behavior?

[Miguel Lavalle]

Hi Conrad,

You are correct in your reading of the Neutron DNS integration
documentation. Ports 'inherit' their dns_domain from their network. I
encourage you to submit a RFE (Request for Enhacement) here:
https://bugs.launchpad.net/neutron. Once you file it, I'll track it down
and will make sure it is properly tagged so it gets discussed by the
Neutron drivers team

Best regards

Miguel

On Mon, Dec 12, 2016 at 1:49 PM, Kimball, Conrad 
wrote:

> We are in the early phases of a project to deploy OpenStack and we face
> the question of DNS integration when launching a VM instance.
>
>
>
> We have found the DNS Integration documentation at
> http://docs.openstack.org/mitaka/networking-guide/config-dns-int.html,
> but to our understanding it doesn’t do what we want to do.
>
>
>
> Where is the best forum for discussing possible changes in this behavior?
>
>
>
> - - -
>
>
>
> Specifically, we do not tie DNS domains to networks – any particular
> network may have VM ports with a variety of DNS domains, with the choice of
> DNS domain left to the person deploying the VM instance (we use DNS domains
> to indicate business unit association, infrastructure function, and so
> forth).
>
>
>
> So we would want the DNS integration to allow specifying both a dns_name
> and a dns_domain when creating a port.  The documentation link above says
> this is allowed for floating IPs, but not for ports – ports can specify
> only a dns_name and always inherit the dns_domain from the network.
>
>
>
> *Conrad Kimball*
>
> Associate Technical Fellow
>
> Chief Architect, Enterprise Cloud Services
>
> Engineering, Operations & Technology / Information Technology / Core
> Infrastructure Engineering
>
> conrad.kimb...@boeing.com
>
> P.O. Box 3707, Mail Code 7M-TE
>
> Seattle, WA  98124-2207
>
> Bellevue 33-11 bldg, office 3A6-3.9
>
> Mobile:  425-591-7802 <(425)%20591-7802>
>
>
>
> __
> OpenStack Development Mailing 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-Infra] [all][stable][ptls] Tagging liberty as EOL

[Doug Hellmann]

Excerpts from Vladyslav Drok's message of 2016-12-14 17:11:56 +0200:
> On Wed, Dec 14, 2016 at 3:48 PM, Ian Cordasco 
> wrote:
> 
> > -Original Message-
> > From: Joshua Hesketh 
> > Reply: OpenStack Development Mailing List (not for usage questions) <
> > openstack-dev@lists.openstack.org>
> > Date: December 14, 2016 at 06:56:22
> > To: OpenStack Development Mailing List ,
> > openstack-infra 
> > Subject:  Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls]
> > Tagging liberty as EOL
> >
> > > The repos listed[0] have had stable/liberty branch removed and replaced
> > > with a liberty-eol tag. Any open reviews have been abandoned.
> > >
> > > Please let me know if there are any mistakes or latecomers to the list.
> > >
> > > Cheers,
> > > Josh
> > >
> > > [0]
> > > https://gist.githubusercontent.com/tbreeds/
> > 93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
> >
> > Glance was late to the party, but it should have had its liberty branches
> > EOL'd as well.
> >
> > --
> > Ian Cordasco
> >
> 
> Also, after liberty was EOL'd and stable/liberty branches were removed,
> liberty release note pages need to be updated to reference liberty-eol tag
> instead of origin/stable/liberty, like done here
> https://review.openstack.org/410798 as a temporary solution, until this is
> fixed on the reno side (https://review.openstack.org/410792), if I get the
> situation correctly.
> 
> -Vlad

Because the other fix was behind a bunch of the rewrite work I'm doing
this cycle, we've set up a stable/newton branch for reno and I have an
alternative fix in https://review.openstack.org/410839. When we get that
merged, I'll release reno 1.9.0 with the fix.

Doug

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

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Swapnil Kulkarni]

On Dec 14, 2016 7:03 PM, "Steven Dake (stdake)"  wrote:

Swapnil,

If you want to do that, please add it to the meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Kolla

Regards
-steve


Done



-Original Message-
From: Swapnil Kulkarni 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Date: Wednesday, December 14, 2016 at 3:22 AM
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

On Wed, Dec 14, 2016 at 3:33 PM, Thierry Carrez 
wrote:
> Ed Leafe wrote:
>> On Dec 12, 2016, at 10:30 PM, Steven Dake (stdake) 
wrote:
>>
>>> The issue raised is they violate the 4 opens.
>>
>> Not necessarily. If you have regular planning meetings and
discussions in an open manner as prescribed, an occasional conference to
discuss a particular matter is not a "violation". What if someone in your
office is working on OpenStack too, and you meet in the hallway and discuss
something technical? Does that violate the 4 Opens?
>>
>> I think we have to balance realism with idealism.
>
> Like I said elsewhere, this is not about suppressing any type of
visual
> or more direct interaction... It is about making sure you are not
> excluding anyone from a project.
>
> In the precise case we are discussing here, there are complaints from
> contributors to a project that recent Hangouts meetings used in the
> Kolla team results in them being excluded (either technically by not
> being able to join them, or creating additional difficulties for
> non-native language speakers to follow or participate in them).
>
> I'm all for giving teams a bit of flexibility in how they organize,
but
> if the process chosen by some of the contributors is clearly excluding
> other contributors, falling back to a more inclusive medium (like IRC
> meetings) is the obvious solution. Jeffrey took the hard step of
raising
> the issue, I don't think ignoring his point and pretending Hangout
> meetings are just fine will get you anywhere.
>
> --
> Thierry Carrez (ttx)
>
> 
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



I do not believe anyone is willing to exclude contributors at any
stage. If such (mis)understanding is there, it needs to be discussed
why it is there and how to remediate it since it's not good for the
community and is diverting the focus.
Let's have 5-10 mins in today's weekly meeting where we get the facts
together behind the issue and try to bring it to a conclusion.

OR have a detailed discussion on #openstack-kolla


__
OpenStack Development Mailing 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] Golang technical requirements

[Doug Hellmann]

Excerpts from Dean Troyer's message of 2016-12-14 08:15:08 -0600:
> On Wed, Dec 14, 2016 at 7:46 AM, Doug Hellmann  wrote:
> > FWIW, some of the deployment tool communities (ansible and puppet,
> > I think) rely on git repos without external artifacts, and we're
> > supporting them in our release tools today. I'm not sure how
> > downstream packagers feel about the lack of external artifacts.
> 
> I recall zigo working hard for the Debian packaging to come strictly
> from Git repo tags but do not recall seeing opinions from other
> packagers.
> 
> > Were you thinking of files other than the tarball when you say
> > "generated files"?
> 
> Yes, in particular, files like AUTHORS and sample config files, which
> IIRC are generated and included in tarballs.

OK, those should be easy enough to deal with if we publish tarballs
of golang source. Perhaps someone from one of our other projects
that uses git tags as releases can comment on how they handle those
things?

Doug

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

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Michał Jastrzębski]

OK, I think we had some grave misunderstandings here.

1. ad-hoc meetings *are not* and *were never meant to be* replacement
for weekly meetings. Kolla community is single community across all
its deliverables and we hold common meetings, chats and mailing list.
Also, as long as I'm PTL, I'm unwilling to change that.
2. Hangouts were never exclusive purposefully. Meeting link was always
posted on irc, and nobody were excluded apart from people not present
on irc at given time.
3. Language barrier is something to acknowledge. I would say if we
find ourselves in situation where one of hangout users has problem
communicating, we either move to IRC or try hard to accommodate his or
hers language barrier. But on few hangouts I was on, that was not the
case. If somebody didn't join because they were ashamed, please, feel
free to approach me on private message (or if I'm not around, hangout
organizer) and let me know. That would be reason enough to stick to
IRC in my book
4. Hangouts were never exclusive to core team. Just happened that core
reviewers were majority of it - not planned or enforced.
5. Only "exclusiveness" I can think of in context of ad hoc meetings
are that people who aren't around irc cannot have voice on this
meeting. Simply because they aren't around and meeting was unplanned.
That's the case with *any* discussion outside of dedicated 1hr every
week. Granted, irc has logs. Hangouts can have notes, or outcome could
be reflected as PoC in gerrit for example (which was the case of
hangout in question..).

Ian, you mentioned that gerrit as outcome of hangout violates 4 opens...how?

Cheers,
Michal

On 14 December 2016 at 09:07, Ian Cordasco  wrote:
>
>
> -Original Message-
> From: Ed Leafe 
> Reply: OpenStack Development Mailing List (not for usage questions) 
> 
> Date: December 14, 2016 at 08:08:33
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject:  Re: [openstack-dev] [kolla][tc] Video Meetings - input requested
>
>> On Dec 14, 2016, at 7:45 AM, Ian Cordasco wrote:
>> >
>> > Taking you to the extreme of your statement, it seems there are several of 
>> > these "ad hoc"
>> meetings a week (by inc0's admission). The video meetings seem to replace 
>> the time that
>> sub-team is missing in the weekly IRC meeting, which Jeffrey has a plan to 
>> solve for.
>> >
>> > Also, based on inc0's email, it seems that these meetings consistently are 
>> > made up primarily
>> (if not singularly) of "cores". So they seem to be violating the open's in 
>> that they're
>> effectively (even if not intentionally) creating a place where only 
>> sub-groups of people
>> working on kolla (k8s) can collaborate.
>> >
>> > Further, the kolla team seems to think that code submissions sent after a 
>> > meeting are
>> sufficient artifacts from the meeting, which there seems to be a majority 
>> who feel otherwise.
>> Based on Jeffrey's descriptions, inc0's emails, and the rest of this thread, 
>> it seems
>> quite clear that kolla isn't obeying one of the 4 opens.
>>
>> Sorry, the conversation seems to have forked. The original issue was Kolla’s 
>> practices,
>> which then forked into a more general discussion. I was responding to the 
>> general side
>> of things: you can’t say that hangouts or hallway conversations are never 
>> good things.
>> But when they are misused, as is described in the Kolla case, then yes, that 
>> should not
>> be allowed to continue.
>
> No worries. I was trying to bring us back to the Kolla case. If we want to 
> discuss more general guidelines around this stuff, I'd rather not hijack this 
> thread because it highlights serious problems in how Kolla is operating that 
> a member of its team has brought up. I don't want us to side-track that 
> conversation too severely. :)
>
> --
> Ian Cordasco
>
>
> __
> OpenStack Development Mailing 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] [release][ptl][all] self-service branch management

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2016-12-14 14:28:30 +:
> On 2016-12-14 08:51:29 -0500 (-0500), Ian Cordasco wrote:
> [...]
> > I do have one question, will creating the branch's end-of-life
> > eventually work the same way? For example, Glance's projects were
> > missed in the recent liberty end of life work. Could we submit a
> > review to do that work so Josh & Tony don't have to or is that
> > something that isn't planned to work through openstack/releases?
> 
> The EOL process is still a little different because it relies on
> branch deletion, which is not an explicit permission we can delegate
> in the version of Gerrit we're running today. There's some
> indication that it will be possible in Gerrit 2.14 (not yet
> released) and we might even be able to backport that feature to 2.13
> (the version to which we're currently working on upgrading). So yes,
> there is an expectation we will safely automate EOL'ing but we don't
> have an exact timeline for it yet.

When we discussed it at the summit, the idea was to think about it
this cycle with the intent of implementing it for Pike. If we take
the approach we've used for the other automation, that would mean
scripting it out to run manually, then building something to take
inputs for the scripts from the YAML files in the releases repo
while still running the scripts manually, and then running all of
that automatically in the job. It sounds like that last part is
blocked for now, but we should be able to make some progress on the
rest of it.

Doug

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

Re: [openstack-dev] [ALU] Re: [ALU] [vitrage] how to use placeholder vertex

[Weyl, Alexey (Nokia - IL)]

1. That is correct.

2. That is not quite correct.
In static we only define the main properties of each entity, meaning type, id, 
category and thus it is ok that for each main entity we will create its 
neighbors and connect between them. There is no need for any distinguish due to 
that.


From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] 
Sent: Wednesday, December 14, 2016 5:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] [vitrage] how to use placeholder vertex

Hi, Alexey,

Thanks for the detail example. It explains the existing mechanism of vertex 
creation well.

So it looks like each resource type will have a primary datasource, e.g. 
nova.host for nova.host, nova.intance for nova.instance, that holds full 
details. Is that correct?

Not sure that you remember the long discussion in static driver review[1] or 
not. At last, we agreed on a unified entity definition for both `nova.host` and 
`switch`, no extra key to indicate it is "external" (should create a 
placeholder).

If I understand it correctly, no placeholder will be created in this case. 
Because we can not distinguish them from the static configuration. And the 
properties of `nova.host` resource shall to be merged from `static` and 
nova.host` datasources. Is that so?

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

On Wed, Dec 14, 2016 at 5:40 PM Weyl, Alexey (Nokia - IL) 
 wrote:
Hi Yujun,
 
This is a good question, and let me explain for you how it works.
Lets say we are supposed to get 2 entities from nova, nova.host called host1 
and nova.instance called vm1 and vm1 is supposed to be connected to host1.
The nova.host driver and nova.instance driver are working simultaneously and 
thus we don’t know the order in which those events will arrive.
We have 2 use cases:
1.   Host1 event arrives before vm1.
In this case the processor will call the transformer of nova.host and will 
create a vertex for host1 in the graph with the full details of host1.
Then, vm1 event will arrive, the processor will create the vm1 vertex in the 
graph, it will update the host1 properties in the graph (because the host1 
details that are created in nova.instance are only its basic details such as: 
category, type, id, is_deleted, is_placeholder they host1 properties won’t be 
changed in the graph because those details are basic and can’t be changed), and 
then it will create an edge between vm1 and host1 (only the nova.instance knows 
to which nova.host it is connected and not vice versa).
2.   Vm1 event arrives before host1.
In this case the processor will add vm1 to the graph, then it will add the 
host1 placeholder to the graph (so we will know to which host vm1 is connected) 
and then add the edge between them.
Then when the processor will handle with the host1 event, it will just add some 
properties of the host1 vertex, and of course will change the is_placeholder 
property of host1 to false.
We also has the consistency service that runs every 10 minutes (its 
configurable with the snapshot_interval) and checks if there are vertices that 
are is_placeholder=True and are in the graph more then 2*snapshot_interval time 
then it means that such a vertex of host1 for example doesn’t really exists and 
it deletes it from the graph). 
In addition, when we understand that we need to delete some entity from the 
graph, upon delete notification for example, then we don’t delete it right 
away, we change the is_deleted property of that entity to True, and we will 
delete it on the next run of the consistency service. The reason we do that, is 
because we need it for the evaluator, because it runs a subgraph matching 
algorithm on the graph, and if the entity that is supposed to be there doesn’t 
appear then it won’t work correctly.
 
The best way to create a placeholder is to call the placeholder method of the 
correct transformer using the transformers array that each transformer class 
has.
 
I hope this helps.
 
Alexey
 
From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] 
Sent: Wednesday, December 14, 2016 10:55 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] [openstack-dev] [vitrage] how to use placeholder vertex
 
Hi, root causers (assuming this nickname has been agreed)
 
It seems the placeholder is created for every neighbor of an entity[1]. I'm not 
sure what will happen if the neighbor entity has been created before. 
 
Will the graph utility handle it? Or we need to check the existence in 
transformer and deal with it?
 
Similar question for how to create a vertex when there is already a placeholder 
with same ID
 
[1]: 
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/static_physical/transformer.py#L114
 
--
Yujun
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient core

[Gary Kotton]

+1

From: Kevin Benton 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, December 14, 2016 at 4:56 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient 
core

+1

On Dec 13, 2016 17:27, "Armando M." 
> wrote:
Hi folks,

Abhishek Raut's recent involvement in OSC and python-neutronclient has helped 
moving a few efforts along in the right direction. I would like to suggest we 
double down on core firepower for the neutronclient repo alongside Akihiro [1].

This not only will help speed up our transition to OSC CLI, but also improve 
the number of folks who can effectively liasion with the OSC team, and look 
after the needs of neutron's client repo.

Many thanks,
Armando

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

__
OpenStack Development Mailing 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-Infra] [all][stable][ptls] Tagging liberty as EOL

[Vladyslav Drok]

On Wed, Dec 14, 2016 at 3:48 PM, Ian Cordasco 
wrote:

> -Original Message-
> From: Joshua Hesketh 
> Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Date: December 14, 2016 at 06:56:22
> To: OpenStack Development Mailing List ,
> openstack-infra 
> Subject:  Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls]
> Tagging liberty as EOL
>
> > The repos listed[0] have had stable/liberty branch removed and replaced
> > with a liberty-eol tag. Any open reviews have been abandoned.
> >
> > Please let me know if there are any mistakes or latecomers to the list.
> >
> > Cheers,
> > Josh
> >
> > [0]
> > https://gist.githubusercontent.com/tbreeds/
> 93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
>
> Glance was late to the party, but it should have had its liberty branches
> EOL'd as well.
>
> --
> Ian Cordasco
>

Also, after liberty was EOL'd and stable/liberty branches were removed,
liberty release note pages need to be updated to reference liberty-eol tag
instead of origin/stable/liberty, like done here
https://review.openstack.org/410798 as a temporary solution, until this is
fixed on the reno side (https://review.openstack.org/410792), if I get the
situation correctly.

-Vlad


>
>
> __
> OpenStack Development Mailing 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] [kolla][tc] Video Meetings - input requested

[Ian Cordasco]

 

-Original Message-
From: Ed Leafe 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: December 14, 2016 at 08:08:33
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

> On Dec 14, 2016, at 7:45 AM, Ian Cordasco wrote:
> >
> > Taking you to the extreme of your statement, it seems there are several of 
> > these "ad hoc"  
> meetings a week (by inc0's admission). The video meetings seem to replace the 
> time that  
> sub-team is missing in the weekly IRC meeting, which Jeffrey has a plan to 
> solve for.
> >
> > Also, based on inc0's email, it seems that these meetings consistently are 
> > made up primarily  
> (if not singularly) of "cores". So they seem to be violating the open's in 
> that they're  
> effectively (even if not intentionally) creating a place where only 
> sub-groups of people  
> working on kolla (k8s) can collaborate.
> >
> > Further, the kolla team seems to think that code submissions sent after a 
> > meeting are  
> sufficient artifacts from the meeting, which there seems to be a majority who 
> feel otherwise.  
> Based on Jeffrey's descriptions, inc0's emails, and the rest of this thread, 
> it seems  
> quite clear that kolla isn't obeying one of the 4 opens.
>  
> Sorry, the conversation seems to have forked. The original issue was Kolla’s 
> practices,  
> which then forked into a more general discussion. I was responding to the 
> general side  
> of things: you can’t say that hangouts or hallway conversations are never 
> good things.  
> But when they are misused, as is described in the Kolla case, then yes, that 
> should not  
> be allowed to continue.

No worries. I was trying to bring us back to the Kolla case. If we want to 
discuss more general guidelines around this stuff, I'd rather not hijack this 
thread because it highlights serious problems in how Kolla is operating that a 
member of its team has brought up. I don't want us to side-track that 
conversation too severely. :)

--  
Ian Cordasco


__
OpenStack Development Mailing 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] [ALU] [vitrage] how to use placeholder vertex

[Yujun Zhang]

Hi, Alexey,

Thanks for the detail example. It explains the existing mechanism of vertex
creation well.

So it looks like each resource type will have a primary datasource, e.g.
nova.host for nova.host, nova.intance for nova.instance, that holds full
details. Is that correct?

Not sure that you remember the long discussion in static driver review[1]
or not. At last, we agreed on a unified entity definition for both
`nova.host` and `switch`, no extra key to indicate it is "external" (should
create a placeholder).

If I understand it correctly, no placeholder will be created in this case.
Because we can not distinguish them from the static configuration. And the
properties of `nova.host` resource shall to be merged from `static` and
nova.host` datasources. Is that so?

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

On Wed, Dec 14, 2016 at 5:40 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

> Hi Yujun,
>
>
>
> This is a good question, and let me explain for you how it works.
>
> Lets say we are supposed to get 2 entities from nova, nova.host called
> host1 and nova.instance called vm1 and vm1 is supposed to be connected to
> host1.
>
> The nova.host driver and nova.instance driver are working simultaneously
> and thus we don’t know the order in which those events will arrive.
>
> We have 2 use cases:
>
> 1.   Host1 event arrives before vm1.
>
> In this case the processor will call the transformer of nova.host and will
> create a vertex for host1 in the graph with the full details of host1.
>
> Then, vm1 event will arrive, the processor will create the vm1 vertex in
> the graph, it will update the host1 properties in the graph (because the
> host1 details that are created in nova.instance are only its basic details
> such as: category, type, id, is_deleted, is_placeholder they host1
> properties won’t be changed in the graph because those details are basic
> and can’t be changed), and then it will create an edge between vm1 and
> host1 (only the nova.instance knows to which nova.host it is connected and
> not vice versa).
>
> 2.   Vm1 event arrives before host1.
>
> In this case the processor will add vm1 to the graph, then it will add the
> host1 placeholder to the graph (so we will know to which host vm1 is
> connected) and then add the edge between them.
>
> Then when the processor will handle with the host1 event, it will just add
> some properties of the host1 vertex, and of course will change the
> is_placeholder property of host1 to false.
>
> We also has the consistency service that runs every 10 minutes (its
> configurable with the snapshot_interval) and checks if there are vertices
> that are is_placeholder=True and are in the graph more then
> 2*snapshot_interval time then it means that such a vertex of host1 for
> example doesn’t really exists and it deletes it from the graph).
>
> In addition, when we understand that we need to delete some entity from
> the graph, upon delete notification for example, then we don’t delete it
> right away, we change the is_deleted property of that entity to True, and
> we will delete it on the next run of the consistency service. The reason we
> do that, is because we need it for the evaluator, because it runs a
> subgraph matching algorithm on the graph, and if the entity that is
> supposed to be there doesn’t appear then it won’t work correctly.
>
>
>
> The best way to create a placeholder is to call the placeholder method of
> the correct transformer using the transformers array that each transformer
> class has.
>
>
>
> I hope this helps.
>
>
>
> Alexey
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Wednesday, December 14, 2016 10:55 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [ALU] [openstack-dev] [vitrage] how to use placeholder vertex
>
>
>
> Hi, root causers (assuming this nickname has been agreed)
>
>
>
> It seems the placeholder is created for every neighbor of an entity[1].
> I'm not sure what will happen if the neighbor entity has been created
> before.
>
>
>
> Will the graph utility handle it? Or we need to check the existence in
> transformer and deal with it?
>
>
>
> Similar question for how to create a vertex when there is already a
> placeholder with same ID
>
>
>
> [1]:
> https://github.com/openstack/vitrage/blob/master/vitrage/datasources/static_physical/transformer.py#L114
>
>
> --
>
> Yujun
> __
> OpenStack Development Mailing 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] [release][ptl][all] self-service branch management

[Ian Cordasco]

 

-Original Message-
From: Jeremy Stanley 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: December 14, 2016 at 08:30:22
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [release][ptl][all] self-service branch management

> On 2016-12-14 08:51:29 -0500 (-0500), Ian Cordasco wrote:
> [...]
> > I do have one question, will creating the branch's end-of-life
> > eventually work the same way? For example, Glance's projects were
> > missed in the recent liberty end of life work. Could we submit a
> > review to do that work so Josh & Tony don't have to or is that
> > something that isn't planned to work through openstack/releases?
>  
> The EOL process is still a little different because it relies on
> branch deletion, which is not an explicit permission we can delegate
> in the version of Gerrit we're running today. There's some
> indication that it will be possible in Gerrit 2.14 (not yet
> released) and we might even be able to backport that feature to 2.13
> (the version to which we're currently working on upgrading). So yes,
> there is an expectation we will safely automate EOL'ing but we don't
> have an exact timeline for it yet.

Awesome! Thank you so much for that answer. =D

--  
Ian Cordasco


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

[openstack-dev] [nova] parameter validation for GET /servers - current concensus from the Nova API meeting

[Sean Dague]

We spent most of the Nova API meeting today to try to get to a concensus
space on https://review.openstack.org/#/c/393205/ which is about
validating the parameters passed for sorting / filtering on the servers
resource. Today, we pretty much take whatever you throw in there and jam
it in the sql filters so we're bleeding out internal details, and
letting you do weird things like sort on join tables which causes
potential major performance issues.

The solution is be explicit about the filters that we support. The
challenge is going from weird grey space where none of this is well
defined, to a well defined space.

We all AGREED that we need to be explicit about what's supported, the
current state of the world is madness.

We still need final agreement on what that whitelist is. John and Alex
are going to validate that over the next day or so. The intent is to
keep this pretty wide to anything sensible in the REST representation
that's not going to kill us on the join tables side.

One of the sticking points on the spec was the idea that everything in
the filter/sort whitelist needed performant indexes. This was going to
make the whitelist smaller, then got push back from ops that really want
some of those other things.

We all AGREED to *drop* that requirement on indexing everything. With
Cells v2 coming, searchlight going to be needed for efficient full cloud
searching of instances, the entire performance profile of a lot of these
are going to change over the next couple of cycles. Instead of focusing
on tightening those up now, we should just include documentation on how
to performance tune your db if your users are regularly using filters we
don't optimize for.

This REMOVES the need for the policy point which was going to allow
these things, as we'll keep the whitelist large. It means every cloud
has the same behavior.

Lastly, there was the question of admin vs. non admin allowed parameters.

We AGREED that the only things we'd make admin only are things that leak
cloud internals, which is node/host attributes. In an ideal future we'd
like non admin users to be able to operate on the hashed versions of
these (currently a sha(project_id + host)), however that's all done
python side now for display, so it's not really an option today.

This would make things like `project_id` and `all_tenants` valid filters
for regular users. However, if we interpret them within the user's
context, that's fine. `all_tenants` means "All tenants that I am allowed
to see". For a Nova admin, that's everyone. In a future with
hierarchical multi tenancy, this might be a subtree. project_id is fine
as long as it's filtered by the project_id's you have access to in your
context. Mostly it will be a noop for normal users, but there is no
reason not to allow it. Plus it does create a soft roll into
hierarchical multi tenancy.


We also AGREED that we really need to get the spec into a merge state by
Friday, and that folks would start working on code under the assumption
that the agreement above is where we are headed. The only really
remaining sticking point is the exact content of the whitelist, which
John and Alex are going to focus on. Then clean up language in the spec.

For folks not in this meeting, please make sure we didn't miss anything
here. Hopefully we can get this closed shortly.

Thanks a bunch,

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [release][ptl][all] self-service branch management

[Jeremy Stanley]

On 2016-12-14 08:51:29 -0500 (-0500), Ian Cordasco wrote:
[...]
> I do have one question, will creating the branch's end-of-life
> eventually work the same way? For example, Glance's projects were
> missed in the recent liberty end of life work. Could we submit a
> review to do that work so Josh & Tony don't have to or is that
> something that isn't planned to work through openstack/releases?

The EOL process is still a little different because it relies on
branch deletion, which is not an explicit permission we can delegate
in the version of Gerrit we're running today. There's some
indication that it will be possible in Gerrit 2.14 (not yet
released) and we might even be able to backport that feature to 2.13
(the version to which we're currently working on upgrading). So yes,
there is an expectation we will safely automate EOL'ing but we don't
have an exact timeline for it yet.
-- 
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

Re: [openstack-dev] Golang technical requirements

[Dean Troyer]

On Wed, Dec 14, 2016 at 7:46 AM, Doug Hellmann  wrote:
> FWIW, some of the deployment tool communities (ansible and puppet,
> I think) rely on git repos without external artifacts, and we're
> supporting them in our release tools today. I'm not sure how
> downstream packagers feel about the lack of external artifacts.

I recall zigo working hard for the Debian packaging to come strictly
from Git repo tags but do not recall seeing opinions from other
packagers.

> Were you thinking of files other than the tarball when you say
> "generated files"?

Yes, in particular, files like AUTHORS and sample config files, which
IIRC are generated and included in tarballs.

dt

-- 

Dean Troyer
dtro...@gmail.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] Golang technical requirements

[Dean Troyer]

On Wed, Dec 14, 2016 at 4:25 AM, Thierry Carrez  wrote:
> I don't think we need to stop producing and publishing source code
> tarballs in the Go case, just because it's not the primary way people
> consume the code. Publication of the source code is something we need to
> do as part of the open source license we use, and some still consider
> tarball publication to be a clearer form of "publication" than keeping a
> git server up.

I'll buy that.  Overall, I don't think we are doing anything today
that is incompatible with what I see golang needing.  This is really a
side-issue that I have heard you, and maybe others, ask about in
general, so I included it to affirm the golang case. Making changes to
the general case is separate in my mind, but this may be a good time
to consider it in parallel since we're thinking about these things
again in detail.

> Beyond the source though, one question is whether we should build, sign
> and distribute binary artifacts (compiled code), or if tagging a source
> repo (and producing a source code tarball) is sufficient. And if we do
> distribute binaries, would we only do that for some deliverables (like
> the top ones that are supposed to be directly used by users) or for
> everything ?

I am not in favor of distributing binaries as a matter of course,
although from a purely selfish point of view I want the ability to do
that for a future CLI binary for Windows.  That CLI doesn't exist yet,
and I  do not see another reason (yet?) to include this in the initial
task list.

dt

-- 

Dean Troyer
dtro...@gmail.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] [kolla][tc] Video Meetings - input requested

[Ed Leafe]

On Dec 14, 2016, at 7:45 AM, Ian Cordasco  wrote:
> 
> Taking you to the extreme of your statement, it seems there are several of 
> these "ad hoc" meetings a week (by inc0's admission). The video meetings seem 
> to replace the time that sub-team is missing in the weekly IRC meeting, which 
> Jeffrey has a plan to solve for.
> 
> Also, based on inc0's email, it seems that these meetings consistently are 
> made up primarily (if not singularly) of "cores". So they seem to be 
> violating the open's in that they're effectively (even if not intentionally) 
> creating a place where only sub-groups of people working on kolla (k8s) can 
> collaborate.
> 
> Further, the kolla team seems to think that code submissions sent after a 
> meeting are sufficient artifacts from the meeting, which there seems to be a 
> majority who feel otherwise. Based on Jeffrey's descriptions, inc0's emails, 
> and the rest of this thread, it seems quite clear that kolla isn't obeying 
> one of the 4 opens.

Sorry, the conversation seems to have forked. The original issue was Kolla’s 
practices, which then forked into a more general discussion. I was responding 
to the general side of things: you can’t say that hangouts or hallway 
conversations are never good things. But when they are misused, as is described 
in the Kolla case, then yes, that should not be allowed to continue.


-- Ed Leafe






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

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Ed Leafe]

On Dec 14, 2016, at 4:03 AM, Thierry Carrez  wrote:
> 
> Jeffrey took the hard step of raising
> the issue, I don't think ignoring his point and pretending Hangout
> meetings are just fine will get you anywhere.

That is why I suggested a balanced approach. If the current practice is 
impacting the members of the team negatively, then it is clearly out of 
balance. 

-- Ed Leafe






__
OpenStack Development Mailing 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] Propose to normalize namespaces

[Doug Hellmann]

Excerpts from Morales, Victor's message of 2016-12-02 19:07:25 +:
> Hey there, 
> 
> There is a mismatch of namespaces in neutron which uses AGENT and agent which 
> is addressed by Ihar in the patch[1].  That raised the question is 
> olo-config-generator should be normalize this namespaces, maybe(with my 
> limited knowledge of oslo.conf) this change can be placed in _clean_opts 
> function[2].  I personally like what Doug is suggesting[3], emitting a 
> warning where is mixing case, which at least give us an idea of places where 
> is having the same issue and eventually normalize them.  Any thoughts on this?
> 
> Regards, 
> 
> Victor Morales
> 
> [1] https://review.openstack.org/#/c/404362
> [2] 
> https://github.com/openstack/oslo.config/blob/master/oslo_config/generator.py#L331-L362
> [3] https://bugs.launchpad.net/oslo.config/+bug/1646084/comments/2

That _cleanup_opts() function looks like a good place to do the
normalization to all lower-case. Remember that "DEFAULT" is properly all
upper-case, though.

Doug

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

Re: [openstack-dev] Golang technical requirements

[Doug Hellmann]

Excerpts from Dean Troyer's message of 2016-12-13 12:45:07 -0600:
> Release Deliverables
> 
> OpenStack still officially considers the tarballs generated during the
> release rpocess to be our official deliverable.  Many downstream
> consumers, however, bypass those and go directly to the tagged
> releases in the Git repos.  The Golang community has no real culture
> of using tarballs at all, given the 'go get' functionality bult in to
> the tooling directly for checking out remote repos.  One obvious
> shortcoming in just defining the release to be Git repo tags is our
> use of generated files.

FWIW, some of the deployment tool communities (ansible and puppet,
I think) rely on git repos without external artifacts, and we're
supporting them in our release tools today. I'm not sure how
downstream packagers feel about the lack of external artifacts.

I think I would be satisfied to see tags, even if we do not build
artifacts from them. We can still run other parts of the release
process, such as building release notes and documentation with the
version number.

Were you thinking of files other than the tarball when you say
"generated files"?

Doug

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

[openstack-dev] [release] Release countdown for week R-10, 12-16 Dec

[Doug Hellmann]

Focus
-

Feature work and major refactoring for bug fixes should be well
under way as we reach the second milestone deadline of
Thursday 15 Dec.

Release Actions
---

Submit the tag request for the Ocata 2 milestone by 15 Dec. Several
projects missed the Ocata-1 deadline. Keep in mind that the milestone
deadlines are date-based and not feature based. Tag HEAD as a
point-in-time indicator of progress, and don't wait for features
to land.

Important Dates
---

Ocata 2 Milestone: 15 Dec

Ocata release schedule: http://releases.openstack.org/ocata/schedule.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

[openstack-dev] [release][ptl][all] self-service branch management

[Doug Hellmann]

The release team is pleased to announce that the branch automation
work is now complete, and that teams can now manage feature and
stable branch creation through the openstack/releases repository.

Creating a branch is very similar to creating a release: Edit the
appropriate file in the releases repo to add the branch information,
let the release team review it, and then when the patch is approved
the bots make your branch. New branches come with patches to update
.gitreview, reno, and constraint settings where needed.

For the complete details about how to format a branch request, see
the README.rst file in the repo [1].

Thanks, as always, to the Infra team for their help in implementing
this automation.

Doug

[1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n63

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

[openstack-dev] [release] Release countdown for week R-11, 5-9 Dec

[Doug Hellmann]

Focus
-

We've passed the first milestone, so teams should be focused on
feature development.

The second milestone deadline is Thursday 15 Dec.

General Notes
-

All release announcements are now being sent to the new openstack-releases
mailing list instead of openstack-dev or openstack-announce. Refer
to the mailing list post [1] for more details.

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107629.html

Release Actions
---

Prepare for the Ocata 2 milestone coming up on 15 Dec. Several
projects missed the Ocata 1 deadline. Keep in mind that the milestone
deadlines are date-based and not feature based. Tag HEAD as a
point-in-time indicator of progress, and don't wait for features
to land.

Important Dates
---

Ocata 2 Milestone: 15 Dec

Ocata release schedule: http://releases.openstack.org/ocata/schedule.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] [ptl][release] ocata release management communication

[Doug Hellmann]

Excerpts from Rob C's message of 2016-11-30 18:38:53 +:
> [Resending without the PTLs in CC because it got my mail stuck in the spam
> filters]
> 
> I'm struggling to find good info on when the adjusted PTL nomination cycle
> starts.
> 
> I've checked here: https://releases.openstack.org/ocata/schedule.
> html#pike-ptls-self-nomination but it looks like the 'elections' section
> was supposed to be added to the table and wasn't.
> 
> I know from the updates to the charter that the elections should happen on
> or before R-3 but it doesn't provide any clarity on how much before then
> the nominations should be made?
> 
> Cheers
> -Rob

Thierry proposed some dates in https://review.openstack.org/404275 but
we need to get the elections team to sign off on them before they're
official.

Doug

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

Re: [openstack-dev] [all][ptls][tc][goals] community goals for Pike

[Doug Hellmann]

Excerpts from Emilien Macchi's message of 2016-11-29 19:39:03 -0500:
> A few months ago, our community started to find and work on
> OpenStack-wide goals to "achieve visible common changes, push for
> basic levels of consistency and user experience, and efficiently
> improve certain areas where technical debt payments have become too
> high – across all OpenStack projects".
> 
> http://governance.openstack.org/goals/index.html
> 
> We started to define a first Goal in Ocata (Remove Copies of Incubated
> Oslo Code) and we would like to move forward in Pike.
> I see 3 actions we could take now:
> 
> 1) Collect feedback of our first iteration of Community Goals in
> OpenStack during Ocata. What went well? What was more challenging?
> 
> Some examples:
> - should we move the goal documents into a separate repo to allow a
> shorter review time, where we could just have 2 TC members approve
> them instead of waiting a week?
> -  we expected all teams to respond to all goals, even if they have no
> work to do. Should we continue that way?
> - should we improve the guidance to achieve Goals?
> 
> I created an etherpad if folks want to give feedback:
> https://etherpad.openstack.org/p/community-goals-ocata-feedback

We also collected some feedback at the summit, with notes in
https://etherpad.openstack.org/p/ocata-summit-xp-community-wide-goals

One piece of feedback was that restricting the work of writing up goals
to TC members felt exclusionary. We set it up that way originally to
make it clear that the goals process was not just a replacement for
cross-project specs and writing up the goal in the governance repo
should happen late in the discussion process, rather than at the
beginning. Maybe we can achieve the same effect by switching to having
TC "sponsors" for goals that should be identified before something is
written up, but allowing anyone to do the writing?

> 2) Goals backlog - https://etherpad.openstack.org/p/community-goals
> - new Goals are highly welcome.
> - each Goal would be achievable in one cycle, if not I think we need
> to break it down into separated Goals (with connections).
> - some Goals already have a team (ex: Python 3) but some haven't.
> Maybe could we dress a list of people able to step-up and volunteer to
> help on these ones.
> - some Goals might require some documentation for how to achieve it.
> 
> I think for now 2) can be discussed on the etherpad, though feel free
> to propose another channel.
> 
> 3) Choose Goals for Pike.
> Some of us already did, but we might want to start looking at what
> Goals we would like to achieve during Pike cycle.
> I was thinking at giving a score to the Goals, that could be
> calculated by its priority (I know it's vague but we know what is
> really urgent for us versus what can wait 6 months); but also the
> number of people who are interested to contribute on a Goal (if this
> Goal doesn't have a team yet).
> For now, openstack/governance is the repository for Goals, please
> propose them here.
> 
> 
> Please give feedback, we're doing iterations here, and hopefully we'll
> improve our Community Goals over the next cycles.
> Thanks for your time,

__
OpenStack Development Mailing 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][monasca] Can we uncap python-kafka ?

[Doug Hellmann]

Excerpts from Clint Byrum's message of 2016-12-02 09:44:40 -0800:
> Excerpts from Tony Breeds's message of 2016-12-02 15:26:40 +1100:
> > On Thu, Dec 01, 2016 at 08:41:54AM -0800, Joshua Harlow wrote:
> > > Keen, Joe wrote:
> > > > I¹ll look into testing the newest version of kafka-python and see if it
> > > > meets our needs.  If it still isn¹t stable and performant enough what 
> > > > are
> > > > the available options?
> > > 
> > > Fix the kafka-python library or fix monasca; those seem to be the options 
> > > to
> > > me :)
> > 
> > Yup, Also worth including fix oslo.messaging to meet monasca's needs.  But
> > *something* needs fixing.
> >  
> > > I'd also not like to block the rest of the world (from using newer 
> > > versions
> > > of kafka-python) during this as well. But then this may diverge/expand 
> > > into
> > > a discussion we had a few summits ago, about getting rid of
> > > co-instability...
> > 
> > lalalalala not listening ;P
> > 
> > Less flippantly, there are a couple of ways to do this but IMO they're not 
> > in
> > the best interest of OpenStack.
> > 
> > 1. vendor/fork python-kafka 0.X
> > 2. Stop the proposal-bot from syncing with monasca, thereby allowing it to 
> > use
> > python-kafka 0.X at the expense of co-installability.
> 
> Could there be a (3)?
> 
>  3. change the oslo driver to work with the currently pinned
>  python-kafka version?

Isn't the point that the pinned version, 0.9.5, is out of date? The
current version is 1.3.1.

Doug

> 
> > 
> > Fortunately either option is easy to reverse once the underlying issue is 
> > fixed.
> > 
> > Yours Tony.
> 

__
OpenStack Development Mailing 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] [release] Release management team draft logo

[Doug Hellmann]

Excerpts from Steve Martinelli's message of 2016-12-02 08:04:51 -0500:
> A bit of colour should will go a long way here, black and brown would help
> make it more obvious (IMO).

Yes, Heidi's email does say this is the version without color. There are
some very subtle grey patches that line up with what I expect to see for
markings on a border collie, so I'm tentatively OK with this pending
seeing the color version.

Doug

> 
> On Fri, Dec 2, 2016 at 4:05 AM, Thierry Carrez 
> wrote:
> 
> > Doug Hellmann wrote:
> > > Release team, please take a look at the attached logo and let me know
> > > what you think.
> >
> > It's not immediately obvious to me it's a shepherd dog, but then I don't
> > exactly know how to make that more obvious.
> >
> > --
> > Thierry Carrez (ttx)
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

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

Re: [openstack-dev] [all] Creating a new IRC meeting room ?

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2016-12-02 11:35:05 +0100:

> So I'm now wondering how much that artificial scarcity policy is hurting
> us more than it helps us. I'm still convinced it's very valuable to have
> a number of "meetings rooms" that you can lurk in and be available for
> pings, without having to join hundreds of channels where meetings might
> happen. But I'm not sure anymore that maintaining an artificial scarcity
> is helpful in limiting conflicts, and I can definitely see that it
> pushes some meetings away from the meeting channels, defeating their
> main purpose.

I lurk in the meeting rooms to respond to questions about releases,
reno, and a couple of the oslo modules. I would prefer to just hang out
in #openstack-release and #openstack-oslo and have folks come there if
they have those questions, though.

Doug

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

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

Excerpts from Kevin Benton's message of 2016-11-30 03:23:04 -0700:
> >I'll let someone from the Neutron team fill in the details behind their 
> >decision,
> because I don't want to misrepresent them.
> 
> I can shed a bit of light on this since I'm a core and had been working for
> a driver vendor at the time of the split. There were a few areas of
> contention:

Thanks, Kevin, it's very helpful to have these points laid out.

> * Releases and stable branches:
> Vendors develop features for their driver and want them available to all of
> their customers immediately after they do their own QA. Additionally, they
> want them available to the customers running security-only and even EOL
> branches. This obviously violates the release process for upstream
> openstack stuff, so terrible, terrible things were done to apply patches to
> these old branches at customer sites.

Drivers can use either the cycle-with-intermediary or independent
release models and have releases at any point within a cycle, so
that's an easy one to solve.

The new driverfixes/ branch type, created as a result of the cinder
team's need for something similar to what you describe here, should
solve the other issue of maintaining support for drivers beyond the
normal EOL point for a stable branch.

> * Pass-through drivers:
> In response to the issue above, many vendors ended up creating 'vendor-lib'
> or an HTTP/RPC API to which their Neutron in-tree driver would just pass
> every call with as little logic as possible. When drivers went this
> direction, we could never tell their current functioning state because we
> were always one vendor release (of either vendor-lib or vendor HTTP API)
> away from them breaking something.
> 
> IIRC there was a design session in the summit about Cinder having this
> problem. They were trying to determine how thin a driver was allowed to be
> before the cores would refuse to accept it. I don't think they reached a
> consensus on what the limit is or if there should even be a limit.

This I do agree is a problem. A pass-through driver provides less value
because it doesn't allow the community to collaborate on the development
of the driver itself, unless the other components are also open sourced.

> * Changes impossible to judge for cores:
> For the logic changes that do occur in tree, cores could only really tell
> if they looked like correct python and appeared to do something sane at a
> very high level. Judging if the change even worked was entirely dependent
> on a good 3rd-party CI response. Judging things like backwards
> compatibility with older vendor backends was completely out of the question
> because no vendor offered a full matrix CI test with every version of their
> product. So reviewing driver changes became somewhat of a rubber stamping
> process that many were not interested in and/or comfortable doing.

This strikes me as an "ownership" issue, in the sense that the
Neutron team feels a sense of ownership of something that they are
too far away from to also feel pride in managing. That's an
understandable tension, and the solution is to let go of the ownership
and let the people close to the code handle it.

If the drivers are out of tree, in a separate repo under the main
team's umbrella, the core reviewers could delegate management of
the code to a subteam and not worry about handling reviews. Clearly
documenting who "owns" each driver and where to go for support, to
file bugs, etc. should go hand-in-hand with this organization, just
like it does for OpenStack as a whole.

> >I hope I'm not the only one who thinks drivers are important?
> 
> Of course we care about drivers (see neutron-lib effort). However, it
> wasn't clear what the point of having them in tree was when cores couldn't
> reason about the changes or even try them without special-purpose hardware.

Yes, of course. My comment was in response to Zane's hyperbolic and
inflammatory rhetoric, nothing else.

> How do you foresee the drivers improving if we bring them back in tree?

I'm not asking you to bring the drivers in-tree. I'm asking you to
bring them back under the umbrella of repositories which are part
of the neutron team.  And I have no idea if the code quality will
change; that's not the point. The point is to encourage more general
collaboration by being welcoming to the human beings who are trying
to contribute to OpenStack.

By all means, let's set some boundaries (no pass-through drivers
would be a good one, so would having some sort of third-party CI
testing their driver), but let's not exclude people from contributing
out of hand.

Doug

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

Re: [openstack-dev] [release][ptl][all] self-service branch management

[Ian Cordasco]

-Original Message-
From: Doug Hellmann 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: December 14, 2016 at 07:47:58
To: openstack-dev 
Subject:  [openstack-dev] [release][ptl][all] self-service branch management

> [Sending again due to mail delivery issues.]
>
> The release team is pleased to announce that the branch automation
> work is now complete, and that teams can now manage feature and
> stable branch creation through the openstack/releases repository.
>
> Creating a branch is very similar to creating a release: Edit the
> appropriate file in the releases repo to add the branch information,
> let the release team review it, and then when the patch is approved
> the bots make your branch. New branches come with patches to update
> .gitreview, reno, and constraint settings where needed.
>
> For the complete details about how to format a branch request, see
> the README.rst file in the repo [1].
>
> Thanks, as always, to the Infra team for their help in implementing
> this automation.
>
> Doug
>
> [1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n63

This looks excellent, Doug!

Thank you Release & Infra teams!

I do have one question, will creating the branch's end-of-life
eventually work the same way? For example, Glance's projects were
missed in the recent liberty end of life work. Could we submit a
review to do that work so Josh & Tony don't have to or is that
something that isn't planned to work through openstack/releases?

Cheers,
--
Ian Cordasco

__
OpenStack Development Mailing 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] [all][stable][ptls] Tagging liberty as EOL

[Ian Cordasco]

-Original Message-
From: Joshua Hesketh 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: December 14, 2016 at 06:56:22
To: OpenStack Development Mailing List , 
openstack-infra 
Subject:  Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls] Tagging 
liberty as EOL

> The repos listed[0] have had stable/liberty branch removed and replaced
> with a liberty-eol tag. Any open reviews have been abandoned.
>  
> Please let me know if there are any mistakes or latecomers to the list.
>  
> Cheers,
> Josh
>  
> [0]
> https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
>   

Glance was late to the party, but it should have had its liberty branches EOL'd 
as well.

--  
Ian Cordasco


__
OpenStack Development Mailing 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] Golang technical requirements

[Doug Hellmann]

[Sending again due to mail delivery issues.]

Excerpts from Dean Troyer's message of 2016-12-13 12:45:07 -0600:
> Release Deliverables
> 
> OpenStack still officially considers the tarballs generated during the
> release rpocess to be our official deliverable.  Many downstream
> consumers, however, bypass those and go directly to the tagged
> releases in the Git repos.  The Golang community has no real culture
> of using tarballs at all, given the 'go get' functionality bult in to
> the tooling directly for checking out remote repos.  One obvious
> shortcoming in just defining the release to be Git repo tags is our
> use of generated files.

FWIW, some of the deployment tool communities (ansible and puppet,
I think) rely on git repos without external artifacts, and we're
supporting them in our release tools today. I'm not sure how
downstream packagers feel about the lack of external artifacts.

I think I would be satisfied to see tags, even if we do not build
artifacts from them. We can still run other parts of the release
process, such as building release notes and documentation with the
version number.

Were you thinking of files other than the tarball when you say
"generated files"?

Doug

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

[openstack-dev] [release] Release countdown for week R-10, 12-16 Dec

[Doug Hellmann]

[Sending again due to mail delivery issues.]

Focus
-

Feature work and major refactoring for bug fixes should be well
under way as we reach the second milestone deadline of
Thursday 15 Dec.

Release Actions
---

Submit the tag request for the Ocata 2 milestone by 15 Dec. Several
projects missed the Ocata-1 deadline. Keep in mind that the milestone
deadlines are date-based and not feature based. Tag HEAD as a
point-in-time indicator of progress, and don't wait for features
to land.

Important Dates
---

Ocata 2 Milestone: 15 Dec

Ocata release schedule: http://releases.openstack.org/ocata/schedule.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] [kolla][tc] Video Meetings - input requested

[Ian Cordasco]

-Original Message-
From: Ed Leafe 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: December 13, 2016 at 21:45:39
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

> On Dec 12, 2016, at 10:30 PM, Steven Dake (stdake) wrote:
>  
> > The issue raised is they violate the 4 opens.
>  
> Not necessarily. If you have regular planning meetings and discussions in an 
> open manner  
> as prescribed, an occasional conference to discuss a particular matter is not 
> a "violation".  
> What if someone in your office is working on OpenStack too, and you meet in 
> the hallway  
> and discuss something technical? Does that violate the 4 Opens?
>  
> I think we have to balance realism with idealism.

Taking you to the extreme of your statement, it seems there are several of 
these "ad hoc" meetings a week (by inc0's admission). The video meetings seem 
to replace the time that sub-team is missing in the weekly IRC meeting, which 
Jeffrey has a plan to solve for.

Also, based on inc0's email, it seems that these meetings consistently are made 
up primarily (if not singularly) of "cores". So they seem to be violating the 
open's in that they're effectively (even if not intentionally) creating a place 
where only sub-groups of people working on kolla (k8s) can collaborate.

Further, the kolla team seems to think that code submissions sent after a 
meeting are sufficient artifacts from the meeting, which there seems to be a 
majority who feel otherwise. Based on Jeffrey's descriptions, inc0's emails, 
and the rest of this thread, it seems quite clear that kolla isn't obeying one 
of the 4 opens.

--  
Ian Cordasco


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

[openstack-dev] [release][ptl][all] self-service branch management

[Doug Hellmann]

[Sending again due to mail delivery issues.]

The release team is pleased to announce that the branch automation
work is now complete, and that teams can now manage feature and
stable branch creation through the openstack/releases repository.

Creating a branch is very similar to creating a release: Edit the
appropriate file in the releases repo to add the branch information,
let the release team review it, and then when the patch is approved
the bots make your branch. New branches come with patches to update
.gitreview, reno, and constraint settings where needed.

For the complete details about how to format a branch request, see
the README.rst file in the repo [1].

Thanks, as always, to the Infra team for their help in implementing
this automation.

Doug

[1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n63

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

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Steven Dake (stdake)]

Swapnil,

If you want to do that, please add it to the meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Kolla

Regards
-steve


-Original Message-
From: Swapnil Kulkarni 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, December 14, 2016 at 3:22 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

On Wed, Dec 14, 2016 at 3:33 PM, Thierry Carrez  
wrote:
> Ed Leafe wrote:
>> On Dec 12, 2016, at 10:30 PM, Steven Dake (stdake)  
wrote:
>>
>>> The issue raised is they violate the 4 opens.
>>
>> Not necessarily. If you have regular planning meetings and discussions 
in an open manner as prescribed, an occasional conference to discuss a 
particular matter is not a "violation". What if someone in your office is 
working on OpenStack too, and you meet in the hallway and discuss something 
technical? Does that violate the 4 Opens?
>>
>> I think we have to balance realism with idealism.
>
> Like I said elsewhere, this is not about suppressing any type of visual
> or more direct interaction... It is about making sure you are not
> excluding anyone from a project.
>
> In the precise case we are discussing here, there are complaints from
> contributors to a project that recent Hangouts meetings used in the
> Kolla team results in them being excluded (either technically by not
> being able to join them, or creating additional difficulties for
> non-native language speakers to follow or participate in them).
>
> I'm all for giving teams a bit of flexibility in how they organize, but
> if the process chosen by some of the contributors is clearly excluding
> other contributors, falling back to a more inclusive medium (like IRC
> meetings) is the obvious solution. Jeffrey took the hard step of raising
> the issue, I don't think ignoring his point and pretending Hangout
> meetings are just fine will get you anywhere.
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



I do not believe anyone is willing to exclude contributors at any
stage. If such (mis)understanding is there, it needs to be discussed
why it is there and how to remediate it since it's not good for the
community and is diverting the focus.
Let's have 5-10 mins in today's weekly meeting where we get the facts
together behind the issue and try to bring it to a conclusion.

OR have a detailed discussion on #openstack-kolla

__
OpenStack Development Mailing 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] Proposing Abhishek Raut as neutronclient core

[Brian Haley]

+1

On 12/13/16 8:22 PM, Armando M. wrote:

Hi folks,

Abhishek Raut's recent involvement in OSC and python-neutronclient has
helped moving a few efforts along in the right direction. I would like
to suggest we double down on core firepower for the neutronclient repo
alongside Akihiro [1].

This not only will help speed up our transition to OSC CLI, but also
improve the number of folks who can effectively liasion with the OSC
team, and look after the needs of neutron's client repo.

Many thanks,
Armando

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


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




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

Re: [openstack-dev] [Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

[David Moreau Simard]

Part of the issue here is that the CentOS team told us yesterday they were
having technical difficulties signing and releasing the new 2.6.0 packages
to the public mirrors.

Yesterday around 6:30PM UTC they gave us an approximate ETA of 5 hours. I
see this morning that it still seems problematic and I pinged them in order
to let them know.

We've definitely also seen glimpses of issues related to running qemu-kvm
<2.6.0 paired with CentOS 7.3 so thanks for the clarifications.

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

On Dec 13, 2016 11:06 PM, "Steve Gordon"  wrote:

> - Original Message -
> > From: "David Moreau Simard" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>, "OpenStack
> > Operators" 
> > Sent: Tuesday, December 13, 2016 6:13:12 PM
> > Subject: [Openstack-operators] [all] Known issue with CentOS 7.3 and
> qemu-kvm(-ev) 2.6.0
> >
> > Hi,
> >
> > CentOS 7.3 was released yesterday and a newer version of qemu-kvm-ev
> > was shipped as part of this release if you have the CentOS
> > Virtualization SIG repositories enabled.
>
> Isn't the issue that the newer version of qemu-kvm-ev (2.6.0) *hasn't*
> shipped yet? E.g. it's not in:
>
> http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/
>
> Hence the mismatch is created because the CentOS repos contain Libvirt
> 2.0.0 but not a matching qemu-kvm-ev build (yet).
>
> Thanks,
>
> Steve
>
> > If you're using RDO >= Newton, you will have this repository enabled.
> > It was not yet enforced in the Mitaka release so you might or might
> > not have it, depending on your deployment.
> > Older releases of OpenStack may also be affected but they are not
> > proactively tested anymore due to EOL.
> >
> > There is currently a known issue when using the following
> > configuration in nova for compute:
> > ==
> > virt_type=qemu
> > cpu_mode=host-model
> > ==
> >
> > This combination will yield in failed attempts at creating instances
> > and you will see errors like these in nova-compute.log [1] or the
> > libvirt logs [2].
> > The problem boils down to libvirt trying to pass a cpu extension that
> > is unknown to qemu:
> > ==
> > qemu-kvm: CPU feature arat not found
> > ==
> >
> > There is a bugzilla [3] for this issue but in the meantime users are
> > encouraged to work around the issue by setting "cpu_mode=none" if they
> > are using the qemu (not KVM) hypervisor.
> > Please note that Nova defaults the 'cpu_mode' parameter to
> > 'host-model' [4] if 'cpu_mode' is not explicitely configured and
> > 'virt_type' is 'qemu' so if you're running into this issue, you will
> > need to explicitely configure it.
> >
> > [1]:
> > http://logs.openstack.org/76/409476/4/check/gate-puppet-
> openstack-integration-4-scenario003-tempest-centos-7/
> 8881991/logs/nova/nova-compute.txt.gz#_2016-12-13_16_39_50_832
> > [2]:
> > http://logs.openstack.org/76/409476/4/check/gate-puppet-
> openstack-integration-4-scenario003-tempest-centos-7/
> 8881991/logs/libvirt/qemu/instance-0001.txt.gz
> > [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1371617
> > [4]:
> > http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/
> libvirt/driver.py?id=146b27f22327f8d60c1017c22ccf18d0e16f1eb7#n3411
> >
> > David Moreau Simard
> > Senior Software Engineer | Openstack RDO
> >
> > dmsimard = [irc, github, twitter]
> >
> > ___
> > OpenStack-operators mailing list
> > openstack-operat...@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
>
__
OpenStack Development Mailing 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] [all][stable][ptls] Tagging liberty as EOL

[Joshua Hesketh]

The repos listed[0] have had stable/liberty branch removed and replaced
with a liberty-eol tag. Any open reviews have been abandoned.

Please let me know if there are any mistakes or latecomers to the list.

Cheers,
Josh

[0]
https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt

On Fri, Dec 9, 2016 at 3:55 PM, Joshua Hesketh 
wrote:

> Hey Tony and all,
>
> I'm happy to take care of these retirements. However I probably can't get
> to it until Tuesday next week. So assuming no other infra root beats me to
> it I'll look at it then.
>
> Cheers,
> Josh
>
> On Thu, Dec 8, 2016 at 3:58 PM, Tony Breeds 
> wrote:
>
>> On Tue, Nov 22, 2016 at 01:35:48PM +1100, Tony Breeds wrote:
>>
>> > I'll batch the removal of the stable/liberty branches between Nov 28th
>> and Dec
>> > 3rd (UTC+1100).  Then during Decemeber I'll attempt to cleanup
>> zuul/layout.yaml
>> > to remove liberty exclusions and jobs.
>>
>> This took longer as there are a few repos that are scheduled for EOL that
>> were a
>> little problematic during the kilo cycle.  I've updated the list at [1]
>>
>> Can the infra team please run eol_branch.sh [2] over the repos listed at
>> that
>> URL [1] and flagged with 'Please EOL'.  The others will need to be done
>> later.
>>
>> eol_branch.sh needs just the repo names what can be generated with
>> something like:
>> URL=https://gist.githubusercontent.com/tbreeds/93cd346c37aa4
>> 6269456f56649f0a4ac/raw/liberty_eol_data.txt
>> eol_branch.sh REPOS=$(curl -s $URL | awk '/Please EOL/ {print $1}')
>>
>> The data format is a balance between human and machine readable.
>>
>> Yours Tony.
>>
>> [1] https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0
>> a4ac#file-liberty_eol_data-txt
>> [2] http://git.openstack.org/cgit/openstack-infra/release-tools/
>> tree/eol_branch.sh
>>
>> ___
>> OpenStack-Infra mailing list
>> openstack-in...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>
>
__
OpenStack Development Mailing 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][Upgrade Squad syncup]

[mathieu bultel]

On 12/14/2016 10:17 AM, Julie Pichon wrote:
> On 14 December 2016 at 08:56, Dougal Matthews  wrote:
>> On 13 December 2016 at 16:12, Emilien Macchi  wrote:
>>> On Tue, Dec 13, 2016 at 10:58 AM, Marios Andreou 
>>> wrote:
 Hi OOOs o/ as discussed on this week's upstream weekly irc meeting [1]
 lets schedule a syncup on the Ocata composable upgrades work and how we
 will build on Steve Hardy's base ansible driven implementation.

 IMO a call would be the best format (I propose to schedule a bluejeans
 call, though I am open to any other suggestions). For now I've setup a
 doodle poll at http://doodle.com/poll/rp8ck6tstaagftqr - please vote if
 you'd like to participate. Assuming we go with bluejeans (unless I hear
 strong pushback/other suggestions) then I'll try and make a recording
 available to address the concerns expressed at

 http://lists.openstack.org/pipermail/openstack-dev/2016-December/108780.html
 (thanks shardy for pointing that out).

 Moving forward we should probably switch to an irc based syncup,
>>> As long as:
>>> - we have zero pushbash from our community members
>>> - anyone can join the call
>>> - our design and discussions stay open (mailing-list, tripleo-specs, IRC)
>>> - a nice summary is sent to openstack-dev
>> or maybe even better, a recording is posted online?
> Personally, I find summaries easier to parse compared to finding an
> hour to listen to people talking back and forth about something,
> though it doesn't need to be an either/or proposition :) One of the
> issues brought up in the other thread about video calls is that they
> can be difficult to follow for folks who don't have English as a first
> language. Having a few written notes about what came up during the
Hehe, thanks Julie, I have excatly the same feeling, +1 with you :)

> meeting and some of the conclusions would help with this I think.
>
> Looking forward to seeing how the upgrade work comes along!
>
> Julie
>
>>> - we keep tripleo meeting on IRC every week
>>>
>>> I don't see any blocker to do video-conference between folks that work
>>> together on a same topic.
>>>
 I'll close the poll at 10UTC tomorrow morning (sorry for short notice :(
 ) and schedule the meeting accordingly with a followup mail here,


 thanks, marios


 [1]

 http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-12-13-14.00.log.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



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

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Thierry Carrez]

Doug Hellmann wrote:
> [...]
> 5. Consider driver teams to be a completely different animal, defined
>in drivers.yaml instead of projects.yaml (grey option) [6]
> 
>This establishes drivers as second-order objects that are necessary
>for the success of the main projects, and for which requirements
>can be loosened. It would establish a new category of team without
>the level playing-field requirement and some of the other team
>requirements that seem not to apply to driver teams because they
>are essentially a public facet of a single vendor.

Hi everyone,

Over the last weeks we made progress on the reviews, and discussed the
various options in a couple of TC meetings. At this point a majority of
TC members is leaning toward an amended version of this "grey" proposal:

https://review.openstack.org/403829

Please review and comment on it, so that we can refine it in time for
the meeting next week. Unless a major issue is raised, we'll probably
approve it then and make further adjustments as incremental changes.

Thanks!

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [glance] Propose Steve Lewis for Glance core

[Ian Cordasco]

+2 from me as well

On Dec 14, 2016 3:16 AM, "Erno Kuvaja"  wrote:

> On Tue, Dec 13, 2016 at 10:05 PM, Brian Rosmaita
>  wrote:
> > I'd like to propose Steve Lewis (stevelle on IRC) for Glance core.  Take
> > a look at any of his reviews, and you can see that he's thorough and
> > comprehensive in his reviewing.  He's knowledgeable about Python,
> > Glance, and software engineering in general.  He's gained a lot of
> > experience in various OpenStack projects (including experience as a core
> > reviewer), and will be a great addition to the Glance core reviewers
> team.
> >
> > If you have any concerns, please let me know.  I plan to add Steve to
> > the core list after this week's Glance meeting.
> >
> > thanks,
> > brian
> >
>
>
> Steve has been doing great job: +100!
>
> - jokke
>
> __
> OpenStack Development Mailing 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] [keystone][nova]Quotas: Store resources and limits in the Keystone

[Andrey Volkov]

Hi,

I think one of the issues we're trying to solve here is duplication
reducing. Quotas in OpenStack commonly contain two parts: limits
management and limits enforcement.

If we're talking about library (delimiter) vs service (keystone or quota
service) for a duplication reducing in a limits management then IMO service is
more appropriate way because:

- Now we have API endpoint for limits
  management for the end user and we will need it in the future. Library can
  reduce an amount of code for such endpoint but can't totally eliminate it.
- Besides the code in services, we have api-ref, docs, and clients also
  and library can't reduce an effort for supporting those.
- Centralized limits management service can provide fresh and
  consistent API (see quota_class, quota_sets).

If we're talking about limits enforcement then it's more subtle thing.
I really agree with Jay that problem can be related to the cache for
usages. And I don't see the way how we can skip saving into reservation
table because we can easily define a moment of reservation with
reservation table but it can be hard with "real" objects like instance
as they have its own logic of creating.

I think a library can be appropriate if services like nova or cinder
have a possibility to deeply integrate external libraries (like django
apps). I mean if a library has own DB tables, cli commands, etc. it
can be seamlessly integrated to the main app. I'm not sure it's the
case for nova, for example. Therefore, for me, separate service
is the winner here too.

Sajeesh Cimson Sasi writes:

> Hi,
> There was an ongoing project of delimiter for Cross Project Quota 
> Management.
> But I don't know the current status.
> Kindly have a look at it.
> https://review.openstack.org/#/c/284454/
> More discussions are required on this.As more and more  projects or 
> services are having the concept ofquotas,Quota as a service can also be 
> thought of.Anyway more discussions are required on this topic.
>best regards,
> sajeesh
> 
> From: Jay Pipes [jaypi...@gmail.com]
> Sent: 13 December 2016 18:55:14
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [keystone][nova]Quotas: Store resources and 
> limits in the Keystone
>
> On 12/13/2016 08:09 AM, Kseniya Tychkova wrote:
>> Hi,
>> I would like to share a spec [1] with you.
>> The main idea of this spec is to start a discussion about quota
>> management in the OpenStack.
>>
>> Quotas are scattered across OpenStack services. Each service defines
>> it's own model and API for
>> managing resource's limits. Because of that, there are several problems:
>>
>>   * Names of the resources and resource-service mapping  are hardcoded.
>> They are hardcoded in the service code (Nova, for example) and it
>> should be hardcoded in the client code (Horizon, for example).
>>
>>   * There is no centralized quota management for OpenStack projects.
>>   * Cinder, Nova and Neutron support (or going to support) hierarchical
>> quotas in different ways.
>>
>> There should be a single point of managing quotas in OpenStack.
>> Keystone looks like a proper place to store resource's limits because:
>>
>>   * Keystone stores projects
>>   * Limits are belong to project.
>
> Another excellent reason to store quota limits in Keystone is because
> virtually all non-list operations require some interaction with quota
> limits, and requiring Nova (or Cinder or Neutron) to call out to yet
> another service each time the user makes one of those non-list
> operations is sub-optimal when Nova is already making a call to Keystone
> for authentication.
>
> The alternative is to have a separate REST API service just for storing
> and returning the quota limits and have Nova, Cinder and Neutron call
> this new service each time a non-list operation is made. While this is
> possible, it's just yet another service that needs to be managed and
> deployed by all installations of OpenStack.
>
> Best,
> -jay
>
>> There are a lot of possible issues with “store limits in Keystone”
>> approach. But all of them can be discussed
>> and such discussion should lead to the good solution for quotas
>> management  in Openstack.
>>
>> Please take a look at the spec when you have time and share your ideas
>> or concerns.
>>
>> [1] https://review.openstack.org/#/c/363765/
>>
>>
>> Kind regards,
>> Kseniya
>>
>>
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing 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
> 

Re: [openstack-dev] [TripleO][Upgrade Squad syncup]

[Marios Andreou]

On 14/12/16 11:17, Julie Pichon wrote:
> On 14 December 2016 at 08:56, Dougal Matthews  wrote:
>> On 13 December 2016 at 16:12, Emilien Macchi  wrote:
>>>
>>> On Tue, Dec 13, 2016 at 10:58 AM, Marios Andreou 
>>> wrote:
 Hi OOOs o/ as discussed on this week's upstream weekly irc meeting [1]
 lets schedule a syncup on the Ocata composable upgrades work and how we
 will build on Steve Hardy's base ansible driven implementation.

 IMO a call would be the best format (I propose to schedule a bluejeans
 call, though I am open to any other suggestions). For now I've setup a
 doodle poll at http://doodle.com/poll/rp8ck6tstaagftqr - please vote if
 you'd like to participate. Assuming we go with bluejeans (unless I hear
 strong pushback/other suggestions) then I'll try and make a recording
 available to address the concerns expressed at

 http://lists.openstack.org/pipermail/openstack-dev/2016-December/108780.html
 (thanks shardy for pointing that out).

 Moving forward we should probably switch to an irc based syncup,
>>>
>>> As long as:
>>> - we have zero pushbash from our community members
>>> - anyone can join the call
>>> - our design and discussions stay open (mailing-list, tripleo-specs, IRC)
>>> - a nice summary is sent to openstack-dev
>>
>> or maybe even better, a recording is posted online?
> 
> Personally, I find summaries easier to parse compared to finding an
> hour to listen to people talking back and forth about something,
> though it doesn't need to be an either/or proposition :) One of the
> issues brought up in the other thread about video calls is that they
> can be difficult to follow for folks who don't have English as a first
> language. Having a few written notes about what came up during the
> meeting and some of the conclusions would help with this I think.
> 
> Looking forward to seeing how the upgrade work comes along!
> 
> Julie
> 
>>> - we keep tripleo meeting on IRC every week
>>>
>>> I don't see any blocker to do video-conference between folks that work
>>> together on a same topic.
>>>
 I'll close the poll at 10UTC tomorrow morning (sorry for short notice :(
 ) and schedule the meeting accordingly with a followup mail here,


Looks like Thursday works for everybody. I've created an etherpad which
we can use for the agenda and for notes during the call and with dial-in
info @ https://etherpad.openstack.org/p/tripleo-upgrades-squad. I've
added what imo are some reasonable defaults but please fix as
appropriate - bear in mind we are aiming for a half hour quick call so
may not get to solve all the things!

Thanks for the feedback about the video vs irc - lets see how we get on
having both a recording and the etherpad for this first syncup,

thanks, marios











 thanks, marios


 [1]

 http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-12-13-14.00.log.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
> 


__
OpenStack Development Mailing 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] Golang technical requirements

[Thierry Carrez]

Monty Taylor wrote:
> On 12/13/2016 12:45 PM, Dean Troyer wrote:
>> Release Deliverables
>>
>> OpenStack still officially considers the tarballs generated during the
>> release rpocess to be our official deliverable.  Many downstream
>> consumers, however, bypass those and go directly to the tagged
>> releases in the Git repos.  The Golang community has no real culture
>> of using tarballs at all, given the 'go get' functionality bult in to
>> the tooling directly for checking out remote repos.  One obvious
>> shortcoming in just defining the release to be Git repo tags is our
>> use of generated files.
> 
> Indeed. On the other hand - our use of git tags to drive our
> deliverables (and pbr's use of them instead of content in a file in the
> source repo) actually has us more closely aligned with this than other
> projects might be.

Yes, especially since we automated the tagging process (reducing the
risk of a random tag being accidentally pushed to a repository), git
tags *are* releases in openstack deliverables.

I don't think we need to stop producing and publishing source code
tarballs in the Go case, just because it's not the primary way people
consume the code. Publication of the source code is something we need to
do as part of the open source license we use, and some still consider
tarball publication to be a clearer form of "publication" than keeping a
git server up.

Beyond the source though, one question is whether we should build, sign
and distribute binary artifacts (compiled code), or if tagging a source
repo (and producing a source code tarball) is sufficient. And if we do
distribute binaries, would we only do that for some deliverables (like
the top ones that are supposed to be directly used by users) or for
everything ?

>> If you have an interest in seeing Golang support implemented for
>> OpenStack, please jump in here and help us nail down how to accomplish
>> that "right".

++

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Swapnil Kulkarni]

On Wed, Dec 14, 2016 at 3:33 PM, Thierry Carrez  wrote:
> Ed Leafe wrote:
>> On Dec 12, 2016, at 10:30 PM, Steven Dake (stdake)  wrote:
>>
>>> The issue raised is they violate the 4 opens.
>>
>> Not necessarily. If you have regular planning meetings and discussions in an 
>> open manner as prescribed, an occasional conference to discuss a particular 
>> matter is not a "violation". What if someone in your office is working on 
>> OpenStack too, and you meet in the hallway and discuss something technical? 
>> Does that violate the 4 Opens?
>>
>> I think we have to balance realism with idealism.
>
> Like I said elsewhere, this is not about suppressing any type of visual
> or more direct interaction... It is about making sure you are not
> excluding anyone from a project.
>
> In the precise case we are discussing here, there are complaints from
> contributors to a project that recent Hangouts meetings used in the
> Kolla team results in them being excluded (either technically by not
> being able to join them, or creating additional difficulties for
> non-native language speakers to follow or participate in them).
>
> I'm all for giving teams a bit of flexibility in how they organize, but
> if the process chosen by some of the contributors is clearly excluding
> other contributors, falling back to a more inclusive medium (like IRC
> meetings) is the obvious solution. Jeffrey took the hard step of raising
> the issue, I don't think ignoring his point and pretending Hangout
> meetings are just fine will get you anywhere.
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



I do not believe anyone is willing to exclude contributors at any
stage. If such (mis)understanding is there, it needs to be discussed
why it is there and how to remediate it since it's not good for the
community and is diverting the focus.
Let's have 5-10 mins in today's weekly meeting where we get the facts
together behind the issue and try to bring it to a conclusion.

OR have a detailed discussion on #openstack-kolla

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

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Thierry Carrez]

Ed Leafe wrote:
> On Dec 12, 2016, at 10:30 PM, Steven Dake (stdake)  wrote:
> 
>> The issue raised is they violate the 4 opens.
> 
> Not necessarily. If you have regular planning meetings and discussions in an 
> open manner as prescribed, an occasional conference to discuss a particular 
> matter is not a "violation". What if someone in your office is working on 
> OpenStack too, and you meet in the hallway and discuss something technical? 
> Does that violate the 4 Opens?
> 
> I think we have to balance realism with idealism.

Like I said elsewhere, this is not about suppressing any type of visual
or more direct interaction... It is about making sure you are not
excluding anyone from a project.

In the precise case we are discussing here, there are complaints from
contributors to a project that recent Hangouts meetings used in the
Kolla team results in them being excluded (either technically by not
being able to join them, or creating additional difficulties for
non-native language speakers to follow or participate in them).

I'm all for giving teams a bit of flexibility in how they organize, but
if the process chosen by some of the contributors is clearly excluding
other contributors, falling back to a more inclusive medium (like IRC
meetings) is the obvious solution. Jeffrey took the hard step of raising
the issue, I don't think ignoring his point and pretending Hangout
meetings are just fine will get you anywhere.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [ALU] [vitrage] how to use placeholder vertex

[Weyl, Alexey (Nokia - IL)]

Hi Yujun,

This is a good question, and let me explain for you how it works.
Lets say we are supposed to get 2 entities from nova, nova.host called host1 
and nova.instance called vm1 and vm1 is supposed to be connected to host1.
The nova.host driver and nova.instance driver are working simultaneously and 
thus we don’t know the order in which those events will arrive.
We have 2 use cases:

1.   Host1 event arrives before vm1.

In this case the processor will call the transformer of nova.host and will 
create a vertex for host1 in the graph with the full details of host1.

Then, vm1 event will arrive, the processor will create the vm1 vertex in the 
graph, it will update the host1 properties in the graph (because the host1 
details that are created in nova.instance are only its basic details such as: 
category, type, id, is_deleted, is_placeholder they host1 properties won’t be 
changed in the graph because those details are basic and can’t be changed), and 
then it will create an edge between vm1 and host1 (only the nova.instance knows 
to which nova.host it is connected and not vice versa).

2.   Vm1 event arrives before host1.

In this case the processor will add vm1 to the graph, then it will add the 
host1 placeholder to the graph (so we will know to which host vm1 is connected) 
and then add the edge between them.

Then when the processor will handle with the host1 event, it will just add some 
properties of the host1 vertex, and of course will change the is_placeholder 
property of host1 to false.

We also has the consistency service that runs every 10 minutes (its 
configurable with the snapshot_interval) and checks if there are vertices that 
are is_placeholder=True and are in the graph more then 2*snapshot_interval time 
then it means that such a vertex of host1 for example doesn’t really exists and 
it deletes it from the graph).

In addition, when we understand that we need to delete some entity from the 
graph, upon delete notification for example, then we don’t delete it right 
away, we change the is_deleted property of that entity to True, and we will 
delete it on the next run of the consistency service. The reason we do that, is 
because we need it for the evaluator, because it runs a subgraph matching 
algorithm on the graph, and if the entity that is supposed to be there doesn’t 
appear then it won’t work correctly.

The best way to create a placeholder is to call the placeholder method of the 
correct transformer using the transformers array that each transformer class 
has.

I hope this helps.

Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Wednesday, December 14, 2016 10:55 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] [openstack-dev] [vitrage] how to use placeholder vertex

Hi, root causers (assuming this nickname has been agreed)

It seems the placeholder is created for every neighbor of an entity[1]. I'm not 
sure what will happen if the neighbor entity has been created before.

Will the graph utility handle it? Or we need to check the existence in 
transformer and deal with it?

Similar question for how to create a vertex when there is already a placeholder 
with same ID

[1]: 
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/static_physical/transformer.py#L114
--
Yujun
__
OpenStack Development Mailing 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][Upgrade Squad syncup]

[Julie Pichon]

On 14 December 2016 at 08:56, Dougal Matthews  wrote:
> On 13 December 2016 at 16:12, Emilien Macchi  wrote:
>>
>> On Tue, Dec 13, 2016 at 10:58 AM, Marios Andreou 
>> wrote:
>> > Hi OOOs o/ as discussed on this week's upstream weekly irc meeting [1]
>> > lets schedule a syncup on the Ocata composable upgrades work and how we
>> > will build on Steve Hardy's base ansible driven implementation.
>> >
>> > IMO a call would be the best format (I propose to schedule a bluejeans
>> > call, though I am open to any other suggestions). For now I've setup a
>> > doodle poll at http://doodle.com/poll/rp8ck6tstaagftqr - please vote if
>> > you'd like to participate. Assuming we go with bluejeans (unless I hear
>> > strong pushback/other suggestions) then I'll try and make a recording
>> > available to address the concerns expressed at
>> >
>> > http://lists.openstack.org/pipermail/openstack-dev/2016-December/108780.html
>> > (thanks shardy for pointing that out).
>> >
>> > Moving forward we should probably switch to an irc based syncup,
>>
>> As long as:
>> - we have zero pushbash from our community members
>> - anyone can join the call
>> - our design and discussions stay open (mailing-list, tripleo-specs, IRC)
>> - a nice summary is sent to openstack-dev
>
> or maybe even better, a recording is posted online?

Personally, I find summaries easier to parse compared to finding an
hour to listen to people talking back and forth about something,
though it doesn't need to be an either/or proposition :) One of the
issues brought up in the other thread about video calls is that they
can be difficult to follow for folks who don't have English as a first
language. Having a few written notes about what came up during the
meeting and some of the conclusions would help with this I think.

Looking forward to seeing how the upgrade work comes along!

Julie

>> - we keep tripleo meeting on IRC every week
>>
>> I don't see any blocker to do video-conference between folks that work
>> together on a same topic.
>>
>> > I'll close the poll at 10UTC tomorrow morning (sorry for short notice :(
>> > ) and schedule the meeting accordingly with a followup mail here,
>> >
>> >
>> > thanks, marios
>> >
>> >
>> > [1]
>> >
>> > http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-12-13-14.00.log.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] [glance] Propose Steve Lewis for Glance core

[Erno Kuvaja]

On Tue, Dec 13, 2016 at 10:05 PM, Brian Rosmaita
 wrote:
> I'd like to propose Steve Lewis (stevelle on IRC) for Glance core.  Take
> a look at any of his reviews, and you can see that he's thorough and
> comprehensive in his reviewing.  He's knowledgeable about Python,
> Glance, and software engineering in general.  He's gained a lot of
> experience in various OpenStack projects (including experience as a core
> reviewer), and will be a great addition to the Glance core reviewers team.
>
> If you have any concerns, please let me know.  I plan to add Steve to
> the core list after this week's Glance meeting.
>
> thanks,
> brian
>


Steve has been doing great job: +100!

- jokke

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