OK, this makes sense. Thanks for clarification!
On Wed, Jan 25, 2017 at 10:50 PM Ihar Hrachyshka
wrote:
> On Tue, Jan 24, 2017 at 10:29 PM, Anna Taraday
> wrote:
> > Thanks for bringing this up!
> >
> > I was assuming that from Ocata everyone should switch from usage 'old'
> > TunnelTypeDriver
I think #3 is the right call for now. The person we had working on privsep
has left the company, and I don't have anyone I could get to work on this
right now. Oh, and we're out of time.
Michael
On Thu, Jan 26, 2017 at 3:49 PM, Matt Riedemann wrote:
> The patch to add support for ephemeral stor
The patch to add support for ephemeral storage with the Virtuozzo config
is using the privsep helper from os-brick to run a new ploop command as
root:
https://review.openstack.org/#/c/312488/
I've objected to this because I'm pretty sure this is not how we
intended to be using privsep in Nova
This is my public hand off to Sylvain for the work done tonight.
Starting with the multinode grenade failure in the nova patch to
integrate placement with the filter scheduler:
https://review.openstack.org/#/c/417961/
The test_schedule_to_all_nodes tempest test was failing in there because
t
>This is why it should be easy to do. The easier it is, the more Neutron
work you'll have time for, in fact.
I agree that writing them should be easy. But I don't want to enable
operators to just tweak config files to alter APIs. So +1000 to developer
productivity. I just don't want it to circumv
Hi Team,
Weekly meetings on Jan. 27 & Feb. 3 have been cancelled for Chinese New Year
vacation.
B. R.,
Zhijiang__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ.
Hi, guys,
Sorry for recalling this thread after 1 year, but we are currently
suffering from the poor performance issue for our public cloud.
As usage of our customers keeps growing, we are at a stage that should
seriously pay more attention to horizon performance problem, so Google took
me to thi
On 25 January 2017 at 18:07, Kevin Benton wrote:
> >Setting aside all the above talk about how we might do things for a
> moment: to take one specific feature example, it actually took several
> /years/ to add VLAN-aware ports to OpenStack. This is an example of a
> feature that doesn't affect o
hi,
On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann wrote:
> Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600:
>> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto :
>> > hi,
>> >
>> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M. wrote:
>> >> Hi
>> >>
>> >> As of today, the project
>There is no such thing as arbitrary API. It is like one person's treasure
is other person's trash no body loves to create arbitrary APIs - there
are genuine needs.
Arbitrary in the sense that new APIs can be developed on-demand to solve
one specific use case that leads to fragmentation and in
Hello everyone,
Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Jan 26th at 9:00 UTC in the #openstack-meeting channel.
The agenda for the meeting can be found here:
*
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_January_26th_2017_.280900_UTC
I've posted some comments on the API Access patch.
The blueprint was saying that 'API Access' would be both at the Project
level, but the way panel groups worked meant that setting the 'default'
panel group didn't work when that dashboard already had panel groups,
since the default panel group wa
I think we may also want to bring this up in a cross-project session at the
PTG. We are definitely to blame for some of the instability, but towards
the end of this cycle I have noticed lots of issues with HTTPS connection
errors, etc that don't seem to be related to Neutron at all. The squad team
>Obviously this is close to my interests, and I see Kevin's raised Gluon as
the bogeyman (which it isn't trying to be).
No, I was pointing out that it's not what I want Neutron to become. It's
entire purpose is to make defining new APIs as simple as writing YAML (i.e.
networking APIs as a service)
Hi Paul,
> To my knowledge it's not possible to change the target repository for an
> open patch. What we've done so far is to abandon the in progress one,
> cherry-pick to the correct repository and start a new review (adding the
> original author as a co-author of course).
Thanks for sharing y
In conjunction with the release of VPP 17.01, I'd like to invite you all to
try out networking-vpp for VPP 17.01. VPP is a fast userspace forwarder
based on the DPDK toolkit, and uses vector packet processing algorithms to
minimise the CPU time spent on each packet and maximise throughput.
network
Thanks rm_work.
I also notice something need to be handled properly.
For barbican, the delete_cert() only deregisters the cert without actually
delete it. That's safe for us to call during
delete_listener()/delete_loadbalancer().
But if the user uses other cert_manager by any chance, say the
loc
Just a heads-up I've been meaning to send for a while... as
discussed in the last month of Infra meetings we've got a pad here
for people to pitch ideas of things they want to collaborate on in
the Infra team space at the PTG on Monday and Tuesday:
https://etherpad.openstack.org/p/infra-ptg-pi
Felipe,
thank you so much for all your efforts so far, I am sure that you will
be a great leader for the Murano!
On Tue, Jan 24, 2017 at 10:58 AM, MONTEIRO, FELIPE C wrote:
> Hi,
>
>
>
> My name is Felipe Monteiro. I have decided to run for Murano PTL for the
> Pike
>
> release cycle. I would li
Big Thanks! from me too. The old UI here was very unintuitive, so I had to
field a lot of questions related to it. This is great. :)
Kevin
From: Lingxian Kong [anlin.k...@gmail.com]
Sent: Wednesday, January 25, 2017 2:23 PM
To: OpenStack Development Mailing List (
I would like to comment a little bit regarding usage of Glare in
Murano and Mirantis OpenStack:
> How much have these projects adopted Glare?
Glare is preferred backend for storing murano packages, which provides
versioning capabilities (they are not available without it)
>Is Glare being deployed
On 25 January 2017 at 14:17, Monty Taylor wrote:
> > Adding an additional networking project to try to solve this will only
> > make things work. We need one API. If it needs to grow features, it
> > needs to grow features - but they should be features that all of
> > OpenStack users get.
>
> WOR
I think the keystone team is in the same spot.
We have an etherpad [0] for jotting down ideas, but we haven't parsed it or
grouped it in into topics yet. I think we were going to start working on
that next week since we're still in the middle of wrapping up the last few
bits for ocata-3. I was jus
On 18:16 Jan 24, Mikhail Fedosin wrote:
> Hey, Flavio :) Thanks for your questions!
>
> As you said currently only Nokia's adopting Glare for its own platform, but
> if we talk about OpenStack, that I believe Mistral will start to use it
> soon.
> In my opinion Glare's adoption is low due to the f
I am preparing for PTG sessions.
How much capacity is in each room ? 30 people or more?
We might want to have different discussions or coding meetups in
parallel in the same room, because each developer concentrates on
different working topics (Tempest, Devstack, Grenade, Patrole, etc
under QA pro
Hi Rob, FFE granted for those two in-flight patches.
On 26 January 2017 at 09:23, Lingxian Kong wrote:
> Hi, Rob,
>
> First, thanks for your work!
>
> What's your plan for the other two tabs (security group, floatingip)? I
> could see the split is very helpful no matter from performance perspecti
Hi, Rob,
First, thanks for your work!
What's your plan for the other two tabs (security group, floatingip)? I
could see the split is very helpful no matter from performance perspective
and both useful from end user's perspective.
BTW, a huge +1 for this FFE!
Cheers,
Lingxian Kong (Larry)
On
On 01/25/2017 08:16 AM, Monty Taylor wrote:
> On 01/24/2017 06:42 PM, Sukhdev Kapur wrote:
>>
>> Ihar and Kevin,
>>
>> As our potential future PTLs, I would like to draw your attention to one
>> of the critical issue regarding Neutron as "the" networking service in
>> OpenStack.
>>
>> I keep hear
On Wed, Jan 25, 2017 at 3:42 PM, Sagi Shnaidman wrote:
> HI, all
>
> I'd like to propose a bit different approach to run experimental jobs in
> TripleO CI.
> As you know we have OVB jobs and not-OVB jobs, and different pipelines for
> running these two types of them.
>
> What is current flow:
> if
HI, all
I'd like to propose a bit different approach to run experimental jobs in
TripleO CI.
As you know we have OVB jobs and not-OVB jobs, and different pipelines for
running these two types of them.
What is current flow:
if you need to run experimental jobs, you write comment with "check
experi
I would certainly be interested in dicussing this, though I'm not currently
signed up for the PTG. Obviously this is close to my interests, and I see
Kevin's raised Gluon as the bogeyman (which it isn't trying to be).
Setting aside all the above talk about how we might do things for a moment:
to
Thanks for the explanation. I agree that it has indeed moved now!
On Wed, Jan 25, 2017 at 8:18 PM Jeremy Stanley wrote:
> On 2017-01-25 20:05:04 + (+), Neil Jerram wrote:
> > I'm not experienced in reading these things, but it seems that nothing is
> > currently getting through the int
On 2017-01-25 20:05:04 + (+), Neil Jerram wrote:
> I'm not experienced in reading these things, but it seems that nothing is
> currently getting through the integrated gate, and from [1] it appears this
> is because the gate-tempest-dsvm-neutron-full-ubuntu-xenial job of [2] has
> hung.
>
I'm not experienced in reading these things, but it seems that nothing is
currently getting through the integrated gate, and from [1] it appears this
is because the gate-tempest-dsvm-neutron-full-ubuntu-xenial job of [2] has
hung.
[1] http://status.openstack.org/zuul/
[2] https://review.openstack.
+1We very much need this as the performance of that panel is awful. This solves that problem while being a fairly minor code change which also provides much better UX.On 26/01/2017 8:07 AM, Rob Cresswell wrote:
o/
I'd like to request an FFE on https://blueprints.launchpad.net/horizon/+spec/
Looking at the code, I don't see a clear case to even use set() type
there. A list would seem to work just fine. Should we try to convert
to using lists there?
Nevertheless, we can look into extending the object base class for
hashing. I wonder though if it's something to tackle in Neutron scope.
Hi Ihar,
While doing the integration for vlanallocation [1] I found that OVO associated
with VlanAllocation throws “unhashable type” error with py35.
The associated stack trace is here [2].
To resolve this issue I added an equality and hash method in the vlanallocation
OVO [3].
My understanding
On 01/23/2017 11:03 AM, Emilien Macchi wrote:
> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common and tripleo-heat-t
Excerpts from Andreas Jaeger's message of 2017-01-25 08:40:16 +0100:
> On 2017-01-25 08:24, Andreas Jaeger wrote:
> > On 2017-01-25 05:03, Matthew Thode wrote:
> >> On 01/24/2017 09:57 PM, Matthew Thode wrote:
> >>> Basically I'd like to ask the docs people if they are fine with updating
> >>> th
Hi all,
Apologies for the late notice, but there won't be a cells meeting this
afternoon being that everyone is busy scrambling for the feature freeze
deadline this week. Let's catch up after FF.
Thanks,
-melanie
__
Open
o/
I'd like to request an FFE on
https://blueprints.launchpad.net/horizon/+spec/reorganise-access-and-security.
This blueprint splits up the access and security tabs into 4 distinct panels.
The first two patches are https://review.openstack.org/#/c/408247 and
https://review.openstack.org/#/c/4
On Tue, Jan 24, 2017 at 5:04 PM, Kevin Benton wrote:
> >I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible so that
> vendors do not run around trying to figure out alternative solutions
>
> The Neutron API
On Tue, Jan 24, 2017 at 10:29 PM, Anna Taraday
wrote:
> Thanks for bringing this up!
>
> I was assuming that from Ocata everyone should switch from usage 'old'
> TunnelTypeDriver to updated one.
I am not sure. We haven't marked the 'old' one with any deprecation
warnings, did we? For Ocata at lea
I've got this on my list of things to look at -- I don't know if it was you
I was talking with on IRC the other day about this issue, but I'm
definitely aware of it. As soon as we are past the Ocata feature freeze
crunch, I'll take a closer look.
My gut says that we should be calling the delete (w
On Tue, Jan 24, 2017 at 12:26 PM, Morales, Victor
wrote:
> Given the latest issues related with the memory consumption[1] in CI jobs,
> I’m just wondering if you have a plan to deal and/or improve it in Neutron.
AFAIU the root cause is still not clear, and we don't know if it's
Neutron or job se
+1 to Dharmendra, great addition.
Thank you very much Stephen for your contributions.
-Sripriya
On 1/24/17, 4:58 PM, "Sridhar Ramaswamy" wrote:
Tackers,
I'd like to propose following changes to the Tacker core team.
Stephen Wong
After being associated with Tacker
Folks,
This thread has gotten too long and hard to follow.
It is clear that we should discuss/address this.
My suggestion is that we organize a session in Atlanta PTG meeting and
discuss this.
I am going to add this on the Neutron etherpad - should this be included in
any other session as well?
On Wed, Jan 25, 2017 at 7:45 AM, Kevin Benton wrote:
> LBaaS is a little special since Octavia will have it's own API endpoint
> completely that they will evolve on their own. The other spun-out projects
> (e.g. VPNaaS) will have the API defined in neutron-lib[1].
In a way, VPNaaS is also special
Folks, this is a great discussion. I hope this leads us to some good
consensus and direction :-)
I would suggest that we discuss this in upcoming PTG meeting as well.
On Wed, Jan 25, 2017 at 5:20 AM, Kevin Benton wrote:
> >So I'm not sure that Kevin and Thierry's answers address Sukhdev's point
Catching up on the thread, lots of good thoughts.
I don't think there is disagreement here around how Networking API
should evolve in terms of vendor extensions. As Kevin suggested, we
don't want to advertise API extensibility without Neutron team
supervision.
One of the reasons behind current ap
My sincere Thanks to every Glance core. You all have inspired
me right from day one. I hope to perform my duties as a Glance
Core to the best of my abilities and help make Glance great.
Thanks,
Dharini Chandrasekar.
On 1/24/17, 07:36, "Brian Rosmaita" wrote:
>I'd like to propose Dharini Ch
+1 for both.
Regards
Bharath T
Imaginea Technologies Inc.
On Wed, Jan 25, 2017 at 8:19 PM, HADDLETON, Robert W (Bob) <
bob.haddle...@nokia.com> wrote:
> +1
>
> Thanks Stephen! And welcome aboard Dharmendra!
>
> Bob
>
>
> On 1/24/2017 6:58 PM, Sridhar Ramaswamy wrote:
>
>> Tackers,
>>
>> I'd li
On 01/25/2017 04:32 PM, Steven Hardy wrote:
> On Wed, Jan 25, 2017 at 02:59:42PM +0200, Marios Andreou wrote:
>> Hi, as part of the composable upgrades workflow shaping up for Newton to
>> Ocata, we need to install the new hiera hook that was first added with
>> [1] and disable the old hook and dat
On Wed, Jan 25, 2017 at 12:13 PM, Javier Pena wrote:
>> Hi,
>>
>> In RDO we are preparing for the incoming Ocata release. This means
>> we'll create a new RDO Trunk builder "centos-ocata" in the next few
>> days (It will be ready for next week). This builder will get content
>> from stable/ocata b
On Tue, Jan 24, 2017 at 4:39 PM, Emilien Macchi wrote:
> OpenStack community decided to officially support Python 3.5 by the
> end of Pike cycle:
> https://governance.openstack.org/tc/goals/pike/python35.html
>
> To track this work in TripleO, I created a blueprint:
> https://blueprints.launchpad.
> Hi,
>
> In RDO we are preparing for the incoming Ocata release. This means
> we'll create a new RDO Trunk builder "centos-ocata" in the next few
> days (It will be ready for next week). This builder will get content
> from stable/ocata branches of projects as they become available and
> fallback
I've started looking into what kind of request load the placement
API can expect when both the scheduler and the resource tracker are
talking to it. I think this is important to do now before we have
things widely relying on this stuff so we can give some reasonable
advice on deployment options a
As discussed in todays team meeting [0]:
* the vote is closed
* the deprecation is delayed
http://eavesdrop.openstack.org/meetings/kolla/2017/kolla.2017-01-25-16.01.log.html
Christian.
--
Christian Berendt
Chief Executive Officer (CEO)
Mail: bere...@betacloud-solutions.de
Web: https://www.bet
Filip,
Thanks for the announce. Can you please follow the steps below to
retire the projects in openstack git repo?
http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
Thanks,
Dims
On Wed, Jan 25, 2017 at 11:39 AM, Filip Pytloun wrote:
> Hello,
>
> I would like to announce mi
Hello,
I would like to announce migration of openstack-salt to join remaining
formulas of the ecosystem.
Since today, openstack-salt and other formulas are living at
github.com/salt-formulas.
In the past few years this ecosystem has grown to more than 90 formulas
suitable for deployment of anythi
Hi Team
Just a quick reminder that next Thursday marks our second bug day for the
year.
Please focus on triage and resolution of bugs across the openstack charms -
the new bugs URL is in the topic in #openstack-charms on Freenode IRC.
Happy bug hunting!
Cheers
James
___
> Update on that agreement : I made the necessary modification in the
> proposal [1] for not verifying the filters. We now send a request to the
> Placement API by introspecting the flavor and we get a list of potential
> destinations.
Thanks!
> When I began doing that modification, I know there
On 01/25/2017 06:16 AM, Monty Taylor wrote:
I have quibble with the current microversions construct. It's mostly
semantic in nature, and I _think_ it's not valid/useful - but I'm going
to describe it here just so that I've said it and we can all acknowledge
it and move on.
My concern is with th
LBaaS is a little special since Octavia will have it's own API endpoint
completely that they will evolve on their own. The other spun-out projects
(e.g. VPNaaS) will have the API defined in neutron-lib[1].
The specific DVR issue you are referring to with roaming IPs being the
target of floating IP
I'm happy to announce my candidacy for Watcher PTL for the Pike release cycle.
I've been working on OpenStack for 2.5 years as engineer. My contributions
have been started in February 2016, they are related to Watcher and Rally
projects. I'm very proud of being one of core developers in Watcher pr
On Wed, Jan 25, 2017 at 02:59:42PM +0200, Marios Andreou wrote:
> Hi, as part of the composable upgrades workflow shaping up for Newton to
> Ocata, we need to install the new hiera hook that was first added with
> [1] and disable the old hook and data as part of the upgrade
> initialization [2]. Mo
On Tue, Jan 24, 2017 at 08:52:51AM -0500, Emilien Macchi wrote:
> I have been discussed with TripleO UI core reviewers and it's pretty
> clear Honza's work has been valuable so we can propose him part of
> Tripleo UI core team.
> His quality of code and reviews make him a good candidate and it woul
On Tue, Jan 24, 2017 at 07:03:56PM +0200, Juan Antonio Osorio wrote:
> Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
> on the current CI solution and in getting tripleo-quickstart jobs for
> it); So I would like to propose him as part of the TripleO CI core team.
> I thin
On Mon, Jan 23, 2017 at 02:03:28PM -0500, Emilien Macchi wrote:
> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common
On Wed, Jan 25 2017, Afek, Ifat (Nokia - IL) wrote:
> As we see it, alarms can be generated by different sources – Aodh, Vitrage,
> Nagios, Zabbix, etc.
I think "generated" is the wrong word here. Aodh does not generate any
alarms: it allows users to create them. And then it evaluates them and
tr
Hi all,
Brian kindly emailed the list last week [1] with our priorities for
python-glanceclient and glance.
The python-glanceclient priorities have all been effectively reviewed
and python-glanceclient has been released. The stable/ocata branch for
it now exists as well.
If you are reviewing Gla
Le 25/01/2017 05:10, Matt Riedemann a écrit :
> On 1/24/2017 2:57 PM, Matt Riedemann wrote:
>> On 1/24/2017 2:38 PM, Sylvain Bauza wrote:
>>>
>>> It's litterally 2 days before FeatureFreeze and we ask operators to
>>> change their cloud right now ? Looks difficult to me and like I said in
>>> mul
On 01/25/2017 09:16 AM, Monty Taylor wrote:
> On 01/24/2017 12:39 PM, Chris Dent wrote:
>> On Mon, 23 Jan 2017, Sean Dague wrote:
>>
>>> We all inherited a bunch of odd and poorly defined behaviors in the
>>> system we're using. They were made because at the time they seemed like
>>> reasonable tra
+1
Thanks Stephen! And welcome aboard Dharmendra!
Bob
On 1/24/2017 6:58 PM, Sridhar Ramaswamy wrote:
Tackers,
I'd like to propose following changes to the Tacker core team.
Stephen Wong
After being associated with Tacker project from its genesis, Stephen
Wong (irc: s3wong) has decided to s
Thanks for reply.
But « a priori » log say « this error can be safely ignore ». And therefore,
this log comes from the live migration that succeeded (compute 2 to compute 1).
The ERROR that questions me is (live migration compute 1 to 2), on compute 1:
2017-01-25 11:03:58.475 113231 ERROR nova.v
On 25/01/2017 01:08, Kevin Benton wrote:
>>I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible so
> that vendors do not run around trying to figure out alternative
> solutions
>
> The Neutron API is already v
Hello OpenStack developers!
My name is Ian and I am now serving I18n PTL for Ocata cycle.
For previous releases, I18n team set higher priorities for translations
on Horizon and Horizon plugins
during Soft and Hard StringFreezes to include user-faced translated
strings as much as possible withi
+1
On 23.1.2017 20:03, Emilien Macchi wrote:
Greeting folks,
I would like to propose some changes in our core members:
- Remove Jay Dobies who has not been active in TripleO for a while
(thanks Jay for your hard work!).
- Add Flavio Percoco core on tripleo-common and tripleo-heat-templates
do
Thanks peeps for responding to Kris. Kris, I had offered a response – do you
need further information answered? It looks to me like all the questions have
been answered by others in the community. If not, feel free to respond and
I’ll answer the remainders.
Sean when your around and I am ple
On 01/24/2017 12:39 PM, Chris Dent wrote:
> On Mon, 23 Jan 2017, Sean Dague wrote:
>
>> We all inherited a bunch of odd and poorly defined behaviors in the
>> system we're using. They were made because at the time they seemed like
>> reasonable tradeoffs, and a couple of years later we learned mor
On 01/24/2017 06:42 PM, Sukhdev Kapur wrote:
>
> Ihar and Kevin,
>
> As our potential future PTLs, I would like to draw your attention to one
> of the critical issue regarding Neutron as "the" networking service in
> OpenStack.
>
> I keep hearing off and on that Neutron is not flexible to addr
On 25/01/17 08:39 AM, Afek, Ifat (Nokia - IL) wrote:
> As we see it, alarms can be generated by different sources – Aodh, Vitrage,
> Nagios, Zabbix, etc. Each source has its own expertise and internal
> implementation. Nagios and Zabbix can raise alarms about the physical layer,
> Aodh can rai
On 01/24/2017 08:04 PM, Kevin Benton wrote:
>>I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible so
> that vendors do not run around trying to figure out alternative
> solutions
>
> The Neutron API is alrea
Hi,
Alarm history and a database are definitely important, but they are not the
main issue here.
As we see it, alarms can be generated by different sources – Aodh, Vitrage,
Nagios, Zabbix, etc. Each source has its own expertise and internal
implementation. Nagios and Zabbix can raise alarms ab
On Tue, Jan 24, 2017 at 6:43 AM, Corey Bryant
wrote:
>
> On Fri, Jan 20, 2017 at 6:34 PM, Alex Schultz wrote:
>>
>> Just FYI,
>>
>> We switched the Ubuntu scenario jobs to non-voting this week due to
>> the large amount of breakage caused by the ocata-proposed update to m2
>> based packages. The
>So I'm not sure that Kevin and Thierry's answers address Sukhdev's point.
I stated that I am happy to develop new APIs in Neutron. "So I'm all for
developing new APIs *as a community*"...
The important distinction I am making is that we can make new APIs (and we
do with routed networks as you me
On 23/01/17 21:03, Emilien Macchi wrote:
> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common and tripleo-heat-templa
Hi, as part of the composable upgrades workflow shaping up for Newton to
Ocata, we need to install the new hiera hook that was first added with
[1] and disable the old hook and data as part of the upgrade
initialization [2]. Most of the existing hieradata was ported to use the
new hook in [3]. The
On Wed, Jan 25, 2017 at 10:20 AM Thierry Carrez
wrote:
> Kevin Benton wrote:
> > [...]
> > The Neutron API is already very extensible and that's problematic. Right
> > now a vendor can write an out-of-tree service plugin or driver that adds
> > arbitrary fields and endpoints to the API that resul
Hi,
I did write a blueprint a while ago but did not start to implement it.
https://blueprints.launchpad.net/magnum/+spec/coreos-best-pratice
> Le 24 janv. 2017 à 23:16, Spyros Trigazis a écrit :
>
> Or start writing down (in the BP) what you want to put in the driver.
> Network, lbaas, script
And you have at least all my support : )
On Wed, Jan 25, 2017 at 12:56 PM, Saad Zaher wrote:
> Hello everyone,
>
> I'm happy to announce my candidacy to be the Freezer PTL for the Pike
> release
> cycle.
>
> The Freezer developers did a very good job over the past releases and I am
> sure
> they
Hi,
What domain name are you using?
Check for 'Traceback' and ' ERROR ' in the logs, maybe you will get a hint
2017-01-25 11:00:21.215 28309 INFO nova.compute.manager
[req-6f21e4a4-28a8-48e3-bf2f-2e1ad3b52470 0329776bd1634978a7fed35a70c77479
7531f209e3514e3f98eb58aafa480285 - - -] [instance:
Hello everyone,
I'm happy to announce my candidacy to be the Freezer PTL for the Pike
release
cycle.
The Freezer developers did a very good job over the past releases and I am
sure
they will continue doing an amazing job over the next release as well.
For the Pike release cycle, I think we need
- Original Message -
> From: "Emilien Macchi"
> To: "OpenStack Development Mailing List"
> Sent: Tuesday, January 24, 2017 2:52:51 PM
> Subject: [openstack-dev] [tripleo] Proposing Honza Pokorny core on tripleo-ui
>
> I have been discussed with TripleO UI core reviewers and it's pretty
On Wed, 25 Jan 2017, Thierry Carrez wrote:
We were discussing this in the context of an "assert" tag, not a goal.
Yes, but it is often the case that changes are being evaluated as if
it was a goal. A couple of glance related changes experienced
reactions of "this doesn't meet compatibility gui
On 24.1.2017 18:03, Juan Antonio Osorio wrote:
Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
on the current CI solution and in getting tripleo-quickstart jobs for
it); So I would like to propose him as part of the TripleO CI core team.
+1
I think he'll make a great add
On 23.1.2017 20:03, Emilien Macchi wrote:
Greeting folks,
I would like to propose some changes in our core members:
- Remove Jay Dobies who has not been active in TripleO for a while
(thanks Jay for your hard work!).
- Add Flavio Percoco core on tripleo-common and tripleo-heat-templates
docker
On 24.1.2017 14:52, Emilien Macchi wrote:
I have been discussed with TripleO UI core reviewers and it's pretty
clear Honza's work has been valuable so we can propose him part of
Tripleo UI core team.
His quality of code and reviews make him a good candidate and it would
also help the other 2 core
On Tue, Jan 24 2017, gordon chung wrote:
> you mean, keep alarm history in aodh and also in panko if needed? i'm ok
> with that.
Yeah, IIRC there's an expirer in Aodh for alarm history based on TTL –
that's enough. That should probably be replaced with just a hard limit on
the number of history
Hi osa team,
i ‘ve got live migration issue in one direction but not in other.
I deploy openstack with OSA, ubuntu trusty, stable/newton branch, 14.0.5 tag.
My 2 compute node are same host type and have nova-compute and cinder-volume
(our ceph cluster as backend) services.
No problem to live mi
1 - 100 of 119 matches
Mail list logo