[openstack-dev] [mistral] Kilo-2 development milestone released

[Renat Akhmerov]

Hi,

Mistral Kilo-2 dev milestone has been released

Release pages for Mistral and Mistral Client:
https://launchpad.net/mistral/kilo/kilo-2 

https://launchpad.net/python-mistralclient/kilo/kilo-2 


There you can find a list of implemented blueprints and fixed bugs as well as 
the links to downloadable files.

Thanks

Renat Akhmerov
@ Mirantis Inc.



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

Re: [openstack-dev] [python-cinderclient] Return request ID to caller

[Kekane, Abhishek]

Hi Devs,

This change is not backward compatible and to do not break OpenStack services 
which are using cinder-client,
we need to first make provision in these consumer services to handle 
cinder-client return type change.
To make this cinder-client change backward compatible we need to do changes in 
consumers of cinder-client like patch : https://review.openstack.org/#/c/152820/

Also for backward compatibility can we make changes suggested by Gary W. Smith 
on cinder-spec : https://review.openstack.org/#/c/132161/6/.
As per his suggestion we need to add one new optional kwarg 'return_req_id' in 
cinder-client api methods, when it is 'True' cinder-client will returns the 
tuple, but when False (the default) it returns the current value (i.e.- only 
response body).

For example cinder-client 'get' method will look like -

def _get(self, url, response_key=None, return_req_id=False):
resp, body = self.api.client.get(url)
if response_key:
body = self.resource_class(self, body[response_key], loaded=True)
else:
body = self.resource_class(self, body, loaded=True)

if return_req_id:
# return tuple containing headers and body
return (resp.headers, body)

return body


If we want headers from cinder-client then we need to pass kwarg 
'return_req_id' as True from caller.
For example from nova we need to call cinder-client get method as -

resp_header, volume = cinderclient(context).volumes.get(volume_id, 
return_req_id=True)


With this optional kwarg 'return_req_id' approach we do not need to make 
changes in services which are using cinder-client.
It will be backward compatible change.

Could you please give your suggestion on this approach.

Thanks,

Abhishek


From: Joe Gordon [mailto:joe.gord...@gmail.com]
Sent: 05 February 2015 22:50
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [python-cinderclient] Return request ID to caller



On Wed, Feb 4, 2015 at 11:23 PM, Malawade, Abhijeet 
mailto:abhijeet.malaw...@nttdata.com>> wrote:
Hi,

I have submitted patch for cinder-client [1] to 'Return tuple containing header 
and body from client' instead of just response.
Also cinder spec for the same is under review [2].

This change will break OpenStack services which are using cinder-client. To do 
not break services which are using cinder-client,
we need to first make changes in those projects to check return type of 
cinder-client. We are working on doing cinder-client return
type check changes in OpenStack services like nova, glance_store, heat, trove, 
manila etc.
We have already submitted patch for same against nova : 
https://review.openstack.org/#/c/152820/

[1] https://review.openstack.org/#/c/152075/
[2] https://review.openstack.org/#/c/132161/

This sounds like a backwards incompatible change to the python client, that 
will break downstream consumers of python-cinderclient. This change should be 
done in a way that allows us to deprecate the old usage without breaking it 
right away.


I want to seek early feedback from the community members on the above patches, 
so please give your thoughts on the same.

Thanks,
Abhijeet Malawade

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

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


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
OpenStack Development Mailing 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][oslo.db][nova] TL; DR Things everybody should know about Galera

[Rushi Agrawal]

On 5 February 2015 at 23:07, Clint Byrum  wrote:

> Excerpts from Avishay Traeger's message of 2015-02-04 22:19:53 -0800:
> > On Wed, Feb 4, 2015 at 11:00 PM, Robert Collins <
> robe...@robertcollins.net>
> > wrote:
> >
> > > On 5 February 2015 at 10:24, Joshua Harlow 
> wrote:
> > > > How interesting,
> > > >
> > > > Why are people using galera if it behaves like this? :-/
> > >
> > > Because its actually fairly normal. In fact its an instance of point 7
> > > on https://wiki.openstack.org/wiki/BasicDesignTenets - one of our
> > > oldest wiki pages :).
> > >
> >
> > When I hear MySQL I don't exactly think of eventual consistency (#7),
> > scalability (#1), horizontal scalability (#4), etc.
> > For the past few months I have been advocating implementing an
> alternative
> > to db/sqlalchemy, but of course it's a huge undertaking.  NoSQL (or even
> > distributed key-value stores) should be considered IMO.  Just some food
> for
> > thought :)
> >
>
> I know it is popular to think that MySQL* == old slow and low-scale, but
> that is only popular with those who have not actually tried to scale
> MySQL. You may want to have a chat with the people running MySQL at
> Google, Facebook, and a long tail of not quite as big sites but still
> massively bigger than most clouds. Note that many of the people who
> helped those companies scale up are involved directly with OpenStack.
>
> Just an aside: Youtube relies completely on MySQL for all of it's database
traffic, but uses a layer on top of it called Vitess [1] to allow it to
scale.

[1]: https://github.com/youtube/vitess


> The NoSQL bits that are popular out there make the easy part easy. There
> is no magic bullet for the hard part, which is when you need to do both
> synchronous and asynchronous. Factor in its maturity and the breadth of
> talent available, and I'll choose MySQL for this task every time.
>
> * Please let's also give a nod to our friends working on MariaDB, a
>   MySQL-compatible fork that many find preferrable and for the purposes
>   of this discussion, equivalent.
>
> __
> OpenStack Development Mailing 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][cinder][neutron][security] Rootwrap on root-intensive nodes

[Steven Dake (stdake)]

On 2/4/15, 10:24 AM, "Daniel P. Berrange"  wrote:

>On Wed, Feb 04, 2015 at 09:10:06AM -0800, James E. Blair wrote:
>> Thierry Carrez  writes:
>> 
>> > You make a good point when you mention "traditional distro" here. I
>> > would argue that containers are slightly changing the rules of the
>> > don't-run-as-root game.
>> >
>> > Solution (2) aligns pretty well with container-powered OpenStack
>> > deployments -- running compute nodes as root in a container (and
>> > embracing abovementioned simplicity/performance gains) sounds like a
>> > pretty strong combo.
>> 
>> This sounds at least a little like a suggestion that containers are a
>> substitute for the security provided by running non-root.  The security
>> landscape around containers is complex, and while there are a lot of
>> benefits, I believe the general consensus is that uid 0 processes should
>> not be seen as fully isolated.
>> 
>> From https://docs.docker.com/articles/security/ :
>> 
>>   Docker containers are, by default, quite secure; especially if you
>>   take care of running your processes inside the containers as
>>   non-privileged users (i.e., non-root).
>> 
>> Which is not to say that using containers is not a good idea, but
>> rather, if one does, one should avoid running as root (perhaps with
>> capabilities), and use selinux (or similar).
>
>Yep, I've seen attempts by some folks to run nova-compute and libvirtd
>and QEMU inside a docker container. Because of the inherantly privileged
>nature of what Nova/libvirt/qemu need to do, you end up having to share
>all the host namespaces with the docker container, except for the
>filesystem
>namespace and even that you need to bind mount a bunch of stuff over. As
>a result the container isn't really offerring any security benefit over
>running the things outside the container. IOW the use of containers to
>confine nova is only solving a managability problem rather than a security
>problem.
>
>Regards,
>Daniel

Daniel,

Agree 100% - compute in containers is all about an atomic image-based
upgrade and downgrade process, not about solving security problems.
Ideally the services that are within containers are as secure as running
natively without containers on bare metal although this might be a bit of
assumption since docker does run with all Linux capabilities enabled.

Regards
-steve

>-- 
>|: http://berrange.com  -o-
>http://www.flickr.com/photos/dberrange/ :|
>|: http://libvirt.org  -o-
>http://virt-manager.org :|
>|: http://autobuild.org   -o-
>http://search.cpan.org/~danberr/ :|
>|: http://entangle-photo.org   -o-
>http://live.gnome.org/gtk-vnc :|
>
>__
>OpenStack Development Mailing 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] [python-novaclient][nova] future of --os-compute-api-version option and whole api versioning

[Christopher Yeoh]

On Thu, Feb 5, 2015 at 11:37 AM, Andrey Kurilin 
wrote:

> First results is https://review.openstack.org/#/c/152569/
>
> > - if os-compute-api-version is not supplied don't send any header at all
> > - it is probably worth doing a bit version parsing to see if it makes
> sense eg of format:
> >  r"^([1-9]\d*)\.([1-9]\d*|0)$" or latest
>
> implemented
>
>
> >- handle  HTTPNotAcceptable if the user asked for a version which is not
> supported
> >  (can also get a badrequest if its badly formatted and got through the
> novaclient filter)
> Based on https://review.openstack.org/#/c/150641/ , HTTPNotFound (404)
> will be returned by API, so the current implementation of novaclient is not
> required any changes.
>
>
So a microversion (say v2.12) is a concept which covers the API as a whole,
not just an extension. And as a result there is a concept of a minimum
version supported (currently 2.1) and a maximum). If a client requests a
version which it outside of min<->max they will have a HTTPNotAcceptable
returned.

If a client a requests a version which is valid, but the actual resource
point they attempt to access does not support an implementation (say the
version requested did not support anything yet), they will get a 404 (eg it
pretends not to be there).



> > - show the version header information returned
> Imo, API should return exception with proper message which already include
> this information.
>

Yep, if you request a version which doesn't fit within the global supported
(min<->max) you will get  a 406 which specifies min/max api versions for
that server.

For any other request you get returned an X-OpenStack-Compute-API-Version
header which
specifies the version used - which you may nto have exactly known on the
request if you didn't specify a version (eg not specified or 'latest')

Regards,

Chris


>
> On Mon, Feb 2, 2015 at 2:02 PM, Andrey Kurilin 
> wrote:
>
>> Thanks for the summary, I'll try to send first patch(maybe WIP) in few
>> days.
>>
>> On Mon, Feb 2, 2015 at 1:43 PM, Christopher Yeoh 
>> wrote:
>>
>>>
>>>
>>> On Sat, Jan 31, 2015 at 4:09 AM, Andrey Kurilin 
>>> wrote:
>>>
 Thanks for the answer. Can I help with implementation of novaclient
 part?

>>>
>>> Sure! Do you think its something you can get proposed into Gerrit by the
>>> end of the week or very soon after?
>>> Its the sort of timeframe we're looking for to get microversions enabled
>>> asap I guess just let me know if it
>>> turns out you don't have the time.
>>>
>>> So I think a short summary of what is needed is:
>>> - if os-compute-api-version is not supplied don't send any header at all
>>> - it is probably worth doing a bit version parsing to see if it makes
>>> sense eg of format:
>>>  r"^([1-9]\d*)\.([1-9]\d*|0)$" or latest
>>> - handle  HTTPNotAcceptable if the user asked for a version which is not
>>> supported
>>>   (can also get a badrequest if its badly formatted and got through the
>>> novaclient filter)
>>> - show the version header information returned
>>>
>>> Regards,
>>>
>>> Chris
>>>
>>>
 On Wed, Jan 28, 2015 at 11:50 AM, Christopher Yeoh 
 wrote:

> On Fri, 23 Jan 2015 15:51:54 +0200
> Andrey Kurilin  wrote:
>
> > Hi everyone!
> > After removing nova V3 API from novaclient[1], implementation of v1.1
> > client is used for v1.1, v2 and v3 [2].
> > Since we moving to micro versions, I wonder, do we need such
> > mechanism of choosing api version(os-compute-api-version) or we can
> > simply remove it, like in proposed change - [3]?
> > If we remove it, how micro version should be selected?
> >
>
> So since v3 was never officially released I think we can re-use
> os-compute-api-version for microversions which will map to the
> X-OpenStack-Compute-API-Version header. See here for details on what
> the header will look like. We need to also modify novaclient to handle
> errors when a version requested is not supported by the server.
>
> If the user does not specify a version number then we should not send
> anything at all. The server will run the default behaviour which for
> quite a while will just be v2.1 (functionally equivalent to v.2)
>
>
> http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html
>
>
> >
> > [1] - https://review.openstack.org/#/c/138694
> > [2] -
> >
> https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L763-L769
> > [3] - https://review.openstack.org/#/c/149006
> >
>
>


 --
 Best regards,
 Andrey Kurilin.

>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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] Request non-priority feature freeze exception for contrail vif driver

[Nati Ueno]

Hi folks

May I request FFE for contrail vif driver?
This is really tiny patch which has just  about 100 line including unit test.
also, it is really harmless code for the other part.

This patch uploaded 1/21 but unfortunately we couldn't get attention
for this patch.

Code
https://review.openstack.org/#/c/148805/
(BP as approved and now pending due to FFE)

Best
Nachi

-- 
Nachi Ueno
email:nati.u...@gmail.com
twitter:http://twitter.com/nati

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

[openstack-dev] [OpenStack-Infra] Devstack error when running g-reg: 401 Unauthorized

[liuxinguo]

Our CI get the following error when build devstack, begin from service ‘g-reg’ 
when uploading image:

is_service_enabled g-reg
2015-02-05 03:14:54.966 | + return 0
2015-02-05 03:14:54.968 | ++ keystone token-get
2015-02-05 03:14:54.968 | ++ grep ' id '
2015-02-05 03:14:54.969 | ++ get_field 2
2015-02-05 03:14:54.970 | ++ local data field
2015-02-05 03:14:54.970 | ++ read data
2015-02-05 03:14:55.797 | ++ '[' 2 -lt 0 ']'
2015-02-05 03:14:55.798 | ++ field='$3'
2015-02-05 03:14:55.799 | ++ echo '| id| 
9660a765e04d4d0a8bc3f0f44b305161 |'
2015-02-05 03:14:55.800 | ++ awk '-F[ \t]*\\|[ \t]*' '{print $3}'
2015-02-05 03:14:55.802 | ++ read data
2015-02-05 03:14:55.804 | + TOKEN=9660a765e04d4d0a8bc3f0f44b305161
2015-02-05 03:14:55.804 | + die_if_not_set 1137 TOKEN 'Keystone fail to get 
token'
2015-02-05 03:14:55.804 | + local exitcode=0
2015-02-05 03:14:55.810 | + echo_summary 'Uploading images'
2015-02-05 03:14:55.810 | + [[ -t 3 ]]
2015-02-05 03:14:55.810 | + [[ True != \T\r\u\e ]]
2015-02-05 03:14:55.810 | + echo -e Uploading images
2015-02-05 03:14:55.810 | + [[ -n '' ]]
2015-02-05 03:14:55.810 | + for image_url in '${IMAGE_URLS//,/ }'
2015-02-05 03:14:55.811 | + upload_image 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz 
9660a765e04d4d0a8bc3f0f44b305161
2015-02-05 03:14:55.811 | + local 
image_url=http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz
2015-02-05 03:14:55.811 | + local token=9660a765e04d4d0a8bc3f0f44b305161
2015-02-05 03:14:55.811 | + local image image_fname image_name
2015-02-05 03:14:55.811 | + mkdir -p /opt/stack/new/devstack/files/images
2015-02-05 03:14:55.813 | ++ basename 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz
2015-02-05 03:14:55.815 | + image_fname=cirros-0.3.2-x86_64-uec.tar.gz
2015-02-05 03:14:55.815 | + [[ 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz != file* 
]]
2015-02-05 03:14:55.815 | + [[ ! -f 
/opt/stack/new/devstack/files/cirros-0.3.2-x86_64-uec.tar.gz ]]
2015-02-05 03:14:55.816 | ++ stat -c %s 
/opt/stack/new/devstack/files/cirros-0.3.2-x86_64-uec.tar.gz
2015-02-05 03:14:55.818 | + [[ 8655821 = \0 ]]
2015-02-05 03:14:55.818 | + 
image=/opt/stack/new/devstack/files/cirros-0.3.2-x86_64-uec.tar.gz
2015-02-05 03:14:55.819 | + [[ 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz =~ openvz 
]]
2015-02-05 03:14:55.819 | + [[ 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz =~ \.vmdk 
]]
2015-02-05 03:14:55.819 | + [[ 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz =~ 
\.vhd\.tgz ]]
2015-02-05 03:14:55.819 | + [[ 
http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-uec.tar.gz =~ 
\.xen-raw\.tgz ]]
2015-02-05 03:14:55.819 | + local kernel=
2015-02-05 03:14:55.819 | + local ramdisk=
2015-02-05 03:14:55.819 | + local disk_format=
2015-02-05 03:14:55.819 | + local container_format=
2015-02-05 03:14:55.819 | + local unpack=
2015-02-05 03:14:55.819 | + local img_property=
2015-02-05 03:14:55.819 | + case "$image_fname" in
2015-02-05 03:14:55.819 | + '[' cirros-0.3.2-x86_64-uec '!=' 
cirros-0.3.2-x86_64-uec.tar.gz ']'
2015-02-05 03:14:55.819 | + image_name=cirros-0.3.2-x86_64-uec
2015-02-05 03:14:55.819 | + local 
xdir=/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec
2015-02-05 03:14:55.819 | + rm -Rf 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec
2015-02-05 03:14:55.912 | + mkdir 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec
2015-02-05 03:14:55.913 | + tar -zxf 
/opt/stack/new/devstack/files/cirros-0.3.2-x86_64-uec.tar.gz -C 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec
2015-02-05 03:14:56.619 | ++ for f in '"$xdir/"*-vmlinuz*' '"$xdir/"aki-*/image'
2015-02-05 03:14:56.619 | ++ '[' -f 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec/cirros-0.3.2-x86_64-vmlinuz
 ']'
2015-02-05 03:14:56.619 | ++ echo 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec/cirros-0.3.2-x86_64-vmlinuz
2015-02-05 03:14:56.619 | ++ break
2015-02-05 03:14:56.620 | ++ true
2015-02-05 03:14:56.620 | + 
kernel=/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec/cirros-0.3.2-x86_64-vmlinuz
2015-02-05 03:14:56.621 | ++ for f in '"$xdir/"*-initrd*' '"$xdir/"ari-*/image'
2015-02-05 03:14:56.622 | ++ '[' -f 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec/cirros-0.3.2-x86_64-initrd
 ']'
2015-02-05 03:14:56.622 | ++ echo 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec/cirros-0.3.2-x86_64-initrd
2015-02-05 03:14:56.622 | ++ break
2015-02-05 03:14:56.622 | ++ true
2015-02-05 03:14:56.623 | + 
ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec/cirros-0.3.2-x86_64-initrd
2015-02-05 03:14:56.624 | ++ for f in '"$xdir/"*.img' '"$xdir/"ami-*/image'
2015-02-05 03:14:56.624 | ++ '[' -f 
/opt/stack/new/devstack/files/images/cirros-0.3.2-x86_64-uec/cirros-0.3.2-x86_64-blank.img
 ']'
2015-02-05 03:14:56.625 | ++ echo 
/opt/s

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

[Mathieu Gagné]

On 2015-02-05 9:36 PM, Angus Lees wrote:

On Fri Feb 06 2015 at 12:59:13 PM Gregory Haynes mailto:g...@greghaynes.net>> wrote:

Along those lines and in an effort to be a bit less doom-and-gloom, I
spent my lunch break trying to find non-marketing documentation on the
Galera replication protocol and how it is exposed. (It was surprisingly
difficult to find such information *)

It's easy to get the transaction ID of the last commit
(wsrep_last_committed), but I can't find a way to wait until at least a
particular transaction ID has been synced.  If we can find that latter
functionality, then we can expose that sequencer all the way through
(HTTP header?) and then any follow-on commands can mention the sequencer
of the previous write command that they really need to see the effects of.

In practice, this should lead to zero additional wait time, since the
Galera replication has almost certainly already caught up by the time
the second command comes in - and we can just read from the local server
with no additional delay.

See the various *Index variables in the etcd API, for how the same idea
gets used there.



I don't use Galera but managed to understand that you don't need all 
this complex system, it's already built-in within Galera. Matthew Booth 
already mentioned it in his first post.


The wsrep_sync_wait [1][2][3] variable can be scoped to the session and 
force a synchronous/committed read if you *really* need it but will 
result in larger read latencies.


[1] 
http://galeracluster.com/documentation-webpages/mysqlwsrepoptions.html#wsrep-sync-wait
[2] 
http://www.percona.com/doc/percona-xtradb-cluster/5.5/wsrep-system-index.html#wsrep_sync_wait
[3] 
https://mariadb.com/kb/en/mariadb/galera-cluster-system-variables/#wsrep_sync_wait


--
Mathieu

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

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

[Gregory Haynes]

Excerpts from Angus Lees's message of 2015-02-06 02:36:32 +:
> On Fri Feb 06 2015 at 12:59:13 PM Gregory Haynes 
> wrote:
> 
> > Excerpts from Joshua Harlow's message of 2015-02-06 01:26:25 +:
> > > Angus Lees wrote:
> > > > On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum  > > > > wrote:
> > > > I'd also like to see consideration given to systems that handle
> > > > distributed consistency in a more active manner. etcd and
> > Zookeeper are
> > > > both such systems, and might serve as efficient guards for critical
> > > > sections without raising latency.
> > > >
> > > >
> > > > +1 for moving to such systems.  Then we can have a repeat of the above
> > > > conversation without the added complications of SQL semantics ;)
> > > >
> > >
> > > So just an fyi:
> > >
> > > http://docs.openstack.org/developer/tooz/ exists.
> > >
> > > Specifically:
> > >
> > > http://docs.openstack.org/developer/tooz/developers.
> > html#tooz.coordination.CoordinationDriver.get_lock
> > >
> > > It has a locking api that it provides (that plugs into the various
> > > backends); there is also a WIP https://review.openstack.org/#/c/151463/
> > > driver that is being worked for etc.d.
> > >
> >
> > An interesting note about the etcd implementation is that you can
> > select per-request whether you want to wait for quorum on a read or not.
> > This means that in theory you could obtain higher throughput for most
> > operations which do not require this and then only gain quorum for
> > operations which require it (e.g. locks).
> >
> 
> Along those lines and in an effort to be a bit less doom-and-gloom, I spent
> my lunch break trying to find non-marketing documentation on the Galera
> replication protocol and how it is exposed. (It was surprisingly difficult
> to find such information *)
> 
> It's easy to get the transaction ID of the last commit
> (wsrep_last_committed), but I can't find a way to wait until at least a
> particular transaction ID has been synced.  If we can find that latter
> functionality, then we can expose that sequencer all the way through (HTTP
> header?) and then any follow-on commands can mention the sequencer of the
> previous write command that they really need to see the effects of.
> 
> In practice, this should lead to zero additional wait time, since the
> Galera replication has almost certainly already caught up by the time the
> second command comes in - and we can just read from the local server with
> no additional delay.
> 
> See the various *Index variables in the etcd API, for how the same idea
> gets used there.
> 
>  - Gus
> 
> (*) In case you're also curious, the only doc I found with any details was
> http://galeracluster.com/documentation-webpages/certificationbasedreplication.html
> and its sibling pages.

My fear with something like this is that this is already a very hard
problem to get correct and this would be adding a fair amount of
complexity client side to achieve this. There is also an issue in that
this would a gelera-specific solution which means well be adding another
dimension to our feature testing matrix if we really wanted to support
it.

IMO we *really* do not want to be in the business of writing distrubuted
locking systems, but rather should be finding a way to either not
require them or rely on existing solutions.

__
OpenStack Development Mailing 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][oslo.db][nova] TL; DR Things everybody should know about Galera

[Angus Lees]

On Fri Feb 06 2015 at 12:59:13 PM Gregory Haynes 
wrote:

> Excerpts from Joshua Harlow's message of 2015-02-06 01:26:25 +:
> > Angus Lees wrote:
> > > On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum  > > > wrote:
> > > I'd also like to see consideration given to systems that handle
> > > distributed consistency in a more active manner. etcd and
> Zookeeper are
> > > both such systems, and might serve as efficient guards for critical
> > > sections without raising latency.
> > >
> > >
> > > +1 for moving to such systems.  Then we can have a repeat of the above
> > > conversation without the added complications of SQL semantics ;)
> > >
> >
> > So just an fyi:
> >
> > http://docs.openstack.org/developer/tooz/ exists.
> >
> > Specifically:
> >
> > http://docs.openstack.org/developer/tooz/developers.
> html#tooz.coordination.CoordinationDriver.get_lock
> >
> > It has a locking api that it provides (that plugs into the various
> > backends); there is also a WIP https://review.openstack.org/#/c/151463/
> > driver that is being worked for etc.d.
> >
>
> An interesting note about the etcd implementation is that you can
> select per-request whether you want to wait for quorum on a read or not.
> This means that in theory you could obtain higher throughput for most
> operations which do not require this and then only gain quorum for
> operations which require it (e.g. locks).
>

Along those lines and in an effort to be a bit less doom-and-gloom, I spent
my lunch break trying to find non-marketing documentation on the Galera
replication protocol and how it is exposed. (It was surprisingly difficult
to find such information *)

It's easy to get the transaction ID of the last commit
(wsrep_last_committed), but I can't find a way to wait until at least a
particular transaction ID has been synced.  If we can find that latter
functionality, then we can expose that sequencer all the way through (HTTP
header?) and then any follow-on commands can mention the sequencer of the
previous write command that they really need to see the effects of.

In practice, this should lead to zero additional wait time, since the
Galera replication has almost certainly already caught up by the time the
second command comes in - and we can just read from the local server with
no additional delay.

See the various *Index variables in the etcd API, for how the same idea
gets used there.

 - Gus

(*) In case you're also curious, the only doc I found with any details was
http://galeracluster.com/documentation-webpages/certificationbasedreplication.html
and its sibling pages.
__
OpenStack Development Mailing 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] [heat] Resource CREATE failed with TypeError

[Qiming Teng]

Hi,

Just checked your template.  It seems your SoftwareDeployment resource
is not referencing the SoftwareConfig resource properly.  A
SoftwareDeployment 'binds' a SoftwareConfig to a Server.  Without that
'binding', the template won't work as expected.

I'll follow up on this checking if Heat should validate that the
'config' property of a SoftwareDeployment is set.

Regards,
  Qiming

On Wed, Feb 04, 2015 at 07:23:10AM +, Zhou, Zhenzan wrote:
> Hi, Experts
> 
> I am writing a template to start a multi node devstack cloud inside 
> overcloud. Heat Engine got exception after started the first controller VM. I 
> am using the latest Heat code.
> Here is the stack trace:
> 
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 ERROR oslo_messaging.rpc.dispatcher 
> [req-f8fbb6d4-924d-4c0c-8b60-16ed30358765 ] Exception during message 
> handling: object of type 'NoneType' has no len()
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher Traceback 
> (most recent call last):
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
> "/opt/stack/venvs/heat/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
>  line 142, in _dispatch_and_reply
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher 
> executor_callback))
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
> "/opt/stack/venvs/heat/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
>  line 186, in _dispatch
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher 
> executor_callback)
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
> "/opt/stack/venvs/heat/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
>  line 130, in _do_dispatch
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher result 
> = func(ctxt, **new_args)
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
> "/opt/stack/venvs/heat/local/lib/python2.7/site-packages/osprofiler/profiler.py",
>  line 105, in wrapper
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher return 
> f(*args, **kwargs)
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
> "/opt/stack/venvs/heat/local/lib/python2.7/site-packages/heat/engine/service.py",
>  line 74, in wrapped
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher return 
> func(self, ctx, *args, **kwargs)
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
> "/opt/stack/venvs/heat/local/lib/python2.7/site-packages/heat/engine/service.py",
>  line 1386, in show_software_config
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher sc = 
> db_api.software_config_get(cnxt, config_id)
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
> "/opt/stack/venvs/heat/local/lib/python2.7/site-packages/heat/db/api.py", 
> line 258, in software_config_get
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher return 
> IMPL.software_config_get(context, config_id)
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
> "/opt/stack/venvs/heat/local/lib/python2.7/site-packages/heat/db/sqlalchemy/api.py",
>  line 717, in software_config_get
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher result 
> = model_query(context, models.SoftwareConfig).get(config_id)
> Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
> 2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
> "/opt/stack/ven

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

[Gregory Haynes]

Excerpts from Joshua Harlow's message of 2015-02-06 01:26:25 +:
> Angus Lees wrote:
> > On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum  > > wrote:
> > I'd also like to see consideration given to systems that handle
> > distributed consistency in a more active manner. etcd and Zookeeper are
> > both such systems, and might serve as efficient guards for critical
> > sections without raising latency.
> >
> >
> > +1 for moving to such systems.  Then we can have a repeat of the above
> > conversation without the added complications of SQL semantics ;)
> >
> 
> So just an fyi:
> 
> http://docs.openstack.org/developer/tooz/ exists.
> 
> Specifically:
> 
> http://docs.openstack.org/developer/tooz/developers.html#tooz.coordination.CoordinationDriver.get_lock
> 
> It has a locking api that it provides (that plugs into the various 
> backends); there is also a WIP https://review.openstack.org/#/c/151463/ 
> driver that is being worked for etc.d.
> 

An interesting note about the etcd implementation is that you can
select per-request whether you want to wait for quorum on a read or not.
This means that in theory you could obtain higher throughput for most
operations which do not require this and then only gain quorum for
operations which require it (e.g. locks).

__
OpenStack Development Mailing 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][oslo.db][nova] TL; DR Things everybody should know about Galera

[Joshua Harlow]

Angus Lees wrote:

On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum mailto:cl...@fewbar.com>> wrote:

In a single thread, using a single database session, then a read after
successful commit is guaranteed to read a version of the database
that existed after that commit.


Ah, I'm relieved to hear this clarification - thanks.

I'd like to see actual examples where that will matter. Meanwhile making
all selects wait for the cluster will basically just ruin responsiveness
and waste tons of time, so we should be careful to think this through
before making any blanket policy.


Matthew's example earlier in the thread is simply a user issuing two
related commands in succession:

$ nova aggregate-create
$ nova aggregate-details

Once that fails a few times, the user will put a poorly commented "sleep
2" in between the two statements, and this will "fix" the problem most
of the time.  A "better" fix would repeat the aggregate-details query
multiple times until it looks like it has found the previous create.

Now, that sleep or poll is of course a poor version of something you
could do at a lower level, by waiting for reads+writes to propagate to a
majority quorum.

I'd also like to see consideration given to systems that handle
distributed consistency in a more active manner. etcd and Zookeeper are
both such systems, and might serve as efficient guards for critical
sections without raising latency.


+1 for moving to such systems.  Then we can have a repeat of the above
conversation without the added complications of SQL semantics ;)



So just an fyi:

http://docs.openstack.org/developer/tooz/ exists.

Specifically:

http://docs.openstack.org/developer/tooz/developers.html#tooz.coordination.CoordinationDriver.get_lock

It has a locking api that it provides (that plugs into the various 
backends); there is also a WIP https://review.openstack.org/#/c/151463/ 
driver that is being worked for etc.d.


-Josh


  - Gus

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


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

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

[Angus Lees]

On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum  wrote:
>
> In a single thread, using a single database session, then a read after
> successful commit is guaranteed to read a version of the database
> that existed after that commit.
>

Ah, I'm relieved to hear this clarification - thanks.

I'd like to see actual examples where that will matter. Meanwhile making
> all selects wait for the cluster will basically just ruin responsiveness
> and waste tons of time, so we should be careful to think this through
> before making any blanket policy.
>

Matthew's example earlier in the thread is simply a user issuing two
related commands in succession:

$ nova aggregate-create
$ nova aggregate-details

Once that fails a few times, the user will put a poorly commented "sleep 2"
in between the two statements, and this will "fix" the problem most of the
time.  A "better" fix would repeat the aggregate-details query multiple
times until it looks like it has found the previous create.

Now, that sleep or poll is of course a poor version of something you could
do at a lower level, by waiting for reads+writes to propagate to a majority
quorum.

I'd also like to see consideration given to systems that handle
> distributed consistency in a more active manner. etcd and Zookeeper are
> both such systems, and might serve as efficient guards for critical
> sections without raising latency.
>

+1 for moving to such systems.  Then we can have a repeat of the above
conversation without the added complications of SQL semantics ;)

 - Gus
__
OpenStack Development Mailing 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] stuck patches at the nova IRC meeting

[Michael Still]

Certainly it was my intent when I created that agenda item to cover
reviews that wouldn't otherwise reach a decision -- either two cores
wedged, or something else that we can't resolve trivially in gerrit.

Now, I can see that people don't like reviews sitting for a long time,
but that's probably too long a list to cover in an IRC meeting. I'm
not opposed to trying, but we should set expectations that we're going
to talk about only a few important reviews, not the dozens that are
unloved.

Michael

On Fri, Feb 6, 2015 at 9:27 AM, Tony Breeds  wrote:
> On Thu, Feb 05, 2015 at 11:13:50PM +0100, Sylvain Bauza wrote:
>
>> I was always considering stuck reviews as reviews where 2 or more cores were
>> disagreeing between themselves so that it was needing a debate discussion
>> during the meeting.
>
> I was under the same impression.
>
> Stuck reviews were for reviewws were there was strong disagreement (amongst
> cores)
> Other reviews can be discussed as part of "Open discussion"
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Rackspace Australia

__
OpenStack Development Mailing 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] looking for status of an old wiki page work item

[Salvatore Orlando]

I reckon the blueprint [1] supersedes the one in the old wiki page you
found.
It lies in abandoned status as it did not make the release plan for Kilo. I
am sure the author and the other contributors working on it will resume it
for the next release.

Salvatore

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

On 5 February 2015 at 22:52, Ryan Moats  wrote:

> I've run into a set of use cases where it would really be useful to be
> able to restrict which external networks a particular tenant can access,
> along the lines of the wiki page [1] talks about..
>
> When I checked for neutron blueprints, the only thing I found was [2] and
> that isn't really close.
>
> So, I'm wondering if there is a blueprint that I missed when I went
> searching or if there are folks that would be interested in seeing along
> the lines of [1] getting implemented...
>
> Thanks in advance,
> Ryan Moats
>
> [1]
> https://wiki.openstack.org/wiki/Neutron/sharing-model-for-external-networks
> [2]
> https://blueprints.launchpad.net/neutron/+spec/external-shared-net-ext-for-nuage-plugin
>
>
> __
> OpenStack Development Mailing 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] FFE request for https://review.openstack.org/#/c/141012 https://blueprints.launchpad.net/openstack/?searchtext=pass-flavor-capabilities-to-ironic-virt-driver

[Nisha Agarwal]

Hi,

FFE request for the patch https://review.openstack.org/#/c/141012.

This is required by other items in ironic namely:
https://review.openstack.org/#/c/135228/6/specs/kilo/uefi-secure-boot.rst.


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

Re: [openstack-dev] [kolla][tripleo] Update on Kolla

[Steven Dake (stdake)]

Angus,

I think the appropriate place would be the openstack list, possibly with the 
[container] flag or [kolla] flag.

Regards
-steve


From: Angus Lees mailto:g...@inodes.org>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, February 5, 2015 at 4:02 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla][tripleo] Update on Kolla

Without taking anything away from this fine and sensible direction, where 
_would_ be a good place to discuss more radical container-based deployments?
(I'm fine if the answer is "use ad-hoc communication channels for now")

On Fri Feb 06 2015 at 7:24:12 AM Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:

On 2/5/15, 10:41 AM, "Paul Bourke" 
mailto:paul.bou...@oracle.com>> wrote:

>Hi Steve,
>
>Thanks for the update.  For those interested in Kolla development and
>discussion, where is the best place to go?
>
>Regards,
>-Paul

Paul,

We hang out in the irc channel #tripleo on freenode.

We use launchpad at http://launchpad.net/kolla

We use the openstack-dev mailing list with the tag [kolla]

Regards,
-steve



>
>On 05/02/15 17:25, Steven Dake (stdake) wrote:
>> Hey folks,
>>
>> I wanted to provide a brief update on where we are headed with Kolla.
>>   Initially Kolla began as a POC to show that containers could be used
>> to deploy OpenStack with the long term plan of integrating that
>> functionality into TripleO.  That goal has not changed.
>>
>> The tripleo community wants baby steps not outright replacement of the
>> infrastructure as was proposed by using Kubernetes in Kolla as a
>> dependency in this review [1].   Our first step in this process will be
>> to create three new container types.  We will create a controller node,
>> a storage node, and a compute node.  We have proven that compute can be
>> used.[2]  Further, one of our community members is working on a DIB
>> elements->container tool here [3] and we plan to use this along with our
>> other R&D in the area to integrate container tech into tripleo.
>>
>> I¹m not quite sure how it will all come together, but after numerous
>> discussions with folks from the tripleo and heat teams, I believe we can
>> find a path forward.
>>
>> Regards
>> -steve
>>
>>
>> [1] https://review.openstack.org/#/c/144199/
>> [2]
>>
>>http://sdake.io/2015/01/28/an-atomic-upgrade-process-for-openstack-comput
>>e-nodes/
>> _[3] _https://review.openstack.org/#/c/152017/
>>
>>
>>
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: 
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [nova] Hypervisor support matrix now in GIT

[Kurt Taylor]

On Thu, Feb 5, 2015 at 10:46 AM, Daniel P. Berrange 
wrote:

> On Thu, Feb 05, 2015 at 10:24:24AM -0600, Kurt Taylor wrote:
> > On Thu, Feb 5, 2015 at 4:31 AM, Daniel P. Berrange 
> > wrote:
> >
> > > Hi Team Nova,
> > >
> > > This is a message to alert everyone to the fact that the old hypervisor
> > > support matrix on the wiki[1], should really be considered obsolete.
> > >
> > > The canonical location for it going forward will be
> > >
> > >http://docs.openstack.org/developer/nova/support-matrix.html
> > >
> > > That URL shows current GIT snapshot, releases will get their own URL
> > > when the time comes.
> > >
> > > The source for this document is part of Nova GIT in the path
> > >
> > >doc/source/support-matrix.ini
> > >
> > > The docs are auto-generated from that ini file using a sphinx extension
> > >
> > >doc/ext/support_matrix.py
> > >
> > > The CSS styling is in
> > >
> > >doc/source/_static/support-matrix.css
> > >
> > > Some things to note here
> > >
> > >  - The new doc was populated based on the contents of the old wiki page
> > > from
> > >about two months ago, so if there have been additions to the wiki in
> > > that
> > >time, they might not all have been captured - depends how good I
> was at
> > >figuring out changes.
> > >
> > >  - Improvements to the content and/or HTML styling should obviously be
> sent
> > >as patches to Nova GIT in the files mentioned above, via normal
> Gerrit
> > >review practice.
> > >
> > >  - Since it is in GIT, the support matrix is now able to record
> information
> > >per release branch of Nova. So users can be clear about what
> features
> > >their release of Nova supports, as opposed to playing guessing
> games.
> > >
> > >  - The in-tree document only covers features of the in-tree Nova
> drivers.
> > >As such it does not include information about Docker or PowerKVM or
> > >the (now deleted) BareMetal drivers. My currently suggestion is that
> > >people maintaining out of tree drivers, should reuse the sphinx
> > > extension
> > >to format their own support matrix ini file in their local GIT repo.
> > >
> >
> > I think that maybe you have confused PowerKVM with PowerVM.  The PowerVM
> > driver was removed, but PowerKVM support is in tree with libvirt.
>
> Ok, so the wiki page was indeed referring to the libvirt impl. That wasn't
> obvious since it didn't mention libvirt in the heading as all the other
> libvirt columns did ! Sorry for not copying across your data then.
>
> Regards,
> Daniel
>

No problem at all, here's the patch to add it:

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

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

Re: [openstack-dev] [kolla][tripleo] Update on Kolla

[Angus Lees]

Without taking anything away from this fine and sensible direction, where
_would_ be a good place to discuss more radical container-based deployments?
(I'm fine if the answer is "use ad-hoc communication channels for now")

On Fri Feb 06 2015 at 7:24:12 AM Steven Dake (stdake) 
wrote:

>
> On 2/5/15, 10:41 AM, "Paul Bourke"  wrote:
>
> >Hi Steve,
> >
> >Thanks for the update.  For those interested in Kolla development and
> >discussion, where is the best place to go?
> >
> >Regards,
> >-Paul
>
> Paul,
>
> We hang out in the irc channel #tripleo on freenode.
>
> We use launchpad at http://launchpad.net/kolla
>
> We use the openstack-dev mailing list with the tag [kolla]
>
> Regards,
> -steve
>
>
>
> >
> >On 05/02/15 17:25, Steven Dake (stdake) wrote:
> >> Hey folks,
> >>
> >> I wanted to provide a brief update on where we are headed with Kolla.
> >>   Initially Kolla began as a POC to show that containers could be used
> >> to deploy OpenStack with the long term plan of integrating that
> >> functionality into TripleO.  That goal has not changed.
> >>
> >> The tripleo community wants baby steps not outright replacement of the
> >> infrastructure as was proposed by using Kubernetes in Kolla as a
> >> dependency in this review [1].   Our first step in this process will be
> >> to create three new container types.  We will create a controller node,
> >> a storage node, and a compute node.  We have proven that compute can be
> >> used.[2]  Further, one of our community members is working on a DIB
> >> elements->container tool here [3] and we plan to use this along with our
> >> other R&D in the area to integrate container tech into tripleo.
> >>
> >> I¹m not quite sure how it will all come together, but after numerous
> >> discussions with folks from the tripleo and heat teams, I believe we can
> >> find a path forward.
> >>
> >> Regards
> >> -steve
> >>
> >>
> >> [1] https://review.openstack.org/#/c/144199/
> >> [2]
> >>
> >>http://sdake.io/2015/01/28/an-atomic-upgrade-process-for-
> openstack-comput
> >>e-nodes/
> >> _[3] _https://review.openstack.org/#/c/152017/
> >>
> >>
> >>
> >>__
> ___
> >>_
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >___
> ___
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] looking for status of an old wiki page work item

[Ryan Moats]

I've run into a set of use cases where it would really be useful to be able
to restrict which external networks a particular tenant can access, along
the lines of the wiki page [1] talks about..

When I checked for neutron blueprints, the only thing I found was [2] and
that isn't really close.

So, I'm wondering if there is a blueprint that I missed when I went
searching or if there are folks that would be interested in seeing along
the lines of [1] getting implemented...

Thanks in advance,
Ryan Moats

[1]
https://wiki.openstack.org/wiki/Neutron/sharing-model-for-external-networks
[2]
https://blueprints.launchpad.net/neutron/+spec/external-shared-net-ext-for-nuage-plugin
__
OpenStack Development Mailing 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] devstack unable to install SQLAlchemy

[Sean Dague]

No, it's too new. Devstack in master is fixed to address those issues.

Supporting instructions that include out of tree patches in the
instructions are beyond what should be expected of from the development
list. The Intel folks that built these instructions and patches are the
ones you should be asking for support.

-Sean

On 02/05/2015 05:26 PM, Roman Mashak wrote:
> Thanks for response.
> I have pip 6.0.8, is it too old? What version should I install to move
> on with installation?
> 
> 2015-02-05 16:44 GMT-05:00 Sean Dague :
>> On 02/05/2015 04:05 PM, Roman Mashak wrote:
>>> Hello,
>>>
>>> OS - Fedora 20.
>>>
>>> I'm in the process of integrating DPDK-accelerated Open vSwitch with
>>> OpenStack, according to the following document
>>> https://01.org/sites/default/files/page/accelerating_openstack_networking_with_intel_architecture_rev008.pdf
>>>
>>> % git clone https://github.com/openstack-dev/devstack.git
>>> % cd devstack
>>> % git checkout 7eac0c927ca95fe3f6457b52d701a010a7e65123
>>> % git clone https://github.com/openstack/nova.git
>>> % cd nova
>>> % git checkout b7738bfb6c2f271d047e8f20c0b74ef647367111
>>>
>>> Then both nova and devstack must be patched with patches to support DPDK.
>>
>> Any set of instructions that require specific git SHA then patch them of
>> both devstack and nova are fragile beyond all repair. Perhaps someone
>> from Intel can explain why that's the prefered install method.
>>
>> The issue you are hitting is due to pip upgrades that happened over
>> Christmas, you have to be on the latest code to get past them (there
>> were a number of fixes that had to be pulled together), which means the
>> Intel instructions are incompatible with a working installation at this
>> time.
>>
>>>
>>> However I'm getting the following error when running stack.sh:
>>>
>>> 2015-02-05 20:06:21.284 | Collecting
>>> SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from
>>> nova===2014.2.1.dev1.gb7738bf)
>>> 2015-02-05 20:06:21.767 |   Could not find a version that satisfies
>>> the requirement SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from
>>> nova===2014.2.1.dev1.gb7738bf) (from versions: 0.4.2p3, 0.4.7p1,
>>> 0.5.4p1, 0.5.4p2, 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6,
>>> 0.1.7, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 0.2.7, 0.2.8,
>>> 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9,
>>> 0.3.10, 0.3.11, 0.4.0b1, 0.4.0b2, 0.4.0b3, 0.4.0b4, 0.4.0b5, 0.4.0b6,
>>> 0.4.0, 0.4.1, 0.4.2a0, 0.4.2b0, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6,
>>> 0.4.7, 0.4.8, 0.5.0b1, 0.5.0b2, 0.5.0b3, 0.5.0rc1, 0.5.0rc2, 0.5.0rc3,
>>> 0.5.0rc4, 0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.5.5, 0.5.6, 0.5.7,
>>> 0.5.8, 0.6b1, 0.6b2, 0.6b3, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.6.5,
>>> 0.6.6, 0.6.7, 0.6.8, 0.6.9, 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.7.5,
>>> 0.7.6, 0.7.7, 0.7.8, 0.7.9, 0.7.10, 0.8.0b2, 0.8.0, 0.8.1, 0.8.2,
>>> 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4,
>>> 0.9.5, 0.9.6, 0.9.7, 0.9.8)
>>> 2015-02-05 20:06:21.770 |   No distributions matching the version for
>>> SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from
>>> nova===2014.2.1.dev1.gb7738bf)
>>>
>>> I tried manually remove sqlalchemy with 'pip uninstall', as well as
>>> remove SQLAlchemy RPM package that might conflict. This didn't help
>>> though.
>>>
>>> This is string from /opt/stack/requirements/global-requirements.txt:
>>>
>>> SQLAlchemy>=0.8.4,<=0.9.99,!=0.9.0,!=0.9.1,!=0.9.2,!=0.9.3,!=0.9.4,!=0.9.5,!=0.9.6
>>>
>>> I also completely removed /opt/stack/requirements/, then unstack.sh
>>> and stack.sh again -- didn't help either.
>>>
>>> What else I'm missing?
>>> Thanks.
>>>
>>
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> 


-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Trove] Core reviewer update

[McReynolds, Auston]

+1

welcome aboard peter + victoria + edmond!

From: Nikhil Manchanda mailto:slick...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, February 5, 2015 at 8:26 AM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Trove] Core reviewer update

Hello Trove folks:

Keeping in line with other OpenStack projects, and attempting to keep
the momentum of reviews in Trove going, we need to keep our core-team up
to date -- folks who are regularly doing good reviews on the code should
be brought in to core and folks whose involvement is dropping off should
be considered for removal since they lose context over time, not being
as involved.

For this update I'm proposing the following changes:
- Adding Peter Stachowski (peterstac) to trove-core
- Adding Victoria Martinez De La Cruz (vkmc) to trove-core
- Adding Edmond Kotowski (edmondk) to trove-core
- Removing Michael Basnight (hub_cap) from trove-core
- Removing Tim Simpson (grapex) from trove-core

For context on Trove reviews and who has been active, please see
Russell's stats for Trove at:
- http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
- http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

Trove-core members -- please reply with your vote on each of these
proposed changes to the core team. Peter, Victoria and Eddie -- please
let me know of your willingness to be in trove-core. Michael, and Tim --
if you are planning on being substantially active on Trove in the near
term, also please do let me know.

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

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

[Tony Breeds]

On Thu, Feb 05, 2015 at 11:13:50PM +0100, Sylvain Bauza wrote:

> I was always considering stuck reviews as reviews where 2 or more cores were
> disagreeing between themselves so that it was needing a debate discussion
> during the meeting.

I was under the same impression.

Stuck reviews were for reviewws were there was strong disagreement (amongst
cores)
Other reviews can be discussed as part of "Open discussion"

Yours Tony.


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

Re: [openstack-dev] devstack unable to install SQLAlchemy

[Roman Mashak]

Thanks for response.
I have pip 6.0.8, is it too old? What version should I install to move
on with installation?

2015-02-05 16:44 GMT-05:00 Sean Dague :
> On 02/05/2015 04:05 PM, Roman Mashak wrote:
>> Hello,
>>
>> OS - Fedora 20.
>>
>> I'm in the process of integrating DPDK-accelerated Open vSwitch with
>> OpenStack, according to the following document
>> https://01.org/sites/default/files/page/accelerating_openstack_networking_with_intel_architecture_rev008.pdf
>>
>> % git clone https://github.com/openstack-dev/devstack.git
>> % cd devstack
>> % git checkout 7eac0c927ca95fe3f6457b52d701a010a7e65123
>> % git clone https://github.com/openstack/nova.git
>> % cd nova
>> % git checkout b7738bfb6c2f271d047e8f20c0b74ef647367111
>>
>> Then both nova and devstack must be patched with patches to support DPDK.
>
> Any set of instructions that require specific git SHA then patch them of
> both devstack and nova are fragile beyond all repair. Perhaps someone
> from Intel can explain why that's the prefered install method.
>
> The issue you are hitting is due to pip upgrades that happened over
> Christmas, you have to be on the latest code to get past them (there
> were a number of fixes that had to be pulled together), which means the
> Intel instructions are incompatible with a working installation at this
> time.
>
>>
>> However I'm getting the following error when running stack.sh:
>>
>> 2015-02-05 20:06:21.284 | Collecting
>> SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from
>> nova===2014.2.1.dev1.gb7738bf)
>> 2015-02-05 20:06:21.767 |   Could not find a version that satisfies
>> the requirement SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from
>> nova===2014.2.1.dev1.gb7738bf) (from versions: 0.4.2p3, 0.4.7p1,
>> 0.5.4p1, 0.5.4p2, 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6,
>> 0.1.7, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 0.2.7, 0.2.8,
>> 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9,
>> 0.3.10, 0.3.11, 0.4.0b1, 0.4.0b2, 0.4.0b3, 0.4.0b4, 0.4.0b5, 0.4.0b6,
>> 0.4.0, 0.4.1, 0.4.2a0, 0.4.2b0, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6,
>> 0.4.7, 0.4.8, 0.5.0b1, 0.5.0b2, 0.5.0b3, 0.5.0rc1, 0.5.0rc2, 0.5.0rc3,
>> 0.5.0rc4, 0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.5.5, 0.5.6, 0.5.7,
>> 0.5.8, 0.6b1, 0.6b2, 0.6b3, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.6.5,
>> 0.6.6, 0.6.7, 0.6.8, 0.6.9, 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.7.5,
>> 0.7.6, 0.7.7, 0.7.8, 0.7.9, 0.7.10, 0.8.0b2, 0.8.0, 0.8.1, 0.8.2,
>> 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4,
>> 0.9.5, 0.9.6, 0.9.7, 0.9.8)
>> 2015-02-05 20:06:21.770 |   No distributions matching the version for
>> SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from
>> nova===2014.2.1.dev1.gb7738bf)
>>
>> I tried manually remove sqlalchemy with 'pip uninstall', as well as
>> remove SQLAlchemy RPM package that might conflict. This didn't help
>> though.
>>
>> This is string from /opt/stack/requirements/global-requirements.txt:
>>
>> SQLAlchemy>=0.8.4,<=0.9.99,!=0.9.0,!=0.9.1,!=0.9.2,!=0.9.3,!=0.9.4,!=0.9.5,!=0.9.6
>>
>> I also completely removed /opt/stack/requirements/, then unstack.sh
>> and stack.sh again -- didn't help either.
>>
>> What else I'm missing?
>> Thanks.
>>
>
>
> --
> Sean Dague
> http://dague.net
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Roman Mashak

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

Re: [openstack-dev] [horizon][keystone]

[Thai Q Tran]

Marek,Yep, that makes a lot of sense. Can definitely add that.-Marek Denis  wrote: -To: From: Marek Denis Date: 02/05/2015 01:35PMSubject: Re: [openstack-dev] [horizon][keystone]
  

  
  
Thai,
  
  We could also add an option in the Horizon's settings that
  automatically chooses one authentication workflow. At CERN we are
  trying to use websso with use of the SAML2 protocols as much as we
  can. That's said we automatically make users to use websso when
  they want to access their accounts via the dashboard. 
  
  Hint: This is being done by automatic redirect to predefined
  Keystone endpoint once user hits our dashboard's URL).
  
  Marek
  
  
  On 05.02.2015 20:15, Thai Q Tran wrote:


  
  Hi Ioram,
Thanks for the feedback. I agree that the names are hard to
follow, they can change to something more intuitive. Or we can
even provide a tooltip for more information.
As for the look and feel, I don't agree that its easier if all
the options are listed. Image if you had 5 different ways for
users to log in and they are all shown at once. That's a lot to
take in.
This approach keep things simply, it's really not that hard to
pick from a list.

Hi Anton,
I'm just building on top of the visuals we already have without
changing things too drastically. If you have a better idea, I
would love to see it.

-Ioram Schechtman Sette
   wrote: -

  To: "OpenStack Development Mailing List (not for
usage questions)" 
From: Ioram Schechtman Sette 
Date: 02/05/2015 03:15AM
Subject: Re: [openstack-dev] [horizon][keystone]


  

  

  

  
Hi Thai,
  
  I agree with Anton that the names are not
  intuitive for users.
  

I would use something like:
  
  - Local authentication (for local credentials)

- ?? (I also have no idea of what is a Default
protocol)
  
  - Authenticate using  (something which is easy to the
  user understand that he could use or not - this is
  for the discovery service or remote IdP)
  

Here in the University of Kent we used another
approach.
  
  Instead of selecting the method using a "list/combo"
  box, we present all the options in a single screen.

I think it's not beautiful, but functional.
  
  I think it would be easier to the user if they could have
  all the options in a single interface, since it doesn't
  become too much loaded (visually polluted).
  
  
  

  
Regards,
  Ioram


  

  

  

  

  2015-02-05
9:20 GMT+00:00 Anton Zemlyanov :

  Hi,


I guess "Credentials"
  is login and password. I
  have no idea what is
  "Default Protocol" or
  "Discovery Service".
The proposed UI is
  rather embarrassing.


Anton
  
  

  
On Thu,
  

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

[Sylvain Bauza]

Le 05/02/2015 17:54, Sean Dague a écrit :

On 02/05/2015 11:50 AM, Daniel P. Berrange wrote:

On Thu, Feb 05, 2015 at 10:42:48AM -0600, Ed Leafe wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/05/2015 09:02 AM, Alexis Lee wrote:


May I suggest stricter moderation? EG a short phase to propose
items, then work through them 1 by 1. Or, we take items one by one
according to who shouts fastest but ask people not to interrupt.

Or how about going through the ones listed on the agenda, rather than
having a free-for-all shouting match?

Indeed, I thought that was the whole point of putting them in the
agenda in the first place :-)

Agreed, I think it just got away from us today with lots of first time
attendees. We'll just have to be a little clearer next time.

-Sean




I was always considering stuck reviews as reviews where 2 or more cores 
were disagreeing between themselves so that it was needing a debate 
discussion during the meeting.


If we're only saying that 'stuck' means a review which hasn't been 
reviewed since a certain amount of time, then we will be having lots of 
people jumping in to ask for a review, so it would be counterproductive.


-Sylvain


__
OpenStack Development Mailing 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] Kilo-2 development milestone available

[Thierry Carrez]

Hi everyone,

The second milestone of the Kilo development cycle, "kilo-2" is now
reached for the Kilo "integrated release" projects, Keystone, Glance,
Nova, Horizon, Neutron, Cinder, Ceilometer, Heat, Trove, Sahara, and
Ironic ! It contains all the new features and bugfixes that have been
added since the the Christmas holiday break.

You can find the full list of new features and fixed bugs, as well as
tarball downloads, at:

https://launchpad.net/keystone/kilo/kilo-2
https://launchpad.net/glance/kilo/kilo-2
https://launchpad.net/nova/kilo/kilo-2
https://launchpad.net/horizon/kilo/kilo-2
https://launchpad.net/neutron/kilo/kilo-2
https://launchpad.net/cinder/kilo/kilo-2
https://launchpad.net/ceilometer/kilo/kilo-2
https://launchpad.net/heat/kilo/kilo-2
https://launchpad.net/trove/kilo/kilo-2
https://launchpad.net/sahara/kilo/kilo-2
https://launchpad.net/ironic/kilo/kilo-2

84 blueprints were implemented and no less than 708 bugs were fixed
during this milestone (not including fixes that landed in Oslo libraries).

The next development milestone, kilo-3, is scheduled for March 19th, and
will coincide with the final feature freeze for integrated projects in
the Kilo cycle.

You can further track upcoming features and Kilo release cycle status
at: http://status.openstack.org/release/

Regards,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

[Davanum Srinivas]

LOL :)

-- dims

On Thu, Feb 5, 2015 at 4:22 PM, Matt Riedemann
 wrote:
>
>
> On 2/5/2015 10:54 AM, Sean Dague wrote:
>>
>> On 02/05/2015 11:50 AM, Daniel P. Berrange wrote:
>>>
>>> On Thu, Feb 05, 2015 at 10:42:48AM -0600, Ed Leafe wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 02/05/2015 09:02 AM, Alexis Lee wrote:

> May I suggest stricter moderation? EG a short phase to propose
> items, then work through them 1 by 1. Or, we take items one by one
> according to who shouts fastest but ask people not to interrupt.


 Or how about going through the ones listed on the agenda, rather than
 having a free-for-all shouting match?
>>>
>>>
>>> Indeed, I thought that was the whole point of putting them in the
>>> agenda in the first place :-)
>>
>>
>> Agreed, I think it just got away from us today with lots of first time
>> attendees. We'll just have to be a little clearer next time.
>>
>> -Sean
>>
>
> Lots of first time attendees on the day of feature freeze? Weird...
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

Re: [openstack-dev] [devstack]Cannot install devstack on CI slave

[Sean Dague]

Yes, we flipped to neutron default around that time, which appears to
have been premature. That's since been reverted -
https://review.openstack.org/#/c/153208/ and we'll make sure that it
works out of the box before it goes default again.

On 02/05/2015 07:20 AM, Eduard Matei wrote:
> Hi, 
> For two days i've been trying to install devstack.
> It keeps failing at configuring neutron, i figured out that it needs two
> new params in localrc: PUBLIC_NETWORK_GATEWAY and NETWORK_GATEWAY
> On my dev machine i managed to install it manually with these params,
> but on the CI slave it fails with error:
> 
> 2015-02-05 12:05:39.329 | + sudo route add -net 10.150.11.0/16 
>  gw 10.140.0.1
> 2015-02-05 12:05:39.440 | route: netmask doesn't match route address
> 
> 
> Localrc:
> 
> [[local|localrc]]
> HOST_IP=10.140.0.2
> FLAT_INTERFACE=eth0
> FIXED_RANGE=10.150.11.0/16  
> FIXED_NETWORK_SIZE=255
> FLOATING_RANGE=10.140.0.0/16  
> PUBLIC_NETWORK_GATEWAY=10.140.0.2
> NETWORK_GATEWAY=10.150.11.1
> MULTI_HOST=0
> SYSLOG=False
> SCREEN_LOGDIR=/opt/stack/logs/screen-logs
> LOGFILE=/opt/stack/logs/stack.sh.log
> ADMIN_PASSWORD=*
> MYSQL_PASSWORD=*
> RABBIT_PASSWORD=*
> SERVICE_PASSWORD=*
> SERVICE_TOKEN=*
> 
> 
> Anyone seen this error or has any idea what i should put in the config?
> 
> 
> Similar log (different values for localrc):
> 
> http://packages.cloudfounders.com/ci_logs/33/130733/40/check/openvstorage-cinder-functionality/ad97bc5/console.html
> 
> 
> Thanks,
> 
> Eduard
> 
> 
> PS. Why did nobody report this issue so far? Either i'm doing something wrong 
> in the localrc or nobody is installing the latest devstack. 
> https://bugs.launchpad.net/devstack/+bug/1417635
> 
> 
> -- 
> 
> *Eduard Biceri Matei, Senior Software Developer*
> www.cloudfounders.com 
>  | eduard.ma...@cloudfounders.com 
> __ __
> 
> __ __
> *CloudFounders, The Private Cloud Software Company*
> __ __
> Disclaimer:
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed.
> If you are not the named addressee or an employee or agent responsible
> for delivering this message to the named addressee, you are hereby
> notified that you are not authorized to read, print, retain, copy or
> disseminate this message or any part of it. If you have received this
> email in error we request you to notify us by reply e-mail and to delete
> all electronic files of the message. If you are not the intended
> recipient you are notified that disclosing, copying, distributing or
> taking any action in reliance on the contents of this information is
> strictly prohibited. 
> E-mail transmission cannot be guaranteed to be secure or error free as
> information could be intercepted, corrupted, lost, destroyed, arrive
> late or incomplete, or contain viruses. The sender therefore does not
> accept liability for any errors or omissions in the content of this
> message, and shall have no liability for any loss or damage suffered by
> the user, which arise as a result of e-mail transmission.
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net



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

Re: [openstack-dev] devstack unable to install SQLAlchemy

[Sean Dague]

On 02/05/2015 04:05 PM, Roman Mashak wrote:
> Hello,
> 
> OS - Fedora 20.
> 
> I'm in the process of integrating DPDK-accelerated Open vSwitch with
> OpenStack, according to the following document
> https://01.org/sites/default/files/page/accelerating_openstack_networking_with_intel_architecture_rev008.pdf
> 
> % git clone https://github.com/openstack-dev/devstack.git
> % cd devstack
> % git checkout 7eac0c927ca95fe3f6457b52d701a010a7e65123
> % git clone https://github.com/openstack/nova.git
> % cd nova
> % git checkout b7738bfb6c2f271d047e8f20c0b74ef647367111
> 
> Then both nova and devstack must be patched with patches to support DPDK.

Any set of instructions that require specific git SHA then patch them of
both devstack and nova are fragile beyond all repair. Perhaps someone
from Intel can explain why that's the prefered install method.

The issue you are hitting is due to pip upgrades that happened over
Christmas, you have to be on the latest code to get past them (there
were a number of fixes that had to be pulled together), which means the
Intel instructions are incompatible with a working installation at this
time.

> 
> However I'm getting the following error when running stack.sh:
> 
> 2015-02-05 20:06:21.284 | Collecting
> SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from
> nova===2014.2.1.dev1.gb7738bf)
> 2015-02-05 20:06:21.767 |   Could not find a version that satisfies
> the requirement SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from
> nova===2014.2.1.dev1.gb7738bf) (from versions: 0.4.2p3, 0.4.7p1,
> 0.5.4p1, 0.5.4p2, 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6,
> 0.1.7, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 0.2.7, 0.2.8,
> 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9,
> 0.3.10, 0.3.11, 0.4.0b1, 0.4.0b2, 0.4.0b3, 0.4.0b4, 0.4.0b5, 0.4.0b6,
> 0.4.0, 0.4.1, 0.4.2a0, 0.4.2b0, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6,
> 0.4.7, 0.4.8, 0.5.0b1, 0.5.0b2, 0.5.0b3, 0.5.0rc1, 0.5.0rc2, 0.5.0rc3,
> 0.5.0rc4, 0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.5.5, 0.5.6, 0.5.7,
> 0.5.8, 0.6b1, 0.6b2, 0.6b3, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.6.5,
> 0.6.6, 0.6.7, 0.6.8, 0.6.9, 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.7.5,
> 0.7.6, 0.7.7, 0.7.8, 0.7.9, 0.7.10, 0.8.0b2, 0.8.0, 0.8.1, 0.8.2,
> 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4,
> 0.9.5, 0.9.6, 0.9.7, 0.9.8)
> 2015-02-05 20:06:21.770 |   No distributions matching the version for
> SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from
> nova===2014.2.1.dev1.gb7738bf)
> 
> I tried manually remove sqlalchemy with 'pip uninstall', as well as
> remove SQLAlchemy RPM package that might conflict. This didn't help
> though.
> 
> This is string from /opt/stack/requirements/global-requirements.txt:
> 
> SQLAlchemy>=0.8.4,<=0.9.99,!=0.9.0,!=0.9.1,!=0.9.2,!=0.9.3,!=0.9.4,!=0.9.5,!=0.9.6
> 
> I also completely removed /opt/stack/requirements/, then unstack.sh
> and stack.sh again -- didn't help either.
> 
> What else I'm missing?
> Thanks.
> 


-- 
Sean Dague
http://dague.net



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

Re: [openstack-dev] [horizon][keystone]

[Marek Denis]

Thai,

We could also add an option in the Horizon's settings that automatically 
chooses one authentication workflow. At CERN we are trying to use websso 
with use of the SAML2 protocols as much as we can. That's said we 
automatically make users to use websso when they want to access their 
accounts via the dashboard.


Hint: This is being done by automatic redirect to predefined Keystone 
endpoint once user hits our dashboard's URL).


Marek


On 05.02.2015 20:15, Thai Q Tran wrote:

Hi Ioram,
Thanks for the feedback. I agree that the names are hard to follow, 
they can change to something more intuitive. Or we can even provide a 
tooltip for more information.
As for the look and feel, I don't agree that its easier if all the 
options are listed. Image if you had 5 different ways for users to log 
in and they are all shown at once. That's a lot to take in.
This approach keep things simply, it's really not that hard to pick 
from a list.


Hi Anton,
I'm just building on top of the visuals we already have without 
changing things too drastically. If you have a better idea, I would 
love to see it.


-Ioram Schechtman Sette  wrote: -
To: "OpenStack Development Mailing List (not for usage questions)" 


From: Ioram Schechtman Sette 
Date: 02/05/2015 03:15AM
Subject: Re: [openstack-dev] [horizon][keystone]

Hi Thai,

I agree with Anton that the names are not intuitive for users.

I would use something like:
- Local authentication (for local credentials)
- ?? (I also have no idea of what is a Default protocol)
- Authenticate using  (something which is 
easy to the user understand that he could use or not - this is for the 
discovery service or remote IdP)


Here in the University of Kent we used another approach.
Instead of selecting the method using a "list/combo" box, we present 
all the options in a single screen.

I think it's not beautiful, but functional.
I think it would be easier to the user if they could have all the 
options in a single interface, since it doesn't become too much loaded 
(visually polluted).


Imagem inline 1
Regards,
Ioram


2015-02-05 9:20 GMT+00:00 Anton Zemlyanov >:


Hi,

I guess "Credentials" is login and password. I have no idea what
is "Default Protocol" or "Discovery Service".
The proposed UI is rather embarrassing.

Anton

On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran mailto:tqt...@us.ibm.com>> wrote:

Hi all,

I have been helping with the websso effort and wanted to get
some feedback.
Basically, users are presented with a login screen where they
can select: credentials, default protocol, or discovery service.
If user selects credentials, it works exactly the same way it
works today.
If user selects default protocol or discovery service, they
can choose to be redirected to those pages.

Keep in mind that this is a prototype, early feedback will be
good.
Here are the relevant patches:
https://review.openstack.org/#/c/136177/
https://review.openstack.org/#/c/136178/
https://review.openstack.org/#/c/151842/

I have attached the files and present them below:






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



--
Marek Denis
[marek.de...@cern.ch]

__
OpenStack Development Mailing 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] stuck patches at the nova IRC meeting

[Matt Riedemann]

On 2/5/2015 10:54 AM, Sean Dague wrote:

On 02/05/2015 11:50 AM, Daniel P. Berrange wrote:

On Thu, Feb 05, 2015 at 10:42:48AM -0600, Ed Leafe wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/05/2015 09:02 AM, Alexis Lee wrote:


May I suggest stricter moderation? EG a short phase to propose
items, then work through them 1 by 1. Or, we take items one by one
according to who shouts fastest but ask people not to interrupt.


Or how about going through the ones listed on the agenda, rather than
having a free-for-all shouting match?


Indeed, I thought that was the whole point of putting them in the
agenda in the first place :-)


Agreed, I think it just got away from us today with lots of first time
attendees. We'll just have to be a little clearer next time.

-Sean



Lots of first time attendees on the day of feature freeze? Weird...

--

Thanks,

Matt Riedemann


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

[openstack-dev] debtcollector 0.1.0 released

[Joshua Harlow]

The Oslo team is pleased to announce the *initial* release of:

debtcollector 0.1.0: A collection of python patterns that help you
collect your technical debt in a non-destructive manner.

For more details, please see the git log history below and:

http://launchpad.net/debtcollector/+milestone/0.1

Please report issues through launchpad:

http://bugs.launchpad.net/debtcollector

Changes in debtcollector 2c4e7d58ddec0058f..0.1.0
-

b078a94 Upper case python
9f0f114 Fix up the docs into reasonable shape
3173337 Add a moved *instance* method deprecation pattern
b833207 Initial import of renames/moves + tests
493c200 Add a .gitreview file with correct values
715f46f Adjust summary of project

Diffstat (except docs and test files)
-

.gitreview|   4 +
README.rst|  16 ++--
debtcollector/__init__.py |   2 +-
debtcollector/_utils.py   |  61 
debtcollector/moves.py| 119 
debtcollector/renames.py  |  45 +
requirements.txt  |   4 +-
setup.py  |   2 +-
test-requirements.txt |   2 +-
18 files changed, 442 insertions(+), 65 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index bc7131e..7cc0111 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6,3 @@ pbr>=0.6,!=0.7,<1.0
-Babel>=1.3
\ No newline at end of file
+Babel>=1.3
+six>=1.7.0
+oslo.utils>=1.2.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 7b79352..d494076 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -15 +15 @@ testscenarios>=0.4
-testtools>=0.9.34
\ No newline at end of file
+testtools>=0.9.34


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

[openstack-dev] devstack unable to install SQLAlchemy

[Roman Mashak]

Hello,

OS - Fedora 20.

I'm in the process of integrating DPDK-accelerated Open vSwitch with
OpenStack, according to the following document
https://01.org/sites/default/files/page/accelerating_openstack_networking_with_intel_architecture_rev008.pdf

% git clone https://github.com/openstack-dev/devstack.git
% cd devstack
% git checkout 7eac0c927ca95fe3f6457b52d701a010a7e65123
% git clone https://github.com/openstack/nova.git
% cd nova
% git checkout b7738bfb6c2f271d047e8f20c0b74ef647367111

Then both nova and devstack must be patched with patches to support DPDK.

However I'm getting the following error when running stack.sh:

2015-02-05 20:06:21.284 | Collecting
SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from
nova===2014.2.1.dev1.gb7738bf)
2015-02-05 20:06:21.767 |   Could not find a version that satisfies
the requirement SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from
nova===2014.2.1.dev1.gb7738bf) (from versions: 0.4.2p3, 0.4.7p1,
0.5.4p1, 0.5.4p2, 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6,
0.1.7, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 0.2.7, 0.2.8,
0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9,
0.3.10, 0.3.11, 0.4.0b1, 0.4.0b2, 0.4.0b3, 0.4.0b4, 0.4.0b5, 0.4.0b6,
0.4.0, 0.4.1, 0.4.2a0, 0.4.2b0, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6,
0.4.7, 0.4.8, 0.5.0b1, 0.5.0b2, 0.5.0b3, 0.5.0rc1, 0.5.0rc2, 0.5.0rc3,
0.5.0rc4, 0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.5.5, 0.5.6, 0.5.7,
0.5.8, 0.6b1, 0.6b2, 0.6b3, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.6.5,
0.6.6, 0.6.7, 0.6.8, 0.6.9, 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.7.5,
0.7.6, 0.7.7, 0.7.8, 0.7.9, 0.7.10, 0.8.0b2, 0.8.0, 0.8.1, 0.8.2,
0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4,
0.9.5, 0.9.6, 0.9.7, 0.9.8)
2015-02-05 20:06:21.770 |   No distributions matching the version for
SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from
nova===2014.2.1.dev1.gb7738bf)

I tried manually remove sqlalchemy with 'pip uninstall', as well as
remove SQLAlchemy RPM package that might conflict. This didn't help
though.

This is string from /opt/stack/requirements/global-requirements.txt:

SQLAlchemy>=0.8.4,<=0.9.99,!=0.9.0,!=0.9.1,!=0.9.2,!=0.9.3,!=0.9.4,!=0.9.5,!=0.9.6

I also completely removed /opt/stack/requirements/, then unstack.sh
and stack.sh again -- didn't help either.

What else I'm missing?
Thanks.

-- 
Roman Mashak

__
OpenStack Development Mailing 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] [Trove] Core reviewer update

[Peter Stachowski]

Hi Nikhil et al.,

Thanks for the nomination!  I’m more than happy to join the core team and do 
all I can to help improve Trove and the community.  Also a +1 for the other 
nominations and sincere thanks for all the work hub_cap and grapex have done 
over the years.  Let’s keep the momentum going!

Thanks all!
Peter

From: Nikhil Manchanda [mailto:slick...@gmail.com]
Sent: February-05-15 8:27 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Trove] Core reviewer update

Hello Trove folks:

Keeping in line with other OpenStack projects, and attempting to keep
the momentum of reviews in Trove going, we need to keep our core-team up
to date -- folks who are regularly doing good reviews on the code should
be brought in to core and folks whose involvement is dropping off should
be considered for removal since they lose context over time, not being
as involved.

For this update I'm proposing the following changes:
- Adding Peter Stachowski (peterstac) to trove-core
- Adding Victoria Martinez De La Cruz (vkmc) to trove-core
- Adding Edmond Kotowski (edmondk) to trove-core
- Removing Michael Basnight (hub_cap) from trove-core
- Removing Tim Simpson (grapex) from trove-core

For context on Trove reviews and who has been active, please see
Russell's stats for Trove at:
- http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
- http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

Trove-core members -- please reply with your vote on each of these
proposed changes to the core team. Peter, Victoria and Eddie -- please
let me know of your willingness to be in trove-core. Michael, and Tim --
if you are planning on being substantially active on Trove in the near
term, also please do let me know.

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

Re: [openstack-dev] [Heat] Add extraroutes support to neutron routers

[Zane Bitter]

On 05/02/15 12:23, James Denton wrote:

Hello all,

Regarding
https://blueprints.launchpad.net/heat/+spec/router-properties-object

Does anyone know if there are plans to implement this functionality in
an upcoming release?


Unlikely - unfortunately the Neutron API for extra routes makes it 
impossible to implement correctly. That said, Kevin's code did land in 
/contrib, so the plugin is there if you need it:


http://git.openstack.org/cgit/openstack/heat/tree/contrib/extraroute

cheers,
Zane.


Our use case meets the one described by Kevin, but
rather than trying to route traffic to an outside resource, we are
routing to another instance off the router.

Thanks!

—
James Denton


__
OpenStack Development Mailing 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] [Trove] Core reviewer update

[Edmond Kotowski]

Everyone,
   I am honored for the nomination to be part of the Trove-Core
reviewers and am ready and willing to take on the responsibility.

Thanks,
   Eddie


>
>

>
> *From:* Nikhil Manchanda [mailto:slick...@gmail.com]
> *Sent:* February-05-15 8:27 AM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [Trove] Core reviewer update
>
>
>
> Hello Trove folks:
>
> Keeping in line with other OpenStack projects, and attempting to keep
> the momentum of reviews in Trove going, we need to keep our core-team up
> to date -- folks who are regularly doing good reviews on the code should
> be brought in to core and folks whose involvement is dropping off should
> be considered for removal since they lose context over time, not being
> as involved.
>
> For this update I'm proposing the following changes:
> - Adding Peter Stachowski (peterstac) to trove-core
> - Adding Victoria Martinez De La Cruz (vkmc) to trove-core
> - Adding Edmond Kotowski (edmondk) to trove-core
> - Removing Michael Basnight (hub_cap) from trove-core
> - Removing Tim Simpson (grapex) from trove-core
>
> For context on Trove reviews and who has been active, please see
> Russell's stats for Trove at:
> - http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
> - http://russellbryant.net/openstack-stats/trove-reviewers-90.txt
>
> Trove-core members -- please reply with your vote on each of these
> proposed changes to the core team. Peter, Victoria and Eddie -- please
> let me know of your willingness to be in trove-core. Michael, and Tim --
> if you are planning on being substantially active on Trove in the near
> term, also please do let me know.
>
> Thanks,
> Nikhil
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][tripleo] Update on Kolla

[Steven Dake (stdake)]

On 2/5/15, 10:41 AM, "Paul Bourke"  wrote:

>Hi Steve,
>
>Thanks for the update.  For those interested in Kolla development and
>discussion, where is the best place to go?
>
>Regards,
>-Paul

Paul,

We hang out in the irc channel #tripleo on freenode.

We use launchpad at http://launchpad.net/kolla

We use the openstack-dev mailing list with the tag [kolla]

Regards,
-steve



>
>On 05/02/15 17:25, Steven Dake (stdake) wrote:
>> Hey folks,
>>
>> I wanted to provide a brief update on where we are headed with Kolla.
>>   Initially Kolla began as a POC to show that containers could be used
>> to deploy OpenStack with the long term plan of integrating that
>> functionality into TripleO.  That goal has not changed.
>>
>> The tripleo community wants baby steps not outright replacement of the
>> infrastructure as was proposed by using Kubernetes in Kolla as a
>> dependency in this review [1].   Our first step in this process will be
>> to create three new container types.  We will create a controller node,
>> a storage node, and a compute node.  We have proven that compute can be
>> used.[2]  Further, one of our community members is working on a DIB
>> elements->container tool here [3] and we plan to use this along with our
>> other R&D in the area to integrate container tech into tripleo.
>>
>> I¹m not quite sure how it will all come together, but after numerous
>> discussions with folks from the tripleo and heat teams, I believe we can
>> find a path forward.
>>
>> Regards
>> -steve
>>
>>
>> [1] https://review.openstack.org/#/c/144199/
>> [2]
>> 
>>http://sdake.io/2015/01/28/an-atomic-upgrade-process-for-openstack-comput
>>e-nodes/
>> _[3] _https://review.openstack.org/#/c/152017/
>>
>>
>> 
>>_
>>_
>> OpenStack Development Mailing 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] fixed ip info shown for port even when dhcp is disabled

[Padmanabhan Krishnan]

 Thanks John and Salvatore. I can probably start a new thread on this or change 
the subject line if needed.

To add more:
Think of deployments in enterprise/DC where only a portion of it is Openstack 
(still migrating). Sure, the commercial external DHCP servers may have API's. 
But, the policy may be such that they don't want their DHCP servers to be 
"told" from Openstack, that for this , this is the IP address you 
need to assign. They may have their own centralized management tools for doing 
that.
And also, they may not have a way where they provide ways to "reserve" an IP 
address for this . By "reserve" i mean, something like telling 
the external DHCP server, you may get a DHCP request for this  in 
the future, give me the IP address that you will assign when such a request 
comes in the future. 
If they have a way to reserve, the proposed IPAM solution still works.

Thanks,
Paddu


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

Date: Thursday, February 5, 2015 8:46 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when 
dhcp is disabled

I have the feeling that the discussion is diverging a bit.
John is correctly stating that with pluggable IPAM it should be possible, in 
theory to write a driver which interfaces to any DHCP server, providing it the 
information it needs to distribute addresses assigned by Neutron. This is 
possible in theory even if the DHCP server does not expose any sort of API - as 
an example you might write a driver which writes into configuration files and 
then restarts or reloads the DHCP server as needed, which is not very different 
from what we do today with Dnsmasq.
However, it seems to me that the gist of Padmanabhan's question is whether 
neutron should allow completely out of band IP address management. Neutron is 
evolving in a direction where this would be possible only if one considers it 
as a simple service for building virtualised layer-2 segments. Unless some form 
of interaction with the entity which manages IPs is envisioned, it would not be 
possible to use neutron's security and routing services.Also, another aspect to 
factor in is nova. I have not checked this in a while, but I seem to recall it 
was not able to boot a VM with network interfaces if it did not obtain also IP 
addresses for such interfaces - and those IPs are indeed fetched from neutron's 
port info.If I got Padmanabhan's point right then we need to discuss if and how 
out of band address mgmt and distribution should be supported in Neutron.
Regards,Salvatore
On 5 February 2015 at 15:20, John Belamaric  wrote:

The pluggable IPAM [1] is intended to support the scenario you described below. 
That is, a fixed IP is provided for the port by IPAM, and then the DHCP server 
is programmed to return that IP for that MAC or DUID (for IPv6). If I 
understand correctly, your concern then is:
1) The DHCP server may not allow such programming;2) The DHCP server may not be 
able to provide an IP allocation via any means other than DHCP (ie, no API to 
pre-allocate the IP)
I would think then, what you are asking for is the ability to attach an 
interface to a layer 2 network without also giving it an IP in any subnet(s) 
that are on that network. Seems like a reasonable request, but I am not sure 
what would be involved in implementing that.
Additionally, we would need some mechanism to update the port with the IP after 
it is allocated via the DHCP server. Otherwise, I don't think all the iptables 
rules and such will be properly configured, so you probably won't be able to 
pass traffic beyond the local subnet. Not sure on that though.

[1] - 
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/neutron-ipam.html


From: Padmanabhan Krishnan 
Reply-To: Padmanabhan Krishnan 
Date: Thursday, February 5, 2015 at 1:47 AM
To: John Belamaric , "OpenStack Development Mailing 
List (not for usage questions)" 
Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when 
dhcp is disabled

Hi John,Sure, this may not be in the scope of IPAM as originally proposed in 
[1]. Am just trying to see if there can be a solution for this scenario using 
IPAM.
What I had in mind is also a centrally managed IPAM and not each VM allocating 
its own IP address. Let me clarify. It's not an uncommon requirement to use a 
commercial DHCP server in an enterprise/DC. I am referring to it as external 
DHCP server from Openstack's perspective.One scenario of deployment is when 
IPAM is done through Openstack and in which case, the  can be programmed in the external DHCP server, assuming they have 
standard API's for that. Then, the VM will get the openstack assigned IP 
address from the DHCP server when it boots up. You also suggested this and 
sure, it's not a problem here.
Now, another scenario and that's of interest is when IPAM itself is done 
direct

Re: [openstack-dev] [horizon] JavaScript docs?

[Aaron D Sahlin]

I agree with points made by both Matt and Radomir. 

We have guidelines for documenting code.   Any code.  (* I need to go see 
what our guidelines actually say)   But the goal is to have comments that 
are useful and make the code
easier to understand, follow and use. Comments should focus on "what 
and why" vs "how".Some files are trivial, but I always appreciated 
having file level comments describing
the purpose of this file.   Then having method level comments for 
non-trivial methods, and so forth down to code blocks. This is how 
projects I have worked on in the past have commented 
so fellow team members could pick up the code and quickly get caught up to 
speed and contribute by just reading the code. 

Now that I am done rambling on comment content   As far as structure 
it would be nice to follow convention and use JSDoc or ngDoc for 
JavaScript files. 


Aaron D. Sahlin
IBMUSM07(asahlin)
Dept. X2WA
Phone 507-253-7349 Tie 553-7349




From:   Matthew Farina 
To: "OpenStack Development Mailing List (not for usage questions)" 

Date:   02/05/2015 11:29 AM
Subject:Re: [openstack-dev] [horizon] JavaScript docs?



I'd like to step back for a moment as to the purpose of different kinds of 
documentation. Sphinx is great and it provides some forms of 
documentation. But, why do we document methods, classes, or functions in 
python? Should we drop that and rely on Sphinx? I don't think anyone would 
argue for that.

Some documentation has a different purpose. For example, text editors and 
IDEs can introspect comments and help as we're writing the code. Or, say 
you have a bit of bit of code like the reusable wizard being written 
JavaScript. If someone is going to use it there should be a code comment 
about it. Just like you'd have for the tables class in Python because 
people are going to use it.

JavaScript is a programming language just as much as Python is. If we 
should have comments in Python we should have comments in JavaScript. It's 
no different.

JSDoc is the common format for JavaScript. It will help with text editors 
and IDEs. If we are going to move into an API docs site (which we don't 
have now) using ngDoc would be helpful. I think documenting in a useful 
manner is a different piece of scope from using that documentation to 
generate a site.

Ideally, we would document JavaScript in a useful manner no matter if we 
are creating html docs from it or not. To document in a useful manner we 
should likely use JSDoc (or ngDoc) for the useful tools rather than do it 
our own way. We should use the wheel everyone else is using rather than do 
it our own way.

Just my 2 cents.


On Thu, Feb 5, 2015 at 1:56 AM, Pavel Karikh  wrote:
On 02/05/2015 11:04 AM, Radomir Dopieralski wrote:
> Plus, the documentation generator that we are using already, Sphinx,
> supports JavaScript perfectly fine, so I see no reason to add another 
tool.

I agree with Radomir, why we can't just use Sphinx? 

__
OpenStack Development Mailing 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] [Trove] Core reviewer update

[Victoria Martínez de la Cruz]

Hi all,

I'm glad to be nominated to Trove core and of course I'm willing to join
you guys. Looking forward to keep up with more and stronger contributions.

Thanks a lot!

Victoria

2015-02-05 14:17 GMT-03:00 Vipul Sabhaya :

> +1 to all the nominations.  Many thanks to the departing cores for their
> contributions and bringing Trove to where it is today.
>
>
> On Feb 5, 2015, at 9:02 AM, Craig Vyvial  wrote:
>
> +1 +1 +1
> I think these nominations will help grow the trove community.
>
> -Craig
>
> On Thu, Feb 5, 2015 at 10:48 AM, Amrith Kumar  wrote:
>
>>  Nikhil,
>>
>>
>>
>> Regarding your nomination of Victoria, Peter and Edmond to core, here is
>> my vote (here are my votes).
>>
>>
>>
>> Victoria: +1
>>
>> Peter: +1
>>
>> Edmond: +1
>>
>>
>>
>> My thanks to all of you for your contributions to the project thus far,
>> and I look forward to working with all of you moving forward.
>>
>>
>>
>> Also, my sincere thanks to Michael (Bas) Basnight and Tim (grapex)
>> Simpson. It has been awesome working with both of you and look forward to
>> working together again!
>>
>>
>>
>> Thanks,
>>
>>
>>
>> -amrith
>>
>>
>>
>>
>>
>> --
>>
>>
>>
>> Amrith Kumar, CTO Tesora (www.tesora.com)
>>
>>
>>
>> Twitter: @amrithkumar
>>
>> IRC: amrith @freenode
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* Nikhil Manchanda [mailto:slick...@gmail.com]
>> *Sent:* Thursday, February 05, 2015 11:27 AM
>> *To:* OpenStack Development Mailing List
>> *Subject:* [openstack-dev] [Trove] Core reviewer update
>>
>>
>>
>> Hello Trove folks:
>>
>> Keeping in line with other OpenStack projects, and attempting to keep
>> the momentum of reviews in Trove going, we need to keep our core-team up
>> to date -- folks who are regularly doing good reviews on the code should
>> be brought in to core and folks whose involvement is dropping off should
>> be considered for removal since they lose context over time, not being
>> as involved.
>>
>> For this update I'm proposing the following changes:
>> - Adding Peter Stachowski (peterstac) to trove-core
>> - Adding Victoria Martinez De La Cruz (vkmc) to trove-core
>> - Adding Edmond Kotowski (edmondk) to trove-core
>> - Removing Michael Basnight (hub_cap) from trove-core
>> - Removing Tim Simpson (grapex) from trove-core
>>
>> For context on Trove reviews and who has been active, please see
>> Russell's stats for Trove at:
>> - http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
>> - http://russellbryant.net/openstack-stats/trove-reviewers-90.txt
>>
>> Trove-core members -- please reply with your vote on each of these
>> proposed changes to the core team. Peter, Victoria and Eddie -- please
>> let me know of your willingness to be in trove-core. Michael, and Tim --
>> if you are planning on being substantially active on Trove in the near
>> term, also please do let me know.
>>
>> Thanks,
>> Nikhil
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing 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] [horizon][keystone]

[Thai Q Tran]

Hi Ioram,Thanks for the feedback. I agree that the names are hard to follow, they can change to something more intuitive. Or we can even provide a tooltip for more information.As for the look and feel, I don't agree that its easier if all the options are listed. Image if you had 5 different ways for users to log in and they are all shown at once. That's a lot to take in.This approach keep things simply, it's really not that hard to pick from a list.Hi Anton,I'm just building on top of the visuals we already have without changing things too drastically. If you have a better idea, I would love to see it.-Ioram Schechtman Sette  wrote: -To: "OpenStack Development Mailing List (not for usage questions)" From: Ioram Schechtman Sette Date: 02/05/2015 03:15AMSubject: Re: [openstack-dev] [horizon][keystone]Hi Thai,I agree with Anton that the names are not intuitive for users.I would use something like:- Local authentication (for local credentials)- ?? (I also have no idea of what is a Default protocol)- Authenticate using  (something which is easy to the user understand that he could use or not - this is for the discovery service or remote IdP)Here in the University of Kent we used another approach.Instead of selecting the method using a "list/combo" box, we present all the options in a single screen.I think it's not beautiful, but functional.I think it would be easier to the user if they could have all the options in a single interface, since it doesn't become too much loaded (visually polluted).Regards,Ioram2015-02-05 9:20 GMT+00:00 Anton Zemlyanov :Hi,I guess "Credentials" is login and password. I have no idea what is "Default Protocol" or "Discovery Service".The proposed UI is rather embarrassing.AntonOn Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran  wrote:Hi all,I have been helping with the websso effort and wanted to get some feedback.Basically, users are presented with a login screen where they can select: credentials, default protocol, or discovery service.If user selects credentials, it works exactly the same way it works today.If user selects default protocol or discovery service, they can choose to be redirected to those pages.Keep in mind that this is a prototype, early feedback will be good.Here are the relevant patches:https://review.openstack.org/#/c/136177/https://review.openstack.org/#/c/136178/https://review.openstack.org/#/c/151842/I have attached the files and present them below:__
OpenStack Development Mailing 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: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-dev] [nova] Request non-priority feature freeze exception for "Add ability to inject routes in interfaces.template"

[Mathieu Gagné]

Hi,

I am requesting the exception for the feature "Add ability to inject 
routes in interfaces.template".


The potential changes in Nova are limited as the feature is opt-in.
The default interfaces.template is not changed for the reasons now 
explained in the new commit message. No comment were made so far 
requiring code refactoring, only ones about procedural technicalities. 
Furthermore, this code has been running in a production environment for 
months without any issue.


The blueprint:


https://blueprints.launchpad.net/nova/+spec/network-template-routes-injection

The change:

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

Thanks

--
Mathieu

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

Re: [openstack-dev] [nova][neutron] Passthrough of PF's from SR-IOV capable devices.

[Steve Gordon]

- Original Message -
> From: "Przemyslaw Czesnowicz" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> 
> Hi
>  
> > 1) If the device is a "normal" PCI device, but is a network card, am I
> > still able to
> > take advantage of the advanced syntax added circa Juno to define the
> > relationship between that card and a given physical network so that the
> > scheduler can place accordingly (and does this still use the ML2 mech
> > drvier for
> > SR-IOV even though it's a "normal" device.
> 
> Actually libvirt won't allow using "normal" PCI devices for network
> interfaces into VM.
> Following error is thrown by libvirt 1.2.9.1:
> libvirtError: unsupported configuration: Interface type hostdev is currently
> supported on SR-IOV Virtual Functions only
> 
> I don't know why libvirt prohibits that. But we should prohibit that on
> Openstack side as well.

This is true for hostdev"> style configuration, "normal" PCI devices are still 
valid in Libvirt for passthrough using  though. The former having been 
specifically created for handling passthrough of VFs, the latter being the more 
generic passthrough functionality and what was used with the original PCI 
passthrough functionality introduced circa Havana.

I guess what I'm really asking in this particular question is what is the 
intersection of these two implementations - if any, as on face value it seems 
that to passthrough a physical PCI device I must use the older syntax and thus 
can't have the scheduler be aware of its external network connectivity.

> > 2) There is no functional reason from a Libvirt/Qemu perspective that I
> > couldn't
> > pass through a PF to a guest, and some users have expressed surprise to me
> > when they have run into this check in the Nova driver. I assume in the
> > initial
> > implementation this was prevented to avoid a whole heap of fun additional
> > logic
> > that is required if this is allowed (e.g. check that no VFs from the PF
> > being
> > requested are already in use, remove all the associated VFs from the pool
> > when
> > assigning the PF, who gets allowed to use PFs versus VFs etc.). Am I
> > correct here
> > or is there another reason that this would be undesirable to allow in
> > future -
> > assuming such checks can also be designed - that I am missing?
> > 
> I think that is correct. But even if the additional logic was implemented  it
> wouldn't work because of how libvirt behaves currently.

Again though, in the code we have a distinction between a physical device (as I 
was asking about in Q1) and a physical function (as I am asking about in Q2) 
and similarly whether libvirt allows or not depends on how you configure in the 
guest XML. Though I wouldn't be surprised on the PF case if it is in fact not 
allowed in Libvirt (even with ) it is again important to consider this 
distinctly separate from passing through the physical device case which we DO 
allow currently in the code I'm asking about.

-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] [horizon][keystone]

[Marek Denis]

Hi,

I am more leaning towards layout Ioram suggested, but with 
protocols/other metods (Kerberos for instance) in the dropdown box.



On 05.02.2015 17:16, Steve Martinelli wrote:

Thanks Ioram,

From the keystone side: the one issue with listing IdPs is that some may
be private, so we're now looking to exploit the apache plugin data in the
environment (https://review.openstack.org/#/c/142743/), thus from the
horizon side the only data they need to send over would be the protocol
that the IdP uses.

What i'm taking away from some of the comments is to preserve the usual
(username and password) flow, and maybe it'll be easier to just list off
the protocols in a separate drop down (SAML and OpenID Connect).

Steve

Ioram Schechtman Sette  wrote on 02/05/2015 06:04:36 AM:

> From: Ioram Schechtman Sette 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 02/05/2015 06:14 AM
> Subject: Re: [openstack-dev] [horizon][keystone]
>
> Hi Thai,
>
> I agree with Anton that the names are not intuitive for users.

> I would use something like:
> - Local authentication (for local credentials)
> - ?? (I also have no idea of what is a Default protocol)
> - Authenticate using  (something which
> is easy to the user understand that he could use or not - this is
> for the discovery service or remote IdP)

> Here in the University of Kent we used another approach.
> Instead of selecting the method using a "list/combo" box, we present
> all the options in a single screen.
> I think it's not beautiful, but functional.
> I think it would be easier to the user if they could have all the
> options in a single interface, since it doesn't become too much
> loaded (visually polluted).
>
> [image removed]
> Regards,
> Ioram
>
> 2015-02-05 9:20 GMT+00:00 Anton Zemlyanov :
> Hi,
>
> I guess "Credentials" is login and password. I have no idea what is
> "Default Protocol" or "Discovery Service".
> The proposed UI is rather embarrassing.
>
> Anton
>
> On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran  wrote:
> Hi all,
>
> I have been helping with the websso effort and wanted to get some 
feedback.

> Basically, users are presented with a login screen where they can
> select: credentials, default protocol, or discovery service.
> If user selects credentials, it works exactly the same way it works 
today.

> If user selects default protocol or discovery service, they can
> choose to be redirected to those pages.
>
> Keep in mind that this is a prototype, early feedback will be good.
> Here are the relevant patches:
> https://review.openstack.org/#/c/136177/
> https://review.openstack.org/#/c/136178/
> https://review.openstack.org/#/c/151842/
>
> I have attached the files and present them below:
>
> [image removed] [image removed] [image removed] [image removed]
>
>

> 
__

> OpenStack Development Mailing 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



--
Marek Denis
[marek.de...@cern.ch]

__
OpenStack Development Mailing 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] Deprecation of in tree EC2 API in Nova for Kilo release

[Vishvananda Ishaya]

On Feb 3, 2015, at 6:19 AM, Sean Dague  wrote:

> On 02/03/2015 08:57 AM, Thierry Carrez wrote:
>> Jesse Pretorius wrote:
>>> I think that perhaps something that shouldn't be lost site of is that
>>> the users using the EC2 API are using it as-is. The only commitment that
>>> needs to be made is to maintain the functionality that's already there,
>>> rather than attempt to keep it up to scratch with newer functionality
>>> that's come into EC2.
>>> 
>>> The stackforge project can perhaps be the incubator for the development
>>> of a full replacement which is more up-to-date and interacts more like a
>>> translator. Once it's matured enough that the users want to use it
>>> instead of the old EC2 API in-tree, then perhaps deprecation is the
>>> right option.
>>> 
>>> Between now and then, I must say that I agree with Sean - perhaps the
>>> best strategy would be to make it clear somehow that the EC2 API isn't a
>>> fully tested or up-to-date API.
>> 
>> Right, there are several dimensions in the issue we are discussing.
>> 
>> - I completely agree we should communicate clearly the status of the
>> in-tree EC2 API to our users.
>> 
>> - Deprecation is a mechanism by which we communicate to our users that
>> they need to evolve their current usage of OpenStack. It should not be
>> used lightly, and it should be a reliable announcement. In the past we
>> deprecated things based on a promised replacement plan that never
>> happened, and we had to un-deprecate. I would very much prefer if we
>> didn't do that ever again, because it's training users to ignore our
>> deprecation announcements. That is what I meant in my earlier email. We
>> /can/ deprecate, but only when we are 99.9% sure we will follow up on that.
>> 
>> - The supposed "35% of our users" are actually more 44% of the user
>> survey respondents replying "yes" when asked if they ever used the EC2
>> API in their deployment of OpenStack. Given that it's far from being up
>> to date or from behaving fully like the current Amazon EC2 API, it's
>> fair to say that those users are probably more interested in keeping the
>> current OpenStack EC2 API support as-is, than they are interested in a
>> new project that will actually make it better and/or different.
> 
> All of which is fair, however there is actually no such thing as
> "keeping support as-is". The EC2 API is the equivalent of parts of Nova
> + Neutron + Cinder + Keystone + Swift. However the whole thing is
> implemented in Nova. Nova, for instances, has a terrible s3 object store
> in tree to make any of this work (so that the EC2 API doesn't actually
> depend on Swift). As the projects drift away and change their semantics,
> and bump their APIs keeping the same support is real work, that's not
> getting done.

This is a bit unfair. This code path is only used for ec2_register_image
which I think is almost completely unused even by ec2 these days. Also,
it can use any s3 object store (for example swift with swift3 in front).

Vish

> 
> It will become different over time regardless, the real question is if
> it gets different worse or different better.
> 
>> - Given legal uncertainty about closed APIs it might make *legal* sense
>> to remove it from Nova or at least mark it deprecated and freeze it
>> until that removal can happen. Projects in Stackforge are, by
>> definition, not OpenStack projects, and therefore do not carry the same
>> risk.
>> 
> 
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [horizon] JavaScript docs?

[Jeremy Stanley]

On 2015-02-05 10:19:39 -0800 (-0800), Matthew Farina wrote:
[...]
> Can we have that system parse and use JSDoc? I'd like it to be
> useful to both JS devs and the doc generation toolchain.

A quick Web search turned up
https://github.com/debrouwere/jsdoc-for-sphinx and
https://github.com/juhamust/jsdoc-toolkit-rst-template but no doubt
there are more.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [horizon] JavaScript docs?

[Michael Krotscheck]

On Thu Feb 05 2015 at 12:07:01 AM Radomir Dopieralski <
openst...@sheep.art.pl> wrote:

>
> Plus, the documentation generator that we are using already, Sphinx,
> supports JavaScript perfectly fine, so I see no reason to add another tool.
>

Try to empathize with us a little here. What you're asking is equivalent to
saying "OpenStack should use JavaDoc for all its documentation because it
supports python". For all the reasons that you would mistrust JavaDoc, I
mistrust Sphinx when it comes to parsing javascript.

With that in mind, how about we run a side-by-side comparison of Sphinx vs.
NGDoc? Without actual comparable output, this discussion isn't much more
than warring opinions.

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

Re: [openstack-dev] [horizon] JavaScript docs?

[Matthew Farina]

Ah, I had forgotten about the python module documentation. Sorry about that
and thanks for pointing it out.

Can we have that system parse and use JSDoc? I'd like it to be useful to
both JS devs and the doc generation toolchain.

On Thu, Feb 5, 2015 at 9:42 AM, Jeremy Stanley  wrote:

> On 2015-02-05 09:20:35 -0800 (-0800), Matthew Farina wrote:
> [...]
> > But, why do we document methods, classes, or functions in python?
> > Should we drop that and rely on Sphinx? I don't think anyone would
> > argue for that.
> [...]
>
> Particularly since Sphinx collects the method/class/function
> docstrings from the source code to assemble them into
> documentation[1]. I see that as its primary reason for existing in
> fact. Why do you seem to think those choices are at odds with one
> another?
>
> [1] http://docs.openstack.org/developer/nova/api/nova.api.validator.html
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

[Joshua Harlow]

Hey now you forgot a site in that list ;-)

-Josh

Clint Byrum wrote:

You may want to have a chat with the people running MySQL at
Google, Facebook, and a long tail of not quite as big sites but still
massively bigger than most clouds.


__
OpenStack Development Mailing 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][neutron] Passthrough of PF's from SR-IOV capable devices.

[Czesnowicz, Przemyslaw]

Hi
 
> 1) If the device is a "normal" PCI device, but is a network card, am I still 
> able to
> take advantage of the advanced syntax added circa Juno to define the
> relationship between that card and a given physical network so that the
> scheduler can place accordingly (and does this still use the ML2 mech drvier 
> for
> SR-IOV even though it's a "normal" device.

Actually libvirt won't allow using "normal" PCI devices for network interfaces 
into VM.
Following error is thrown by libvirt 1.2.9.1:
libvirtError: unsupported configuration: Interface type hostdev is currently 
supported on SR-IOV Virtual Functions only

I don't know why libvirt prohibits that. But we should prohibit that on 
Openstack side as well.
> 
> 2) There is no functional reason from a Libvirt/Qemu perspective that I 
> couldn't
> pass through a PF to a guest, and some users have expressed surprise to me
> when they have run into this check in the Nova driver. I assume in the initial
> implementation this was prevented to avoid a whole heap of fun additional 
> logic
> that is required if this is allowed (e.g. check that no VFs from the PF being
> requested are already in use, remove all the associated VFs from the pool when
> assigning the PF, who gets allowed to use PFs versus VFs etc.). Am I correct 
> here
> or is there another reason that this would be undesirable to allow in future -
> assuming such checks can also be designed - that I am missing?
> 
I think that is correct. But even if the additional logic was implemented  it 
wouldn't work because of how libvirt behaves currently.

Regards
Przemek

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

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

[openstack-dev] [horizon] system information panel, update with heat-engine status

[Manickam, Kanagaraj]

Hello Horizon Cores,

In K-2, Heat is enabled with new REST API to report the running heat-engine 
status, This is in-line with how nova reports nova-compute running status.
To report this feature in horizon under 'System information panel', a new 
blueprint is created at 
https://blueprints.launchpad.net/horizon/+spec/heat-engine-status-report

Can one of you kindly approve it to target in K release, so that admin can view 
the currently running Heat-engine's status from horizon.

Thanks.

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

Re: [openstack-dev] [horizon] JavaScript docs?

[Jeremy Stanley]

On 2015-02-05 09:20:35 -0800 (-0800), Matthew Farina wrote:
[...]
> But, why do we document methods, classes, or functions in python?
> Should we drop that and rely on Sphinx? I don't think anyone would
> argue for that.
[...]

Particularly since Sphinx collects the method/class/function
docstrings from the source code to assemble them into
documentation[1]. I see that as its primary reason for existing in
fact. Why do you seem to think those choices are at odds with one
another?

[1] http://docs.openstack.org/developer/nova/api/nova.api.validator.html
-- 
Jeremy Stanley

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

Re: [openstack-dev] [kolla][tripleo] Update on Kolla

[Paul Bourke]

Hi Steve,

Thanks for the update.  For those interested in Kolla development and 
discussion, where is the best place to go?


Regards,
-Paul

On 05/02/15 17:25, Steven Dake (stdake) wrote:

Hey folks,

I wanted to provide a brief update on where we are headed with Kolla.
  Initially Kolla began as a POC to show that containers could be used
to deploy OpenStack with the long term plan of integrating that
functionality into TripleO.  That goal has not changed.

The tripleo community wants baby steps not outright replacement of the
infrastructure as was proposed by using Kubernetes in Kolla as a
dependency in this review [1].   Our first step in this process will be
to create three new container types.  We will create a controller node,
a storage node, and a compute node.  We have proven that compute can be
used.[2]  Further, one of our community members is working on a DIB
elements->container tool here [3] and we plan to use this along with our
other R&D in the area to integrate container tech into tripleo.

I’m not quite sure how it will all come together, but after numerous
discussions with folks from the tripleo and heat teams, I believe we can
find a path forward.

Regards
-steve


[1] https://review.openstack.org/#/c/144199/
[2]
http://sdake.io/2015/01/28/an-atomic-upgrade-process-for-openstack-compute-nodes/
_[3] _https://review.openstack.org/#/c/152017/


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



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

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

[Clint Byrum]

Excerpts from Avishay Traeger's message of 2015-02-04 22:19:53 -0800:
> On Wed, Feb 4, 2015 at 11:00 PM, Robert Collins 
> wrote:
> 
> > On 5 February 2015 at 10:24, Joshua Harlow  wrote:
> > > How interesting,
> > >
> > > Why are people using galera if it behaves like this? :-/
> >
> > Because its actually fairly normal. In fact its an instance of point 7
> > on https://wiki.openstack.org/wiki/BasicDesignTenets - one of our
> > oldest wiki pages :).
> >
> 
> When I hear MySQL I don't exactly think of eventual consistency (#7),
> scalability (#1), horizontal scalability (#4), etc.
> For the past few months I have been advocating implementing an alternative
> to db/sqlalchemy, but of course it's a huge undertaking.  NoSQL (or even
> distributed key-value stores) should be considered IMO.  Just some food for
> thought :)
> 

I know it is popular to think that MySQL* == old slow and low-scale, but
that is only popular with those who have not actually tried to scale
MySQL. You may want to have a chat with the people running MySQL at
Google, Facebook, and a long tail of not quite as big sites but still
massively bigger than most clouds. Note that many of the people who
helped those companies scale up are involved directly with OpenStack.

The NoSQL bits that are popular out there make the easy part easy. There
is no magic bullet for the hard part, which is when you need to do both
synchronous and asynchronous. Factor in its maturity and the breadth of
talent available, and I'll choose MySQL for this task every time.

* Please let's also give a nod to our friends working on MariaDB, a
  MySQL-compatible fork that many find preferrable and for the purposes
  of this discussion, equivalent.

__
OpenStack Development Mailing 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][tripleo] Update on Kolla

[Steven Dake (stdake)]

Hey folks,

I wanted to provide a brief update on where we are headed with Kolla.  
Initially Kolla began as a POC to show that containers could be used to deploy 
OpenStack with the long term plan of integrating that functionality into 
TripleO.  That goal has not changed.

The tripleo community wants baby steps not outright replacement of the 
infrastructure as was proposed by using Kubernetes in Kolla as a dependency in 
this review [1].   Our first step in this process will be to create three new 
container types.  We will create a controller node, a storage node, and a 
compute node.  We have proven that compute can be used.[2]  Further, one of our 
community members is working on a DIB elements->container tool here [3] and we 
plan to use this along with our other R&D in the area to integrate container 
tech into tripleo.

I’m not quite sure how it will all come together, but after numerous 
discussions with folks from the tripleo and heat teams, I believe we can find a 
path forward.

Regards
-steve



[1] https://review.openstack.org/#/c/144199/
[2] 
http://sdake.io/2015/01/28/an-atomic-upgrade-process-for-openstack-compute-nodes/
[3] https://review.openstack.org/#/c/152017/
__
OpenStack Development Mailing 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] [Heat] Add extraroutes support to neutron routers

[James Denton]

Hello all,

Regarding https://blueprints.launchpad.net/heat/+spec/router-properties-object

Does anyone know if there are plans to implement this functionality in an 
upcoming release? Our use case meets the one described by Kevin, but rather 
than trying to route traffic to an outside resource, we are routing to another 
instance off the router.

Thanks!

—
James Denton
__
OpenStack Development Mailing 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][oslo.db][nova] TL; DR Things everybody should know about Galera

[Clint Byrum]

Excerpts from Angus Lees's message of 2015-02-04 16:59:31 -0800:
> On Thu Feb 05 2015 at 9:02:49 AM Robert Collins 
> wrote:
> 
> > On 5 February 2015 at 10:24, Joshua Harlow  wrote:
> > > How interesting,
> > >
> > > Why are people using galera if it behaves like this? :-/
> >
> > Because its actually fairly normal. In fact its an instance of point 7
> > on https://wiki.openstack.org/wiki/BasicDesignTenets - one of our
> > oldest wiki pages :).
> >
> > In more detail, consider what happens in full isolation when you have
> > the A and B example given, but B starts its transaction before A.
> >
> > B BEGIN
> > A BEGIN
> > A INSERT foo
> > A COMMIT
> > B SELECT foo -> NULL
> >
> 
> Note that this still makes sense from each of A and B's individual view of
> the world.
> 
> If I understood correctly, the big change with Galera that Matthew is
> highlighting is that read-after-write may not be consistent from the pov of
> a single thread.
> 

No that's not a complete picture.

What Matthew is highlighting is that after a commit, a new transaction
may not see the write if it is done on a separate node in the cluster.

In a single thread, using a single database session, then a read after
successful commit is guaranteed to read a version of the database
that existed after that commit. What it may not be consistent with is
subsequent writes which may have happened after the commit on other
servers, unless you use the sync wait.

> Not have read-after-write is *really* hard to code to (see for example x86
> SMP cache coherency, C++ threading semantics, etc which all provide
> read-after-write for this reason).  This is particularly true when the
> affected operations are hidden behind an ORM - it isn't clear what might
> involve a database call and sequencers (or logical clocks, etc) aren't made
> explicit in the API.
> 
> I strongly suggest just enabling wsrep_casual_reads on all galera sessions,
> unless you can guarantee that the high-level task is purely read-only, and
> then moving on to something else ;)  If we choose performance over
> correctness here then we're just signing up for lots of debugging of hard
> to reproduce race conditions, and the fixes are going to look like what
> wsrep_casual_reads does anyway.
> 
> (Mind you, exposing sequencers at every API interaction would be awesome,
> and I look forward to a future framework and toolchain that makes that easy
> to do correctly)
> 

I'd like to see actual examples where that will matter. Meanwhile making
all selects wait for the cluster will basically just ruin responsiveness
and waste tons of time, so we should be careful to think this through
before making any blanket policy.

I'd also like to see consideration given to systems that handle
distributed consistency in a more active manner. etcd and Zookeeper are
both such systems, and might serve as efficient guards for critical
sections without raising latency.

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

Re: [openstack-dev] [horizon] JavaScript docs?

[Matthew Farina]

I'd like to step back for a moment as to the purpose of different kinds of
documentation. Sphinx is great and it provides some forms of documentation.
But, why do we document methods, classes, or functions in python? Should we
drop that and rely on Sphinx? I don't think anyone would argue for that.

Some documentation has a different purpose. For example, text editors and
IDEs can introspect comments and help as we're writing the code. Or, say
you have a bit of bit of code like the reusable wizard being written
JavaScript. If someone is going to use it there should be a code comment
about it. Just like you'd have for the tables class in Python because
people are going to use it.

JavaScript is a programming language just as much as Python is. If we
should have comments in Python we should have comments in JavaScript. It's
no different.

JSDoc is the common format for JavaScript. It will help with text editors
and IDEs. If we are going to move into an API docs site (which we don't
have now) using ngDoc would be helpful. I think documenting in a useful
manner is a different piece of scope from using that documentation to
generate a site.

Ideally, we would document JavaScript in a useful manner no matter if we
are creating html docs from it or not. To document in a useful manner we
should likely use JSDoc (or ngDoc) for the useful tools rather than do it
our own way. We should use the wheel everyone else is using rather than do
it our own way.

Just my 2 cents.


On Thu, Feb 5, 2015 at 1:56 AM, Pavel Karikh  wrote:

> On 02/05/2015 11:04 AM, Radomir Dopieralski wrote:
> > Plus, the documentation generator that we are using already, Sphinx,
> > supports JavaScript perfectly fine, so I see no reason to add another
> tool.
>
> I agree with Radomir, why we can't just use Sphinx?
>
> __
> OpenStack Development Mailing 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] [python-cinderclient] Return request ID to caller

[Joe Gordon]

On Wed, Feb 4, 2015 at 11:23 PM, Malawade, Abhijeet <
abhijeet.malaw...@nttdata.com> wrote:

>  Hi,
>
>
>
> I have submitted patch for cinder-client [1] to 'Return tuple containing
> header and body from client' instead of just response.
>
> Also cinder spec for the same is under review [2].
>
>
>
> This change will break OpenStack services which are using cinder-client.
> To do not break services which are using cinder-client,
>
> we need to first make changes in those projects to check return type of
> cinder-client. We are working on doing cinder-client return
>
> type check changes in OpenStack services like nova, glance_store, heat,
> trove, manila etc.
>
> We have already submitted patch for same against nova :
> https://review.openstack.org/#/c/152820/
>
>
>
> [1] https://review.openstack.org/#/c/152075/
>
> [2] https://review.openstack.org/#/c/132161/
>

This sounds like a backwards incompatible change to the python client, that
will break downstream consumers of python-cinderclient. This change should
be done in a way that allows us to deprecate the old usage without breaking
it right away.


>
>
> I want to seek early feedback from the community members on the above
> patches, so please give your thoughts on the same.
>
>
>
> Thanks,
>
> Abhijeet Malawade
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> OpenStack Development Mailing 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] [Trove] Core reviewer update

[Vipul Sabhaya]

+1 to all the nominations.  Many thanks to the departing cores for their 
contributions and bringing Trove to where it is today.


> On Feb 5, 2015, at 9:02 AM, Craig Vyvial  wrote:
> 
> +1 +1 +1
> I think these nominations will help grow the trove community. 
> 
> -Craig
> 
>> On Thu, Feb 5, 2015 at 10:48 AM, Amrith Kumar  wrote:
>> Nikhil,
>> 
>>  
>> 
>> Regarding your nomination of Victoria, Peter and Edmond to core, here is my 
>> vote (here are my votes).
>> 
>>  
>> 
>> Victoria: +1
>> 
>> Peter: +1
>> 
>> Edmond: +1
>> 
>>  
>> 
>> My thanks to all of you for your contributions to the project thus far, and 
>> I look forward to working with all of you moving forward.
>> 
>>  
>> 
>> Also, my sincere thanks to Michael (Bas) Basnight and Tim (grapex) Simpson. 
>> It has been awesome working with both of you and look forward to working 
>> together again!
>> 
>>  
>> 
>> Thanks,
>> 
>>  
>> 
>> -amrith
>> 
>>  
>> 
>>  
>> 
>> --
>> 
>>  
>> 
>> Amrith Kumar, CTO Tesora (www.tesora.com)
>> 
>>  
>> 
>> Twitter: @amrithkumar 
>> 
>> IRC: amrith @freenode
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> From: Nikhil Manchanda [mailto:slick...@gmail.com] 
>> Sent: Thursday, February 05, 2015 11:27 AM
>> To: OpenStack Development Mailing List
>> Subject: [openstack-dev] [Trove] Core reviewer update
>> 
>>  
>> 
>> Hello Trove folks:
>> 
>> Keeping in line with other OpenStack projects, and attempting to keep
>> the momentum of reviews in Trove going, we need to keep our core-team up
>> to date -- folks who are regularly doing good reviews on the code should
>> be brought in to core and folks whose involvement is dropping off should
>> be considered for removal since they lose context over time, not being
>> as involved.
>> 
>> For this update I'm proposing the following changes:
>> - Adding Peter Stachowski (peterstac) to trove-core
>> - Adding Victoria Martinez De La Cruz (vkmc) to trove-core
>> - Adding Edmond Kotowski (edmondk) to trove-core
>> - Removing Michael Basnight (hub_cap) from trove-core
>> - Removing Tim Simpson (grapex) from trove-core
>> 
>> For context on Trove reviews and who has been active, please see
>> Russell's stats for Trove at:
>> - http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
>> - http://russellbryant.net/openstack-stats/trove-reviewers-90.txt
>> 
>> Trove-core members -- please reply with your vote on each of these
>> proposed changes to the core team. Peter, Victoria and Eddie -- please
>> let me know of your willingness to be in trove-core. Michael, and Tim --
>> if you are planning on being substantially active on Trove in the near
>> term, also please do let me know.
>> 
>> Thanks,
>> Nikhil
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing 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] [congress] sprinting towards Kilo2

[sean roberts]

started congress sprint hangout
https://plus.google.com/hangouts/_/gwspatjycr3rore6smdkganufua
and / or join on the #congress channel

On Wed, Feb 4, 2015 at 4:59 PM, sean roberts 
wrote:

> Join the Congress team to push your code over the milestone line. The
> Congress team will be online from 9am to 5pm over the next two days. Reach
> out through the #congress IRC channel. We will start a google hangout and
> post the URL in the #congress channel.
>
> See you there!
>
>
> On Tuesday, February 3, 2015, sean roberts 
> wrote:
>
>> Over the last couple of meetings, we have discussed holding a hackathon
>> this Thursday and Friday. You each have some code you are working on. Let’s
>> each pick a 3-4 hour block of time to intensively collaborate. We can use
>> the #congress IRC channel and google hangout.
>>
>> Reply to this thread, so we can allocate people’s time.
>>
>> ~ sean
>>
>
>
> --
> ~sean
>



-- 

~ sean
__
OpenStack Development Mailing 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] [Trove] Core reviewer update

[Craig Vyvial]

+1 +1 +1
I think these nominations will help grow the trove community.

-Craig

On Thu, Feb 5, 2015 at 10:48 AM, Amrith Kumar  wrote:

>  Nikhil,
>
>
>
> Regarding your nomination of Victoria, Peter and Edmond to core, here is
> my vote (here are my votes).
>
>
>
> Victoria: +1
>
> Peter: +1
>
> Edmond: +1
>
>
>
> My thanks to all of you for your contributions to the project thus far,
> and I look forward to working with all of you moving forward.
>
>
>
> Also, my sincere thanks to Michael (Bas) Basnight and Tim (grapex)
> Simpson. It has been awesome working with both of you and look forward to
> working together again!
>
>
>
> Thanks,
>
>
>
> -amrith
>
>
>
>
>
> --
>
>
>
> Amrith Kumar, CTO Tesora (www.tesora.com)
>
>
>
> Twitter: @amrithkumar
>
> IRC: amrith @freenode
>
>
>
>
>
>
>
>
>
>
>
> *From:* Nikhil Manchanda [mailto:slick...@gmail.com]
> *Sent:* Thursday, February 05, 2015 11:27 AM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [Trove] Core reviewer update
>
>
>
> Hello Trove folks:
>
> Keeping in line with other OpenStack projects, and attempting to keep
> the momentum of reviews in Trove going, we need to keep our core-team up
> to date -- folks who are regularly doing good reviews on the code should
> be brought in to core and folks whose involvement is dropping off should
> be considered for removal since they lose context over time, not being
> as involved.
>
> For this update I'm proposing the following changes:
> - Adding Peter Stachowski (peterstac) to trove-core
> - Adding Victoria Martinez De La Cruz (vkmc) to trove-core
> - Adding Edmond Kotowski (edmondk) to trove-core
> - Removing Michael Basnight (hub_cap) from trove-core
> - Removing Tim Simpson (grapex) from trove-core
>
> For context on Trove reviews and who has been active, please see
> Russell's stats for Trove at:
> - http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
> - http://russellbryant.net/openstack-stats/trove-reviewers-90.txt
>
> Trove-core members -- please reply with your vote on each of these
> proposed changes to the core team. Peter, Victoria and Eddie -- please
> let me know of your willingness to be in trove-core. Michael, and Tim --
> if you are planning on being substantially active on Trove in the near
> term, also please do let me know.
>
> Thanks,
> Nikhil
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] [Trove] Core reviewer update

[Iccha Sethi]

+1.

Congratulations to the new core members.

From: Denis Makogon mailto:dmako...@mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, February 5, 2015 at 10:38 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Trove] Core reviewer update

+1

Congratulations Peter, Victoria and Edmond.


On Thu, Feb 5, 2015 at 6:26 PM, Nikhil Manchanda 
mailto:slick...@gmail.com>> wrote:
Hello Trove folks:

Keeping in line with other OpenStack projects, and attempting to keep
the momentum of reviews in Trove going, we need to keep our core-team up
to date -- folks who are regularly doing good reviews on the code should
be brought in to core and folks whose involvement is dropping off should
be considered for removal since they lose context over time, not being
as involved.

For this update I'm proposing the following changes:
- Adding Peter Stachowski (peterstac) to trove-core
- Adding Victoria Martinez De La Cruz (vkmc) to trove-core
- Adding Edmond Kotowski (edmondk) to trove-core
- Removing Michael Basnight (hub_cap) from trove-core
- Removing Tim Simpson (grapex) from trove-core

For context on Trove reviews and who has been active, please see
Russell's stats for Trove at:
- http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
- http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

Trove-core members -- please reply with your vote on each of these
proposed changes to the core team. Peter, Victoria and Eddie -- please
let me know of your willingness to be in trove-core. Michael, and Tim --
if you are planning on being substantially active on Trove in the near
term, also please do let me know.

Thanks,
Nikhil

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


__
OpenStack Development Mailing 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] stuck patches at the nova IRC meeting

[Sean Dague]

On 02/05/2015 11:50 AM, Daniel P. Berrange wrote:
> On Thu, Feb 05, 2015 at 10:42:48AM -0600, Ed Leafe wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 02/05/2015 09:02 AM, Alexis Lee wrote:
>>
>>> May I suggest stricter moderation? EG a short phase to propose
>>> items, then work through them 1 by 1. Or, we take items one by one
>>> according to who shouts fastest but ask people not to interrupt.
>>
>> Or how about going through the ones listed on the agenda, rather than
>> having a free-for-all shouting match?
> 
> Indeed, I thought that was the whole point of putting them in the
> agenda in the first place :-)

Agreed, I think it just got away from us today with lots of first time
attendees. We'll just have to be a little clearer next time.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Trove] Core reviewer update

[Tim Simpson]

+1

Alas, my days of offering substantial activity on Trove are over. Best of luck 
in all of your adventures!



On Feb 5, 2015, at 10:26 AM, Nikhil Manchanda 
mailto:slick...@gmail.com>>
 wrote:

Hello Trove folks:

Keeping in line with other OpenStack projects, and attempting to keep
the momentum of reviews in Trove going, we need to keep our core-team up
to date -- folks who are regularly doing good reviews on the code should
be brought in to core and folks whose involvement is dropping off should
be considered for removal since they lose context over time, not being
as involved.

For this update I'm proposing the following changes:
- Adding Peter Stachowski (peterstac) to trove-core
- Adding Victoria Martinez De La Cruz (vkmc) to trove-core
- Adding Edmond Kotowski (edmondk) to trove-core
- Removing Michael Basnight (hub_cap) from trove-core
- Removing Tim Simpson (grapex) from trove-core

For context on Trove reviews and who has been active, please see
Russell's stats for Trove at:
- http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
- http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

Trove-core members -- please reply with your vote on each of these
proposed changes to the core team. Peter, Victoria and Eddie -- please
let me know of your willingness to be in trove-core. Michael, and Tim --
if you are planning on being substantially active on Trove in the near
term, also please do let me know.

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

__
OpenStack Development Mailing 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] stuck patches at the nova IRC meeting

[Daniel P. Berrange]

On Thu, Feb 05, 2015 at 10:42:48AM -0600, Ed Leafe wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 02/05/2015 09:02 AM, Alexis Lee wrote:
> 
> > May I suggest stricter moderation? EG a short phase to propose
> > items, then work through them 1 by 1. Or, we take items one by one
> > according to who shouts fastest but ask people not to interrupt.
> 
> Or how about going through the ones listed on the agenda, rather than
> having a free-for-all shouting match?

Indeed, I thought that was the whole point of putting them in the
agenda in the first place :-)

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing 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] [Trove] Core reviewer update

[Amrith Kumar]

Nikhil,

Regarding your nomination of Victoria, Peter and Edmond to core, here is my 
vote (here are my votes).

Victoria: +1
Peter: +1
Edmond: +1

My thanks to all of you for your contributions to the project thus far, and I 
look forward to working with all of you moving forward.

Also, my sincere thanks to Michael (Bas) Basnight and Tim (grapex) Simpson. It 
has been awesome working with both of you and look forward to working together 
again!

Thanks,

-amrith


--

Amrith Kumar, CTO Tesora (www.tesora.com)

Twitter: @amrithkumar
IRC: amrith @freenode





From: Nikhil Manchanda [mailto:slick...@gmail.com]
Sent: Thursday, February 05, 2015 11:27 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Trove] Core reviewer update

Hello Trove folks:

Keeping in line with other OpenStack projects, and attempting to keep
the momentum of reviews in Trove going, we need to keep our core-team up
to date -- folks who are regularly doing good reviews on the code should
be brought in to core and folks whose involvement is dropping off should
be considered for removal since they lose context over time, not being
as involved.

For this update I'm proposing the following changes:
- Adding Peter Stachowski (peterstac) to trove-core
- Adding Victoria Martinez De La Cruz (vkmc) to trove-core
- Adding Edmond Kotowski (edmondk) to trove-core
- Removing Michael Basnight (hub_cap) from trove-core
- Removing Tim Simpson (grapex) from trove-core

For context on Trove reviews and who has been active, please see
Russell's stats for Trove at:
- http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
- http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

Trove-core members -- please reply with your vote on each of these
proposed changes to the core team. Peter, Victoria and Eddie -- please
let me know of your willingness to be in trove-core. Michael, and Tim --
if you are planning on being substantially active on Trove in the near
term, also please do let me know.

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

Re: [openstack-dev] [nova] Hypervisor support matrix now in GIT

[Daniel P. Berrange]

On Thu, Feb 05, 2015 at 10:24:24AM -0600, Kurt Taylor wrote:
> On Thu, Feb 5, 2015 at 4:31 AM, Daniel P. Berrange 
> wrote:
> 
> > Hi Team Nova,
> >
> > This is a message to alert everyone to the fact that the old hypervisor
> > support matrix on the wiki[1], should really be considered obsolete.
> >
> > The canonical location for it going forward will be
> >
> >http://docs.openstack.org/developer/nova/support-matrix.html
> >
> > That URL shows current GIT snapshot, releases will get their own URL
> > when the time comes.
> >
> > The source for this document is part of Nova GIT in the path
> >
> >doc/source/support-matrix.ini
> >
> > The docs are auto-generated from that ini file using a sphinx extension
> >
> >doc/ext/support_matrix.py
> >
> > The CSS styling is in
> >
> >doc/source/_static/support-matrix.css
> >
> > Some things to note here
> >
> >  - The new doc was populated based on the contents of the old wiki page
> > from
> >about two months ago, so if there have been additions to the wiki in
> > that
> >time, they might not all have been captured - depends how good I was at
> >figuring out changes.
> >
> >  - Improvements to the content and/or HTML styling should obviously be sent
> >as patches to Nova GIT in the files mentioned above, via normal Gerrit
> >review practice.
> >
> >  - Since it is in GIT, the support matrix is now able to record information
> >per release branch of Nova. So users can be clear about what features
> >their release of Nova supports, as opposed to playing guessing games.
> >
> >  - The in-tree document only covers features of the in-tree Nova drivers.
> >As such it does not include information about Docker or PowerKVM or
> >the (now deleted) BareMetal drivers. My currently suggestion is that
> >people maintaining out of tree drivers, should reuse the sphinx
> > extension
> >to format their own support matrix ini file in their local GIT repo.
> >
> 
> I think that maybe you have confused PowerKVM with PowerVM.  The PowerVM
> driver was removed, but PowerKVM support is in tree with libvirt.

Ok, so the wiki page was indeed referring to the libvirt impl. That wasn't
obvious since it didn't mention libvirt in the heading as all the other
libvirt columns did ! Sorry for not copying across your data then.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing 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] fixed ip info shown for port even when dhcp is disabled

[Salvatore Orlando]

I have the feeling that the discussion is diverging a bit.

John is correctly stating that with pluggable IPAM it should be possible,
in theory to write a driver which interfaces to any DHCP server, providing
it the information it needs to distribute addresses assigned by Neutron.
This is possible in theory even if the DHCP server does not expose any sort
of API - as an example you might write a driver which writes into
configuration files and then restarts or reloads the DHCP server as needed,
which is not very different from what we do today with Dnsmasq.

However, it seems to me that the gist of Padmanabhan's question is whether
neutron should allow completely out of band IP address management. Neutron
is evolving in a direction where this would be possible only if one
considers it as a simple service for building virtualised layer-2 segments.
Unless some form of interaction with the entity which manages IPs is
envisioned, it would not be possible to use neutron's security and routing
services.
Also, another aspect to factor in is nova. I have not checked this in a
while, but I seem to recall it was not able to boot a VM with network
interfaces if it did not obtain also IP addresses for such interfaces - and
those IPs are indeed fetched from neutron's port info.
If I got Padmanabhan's point right then we need to discuss if and how out
of band address mgmt and distribution should be supported in Neutron.

Regards,
Salvatore

On 5 February 2015 at 15:20, John Belamaric  wrote:

>  The pluggable IPAM [1] is intended to support the scenario you described
> below. That is, a fixed IP is provided for the port by IPAM, and then the
> DHCP server is programmed to return that IP for that MAC or DUID (for
> IPv6). If I understand correctly, your concern then is:
>
>  1) The DHCP server may not allow such programming;
> 2) The DHCP server may not be able to provide an IP allocation via any
> means other than DHCP (ie, no API to pre-allocate the IP)
>
>  I would think then, what you are asking for is the ability to attach an
> interface to a layer 2 network without also giving it an IP in any
> subnet(s) that are on that network. Seems like a reasonable request, but I
> am not sure what would be involved in implementing that.
>
>  Additionally, we would need some mechanism to update the port with the
> IP after it is allocated via the DHCP server. Otherwise, I don't think all
> the iptables rules and such will be properly configured, so you probably
> won't be able to pass traffic beyond the local subnet. Not sure on that
> though.
>
>
>   [1] -
> http://specs.openstack.org/openstack/neutron-specs/specs/kilo/neutron-ipam.html
>
>
>
>   From: Padmanabhan Krishnan 
> Reply-To: Padmanabhan Krishnan 
> Date: Thursday, February 5, 2015 at 1:47 AM
> To: John Belamaric , "OpenStack Development
> Mailing List (not for usage questions)"  >
> Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even
> when dhcp is disabled
>
>Hi John,
> Sure, this may not be in the scope of IPAM as originally proposed in [1].
> Am just trying to see if there can be a solution for this scenario using
> IPAM.
>
>  What I had in mind is also a centrally managed IPAM and not each VM
> allocating its own IP address. Let me clarify.
>
> It's not an uncommon requirement to use a commercial DHCP server in an
> enterprise/DC. I am referring to it as external DHCP server from
> Openstack's perspective.
> One scenario of deployment is when IPAM is done through Openstack and in
> which case, the  can be programmed in the
> external DHCP server, assuming they have standard API's for that. Then, the
> VM will get the openstack assigned IP address from the DHCP server when it
> boots up. You also suggested this and sure, it's not a problem here.
>
>  Now, another scenario and that's of interest is when IPAM itself is done
> directly using the commercial DHCP server for various reasons. I am just
> trying to see how this model will work (or can be extended to work) for
> this case. What's the role of pluggable IPAM [1] in this scenario? If at
> all there's a way to tell the external DHCP server, do your own allocation
> and return an IP address for me for this , then this IP
> address can be returned during the allocate_ip API by the pluggable IPAM?
> But, I am not sure, an external DHCP server will have this flexibility.
> Then, in such scenarios, the only way is to not allocate an IP address
> during create_port. When the VM comes up and sends a DHCP request the
> commercial DHCP server responds with an address. The pluggable IPAM then
> can use its own method, and when it discovers the IP address of the VM, it
> can call to update_port with the IP address.
> Any other way?
>
>  [1] -
> http://specs.openstack.org/openstack/neutron-specs/specs/kilo/neutron-ipam.html
>
>  Thanks,
> Paddu
>
>
>   On Tuesday, February 3, 2015 8:57 AM, John Belamaric <
> jbelama...@infoblox.com> wrote:
>
>
>   Hi Paddu,
>
>  I think this is less an issue of 

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/05/2015 09:02 AM, Alexis Lee wrote:

> May I suggest stricter moderation? EG a short phase to propose
> items, then work through them 1 by 1. Or, we take items one by one
> according to who shouts fastest but ask people not to interrupt.

Or how about going through the ones listed on the agenda, rather than
having a free-for-all shouting match?

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iQIcBAEBAgAGBQJU052HAAoJEKMgtcocwZqLHiIP/A7vIQsh219+7mnxttDPLc4A
Av25XW6WJDVciPlR5VIlDIQTdl/Gy2sv2IyArhmmBalnBRiFmWbkjli9lg3/r2IY
//EtkRGNiOPSiXRVoWBSF4z/yceO/8iTdmjikVuLOCDtP9TD96Va3wxM8JFVQqa6
YpF05SqEUHoWIB1+sZ0tqK6PsDH07hgWT472kZ4jOjL9ZZUS8abAaX72tltqmt2x
V0e/liLdiO9sDD5owRZhOV6ho6AIkSeh76Ng6q9sLIKZC/Tm94s/M4R88kLaSpqE
PqaL06z5OTQXEKzBuVu6irV2c389JEdhG3HpmgI+r/b7jQJoy5Ui73V8h6+dNVvG
/hbUIoJGTQY+jgZTfDgOq41ceu0ujdhO29bR0WnfcLN9RRc0sz/cTz1c6n1MvBmP
knBkYd+TjYbsdgI7m3gD9TIvs1rgS8FQ6OOKaDHoqxrjL19rrGFOn2ZsjcODJSnk
m0Bm1Dj6jpPcyzxGZoKWJLlZ2WQvUvR6RRLw52DXWUxdUdYGIqKFpAwHrjbAzSyg
LOuyK90vixCR1Nv+iCSguvRqCo0bxGwHZfOua00qf2RQF0ByQh4cbqA+P1PuE+kC
GOP8doUbqIHMLuU1aHdIAL5u6q9ussqdc5InN58zaju2o4sdggbh2e1NBwkSM77f
KTd+HJNCsApaXhP7mRWS
=wUry
-END PGP SIGNATURE-

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

Re: [openstack-dev] [nova] Hypervisor support matrix now in GIT

[Daniel P. Berrange]

On Thu, Feb 05, 2015 at 10:22:08AM -0600, Matt Riedemann wrote:
> 
> 
> On 2/5/2015 4:49 AM, Daniel P. Berrange wrote:
> >On Thu, Feb 05, 2015 at 11:40:46AM +0100, Andreas Jaeger wrote:
> >>On 02/05/2015 11:31 AM, Daniel P. Berrange wrote:
> >>>This is a message to alert everyone to the fact that the old hypervisor
> >>>support matrix on the wiki[1], should really be considered obsolete
> >>>[...]
> >>
> >>In that case, I suggest to remove it's contents and just leave a pointer
> >>to the new location,
> >
> >See my point about it being the only place with info about the out of
> >tree Docker & PowerKVM drivers. I want to give them time to setup a
> >support matrix in their own GIT repo before removing the only source
> >of info about them.
> >
> >I will be updating the wiki page to warn people about the new location
> >though.
> >
> >Regards,
> >Daniel
> >
> 
> There might be some confusion on PowerKVM here, the pKVM support is in tree
> in the libvirt driver, that's what the PowerKVM third party CI is running
> against.
> 
> The new as of last week PowerVM driver in stackforge [1] (and older PowerVC
> driver in stackforge [2]) are different and shouldn't be in the hypervisor
> support matrix wiki or the in-tree hypervisor support table.


Ok, so in this page

   https://wiki.openstack.org/wiki/HypervisorSupportMatrix#Features

The 'PowerKVM' column doesn't mention libvirt and it links to this page

  www.ibm.com/systems/power/software/linux/powerlinux/powerkvm


So I assumed that was referring to one of the stackforge drivers, and
that info on power-kvm-with-libvirt was simply missing entirely from
the wiki page.  So we'd need someone to update the new in-tree docs
with power-kvm-on-libvirt information from scratch.

If anyone still cares about the non-libvirt Power drivers they can
maintain a support matrix in stackforge for that.

> The only thing I'd say about the pKVM support in the in-tree matrix is what
> it's distro support is, i.e. if I have latest Fedora ppc64 will nova
> libvirt/qemu work with it?  How about Ubuntu?

The approach we've been trying to take with libvirt recently is that
each new platform we support (whether a new architecture, or new
libvirt hypervisor) would explicitly declare the minimum required
libvirt version for that platform.

eg the Parallels driver added

  MIN_LIBVIRT_PARALLELS_VERSION = (1, 2, 12)

And in init_host()

if (CONF.libvirt.virt_type == 'parallels' and
not self._host.has_min_version(MIN_LIBVIRT_PARALLELS_VERSION)):


Given that Power support in libvirt requires some minimum version,
we'll need to add a MIN_LIBVIRT_POWER_KVM_VERSION and check for
that.

These min version numbers aren't something I've attempted to capture
in the context of the feature matrix.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing 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] [Trove] Core reviewer update

[Denis Makogon]

+1

Congratulations Peter, Victoria and Edmond.


On Thu, Feb 5, 2015 at 6:26 PM, Nikhil Manchanda  wrote:

> Hello Trove folks:
>
> Keeping in line with other OpenStack projects, and attempting to keep
> the momentum of reviews in Trove going, we need to keep our core-team up
> to date -- folks who are regularly doing good reviews on the code should
> be brought in to core and folks whose involvement is dropping off should
> be considered for removal since they lose context over time, not being
> as involved.
>
> For this update I'm proposing the following changes:
> - Adding Peter Stachowski (peterstac) to trove-core
> - Adding Victoria Martinez De La Cruz (vkmc) to trove-core
> - Adding Edmond Kotowski (edmondk) to trove-core
> - Removing Michael Basnight (hub_cap) from trove-core
> - Removing Tim Simpson (grapex) from trove-core
>
> For context on Trove reviews and who has been active, please see
> Russell's stats for Trove at:
> - http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
> - http://russellbryant.net/openstack-stats/trove-reviewers-90.txt
>
> Trove-core members -- please reply with your vote on each of these
> proposed changes to the core team. Peter, Victoria and Eddie -- please
> let me know of your willingness to be in trove-core. Michael, and Tim --
> if you are planning on being substantially active on Trove in the near
> term, also please do let me know.
>
> Thanks,
> Nikhil
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] barbican resource delete question

[Steve Heyman]

Greetings all -

Today Barbican provides a “soft” delete of resources – they remain in our 
database, tagged as deleted.

We are looking at adding quotas 
(https://review.openstack.org/#/c/132091/10/specs/kilo/quota-support-for-barbican-resources.rst)
 and that introduces some pain for testing or usage patterns with many 
create/delete cycles as the quota (which includes the soft deleted resources) 
would fill up quickly making the project unusable.

Would like to gather some thoughts on how others handle this situation – making 
all deletes hard deletes isn’t an option due to things like audit trails.

[cid:41BC778A-3AB5-49E3-9292-515E9FD3B83C]
__
OpenStack Development Mailing 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][oslo.db][nova] TL; DR Things everybody should know about Galera

[Mike Bayer]

Attila Fazekas  wrote:

> I have a question related to deadlock handling as well.
> 
> Why the DBDeadlock exception is not caught generally for all api/rpc request ?
> 
> The mysql recommendation regarding to Deadlocks [1]:
> "Normally, you must write your applications so that they are always 
> prepared to re-issue a transaction if it gets rolled back because of a 
> deadlock."
> 
> Now the services are just handling the DBDeadlock in several places.
> We have some logstash hits for other places even without galera.
> 
> Instead of throwing 503 to the end user, the request could be repeated 
> `silently`.
> 
> The users would be able repeat the request himself,
> so the automated repeat should not cause unexpected new problem.
> 
> The retry limit might be configurable, the exception needs to be watched 
> before
> anything sent to the db on behalf of the transaction or request.
> 
> Considering all request handler as potential deadlock thrower seams much 
> easier than,
> deciding case by case.  

typically, deadlocks in “normal” applications are very unusual, except in
well-known “hot-spots” where they are known to occur. The deadlock-retry can
be applied to all methods as a whole, but this generally adds a lot more
weight to the app, in that methods need to be written with the assumption
that this is to occur. It complicates the potential that perhaps one method
that is already wrapped in a retry needs to call upon another method that is
also wrapped - should the wrappers organize themselves into a single “wrap”
for the whole thing?   It’s not like this is a bad idea, but it does have 
potential
implications.

Part of the promise of enginefacade [1] is that, if applications used the
decorator version (which unfortunately not all apps week to want to), we
could build this “smart retry” functionality right into the decorator and we 
would in fact gain the ability to do this pretty easily.

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




> [1] http://dev.mysql.com/doc/refman/5.0/en/innodb-deadlocks.html
> 
> - Original Message -
>> From: "Matthew Booth" 
>> To: openstack-dev@lists.openstack.org
>> Sent: Thursday, February 5, 2015 10:36:55 AM
>> Subject: Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody 
>> should know about Galera
>> 
>> On 04/02/15 17:05, Sahid Orentino Ferdjaoui wrote:
 * Commit will fail if there is a replication conflict
 
 foo is a table with a single field, which is its primary key.
 
 A: start transaction;
 B: start transaction;
 A: insert into foo values(1);
 B: insert into foo values(1); <-- 'regular' DB would block here, and
  report an error on A's commit
 A: commit; <-- success
 B: commit; <-- KABOOM
 
 Confusingly, Galera will report a 'deadlock' to node B, despite this not
 being a deadlock by any definition I'm familiar with.
>>> 
>>> Yes ! and if I can add more information and I hope I do not make
>>> mistake I think it's a know issue which comes from MySQL, that is why
>>> we have a decorator to do a retry and so handle this case here:
>>> 
>>>  
>>> http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sqlalchemy/api.py#n177
>> 
>> Right, and that remains a significant source of confusion and
>> obfuscation in the db api. Our db code is littered with races and
>> potential actual deadlocks, but only some functions are decorated. Are
>> they decorated because of real deadlocks, or because of Galera lock
>> contention? The solutions to those 2 problems are very different! Also,
>> hunting deadlocks is hard enough work. Adding the possibility that they
>> might not even be there is just evil.
>> 
>> Incidentally, we're currently looking to replace this stuff with some
>> new code in oslo.db, which is why I'm looking at it.
>> 
>> Matt
>> --
>> Matthew Booth
>> Red Hat Engineering, Virtualisation Team
>> 
>> Phone: +442070094448 (UK)
>> GPG ID:  D33C3490
>> GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [nova] Hypervisor support matrix now in GIT

[Kurt Taylor]

On Thu, Feb 5, 2015 at 10:22 AM, Matt Riedemann 
wrote:

>
>
> On 2/5/2015 4:49 AM, Daniel P. Berrange wrote:
>
>> On Thu, Feb 05, 2015 at 11:40:46AM +0100, Andreas Jaeger wrote:
>>
>>> On 02/05/2015 11:31 AM, Daniel P. Berrange wrote:
>>>
 This is a message to alert everyone to the fact that the old hypervisor
 support matrix on the wiki[1], should really be considered obsolete
 [...]

>>>
>>> In that case, I suggest to remove it's contents and just leave a pointer
>>> to the new location,
>>>
>>
>> See my point about it being the only place with info about the out of
>> tree Docker & PowerKVM drivers. I want to give them time to setup a
>> support matrix in their own GIT repo before removing the only source
>> of info about them.
>>
>> I will be updating the wiki page to warn people about the new location
>> though.
>>
>> Regards,
>> Daniel
>>
>>
> There might be some confusion on PowerKVM here, the pKVM support is in
> tree in the libvirt driver, that's what the PowerKVM third party CI is
> running against.
>
> The new as of last week PowerVM driver in stackforge [1] (and older
> PowerVC driver in stackforge [2]) are different and shouldn't be in the
> hypervisor support matrix wiki or the in-tree hypervisor support table.
>
> I can't wait for the day when there will be one power driver to rule them
> all and Frodo will have to destroy it in Mount Doom to avoid confusion.
>
> The only thing I'd say about the pKVM support in the in-tree matrix is
> what it's distro support is, i.e. if I have latest Fedora ppc64 will nova
> libvirt/qemu work with it?  How about Ubuntu?
>
> [1] http://git.openstack.org/cgit/stackforge/nova-powervm/
> [2] http://git.openstack.org/cgit/stackforge/powervc-driver/
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>

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


Thanks Matt, I'll include that in the patch.

Kurt Taylor (krtaylor)
__
OpenStack Development Mailing 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] Core reviewer update

[Nikhil Manchanda]

Hello Trove folks:

Keeping in line with other OpenStack projects, and attempting to keep
the momentum of reviews in Trove going, we need to keep our core-team up
to date -- folks who are regularly doing good reviews on the code should
be brought in to core and folks whose involvement is dropping off should
be considered for removal since they lose context over time, not being
as involved.

For this update I'm proposing the following changes:
- Adding Peter Stachowski (peterstac) to trove-core
- Adding Victoria Martinez De La Cruz (vkmc) to trove-core
- Adding Edmond Kotowski (edmondk) to trove-core
- Removing Michael Basnight (hub_cap) from trove-core
- Removing Tim Simpson (grapex) from trove-core

For context on Trove reviews and who has been active, please see
Russell's stats for Trove at:
- http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
- http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

Trove-core members -- please reply with your vote on each of these
proposed changes to the core team. Peter, Victoria and Eddie -- please
let me know of your willingness to be in trove-core. Michael, and Tim --
if you are planning on being substantially active on Trove in the near
term, also please do let me know.

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

Re: [openstack-dev] [nova] Hypervisor support matrix now in GIT

[Kurt Taylor]

On Thu, Feb 5, 2015 at 4:31 AM, Daniel P. Berrange 
wrote:

> Hi Team Nova,
>
> This is a message to alert everyone to the fact that the old hypervisor
> support matrix on the wiki[1], should really be considered obsolete.
>
> The canonical location for it going forward will be
>
>http://docs.openstack.org/developer/nova/support-matrix.html
>
> That URL shows current GIT snapshot, releases will get their own URL
> when the time comes.
>
> The source for this document is part of Nova GIT in the path
>
>doc/source/support-matrix.ini
>
> The docs are auto-generated from that ini file using a sphinx extension
>
>doc/ext/support_matrix.py
>
> The CSS styling is in
>
>doc/source/_static/support-matrix.css
>
> Some things to note here
>
>  - The new doc was populated based on the contents of the old wiki page
> from
>about two months ago, so if there have been additions to the wiki in
> that
>time, they might not all have been captured - depends how good I was at
>figuring out changes.
>
>  - Improvements to the content and/or HTML styling should obviously be sent
>as patches to Nova GIT in the files mentioned above, via normal Gerrit
>review practice.
>
>  - Since it is in GIT, the support matrix is now able to record information
>per release branch of Nova. So users can be clear about what features
>their release of Nova supports, as opposed to playing guessing games.
>
>  - The in-tree document only covers features of the in-tree Nova drivers.
>As such it does not include information about Docker or PowerKVM or
>the (now deleted) BareMetal drivers. My currently suggestion is that
>people maintaining out of tree drivers, should reuse the sphinx
> extension
>to format their own support matrix ini file in their local GIT repo.
>

I think that maybe you have confused PowerKVM with PowerVM.  The PowerVM
driver was removed, but PowerKVM support is in tree with libvirt.


>
>I've not deleted the wiki page, since in the short term it is the
>only place with info about Docker/PowerKVM.
>
>  - When submitting a new virt driver for merge in Nova, you should add
>it to the docs/source/support-matrix.ini file. This clearly shows
>reviewers what feature set your initial code submission supports
>
>For example, the Parallels team who have been adding Parallels support
>to Libvirt for Kilo should submit a patch to update this matrix prior
>to Kilo release.
>
>Likewise people working on making libvirt KVM run on Arm and PPC
>should update the matrix, since it only records x86 support status
>for Libvirt currently.
>

I will push a patch to update the matrix shortly.


>
>  - When adding support for new APIs to existing drivers, rememeber to
>update the docs/source/support-matrix.ini file to list the new
>capability for the driver you changed.
>
>  - If adding new public API features, consider whether to add a new
>feature line item to the docs/source/support-matrix.ini if it is
>likely users need to know about support status across drivers.
>
>  - Against each line item feature, there is note about whether the
>feature is considered mandatory to support in all drivers. The
>current support matrix only lists 2 features as mandatory - start
>and stop of instances. Everything else was left as optional on the
>basis that at least one existing in-tree driver doesn't support
>the feature.
>
>It is very important to note that this is a *tentative* list. The
>decision about mandatory vs optional features is subject to change
>as it has *not* undergone detailed critique by Nova core team at
>this time. IOW, we might make more features mandatory to support
>in the future. TBD.
>
>  - There is clear scope for making the existing feature list more
>fine grained. For example there are many different ways to configure
>block storage for guests and only a few of them are captured in the
>current support matrix. Likewise for networking, and many other
>aspects of guest configuration.
>
>
> Sean has added the support matrix as a discussion item for today's
> Nova meeting, to evaluate what if any changes we need to make to it
> in the near term to better capture the current thoughts of Nova team
> about support status.
>
>   https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
>
> So either send questions in this thread or join the IRC meeting
>
> Regards,
> Daniel
>
> [1] https://wiki.openstack.org/wiki/HypervisorSupportMatrix
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
> :|
>
> __
> OpenStack Development Mai

Re: [openstack-dev] [nova] Hypervisor support matrix now in GIT

[Matt Riedemann]

On 2/5/2015 4:49 AM, Daniel P. Berrange wrote:

On Thu, Feb 05, 2015 at 11:40:46AM +0100, Andreas Jaeger wrote:

On 02/05/2015 11:31 AM, Daniel P. Berrange wrote:

This is a message to alert everyone to the fact that the old hypervisor
support matrix on the wiki[1], should really be considered obsolete
[...]


In that case, I suggest to remove it's contents and just leave a pointer
to the new location,


See my point about it being the only place with info about the out of
tree Docker & PowerKVM drivers. I want to give them time to setup a
support matrix in their own GIT repo before removing the only source
of info about them.

I will be updating the wiki page to warn people about the new location
though.

Regards,
Daniel



There might be some confusion on PowerKVM here, the pKVM support is in 
tree in the libvirt driver, that's what the PowerKVM third party CI is 
running against.


The new as of last week PowerVM driver in stackforge [1] (and older 
PowerVC driver in stackforge [2]) are different and shouldn't be in the 
hypervisor support matrix wiki or the in-tree hypervisor support table.


I can't wait for the day when there will be one power driver to rule 
them all and Frodo will have to destroy it in Mount Doom to avoid confusion.


The only thing I'd say about the pKVM support in the in-tree matrix is 
what it's distro support is, i.e. if I have latest Fedora ppc64 will 
nova libvirt/qemu work with it?  How about Ubuntu?


[1] http://git.openstack.org/cgit/stackforge/nova-powervm/
[2] http://git.openstack.org/cgit/stackforge/powervc-driver/

--

Thanks,

Matt Riedemann


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

[openstack-dev] [nova][neutron] Passthrough of PF's from SR-IOV capable devices.

[Steve Gordon]

Hi all,

In the current SR-IOV implementation there is a check in Nova (specifically 
_get_device_type in nova/virt/libvirt/driver.py) that determines if a given PCI 
device is:

- a normal PCI device,
- an SR-IOV physical function (PF); or
- an SR-IOV virtual function (VF).

If it's a normal PCI device or a virtual function it's considered fair game for 
passthrough, if it's a PF it's not (considered to be owned by the host). There 
are two things I am a little unclear on and was hoping someone might be able to 
help me understand:

1) If the device is a "normal" PCI device, but is a network card, am I still 
able to take advantage of the advanced syntax added circa Juno to define the 
relationship between that card and a given physical network so that the 
scheduler can place accordingly (and does this still use the ML2 mech drvier 
for SR-IOV even though it's a "normal" device.

2) There is no functional reason from a Libvirt/Qemu perspective that I 
couldn't pass through a PF to a guest, and some users have expressed surprise 
to me when they have run into this check in the Nova driver. I assume in the 
initial implementation this was prevented to avoid a whole heap of fun 
additional logic that is required if this is allowed (e.g. check that no VFs 
from the PF being requested are already in use, remove all the associated VFs 
from the pool when assigning the PF, who gets allowed to use PFs versus VFs 
etc.). Am I correct here or is there another reason that this would be 
undesirable to allow in future - assuming such checks can also be designed - 
that I am missing?

Thanks,

Steve

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

Re: [openstack-dev] [horizon][keystone]

[Steve Martinelli]

Thanks Ioram,

>From the keystone side: the one issue with listing IdPs is that some may
be private, so we're now looking to exploit the apache plugin data in the
environment (https://review.openstack.org/#/c/142743/), thus from the
horizon side the only data they need to send over would be the protocol
that the IdP uses.

What i'm taking away from some of the comments is to preserve the usual
(username and password) flow, and maybe it'll be easier to just list off
the protocols in a separate drop down (SAML and OpenID Connect).

Steve

Ioram Schechtman Sette  wrote on 02/05/2015 06:04:36 AM:

> From: Ioram Schechtman Sette 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 02/05/2015 06:14 AM
> Subject: Re: [openstack-dev] [horizon][keystone]
> 
> Hi Thai,
> 
> I agree with Anton that the names are not intuitive for users.

> I would use something like:
> - Local authentication (for local credentials)
> - ?? (I also have no idea of what is a Default protocol)
> - Authenticate using  (something which 
> is easy to the user understand that he could use or not - this is 
> for the discovery service or remote IdP)

> Here in the University of Kent we used another approach.
> Instead of selecting the method using a "list/combo" box, we present
> all the options in a single screen.
> I think it's not beautiful, but functional.
> I think it would be easier to the user if they could have all the 
> options in a single interface, since it doesn't become too much 
> loaded (visually polluted).
> 
> [image removed] 
> Regards,
> Ioram
> 
> 2015-02-05 9:20 GMT+00:00 Anton Zemlyanov :
> Hi,
> 
> I guess "Credentials" is login and password. I have no idea what is 
> "Default Protocol" or "Discovery Service".
> The proposed UI is rather embarrassing.
> 
> Anton
> 
> On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran  wrote:
> Hi all,
> 
> I have been helping with the websso effort and wanted to get some 
feedback.
> Basically, users are presented with a login screen where they can 
> select: credentials, default protocol, or discovery service.
> If user selects credentials, it works exactly the same way it works 
today.
> If user selects default protocol or discovery service, they can 
> choose to be redirected to those pages.
> 
> Keep in mind that this is a prototype, early feedback will be good.
> Here are the relevant patches:
> https://review.openstack.org/#/c/136177/
> https://review.openstack.org/#/c/136178/
> https://review.openstack.org/#/c/151842/
> 
> I have attached the files and present them below:
> 
> [image removed] [image removed] [image removed] [image removed] 
> 
> 

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

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

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

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

[Matthew Booth]

On 05/02/15 15:02, Alexis Lee wrote:
> Sean Dague said on Wed, Feb 04, 2015 at 09:51:30AM -0500:
>> As there has been a bunch of concern around patches getting lost or
>> stuck, I wanted to re-announce the fact that we've got a dedicated slot
>> at the weekly Nova meeting for just those sorts of things.
> 
> The slot turned into everyone talking at once fairly quickly this week.
> That led to several patches not getting a real discussion.
> 
> May I suggest stricter moderation? EG a short phase to propose items,
> then work through them 1 by 1. Or, we take items one by one according to
> who shouts fastest but ask people not to interrupt.

+1

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

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

Re: [openstack-dev] [neutron] IPv6 Status

[Brian Haley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/05/2015 05:38 AM, Ihar Hrachyshka wrote:
> On 02/05/2015 09:14 AM, Andreas Scheuring wrote:
>> Hi,
> 
>> is there a central place where I can find a matrix (or something similar)
>> that shows what is currently supposed to work in the sense of IPv6
>> Networking?

I'm not sure there's a matrix, but there are a number of updates coming in
Kilo, check https://blueprints.launchpad.net/neutron/kilo for the IPv6 ones.

Most of the bug fixes are tagged and can be found here:

https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6

>> I also had a look at a couple of blueprints out there, but I'm looking
>> for a simple overview containing what's supported, on which features are
>> people working on and what's future. I mean all the good stuff for Tenant
>> Networks like
> 
>> - SNAT - FloatingIP - External Provider Networks - DVR - fwaas, 
>> vpnaas,...

There will be no default SNATv6 or Floating IPv6 as decided at the Kilo Summit
- - they're really not necessary if the VM has a global address.

Probably the best thing for you to do is spin-up a devstack with IPv6 enabled
and see how things work, putting these in local.conf will enable both DVR and
IPv6 (assuming you have RECLONE=yes):

Q_DVR_MODE=dvr_snat

# to enable IPv4 and IPv6
IP_VERSION=4+6

>> and also about the Host Network - e.g. vxlan/gre tunneling via ipv6 host
>> network...
> 
> AFAIK it's not supported by OVS yet. The last time I talked to a guy who
> worked on the feature, he told me that it will take some time, and it will
> probably be VXLAN only. (Unless someone steps in.)

OVS/VXLAN w/IPv6 is not supported, pointer to thread:

http://openvswitch.org/pipermail/discuss/2015-January/016344.html

- -Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU05XhAAoJEIYQqpVulyUozYgH/iple8dvRoyE0Z+9aUObcYxi
uh5jkly4zeCs7OUEOlMDeAsboKBdgEc+kSLzu6ianqd1f8CtHXG1iROn2YTb7z05
HN5bPByT9pZW5eu5lSN0KsOvlnpJCvK/Kz6xbW+cJJ03YCmHZkto64SEOcnJJ1iq
mFFnKOjxDlxHUGJyt0GNto7hQNV9RUSVA6fk7omsn5UnSP4RcZJjqbXCFW4mmU9j
ppUGB+dnGeQyKq0egPN9bzNRudSfVKA6mne5ipxOhYNzju5LBp84xqIAlBq0w7k7
8SIYsdDIrmPjWwckr6+39QHFSCUPqbNmRyH2H28CoYpd7ZQuvPZ2osseNX0AahA=
=ahi+
-END PGP SIGNATURE-

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

Re: [openstack-dev] [Neutron] fixed ip info shown for port even when dhcp is disabled

[John Belamaric]

The pluggable IPAM [1] is intended to support the scenario you described below. 
That is, a fixed IP is provided for the port by IPAM, and then the DHCP server 
is programmed to return that IP for that MAC or DUID (for IPv6). If I 
understand correctly, your concern then is:

1) The DHCP server may not allow such programming;
2) The DHCP server may not be able to provide an IP allocation via any means 
other than DHCP (ie, no API to pre-allocate the IP)

I would think then, what you are asking for is the ability to attach an 
interface to a layer 2 network without also giving it an IP in any subnet(s) 
that are on that network. Seems like a reasonable request, but I am not sure 
what would be involved in implementing that.

Additionally, we would need some mechanism to update the port with the IP after 
it is allocated via the DHCP server. Otherwise, I don't think all the iptables 
rules and such will be properly configured, so you probably won't be able to 
pass traffic beyond the local subnet. Not sure on that though.


[1] - 
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/neutron-ipam.html



From: Padmanabhan Krishnan mailto:kpr...@yahoo.com>>
Reply-To: Padmanabhan Krishnan mailto:kpr...@yahoo.com>>
Date: Thursday, February 5, 2015 at 1:47 AM
To: John Belamaric mailto:jbelama...@infoblox.com>>, 
"OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when 
dhcp is disabled

Hi John,
Sure, this may not be in the scope of IPAM as originally proposed in [1]. Am 
just trying to see if there can be a solution for this scenario using IPAM.

What I had in mind is also a centrally managed IPAM and not each VM allocating 
its own IP address. Let me clarify.

It's not an uncommon requirement to use a commercial DHCP server in an 
enterprise/DC. I am referring to it as external DHCP server from Openstack's 
perspective.
One scenario of deployment is when IPAM is done through Openstack and in which 
case, the  can be programmed in the external DHCP 
server, assuming they have standard API's for that. Then, the VM will get the 
openstack assigned IP address from the DHCP server when it boots up. You also 
suggested this and sure, it's not a problem here.

Now, another scenario and that's of interest is when IPAM itself is done 
directly using the commercial DHCP server for various reasons. I am just trying 
to see how this model will work (or can be extended to work) for this case. 
What's the role of pluggable IPAM [1] in this scenario? If at all there's a way 
to tell the external DHCP server, do your own allocation and return an IP 
address for me for this , then this IP address can be returned 
during the allocate_ip API by the pluggable IPAM? But, I am not sure, an 
external DHCP server will have this flexibility.
Then, in such scenarios, the only way is to not allocate an IP address during 
create_port. When the VM comes up and sends a DHCP request the commercial DHCP 
server responds with an address. The pluggable IPAM then can use its own 
method, and when it discovers the IP address of the VM, it can call to 
update_port with the IP address.
Any other way?

[1] - 
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/neutron-ipam.html

Thanks,
Paddu


On Tuesday, February 3, 2015 8:57 AM, John Belamaric 
mailto:jbelama...@infoblox.com>> wrote:


Hi Paddu,

I think this is less an issue of the pluggable IPAM than it is the Neutron 
management layer, which requires an IP for a port, as far as I know. If the 
management layer is updated to allow a port to exist without a known IP, then 
an additional IP request type could be added to represent the placeholder you 
describing.

However, doing so leaves IPAM out of the hands of Neutron and out of the hands 
of the external (presumably authoritative) IPAM system. This could lead to 
duplicate IP issues since each VM is deciding its own IP without any 
centralized coordination. I wouldn't recommend this approach to managing your 
IP space.

John

From: Padmanabhan Krishnan mailto:kpr...@yahoo.com>>
Reply-To: Padmanabhan Krishnan mailto:kpr...@yahoo.com>>
Date: Wednesday, January 28, 2015 at 4:58 PM
To: John Belamaric mailto:jbelama...@infoblox.com>>, 
"OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when 
dhcp is disabled

Some follow up questions on this.

In the specs, i see that during a "create_port",  there's provisions to query 
the external source by  "Pluggable IPAM" to return the IP.
This works fine for cases where the external source (say, DHCP server) can be 
queried for the IP address when a launch happens.

Is there a provision to have the flexibility of a "late IP assignment"?

I am thinking of cases, like the temporary unavailability of external IP source 
or lack of standard

Re: [openstack-dev] [nova] memory reporting for huge pages

[Alexis Lee]

Chris Friesen said on Wed, Feb 04, 2015 at 05:35:55PM -0600:
> it can be very difficult to determine whether
> a given flavor/image is bootable within the network

This implies to me that what you'd really like is to be able to ask the
scheduler whether a given flavor/image is bootable. The Gantt team are
working on breaking the scheduler out of Nova, as part of this it will
become a consultant rather than part of the chain-of-command for booting
instances (IE, a proxy). That should make such a query relatively easy
to support.


Alexis
-- 
Nova Engineer, HP Cloud.  AKA lealexis, lxsli.

__
OpenStack Development Mailing 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] stuck patches at the nova IRC meeting

[Alexis Lee]

Sean Dague said on Wed, Feb 04, 2015 at 09:51:30AM -0500:
> As there has been a bunch of concern around patches getting lost or
> stuck, I wanted to re-announce the fact that we've got a dedicated slot
> at the weekly Nova meeting for just those sorts of things.

The slot turned into everyone talking at once fairly quickly this week.
That led to several patches not getting a real discussion.

May I suggest stricter moderation? EG a short phase to propose items,
then work through them 1 by 1. Or, we take items one by one according to
who shouts fastest but ask people not to interrupt.


Alexis
-- 
Nova Engineer, HP Cloud.  AKA lealexis, lxsli.

__
OpenStack Development Mailing 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 Foundation] Finding people to work on the EC2 API in Nova

[Sean Dague]

On 02/05/2015 07:01 AM, Alexandre Levine wrote:
> Davanum,
> 
> We've added the devstack support. It's in our stackforge repository.
> https://github.com/stackforge/ec2-api/tree/master/contrib/devstack
> 
> Best regards,
>   Alex Levine

I've converted it to a devstack external plugin structure in this review
- https://review.openstack.org/#/c/153206/

so that will make using this as simple as

enable_plugin ec2-api https://github.com/stackforge/ec2-api

Once that merges.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [nova][cinder][neutron][security] Rootwrap on root-intensive nodes

[Nicolas Trangez]

On Thu, 2015-02-05 at 08:27 -0500, Tristan Cacqueray wrote:
> Thus if we want to emulate OpenSSH design, the rpc call would also
> need to
> carry authentication data in order to prevent unwanted activity. And
> the
> rpc daemon would then need to enforce some kind of acl/policy.

Sounds a lot like what the DBus system bus implements/provides to me...
And it took quite some time to get that done.

(Note: I'm not proposing its usage in any way)

Nicolas


__
OpenStack Development Mailing 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][cinder][neutron][security] Rootwrap on root-intensive nodes

[Tristan Cacqueray]

On 02/04/2015 01:13 PM, Clint Byrum wrote:
> Excerpts from Tristan Cacqueray's message of 2015-02-04 09:02:19 -0800:
>> On 02/04/2015 06:57 AM, Daniel P. Berrange wrote:
>>> (4) I think that ultimately we need to ditch rootwrap and provide a proper
>>> privilege separated, formal RPC mechanism for each project.
>>>
>>> eg instead of having a rootwrap command, or rootwrap server attempting
>>> to validate safety of
>>>
>>> qemu-img create -f qcow2 
>>> /var/lib/nova/instances/instance1/disk.qcow2
>>>
>>> we should have a  nova-compute-worker daemon running as root, that accepts
>>> an RPC command from nova-compute running unprivileged. eg
>>>
>>> CreateImage("instane0001", "qcow2", "disk.qcow")
>>>
>>> This immediately makes it trivial to validate that we're not trying to
>>> trick qemu-img into overwriting some key system file.
>>>
>>> This is certainly alot more work than trying to patchup rootwrap, but
>>> it would provide a level of security that rootwrap can never achieve IMHO.
>>>
>>
>> This 4th idea sounds interesting, though we are assuming this new service
>> running as root would be exempt of bug, especially if it uses the same
>> libraries as non-root services... For example a major bug in python would
>> give attacker direct root access while the rootwrap solution would in
>> theory keep the intruder at the sudo level...
>>
> 
> I don't believe that anyone assumes the new service would be without
> bugs. 

I meant less bug than another solution. Such RPC service daemon will
eventually requires quite some code to be robust, which could lead to
more bugs.


> But just like the OpenSSH team saw years ago, privilege separation
> means that you can absolutely know what is running as root, and what is
> not. So when you decide to commit your resources to code audits, you
> _start_ with the things that run with elevated privileges.
> 

Not quite sure to follow here... OpenSSH is using privilege separation after
authentication, e.g. the root-based process is doing the authentication while
the external data processing is done through an unprivileged process.

If I understand correctly Daniel's solution (4), it's to have a semantic on the
privileged actions to avoid mis-usage (like inject command in a sudo call).

Thus if we want to emulate OpenSSH design, the rpc call would also need to
carry authentication data in order to prevent unwanted activity. And the
rpc daemon would then need to enforce some kind of acl/policy.

The amount of code to be audited could arguably be higher with such design.


>>
>> For completeness, I'd like to propose a more long-term solution:
>>
>> (5) Get ride of root! Seriously, OpenStack could support security mechanism
>> like SELinux or AppArmor in order to properly isolate service and let them
>> run what they need to run.
>>
>> For what it worth, the underlying issue here is having a single almighty 
>> super
>> user: root and thus we should, at least, consider solution that remove the
>> need of such powers (e.g. kernel module loading, ptrace or raw socket).
>>
> 
> We don't need a security module to drop all of those capabilities
> entirely and run as a hobbled root user. By my measure, this process for
> nova-compute would only need CAP_NET_ADMIN, CAP_SYS_ADMIN and CAP_KILL.
> These capabilities can be audited per-agent and even verified as needed
> simply by running integration tests without each one to see what breaks.
>
Capabilities might be a candidate as well, but they don't cover every cases
and lack granularity...

SECCOMP filters might be good enough too.


>> Beside, as long as sensitive process are not contained at the system level,
>> the attack surface for a non-root user is still very wide (e.g. system calls,
>> setuid binaries, ipc, ...)
>>
>>
>> While this might sounds impossible to implement upstream because it's too
>> vendor specific or just because of other technicals difficulties,
>> I guess it still deserves a mention in this thread.
>>
> 
> I think OpenStack can do its part by making privilege separation a
> reality for the security sensitive parts of OpenStack, and that will
> ease pressure to implement strong controls in any security modules the
> Linux distros ship with.
> 
That would be a great step forward indeed. Having some kind of privilege
separation would surely help a lot to properly configure security modules.

Regards,
Tristan



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

[openstack-dev] [Manila] Kilo-2 is done / deadlines for Kilo-3

[Ben Swartzlander]

The K-2 milestone was wrapped up last night! Now we can turn our 
attention to merging the rest of the features for K-3. Thanks again to 
the reviewers who helped make K-2 possible.


And a reminder to submitters: feature proposal freeze is in exactly 4 
weeks. That means any new feature not submitted to gerrit and mergeable 
by March 5 will not be considered for Kilo. New features also must be 
merged before March 19 or they will get pushed out to L.


And I hope it goes without saying, but please don't wait until the day 
before the deadline just because you can. We make no guarantees about 
anything getting merged, and the sooner your patch is up on gerrit, the 
better its chances are.


-Ben Swartzlander


__
OpenStack Development Mailing 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 Foundation] Finding people to work on the EC2 API in Nova

[Jeremy Stanley]

On 2015-02-02 14:45:53 +0300 (+0300), Alexandre Levine wrote:
> On 2/2/15 12:58 PM, Daniel P. Berrange wrote:
[...]
> > We need to at least discuss & iterate on this a few times
> > online, so that we can take advantage of the f2f time for any
> > remaining harder parts of the discussion.
[...]
> how do you usually do those online discussions? I mean what is the
> tooling?

You're doing it right now.

But also, comments on review.openstack.org for your proposed spec,
ad hoc discussions in appropriate IRC channels[1] and possibly more
officially in weekly IRC meetings[2].

[1] https://wiki.openstack.org/wiki/IRC
[2] https://wiki.openstack.org/wiki/Meetings
-- 
Jeremy Stanley

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

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

[Attila Fazekas]

- Original Message -
> From: "Matthew Booth" 
> To: openstack-dev@lists.openstack.org
> Sent: Thursday, February 5, 2015 12:32:33 PM
> Subject: Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody 
> should know about Galera
> 
> On 05/02/15 11:01, Attila Fazekas wrote:
> > I have a question related to deadlock handling as well.
> > 
> > Why the DBDeadlock exception is not caught generally for all api/rpc
> > request ?
> > 
> > The mysql recommendation regarding to Deadlocks [1]:
> > "Normally, you must write your applications so that they are always
> >  prepared to re-issue a transaction if it gets rolled back because of a
> >  deadlock."
> 
> This is evil imho, although it may well be pragmatic. A deadlock (a real
> deadlock, that is) occurs because of a preventable bug in code. It
> occurs because 2 transactions have attempted to take multiple locks in a
> different order. Getting this right is hard, but it is achievable. The
> solution to real deadlocks is to fix the bugs.
>
> 
> Galera 'deadlocks' on the other hand are not deadlocks, despite being
> reported as such (sounds as though this is due to an implementation
> quirk?). They don't involve 2 transactions holding mutual locks, and
> there is never any doubt about how to proceed. They involve 2
> transactions holding the same lock, and 1 of them committed first. In a
> real deadlock they wouldn't get as far as commit. This isn't any kind of
> bug: it's normal behaviour in this environment and you just have to
> handle it.
>
> > Now the services are just handling the DBDeadlock in several places.
> > We have some logstash hits for other places even without galera.
> 
> I haven't had much success with logstash. Could you post a query which
> would return these? This would be extremely interesting.

Just use this:
message: "DBDeadlock"

If you would like to exclude the lock wait timeout ones:
message: "Deadlock found when trying to get lock"


> > Instead of throwing 503 to the end user, the request could be repeated
> > `silently`.
> > 
> > The users would be able repeat the request himself,
> > so the automated repeat should not cause unexpected new problem.
> 
> Good point: we could argue 'no worse than now', even if it's buggy.
> 
> > The retry limit might be configurable, the exception needs to be watched
> > before
> > anything sent to the db on behalf of the transaction or request.
> > 
> > Considering all request handler as potential deadlock thrower seams much
> > easier than,
> > deciding case by case.
> 
> Well this happens at the transaction level, and we don't quite have a
> 1:1 request:transaction relationship. We're moving towards it, but
> potentially long running requests will always have to use multiple
> transactions.
> 
> However, I take your point. I think retry on transaction failure is
> something which would benefit from standard handling in a library.
> 
> Matt
> --
> Matthew Booth
> Red Hat Engineering, Virtualisation Team
> 
> Phone: +442070094448 (UK)
> GPG ID:  D33C3490
> GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
> 
> __
> OpenStack Development Mailing 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] [OSSN 0043] glibc 'GHOST' vulnerability can allow remote code execution

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

glibc 'GHOST' vulnerability can allow remote code execution
- ---

### Summary ###
A serious vulnerability in the GNU C library (glibc) gethostbyname*
functions can allow an attacker to perform remote code execution with
the privileges of the application that calls the gethostbyname*
function. The vulnerable functions are used by a vast number of
programs, effectively any time a network socket is used in a linux
system, so the full exploitability of this vulnerability will not
become known immediately.

The publishers of this vulnerability, Qualys, have announced a proof of
concept exploit for the Exim mail server, which bypasses operating
system protections such as ASLR and DEP.


### Affected Services / Software ###
All versions running on Linux installations with a vulnerable glibc
library.

### Discussion ###
The GNU C library (glibc), from versions 2.2 to 2.17 inclusive, has
a group of vulnerable functions for hostname/address resolution. There
is a buffer overflow in the __nss_hostname_digits_dots() function which
is used by the gethostbyname*() group of functions. The maximum amount
of memory that can be overwritten is sizeof(char *), i.e. 4 bytes on
typical 32-bit systems and 8 bytes on typical 64-bit systems.

These low-level functions are linked by many other C/C++ programs and
interpreted languages like Python, Perl and Bash, so this vulnerability
is insidious and will appear in cases where it would not at first seem
obvious. There are many cases in a typical Linux installation where
these functions will be used, generally wherever a hostname is resolved
to an IP address, although in newer applications an IPv6 compatible
function, getaddinfo() may be used instead.

This vulnerability could let an attacker remotely execute code in cases
where they control the input to a function that performs hostname
resolution. There are no currently-known OpenStack-specific
exploitation paths associated with this vulnerability. However, the
Python socket library presents a gethostbyname() wrapper around the
glibc function, and there are various ways in which this could be
exposed.

### Recommended Actions ###
The glibc library is loaded into memory when a process that uses it
starts up, so to fix the vulnerability, glibc should be updated to a
non-vulnerable version (2.18 or newer) and all services which use glibc
should be restarted to replace the version in memory. Due to the number
of places where these vulnerable functions are used, this effectively
means that vulnerable systems must be restarted after updating glibc.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0043
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1415416
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: CVE-2015-0235
Source advisory:
https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU02eRAAoJEJa+6E7Ri+EVXu8IAIDuL3LbQKtSvLiyleAqF3nd
WUTiqdAIRc6cf7xJdMyVm8W0ISOE88YpscSeT55xbiaPVL7joro0vVP7CLhFg5E3
wRzT9W+abAj62EFU7SOjLGiKEWbIHa+Aa3W+r/bPXCJACP3V1XCEnZya+g6GuXT7
JbV9EYYeprAGWQNvSEA8g49YYq44aIxuGqDd6ti6pye3wTgf5e0emGP1BIS/i3TI
htQfp4F+zGtRukjWdg3HVoLOKtZYqLHEJT0EUEcq4hzTFKEFhk6x93zYIrRhil+d
+Jm70OeeKosS64Ebe+06sc2g1jTVNryvozxl95MYR09axkfgd2myjxDZMB5Ak+o=
=NlVl
-END PGP SIGNATURE-

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

[openstack-dev] [Murano] Translation usage suggestion

[Ekaterina Chernova]

Hi all!

Recently we have discussed the log and exception translations and have not
come to a decision.

I've made some research and found a useful documents:


   - https://wiki.openstack.org/wiki/LoggingStandards#Log_Translation
   - https://wiki.openstack.org/wiki/Translations


Here two main points, that I can highlight

* "*Exception text should **not** be marked for translation,*
because if an exception occurs there is no guarantee that the
translation machinery will be functional."

** "Debug level log messages are not translated"*

Some projects do not follow these rules, but I suggest to take them into
consideration and perform the following actions:

   - First of all, we should remove gettext utils usage and replace it with
   oslo.i18n;
   - Remove exception messages translation;
   - Add log translation to info, warn and error log level (and
   log.exception which creates log.error message).

Note, that different log levels can be separated to different files. It's
also supported to have different log files for different languages.

What do you think?
__
OpenStack Development Mailing 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 Foundation] Finding people to work on the EC2 API in Nova

[Davanum Srinivas]

Alexandre,

very cool. Next step would be what we call a dsvm job that uses this
devstack hook. Example i am most familiar is is nova-docker's
check-tempest-dsvm-docker job:

https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/nova-docker.yaml
(also see zuul/layout.yaml)

thanks,
dims

On Thu, Feb 5, 2015 at 7:01 AM, Alexandre Levine
 wrote:
> Davanum,
>
> We've added the devstack support. It's in our stackforge repository.
> https://github.com/stackforge/ec2-api/tree/master/contrib/devstack
>
> Best regards,
>   Alex Levine
>
> On 1/31/15 2:21 AM, Davanum Srinivas wrote:
>>
>> Alexandre, Randy,
>>
>> Are there plans afoot to add support to switch on stackforge/ec2-api
>> in devstack? add tempest tests etc? CI Would go a long way in
>> alleviating concerns i think.
>>
>> thanks,
>> dims
>>
>> On Fri, Jan 30, 2015 at 1:24 PM, Bias, Randy  wrote:
>>>
>>> As you know we have been driving forward on the stack forge project and
>>> it¹s our intention to continue to support it over time, plus reinvigorate
>>> the GCE APIs when that makes sense. So we¹re supportive of deprecating
>>> from Nova to focus on EC2 API in Nova.  I also think it¹s good for these
>>> APIs to be able to iterate outside of the standard release cycle.
>>>
>>>
>>>
>>> --Randy
>>>
>>> VP, Technology, EMC Corporation
>>> Formerly Founder & CEO, Cloudscaling (now a part of EMC)
>>> +1 (415) 787-2253 [google voice]
>>> TWITTER: twitter.com/randybias
>>> LINKEDIN: linkedin.com/in/randybias
>>> ASSISTANT: ren...@emc.com
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 1/29/15, 4:01 PM, "Michael Still"  wrote:
>>>
 Hi,

 as you might have read on openstack-dev, the Nova EC2 API
 implementation is in a pretty sad state. I wont repeat all of those
 details here -- you can read the thread on openstack-dev for detail.

 However, we got here because no one is maintaining the code in Nova
 for the EC2 API. This is despite repeated calls over the last 18
 months (at least).

 So, does the Foundation have a role here? The Nova team has failed to
 find someone to help us resolve these issues. Can the board perhaps
 find resources as the representatives of some of the largest
 contributors to OpenStack? Could the Foundation employ someone to help
 us our here?

 I suspect the correct plan is to work on getting the stackforge
 replacement finished, and ensuring that it is feature compatible with
 the Nova implementation. However, I don't want to preempt the design
 process -- there might be other ways forward here.

 I feel that a continued discussion which just repeats the last 18
 months wont actually fix the situation -- its time to "break out" of
 that mode and find other ways to try and get someone working on this
 problem.

 Thoughts welcome.

 Michael

 --
 Rackspace Australia

 ___
 Foundation mailing list
 foundat...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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



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

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

[openstack-dev] [devstack]Cannot install devstack on CI slave

[Eduard Matei]

Hi,
For two days i've been trying to install devstack.
It keeps failing at configuring neutron, i figured out that it needs two
new params in localrc: PUBLIC_NETWORK_GATEWAY and NETWORK_GATEWAY
On my dev machine i managed to install it manually with these params, but
on the CI slave it fails with error:

2015-02-05 12:05:39.329 | + sudo route add -net 10.150.11.0/16 gw 10.140.0.1
2015-02-05 12:05:39.440 | route: netmask doesn't match route address


Localrc:

[[local|localrc]]
HOST_IP=10.140.0.2
FLAT_INTERFACE=eth0
FIXED_RANGE=10.150.11.0/16
FIXED_NETWORK_SIZE=255
FLOATING_RANGE=10.140.0.0/16
PUBLIC_NETWORK_GATEWAY=10.140.0.2
NETWORK_GATEWAY=10.150.11.1
MULTI_HOST=0
SYSLOG=False
SCREEN_LOGDIR=/opt/stack/logs/screen-logs
LOGFILE=/opt/stack/logs/stack.sh.log
ADMIN_PASSWORD=*
MYSQL_PASSWORD=*
RABBIT_PASSWORD=*
SERVICE_PASSWORD=*
SERVICE_TOKEN=*


Anyone seen this error or has any idea what i should put in the config?


Similar log (different values for localrc):

http://packages.cloudfounders.com/ci_logs/33/130733/40/check/openvstorage-cinder-functionality/ad97bc5/console.html


Thanks,

Eduard


PS. Why did nobody report this issue so far? Either i'm doing
something wrong in the localrc or nobody is installing the latest
devstack. https://bugs.launchpad.net/devstack/+bug/1417635


-- 

*Eduard Biceri Matei, Senior Software Developer*
www.cloudfounders.com
 | eduard.ma...@cloudfounders.com



*CloudFounders, The Private Cloud Software Company*

Disclaimer:
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed.
If you are not the named addressee or an employee or agent responsible
for delivering this message to the named addressee, you are hereby
notified that you are not authorized to read, print, retain, copy or
disseminate this message or any part of it. If you have received this
email in error we request you to notify us by reply e-mail and to
delete all electronic files of the message. If you are not the
intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.
E-mail transmission cannot be guaranteed to be secure or error free as
information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the content of this
message, and shall have no liability for any loss or damage suffered
by the user, which arise as a result of e-mail transmission.
__
OpenStack Development Mailing 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 Foundation] Finding people to work on the EC2 API in Nova

[Alexandre Levine]

Davanum,

We've added the devstack support. It's in our stackforge repository.
https://github.com/stackforge/ec2-api/tree/master/contrib/devstack

Best regards,
  Alex Levine

On 1/31/15 2:21 AM, Davanum Srinivas wrote:

Alexandre, Randy,

Are there plans afoot to add support to switch on stackforge/ec2-api
in devstack? add tempest tests etc? CI Would go a long way in
alleviating concerns i think.

thanks,
dims

On Fri, Jan 30, 2015 at 1:24 PM, Bias, Randy  wrote:

As you know we have been driving forward on the stack forge project and
it¹s our intention to continue to support it over time, plus reinvigorate
the GCE APIs when that makes sense. So we¹re supportive of deprecating
from Nova to focus on EC2 API in Nova.  I also think it¹s good for these
APIs to be able to iterate outside of the standard release cycle.



--Randy

VP, Technology, EMC Corporation
Formerly Founder & CEO, Cloudscaling (now a part of EMC)
+1 (415) 787-2253 [google voice]
TWITTER: twitter.com/randybias
LINKEDIN: linkedin.com/in/randybias
ASSISTANT: ren...@emc.com






On 1/29/15, 4:01 PM, "Michael Still"  wrote:


Hi,

as you might have read on openstack-dev, the Nova EC2 API
implementation is in a pretty sad state. I wont repeat all of those
details here -- you can read the thread on openstack-dev for detail.

However, we got here because no one is maintaining the code in Nova
for the EC2 API. This is despite repeated calls over the last 18
months (at least).

So, does the Foundation have a role here? The Nova team has failed to
find someone to help us resolve these issues. Can the board perhaps
find resources as the representatives of some of the largest
contributors to OpenStack? Could the Foundation employ someone to help
us our here?

I suspect the correct plan is to work on getting the stackforge
replacement finished, and ensuring that it is feature compatible with
the Nova implementation. However, I don't want to preempt the design
process -- there might be other ways forward here.

I feel that a continued discussion which just repeats the last 18
months wont actually fix the situation -- its time to "break out" of
that mode and find other ways to try and get someone working on this
problem.

Thoughts welcome.

Michael

--
Rackspace Australia

___
Foundation mailing list
foundat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation


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






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

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

[Matthew Booth]

On 05/02/15 11:11, Sahid Orentino Ferdjaoui wrote:
>> I'm still confused as to how this code got there, though. We shouldn't
>> be hitting Galera lock contention (reported as deadlocks) if we're using
>> a single master, which I thought we were. Does this mean either:
> 
> I guess we can hit a lock contention even in single master.

I don't think so, but you can certainly still have real deadlocks.
They're bugs, though.

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

__
OpenStack Development Mailing 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][oslo.db][nova] TL; DR Things everybody should know about Galera

[Matthew Booth]

On 05/02/15 11:01, Attila Fazekas wrote:
> I have a question related to deadlock handling as well.
> 
> Why the DBDeadlock exception is not caught generally for all api/rpc request ?
> 
> The mysql recommendation regarding to Deadlocks [1]:
> "Normally, you must write your applications so that they are always 
>  prepared to re-issue a transaction if it gets rolled back because of a 
> deadlock."

This is evil imho, although it may well be pragmatic. A deadlock (a real
deadlock, that is) occurs because of a preventable bug in code. It
occurs because 2 transactions have attempted to take multiple locks in a
different order. Getting this right is hard, but it is achievable. The
solution to real deadlocks is to fix the bugs.

Galera 'deadlocks' on the other hand are not deadlocks, despite being
reported as such (sounds as though this is due to an implementation
quirk?). They don't involve 2 transactions holding mutual locks, and
there is never any doubt about how to proceed. They involve 2
transactions holding the same lock, and 1 of them committed first. In a
real deadlock they wouldn't get as far as commit. This isn't any kind of
bug: it's normal behaviour in this environment and you just have to
handle it.

> Now the services are just handling the DBDeadlock in several places.
> We have some logstash hits for other places even without galera.

I haven't had much success with logstash. Could you post a query which
would return these? This would be extremely interesting.

> Instead of throwing 503 to the end user, the request could be repeated 
> `silently`.
> 
> The users would be able repeat the request himself,
> so the automated repeat should not cause unexpected new problem.

Good point: we could argue 'no worse than now', even if it's buggy.

> The retry limit might be configurable, the exception needs to be watched 
> before
> anything sent to the db on behalf of the transaction or request.
> 
> Considering all request handler as potential deadlock thrower seams much 
> easier than,
> deciding case by case.  

Well this happens at the transaction level, and we don't quite have a
1:1 request:transaction relationship. We're moving towards it, but
potentially long running requests will always have to use multiple
transactions.

However, I take your point. I think retry on transaction failure is
something which would benefit from standard handling in a library.

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

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