Hi Jaesuk, The change in InfluxDB licensing was announced in the blog at,
https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/.
Up until that announcement, InfluxDB was planning on supporting all their
clustering and HA capabilities in the open-source ver
We are delighted to announce the release of:
keystoneauth1 2.8.0: Authentication Library for OpenStack Identity
This release is part of the newton release series.
With source available at:
http://git.openstack.org/cgit/openstack/keystoneauth
With package available at:
https://pypi.pyt
My understanding of Prometheus is that it doesn't support HA, fault-tolerant
clustering either.
The recommendation from the Prometheus developers for HA and
fault-tolerance/reliability is to run multiple Prometheus servers with one
server scraping metrics from another server.
To do something s
Aha, it's pretty interesting, I vote for Zun as well :)
2016-06-02 12:56 GMT+08:00 Fei Long Wang :
> +1 for Zun, I love it and it's definitely a good container :)
>
>
> On 02/06/16 15:46, Monty Taylor wrote:
> > On 06/02/2016 06:29 AM, 秀才 wrote:
> >> i suggest a name Zun :)
> >> please see the re
Hi László, as another alternative you could achieve something similar in
Monasca, without using the InfluxDB Relay project, by configuring multiple
Monasca Persisters each in a different consumer group, and with it's own
independent InfluxDB server instance. Not sure which is the better approach
On 06/02/2016 10:06 AM, Hochmuth, Roland M wrote:
> Hi Jaesuk, The change in InfluxDB licensing was announced in the blog at,
> https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/.
> Up until that announcement, InfluxDB was planning on supporting all thei
Hi Jeremy,
Please see my answers below:
On 31 May 2016 at 19:38, Jeremy Stanley wrote:
> On 2016-05-31 19:20:22 +0300 (+0300), Sergey Kraynev wrote:
> [...]
> > * *Second part related with changes with future repositories and*
> > important for Openstack Infra team *
> > JFYI, what we pl
Mark Voelker wrote:
On Jun 1, 2016, at 12:27 PM, Armando M. wrote:
[...]
To the best of my knowledge none of the *-aas projects are part of defcore, and
since [1] has no presence of vpn, fw, lb, nor planned, I thought I was on the
safe side.
Thanks for checking. You are correct: LBaaS, VPNa
Yanyan Hu wrote:
Aha, it's pretty interesting, I vote for Zun as well :)
I don't get to vote, but since I was the one to suggest Higgins in the
first place, I must admit that Zun sounds like a good alternative.
--
Thierry Carrez (ttx)
Hi,
During the discussion about accepting vitrage into the big tent[1], there was a
concern raised by a few people regarding whether Vitrage is suitable for a
public cloud. They were bothered that allowing each user to see the entire
cloud topology is not suitable in such environments.
It is
Hi Jamie
In my opinion no security token should have the potential to last
forever. This is a bad idea and can lead to all sorts of security
vulnerabilities, some of which you highlight below. I thus take issue
with your statement 'Ideally in a big system like this we only want to
validate a token
Hi all,
In early May we tagged/EOL'd several (13) projects. We'd like to do a
final round for a more complete set. We looked for projects meet one or more
of the following criteria:
- The project is openstack-dev/devstack, openstack-dev/grenade or
openstack/requirements
- The project has th
I think all networking-* repos should EOL too, since they are plugins to
neutron which is already EOL. I struggle to find a way that could maintain
their gate without neutron.
> On 02 Jun 2016, at 12:31, Tony Breeds wrote:
>
> Hi all,
>In early May we tagged/EOL'd several (13) projects. W
On 01/06/16 16:45, Joshua Harlow wrote:
Do u have any more details (perhaps an 'real-life' example that you can
walk us through) of this and how it played out. It'd be interesting to
hear (I believe it has happened a few times but I've never heard how it
was resolved or the details of it).
The
Hi Tony,
OpenStack-Ansible is just waiting for the requirements repository and the
swift repository kilo-eol tags. Once they're done we'd like to bump the
SHA's for our 'kilo' to the EOL tags of those two repositories, tag a
release, then do our own kilo-eol tag.
Thanks,
Jesse
IRC: odyssey4me
O
On 06/02/2016 04:02 AM, Monty Taylor wrote:
On 06/02/2016 10:06 AM, Hochmuth, Roland M wrote:
Hi Jaesuk, The change in InfluxDB licensing was announced in the blog at,
https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/.
Up until that announcement, Inf
On 06/02/2016 04:02 AM, Monty Taylor wrote:
On 06/02/2016 10:06 AM, Hochmuth, Roland M wrote:
Hi Jaesuk, The change in InfluxDB licensing was announced in the blog at,
https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/.
Up until that announcement, Inf
On Mon, May 23, 2016 at 10:58 AM, Elizabeth K. Joseph
wrote:
> Hi everyone,
>
> On Friday, June 3, from approximately 20:00 through 24:00 UTC Gerrit
> will be unavailable while we rename some projects.
>
> Currently, we plan on renaming the following projects:
>
> openstack/openstack-ansible-ironi
Hi there,
Due to obvious inactivity I proposed the removal of the Cue project team
from the "Big Tent" list of official OpenStack projects under Technical
Committee governance:
https://review.openstack.org/324412
Please comment on that review if you think it's the wrong call.
--
Thierry Car
On 2016-06-02 11:08:14 +0300 (+0300), Sergey Kraynev wrote:
[...]
> I am happy to hear, that you don't mind about it. We suppose, that
> the number of such repositories should not be more then 10.
> Probably the number will be about 5-10 repos. I suppose, that it's
> extremely big number.
[...]
Ye
> -Original Message-
> From: Monty Taylor [mailto:mord...@inaugust.com]
> Sent: 01 June 2016 13:54
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] State machines in Nova
>
> On 06/01/2016 03:50 PM, Andrew Laski wrote:
> >
> >
> > On Wed, Jun 1, 2016, at 05:5
Looking at some of the capabilities jinja2 has, it's hard to justify changing
the method already in place.
I think jinja2 can provide a clear and operational way for operators to
customize the dockerfiles as needed.
Kolla just hasn't applied them yet.
I'm extremely hesitant to agree on changing
Hi,
There are a few changes that seem to be lined up for Newton to make manila's
share access control, update_access(), workflow better [1] --
reduce races in DB updates, avoid non-atomic state transitions, and
possibly enable the workflow fit in a HA active-active manila
configuration (if not alr
Hi,
While importing Panko¹ into OpenStack, Andreas informed me that the jobs
"openstack-server-release-jobs" and "publish-to-pypi" were incompatible
and that the release team would know that. We actually want to publish
Panko as an OpenStack server and also to PyPI.
We already have both these job
Hi neutron-stable-maint members,
yesterday we released neutron 7.1.0 tarballs. Those tarballs are the last ones
that allowed patches that did not fulfil requirements of Phase II: "Phase II
(6-12 months): Only critical bugfixes and security patches are acceptable” [1]
For Neutron’s sake, at this
Excerpts from Gregory Haynes's message of 2016-06-01 12:50:19 -0500:
> Hello everyone,
>
> I'd like to propose adding Stephane Miller (cinerama) to the
> diskimage-builder core team. She has been a huge help with our reviews
> for some time now and I think she would make a great addition to our
>
Madhuri,
It looks both of us agree the idea of having heterogeneous set of nodes. For
the implementation, I am open to alternative (I supported the work-around idea
because I cannot think of a feasible implementation by purely using Heat,
unless Heat support "for" logic which is very unlikely t
We are psyched to announce the release of:
os-client-config 1.18.0: OpenStack Client Configuation Library
This release is part of the newton release series.
With source available at:
http://git.openstack.org/cgit/openstack/os-client-config
With package available at:
https://pypi.pytho
Hi all,
Evgeny Li, one of two core reviewers of fuel-astute project [1], could not
participate on this project anymore because of his high load on another
project.
I want to express my sincere gratitude for his help and great advices and
wish
good luck in his new project.
For safe and better avail
Thanks to everyone who helped collecting wiki use cases on that etherpad.
I tried to categorize the various use cases and I think they fit in 4
categories:
1/ Things that are already in the process of being moved to reference
websites or documentation
That would be the main "portal" page wi
On 06/02/2016 01:23 AM, Jamie Lennox wrote:
Hi All,
I'd like to bring to the attention of the wider security groups and
OpenStack users the Service Users Permissions [1] spec currently
proposed against keystonemiddleware.
To summarize quickly OpenStack has long had the problem of token
expi
Hongbin,
for the implementation of heterogeneous, I think we should avoid to talking
with nova or other service directly, which will bring lots of coding.
maybe the best way is to refactor our heat template, and let a bay support
several heat template when we scale-out new node or delete additiona
On Thu, Jun 2, 2016 at 12:04 AM, zhi wrote:
> The reason putting the routers namespaces behind the fip namespace is
> saving mac address tables in switches. In Centralized Virtual Router, there
> are many "qg" interfaces in the external bridge. Every "qg" interface may
> contains one or more
Hello,
I would like to propose that we make Deklan Dieterly (ddieterly) core on
freezer.
He has been a highly valuable developper for the past few month, mainly working
on integration testing for Freezer components.
He has also been helping a lot with features and Ux testing.
His work can be fo
On 01/06/16 13:50, Andrew Laski wrote:
This is a great point. I think most people have an implicit assumption
that the state machine will be exposed to end users via the API. I would
like to avoid that for exactly the reason you've mentioned. Of course
we'll want to expose something to users but
> On Jun 2, 2016, at 10:03 AM, Adam Young wrote:
>
> To do all of this right, however, requires a degree of introspection that we
> do not have in OpenStack. Trove needs to ask Nova "I want to do X, what role
> do I need?" and there is no where in the system today that this information
> li
Small correction for the final line of the last email.
I am proposing Deklan and not Saad as core.
- Pierre
From: Mathieu, Pierre-Arthur
Sent: Thursday, June 2, 2016 4:29:29 PM
To: openstack-dev@lists.openstack.org
Cc: freezer-eskimos
Subject: [openstack-d
On 06/02/2016 10:59 AM, Thierry Carrez wrote:
> Thanks to everyone who helped collecting wiki use cases on that etherpad.
>
> I tried to categorize the various use cases and I think they fit in 4
> categories:
>
> 1/ Things that are already in the process of being moved to reference
> websites or
Hi,
>From this link
https://github.com/openstack/networking-sfc/tree/master/devstack, it is
about installing networking-sfc together with neutron-server,
I want to install networking-sfc on compute node, can anyone tell me how
to set the local.conf?
Regards,
Juno Zhu
IBM China Development L
open swift/swiftclient patches to stable/kilo have been abandoned
--John
On 2 Jun 2016, at 4:45, Jesse Pretorius wrote:
> Hi Tony,
>
> OpenStack-Ansible is just waiting for the requirements repository and the
> swift repository kilo-eol tags. Once they're done we'd like to bump the
> SHA's for
+1
-Original Message-
From: Mathieu, Pierre-Arthur
Sent: Thursday 2 June 2016 16:29
To: openstack-dev@lists.openstack.org
Cc: freezer-eskimos
Subject: [openstack-dev][freezer] Addition to the core team
Hello,
I would like to propose that we make Deklan Dieterly (ddieterly) core on
fre
Has anyone talked with the gnocchi folks? It seems like a good time to. :)
Thanks,
Kevin
From: Jay Pipes [jaypi...@gmail.com]
Sent: Thursday, June 02, 2016 4:55 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Monasca] influxDB cluster
On 06/02/2016 11:36 AM, Shawn McKinney wrote:
On Jun 2, 2016, at 10:03 AM, Adam Young wrote:
To do all of this right, however, requires a degree of introspection that we do not have
in OpenStack. Trove needs to ask Nova "I want to do X, what role do I need?"
and there is no where in the sys
Ryan,
Sure - may need some help and it will probably be next week before I get to it.
Regards
John
From: Ryan Moats mailto:rmo...@us.ibm.com>>
Date: Wednesday, June 1, 2016 at 1:25 PM
To: John McDowall
mailto:jmcdow...@paloaltonetworks.com>>
Cc: Ben Pfaff mailto:b...@ovn.org>>,
"disc...@openv
Juno,
Sure make sense. I will have ovs/ovn in rough shape by end of week (hopefully)
that will allow you to call the interfaces from networking-ovn. Ryan has asked
that we submit WIP patches etc so hopefully that will kickstart the review
process.
Also, hopefully some of the networking-sfc team
Greetings OpenStack community,
This week there are no new merged guidelines nor guidelines proposed for
freeze but there is a new guideline discussing ways to ensure that URIs
are semantically consistent: https://review.openstack.org/#/c/322194/
# Recently merged guidelines
These guidelines
> On Jun 1, 2016, at 2:01 PM, Matt Riedemann wrote:
>
> Agree with Sean, I'd prefer separate microversions since it makes getting
> these in easier since they are easier to review (and remember we make changes
> to python-novaclient for each of these also).
>
> Also agree with using a single
John McDowall wrote on 06/02/2016 11:03:28
AM:
> From: John McDowall
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff , "disc...@openvswitch.org"
> , Justin Pettit ,
> "OpenStack Development Mailing List" d...@lists.openstack.org>, Russell Bryant
> Date: 06/02/2016 11:03 AM
> Subject: Re: [OVN
Hello:
For the last two cycles we have tried to introduce a new filter to be able to
interact better with the aggregates, using the metadata to accept or reject an
instance depending on the flavor:
https://review.openstack.org/#/c/189279/
This filter was reverted and we agreed to presen
> On Jun 2, 2016, at 10:58 AM, Adam Young wrote:
>
> Any senseible RBAC setup would support this, but we are not using a sensible
> one, we are using a hand rolled one. Replacing everything with Fortress
> implies a complete rewrite of what we do now. Nuke it from orbit type stuff.
>
> What
> -Original Message-
> From: Alonso Hernandez, Rodolfo
> [mailto:rodolfo.alonso.hernan...@intel.com]
> Sent: Thursday, June 2, 2016 6:00 PM
> To: OpenStack Development Mailing List (not for usage questions)
>
> Subject: [openstack-dev] [nova] [scheduler] New filter:
> AggregateInstanceAf
On 06/02/2016 12:53 PM, Everett Toews wrote:
>
>> On Jun 1, 2016, at 2:01 PM, Matt Riedemann
>> wrote:
>>
>> Agree with Sean, I'd prefer separate microversions since it makes getting
>> these in easier since they are easier to review (and remember we make
>> changes to python-novaclient for ea
Bryan,
I spent some time looking into the proper way to document configuration
options in OpenStack. There's a configuration reference that's part of the
openstack-manuals project. It'll take some time to figure out the best way
of contributing to that.
But for now I added a section to our docs
Thanks for feedback here.
There are not any objections, so I will drop old code reviews on Tempest queue.
Thanks
Ken Ohmichi
---
2016-05-31 23:55 GMT-07:00 Masayuki Igawa :
> On Wed, Jun 1, 2016 at 3:05 AM, Andrea Frittoli
> wrote:
>> On Mon, 30 May 2016, 6:25 p.m. Ken'ichi Ohmichi,
>> wrote:
+1
Sent from my Samsung device
Original message
From: "Ramirez Garcia, Guillermo"
Date: 02/06/2016 17:40 (GMT+01:00)
To: "Mathieu, Pierre-Arthur" ,
openstack-dev@lists.openstack.org
Cc: freezer-eskimos
Subject: Re: [openstack-dev] [freezer] Addition to the core t
Has an email been posted to the [heat] community for their input? Maybe I
missed it.
Thanks,
-Keith
On 6/2/16, 9:42 AM, "Hongbin Lu" wrote:
>Madhuri,
>
>It looks both of us agree the idea of having heterogeneous set of nodes.
>For the implementation, I am open to alternative (I supported the
>
I agree that if this occurred it is a bug. Please open a bug for us
in launchpad and include your controller worker logs and amphora-agent
log from the impacted amphora.
Thanks,
Michael
On Wed, Jun 1, 2016 at 9:55 AM, Stephen Balukoff wrote:
> Hello Yong Sheng Gong!
>
> Apologies for the laten
Hi Sergey, Welcome to working on Octavia!
I'm not sure I fully understand your proposals, but I can give my
thoughts/opinion on the challenge for Active/Active.
In general I agree with Stephen.
The intention of using TaskFlow is to facilitate code reuse across
similar but different code flows.
Hi,
I recently reviewed a patch [1] that is trying to address an issue with ironic
(master) talking to a ramdisk that has a mitaka IPA lurking around.
It made me think that IPA may no longer be a teenager (yay, boo). IPA now has a
stable branch. I think it is time it grows up and acts responsib
Hi Neutrinos,
I would like to start the first bi-weekly upgrades work report.
TLDR:
In order to inform community what is going on in upgrades field, we would like
to start bi-weekly reporting. We would like to show progress in database
resource transition to Oslo VersionedObjects. Also list
Thanks Artur for this summarize.
> On Jun 2, 2016, at 3:29 PM, Korzeniewski, Artur
> wrote:
>
> Hi Neutrinos,
> I would like to start the first bi-weekly upgrades work report.
>
> TLDR:
> In order to inform community what is going on in upgrades field, we would
> like to start bi-weekly repo
As of now we're planning to hold our midcycle meetup in virtually on
June 28, 29, and possibly June 30 (depending on agenda).
If any core reviewers or significant contributors can't attend those
days please let me know.
Also if anyone wants to travel to RTP to join those of us based here I
a
2 июня 2016 г. 10:19 PM пользователь "Loo, Ruby"
написал:
>
> Hi,
>
> I recently reviewed a patch [1] that is trying to address an issue with
ironic (master) talking to a ramdisk that has a mitaka IPA lurking around.
>
> It made me think that IPA may no longer be a teenager (yay, boo). IPA now
has
At the start of the Newton release we agreed to keep the same deadlines
we had for Mitaka. I thought everyone knew what those were but there is
some confusion so I'll remind everyone.
As always, we will enforce a Feature Freeze on the N-3 milestone date:
September 1st [1]. Only bugfixes and do
We have made the decision to remove the v1 API from Manila in Newton (it
was deprecated in Mitaka). Only v2.0+ will be supported. For those that
don't know, v2.0 is exactly the same as v1 but it has microversion
support. You need a client library from Liberty or Mitaka to get
microversion suppo
Call me ignorance, but I'm surprised at neutron-lbaas being a dependency
of magnum. Why is this? Sorry if it has been asked before and I've
just missed that answer?
Thanks,
Brandon
On Wed, 2016-06-01 at 14:39 +, Hongbin Lu wrote:
> Hi lbaas team,
>
>
>
> I wonder if there is an operator-
These changes have all merged and taken effect. Ironic and IPA gate jobs
are now operating as mentioned below, with one change; during review it
was decided to lower the amount of ram per node to 384mb instead of
512mb of RAM. This will ensure that we don't add additional bloat to
TinyIPA ramdi
These changes have all merged and taken effect. Ironic and IPA gate jobs
are now operating as mentioned below, with one change; during review it
was decided to lower the amount of ram per node to 384mb instead of
512mb of RAM. This will ensure that we don't add additional bloat to
TinyIPA ramdi
Hu,
Reconfigure was not designed to handle changes to globals.yml. I think its a
good goal that it should be able to do so, but it does not today.
Reconfigure was designed to handle changes to /etc/kolla/config/* (where custom
config for services live). Reconfigure in its current incarnation
Brandon,
Magnum uses neutron’s LBaaS service to allow for multi-master bays. We can
balance connections between multiple kubernetes masters, for example. It’s not
needed for single master bays, which are much more common. We have a blueprint
that is in design stage for de-coupling magnum from n
Stephen, Michael, thank you for having a look.
I'll respond to every issue you mentioned when I get to work on Sunday.
Until then, in case you don't mind inspecting a small diff, just to
clarify my point, please have a look at a rather straightforward change,
which
1. exemplifies pretty much al
On Thu, Jun 2, 2016 at 6:31 AM, Tony Breeds wrote:
> Hi all,
> In early May we tagged/EOL'd several (13) projects. We'd like to do a
> final round for a more complete set. We looked for projects meet one or more
> of the following criteria:
> - The project is openstack-dev/devstack, openstac
Hi
As you know, I have been working on specs that change the way we handle the
uniqueness of project names in Newton. The goal of this is to better support
project hierarchies, which as they stand today are restrictive in that all
project names within a domain must be unique, irrespective of wh
I am really struggling to accept the idea of heterogeneous clusters. My
experience causes me to question whether a heterogeneus cluster makes sense for
Magnum. I will try to explain why I have this hesitation:
1) If you have a heterogeneous cluster, it suggests that you are using external
intel
On Thu, Jun 02, 2016 at 12:38:15PM +0200, Ihar Hrachyshka wrote:
> I think all networking-* repos should EOL too, since they are plugins to
> neutron which is already EOL. I struggle to find a way that could maintain
> their gate without neutron.
Thanks I've added them.
Yours Tony.
signature.as
On Thu, Jun 02, 2016 at 07:10:23PM -0400, Emilien Macchi wrote:
> I think that all openstack/puppet-* projects that have stable/kilo can
> be kilo-EOLed.
> Let me know if it's ok and I'll abandon all open reviews.
Totally fine with me.
I've added them. Feel free to abanond the reviews. Any you
On Thu, Jun 02, 2016 at 08:41:40AM -0700, John Dickinson wrote:
> open swift/swiftclient patches to stable/kilo have been abandoned
Thanks John
Tony.
signature.asc
Description: PGP signature
__
OpenStack Development Mailing
Hongbin,
Have you considered a workflow engine?
FWIW I agree with Adrian about the difficulties of heterogenous systems.
Much better to operate, and in reality the world has moved entirely to
x86_64 + Linux. I could see a future in which ARM breaks into the server
space, but that is multiple yea
As an operator that has clouds that are partitioned into different host
aggregates with different flavors targeting them, I totally believe we will
have users that want to have a single k8s cluster span multiple different
flavor types. I'm sure once I deploy magnum, I will want it too. You could
On 06/02/2016 07:22 PM, Henry Nash wrote:
Hi
As you know, I have been working on specs that change the way we
handle the uniqueness of project names in Newton. The goal of this is
to better support project hierarchies, which as they stand today are
restrictive in that all project names within
Hi folks,
I think we are nearly done with Item #5 [1] of the VMT. One question remains.
We need to know which repo the analysis documentation will land in . There is
security-doc we could use for this purpose, but we could also create a new
repository called "security-analysis" (or open to ot
Hi,
As part of the Performance VMs CI and technical debt session we had in Ausin
summit, we decide to focus on fixing pci resize and migration bugs.
Currently the pci resize patch [1] and migration patch [2] are up for review.
The resize patch is tested with Intel PCI CI
http://52.27.155.1
Hey folks,
IRC and mailing list were going far too slow for us to make progress on the
competing specifications for handling Dockerfile customization. Instead we
held a hangout, which I don't like because it isn't recorded, but it is high
bandwidth and permitted us to work through the problem
Hi John,
I agree with submitting WIP patches to community, because you already did
many works on networking-sfc and networking-ovn, it is better that you
submit the initial patches about networking-sfc and networking-ovn, then
me and Srilatha take over the patches. Do you have time to do it? if
Hi, Friends,
I used Openstack-Juno heat, keystone and Mitaka sahara in CentOS7. Sahara is
installed in docker container using host network.
When sahara wants to call heat to create a hadoop cluster, the below error is
happened.
Could you help to check this issue? I guess, the heat couldn't
On Thu, Jun 02, 2016 at 08:27:29AM +0200, Matthias Runge wrote:
> Horizoners,
>
> please join me to welcome
>
> * Richard Jones
> * Rob Cresswell
> * Thai Tran
>
> as new Horizon stable core reviewers.
>
> Thank you guys for stepping up and thank you tonyb for pulling stats and
> pushing this.
Hello,
There is one quite strange issue in Tricircle stable/mitaka branch
(https://github.com/openstack/tricircle/tree/stable/mitaka) . Even the patch (
https://review.openstack.org/#/c/324209/ ) were given Code-Review +2 and
Workflow +1, the gating job not started, and the patch was not merged
Hi everyone,
I'm very pleased to be able to announce the results of our Install Guide naming
poll this week. We ended up with 31 responses, and a very clear winner in
"OpenStack Installation Tutorial". Thank you to everyone who voted! Also, just
a note that I'm still very much in need of repres
Juno
Whatever gets it done faster- let me get the three repos aligned. I need to get
the ovs/ovn work done so networking-ovn can call it, and the networking-sfc can
call networking-ovn.
Hopefully I will have it done tomorrow or over the weekend - let's touch base
Monday or Sunday night.
Regar
On Thu, Jun 02, 2016 at 08:31:43PM +1000, Tony Breeds wrote:
> Hi all,
> In early May we tagged/EOL'd several (13) projects. We'd like to do a
> final round for a more complete set. We looked for projects meet one or more
> of the following criteria:
> - The project is openstack-dev/devstack,
90 matches
Mail list logo
