[openstack-dev] [Tacker] Ocata design summit topics

[Sripriya Seetharam]

Hi Tackers,

We have the Ocata design summit topics and initial agenda items captured in the 
below etherpad link:

https://etherpad.openstack.org/p/tacker-ocata-summit

The OpenStack design summit schedule page has also been updated to reflect 
these topics in the fishbowl and working sessions.

Feel free to add your inputs/thoughts on the topics. See you all at the summit!

Thanks,
Sripriya
__
OpenStack Development Mailing 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] [osc] bug/design flaw: Clients not cached per region

[Adrian Turjak]

On 18/10/16 15:52, Jamie Lennox wrote:
>
> A comment from the cheap seats, almost all clients are using a
> keystoneauth1 session at this point and that's where your
> authentication information is being cached. There is essentially no
> cost to creating a client with an existing session as auth happens on
> demand.
>
> The region_name is not part of the authentication request, it's used
> to lookup the endpoint and so is passed to Client creation.
>
> Given this maybe there is no longer any value in a ClientCache? It was
> mostly useful to prevent clients doing dumb and share auth amongst
> them. So long as the session/auth is created and saved once, a client
> can be created per use/request with this information (including
> region) with no real performance impact.
>
> Jamie
>
Getting rid of the cache would solve my problem, and considering it's
all one shared session it shouldn't cause any problems.

Updating region_name would still be a problem for interactive mode,
although really that is a problem that is present right now anyway.
__
OpenStack Development Mailing 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] indoor climbing break at summit?

[Joshua Harlow]

Adam Young wrote:

On 10/17/2016 09:53 AM, Chris Dent wrote:


It turns out that summit this year will be just down the road from
Chris Sharma's relatively new indoor climbing gym in Barcelona:

http://www.sharmaclimbingbcn.com/

If the fun, frisson and frustration of summit sessions leaves you with
the energy or need to pull down, maybe we should arrange a visit if we
can find the time. Maybe we can scribble on an etherpad or something.
Most of the pictures are of bouldering but since they rent out
harnesses I guess there must be roped climbing too.

If you're thinking of going apparently they do pre-registration to
speed things up:

http://www.sharmaclimbingbcn.com/en/gym/




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


 I'm in.  What night?



Anyone want to bring a (gym size recommended, unless the walls there are 
*hugg*) rope for leading? I don't want to bring mine all the way 
from CA (unless I have to).


-Josh

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

Re: [openstack-dev] [oslo] Propose support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[Joshua Harlow]

I think doug (he can correct me if I am wrong) was more wondering the 
question of 'why would you want to use random data' in a test vs using 
known fixed data. When a test fails it can be quite hard to identify the 
reason if certain data that the test uses is randomized for each run.


Randomness might be useful, but it has always made me feel like 
something is off when you see to much of it in tests...


-Josh

TommyLike Hu wrote:

Hmm,it's used to generate the ip address for validation or rule
checking, Meanwhile add some randomness. Of course it's unreasonable the
case you mentioned, please check the existed cases [1] and [2]

[1]
https://github.com/openstack/manila/blob/master/manila_tempest_tests/tests/api/base.py#L828
[2]
https://github.com/openstack/manila/blob/master/manila_tempest_tests/tests/api/test_replication.py#L76

Doug Hellmann >于
2016年10月18日周二 上午12:01写道：

Excerpts from TommyLike Hu's message of 2016-10-17 14:46:36 +:
 > It's used in testcase already, and basic codes is from here:
 >

https://github.com/openstack/manila/blob/master/manila_tempest_tests/utils.py#L93

OK, I guess the real question I had is why use *random* addresses.
Because that seems like a way to end up having two tests try to use the
same address at the same time. If that did happen, would it cause
conflicts or race conditions for the manila tests?

 >
 > Doug Hellmann >于2016年10月17日周一 下午10:13写道：
 >
 > > Excerpts from TommyLike Hu's message of 2016-10-17 09:56:15 +:
 > > > When I handle some stuff related to Manila recently, I found
a case which
 > > > may be suitable for Oslo, Anyhow I put it in the maillist so
it can be
 > > > discussed before I put it in action.
 > > > In testcase, we need a function(maybe 2) to generate random
ip address
 > > (or
 > > > network), also they should in the range of [1](ipv4
documentation range)
 > > or
 > > > [2](ipv6 documentation range), this is the draft code for ipv4:
 > > >
 > > > import six
 > > > import random
 > > >
 > > >
 > > > def rand_ipv4(network=False):
 > > > """This uses the TEST-NET-3 range of reserved IP addresses."""
 > > >
 > > > test_net_3 = '203.0.113.'
 > > > if network:
 > > > host_length = random.randint(0, 8)
 > > > address_segment = random.randint(0, 8 - host_length)
 > > > address_segment <<= host_length
 > > > address = test_net_3 + six.text_type(address_segment)
 > > > address = '/'.join((address,
 > > > six.text_type(32 - host_length)))
 > > > else:
 > > > address = test_net_3 +
six.text_type(random.randint(0, 255))
 > > > return address
 > > >
 > > > The primary use case here is writing testcases,  I am not
sure whether it
 > > > is suitable here, or maybe I misunderstood the intention of
TEST-NET-3,
 > > > please leave any comment you like.
 > > >
 > > >
 > > > [1] https://tools.ietf.org/html/rfc5737
 > > > [2] https://tools.ietf.org/html/rfc5156
 > >
 > > In what way are you using random addresses in tests?
 > >
 > > 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 Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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

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


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

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[Takashi Yamamoto]

+1

On Sat, Oct 15, 2016 at 3:30 AM, Miguel Lavalle  wrote:
> Dear Neutrinos,
>
> I am organizing a social event for the team on Thursday 27th at 19:30. After
> doing some Google research, I am proposing Raco de la Vila, which is located
> in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here:
> http://www.racodelavila.com/en/carta-racodelavila.htm
>
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under
> 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get
> a final count.
>
> Here's some reviews:
> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
>
> Cheers
>
> Miguel
>
> __
> OpenStack Development Mailing 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] [osc] bug/design flaw: Clients not cached per region

[Jamie Lennox]

On 18 October 2016 at 12:09, Dean Troyer  wrote:

> On Mon, Oct 17, 2016 at 5:29 PM, Adrian Turjak 
> wrote:
> > What I'm wondering is can the current client cache be changed to be keyed
> > off the client_manager.region_name? That way the change is only in how
> the
> > clients are built and the code elsewhere doesn't change unless it
> actually
> > does something by manually changing region_name. This would then be a
> change
> > that would go unnoticed outside of the clientmanger and simply add a new
> > feature.
> >
> > Actually, I got distracted while writing this email and wrote a patch:
> > https://review.openstack.org/#/c/387696
> >
> > Using the test command in my first email, this works. It should simply
> work
> > with all existing cases, but the test suite should confirm that first of
> > course.
> >
> > With that change anyone can easily work exactly as before (region_name
> will
> > be set to your default region), and new features that are multi-region
> can
> > be introduced without any pain provided they know to update
> > client_manager.region_name.
>
> This is where I have a problem with this approach.  Those are
> descriptors, and make_client() is only called at first reference.  Any
> given command can not assume it will be the first one to initialize
> the client, or not.  Changing region_name like that is not going to
> reset the descriptor, that would now become a manual call.
>
> For the minimialist case of a CLI re-loading for each command issued
> (the common case it seems) this is less of an issue.  But for any
> longer-running invocation, such as interactive mode or a non-cli
> consumer of osc-lib, this quickly gets to be sub-optimal.  Keeping a
> client dict keyed off region name allows you to keep all of those
> clients (instantiated only as needed/used) around as long as you need
> them and not require re-creating them.
>
> There is also an interaction with the requests session cache that I do
> not think will be a problem, but have not yet thought through all the
> way here that we should consider.
>
> > I have been following this a little and it does sound interesting. Am
> > curious what solution is found for this. Can plugins overwrite existing
> > commands? That way if someone wanted a server create with their own
> features
> > they just make a plugin that replaces the standard command. While a bit
> of a
> > blunt solution, it does seem like the simplest, although people need to
> be
> > aware when installing plugins that they can replace/overwrite default
> > commands and be careful to install only trusted plugins.
>
> Currently there is _no_ checking done WRT the command namespaces, any
> plugin can happily stomp on any other command.  The results are
> officially undefined, mostly because the load order via setuptools is
> not deterministic or assured.  My server create plugin works, but we
> can not assure that will always be the case, which is why this is not
> released yet.
>
> The next plugin interface revision will have a notion of registering
> its commands so we can be more deliberate with the call orders and
> also collision checking.  There also needs to be some way to sanity
> check that not just any old thing that you might not be aware of is
> hooking your commands.
>
> 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
>

A comment from the cheap seats, almost all clients are using a
keystoneauth1 session at this point and that's where your authentication
information is being cached. There is essentially no cost to creating a
client with an existing session as auth happens on demand.

The region_name is not part of the authentication request, it's used to
lookup the endpoint and so is passed to Client creation.

Given this maybe there is no longer any value in a ClientCache? It was
mostly useful to prevent clients doing dumb and share auth amongst them. So
long as the session/auth is created and saved once, a client can be created
per use/request with this information (including region) with no real
performance impact.


Jamie
__
OpenStack Development Mailing 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 support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[TommyLike Hu]

Ha,thanks for your link, it's absolutely much clearer and more correct
here, and how do you think of this util function itself?

Kiall Mac Innes 于2016年10月18日周二 上午12:03写道：

> We tend to try stick with the various TEST-NET CIDRs etc as well in
> Designate, and document them here:
>
>
> http://docs.openstack.org/developer/designate/developer-guidelines.html#example-dns-names-and-ip-space
> Thanks,
> Kiall
>
>
> On 17/10/16 10:56, TommyLike Hu wrote:
>
> When I handle some stuff related to Manila recently, I found a case which
> may be suitable for Oslo, Anyhow I put it in the maillist so it can be
> discussed before I put it in action.
> In testcase, we need a function(maybe 2) to generate random ip address (or
> network), also they should in the range of [1](ipv4 documentation range) or
> [2](ipv6 documentation range), this is the draft code for ipv4:
>
> import six
> import random
>
>
> def rand_ipv4(network=False):
> """This uses the TEST-NET-3 range of reserved IP addresses."""
>
> test_net_3 = '203.0.113.'
> if network:
> host_length = random.randint(0, 8)
> address_segment = random.randint(0, 8 - host_length)
> address_segment <<= host_length
> address = test_net_3 + six.text_type(address_segment)
> address = '/'.join((address,
> six.text_type(32 - host_length)))
> else:
> address = test_net_3 + six.text_type(random.randint(0, 255))
> return address
>
> The primary use case here is writing testcases,  I am not sure whether it
> is suitable here, or maybe I misunderstood the intention of TEST-NET-3,
> please leave any comment you like.
>
>
> [1]  https://tools.ietf.org/html/rfc5737
> [2]  https://tools.ietf.org/html/rfc5156
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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 support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[TommyLike Hu]

Hmm,it's used to generate the ip address for validation or rule checking,
Meanwhile add some randomness. Of course it's unreasonable the case you
mentioned, please check the existed cases [1] and [2]

[1]
https://github.com/openstack/manila/blob/master/manila_tempest_tests/tests/api/base.py#L828
[2]
https://github.com/openstack/manila/blob/master/manila_tempest_tests/tests/api/test_replication.py#L76

Doug Hellmann 于2016年10月18日周二 上午12:01写道：

> Excerpts from TommyLike Hu's message of 2016-10-17 14:46:36 +:
> > It's used in testcase already, and basic codes is from here:
> >
> https://github.com/openstack/manila/blob/master/manila_tempest_tests/utils.py#L93
>
> OK, I guess the real question I had is why use *random* addresses.
> Because that seems like a way to end up having two tests try to use the
> same address at the same time. If that did happen, would it cause
> conflicts or race conditions for the manila tests?
>
> >
> > Doug Hellmann 于2016年10月17日周一 下午10:13写道：
> >
> > > Excerpts from TommyLike Hu's message of 2016-10-17 09:56:15 +:
> > > > When I handle some stuff related to Manila recently, I found a case
> which
> > > > may be suitable for Oslo, Anyhow I put it in the maillist so it can
> be
> > > > discussed before I put it in action.
> > > > In testcase, we need a function(maybe 2) to generate random ip
> address
> > > (or
> > > > network), also they should in the range of [1](ipv4 documentation
> range)
> > > or
> > > > [2](ipv6 documentation range), this is the draft code for ipv4:
> > > >
> > > > import six
> > > > import random
> > > >
> > > >
> > > > def rand_ipv4(network=False):
> > > > """This uses the TEST-NET-3 range of reserved IP addresses."""
> > > >
> > > > test_net_3 = '203.0.113.'
> > > > if network:
> > > > host_length = random.randint(0, 8)
> > > > address_segment = random.randint(0, 8 - host_length)
> > > > address_segment <<= host_length
> > > > address = test_net_3 + six.text_type(address_segment)
> > > > address = '/'.join((address,
> > > > six.text_type(32 - host_length)))
> > > > else:
> > > > address = test_net_3 + six.text_type(random.randint(0, 255))
> > > > return address
> > > >
> > > > The primary use case here is writing testcases,  I am not sure
> whether it
> > > > is suitable here, or maybe I misunderstood the intention of
> TEST-NET-3,
> > > > please leave any comment you like.
> > > >
> > > >
> > > > [1]  https://tools.ietf.org/html/rfc5737
> > > > [2]  https://tools.ietf.org/html/rfc5156
> > >
> > > In what way are you using random addresses in tests?
> > >
> > > 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 Development Mailing 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] [osc] bug/design flaw: Clients not cached per region

[Adrian Turjak]

On 18/10/16 15:15, Adrian Turjak wrote:
> Although option would be to leave the cache in osc-lib untouched as a
> pure singleton and just make a new one for openstackclient that does
> support regions.

odd typo. "Although another option would be"


__
OpenStack Development Mailing 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] [osc] bug/design flaw: Clients not cached per region

[Adrian Turjak]

On 18/10/16 14:09, Dean Troyer wrote:
> On Mon, Oct 17, 2016 at 5:29 PM, Adrian Turjak  
> wrote:
>> What I'm wondering is can the current client cache be changed to be keyed
>> off the client_manager.region_name? That way the change is only in how the
>> clients are built and the code elsewhere doesn't change unless it actually
>> does something by manually changing region_name. This would then be a change
>> that would go unnoticed outside of the clientmanger and simply add a new
>> feature.
>>
>> Actually, I got distracted while writing this email and wrote a patch:
>> https://review.openstack.org/#/c/387696
>>
>> Using the test command in my first email, this works. It should simply work
>> with all existing cases, but the test suite should confirm that first of
>> course.
>>
>> With that change anyone can easily work exactly as before (region_name will
>> be set to your default region), and new features that are multi-region can
>> be introduced without any pain provided they know to update
>> client_manager.region_name.
> This is where I have a problem with this approach.  Those are
> descriptors, and make_client() is only called at first reference.  Any
> given command can not assume it will be the first one to initialize
> the client, or not.  Changing region_name like that is not going to
> reset the descriptor, that would now become a manual call.
>
> For the minimialist case of a CLI re-loading for each command issued
> (the common case it seems) this is less of an issue.  But for any
> longer-running invocation, such as interactive mode or a non-cli
> consumer of osc-lib, this quickly gets to be sub-optimal.  Keeping a
> client dict keyed off region name allows you to keep all of those
> clients (instantiated only as needed/used) around as long as you need
> them and not require re-creating them.
>
> There is also an interaction with the requests session cache that I do
> not think will be a problem, but have not yet thought through all the
> way here that we should consider.
I'm not sure why being the first one to initialize the client or not is
a problem in anything other than interactive move. The only worry would
be in interactive mode where if one command altered
client_manger.region_name it does so globally and the next command will
reuse the set region. In all the common cases region_name will first be
set/reset from OS_REGION_NAME or clouds.yaml.

Other things that may confuse people:
client_manager.region_name = "RegionOne"
nova = client_manager.compute # reference to nova in RegionOne
# do stuff ...
client_manager.region_name = "RegionTwo"
# still a reference to nova in RegionOne
nova = client_manager.compute # only now is a reference to nova in RegionTwo


With this suggestion all I'm doing is moving your suggestion
('nova_client = self.app.client_manager.
compute[region]') down to the cache layer and having the cache still act
like a singleton but actually be a mapping of regions to clients. It
fixes my problem and needs no major refactoring elsewhere which is a
plus. Although option would be to leave the cache in osc-lib untouched
as a pure singleton and just make a new one for openstackclient that
does support regions.

For anyone using multi-region commands and the interactive mode, we
would need a different solution, but in part that could wait until there
are officially supported multi-region commands/plugins .

Ultimately I'm not fussed what the solution is, but I do think that not
having support for changing regions in the client manager or per region
clients is a waste. Plugins like ours, or future multi-region features,
will have to explicitly create the per region clients themselves, and
while not hard it does make having a central client manager less useful
or means they are duplicating the make_client functions for existing
clients like nova.

That said, I think the work being done with the OpenStackClient is
fantastic. It has been a massive effort and now especially with plugins
it is wonderful to work with. So don't take this as a complaint, I
genuinely do want to help make it better!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

On Oct 17, 2016, at 6:44 PM, Morgan Fainberg  wrote:
> 
> 
> On Oct 17, 2016 17:32, "Thomas Goirand"  > wrote:
> >
> > On 10/17/2016 08:43 PM, Adam Harwell wrote:
> > > Jim, that is exactly my thought -- the main focus of g-r as far as I was
> > > aware is to maintain interoperability between project dependencies for
> > > openstack deploys, and since our amphora image is totally separate, it
> > > should not be restricted to g-r requirements.
> >
> > The fact that we have a unified version number of a given lib in all of
> > OpenStack is also because that's a requirement of downstream distros.
> >
> > Imagine that someone would like to build the Octavia image using
> > exclusively packages from ...
> >
Right, so, we’re dancing around the common problem in openstack lately: what 
the heck is openstack?

This came up because service VMs/data plane implementations, which this is, 
have different requirements than API services. Paths forward:

1. Add gunicorn to global requirements.

2. Create a project specific “amphora-requirements.txt” file for the service VM 
packages (this is actually my preference.) It has been pointed out that this 
wouldn’t be kept up-to-date by the bot. We could modify the bot to include it 
in some way, or do it manually, or with a project specific job.

3. Split our service VM builds into another repo, to keep a clean separation 
between API services and the backend.  But, even this new repo’s standlone 
requirements.txt file will have the g-r issue from #1.

4. Boot the backend out of OpenStack entirely.

Thanks,
doug


> > > I brought this up, but
> > > others thought it would be prudent to go the g-r route anyway.
> >
> > It is, and IMO you should go this route.
> >
> > Cheers,
> >
> > Thomas Goirand (zigo)
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> > 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > 
> For the record uwsgi was not (at least at one point) allowed in g-r as it was 
> not a "runtime dependency" it was to be installed more like apache mod_wsgi 
> at the time. Gunicorn could fall into the same category, it is meant to be 
> used in conjunction with the runtime but not be a hard requirement for the 
> runtime itself. 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [nova][scheduler] ResourceProvider design issues

[Jay Pipes]

On 10/17/2016 11:14 PM, Ed Leafe wrote:

Now that we’re starting to model some more complex resources, it seems that 
some of the original design decisions may have been mistaken. One approach to 
work around this is to create multiple levels of resource providers. While that 
works, it is unnecessarily complicated IMO. I think we need to revisit some 
basic assumptions about the design before we dig ourselves a big design hole 
that will be difficult to get out of. I’ve tried to summarize my thoughts in a 
blog post. I don’t presume that this is the only possible solution, but I feel 
it is better than the current approach.

https://blog.leafe.com/virtual-bike-sheds/


I commented on your blog, but leave it here for posterity:

First, one of the reasons for the resource providers work was to 
*standardize* as much as possible the classes of resource that a cloud 
provides. Without standardized resource classes, there is no 
interoperability between clouds. The proposed solution of creating 
resource classes for each combination of actual resource class (the 
SRIOV VF) and the collection of traits that the VF might have (physical 
network tag, speed, product and vendor ID, etc) means there would be no 
interoperable way of referring to a VF resource in one OpenStack cloud 
as provided the same thing in another OpenStack cloud. The fact that a 
VF might be tagged to physical network A or physical network B doesn’t 
change the fundamentals: it’s a virtual function on an SR-IOV-enabled 
NIC that a guest consumes. If I don’t have a single resource class that 
represents a virtual function on an SR-IOV-enabled NIC (and instead I 
have dozens of different resource classes that refer to variations of 
VFs based on network tag and other traits) then I cannot have a 
normalized multi-OpenStack cloud environment because there’s no 
standardization.


Secondly, the compute host to SR-IOV PF is only one relationship that 
can be represented by nested resource providers. Other relationships 
that need to be represented include:


* Compute host to NUMA cell relations where a NUMA cell provides both 
VCPU, MEMORY_MB and MEMORY_PAGE_2M and MEMORY_PAGE_1G inventories that 
are separate from each other but accounted for in the parent provider 
(meaning the compute host’s MEMORY_MB inventory is logically the 
aggregate of both NUMA cells’ inventories of MEMORY_MB). In your data 
modeling, how would you represent two NUMA cells, each with their own 
inventories and allocations? Would you create resource classes called 
NUMA_CELL_0_MEMORY_MB and NUMA_CELL_1_MEMORY_MB etc? See point above 
about one of the purposes of the resource providers work being the 
standardization of resource classification.


* NIC bandwidth and NIC bandwidth per physical network. If I have 4 
physical NICs on a compute host and I want to track network bandwidth as 
a consumable resource on each of those NICs, how would I go about doing 
that? Again, would you suggest auto-creating a set of resource classes 
representing the NICs? So, NET_BW_KB_EKB_ENP3S1, NET_BW_KB_ENP4S0, and 
so on? If I wanted to see the total aggregate bandwidth of the compute 
host, the system will now have to have tribal knowledge built into it to 
know that all the NET_BW_KB* resource classes are all describing the 
same exact resource class (network bandwidth in KB) but that the 
resource class names should be interpreted in a certain way. Again, not 
standardizable. In the nested resource providers modeling, we would have 
a parent compute host resource provider and 4 child resource providers — 
one for each of the NICs. Each NIC would have a set of traits 
indicating, for example, the interface name or physical network tag. 
However, the inventory (quantitative) amounts for network bandwidth 
would be a single standardized resource class, say NET_BW_KB. This 
nested resource providers system accurately models the real world setup 
of things that are providing the consumable resource, which is network 
bandwidth.


Finally, I think you are overstating the complexity of the SQL that is 
involved in the placement queries.  I’ve tried to design the DB schema 
with an eye to efficient and relatively simple SQL queries — and keeping 
quantitative and qualitative things decoupled in the schema was a big 
part of that efficiency. I’d like to see specific examples of how you 
would solve the above scenarios by combining the qualitative and 
quantitative aspects into a single resource type but still manage to 
have some interoperable standards that multiple OpenStack clouds can expose.


Best,
-jay

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

[openstack-dev] [Infra] Meeting Tuesday October 18th at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday October 18th, at 19:00 UTC in #openstack-meeting

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

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

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

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-10-11-19.02.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-10-11-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-10-11-19.02.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

Re: [openstack-dev] [ironic] When should a project be under Ironic's governance?

[Dean Troyer]

On Mon, Oct 17, 2016 at 7:02 PM, Jay Faulkner  wrote:
> However, I get the impression some folks attach additional connotations to 
> this; such as the Ironic core team gaining an implied responsibility to the 
> code or it being seen as a “seal of approval” from Ironic. This means that 
> the primary question at hand to be answered is what does it matter, 
> specifically /in the Baremetal project/ to be included in our governance. Is 
> it simply the benefits provided at a high level by OpenStack, or does it 
> imply additional things. This is the question we have to answer to make a 
> decision about what projects should be under Ironic’s governance and what 
> exactly it means.

This sounds a lot like the Neutron Stadium, which has recently been
(mostly?) dismantled, partially because, as I understand, the PTL no
longer felt able to speak for and have sufficient visibility into the
projects within.  There is not an implied responsibility for the PTL
to be 'in charge', it is explicit.  There are also explicit
expectations regarding team membership overlap among the
'sub-projects' that fall under a big tent project.

> Unless there’s more to it than I understand right now, I’d prefer an 
> open-arms approach to projects being in bare metal governance: as long as 
> they’re willing to follow the 4 opens, and are working toward the goals of 
> the Baremetal project, I’d rather have those projects and their contributors 
> as part of our team than not.

Please talk to the Neutron folk about this and their experiences over
the last couple of years.  This is recent enough that it should be
very easy to recall the reasons for going in, as well as coming out of
the stadium.

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] [osc] bug/design flaw: Clients not cached per region

[Dean Troyer]

On Mon, Oct 17, 2016 at 5:29 PM, Adrian Turjak  wrote:
> What I'm wondering is can the current client cache be changed to be keyed
> off the client_manager.region_name? That way the change is only in how the
> clients are built and the code elsewhere doesn't change unless it actually
> does something by manually changing region_name. This would then be a change
> that would go unnoticed outside of the clientmanger and simply add a new
> feature.
>
> Actually, I got distracted while writing this email and wrote a patch:
> https://review.openstack.org/#/c/387696
>
> Using the test command in my first email, this works. It should simply work
> with all existing cases, but the test suite should confirm that first of
> course.
>
> With that change anyone can easily work exactly as before (region_name will
> be set to your default region), and new features that are multi-region can
> be introduced without any pain provided they know to update
> client_manager.region_name.

This is where I have a problem with this approach.  Those are
descriptors, and make_client() is only called at first reference.  Any
given command can not assume it will be the first one to initialize
the client, or not.  Changing region_name like that is not going to
reset the descriptor, that would now become a manual call.

For the minimialist case of a CLI re-loading for each command issued
(the common case it seems) this is less of an issue.  But for any
longer-running invocation, such as interactive mode or a non-cli
consumer of osc-lib, this quickly gets to be sub-optimal.  Keeping a
client dict keyed off region name allows you to keep all of those
clients (instantiated only as needed/used) around as long as you need
them and not require re-creating them.

There is also an interaction with the requests session cache that I do
not think will be a problem, but have not yet thought through all the
way here that we should consider.

> I have been following this a little and it does sound interesting. Am
> curious what solution is found for this. Can plugins overwrite existing
> commands? That way if someone wanted a server create with their own features
> they just make a plugin that replaces the standard command. While a bit of a
> blunt solution, it does seem like the simplest, although people need to be
> aware when installing plugins that they can replace/overwrite default
> commands and be careful to install only trusted plugins.

Currently there is _no_ checking done WRT the command namespaces, any
plugin can happily stomp on any other command.  The results are
officially undefined, mostly because the load order via setuptools is
not deterministic or assured.  My server create plugin works, but we
can not assure that will always be the case, which is why this is not
released yet.

The next plugin interface revision will have a notion of registering
its commands so we can be more deliberate with the call orders and
also collision checking.  There also needs to be some way to sanity
check that not just any old thing that you might not be aware of is
hooking your commands.

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] [requirements][lbaas] gunicorn to g-r

[Morgan Fainberg]

On Oct 17, 2016 17:32, "Thomas Goirand"  wrote:
>
> On 10/17/2016 08:43 PM, Adam Harwell wrote:
> > Jim, that is exactly my thought -- the main focus of g-r as far as I was
> > aware is to maintain interoperability between project dependencies for
> > openstack deploys, and since our amphora image is totally separate, it
> > should not be restricted to g-r requirements.
>
> The fact that we have a unified version number of a given lib in all of
> OpenStack is also because that's a requirement of downstream distros.
>
> Imagine that someone would like to build the Octavia image using
> exclusively packages from ...
>
> > I brought this up, but
> > others thought it would be prudent to go the g-r route anyway.
>
> It is, and IMO you should go this route.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

For the record uwsgi was not (at least at one point) allowed in g-r as it
was not a "runtime dependency" it was to be installed more like apache
mod_wsgi at the time. Gunicorn could fall into the same category, it is
meant to be used in conjunction with the runtime but not be a hard
requirement for the runtime itself.
__
OpenStack Development Mailing 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] Early access: User Survey results & DIY analysis tool

[Heidi Joy Tretheway]

Hello Developers, 
I wanted to alert you that tomorrow we’ll issue a news release on our key 
findings from the eighth User Survey. This cycle, we focused on a 
deployments-only update of the charts most often cited by our community.

On openstack.org/user-survey , you’ll be 
able to download the 12-page PDF “highlights” report (as well as past reports), 
view a 2-minute video overview , and learn more 
about these key findings:
NPS for deployments continues to tick up, 8 points higher than a year ago.
The share of deployments in production is 20% higher than a year ago.
Cost, operational efficiency and innovation are the top three business drivers.
Significantly higher interest in NFV and bare metal, and containers leads the 
list of emerging technologies three cycles in a row.
OpenStack is adopted by companies of every size. Nearly one-quarter of users 
are companies smaller than 100 people.
Want to dig deeper? We’re unveiling a beta version of our User Survey analysis 
tool at www.openstack.org/analytics  that 
enables you to compare 2016 data to prior data, and to apply six global filters 
to evaluate key metrics that matter to you.

We look forward to February, when we’ll ask you to answer the full-length User 
Survey. The report will be available by our Boston Summit, May 8–12, 2017. 
Please feel free to send me any questions or feedback about either the report 
or analysis tool.



Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769  | Skype: heidi.tretheway 

     




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

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Ian Cordasco]

On Oct 17, 2016 7:27 PM, "Thomas Goirand"  wrote:
>
> On 10/17/2016 08:43 PM, Adam Harwell wrote:
> > Jim, that is exactly my thought -- the main focus of g-r as far as I was
> > aware is to maintain interoperability between project dependencies for
> > openstack deploys, and since our amphora image is totally separate, it
> > should not be restricted to g-r requirements.
>
> The fact that we have a unified version number of a given lib in all of
> OpenStack is also because that's a requirement of downstream distros.
>
> Imagine that someone would like to build the Octavia image using
> exclusively packages from ...
>
> > I brought this up, but
> > others thought it would be prudent to go the g-r route anyway.
>
> It is, and IMO you should go this route.

I'm not convinced by your arguments here, Thomas. If the distributor were
packaging Octavia for X but the image is using some other operating system,
say Y, why are X's packages relevant? I would think that if this is
something inside an image going to be launched by Octavia that
co-installibilty wouldn't really be an issue.

I don't lean either way right now, so I'd really like to understand your
point of view, especially since right now it isn't making much sense to me.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[IWAMOTO Toshihiro]

+1

Thanks for organizing.

At Fri, 14 Oct 2016 13:30:57 -0500,
Miguel Lavalle wrote:
> 
> [1  ]
> [1.1  ]
> Dear Neutrinos,
> 
> I am organizing a social event for the team on Thursday 27th at 19:30.
> After doing some Google research, I am proposing Raco de la Vila, which is
> located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is
> here: http://www.racodelavila.com/en/carta-racodelavila.htm
> 
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under
> 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get
> a final count.
> 
> Here's some reviews:
> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
> 
> Cheers

--
IWAMOTO Toshihiro

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

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Thomas Goirand]

On 10/17/2016 08:43 PM, Adam Harwell wrote:
> Jim, that is exactly my thought -- the main focus of g-r as far as I was
> aware is to maintain interoperability between project dependencies for
> openstack deploys, and since our amphora image is totally separate, it
> should not be restricted to g-r requirements.

The fact that we have a unified version number of a given lib in all of
OpenStack is also because that's a requirement of downstream distros.

Imagine that someone would like to build the Octavia image using
exclusively packages from ...

> I brought this up, but
> others thought it would be prudent to go the g-r route anyway.

It is, and IMO you should go this route.

Cheers,

Thomas Goirand (zigo)


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

Re: [openstack-dev] PTG from the Ops Perspective - a few short notes

[Morgan Fainberg]

On Oct 17, 2016 12:15, "Clint Byrum"  wrote:
>
> Excerpts from Chris Dent's message of 2016-10-17 10:38:25 +0100:
> > On Mon, 17 Oct 2016, Renat Akhmerov wrote:
> >
> > > If you are a developer, of course, PTG is an important event to
> > > attend. But… Being a developer, I would also love to attend summits
> > > also. For a bunch of reasons like catching up with the activities
> > > wider than my current focus of development, participating in getting
> > > user feedback and help clarifying possible misunderstanding of
> > > technical things being discussed which makes feedback gathering
> > > process more valuable (I believe that often users don’t know what
> > > they want, at least, in details, we need to help them understand by
> > > sharing our experience) etc. Also, for purely psychological reason I
> > > think it’s very important for people who mostly focus on very
> > > specific tasks to sometimes go and see events like an OpenStack
> > > summit. From my experience, people often change their attitude to
> > > their work when they see how many people are interested in what they
> > > are working on in labs. And it’s almost impossible to find a better
> > > way of getting that feeling of participating in something tremendous
> > > than attending summits.
> >
> > This. A thousand times this.
> >
> > Summit is one of the few ways that I get to see the big picture and
> > that there are actual real people doing real things with OpenStack.
> >
>
> Agree with all of these things. However, a lot of us felt that the
> pressure to do both at the same time was compromising both to the point
> that the sum of these two things was not even equal to the parts.
>
> Perhaps more dev focused people will find themselves going to 2 PTG's,
> and just one summit, the one closer to them geographically, every year.
>
> __
> OpenStack Development Mailing 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 have very mixed feeling about the PTG. The more I spend thinking of it
the less I am a fan of the distinction between the summit and the PTG as it
stands. If the summit became a yearly thing and the PTG twice yearly I
think much of the concerns would subside. Seeing as that is not the case, I
see the PTG to bee currently poorly communicated.

Given the choice as a developer between summit and PTG I would pick summit.
I hope "OpenStack: the gathering" solves the split midcycles. But frankly I
am at this point in agreement that the lack of direct OPS feedback and
worry about lacking the larger picture is a serious detractor for what has
been proposed for the PTG.

It comes down to needing to now keep a solid presence for both for the
cores and PTLs, which is contrary to the original proposal. I hope I am
wrong in this assessment.
__
OpenStack Development Mailing 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] Neutron team social event in Barcelona

[Russell Bryant]

On Friday, October 14, 2016, Miguel Lavalle  wrote:

> Dear Neutrinos,
>
> I am organizing a social event for the team on Thursday 27th at 19:30.
> After doing some Google research, I am proposing Raco de la Vila, which is
> located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu
> is here: http://www.racodelavila.com/en/carta-racodelavila.htm
>
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
> under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we
> can get a final count.
>
> Here's some reviews: https://www.tripadvisor.com/
> Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_
> Vila-Barcelona_Catalonia.html
>

+1


-- 
Russell Bryant
__
OpenStack Development Mailing 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] [ironic] When should a project be under Ironic's governance?

[Jay Faulkner]

> On Oct 17, 2016, at 1:27 PM, Michael Turek  wrote:
> 
> Hello ironic!
> 
> At today's IRC meeting, the questions "what should and should not be a 
> project be under Ironic's governance" and "what does it mean to be under 
> Ironic's governance" were raised. Log here:
> 
> http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-10-17-17.00.log.html#l-176
> 
> See http://governance.openstack.org/reference/projects/ironic.html for a list 
> of projects currently under Ironic's governance.
> 
> Is it as simple as "any project that aides in openstack baremetal deployment 
> should be under Ironic's governance"? This is probably too general (nova 
> arguably fits here) but it might be a good starting point.
> 
> Another angle to look at might be that a project belongs under the Ironic 
> governance when both Ironic (the main services) and the candidate subproject 
> would benefit from being under the same governance. A hypothetical example of 
> this is when Ironic and the candidate project need to release together.
> 
> Just some initial thoughts to get the ball rolling. What does everyone else 
> think?
> 

I think there were a lot of people in the meeting who were confused by what 
being under governance means. As I understand it, in the strictest sense, it 
means:
- Project contributors can vote for TC/PTL
- Project has access to cross-project resources
- Access to summit/PTG time (at PTL’s discretion)

However, I get the impression some folks attach additional connotations to 
this; such as the Ironic core team gaining an implied responsibility to the 
code or it being seen as a “seal of approval” from Ironic. This means that the 
primary question at hand to be answered is what does it matter, specifically 
/in the Baremetal project/ to be included in our governance. Is it simply the 
benefits provided at a high level by OpenStack, or does it imply additional 
things. This is the question we have to answer to make a decision about what 
projects should be under Ironic’s governance and what exactly it means.

Unless there’s more to it than I understand right now, I’d prefer an open-arms 
approach to projects being in bare metal governance: as long as they’re willing 
to follow the 4 opens, and are working toward the goals of the Baremetal 
project, I’d rather have those projects and their contributors as part of our 
team than not. 

Thanks,
Jay Faulkner


> Thanks,
> Mike Turek
> 
> 
> __
> OpenStack Development Mailing 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] next upgrades meeting is Nov 7th

[Edgar Magana]

Unfortunately, it is unavoidable!
One of the greatest countries with the worse candidates!

Edgar

From: "Armando M." 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, October 17, 2016 at 3:32 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [neutron] next upgrades meeting is Nov 7th



On 17 October 2016 at 12:29, Ihar Hrachyshka 
> wrote:
Hi all,

due to the summit we cancel the next two upgrades subteam meetings.

We will get back Nov 7th, just in time to close any remaining gaps before the 
world as we know it is destroyed by US elections the next day.

Don't even joke about this, it's not funny :)


See you there,
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

Re: [openstack-dev] [neutron] next upgrades meeting is Nov 7th

[Armando M.]

On 17 October 2016 at 12:29, Ihar Hrachyshka  wrote:

> Hi all,
>
> due to the summit we cancel the next two upgrades subteam meetings.
>
> We will get back Nov 7th, just in time to close any remaining gaps before
> the world as we know it is destroyed by US elections the next day.
>

Don't even joke about this, it's not funny :)


>
> See you there,
> 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

Re: [openstack-dev] [osc] bug/design flaw: Clients not cached per region

[Adrian Turjak]

On 18/10/16 03:36, Dean Troyer wrote:
> On Sun, Oct 16, 2016 at 9:11 PM, Adrian Turjak
> > wrote:
>
> The problem I'm running into is for some of our custom plugins we
> require the commands to run in all regions. We do this by getting the
> region list from keystone, and then doing the command in each region.
>
> ... 
>
> Is there a way to explicitly reinitialise the client_manager?
> 'client_mananger.reinitialise()' or something as easy? Maybe even a
> clear cache command?
>
>
> There is not a way to re-init the ClientManager, and really, you don't
> want to do that, but you do want a new compute client for each
> region.  OSC sets up the ClientManager client attributes with
> descriptors in common/clientmanager.py get_plugin_modules().  At this
> point we do not have any region information, so to do that you would
> have to do it later, but it is simple enough to return whatever you
> want from your plugin's make_client().  Normally that will be a client
> object for the desired API, for your plugin it could be a dict of
> client objects keyed off region_name.  Then your consuming code would
> need to deref those with:
>
>   for region in regions:
>   nova_client = self.app.client_manager.compute[region]
>   do_something(nova_client)
>  
>  
>
> While explicitly initialising clients isn't exactly difficult, it is
> something that would make more sense to simply work in the base
> openstackclient code as multi-region commands can and will be
> useful for
> a lot of people.
>
>
> Generalizing this to all of the existing plugins would be an enormous
> change, but doable.  We would need to think hard about how many of
> these things we need to handle, not just region, but cell or whatever
> else may be out there that a command would want to iterate on.
I don't think it is worth doing such a change exactly because it would
be a huge amount of work. Thats why I was hoping to have the value
returned be partly keyed off 'client_manager.region_name'. The clients
do get built off that value already, and I've tested altering that value
before the first client is built and even if my authed region was
RegionOne, if I manually set it to RegionTwo, the client will be built
for region two. The problem is that once cached, the client will always
be RegionTwo.

What I'm wondering is can the current client cache be changed to be
keyed off the client_manager.region_name? That way the change is only in
how the clients are built and the code elsewhere doesn't change unless
it actually does something by manually changing region_name. This would
then be a change that would go unnoticed outside of the clientmanger and
simply add a new feature.

Actually, I got distracted while writing this email and wrote a patch:
https://review.openstack.org/#/c/387696

Using the test command in my first email, this works. It should simply
work with all existing cases, but the test suite should confirm that
first of course.

With that change anyone can easily work exactly as before (region_name
will be set to your default region), and new features that are
multi-region can be introduced without any pain provided they know to
update client_manager.region_name.


> Note that we currently can not reliably hook existing commands to
> extend them, for example to support a 'server create' that uses --ram,
> --vcpu and --disk in place of --flavor.  That will be discussed next
> week in BCN.
I have been following this a little and it does sound interesting. Am
curious what solution is found for this. Can plugins overwrite existing
commands? That way if someone wanted a server create with their own
features they just make a plugin that replaces the standard command.
While a bit of a blunt solution, it does seem like the simplest,
although people need to be aware when installing plugins that they can
replace/overwrite default commands and be careful to install only
trusted plugins.

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

[openstack-dev] [ironic] PTG attendance

[Jim Rollenhagen]

Hey folks,

Thought I sent this to the list, but apparently not, maybe just the organizers.

The ironic team *does* plan to be at the PTG in February. Hope to see
everyone there. :)

// jim

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

[openstack-dev] [ironic] Core team updates

[Jim Rollenhagen]

Hey friends,

The ironic-core team has done some great things over the last year.
We've landed a ton of code, grown some new members (and continually
growing more), and generally stayed pretty well connected.

However, some folks are clearly reviewing far more than others. While
I realize that folks may have commitments outside of ironic, I'd like to ask
everyone to be mindful of their review quantity (and always quality, of
course). :)

Reviews for the ironic umbrella in the last 90 days:
http://stackalytics.com/report/contribution/ironic-group/90

A good rule of thumb to try to meet is 3 reviews/day, which our top 8
reviewers are meeting (admittedly I am not).

There's also a couple people that haven't been active in the project
for quite a while that I'm dropping today:

Chris Krelle (NobodyCam)
Haomeng Wang (haomeng)

Of course, we welcome both of you back quickly if your activity picks
back up. :)

// jim

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

Re: [openstack-dev] [openstack][nova] Port unbound from active VM

[Ajay Kalambur (akalambu)]

Hi
I logged the following bug
https://bugs.launchpad.net/nova/+bug/1634269

I sent out review below please let me know if I am on right track

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

Ajay




From: Kevin Benton >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, October 14, 2016 at 1:23 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [openstack][nova] Port unbound from active VM

I suggest filing a bug against nova for this.

On Thu, Oct 13, 2016 at 9:44 AM, Ajay Kalambur (akalambu) 
> wrote:
Any comments/input on this?
Ajay


From: Ajay Kalambur >
Date: Monday, October 10, 2016 at 6:31 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack][nova] Port unbound from active VM

Hi
There seems to be a corner case bug in nova code. Steps to reproduce it are

  1.  Create a neutron port
  2.  Create a VM and launch instance with this port
  3.  Shutdown nova compute and network agent on compute node
  4.  Unbind port from VM and delete the VM (offline delete)
  5.  Now create a VM with same port but on a different compute node
  6.  Bring up nova compute on old node

It basically runs the reap for deleted instances and cleanes up VM from 
libvirt. In the process it unbinds the pre-existing ports and ends up unbinding 
the port from an active VM on a different compute node
Reason nova simply sends a blind port-update with binding_host: “” even if that 
port is bound to a different instance


So following fix seemed to help any suggestions on a better fix

In nova/network/neutronv2/api.py. So basically when neutron sees no ports for 
this instance don’t attempt an unbind
In this case
data = neutron.list_ports(**search_opts)
Call in deallocate_for_instance returns empty ports




  # Reset device_id and device_owner for the ports that are skipped

if data.get('ports', []):

self._unbind_ports(context, ports_to_skip, neutron)

else:

LOG.debug("Neutron sees a different view of this port hence 
skipping unbind”)



Ajay


__
OpenStack Development Mailing 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] [nova][scheduler] ResourceProvider design issues

[Ed Leafe]

Now that we’re starting to model some more complex resources, it seems that 
some of the original design decisions may have been mistaken. One approach to 
work around this is to create multiple levels of resource providers. While that 
works, it is unnecessarily complicated IMO. I think we need to revisit some 
basic assumptions about the design before we dig ourselves a big design hole 
that will be difficult to get out of. I’ve tried to summarize my thoughts in a 
blog post. I don’t presume that this is the only possible solution, but I feel 
it is better than the current approach.

https://blog.leafe.com/virtual-bike-sheds/


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

[openstack-dev] [tripleo][ironic] introspection and CI

[Wesley Hayutin]

Greetings,

The RDO CI team is considering adding retries to our calls to introspection
again [1].
This is very handy for bare metal environments where retries may be needed
due to random chaos in the environment itself.

We're trying to balance two things here..
1. reduce the number of false negatives in CI
2. try not to overstep what CI should vs. what the product should do.

We would like to hear your comments if you think this is acceptable for CI
or if this may be overstepping.

Thank you


[1] http://paste.openstack.org/show/586035/
__
OpenStack Development Mailing 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] indoor climbing break at summit?

[Adam Young]

On 10/17/2016 09:53 AM, Chris Dent wrote:


It turns out that summit this year will be just down the road from
Chris Sharma's relatively new indoor climbing gym in Barcelona:

http://www.sharmaclimbingbcn.com/

If the fun, frisson and frustration of summit sessions leaves you with
the energy or need to pull down, maybe we should arrange a visit if we
can find the time. Maybe we can scribble on an etherpad or something.
Most of the pictures are of bouldering but since they rent out
harnesses I guess there must be roped climbing too.

If you're thinking of going apparently they do pre-registration to
speed things up:

http://www.sharmaclimbingbcn.com/en/gym/




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


I'm in.  What night?

__
OpenStack Development Mailing 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] Scaling-up the team with Squads

[Emilien Macchi]

So we had a lot of interesting feedback in the spec, I addressed all
comments, let me know if I missed something.
I'm also interested to have feedback from other team members.

Thanks,

On Tue, Oct 11, 2016 at 7:46 PM, Emilien Macchi  wrote:
> It has been some weeks I have been thinking how TripleO project could
> scale-up the way we work together.
> Over the cycles, we have more contributors, more projects, I think
> it's time to revisit our organization.
>
> Here's the proposal: https://review.openstack.org/385201
>
> Feel free to review it prior the Summit, so we can have a productive
> "Growing the team" session in Barcelona.
>
> Thanks,
> --
> 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

[openstack-dev] [ironic] When should a project be under Ironic's governance?

[Michael Turek]

Hello ironic!

At today's IRC meeting, the questions "what should and should not be a 
project be under Ironic's governance" and "what does it mean to be under 
Ironic's governance" were raised. Log here:


http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-10-17-17.00.log.html#l-176

See http://governance.openstack.org/reference/projects/ironic.html for a 
list of projects currently under Ironic's governance.


Is it as simple as "any project that aides in openstack baremetal 
deployment should be under Ironic's governance"? This is probably too 
general (nova arguably fits here) but it might be a good starting point.


Another angle to look at might be that a project belongs under the 
Ironic governance when both Ironic (the main services) and the candidate 
subproject would benefit from being under the same governance. A 
hypothetical example of this is when Ironic and the candidate project 
need to release together.


Just some initial thoughts to get the ball rolling. What does everyone 
else think?


Thanks,
Mike Turek


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

[openstack-dev] [neutron] next upgrades meeting is Nov 7th

[Ihar Hrachyshka]

Hi all,

due to the summit we cancel the next two upgrades subteam meetings.

We will get back Nov 7th, just in time to close any remaining gaps before  
the world as we know it is destroyed by US elections the next day.


See you there,
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-dev] [Neutron] Next neutron-lib meeting is November 9

[Henry Gessau]

Due to the summit.

__
OpenStack Development Mailing 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] PTG from the Ops Perspective - a few short notes

[Clint Byrum]

Excerpts from Chris Dent's message of 2016-10-17 10:38:25 +0100:
> On Mon, 17 Oct 2016, Renat Akhmerov wrote:
> 
> > If you are a developer, of course, PTG is an important event to
> > attend. But… Being a developer, I would also love to attend summits
> > also. For a bunch of reasons like catching up with the activities
> > wider than my current focus of development, participating in getting
> > user feedback and help clarifying possible misunderstanding of
> > technical things being discussed which makes feedback gathering
> > process more valuable (I believe that often users don’t know what
> > they want, at least, in details, we need to help them understand by
> > sharing our experience) etc. Also, for purely psychological reason I
> > think it’s very important for people who mostly focus on very
> > specific tasks to sometimes go and see events like an OpenStack
> > summit. From my experience, people often change their attitude to
> > their work when they see how many people are interested in what they
> > are working on in labs. And it’s almost impossible to find a better
> > way of getting that feeling of participating in something tremendous
> > than attending summits.
> 
> This. A thousand times this.
> 
> Summit is one of the few ways that I get to see the big picture and
> that there are actual real people doing real things with OpenStack.
> 

Agree with all of these things. However, a lot of us felt that the
pressure to do both at the same time was compromising both to the point
that the sum of these two things was not even equal to the parts.

Perhaps more dev focused people will find themselves going to 2 PTG's,
and just one summit, the one closer to them geographically, every year.

__
OpenStack Development Mailing 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] [ironic] weekly subteam report

[Rajini.Ram]

Dell - Internal Use - Confidential
There is a related patch to the neutron subnet pool fix,
This allows you to use FIXED_RANGE without using subnet pool
https://review.openstack.org/#/c/378063/


-Original Message-
From: Loo, Ruby [mailto:ruby@intel.com]
Sent: Monday, October 17, 2016 1:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [ironic] weekly subteam report

Hi,

Here is this week's subteam report for Ironic. As usual, this is pulled 
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff between 10 Oct 2016 and 17 Oct 2016)
- Ironic: 224 (+8) bugs + 209 wishlist items (-3). 23 new (+8), 171 in progress 
(-2), 1 critical, 30 high and 20 incomplete (+1)
- Inspector: 10 bugs (-1) + 19 wishlist items. 1 new, 9 in progress (-1), 0 
critical, 1 high and 1 incomplete
- Nova bugs with Ironic tag: 11 (+1). 1 new (+1), 0 critical, 1 high
- the critical bug is the neutron pool issue (has workaround in place right 
now):
- https://bugs.launchpad.net/ironic-python-agent/+bug/1629133
- seems like they've merged a fix, we should try removing the work around:
- https://review.openstack.org/#/c/381965/

Gate improvements (jlvillal, lucasagomes, dtantsur) 
===
* trello: 
https://trello.com/c/HWVHhxOj/1-multi-tenant-networking-network-isolation
- ironic-lib was successfully moved to xenial, and finally has some good 
coverage
- I've proposed a plan on our CI jobs refactoring: 
http://lists.openstack.org/pipermail/openstack-dev/2016-October/105558.html

Generic boot-from-volume (TheJulia, dtantsur, lucasagomes) 
==
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- Specification in need of reviews: https://review.openstack.org/#/c/294995/

Driver composition (dtantsur)
=
* trello: https://trello.com/c/fTya14y6/14-driver-composition
- dtantsur has reviewed the spec update. lgtm, but needs clarification a bit.

Notifications (mariojv)
===
* trello: https://trello.com/c/MD8HNcwJ/17-notifications
- Power state change notifications currently merging: 
https://review.openstack.org/#/c/321865/
- Spec for CRUD notifications, provision state change notifications, and 
maintenance notifications landed: https://review.openstack.org/#/c/347242/
- Code still needing review
- https://review.openstack.org/#/c/348437/
- https://review.openstack.org/#/c/356541/ (currently workflow -1)

Serial console (yossy, hshiina, yuikotakadamori) 

* trello: https://trello.com/c/nm3I8djr/20-serial-console
- nova patch merged last Friday: https://review.openstack.org/#/c/328157/
- DONE \o/

Enhanced root device hints (lucasagomes) 

* trello: https://trello.com/c/f9DTEvDB/21-enhanced-root-device-hints
- The code is merged in all involved projects: Ironic, IPA and ironic-lib
- Missing documentation: https://review.openstack.org/#/c/386714/

Inspector (dtansur)
===
* trello: https://trello.com/c/PwH1pexJ/23-rescue-mode
- no updates, hacking on :) ++ lol

Bifrost (TheJulia)
==
- Keystone support and support for enabling inspector to enroll discovered 
hardware currently in review.

.

Until the week after the summit,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing 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] Team meeting this Monday at 2100 UTC + forthcoming schedule

[Armando M.]

On 17 October 2016 at 11:45, Dariusz Śmigiel 
wrote:

> It means that next Team Meeting will have a place on November 8, Tuesday.
>
> Any cancellations for other Neutron Meetings?
>

I think those should be advertised in emails with their respective subjects.


>
> 2016-10-17 13:28 GMT-05:00 Armando M. :
> > Hi neutrinos,
> >
> > A kind reminder for this week's meeting. More on the agenda [1]. Also,
> due
> > to the summit, the next occurrences will be cancelled.
> >
> > - Oct 25, Tuesday
> > - Oct 31, Monday
> >
> > Cheers,
> > Armando
> >
> > [1] https://wiki.openstack.org/wiki/Network/Meetings
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Darek "dasm" Śmigiel
>
> 
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova]Question about unit tests for shelve/unshleve

[Andrew Laski]

On Sun, Oct 16, 2016, at 07:11 AM, Rikimaru Honjo wrote:
> Hi all,
> 
> I have a question about unit tests of nova.
> (I found this question when I fixed a bug about shelve.[1])
> 
> "nova.tests.unit.compute.test_shelve.ShelveComputeAPITestCase" has
> test cases for "nova.compute.api.API.shelve()/unshelve()".
> But "nova.tests.unit.compute.test_compute_api._ComputeAPIUnitTestMixIn"
> also has test cases for same methods.
> 
> Is their purpose duplicated?
> And, can I organize them if their purpose is duplicated?

I just looked at them briefly and they're not exactly duplicates. It
appears that test_shelve.py has more functional tests and
test_compute_api.py is more unit tests. But it would be nice to have
them all in the same place.

> 
> FYI, I think that we should consolidate them into
> "nova.tests.unit.compute.test_compute_api._ComputeAPIUnitTestMixIn".
> Because it is inherited to some test classes.
> 

Personally I would prefer consolidating them into test_shelve.py because
_ComputeAPIUnitTestMixin is a giant class and it can be hard to discover
where something is tested. I like having the features tested in a
dedicated test file.

> 
> [1]: https://bugs.launchpad.net/nova/+bug/1588657
> 
> Best regards,
> -- 
> Rikimaru Honjo
> E-mail:honjo.rikim...@po.ntts.co.jp
> 
> 
> __
> OpenStack Development Mailing 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] Team meeting this Monday at 2100 UTC + forthcoming schedule

[Dariusz Śmigiel]

It means that next Team Meeting will have a place on November 8, Tuesday.

Any cancellations for other Neutron Meetings?

2016-10-17 13:28 GMT-05:00 Armando M. :
> Hi neutrinos,
>
> A kind reminder for this week's meeting. More on the agenda [1]. Also, due
> to the summit, the next occurrences will be cancelled.
>
> - Oct 25, Tuesday
> - Oct 31, Monday
>
> Cheers,
> Armando
>
> [1] https://wiki.openstack.org/wiki/Network/Meetings
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Darek "dasm" Śmigiel


Q: Why is this email five sentences or less?
A: http://five.sentenc.es

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

[openstack-dev] [Ironic] OpenStack Summit Barcelona: Ironic Meetup (evening)

[Lucas Alvares Gomes]

Hi everyone,

We are planning to have an evening Ironic contributors meetup at some
point in the Barcelona Summit and we need to decide which day of that
week would be most suited for all/most of us. So, if you are willing
to attend please put your name and possible days at
http://doodle.com/poll/56qkr5rsxu447acr

As a note, depending on the number of people willing to attend it may
be hard to find a venue to host everyone, so we can't guarantee that
the event is really going to happen. We will try!!!

Cheers,
Lucas

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

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

Jim, that is exactly my thought -- the main focus of g-r as far as I was
aware is to maintain interoperability between project dependencies for
openstack deploys, and since our amphora image is totally separate, it
should not be restricted to g-r requirements. I brought this up, but others
thought it would be prudent to go the g-r route anyway. So, I don't really
care what g-r says in this case, but I am aware my personality tends a bit
towards anarchistic, so I ceded the argument in an attempt to play nice. :)
If others also agree that g-r should not apply in cases like these, we can
re-evaluate our choice to add gunicorn to our main requirements file, and
install it via alternate mechanisms.

--Adam

On Tue, Oct 18, 2016 at 3:16 AM Doug Wiegley 
wrote:

> On Oct 17, 2016, at 12:02 PM, Jim Rollenhagen 
> wrote:
> >
> > On Mon, Oct 17, 2016 at 1:33 PM, Doug Wiegley
> >  wrote:
> >> Hi,
> >>
> >> On a review to add gunicorn to global requirements[1], we were asked to
> send a notice to the ML. In this particular application, it’s for use
> inside a service VM for Octavia. Objections/comments/other?
> >
> > global-requirements is meant to ensure co-installability between
> > OpenStack services.
> > Is it safe to assume that software running in service VMs does not need
> to be
> > co-installable with other OpenStack services, since it's separated
> > from the control
> > plane?
> >
>
> In this particular case, yes, that’s not a concern, but if added to g-r,
> it might proliferate elsewhere over time.
>
> Thanks,
> doug
>
> > // jim
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing 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] Neutron team social event in Barcelona

[Ben Pfaff]

On Fri, Oct 14, 2016 at 01:30:57PM -0500, Miguel Lavalle wrote:
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under
> 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get
> a final count.

I'm planning to attend.

__
OpenStack Development Mailing 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] Neutron team social event in Barcelona

[Adam Harwell]

+1

On Tue, Oct 18, 2016 at 3:05 AM Michael Johnson  wrote:

> +1
>
> On Fri, Oct 14, 2016 at 11:30 AM, Miguel Lavalle 
> wrote:
> > Dear Neutrinos,
> >
> > I am organizing a social event for the team on Thursday 27th at 19:30.
> After
> > doing some Google research, I am proposing Raco de la Vila, which is
> located
> > in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here:
> > http://www.racodelavila.com/en/carta-racodelavila.htm
> >
> > It is easy to get there by subway from the Summit venue:
> > https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
> under
> > 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can
> get
> > a final count.
> >
> > Here's some reviews:
> >
> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
> >
> > Cheers
> >
> > Miguel
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] weekly subteam report

[Loo, Ruby]

Hi,

Here is this week's subteam report for Ironic. As usual, this is pulled 
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff between 10 Oct 2016 and 17 Oct 2016)
- Ironic: 224 (+8) bugs + 209 wishlist items (-3). 23 new (+8), 171 in progress 
(-2), 1 critical, 30 high and 20 incomplete (+1)
- Inspector: 10 bugs (-1) + 19 wishlist items. 1 new, 9 in progress (-1), 0 
critical, 1 high and 1 incomplete
- Nova bugs with Ironic tag: 11 (+1). 1 new (+1), 0 critical, 1 high
- the critical bug is the neutron pool issue (has workaround in place right 
now):
- https://bugs.launchpad.net/ironic-python-agent/+bug/1629133
- seems like they've merged a fix, we should try removing the work around:
- https://review.openstack.org/#/c/381965/

Gate improvements (jlvillal, lucasagomes, dtantsur)
===
* trello: 
https://trello.com/c/HWVHhxOj/1-multi-tenant-networking-network-isolation
- ironic-lib was successfully moved to xenial, and finally has some good 
coverage
- I've proposed a plan on our CI jobs refactoring: 
http://lists.openstack.org/pipermail/openstack-dev/2016-October/105558.html

Generic boot-from-volume (TheJulia, dtantsur, lucasagomes)
==
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- Specification in need of reviews: https://review.openstack.org/#/c/294995/

Driver composition (dtantsur)
=
* trello: https://trello.com/c/fTya14y6/14-driver-composition
- dtantsur has reviewed the spec update. lgtm, but needs clarification a bit.

Notifications (mariojv)
===
* trello: https://trello.com/c/MD8HNcwJ/17-notifications
- Power state change notifications currently merging: 
https://review.openstack.org/#/c/321865/
- Spec for CRUD notifications, provision state change notifications, and 
maintenance notifications landed: https://review.openstack.org/#/c/347242/
- Code still needing review
- https://review.openstack.org/#/c/348437/
- https://review.openstack.org/#/c/356541/ (currently workflow -1)

Serial console (yossy, hshiina, yuikotakadamori)

* trello: https://trello.com/c/nm3I8djr/20-serial-console
- nova patch merged last Friday: https://review.openstack.org/#/c/328157/
- DONE \o/

Enhanced root device hints (lucasagomes)

* trello: https://trello.com/c/f9DTEvDB/21-enhanced-root-device-hints
- The code is merged in all involved projects: Ironic, IPA and ironic-lib
- Missing documentation: https://review.openstack.org/#/c/386714/

Inspector (dtansur)
===
* trello: https://trello.com/c/PwH1pexJ/23-rescue-mode
- no updates, hacking on :) ++ lol

Bifrost (TheJulia)
==
- Keystone support and support for enabling inspector to enroll discovered 
hardware currently in review.

.

Until the week after the summit,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard

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

[openstack-dev] [Neutron] Team meeting this Monday at 2100 UTC + forthcoming schedule

[Armando M.]

Hi neutrinos,

A kind reminder for this week's meeting. More on the agenda [1]. Also, due
to the summit, the next occurrences will be cancelled.

- Oct 25, Tuesday
- Oct 31, Monday

Cheers,
Armando

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

[openstack-dev] [kolla] Last bug before tagging 3.0.0

[Steven Dake (stdake)]

Folks,

We are in dire need of any help core reviewers can provide fixing the following 
bug:
https://etherpad.openstack.org/p/kolla-bug-1631503

For everyone that submits a patch, please take responsibility to back port it 
to stable/newton.  This is a one click operation.  Make sure not to back port 
until after the master patch has gone through review.  If you don’t know how 
reach out to me on irc.

We are in need of upgrade testing after this patch set merges.

This is the last patch set needed to tag 3.0.0.  Our deadline is Tuesday 
October 18th, 2016 23:45 UTC.

Everything else with stable/newton looking really good!  Please help us finish 
the job on 3.0.0.

Regards
-steve

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

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

On Oct 17, 2016, at 12:02 PM, Jim Rollenhagen  wrote:
> 
> On Mon, Oct 17, 2016 at 1:33 PM, Doug Wiegley
>  wrote:
>> Hi,
>> 
>> On a review to add gunicorn to global requirements[1], we were asked to send 
>> a notice to the ML. In this particular application, it’s for use inside a 
>> service VM for Octavia. Objections/comments/other?
> 
> global-requirements is meant to ensure co-installability between
> OpenStack services.
> Is it safe to assume that software running in service VMs does not need to be
> co-installable with other OpenStack services, since it's separated
> from the control
> plane?
> 

In this particular case, yes, that’s not a concern, but if added to g-r, it 
might proliferate elsewhere over time.

Thanks,
doug

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


__
OpenStack Development Mailing 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] Neutron team social event in Barcelona

[Michael Johnson]

+1

On Fri, Oct 14, 2016 at 11:30 AM, Miguel Lavalle  wrote:
> Dear Neutrinos,
>
> I am organizing a social event for the team on Thursday 27th at 19:30. After
> doing some Google research, I am proposing Raco de la Vila, which is located
> in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here:
> http://www.racodelavila.com/en/carta-racodelavila.htm
>
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under
> 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get
> a final count.
>
> Here's some reviews:
> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
>
> Cheers
>
> Miguel
>
> __
> OpenStack Development Mailing 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] [requirements][lbaas] gunicorn to g-r

[Jim Rollenhagen]

On Mon, Oct 17, 2016 at 1:33 PM, Doug Wiegley
 wrote:
> Hi,
>
> On a review to add gunicorn to global requirements[1], we were asked to send 
> a notice to the ML. In this particular application, it’s for use inside a 
> service VM for Octavia. Objections/comments/other?

global-requirements is meant to ensure co-installability between
OpenStack services.
Is it safe to assume that software running in service VMs does not need to be
co-installable with other OpenStack services, since it's separated
from the control
plane?

// jim

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

Re: [openstack-dev] [all] indoor climbing break at summit?

[Chris Dent]

On Mon, 17 Oct 2016, gordon chung wrote:


you forgot to add disclaimer how you broke every bone in your body a
while back.


\o/ Thanks for paying attention, you get a gold star. But actually
it was only three. And it was outside.

Maybe what you're really looking for here is: Climbing is dangerous. If
you choose to climb, it is at your own risk.

(Sharma's people will take care of that in the registration.)

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

Hi,

On a review to add gunicorn to global requirements[1], we were asked to send a 
notice to the ML. In this particular application, it’s for use inside a service 
VM for Octavia. Objections/comments/other?

Thanks,
doug


[1] https://review.openstack.org/#/c/386790/
__
OpenStack Development Mailing 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] indoor climbing break at summit?

[gordon chung]

On 17/10/16 09:53 AM, Chris Dent wrote:
>
> It turns out that summit this year will be just down the road from
> Chris Sharma's relatively new indoor climbing gym in Barcelona:
>
> http://www.sharmaclimbingbcn.com/
>
> If the fun, frisson and frustration of summit sessions leaves you with
> the energy or need to pull down, maybe we should arrange a visit if we
> can find the time. Maybe we can scribble on an etherpad or something.
> Most of the pictures are of bouldering but since they rent out
> harnesses I guess there must be roped climbing too.
>
> If you're thinking of going apparently they do pre-registration to
> speed things up:
>
> http://www.sharmaclimbingbcn.com/en/gym/
>

you forgot to add disclaimer how you broke every bone in your body a 
while back.

-- 
gord

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

Re: [openstack-dev] [all] indoor climbing break at summit?

[Mathieu, Pierre-Arthur]

Great idea :-)

- Pierre

   

From: Joshua Harlow 
Sent: Monday, October 17, 2016 4:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] indoor climbing break at summit?
    
Chris Dent wrote:
>
> It turns out that summit this year will be just down the road from
> Chris Sharma's relatively new indoor climbing gym in Barcelona:
>
> http://www.sharmaclimbingbcn.com/
>
> If the fun, frisson and frustration of summit sessions leaves you with
> the energy or need to pull down, maybe we should arrange a visit if we
> can find the time. Maybe we can scribble on an etherpad or something.
> Most of the pictures are of bouldering but since they rent out
> harnesses I guess there must be roped climbing too.
>
> If you're thinking of going apparently they do pre-registration to
> speed things up:
>
> http://www.sharmaclimbingbcn.com/en/gym/
>

+2 from me :-P

-Josh

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

__
OpenStack Development Mailing 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 support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[Kiall Mac Innes]

We tend to try stick with the various TEST-NET CIDRs etc as well in 
Designate, and document them here:


http://docs.openstack.org/developer/designate/developer-guidelines.html#example-dns-names-and-ip-space

Thanks,
Kiall

On 17/10/16 10:56, TommyLike Hu wrote:
When I handle some stuff related to Manila recently, I found a case 
which may be suitable for Oslo, Anyhow I put it in the maillist so it 
can be discussed before I put it in action.
In testcase, we need a function(maybe 2) to generate random ip address 
(or network), also they should in the range of [1](ipv4 documentation 
range) or [2](ipv6 documentation range), this is the draft code for ipv4:


import six
import random


def rand_ipv4(network=False):
"""This uses the TEST-NET-3 range of reserved IP addresses."""

test_net_3 = '203.0.113.'
if network:
host_length = random.randint(0, 8)
address_segment = random.randint(0, 8 - host_length)
address_segment <<= host_length
address = test_net_3 + six.text_type(address_segment)
address = '/'.join((address,
six.text_type(32 - host_length)))
else:
address = test_net_3 + six.text_type(random.randint(0, 255))
return address

The primary use case here is writing testcases,  I am not sure whether 
it is suitable here, or maybe I misunderstood the intention of 
TEST-NET-3, please leave any comment you like.



[1] https://tools.ietf.org/html/rfc5737
[2] https://tools.ietf.org/html/rfc5156




__
OpenStack Development Mailing 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] [tosca-parser] [heat-translator] cross-project design session with [Tacker] at summit

[Sahdev P Zala]

Hi team, 

The TOSCA-Parser/Heat-Translator and Tacker will be having a cross-project 
design session at the Barcelona summit. Sripriya has started etherpad doc 
to collect discussion items. If you have any, please add it there. 

Friday, Nov 18th, 11:00am - 11:40am - Workroom Session
Location: CCIB - Centre de Convencions Internacional de Barcelona - P1 - 
Room 128

https://etherpad.openstack.org/p/tacker-ocata-summit


Safe travels. See you there!

Regards, 
Sahdev Zala


__
OpenStack Development Mailing 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 support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[Doug Hellmann]

Excerpts from TommyLike Hu's message of 2016-10-17 14:46:36 +:
> It's used in testcase already, and basic codes is from here:
> https://github.com/openstack/manila/blob/master/manila_tempest_tests/utils.py#L93

OK, I guess the real question I had is why use *random* addresses.
Because that seems like a way to end up having two tests try to use the
same address at the same time. If that did happen, would it cause
conflicts or race conditions for the manila tests?

> 
> Doug Hellmann 于2016年10月17日周一 下午10:13写道：
> 
> > Excerpts from TommyLike Hu's message of 2016-10-17 09:56:15 +:
> > > When I handle some stuff related to Manila recently, I found a case which
> > > may be suitable for Oslo, Anyhow I put it in the maillist so it can be
> > > discussed before I put it in action.
> > > In testcase, we need a function(maybe 2) to generate random ip address
> > (or
> > > network), also they should in the range of [1](ipv4 documentation range)
> > or
> > > [2](ipv6 documentation range), this is the draft code for ipv4:
> > >
> > > import six
> > > import random
> > >
> > >
> > > def rand_ipv4(network=False):
> > > """This uses the TEST-NET-3 range of reserved IP addresses."""
> > >
> > > test_net_3 = '203.0.113.'
> > > if network:
> > > host_length = random.randint(0, 8)
> > > address_segment = random.randint(0, 8 - host_length)
> > > address_segment <<= host_length
> > > address = test_net_3 + six.text_type(address_segment)
> > > address = '/'.join((address,
> > > six.text_type(32 - host_length)))
> > > else:
> > > address = test_net_3 + six.text_type(random.randint(0, 255))
> > > return address
> > >
> > > The primary use case here is writing testcases,  I am not sure whether it
> > > is suitable here, or maybe I misunderstood the intention of TEST-NET-3,
> > > please leave any comment you like.
> > >
> > >
> > > [1]  https://tools.ietf.org/html/rfc5737
> > > [2]  https://tools.ietf.org/html/rfc5156
> >
> > In what way are you using random addresses in tests?
> >
> > 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 Development Mailing 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] Neutron team social event in Barcelona

[John Davidge]

+1

Thanks Miguel!

From: Miguel Lavalle >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, October 14, 2016 at 7:30 PM
To: OpenStack Development Mailing List 
>
Subject: [openstack-dev] [Neutron] Neutron team social event in Barcelona

Dear Neutrinos,

I am organizing a social event for the team on Thursday 27th at 19:30. After 
doing some Google research, I am proposing Raco de la Vila, which is located in 
Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here: 
http://www.racodelavila.com/en/carta-racodelavila.htm

It is easy to get there by subway from the Summit venue: 
https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under 
'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get a 
final count.

Here's some reviews: 
https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html

Cheers

Miguel


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ptl][release] Ocata release liasons

[Doug Hellmann]

It's time to update the release liaison list for the Ocata release.
By default, the release liaison is the PTL and we can continue with
that assumption for this cycle again. If you would like to hand
those duties off to someone else, please update the wiki page
appropriately [1].

Please also ensure that your teams are represented at the release
retrospective and planning session at the summit Thursday afternoon
[2].

Thanks,
Doug

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

[2] 
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17023/release-management-newton-retrospective-ocata-schedule-and-more-release-process-improvements

__
OpenStack Development Mailing 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] indoor climbing break at summit?

[Joshua Harlow]

Chris Dent wrote:


It turns out that summit this year will be just down the road from
Chris Sharma's relatively new indoor climbing gym in Barcelona:

http://www.sharmaclimbingbcn.com/

If the fun, frisson and frustration of summit sessions leaves you with
the energy or need to pull down, maybe we should arrange a visit if we
can find the time. Maybe we can scribble on an etherpad or something.
Most of the pictures are of bouldering but since they rent out
harnesses I guess there must be roped climbing too.

If you're thinking of going apparently they do pre-registration to
speed things up:

http://www.sharmaclimbingbcn.com/en/gym/



+2 from me :-P

-Josh

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

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[Carl Baldwin]

+2

Carl

On Fri, Oct 14, 2016 at 12:30 PM, Miguel Lavalle 
wrote:

> Dear Neutrinos,
>
> I am organizing a social event for the team on Thursday 27th at 19:30.
> After doing some Google research, I am proposing Raco de la Vila, which is
> located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu
> is here: http://www.racodelavila.com/en/carta-racodelavila.htm
>
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
> under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we
> can get a final count.
>
> Here's some reviews: https://www.tripadvisor.com/
> Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_
> Vila-Barcelona_Catalonia.html
>
> Cheers
>
> Miguel
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [trove] no more commits to trove-integration please

[Amrith Kumar]

As we work our way through the project to eliminate the trove-integration
repository, there must come a point when we stop adding any more commits to
the trove-integration repository.

 

As described in the spec[1] for this project, everything in
trove-integration repository (as of the current HEAD
9f92ca853f8aa2f72921e54682c918941a8f0919) has been dropped into the trove
repository [2], and the old redstack tool has been renamed to trovestack[3].
CI Jobs in the trove repository have been proposed. They are currently
experimental jobs and as soon as we know that they are working, they will be
switched to active (voting or non-voting as appropriate) and we will be in a
position where master will no longer need the trove-integration repository.

 

We will keep the trove-integration repository around for two cycles (as it
will continue to be used by the stable branches liberty, mitaka and newton)
and when we get to the Queens release, we'll be able to safely get rid of
the trove-integration repository.

 

At this point, I believe that we are at the stage where we should stop
additional commits to trove-integration.

 

There are two commits outstanding on the repository and I've requested the
author resubmit them to trove.

 

We will discuss this at the Trove meeting this Wednesday. Consistent with
the plan [1], I will be proposing that there will be no further commits to
trove-integration unless they are for something extraordinary that is
required in a stable branch.

 

Thanks,

 

-amrith 

 

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

[2] https://review.openstack.org/#/c/384195/

[3] https://review.openstack.org/#/c/384746/

[4] https://review.openstack.org/#/c/387386/

 

 



smime.p7s
Description: S/MIME cryptographic 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] [Neutron] Database field sizes and attribute "MAX_LEN" constants

[Morales, Victor]

I just want to add my two cents on this.  Several months ago I asked to nova 
community about a bug that they decided to don’t implement, this bug was 
suggesting to add a validation to String OVO field[1] to check if the length of 
the columns has been changed, the answer was that they considered hard to track 
those DB changes.  I mentioned this because maybe we can explore this other 
alternative, just in case that we don’t have the same type of restrictions that 
nova has. By other hand, if our goal is ensuring that integrity of the class 
maybe we can validate them as we do in OVO, using a hash code.

[1] 
https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/fields.py#L254-L265





On 10/15/16, 2:36 PM, "Henry Gessau"  wrote:

>Hi neutrinos,
>
>In Neutron many attributes are stored in database fields. The size of these
>fields therefore determines the maximum length of the attribute values.
>
>I would like to get some consistency in place around how we define the
>constants and where they are used. Here are my thoughts...
>
>
>1. Raw sizes in alembic migrations
>
>In the alembic migrations which build the DB schema, we should use the raw
>number value of the field size.
>
>2. FOO_FIELD_SIZE in the sqlalchemy models
>
>In the sqlalchemy models, we should use the _FIELD_SIZE constants
>defined in neutron_lib/db/constants.py
>
>3. Everywhere else, use FOO_FIELD_SIZE, or another constant (like FOO_MAX_LEN)
>based on FOO_FIELD_SIZE.
>
>
>"Why raw numbers in alembic migrations?", you may ask. Well, we have tests
>that verify that the models match the schema generated by migrations. If both
>the models and the migrations use the constants then the tests would not
>detect if a patch changes the constant value.
>
>By using raw numbers in migrations, together with our rule of not allowing
>changes to existing migrations, we allow the tests to detect and fail on any
>attempt to alter a FIELD_SIZE constant.
>
>Let me know if this makes sense or if you think it's a terrible idea.
>
>If there are no objections, I intend to submit a patch or patches to:
> - replace constants with numbers in existing migrations
> - ensure all models use the appropriate constants
>
>Existing code uses FOO_MAX_LEN in a lot of places. In most of these places it
>would make sense to simply switch to using FOO_FIELD_SIZE. However, some code
>may be quite far removed from the DB and would look better by sticking to
>FOO_MAX_LEN. I added item 3. above to allow for that.
>
>
>__
>OpenStack Development Mailing 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] [Craton] Meeting Cancelled for 2016-10-24

[Ian Cordasco]

Hi all,

With the majority of the Craton team at the Summit next week, we will
be cancelling the weekly IRC meeting. We'll see you all on the 31st!

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] [oslo] Propose support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[TommyLike Hu]

It's used in testcase already, and basic codes is from here:
https://github.com/openstack/manila/blob/master/manila_tempest_tests/utils.py#L93

Doug Hellmann 于2016年10月17日周一 下午10:13写道：

> Excerpts from TommyLike Hu's message of 2016-10-17 09:56:15 +:
> > When I handle some stuff related to Manila recently, I found a case which
> > may be suitable for Oslo, Anyhow I put it in the maillist so it can be
> > discussed before I put it in action.
> > In testcase, we need a function(maybe 2) to generate random ip address
> (or
> > network), also they should in the range of [1](ipv4 documentation range)
> or
> > [2](ipv6 documentation range), this is the draft code for ipv4:
> >
> > import six
> > import random
> >
> >
> > def rand_ipv4(network=False):
> > """This uses the TEST-NET-3 range of reserved IP addresses."""
> >
> > test_net_3 = '203.0.113.'
> > if network:
> > host_length = random.randint(0, 8)
> > address_segment = random.randint(0, 8 - host_length)
> > address_segment <<= host_length
> > address = test_net_3 + six.text_type(address_segment)
> > address = '/'.join((address,
> > six.text_type(32 - host_length)))
> > else:
> > address = test_net_3 + six.text_type(random.randint(0, 255))
> > return address
> >
> > The primary use case here is writing testcases,  I am not sure whether it
> > is suitable here, or maybe I misunderstood the intention of TEST-NET-3,
> > please leave any comment you like.
> >
> >
> > [1]  https://tools.ietf.org/html/rfc5737
> > [2]  https://tools.ietf.org/html/rfc5156
>
> In what way are you using random addresses in tests?
>
> 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 Development Mailing 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] [osc] bug/design flaw: Clients not cached per region

[Dean Troyer]

On Sun, Oct 16, 2016 at 9:11 PM, Adrian Turjak 
wrote:

> The problem I'm running into is for some of our custom plugins we
> require the commands to run in all regions. We do this by getting the
> region list from keystone, and then doing the command in each region.
>
...

> Is there a way to explicitly reinitialise the client_manager?
> 'client_mananger.reinitialise()' or something as easy? Maybe even a
> clear cache command?
>

There is not a way to re-init the ClientManager, and really, you don't want
to do that, but you do want a new compute client for each region.  OSC sets
up the ClientManager client attributes with descriptors in
common/clientmanager.py get_plugin_modules().  At this point we do not have
any region information, so to do that you would have to do it later, but it
is simple enough to return whatever you want from your plugin's
make_client().  Normally that will be a client object for the desired API,
for your plugin it could be a dict of client objects keyed off
region_name.  Then your consuming code would need to deref those with:

  for region in regions:
  nova_client = self.app.client_manager.compute[region]
  do_something(nova_client)



> While explicitly initialising clients isn't exactly difficult, it is
> something that would make more sense to simply work in the base
> openstackclient code as multi-region commands can and will be useful for
> a lot of people.
>

Generalizing this to all of the existing plugins would be an enormous
change, but doable.  We would need to think hard about how many of these
things we need to handle, not just region, but cell or whatever else may be
out there that a command would want to iterate on.


> Not to mention adding multi-region support to some commands so you don't
> have to change OS_REGION_NAME or your region in clouds.yaml could be
> very useful. A command to list your instances across all regions could
> be quite useful and easy to do.
>

It would, and would be near-trivial to do in a plugin with the clients
initialized as I showed above.  Note that we currently can not reliably
hook existing commands to extend them, for example to support a 'server
create' that uses --ram, --vcpu and --disk in place of --flavor.  That will
be discussed next week in BCN.

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] [Neutron] Database field sizes and attribute "MAX_LEN" constants

[Anna Taraday]

Ihar, we all adults here, but this does not save us from making silly
mistakes sometimes :(
I think that if we can protect from possible mistakes - lets do this, as
messing up with size of fields is a common issue.

On Mon, Oct 17, 2016 at 2:16 PM Ihar Hrachyshka  wrote:

> Henry Gessau  wrote:
>
> > Anna Taraday  wrote:
> >> Henry, thanks for taking care of this!
> >>
> >> In my opinion, it is just safe to use raw values in migration, because
> >> migration is a strict point in time.
> >>
> >> I remember how many patches I send in havana in Neutron for fixing
> >> synchronization issues. Usage constants everywhere can be good in this
> >> case,
> >> but ModelMigrationSyc did such check of this for us already.
> >>
> >> If we want to have constants everywhere, we should guarantee that they
> are
> >> unchanged - have test in neutron-lib which verifies their values.
> >
> > Yes, we could have some tests, although a patch changing a constant would
> > probably also have a change to the test. :) We might need to also have a
> > prominent "Warning! Do not change this test!" comment for each test.
>
> I actually think (or hope) everyone is adult here, and will be able to
> block a patch changing a constant, even if there is no unit test written,
> especially if we put such a warning in a comment above the constants we
> know are especially unsafe to touch.
>
> But if we are still think that it’s better safe than sorry, we could have
> some tests to make that even more explicit. It just seems like a waste of
> cpu cycles when any careful reviewer can spot such an issue.
>
> Anyhow, whatever works for the goal, that I think is: making constants safe
> to use in all relevant contexts, including alembic.
>
> 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
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] indoor climbing break at summit?

[Chris Dent]

It turns out that summit this year will be just down the road from
Chris Sharma's relatively new indoor climbing gym in Barcelona:

http://www.sharmaclimbingbcn.com/

If the fun, frisson and frustration of summit sessions leaves you with
the energy or need to pull down, maybe we should arrange a visit if we
can find the time. Maybe we can scribble on an etherpad or something.
Most of the pictures are of bouldering but since they rent out
harnesses I guess there must be roped climbing too.

If you're thinking of going apparently they do pre-registration to
speed things up:

http://www.sharmaclimbingbcn.com/en/gym/


--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Propose support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[Doug Hellmann]

Excerpts from TommyLike Hu's message of 2016-10-17 09:56:15 +:
> When I handle some stuff related to Manila recently, I found a case which
> may be suitable for Oslo, Anyhow I put it in the maillist so it can be
> discussed before I put it in action.
> In testcase, we need a function(maybe 2) to generate random ip address (or
> network), also they should in the range of [1](ipv4 documentation range) or
> [2](ipv6 documentation range), this is the draft code for ipv4:
> 
> import six
> import random
> 
> 
> def rand_ipv4(network=False):
> """This uses the TEST-NET-3 range of reserved IP addresses."""
> 
> test_net_3 = '203.0.113.'
> if network:
> host_length = random.randint(0, 8)
> address_segment = random.randint(0, 8 - host_length)
> address_segment <<= host_length
> address = test_net_3 + six.text_type(address_segment)
> address = '/'.join((address,
> six.text_type(32 - host_length)))
> else:
> address = test_net_3 + six.text_type(random.randint(0, 255))
> return address
> 
> The primary use case here is writing testcases,  I am not sure whether it
> is suitable here, or maybe I misunderstood the intention of TEST-NET-3,
> please leave any comment you like.
> 
> 
> [1]  https://tools.ietf.org/html/rfc5737
> [2]  https://tools.ietf.org/html/rfc5156

In what way are you using random addresses in tests?

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] [ptl][oslo][goals] cross-project workshop on Ocata goal

[Doug Hellmann]

As part of our community goal process [1], we will have a workshop
at the summit next week to discuss implementation details for the
"Remove Incubated Oslo Code" goal [2] and to connect folks who plan
to do the work with guides for migrating to the relevant Oslo
libraries.  Please ensure that your team is represented in the
session [3].

Doug

[1] http://governance.openstack.org/goals/index.html
[2] http://governance.openstack.org/goals/ocata/remove-incubated-oslo-code.html
[3] 
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16941/cross-project-workshops-ocata-goal-remove-incubated-oslo-code

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

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

[Iury Gregory]

Hello Puppeteers!

We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting-4

Here is the agenda:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20161018

Feel free to add topics, and any outstanding bug and patch.

See you tomorrow!
Thanks

-- 
~


*Att[]'sIury Gregory Melo Ferreira *
*Master student in Computer Science at UFCG*

*Part of the puppet-manager-core team in OpenStack*
*E-mail:  iurygreg...@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] [tripleo] [tripleo-ci] tripleo-quickstart-extras and tripleo third party ci

[John Trowbridge]

Added tripleo tag as this missed my email filter, and therefore may have
missed others as well.

On 10/14/2016 02:01 PM, Wesley Hayutin wrote:
> Greetings,
> 
> Hey everyone, I wanted to post a link to a blueprint I'm interested in
> discussing at summit with everyone.  Please share your thoughts and
> comments in the spec / gerrit review.
> 
> https://blueprints.launchpad.net/tripleo/+spec/tripleo-third-party-ci-quickstart
> 
> Thank you!
> 
> 
> 
> __
> OpenStack Development Mailing 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] Neutron team social event in Barcelona

[Miguel Angel Ajo Pelayo]

I probably won't be able to go, but if you plan to hangout in any
other place around after/before dinner, may be I'll join.

 Cheers & Enjoy! :)

On Mon, Oct 17, 2016 at 12:56 PM, Nate Johnston  wrote:
> I responded to Miguel privately, but I'll be there as well!
>
> --N.
>
> On Fri, Oct 14, 2016 at 01:30:57PM -0500, Miguel Lavalle wrote:
>> set=UTF-8
>>
>> Dear Neutrinos,
>>
>> I am organizing a social event for the team on Thursday 27th at 19:30.
>> After doing some Google research, I am proposing Raco de la Vila, which is
>> located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is
>> here: http://www.racodelavila.com/en/carta-racodelavila.htm
>>
>> It is easy to get there by subway from the Summit venue:
>> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under
>> 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get
>> a final count.
>>
>> Here's some reviews:
>> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
>>
>> Chee
>
>> n: inline
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/ope
>
>
> __
> OpenStack Development Mailing 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] [api] [searchlight] Duplicate parameter names

[Chris Dent]

On Wed, 12 Oct 2016, McLellan, Steven wrote:


This issue came up during our meeting last week and it was suggested
to ask the API working group for its opinion, so any comments welcome.


If for whatever reason you don't get enough joy from the mailing
list, feel free to stick this topic on the agenda[1] and show up to
the meetings to talk about it. I'd hope in this case, however, that
email ought to suffice.


This obviously isn't life threatening, more of a convenience for a
number of people who's expressed frustration with getting the
parameter names wrong, but does anyone on the API WG have a strong
opinion against doing it?


If you've already established a commitment to elasticsearch and a
precedent for using some of its grammar for query strings I'd say
that _not_ doing it would be a mistake. What you've proposed in the
review (doing both but not allowing intermixing of the two styles).
makes sense to me.


[1] I am aware of the discussions around paging versus 'marker'-based
scrolling. We plan to add support for a more cursor-like method as
well, but Elasticsearch has always supported paging.


I think this is part of why the pagination guideline sort of stalled
out. In addition to the things you mentioned, it's also the case
that the concept of a page is broken in anything more than the
simplest environment.

I think in your case you want to go with what works and what users
will expect. That's the most important. Trying to achieve strict
consistency on query parameters across the entire breadth of
OpenStack isn't being considerate of the differents contexts of use
and users.

[1] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Database field sizes and attribute "MAX_LEN" constants

[Ihar Hrachyshka]

Henry Gessau  wrote:


Anna Taraday  wrote:

Henry, thanks for taking care of this!

In my opinion, it is just safe to use raw values in migration, because
migration is a strict point in time.

I remember how many patches I send in havana in Neutron for fixing
synchronization issues. Usage constants everywhere can be good in this  
case,

but ModelMigrationSyc did such check of this for us already.

If we want to have constants everywhere, we should guarantee that they are
unchanged - have test in neutron-lib which verifies their values.


Yes, we could have some tests, although a patch changing a constant would
probably also have a change to the test. :) We might need to also have a
prominent "Warning! Do not change this test!" comment for each test.


I actually think (or hope) everyone is adult here, and will be able to  
block a patch changing a constant, even if there is no unit test written,  
especially if we put such a warning in a comment above the constants we  
know are especially unsafe to touch.


But if we are still think that it’s better safe than sorry, we could have  
some tests to make that even more explicit. It just seems like a waste of  
cpu cycles when any careful reviewer can spot such an issue.


Anyhow, whatever works for the goal, that I think is: making constants safe  
to use in all relevant contexts, including alembic.


Ihar

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

Re: [openstack-dev] [Neutron] Database field sizes and attribute "MAX_LEN" constants

[Henry Gessau]

Anna Taraday  wrote:
> Henry, thanks for taking care of this!
> 
> In my opinion, it is just safe to use raw values in migration, because
> migration is a strict point in time.
> 
> I remember how many patches I send in havana in Neutron for fixing
> synchronization issues. Usage constants everywhere can be good in this case,
> but ModelMigrationSyc did such check of this for us already.
> 
> If we want to have constants everywhere, we should guarantee that they are
> unchanged - have test in neutron-lib which verifies their values. 

Yes, we could have some tests, although a patch changing a constant would
probably also have a change to the test. :) We might need to also have a
prominent "Warning! Do not change this test!" comment for each test.

> 
> 
> On Sat, Oct 15, 2016 at 10:41 PM Henry Gessau  > wrote:
> 
> Hi neutrinos,
> 
> In Neutron many attributes are stored in database fields. The size of 
> these
> fields therefore determines the maximum length of the attribute values.
> 
> I would like to get some consistency in place around how we define the
> constants and where they are used. Here are my thoughts...
> 
> 
> 1. Raw sizes in alembic migrations
> 
> In the alembic migrations which build the DB schema, we should use the raw
> number value of the field size.
> 
> 2. FOO_FIELD_SIZE in the sqlalchemy models
> 
> In the sqlalchemy models, we should use the _FIELD_SIZE constants
> defined in neutron_lib/db/constants.py
> 
> 3. Everywhere else, use FOO_FIELD_SIZE, or another constant (like 
> FOO_MAX_LEN)
> based on FOO_FIELD_SIZE.
> 
> 
> "Why raw numbers in alembic migrations?", you may ask. Well, we have tests
> that verify that the models match the schema generated by migrations. If 
> both
> the models and the migrations use the constants then the tests would not
> detect if a patch changes the constant value.
> 
> By using raw numbers in migrations, together with our rule of not allowing
> changes to existing migrations, we allow the tests to detect and fail on 
> any
> attempt to alter a FIELD_SIZE constant.
> 
> Let me know if this makes sense or if you think it's a terrible idea.
> 
> If there are no objections, I intend to submit a patch or patches to:
>  - replace constants with numbers in existing migrations
>  - ensure all models use the appropriate constants
> 
> Existing code uses FOO_MAX_LEN in a lot of places. In most of these 
> places it
> would make sense to simply switch to using FOO_FIELD_SIZE. However, some 
> code
> may be quite far removed from the DB and would look better by sticking to
> FOO_MAX_LEN. I added item 3. above to allow for that.


__
OpenStack Development Mailing 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] Neutron team social event in Barcelona

[Nate Johnston]

I responded to Miguel privately, but I'll be there as well!  

--N.

On Fri, Oct 14, 2016 at 01:30:57PM -0500, Miguel Lavalle wrote:
> set=UTF-8
> 
> Dear Neutrinos,
> 
> I am organizing a social event for the team on Thursday 27th at 19:30.
> After doing some Google research, I am proposing Raco de la Vila, which is
> located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is
> here: http://www.racodelavila.com/en/carta-racodelavila.htm
> 
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under
> 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get
> a final count.
> 
> Here's some reviews:
> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
> 
> Chee

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


__
OpenStack Development Mailing 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] Database field sizes and attribute "MAX_LEN" constants

[Henry Gessau]

Ihar Hrachyshka  wrote:
> Henry Gessau  wrote:
> 
>> Hi neutrinos,
>>
>> In Neutron many attributes are stored in database fields. The size of these
>> fields therefore determines the maximum length of the attribute values.
>>
>> I would like to get some consistency in place around how we define the
>> constants and where they are used. Here are my thoughts...
>>
>>
>> 1. Raw sizes in alembic migrations
>>
>> In the alembic migrations which build the DB schema, we should use the raw
>> number value of the field size.
>>
>> 2. FOO_FIELD_SIZE in the sqlalchemy models
>>
>> In the sqlalchemy models, we should use the _FIELD_SIZE constants
>> defined in neutron_lib/db/constants.py
>>
>> 3. Everywhere else, use FOO_FIELD_SIZE, or another constant (like  
>> FOO_MAX_LEN)
>> based on FOO_FIELD_SIZE.
>>
>>
>> "Why raw numbers in alembic migrations?", you may ask. Well, we have tests
>> that verify that the models match the schema generated by migrations. If  
>> both
>> the models and the migrations use the constants then the tests would not
>> detect if a patch changes the constant value.
>>
>> By using raw numbers in migrations, together with our rule of not allowing
>> changes to existing migrations, we allow the tests to detect and fail on  
>> any
>> attempt to alter a FIELD_SIZE constant.
>>
>> Let me know if this makes sense or if you think it's a terrible idea.
> 
> Not sure. I mean, if you envision that a ‘constant’ value maintained in  
> neutron-lib may be changed in the future, then it’s not safe to use it  
> anywhere, both in models and alembic scripts.
> 
> But I believe those lib constants are supposed to be unchanged, and  
> reviewers of the library should understand that; in which case we should be  
> safe to use them in alembic scripts too.
> 
> Is it that we don’t trust neutron-lib core reviewers to follow the rule?

OK, I suppose using *_FIELD_SIZE constants from neutron-lib in the alembic
scripts is safe enough.

I began thinking about this problem before I added field sizes to neutron-lib,
and it was not a matter of trust. It was more about having a mechanism to
detect a problem if someone tries to change, say, FILE_NAME_MAX_LEN from 16 to
80 without realizing it is related to a DB field. That's a hypothetical
example, but we have many constants and I did not want to count on humans to
detect every impacting case.


__
OpenStack Development Mailing 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] [zaqar] Design Summit Schedule

[feilong]

Hi All,

As we discussed, I've pushed the final design summit schedule[1][2] for 
Zaqar. Please take a look and let me know if there is anything we need 
to change to avoid conflicts.


[1] 
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Zaqar

[2] https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Zaqar



--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at 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] [ironic][devstack][devstack-gate][openstack-infra][networking-generic-switch] Ironic multinode job

[Vasyl Saienko]

Hello openstack-infra, community,

Ironic team got stable multinode job
 and want to move on and add it
to check/gate pipelines. At the moment we are blocked by devstack-gate
changes (3 patches in the list below).
We are kindly asking to help review/merge infra part which is blocker for
the rest of Ironic changes.

*devstack:*

   - "Use userrc_early for all nodes"
   https://review.openstack.org/350801/
   - "Drop SERVICE_HOST=127.0.0.1 from setup_localrc()" https://
   review.openstack.org/#/c/368870/
   


*devstack-gate:*

   -  "Setup ssh-key on subnodes for Ironic" https://review.opensta
   ck.org/#/c/364830
   - "Update ENABLED_SERVICE on subnode with ironic"
   https://review.openstack.org/#/c/368611
   
   - "Update local.conf for ironic-multinode case"
   https://review.openstack.org/#/c/352790/
   


 *ironic:*

   - "Skip create_ovs_taps() for multitenancy case"
*https://review.openstack.org/#/c/382360
   *
   - "Ignore required_services for multinode topology"
   https://review.openstack.org/#/c/352793
   
   - "Skip db configuration on subnodes" https://review.opens
   tack.org/#/c/353303
   - "Fix setting custom IRONIC_VM_NETWORK_BRIDGE" http
   s://review.openstack.org/#/c/365116/
   
   - "Update devstack provision net config for multihost"
   https://review.openstack.org/#/c/368644/
   
   - "Update ironic node names for multinode case"
   https://review.openstack.org/#/c/368645/
   
   - "Skip some steps for multinode case" https://review.openstack
   .org/#/c/368646/
   - "Add devstack setup_vxlan_network()" https:/
   /review.openstack.org/#/c/368647
   
   - "Update iptables rules and services IPs for multinode"
   https://review.openstack.org/#/c/368648/
   


"DO NOT MERGE: Testing multinode stuff" https://review.openstac
k.org/#/c/368173/

Sincerely,
Vasyl Saienko

On Tue, Sep 13, 2016 at 12:04 PM, Vasyl Saienko 
wrote:

> Hello Community,
>
> I'm happy to announce that we got stable ironic multinode job. There are a
> lot of patches  (around 20) to different projects needed to be merged
> before we can move this job to check pipeline.  That is why I'm writing
> this email to openstack-dev. I'm kindly asking cores from the devstack,
> devstack-gate, networking-generic-switch, ironic to review related patches
> from the following list:
>
> *devstack:*
> "Fix common functions to work with V2" https://review.openstack.o
> rg/#/c/366922/
> "Drop SERVICE_HOST=127.0.0.1 from setup_localrc()" https://
> review.openstack.org/#/c/368870/
>
> *devstack-gate:*
> "Add c-vol,c-bak on subnode when c-api enabled"
> https://review.openstack.org/#/c/352909
> "Preparing multinode networking for Ironic" https://review.opensta
> ck.org/#/c/335981
> "Setup ssh-key on subnodes for Ironic" https://review.opensta
> ck.org/#/c/364830
> "Update ENABLED_SERVICE on subnode with ironic"
> https://review.openstack.org/#/c/368611
> "Update local.conf for ironic-multinode case"
> https://review.openstack.org/#/c/352790/
>
> *networking-generic-switch*:
> "Setup multinode avare config" https://review.opensta
> ck.org/#/c/364848/
>
> *ironic:*
> "Configure clean network to provision network"
> https://review.openstack.org/#/c/356632
> "Ignore required_services for multinode topology"
> https://review.openstack.org/#/c/352793
> "Source openrc on subnode in multinode topology"
> https://review.openstack.org/#/c/353302/
> "Skip db configuration on subnodes" https://review.opens
> tack.org/#/c/353303
> "Fix setting custom IRONIC_VM_NETWORK_BRIDGE" http
> s://review.openstack.org/#/c/365116/
> "Update devstack provision net config for multihost"
> https://review.openstack.org/#/c/368644/
> "Update ironic node names for multinode case"
> https://review.openstack.org/#/c/368645/
> "Skip some steps for multinode case" https://review.openstack
> .org/#/c/368646/
> "Add devstack setup_vxlan_network()" https:/
> /review.openstack.org/#/c/368647
> "Update iptables rules and services IPs for multinode"
> https://review.openstack.org/#/c/368648/
> "Testing multinode stuff" https://review.openstack.org/#/c/368173/
>
> Sincerely,
> Vasyl Saienko
>
>
__
OpenStack Development Mailing List (not for usage 

[openstack-dev] [zaqar] Design Summit Schedule

[Fei Long Wang]

Hi All,

As we discussed, I've pushed the final design summit schedule[1][2] for 
Zaqar. Please take a look and let me know if there is anything we need 
to change to avoid conflicts.


[1] 
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Zaqar

[2] https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Zaqar

--
Cheers & Best regards,
Fei Long 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] [Neutron] Neutron team social event in Barcelona

[Elena Ezhova]

+1

On Fri, Oct 14, 2016 at 9:30 PM, Miguel Lavalle  wrote:

> Dear Neutrinos,
>
> I am organizing a social event for the team on Thursday 27th at 19:30.
> After doing some Google research, I am proposing Raco de la Vila, which is
> located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu
> is here: http://www.racodelavila.com/en/carta-racodelavila.htm
>
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
> under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we
> can get a final count.
>
> Here's some reviews: https://www.tripadvisor.com/
> Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_
> Vila-Barcelona_Catalonia.html
>
> Cheers
>
> Miguel
>
> __
> OpenStack Development Mailing 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] Neutron team social event in Barcelona

[Neil Jerram]

+1, looks lovely!

On Fri, Oct 14, 2016 at 7:31 PM Miguel Lavalle  wrote:

> Dear Neutrinos,
>
> I am organizing a social event for the team on Thursday 27th at 19:30.
> After doing some Google research, I am proposing Raco de la Vila, which is
> located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu
> is here: http://www.racodelavila.com/en/carta-racodelavila.htm
>
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
> under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we
> can get a final count.
>
> Here's some reviews:
> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
>
> Cheers
>
> Miguel
> __
> OpenStack Development Mailing 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] Neutron team social event in Barcelona

[Bernard Cafarelli]

+1 (and we are getting quite close to the 25 people headcount)

On 17 October 2016 at 11:37, Daniel Alvarez Sanchez  wrote:
> Hi,
>
> +1 here
>
> On Mon, Oct 17, 2016 at 10:01 AM, Korzeniewski, Artur
>  wrote:
>>
>> +1
>>
>>
>>
>> From: Oleg Bondarev [mailto:obonda...@mirantis.com]
>> Sent: Monday, October 17, 2016 9:52 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [Neutron] Neutron team social event in
>> Barcelona
>>
>>
>>
>> +1
>>
>>
>>
>> On Mon, Oct 17, 2016 at 10:23 AM, Jakub Libosvar 
>> wrote:
>>
>> +1
>>
>>
>>
>> On 14/10/2016 20:30, Miguel Lavalle wrote:
>>
>> Dear Neutrinos,
>>
>> I am organizing a social event for the team on Thursday 27th at 19:30.
>> After doing some Google research, I am proposing Raco de la Vila, which
>> is located in Poblenou: http://www.racodelavila.com/en/index.htm. The
>> menu is here: http://www.racodelavila.com/en/carta-racodelavila.htm
>>
>> It is easy to get there by subway from the Summit venue:
>> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
>> under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so
>> we can get a final count.
>>
>> Here's some reviews:
>>
>> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
>>
>> Cheers
>>
>> Miguel
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Bernard Cafarelli

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

[openstack-dev] [neutron][calico] Disappearance of neutron-lib deprecation warnings?

[Neil Jerram]

Back in August, HenryG committed a useful change [1] to networking-calico
(and I assume to other neutron projects) to show deprecation warnings for
imports from neutron that should now be from neutron-lib.  But then in late
August / early September, those deprecation warnings disappeared again -
and sadly it wasn't because the imports had been fixed to use neutron-lib.
Have any other projects seen that too, and does anyone know what caused
that disappearance?

Specifically, the gate job for a change merged on August 15th shows those
warnings [2], but the gate job for the next merged change, on September
8th, does not show those warnings [3].

Any ideas?
 Neil


[1] https://review.openstack.org/#/c/353135/
[2]
http://logs.openstack.org/48/344848/5/gate/gate-networking-calico-python27-ubuntu-xenial/2f7f55d/console.html.gz
[3]
http://logs.openstack.org/74/366874/2/gate/gate-networking-calico-python27-ubuntu-xenial/637dc05/console.html.gz
__
OpenStack Development Mailing 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] [oslo] Propose support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[TommyLike Hu]

When I handle some stuff related to Manila recently, I found a case which
may be suitable for Oslo, Anyhow I put it in the maillist so it can be
discussed before I put it in action.
In testcase, we need a function(maybe 2) to generate random ip address (or
network), also they should in the range of [1](ipv4 documentation range) or
[2](ipv6 documentation range), this is the draft code for ipv4:

import six
import random


def rand_ipv4(network=False):
"""This uses the TEST-NET-3 range of reserved IP addresses."""

test_net_3 = '203.0.113.'
if network:
host_length = random.randint(0, 8)
address_segment = random.randint(0, 8 - host_length)
address_segment <<= host_length
address = test_net_3 + six.text_type(address_segment)
address = '/'.join((address,
six.text_type(32 - host_length)))
else:
address = test_net_3 + six.text_type(random.randint(0, 255))
return address

The primary use case here is writing testcases,  I am not sure whether it
is suitable here, or maybe I misunderstood the intention of TEST-NET-3,
please leave any comment you like.


[1]  https://tools.ietf.org/html/rfc5737
[2]  https://tools.ietf.org/html/rfc5156
__
OpenStack Development Mailing 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] Neutron team social event in Barcelona

[Daniel Alvarez Sanchez]

Hi,

+1 here

On Mon, Oct 17, 2016 at 10:01 AM, Korzeniewski, Artur <
artur.korzeniew...@intel.com> wrote:

> +1
>
>
>
> *From:* Oleg Bondarev [mailto:obonda...@mirantis.com]
> *Sent:* Monday, October 17, 2016 9:52 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Neutron] Neutron team social event in
> Barcelona
>
>
>
> +1
>
>
>
> On Mon, Oct 17, 2016 at 10:23 AM, Jakub Libosvar 
> wrote:
>
> +1
>
>
>
> On 14/10/2016 20:30, Miguel Lavalle wrote:
>
> Dear Neutrinos,
>
> I am organizing a social event for the team on Thursday 27th at 19:30.
> After doing some Google research, I am proposing Raco de la Vila, which
> is located in Poblenou: http://www.racodelavila.com/en/index.htm. The
> menu is here: http://www.racodelavila.com/en/carta-racodelavila.htm
>
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
> under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so
> we can get a final count.
>
> Here's some reviews:
> https://www.tripadvisor.com/Restaurant_Review-g187497-
> d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
>
> Cheers
>
> Miguel
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] PTG from the Ops Perspective - a few short notes

[Chris Dent]

On Mon, 17 Oct 2016, Renat Akhmerov wrote:


If you are a developer, of course, PTG is an important event to
attend. But… Being a developer, I would also love to attend summits
also. For a bunch of reasons like catching up with the activities
wider than my current focus of development, participating in getting
user feedback and help clarifying possible misunderstanding of
technical things being discussed which makes feedback gathering
process more valuable (I believe that often users don’t know what
they want, at least, in details, we need to help them understand by
sharing our experience) etc. Also, for purely psychological reason I
think it’s very important for people who mostly focus on very
specific tasks to sometimes go and see events like an OpenStack
summit. From my experience, people often change their attitude to
their work when they see how many people are interested in what they
are working on in labs. And it’s almost impossible to find a better
way of getting that feeling of participating in something tremendous
than attending summits.


This. A thousand times this.

Summit is one of the few ways that I get to see the big picture and
that there are actual real people doing real things with OpenStack.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[Luis Tomas Bolivar]

+1

On 10/14/2016 08:30 PM, Miguel Lavalle wrote:
> Dear Neutrinos,
> 
> I am organizing a social event for the team on Thursday 27th at 19:30.
> After doing some Google research, I am proposing Raco de la Vila, which is
> located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is
> here: http://www.racodelavila.com/en/carta-racodelavila.htm
> 
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under
> 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get
> a final count.
> 
> Here's some reviews:
> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
> 
> Cheers
> 
> Miguel
> 
> 
> 
> __
> OpenStack Development Mailing 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] [mistral] Cancelling team meeting - 10/17/2016

[Renat Akhmerov]

Hi, just one week left before the summit and there’s a lot of preparations 
going on so we’re cancelling team meeting today.

Looking forward to seeing you in Barcelona to discuss our topics in person.

Renat Akhmerov
@Nokia

__
OpenStack Development Mailing 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] PTG from the Ops Perspective - a few short notes

[Renat Akhmerov]

Just my small addition into the collection of opinions.

It seems to me that at the core of all disagreements around this new format is 
the difference in our roles.

I've heard from some high-level managers several times that this new format is 
really great because so far we’ve
always had a dilemma who to send to a summit for budget reasons, whether it 
should be sales/marketing/speaking
people to promote projects/initiatives or developers to actually design stuff. 
So they say “Now it’s good because we
clearly know that we won’t be sending developers to summits, what are they 
going to do there? Instead, we
could consider sending some dev folks to a PTG”.


If you are a developer, of course, PTG is an important event to attend. But… 
Being a developer, I would also
love to attend summits also. For a bunch of reasons like catching up with the 
activities wider than my current
focus of development, participating in getting user feedback and help 
clarifying possible misunderstanding
of technical things being discussed which makes feedback gathering process more 
valuable (I believe
that often users don’t know what they want, at least, in details, we need to 
help them understand by sharing
our experience) etc. Also, for purely psychological reason I think it’s very 
important for people who mostly
focus on very specific tasks to sometimes go and see events like an OpenStack 
summit. From my experience,
people often change their attitude to their work when they see how many people 
are interested in what
they are working on in labs. And it’s almost impossible to find a better way of 
getting that feeling of participating
in something tremendous than attending summits.

Having that said though, I myself have mixed feelings about this new format. I 
like the PTG idea to be able to
focus on purely technical stuff. But I would like to participate in both 
events, they are almost equally important 
for me but budget is budget, travelling 4 times a year may be challenging.

Renat Akhmerov
@Nokia

> On 14 Oct 2016, at 23:54, Clint Byrum  wrote:
> 
> Excerpts from Eoghan Glynn's message of 2016-10-14 05:08:44 -0400:
>> 
> Excerpts from Jaesuk Ahn's message of 2016-10-12 15:08:24 +:
>> It can be cheap if you are in the US. However, for Asia folks, it is not
>> that cheap considering it is all overseas travel. In addition,
>> all-in-one
>> event like the current summit makes us much easier to get the travel
>> fund
>> from the company, since the company only need to send everyone (tech,
>> ops,
>> business, strategy) to one event. Even as an ops or developers, doing
>> presentation or a meeting with one or two important company can be very
>> good excuse to get the travel money.
>> 
> 
> This is definitely on the list of concerns I heard while the split was
> being discussed.
> 
> I think the concern is valid, and we'll have to see how it affects
> attendance at PTG's and summits.
> 
> However, I am not so sure the overseas cost is being accurately
> characterized. Of course, the complications are higher with immigration
> details, but ultimately hotels around international hub airports are
> extremely cheap, and flights tend to be quite a bit less expensive and
> more numerous to these locations. You'll find flights from Narita to
> LAX for < $500 where as you'd be hard pressed to find Narita to Boston
> for under $600, and they'll be less convenient, possibly requiring more
> hotel days.
 
 The bit about hotels contradicts my whole experience. I've never seen
 hotels in
 big busy hubs cheaper than in less popular and crowded cities. Following
 your
 logic, hotels e.g. in Paris should be cheaper than ones in e.g. Prague,
 which I
 promise you is far from being the case :)
 
>>> 
>>> Sorry I communicated that horribly.
>>> 
>>> The hotels next to LAX, which are _ugly_ and _disgusting_ but perfectly
>>> suitable for a PTG, are much cheaper than say, the ones in DT LA near the
>>> convention center, or in Hollywood, or near Disneyland.
>>> 
>>> A better comparison than LAX might be Atlanta or Minneapolis, which
>>> are cities that aren't such common end-destinations, but have tons of
>>> flights in and out and generally affordable accommodations.
>>> 
> 
> Also worth considering is how cheap the space is for the PTG
> vs. Summit. Without need for large expo halls, keynote speakers,
> catered lunch and cocktail hours, we can rent a smaller, less impressive
> space. That should mean either a cheaper ticket price (if there is one
> at all) or more sponsored travel to the PTG. Either one of those should
> help alleviate the concerns about travel budget.
 
 For upstream developers ticker price was 0. Now it will be > 0, so for
 companies
 who send mostly developers, this is a clear budget increase.
 
>>> 
>>> 

[openstack-dev] [zaqar] Meeting cancelled at 17th Oct

[Fei Long Wang]

Hi Team,

Since most of us maybe in travel to summit, so the meeting will be 
cancelled and let's meet at Barcelona.


--
Cheers & Best regards,
Fei Long 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] [Neutron] Database field sizes and attribute "MAX_LEN" constants

[Anna Taraday]

Henry, thanks for taking care of this!

In my opinion, it is just safe to use raw values in migration, because
migration is a strict point in time.

I remember how many patches I send in havana in Neutron for fixing
synchronization issues. Usage constants everywhere can be good in this
case, but ModelMigrationSyc did such check of this for us already.

If we want to have constants everywhere, we should guarantee that they are
unchanged - have test in neutron-lib which verifies their values.


On Sat, Oct 15, 2016 at 10:41 PM Henry Gessau  wrote:

Hi neutrinos,

In Neutron many attributes are stored in database fields. The size of these
fields therefore determines the maximum length of the attribute values.

I would like to get some consistency in place around how we define the
constants and where they are used. Here are my thoughts...


1. Raw sizes in alembic migrations

In the alembic migrations which build the DB schema, we should use the raw
number value of the field size.

2. FOO_FIELD_SIZE in the sqlalchemy models

In the sqlalchemy models, we should use the _FIELD_SIZE constants
defined in neutron_lib/db/constants.py

3. Everywhere else, use FOO_FIELD_SIZE, or another constant (like
FOO_MAX_LEN)
based on FOO_FIELD_SIZE.


"Why raw numbers in alembic migrations?", you may ask. Well, we have tests
that verify that the models match the schema generated by migrations. If
both
the models and the migrations use the constants then the tests would not
detect if a patch changes the constant value.

By using raw numbers in migrations, together with our rule of not allowing
changes to existing migrations, we allow the tests to detect and fail on any
attempt to alter a FIELD_SIZE constant.

Let me know if this makes sense or if you think it's a terrible idea.

If there are no objections, I intend to submit a patch or patches to:
 - replace constants with numbers in existing migrations
 - ensure all models use the appropriate constants

Existing code uses FOO_MAX_LEN in a lot of places. In most of these places
it
would make sense to simply switch to using FOO_FIELD_SIZE. However, some
code
may be quite far removed from the DB and would look better by sticking to
FOO_MAX_LEN. I added item 3. above to allow for that.


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

-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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] Neutron team social event in Barcelona

[Anna Taraday]

Very nice place, I'd love to come :)
+1

On Mon, Oct 17, 2016 at 11:18 AM  wrote:

> Hello,
>
> +1
>
> --
> Sławek Kapłoński
> sla...@kaplonski.pl
>
>
> W dniu 14.10.2016 20:30, Miguel Lavalle napisał(a):
>
> > Dear Neutrinos,
> >
> > I am organizing a social event for the team on Thursday 27th at 19:30.
> > After doing some Google research, I am proposing Raco de la Vila, which
> > is located in Poblenou: http://www.racodelavila.com/en/index.htm. The
> > menu is here: http://www.racodelavila.com/en/carta-racodelavila.htm
> >
> > It is easy to get there by subway from the Summit venue:
> > https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
> > under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so
> > we can get a final count.
> >
> > Here's some reviews:
> >
> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
> >
> > Cheers
> >
> > Miguel
> >
> __
> > OpenStack Development Mailing 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
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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] Database field sizes and attribute "MAX_LEN" constants

[Ihar Hrachyshka]

Henry Gessau  wrote:


Hi neutrinos,

In Neutron many attributes are stored in database fields. The size of these
fields therefore determines the maximum length of the attribute values.

I would like to get some consistency in place around how we define the
constants and where they are used. Here are my thoughts...


1. Raw sizes in alembic migrations

In the alembic migrations which build the DB schema, we should use the raw
number value of the field size.

2. FOO_FIELD_SIZE in the sqlalchemy models

In the sqlalchemy models, we should use the _FIELD_SIZE constants
defined in neutron_lib/db/constants.py

3. Everywhere else, use FOO_FIELD_SIZE, or another constant (like  
FOO_MAX_LEN)

based on FOO_FIELD_SIZE.


"Why raw numbers in alembic migrations?", you may ask. Well, we have tests
that verify that the models match the schema generated by migrations. If  
both

the models and the migrations use the constants then the tests would not
detect if a patch changes the constant value.

By using raw numbers in migrations, together with our rule of not allowing
changes to existing migrations, we allow the tests to detect and fail on  
any

attempt to alter a FIELD_SIZE constant.

Let me know if this makes sense or if you think it's a terrible idea.


Not sure. I mean, if you envision that a ‘constant’ value maintained in  
neutron-lib may be changed in the future, then it’s not safe to use it  
anywhere, both in models and alembic scripts.


But I believe those lib constants are supposed to be unchanged, and  
reviewers of the library should understand that; in which case we should be  
safe to use them in alembic scripts too.


Is it that we don’t trust neutron-lib core reviewers to follow the rule?

Ihar

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

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[slawek]

Hello,

+1

--
Sławek Kapłoński
sla...@kaplonski.pl


W dniu 14.10.2016 20:30, Miguel Lavalle napisał(a):


Dear Neutrinos,

I am organizing a social event for the team on Thursday 27th at 19:30. 
After doing some Google research, I am proposing Raco de la Vila, which 
is located in Poblenou: http://www.racodelavila.com/en/index.htm. The 
menu is here: http://www.racodelavila.com/en/carta-racodelavila.htm


It is easy to get there by subway from the Summit venue: 
https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people 
under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so 
we can get a final count.


Here's some reviews: 
https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html


Cheers

Miguel
__
OpenStack Development Mailing 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] Neutron team social event in Barcelona

[Korzeniewski, Artur]

+1

From: Oleg Bondarev [mailto:obonda...@mirantis.com]
Sent: Monday, October 17, 2016 9:52 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

+1

On Mon, Oct 17, 2016 at 10:23 AM, Jakub Libosvar 
> wrote:
+1


On 14/10/2016 20:30, Miguel Lavalle wrote:
Dear Neutrinos,

I am organizing a social event for the team on Thursday 27th at 19:30.
After doing some Google research, I am proposing Raco de la Vila, which
is located in Poblenou: http://www.racodelavila.com/en/index.htm. The
menu is here: http://www.racodelavila.com/en/carta-racodelavila.htm

It is easy to get there by subway from the Summit venue:
https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so
we can get a final count.

Here's some reviews:
https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html

Cheers

Miguel

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


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

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

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[Oleg Bondarev]

+1

On Mon, Oct 17, 2016 at 10:23 AM, Jakub Libosvar 
wrote:

> +1
>
>
> On 14/10/2016 20:30, Miguel Lavalle wrote:
>
>> Dear Neutrinos,
>>
>> I am organizing a social event for the team on Thursday 27th at 19:30.
>> After doing some Google research, I am proposing Raco de la Vila, which
>> is located in Poblenou: http://www.racodelavila.com/en/index.htm. The
>> menu is here: http://www.racodelavila.com/en/carta-racodelavila.htm
>>
>> It is easy to get there by subway from the Summit venue:
>> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
>> under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so
>> we can get a final count.
>>
>> Here's some reviews:
>> https://www.tripadvisor.com/Restaurant_Review-g187497-d16820
>> 57-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
>>
>> Cheers
>>
>> Miguel
>>
>>
>> 
>> __
>> 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] [mistral][ocata][summit] Etherpad for work sessions

[Renat Akhmerov]

Sorry, this is the right link: 
https://etherpad.openstack.org/p/mistral-barcelona-summit-topics-2016 


Renat Akhmerov
@Nokia

> On 17 Oct 2016, at 14:18, Renat Akhmerov  wrote:
> 
> Hi,
> 
> An etherpad for Mistral work sessions in Barcelona is created: 
> https://etherpad.openstack.org/p/mistral-barcelona-summit-topics-2106 
> 
> 
> I put an initial list of topics which are the most important from my 
> perspective. Please add yours so that we could plan our sessions in advance.
> 
> Thanks
> 
> Renat Akhmerov
> @Nokia
> 

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