[openstack-dev] [neutron][taas] TaaS IRC schedule

[Soichi Shigeta]

 Hi,

TaaS IRC meetings on 12/21, 12/28 and 1/4 being
  canceled because of Christmas and New Year holidays.

  We will resume TaaS IRC on 1/11/2017.

  Have a nice holiday!

  Sincerely,
  Soichi


__
OpenStack Development Mailing List (not for 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][infra] Python3 change in OpenStack CI

[Andreas Jaeger]

On 2016-12-13 08:29, Andreas Jaeger wrote:
> As part of the move to run master and stable/newton on Xenial, we
> disabled testing python 3.4 on these newer branches.
> 
> Now, for testing we have:
> * python3.4 on older branches (stable/liberty and stable/mitaka) - on a
> trusty VM
> * python3.5 on newer branches (stable/newton, master and future stable
> branches)
> 
> In the past Clark had added python 3.5 jobs to all repos that had python
> 3.4 jobs as non-voting and asked to make them voting. Some projects have
> still not done this.
> 
> I encourage every project to:
> 1) Make python 3.5 testing voting if not done already.
> 2) Add python 3.5 testing if there's no testing currently
> 3) Remove python 3.4 jobs if they have no older branches (only master)
> 
> Please review your existing jobs and send changes to project-config repo,


FYI, I've started removing old trusty jobs and python34 jobs on many
projects - and made python35 voting when possible and python34 was voting.

https://review.openstack.org/#/q/project:openstack-infra/project-config+branch:master+topic:trusty-cleanup

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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

Re: [openstack-dev] [kuryr] Kuryr Kubernetes Demo

[Pete Birley]

Ilya,

That's a great demo, thanks for sharing! - I'm quite interested in how we
could potentially use this in collaboration with Kolla-Kubernetes to
provide a unified Kubernetes-OpenStack environment, and will explore this
over the next couple of weeks.

Cheers

Pete

On Mon, Dec 19, 2016 at 2:11 AM, Ilya Chukhnakov 
wrote:

> Hello, fellow kuryrs!
>
> I'd like to share a demo [1] that shows how Kuryr enables OpenStack
> Neutron networking for Kubernetes and allows Pods to access Nova VMs and
> vice versa.
>
> [1] https://asciinema.org/a/51qn06lgz78gcbzascpl2du4w
>
> ---
> Regards,
>
> Ilya
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

[image: Port.direct] 

Pete Birley / Director
pete@port.direct / +447446862551

*PORT.*DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Port.direct is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [swift] limit/marker/count behavior when limit not given

[Matthew Oliver]

On Mon, Dec 19, 2016 at 11:54 AM, Monty Taylor  wrote:

> Hey all,
>
> In the docs for listing containers:
>
> http://developer.openstack.org/api-ref/object-storage/?
> expanded=show-account-details-and-list-containers-detail
>
> it says that limit is optional. However, if you give it
> full_listing=True, swiftclient always sends at least a second query with
> a marker set to the name of the last element of the original return
> value. This leads me believe there is a default value for limit server
> side that swiftclient is trying to account for.
>
> Looking through capabilities, it seems there is:
>
> swift.account_listing_limit
> swift.container_listing_limit
>
>
Yeah there is a server side limit, and as you surmise you can find it when
you query the cluster for the information (swift capabilities or  curl -i
http:///info |python -m json.tool).

The swift client will look at capabilities and be smart about it.

We limit the size of the response to the server size limit. full_listing is
swiftclient trying to be helpful and paginate for you.


> I'm guessing swift.account_listing_limit would apply to getting the list
> of containers, and container_listing_limit would apply to listing
> objects in a container, yeah?
>

Exactly, yes.


>
> Relatedly, there is a X-Account-Container-Count header. Testing against
> rackspace public shows me that it contains the total count of containers
> even if I provide a limit parameter:
>
> >>> r=c.get('/?format=json&limit=2')
> >>> r.headers['X-Account-Container-Count']
> '4'
>
> Would that also be the case if I had hit the
> swift.account_listing_limit limit?


Yup, the container-count (account metadata) and object-count (container
metadata) are how many are in the account/container NOT in the response. As
it's gathering the metadata information from the account/container. If you
fire off a HEAD (or stat in swiftclient) you'll get the same counts.




> I ask because it seems like it would be ever-so-mildly more efficient to
> look at the returned count and the total count and only do the loop if
> there is a mismatch - but I'm curious if there is something I should
> account for I'm not seeing. (I'm working on making direct REST calls,
> but starting with swiftclient's behavior to make sure I'm doing things
> right)
>
> Also - the question about limit behavior when not given seems like it
> could be added to the docs - and I'd be happy to make that patch if I'm
> reading things right.
>

Looking at the API docs briefly, this could be more clearly stated.
Especially as the first paragraph in the Account GET mentions if you get
'limit' back then there are more objects, and the first paragraph of the
Container GET mentions there being a default limit on the server side if
the parameters are omitted:
http://developer.openstack.org/api-ref/object-storage/?expanded=show-account-details-and-list-containers-detail,show-container-details-and-list-objects-detail

So yeah could definitely be cleaned up.


> Thanks!
> Monty
>
> No thank you :)

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


I was talking to Richard from horizon while they've been building a new
Swift UI, and for displaying many objects, they've mentioned liking someway
of knowing if there are any more results, so they can continue to paginate
as people scroll etc, our discussions have gone further then just knowing
if there's more now. And so I plan on having a play with helping them
paginate better on the Swift side for Horizon.

At the moment, if you get limit results back (where limit is what you
define or defaults to the server default) then there is a good chance there
are more objects. Just keeping track of the total can be a little
problematic as It's possible for that count to grow or shrink between
requests. So if you hit limit, then there is probably more and do another
request is easiest.

Regards,
Matt
__
OpenStack Development Mailing List (not for 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] Weekly wrap-up

[Richard Jones]

Yep, Rob's correct, that's the intent. There's also plenty of non-WIP
high priority patches in the starred list :-)

On 16 December 2016 at 23:31, Rob Cresswell (rcresswe)
 wrote:
> I think the intent is to get eyes on those patches, to prevent a 1000 line
> rewrite only for a core to say “I think this is a bad idea”. So for
> important patches, its probably good to get earlier feedback.
>
> Rob
>
>
> On 16 Dec 2016, at 08:13, Radomir Dopieralski 
> wrote:
>
> I wonder if it really makes sense to put WIP patches on the priority list. I
> think it's a bit counter-productive, considering that the prioritizing of
> patches was supposed to make them merge faster -- but we don't want to merge
> WIP patches, do we?
>
> On Fri, Dec 16, 2016 at 5:31 AM, Richard Jones 
> wrote:
>>
>> Hi folks,
>>
>> No Horizon meeting next week! I'll be around the week after (28th
>> December) so if anyone else is around we can totally have a meeting
>> then.
>>
>> Things that have happened this week, including in the team meeting[1]
>>
>> Ocata-2 was tagged!
>>
>> xstatic-angular-bootstrap 2.2.0.0 was released, which promptly broke
>> Ocata-2 (and Ocata-1, you're welcome). We knew it was coming, and Rob
>> Cresswell had a compatibility patch in place ready to go, so master
>> was back to working within half an hour of the upper-constraints patch
>> enabling 2.2.0.0! If you notice anything busted in Horizon related to
>> bootstrap please file a bug!
>>
>> I'd like to remind everyone that we have a blueprint in play which
>> describes our approach to API microversions[2]. Rob has a patch which
>> will land imminently that implements the core of the design. Please
>> hold off implementing your own version settings/checks! We've seen a
>> few microversion-related patches appear recently, and that's great to
>> see, we just need to make sure we're all heading in the same
>> direction.
>>
>> I've put up the first patch using ui-router which rather dramatically
>> alters the Swift UI[3], so I'd like some feedback on it please.
>>
>> We've got about five(ish) weeks until Feature Freeze[4], folks, so all
>> the help we can get on the priority patches[5] (reviews or coding
>> help) is appreciated!
>>
>>
>> I hope you all get to have some time off, and have an enjoyable holiday,
>>
>>Richard
>>
>> [1]
>> http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-12-14-20.00.html
>> [2] https://blueprints.launchpad.net/horizon/+spec/microversion-support
>> [3] https://review.openstack.org/#/c/350523
>> [4] https://releases.openstack.org/ocata/schedule.html
>> [5]
>> https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status:open
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [neutron] Where will Neutron go in future?

[zhi]

Hi, Nate, thanks for your reply.

May I ask a little stupid question? What's the difference between fwaas and
security group? In my opinion, fwaas and security group are both using
linux iptables now. So, what's the differences between them?

Thanks
Zhi Chang
__
OpenStack Development Mailing List (not for 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] Where will Neutron go in future?

[Nate Johnston]

The neutron-fwaas team is an active and enthusiastic participant in the
Neutron stadium, and is targeting FWaaS v2 to complete in the Ocala
release. Once FWaaS v2 is complete, the neutron-fwaas team will start
deprecating FWaaS v1 in the Pike cycle.

--N.

On Sun, Dec 18, 2016 at 9:56 PM zhi  wrote:

> Deal all.
>
> I have some questions about what will Neutron does in next releases.
>
> As far as I know, LBaaSv2 will be deprecated in next 2 releases, maybe P
> release, we will not see LBaaSv2 anymore, isn't it? Instead of LBaaSv2(
> HAProxy driver based ), Octavia will be the only LBaaS solution, isn't it?
>
> What's about namespace based L3 router? Do we have any ideas about NFV
> solution in L3 router just like Octavia?
>
> Finally, where will Neutron *aaS go in future? Now, vpnaas was not part of
> neutron governance. What about fwaas? Do we deprecated it in next releases?
>
> I wish someone could give some exact words about these. I will thanks a
> lot. :)
>
>
> Thanks
> Zhi Chang
>
>
> __
>
> OpenStack Development Mailing 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] Where will Neutron go in future?

[zhi]

Deal all.

I have some questions about what will Neutron does in next releases.

As far as I know, LBaaSv2 will be deprecated in next 2 releases, maybe P
release, we will not see LBaaSv2 anymore, isn't it? Instead of LBaaSv2(
HAProxy driver based ), Octavia will be the only LBaaS solution, isn't it?

What's about namespace based L3 router? Do we have any ideas about NFV
solution in L3 router just like Octavia?

Finally, where will Neutron *aaS go in future? Now, vpnaas was not part of
neutron governance. What about fwaas? Do we deprecated it in next releases?

I wish someone could give some exact words about these. I will thanks a
lot. :)


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

[openstack-dev] [kuryr] Kuryr Kubernetes Demo

[Ilya Chukhnakov]

Hello, fellow kuryrs!

I'd like to share a demo [1] that shows how Kuryr enables OpenStack Neutron 
networking for Kubernetes and allows Pods to access Nova VMs and vice versa.

[1] https://asciinema.org/a/51qn06lgz78gcbzascpl2du4w 


---
Regards,

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

Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate Johnston as service LTs

[Hirofumi Ichihara]

+1

On 2016/12/16 8:58, Armando M. wrote:

Hi neutrinos,

I would like to propose Ryan and Nate as the go-to fellows for 
service-related patches.


Both are core in their repos of focus, namely neutron-dynamic-routing 
and neutron-fwaas, and have a good understanding of the service 
framework, the agent framework and other bits and pieces. At this 
point, entrusting them with the responsibility is almost a formality.


Cheers,
Armando

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


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


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

Re: [openstack-dev] [neutron] proposing Miguel Lavalle as neutron core and Brian Haley as L3 Lt

[Hirofumi Ichihara]

+1

On 2016/12/16 8:14, Armando M. wrote:

Hi neutrinos,

Miguel Lavalle has been driving the project forward consistently and 
reliably. I would like to propose him to be entrusted with +2/+A 
rights in the areas he's been most prolific, which are L3 and DHCP.


At the same time, I'd like to propose Brian Haley as our next Chief L3 
Officer. Both of them have worked with Carl Baldwin extensively and 
that can only be a guarantee of quality.


Cheers,
Armando

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


__
OpenStack Development Mailing 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] [swift] limit/marker/count behavior when limit not given

[Monty Taylor]

Hey all,

In the docs for listing containers:

http://developer.openstack.org/api-ref/object-storage/?expanded=show-account-details-and-list-containers-detail

it says that limit is optional. However, if you give it
full_listing=True, swiftclient always sends at least a second query with
a marker set to the name of the last element of the original return
value. This leads me believe there is a default value for limit server
side that swiftclient is trying to account for.

Looking through capabilities, it seems there is:

swift.account_listing_limit
swift.container_listing_limit

I'm guessing swift.account_listing_limit would apply to getting the list
of containers, and container_listing_limit would apply to listing
objects in a container, yeah?

Relatedly, there is a X-Account-Container-Count header. Testing against
rackspace public shows me that it contains the total count of containers
even if I provide a limit parameter:

>>> r=c.get('/?format=json&limit=2')
>>> r.headers['X-Account-Container-Count']
'4'

Would that also be the case if I had hit the
swift.account_listing_limit limit?

I ask because it seems like it would be ever-so-mildly more efficient to
look at the returned count and the total count and only do the loop if
there is a mismatch - but I'm curious if there is something I should
account for I'm not seeing. (I'm working on making direct REST calls,
but starting with swiftclient's behavior to make sure I'm doing things
right)

Also - the question about limit behavior when not given seems like it
could be added to the docs - and I'd be happy to make that patch if I'm
reading things right.

Thanks!
Monty

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

Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

[Tony Breeds]

On Fri, Dec 16, 2016 at 04:52:30PM +, Jeremy Stanley wrote:
> On 2016-12-16 13:58:58 +1100 (+1100), Tony Breeds wrote:
> [...]
> > Due to a failure in the release pipline [1] some of the release
> > jobs haven't been done.
> [...]
> > [1] 
> > http://lists.openstack.org/pipermail/release-job-failures/2016-December/000324.html
> [...]
> 
> The failure looks an awful lot like an incidence of
> https://github.com/pyca/cryptography/issues/2750 which suggests this
> could be due to Liberty-era cryptography 1.1.2 being incompatible
> with libssl 1.0.2g on Ubuntu Xenial. For gate jobs this wouldn't
> present a problem because Gerrit tells Zuul what branch a change is
> destined for, but with tags there is no such context so we ended up
> trying to build that release tarball on Xenial even though we tested
> the changes leading up to it for stable/liberty on Trusty.

Thanks for the explanation Jeremy.

Given that we can't just re-run the job and expect success what options do we
have to publish an 11.0.2 tarball?

I'm assuming this will be a somewhat manual process, given that is there
anything preventing us from tagging glance liberty-eol?

Yours Tony.


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

Re: [openstack-dev] [all][stable][ptls] Tagging liberty as EOL

[Tony Breeds]

On Fri, Dec 16, 2016 at 05:41:31PM -0500, Emilien Macchi wrote:
> Hey Tony,
> 
> Could we also EOL tripleo-incubator and tripleo-image-elements
> stable/icehouse please?

Yup, No problem.

Tony.


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

Re: [openstack-dev] [neutron] multinode CI jobs in the gate

[Armando M.]

On 18 December 2016 at 12:28, John Schwarz  wrote:

> Hey,
>
> There is already an experimental job called
> "gate-tempest-dsvm-neutron-dvr-ha-multinode-full-ubuntu-xenial-nv"
> (which was added by [1]).
>
> However, the job is currently a "one dvr_snat nodes, two dvr nodes"
> deployment (instead of the "two dvr_snat nodes, one dvr node" that it
> should be in order to make L3HA work there). The patch which makes the
> final transition is being worked on in [2], and it's ready to be
> merged afaik. Once it merges, we'll have a DVR+HA gate in the
> experimental queue.
>

Excellent! thanks for the update, John!

Cheers,
Armando


>
> John.
>
> [1]: https://review.openstack.org/#/c/383742/
> [2]: https://review.openstack.org/#/c/383827/
>
> On Fri, Dec 16, 2016 at 2:23 AM, Armando M.  wrote:
> > Hi Neutrinos,
> >
> > Infra patch proposed in [1] got me thinking again about what we shall do
> > when it comes to multinode testing in the gate and how to focus our
> testing
> > and CI efforts upstream going forward. My line of thinking has always
> been
> > that multinode resources should be devoted to configurations whose
> coverage
> > fully benefit from the inherent nature of the distributed deployment, and
> > that means giving priority to DVR+HA and demote other configurations that
> > use centralized routing.
> >
> > I know that some of you in team have worked on this, but I am a bit
> behind
> > on the latest status update. Any good soul willing to bring a strapped
> (for
> > time) PTL up to speed?
> >
> > Cheers,
> > Armando
> >
> > [1] https://review.openstack.org/#/c/411263/
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> John Schwarz,
> Senior Software Engineer,
> Red Hat.
>
> __
> OpenStack Development Mailing 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] [meteos] Meteos Released !!

[Telles Nobrega]

Denis, I believe it would make sense to use containers for all the benefits
that containers bring.

On the other hand, I believe that using Sahara brings an easy of
configuration to Meteos, because deploying and configuring Spark
automatically on Meteos would be a bit of rework.

Nonetheless, It does raise the question if Sahara should work with
containers as well as VM.

On Fri, Dec 16, 2016 at 6:09 PM, Denis Makogon  wrote:

> Hello Hiroyuki.
>
> Congrats on public release. So, i'd like to clarify few things. I know
> that for running ML jobs Meteos needs Spark instances and Meteos talks to
> Sahara to deploy them. So, i'm not quite familiar with infrastructure
> drives in Sahara, but would that make sense to work with Docker containers
> rather than deploying virtual machines, the thing is spinning up a VM takes
> a lot time, but Docker container takes 300ms to start.
>
> Kind regards,
> Denis Makogon
>
>
> 2016-12-16 7:14 GMT+02:00 Hiroyuki Eguchi :
>
>> Hi all,
>>
>>
>>
>> I'm pleased to announce the release of Meteos.
>>
>>
>>
>> Meteos is Machine Learning as a Service (MLaaS) in Apache Spark.
>>
>>
>>
>> Meteos allows users to analyze huge amount of data and predict a value by
>> data mining and machine learning algorithms.
>>
>> Meteos create a workspace of Machine Learning via sahara spark plugin and
>> manage some resources and jobs regarding Machine Learning.
>>
>>
>>
>> Everyone can participate in this project as a user, developer, reviewer
>> in the same way as another OpenStack projects.
>>
>>
>>
>> Please give it a try.
>>
>> If you find any requests and comments, please feel free to feedback.
>>
>>
>>
>> See the following documents to find the relevant information:
>>
>>
>>
>> [Wiki]
>>
>> https://wiki.openstack.org/wiki/Meteos
>>
>>
>>
>> [Installation Document]
>>
>> https://wiki.openstack.org/wiki/Meteos/Devstack
>>
>>
>>
>> [Examples]
>>
>> Predict a Sales Figures by using LinearRegression Model
>>
>> https://wiki.openstack.org/wiki/Meteos/ExampleLinear
>>
>>
>>
>> Make a Decision to buy a stock by using DecisionTree Model
>>
>> https://wiki.openstack.org/wiki/Meteos/ExampleDecisionTree
>>
>>
>>
>> Recommend a Movie by using Recommendation Model
>>
>> https://wiki.openstack.org/wiki/Meteos/ExampleRecommend
>>
>>
>>
>> Search Synonyms by using Word2Vec Model
>>
>> https://wiki.openstack.org/wiki/Meteos/ExampleWord2Vec
>>
>>
>>
>>
>>
>> Thanks.
>>
>> Hiroyuki Eguchi
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
[image: Red Hat] 
Telles Nobrega | Software Engineer
Red Hat Brasil
T: +55 11 3529-6000 | M: +55 11 9 9910-1689
Av. Brigadeiro Faria Lima 3900, 8° Andar. São Paulo, Brasil.
RED HAT | TRIED. TESTED. TRUSTED. Saiba porque em redhat.com

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

Re: [openstack-dev] [neutron] multinode CI jobs in the gate

[John Schwarz]

Hey,

There is already an experimental job called
"gate-tempest-dsvm-neutron-dvr-ha-multinode-full-ubuntu-xenial-nv"
(which was added by [1]).

However, the job is currently a "one dvr_snat nodes, two dvr nodes"
deployment (instead of the "two dvr_snat nodes, one dvr node" that it
should be in order to make L3HA work there). The patch which makes the
final transition is being worked on in [2], and it's ready to be
merged afaik. Once it merges, we'll have a DVR+HA gate in the
experimental queue.

John.

[1]: https://review.openstack.org/#/c/383742/
[2]: https://review.openstack.org/#/c/383827/

On Fri, Dec 16, 2016 at 2:23 AM, Armando M.  wrote:
> Hi Neutrinos,
>
> Infra patch proposed in [1] got me thinking again about what we shall do
> when it comes to multinode testing in the gate and how to focus our testing
> and CI efforts upstream going forward. My line of thinking has always been
> that multinode resources should be devoted to configurations whose coverage
> fully benefit from the inherent nature of the distributed deployment, and
> that means giving priority to DVR+HA and demote other configurations that
> use centralized routing.
>
> I know that some of you in team have worked on this, but I am a bit behind
> on the latest status update. Any good soul willing to bring a strapped (for
> time) PTL up to speed?
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/411263/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
John Schwarz,
Senior Software Engineer,
Red Hat.

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

Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate Johnston as service LTs

[Gary Kotton]

+1

From: "Armando M." 
Reply-To: OpenStack List 
Date: Friday, December 16, 2016 at 1:58 AM
To: OpenStack List 
Subject: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate Johnston as 
service LTs

Hi neutrinos,

I would like to propose Ryan and Nate as the go-to fellows for service-related 
patches.

Both are core in their repos of focus, namely neutron-dynamic-routing and 
neutron-fwaas, and have a good understanding of the service framework, the 
agent framework and other bits and pieces. At this point, entrusting them with 
the responsibility is almost a formality.

Cheers,
Armando

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

Re: [openstack-dev] [neutron] proposing Miguel Lavalle as neutron core and Brian Haley as L3 Lt

[Gary Kotton]

+1

From: "Armando M." 
Reply-To: OpenStack List 
Date: Friday, December 16, 2016 at 1:14 AM
To: OpenStack List 
Subject: [openstack-dev] [neutron] proposing Miguel Lavalle as neutron core and 
Brian Haley as L3 Lt

Hi neutrinos,

Miguel Lavalle has been driving the project forward consistently and reliably. 
I would like to propose him to be entrusted with +2/+A rights in the areas he's 
been most prolific, which are L3 and DHCP.

At the same time, I'd like to propose Brian Haley as our next Chief L3 Officer. 
Both of them have worked with Carl Baldwin extensively and that can only be a 
guarantee of quality.

Cheers,
Armando

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