Hi.
I have a question for operating Openstack cluster. Since it's my first mail
to mailing list, if it's not a right place to do, sorry for that and please
let me know the right one. :)
Our company operates Openstack clusters and we had legacy DNS system, and
it needs to check hostname check
Having an interface for vendordata that gets deletes would be quite nice.
Right now for novajoin we listen to the nova notifications for updates and
deletes; if this could be handled natively by vendordata, it would simplify
our codebase.
BR
On Fri, Mar 16, 2018 at 7:34 AM, Michael Still
+1
From: Jeffrey Zhang [mailto:zhang.lei@gmail.com]
Sent: Monday, March 12, 2018 9:07 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [kolla][vote] core nomination for caoyuan
Kolla core reviewer team,
It is my pleasure to nominate
thanks for the proposal, Doug. I need an example to understand how
things will work out...
so, let me use a real-life example (version numbers are made up):
openstackdocstheme uses sphinx and needs sphinx 1.6.0 or higher but
knows version 1.6.7 is broken.
So, openstackdocstheme would add to its
Hi All
I finally got round to writing up my summary of the Upgrades session at the
PTG in Dublin (see [0]).
One outcome of that session was to form a new SIG centered on Upgrading
OpenStack - I'm pleased to announce that the SIG has been formally accepted!
The objective of the Upgrade SIG is to
recently, a new patch is merged[0]. It adds neutron and horizon itself into
upper-constraints.txt. But this will break installing horizon and neutron
with
upper-constraints.txt.
Now it breaks the kolla's master branch patch. And have to remove the
"horizon"
and "neutron" in the files.
This is related to the topic in "[horizon][neutron] tools/tox_install
changes - breakage with constraints".
proposes to remove these projects from upper-constraints (for a
different reason)https://review.openstack.org/#/c/552865 that adds
other projects to global-requirements, explicitly postpone
Miguel Lavalle, 2018-03-12 13:45:
> * Ruijing Guo proposed to support VLAN transparency in Neutron OVS
> agent.
>
> [...] - While on this topic, the conversation temporarily forked to
> the use of registers instead of ovsdb port tags in L2 agent br-int
> and possibly remove br-tun. Thomas Morin
thanks Thomas, i will move my question into that topics.
anyone who are interesting this issue, please reply in "[horizon][neutron]
tools/tox_install changes - breakage with constraints".
On Fri, Mar 16, 2018 at 6:42 PM, Thomas Morin
wrote:
> This is related to the
Now it breaks the kolla's master branch jobs. And have to remove the
"horizon"
and "neutron" in the upper-constraints.txt file. check[1][2].
i wanna know what's the correct way to install horizon develop
branch with upper-constraints.txt file?
[1]
On 2018-03-16 11:42, Thomas Morin wrote:
> This is related to the topic in "[horizon][neutron] tools/tox_install
> changes - breakage with constraints".
>
> proposes to remove these projects from upper-constraints (for a
> different reason)
> https://review.openstack.org/#/c/552865
>
On 2018-03-16 11:49, Jeffrey Zhang wrote:
> Now it breaks the kolla's master branch jobs. And have to remove the
> "horizon"
> and "neutron" in the upper-constraints.txt file. check[1][2].
>
> i wanna know what's the correct way to install horizon develop
> branch with upper-constraints.txt
Right, that's a little absurd, 1TB? :-) , I completely agree.
They could live with anything, but I'd try to estimate minimums across
distributions
for example, an RDO test deployment with containers looks like:
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.24.8 "sudo df -h
; sudo
Hello,
We were using it until a couple of weeks ago, when 10.1.31 got out.
10.1.31 got issues with clustering and we moved to use a mirror of
10.1. (here 10.1.30), instead of 10.1.
We haven't decided if we'll move back to 10.1 when 10.1.32 will be out.
You can remove it for now, I think we can
Meta: When responding to lists, please do not cc individuals, just
repond to the list. Thanks, response within.
On Fri, 16 Mar 2018, Gilles Dubreuil wrote:
In order to continue and progress on the API Schema guideline [1] as
mentioned in [2] to make APIs more machine-discoverable and also
Hello,
For OpenStack-Ansible, we don't need to do anything for that community
goal. I am not sure how we can remove our name from the storyboard,
so I just inform you here.
Jean-Philippe Evrard (evrardjp)
On 28 February 2018 at 05:27, ChangBo Guo wrote:
> Hi ALL,
>
> TC
Interesting.
I'll take a look as well (Winstackers). Just an FYI, SIGHUP doesn't exist in
Windows, so for services like nova-compute, neutron-hyperv-agent,
neutron-ovs-agent, ceilometer-polling we'd have to use something else.
Best regards,
Claudiu Belu
Hello,
That's what it always was, but it was hidden in the pages. Now that I
refactored the pages to be more visible, you spotted it :)
Congratulations!
More seriously, I'd like to remove that requirement, showing people
can do whatever they like. It all depends on how/where they store
images,
> Can you be more specific about what is limiting you when you use
> volume-backed instances?
Presumably it's because you're taking a trip over iscsi instead of using
the native attachment mechanism for the technology that you're using? If
so, that's a valid argument, but it's hard to see the
On Fri, Mar 16, 2018 at 09:23:11AM -0700, melanie witt wrote:
> On Fri, 16 Mar 2018 17:33:30 +0200, Peter Penchev wrote:
> > Would there be any major opposition to adding a StorPool shared
> > storage image backend, so that our customers are not limited to
> > volume-backed instances? Right now,
This is the second edition of what is going on in Chef OpenStack. The
goal is to give a quick overview to see our progress and what is on
the menu. Feedback is always welcome, as this is an iterative thing.
Appetizers
=> Pike has been branched! Supermarket has also received a round of
Just updating the subject line tag to glance. ;)
On Fri, Mar 16, 2018 at 05:33:30PM +0200, Peter Penchev wrote:
> Hi,
>
> A couple of years ago I created a Nova spec for the StorPool image
> backend: https://review.openstack.org/#/c/137830/ There was some
> discussion, but then our company
On Fri, 16 Mar 2018 17:33:30 +0200, Peter Penchev wrote:
Would there be any major opposition to adding a StorPool shared
storage image backend, so that our customers are not limited to
volume-backed instances? Right now, creating a StorPool volume and
snapshot from a Glance image and then
kolla install openstack packages through master tarball file on kolla
master branch[0]. like
pip install -c upper-constraints.txt neutron-master.tar.gz
On stable branch, kolla install through neutron tag tarball. so it should
work.
But i think there will be also some issue here. How about i
On 2018-03-16 13:22, Jeffrey Zhang wrote:
> kolla install openstack packages through master tarball file on kolla
> master branch[0].
>
> On stable branch, kolla install through neutron tag tarball. But i think
> there will be also
> some issue here. How about i want to install
On Mar 15, 2018, at 10:31 PM, Gilles Dubreuil wrote:
>
> Any chance we can progress on this one?
>
> I believe there are not enough participants to split the API SIG meeting in
> 2, and also more likely because of the same lack of people across the 2 it
> could make it
On 3/16/2018 10:33 AM, Peter Penchev wrote:
Would there be any major opposition to adding a StorPool shared
storage image backend, so that our customers are not limited to
volume-backed instances? Right now, creating a StorPool volume and
snapshot from a Glance image and then booting instances
The Glance Bug Squad will meet biweekly on Monday of even-numbered ISO
weeks at 10:00 UTC in #openstack-glance. The meeting will last 45
minutes.
The first meeting will be 19 March 2018.
Agenda and notes: https://etherpad.openstack.org/p/glance-bug-squad-meeting
What about the other way around? An Octavia plugin that simply manages k8s
Ingress objects on a k8s cluster? Depending on how operators are deploying
openstack, this might be a much easier way to deploy Octavia.
Thanks,
Kevin
From: Lingxian Kong
On Fri, Mar 16, 2018 at 11:04:06AM -0500, Sean McGinnis wrote:
> Just updating the subject line tag to glance. ;)
Errr, sorry, but no, this is for a Nova image backend (yes, namespace
overload, I know) - the driver that lets a Nova host create "local"
images for non-volume-backed instances.
> On
Excerpts from Jeremy Stanley's message of 2018-03-16 13:43:00 +:
> On 2018-03-16 08:34:28 -0500 (-0500), Sean McGinnis wrote:
> > On Mar 16, 2018, at 04:02, Jean-Philippe Evrard
> > wrote:
> >
> > > For OpenStack-Ansible, we don't need to do anything for that
> > >
I can provide some insights from the Dell EMC ScaleIO side.
As you can see from the patch that Matt pointed to, it is possible to add
ephemeral/image backend support to Nova. That said, it is not easy and [IMHO]
prone to error. There is no ‘driver model’ like there is in Cinder, where you
just
# Keystone Team Update - Week of 12 March 2018
## News
### Keystone Admin-ness: the Future
At the Denver PTG, while grappling with the concept of admin-ness, we had a
moment of clarity when we realized that there were some classes of admin
actions that could be described as "global" across
> On Mar 16, 2018, at 7:40 AM, Simon Leinen wrote:
>
> Joe Topjian writes:
>> Terraform hat! I want to slightly nit-pick this one since the words
>> "leak" and "admin-priv" can sound scary: Terraform technically wasn't
>> doing anything wrong. The problem was that
Hi all,
If you see your project name in the subject that is because a global search
revived usage of "pxe_ipmitool", "agent_ipmitool" or "pxe_ssh" drivers in the
non-unit-test context in one or more of your repositories.
The classic drivers, such as pxe_ipmitool, were deprecated in Queens,
On 2018-03-16 08:34:28 -0500 (-0500), Sean McGinnis wrote:
> On Mar 16, 2018, at 04:02, Jean-Philippe Evrard
> wrote:
>
> > For OpenStack-Ansible, we don't need to do anything for that
> > community goal. I am not sure how we can remove our name from
> > the
Just FYI, l7 policy/rule support for Neutron LBaaS V2 and Octavia is on its
way[1], because we will have both octavia and magnum deployed on our
openstack based public cloud this year, an ingress controller for
openstack(octavia) is also on our TODO list, any kind of collaboration are
welcomed :-)
> On Mar 16, 2018, at 04:02, Jean-Philippe Evrard
> wrote:
>
> Hello,
>
> For OpenStack-Ansible, we don't need to do anything for that community
> goal. I am not sure how we can remove our name from the storyboard,
> so I just inform you here.
>
> Jean-Philippe
In the stable/queens branch, since openstacksdk0.11.3 and os-service-types1.1.0
are described in openstack's upper-constraints.txt,
https://github.com/openstack/requirements/blob/stable/queens/upper-constraints.txt#L411
Hi,
A couple of years ago I created a Nova spec for the StorPool image
backend: https://review.openstack.org/#/c/137830/ There was some
discussion, but then our company could not immediately allocate the
resources to write the driver itself, so the spec languished and was
eventually abandoned.
On Fri, Mar 16, 2018 at 5:01 AM, Joe Topjian wrote:
> Hi Chris,
>
> I wear a number of hats related to this discussion, so I'll add a few
> points of view :)
>
> It turns out that with
>> Terraform, it's possible to tear down resources in a way that causes
>> Neutron to
>> leak
On 3/16/2018 1:22 AM, 양유석 wrote:
Our company operates Openstack clusters and we had legacy DNS system,
and it needs to check hostname check more strictly including RFC952.
Also our operators demands for unique hostname in a region (we do not
have tenant network yet using l3 only network). So
Hello,
Thanks for the notice!
JP
On 16 March 2018 at 12:09, Dmitry Tantsur wrote:
> Hi all,
>
> If you see your project name in the subject that is because a global search
> revived usage of "pxe_ipmitool", "agent_ipmitool" or "pxe_ssh" drivers in
> the non-unit-test
Hey folks,
As many core reviewers in Kolla core teams may already know, I am focused on
OpenStack board of director work and adjacent community work. This involves
bridging the OpenStack ecosystem and its various strategic focus areas with
adjacent community projects that make sense. My work
Thanks!
On 16 March 2018 at 16:56, Doug Hellmann wrote:
> Excerpts from Jeremy Stanley's message of 2018-03-16 13:43:00 +:
>> On 2018-03-16 08:34:28 -0500 (-0500), Sean McGinnis wrote:
>> > On Mar 16, 2018, at 04:02, Jean-Philippe Evrard
>> >
Hi Manjeet / Isaku,
I am unable to apply qos policy with dscp marking rule to a port.
1.Create a Qos Policy
2.Create a dscp marking rule on to create qos policy
3.Apply above created policy to a port
openstack network qos rule set --dscp-mark 22 dscp-marking
On 16 March 2018 at 16:39, Dan Smith wrote:
>> Can you be more specific about what is limiting you when you use
>> volume-backed instances?
>
> Presumably it's because you're taking a trip over iscsi instead of using
> the native attachment mechanism for the technology that
Awesome!
Might IMHO be useful to also start doing this with other projects.
James E. Blair wrote:
Hi,
To date, Zuul has (perhaps rightly) often been seen as an
OpenStack-specific tool. That's only natural since we created it
explicitly to solve problems we were having in scaling the testing
On 2018-03-16 21:22:51 + (+), Jim Rollenhagen wrote:
[...]
> It seems mod_wsgi doesn't want python applications catching SIGHUP,
> as Apache expects to be able to catch that. By default, it even ensures
> signal handlers do not get registered.[0]
[...]
> Given we just had a goal to make
This Arista release is failing because the packaging job can't run "tox
-e venv" because neutron is listed in the requirements.txt for the
Arista code and in the constraints file.
Excerpts from zuul's message of 2018-03-16 19:50:48 +:
> Build failed.
>
> - release-openstack-python
>
On Fri, Mar 16, 2018 at 5:34 PM, Jeremy Stanley wrote:
> On 2018-03-16 21:22:51 + (+), Jim Rollenhagen wrote:
> [...]
>> It seems mod_wsgi doesn't want python applications catching SIGHUP,
>> as Apache expects to be able to catch that. By default, it even ensures
>>
On 03/02/2018 02:24 AM, Emilien Macchi wrote:
> A quick update:
>
> - Discussed with Jiri Tomasek from TripleO UI squad and he agreed that his
> squad would start to use Storyboard, and experiment it.
> - I told him I would take care of making sure all UI bugs created in
> Launchpad would be
Submission is no longer anonymous, but the results are not public, still. The
submitter decides whether the guideline results are public, but if they do,
only the guideline tests are made public. If the submitter does not actively
select public availability for the test results, all results
knikolla brought up an interesting wedge in this goal in #openstack-keystone
today.
It seems mod_wsgi doesn't want python applications catching SIGHUP,
as Apache expects to be able to catch that. By default, it even ensures
signal handlers do not get registered.[0]
I can't quickly find uwsgi's
On Fri, Mar 16, 2018 at 09:39:14AM -0700, Dan Smith wrote:
> > Can you be more specific about what is limiting you when you use
> > volume-backed instances?
>
> Presumably it's because you're taking a trip over iscsi instead of using
> the native attachment mechanism for the technology that
hi,
tacker team has held a vPTG via zoom, which is recorded at
https://etherpad.openstack.org/p/Tacker-PTG-Rocky
in summary:
P1 tasks:
1. web studio for vnf resources
2. sfc across k8s with openstack vims
3. make tacker server with monitoring features scaleable
other tasks:
1. policy for
kolla install openstack packages through master tarball file on kolla
master branch[0].
On stable branch, kolla install through neutron tag tarball. But i think
there will be also
some issue here. How about i want to install neutron-12.0.1.tar.gz, whereas
neutron===12.0.0
exist in the
>
> ...then there's no way I can know ahead of time what all those might be.
> (In particular, if I want to support new devices without updating my
> code.) I.e. I *can't* write the corresponding
> provider_tree.remove_trait(...) condition. Maybe that never becomes a
> real problem because
Joe Topjian writes:
> Terraform hat! I want to slightly nit-pick this one since the words
> "leak" and "admin-priv" can sound scary: Terraform technically wasn't
> doing anything wrong. The problem was that Octavia was creating
> resources but not setting ownership to the tenant. When it came time
On 3/16/2018 9:29 AM, Kwan, Louie wrote:
In the stable/queens branch, since openstacksdk0.11.3 and os-service-types1.1.0
are described in openstack's upper-constraints.txt,
https://github.com/openstack/requirements/blob/stable/queens/upper-constraints.txt#L411
Hi!
This is the weekly summary of Technical Committee initiatives. You can
find the full list of all open topics (updated twice a week) at:
https://wiki.openstack.org/wiki/Technical_Committee_Tracker
If you are working on something (or plan to work on something)
governance-related that is not
On 13 March 2018 at 18:51, Eric K wrote:
> Hi Mistral folks and others,
>
> I'm working on Congress tempest tests [1] for integration with Mistral. In
> the tests, we use a Mistral service client to call Mistral APIs and
> compare results against those obtained by
Here's a placement update!
# Most Important
While work has started on some of the already approved specs, there
are still a fair few under review, and a couple yet to be written.
Given the number of specs we've got going it's entirely likely we've
bitten off more than we can chew, but we'll
Hi Andreas,
In the documentation for networking-bgpvpn, we suggest to install these
packages with "pip install -c https://git.openstack.org/cgit/openstack/
requirements/plain/upper-constraints.txtt networking-bgpvpn=8.0.0" .In
many cases this can work well enough for people wanting to try this
64 matches
Mail list logo