On 11/19/2018 9:32 PM, Rambo wrote:
I have an idea.Now we can't filter the special flavor according
to the property.Can we achieve it?If we achieved this,we can filter the
flavor according the property's key and value to filter the flavor. What
do you think of the idea?Can you tell me mo
On 11/19/2018 3:17 AM, melanie witt wrote:
- Not directly related to the session, but CERN (hallway track) and
NeCTAR (dev ML) have both given feedback and asked that the
policy-driven idea for handling quota for down cells be avoided. Revived
the "propose counting quota in placement" spec to s
On 11/18/2018 6:51 AM, Alex Xu wrote:
Sounds make sense to me, and then we needn't fix this strange behaviour
also https://review.openstack.org/#/c/409644/
The same discussion was had in the spec for that change:
https://review.openstack.org/#/c/511825/
Ultimately it amounted to a big "meh, l
On 11/13/2018 4:45 AM, Chen CH Ji wrote:
Got it, this is what I am looking for .. thank you
Regarding that you can do with server create, I believe it's:
1. don't specify anything for networking, you get a port on the network
available to you; if there are multiple networks, it's a failure an
No major updates this week, but there is some decent progress in more
projects getting their framework patch merged [1]. Thanks again to Rajat
and Akhil for their persistent effort. There are more open reviews
available for adding the framework to projects [2]. Some projects, like
cloudkitty [3
After hacking on the PoC for awhile [1] I have finally pushed up a spec
[2]. Behold it in all its dark glory!
[1] https://review.openstack.org/#/c/603930/
[2] https://review.openstack.org/#/c/616037/
On 8/22/2018 8:23 PM, Matt Riedemann wrote:
Hi everyone,
I have started an etherpad for
On 11/6/2018 5:24 PM, Rochelle Grober wrote:
Maybe the fastest way to get info would be to turn it off and see where the
code barfs in a long run (to catch as many projects as possible)?
There is zero integration testing for lazy translation, so "turning it
off and seeing what breaks" wouldn'
On 11/5/2018 10:43 AM, Matt Riedemann wrote:
If you are seeing this error when implementing and running the upgrade
check command in your project:
Traceback (most recent call last):
File
"/home/osboxes/git/searchlight/.tox/venv/lib/python3.5/site-packages/oslo_upgradecheck/upgradeche
On 11/5/2018 1:36 PM, Doug Hellmann wrote:
I think the lazy stuff was all about the API responses. The log
translations worked a completely different way.
Yeah maybe. And if so, I came across this in one of the blueprints:
https://etherpad.openstack.org/p/disable-lazy-translation
Which says t
On 11/5/2018 1:17 PM, Matt Riedemann wrote:
I'm thinking of a case like, resize and instance but rather than
confirm/revert it, the user deletes the instance. That would cleanup the
allocations from the target node but potentially not from the source node.
Well this case is at least n
On 11/5/2018 12:28 PM, Mohammed Naser wrote:
Have you dug into any of the operations around these instances to
determine what might have gone wrong? For example, was a live migration
performed recently on these instances and if so, did it fail? How about
evacuations (rebuild from a down host).
T
This is a follow up to a dev ML email [1] where I noticed that some
implementations of the upgrade-checkers goal were failing because some
projects still use the oslo_i18n.enable_lazy() hook for lazy log message
translation (and maybe API responses?).
The very old blueprints related to this ca
On 11/2/2018 3:47 AM, Andreas Scheuring wrote:
Dear Nova Community,
I want to announce the new focal point for Nova s390x libvirt/kvm.
Please welcome "Cathy Zhang” to the Nova team. She and her team will be
responsible for maintaining the s390x libvirt/kvm Thirdparty CI [1] and any s390x
spec
On 11/4/2018 10:17 PM, Chen CH Ji wrote:
Yes, this has been discussed for long time and If I remember this
correctly seems S PTG also had some discussion on it (maybe public Cloud
WG ? ), Claudiu has been pushing this for several cycles and he actually
had some code at [1] but no additional pro
If you are seeing this error when implementing and running the upgrade
check command in your project:
Traceback (most recent call last):
File
"/home/osboxes/git/searchlight/.tox/venv/lib/python3.5/site-packages/oslo_upgradecheck/upgradecheck.py",
line 184, in main
return conf.command.ac
There is not much news this week. There are several open changes which
add the base command framework to projects [1]. Those need reviews from
the related core teams. gmann and I have been trying to go through them
first to make sure they are ready for core review.
There is one neutron change
On 11/5/2018 5:52 AM, Chris Dent wrote:
* We need to have further discussion and investigation on
allocations getting out of sync. Volunteers?
This is something I've already spent a lot of time on with the
heal_allocations CLI, and have already started asking mnaser questions
about this el
On 11/4/2018 4:22 AM, Mohammed Naser wrote:
Just for information sake, a clean state cloud which had no reported issues
over maybe a period of 2-3 months already has 4 allocations which are
incorrect and 12 allocations pointing to the wrong resource provider, so I
think this comes does to committ
On 11/2/2018 2:22 PM, Eric Fried wrote:
Based on a (long) discussion yesterday [1] I have put up a patch [2]
whereby you can set [compute]resource_provider_association_refresh to
zero and the resource tracker will never* refresh the report client's
provider cache. Philosophically, we're removing
On 11/1/2018 7:22 PM, Kendall Nelson wrote:
We've made a lot of progress in StoryBoard-land over the last couple of
releases cleaning up bugs, fixing UI annoyances, and adding features
that people have requested. All along we've also continued to migrate
projects as they've become unblocked. Wh
I came across this bug [1] in triage today and I thought this was fixed
already [2] but either something regressed or there is more to do here.
I'm mostly just wondering, are operators already running any kind of
script which purges old instance_faults table records before an instance
is delet
On 10/30/2018 11:03 AM, Clark Boylan wrote:
If you find any of this interesting and would like to help feel free to reach
out to myself or the infra team.
I find this interesting and thanks for providing the update to the
mailing list. That's mostly what I wanted to say.
FWIW I've still got
This is a notice to any out of tree virt driver implementors of the
ComputeDriver.update_provider_tree() interface that they now need to set
the allocation_ratio and reserved amounts for VCPU, MEMORY_MB and
DISK_GB inventory from the update_provider_tree() method assuming [1]
merges. The patch
Given the outstanding results of my recruiting job last week [1] I have
been tasked with recruiting one of our glorious and most talented
contributors to work on the fast-forward-upgrade script changes needed
for the reshape-provider-tree blueprint.
The work item is nicely detailed in the spec
There isn't much news this week except some of the base framework
changes being proposed to projects are getting merged which is nice to see.
https://storyboard.openstack.org/#!/story/2003657
https://review.openstack.org/#/q/topic:upgrade-checkers+status:merged
And there are a lot of patches t
On 10/25/2018 2:55 PM, Chris Friesen wrote:
2) The main benefit (as I see it) of the quota class API is to allow
dynamic adjustment of the default quotas without restarting services.
I could be making this up, but I want to say back at the Pike PTG people
were also complaining that not having
Hello OSA/TripleO people,
A plan/checklist was put in place at the Stein PTG for extracting
placement from nova [1]. The first item in that list is done in grenade
[2], which is the devstack-based upgrade project in the integrated gate.
That should serve as a template for the necessary upgrade
On 10/24/2018 6:55 PM, Sam Morrison wrote:
I’ve been thinking of some hybrid cellsv1/v2 thing where we’d still have the
top level api cell DB but the API would only ever read from it. Nova-api would
only write to the compute cell DBs.
Then keep the nova-cells processes just doing instance_updat
On 10/24/2018 10:10 AM, Jay Pipes wrote:
I'd like to propose deprecating this API and getting rid of this
functionality since it conflicts with the new Keystone /limits endpoint,
is highly coupled with RAX's turnstile middleware and I can't seem to
find anyone who has ever used it. Deprecating
On 10/23/2018 1:41 PM, Sean McGinnis wrote:
Yeah, but part of the reason for placeholders was consistency across all of
the services. I guess if there are never going to be upgrade checks in
adjutant then I could see skipping it, but otherwise I would prefer to at
least get the framework in place
On 10/23/2018 8:09 AM, Ben Nemec wrote:
Can't we just add a noop command like we are for the services that don't
currently need upgrade checks?
We could, but I was also hoping that for most projects we will actually
be able to replace the noop / placeholder check with *something* useful
in St
On 10/22/2018 4:35 PM, Adrian Turjak wrote:
The one other open question I have is about the Adjutant change [2]. I
know Adjutant is very new and I'm not sure what upgrades look like for
that project, so I don't really know how valuable adding the upgrade
check framework is to that project. Is it
On 10/22/2018 11:59 AM, Matt Riedemann wrote:
Thanks for this. Have you debugged to the point of knowing where the
initial DB query is starting from?
Looking at history, my guess is this is the change which introduced it
for all requests:
https://review.openstack.org/#/c/276861/
From that
On 10/22/2018 11:25 AM, Sergio A. de Carvalho Jr. wrote:
Hi,
While troubleshooting a production issue we identified that the Nova
metadata API is fetching a lot more raw data from the database than
seems necessary. The problem appears to be caused by the SQL query used
to fetch instance data
The big news this week is we have a couple of volunteer developers from
NEC (Akhil Jain and Rajat Dhasmana) who are pushing the base framework
changes across a lot of the projects [1]. I'm trying to review as many
of these as I can. The request now is for the core teams on these
projects to rev
e.
On 10/15/2018 3:29 PM, Ben Nemec wrote:
On 10/15/18 3:27 AM, Jean-Philippe Evrard wrote:
On Fri, 2018-10-12 at 17:05 -0500, Matt Riedemann wrote:
The big update this week is version 0.1.0 of oslo.upgradecheck was
released. The documentation along with usage examples can be found
here
On 10/16/2018 9:43 AM, Ghanshyam Mann wrote:
I was discussing with mriedem [1] about idea of building a volunteer team which
can work with him on upgrade-checkers goal [2]. There are lot of work needed
for this goal[3], few projects which does not have upgrade impact yet needs CLI
framework wi
On 10/17/2018 9:24 AM, Ivan Kolodyazhny wrote:
As you may know, unfortunately, Horizon doesn't support all features
provided by APIs. That's why we created feature gaps list [1].
I'd got a lot of great conversations with projects teams during the PTG
and we tried to figure out what should be
On 10/16/2018 5:48 AM, Chris Dent wrote:
* We need to address database creation scripts and database migrations.
There's a general consensus that we should use alembic, and start
things from a collapsed state. That is, we don't need to represent
already existing migrations in the new re
On 10/15/2018 3:01 PM, Jimmy McArthur wrote:
The Forum schedule is now up
(https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).
If you see a glaring content conflict within the Forum itself, please
let me know.
Not a conflict, but it looks like there is a duplicate for Le
The big update this week is version 0.1.0 of oslo.upgradecheck was
released. The documentation along with usage examples can be found here
[1]. A big thanks to Ben Nemec for getting that done since a few
projects were waiting for it.
In other updates, some changes were proposed in other projec
On 10/10/2018 7:46 AM, Jay Pipes wrote:
2) in the old microversions change the blind allocation copy to gather
every resource from a nested source RPs too and try to allocate that
from the destination root RP. In nested allocation cases putting this
allocation to placement will fail and nova will
On 10/9/2018 10:08 AM, Balázs Gibizer wrote:
Question for you as well: if we remove (or change) the force flag in a
new microversion then how should the old microversions behave when
nested allocations would be required?
Fail fast if we can detect we have nested. We don't support forcing
those
On 10/5/2018 6:59 PM, melanie witt wrote:
5) when live migration fails due to a internal error rollback is not
handled correctly https://bugs.launchpad.net/nova/+bug/1788014
- Bug was reported on 2018-08-20
- The change that caused the regression landed on 2018-07-26, FF day
https://review.ope
On 10/9/2018 11:08 AM, Miguel Lavalle wrote:
Since it has been more than a week since this nomination was posted and
we have received only positive feedback, can we move ahead and add
Bernard Cafarelli to Neutron Stable core team?
Done:
https://review.openstack.org/#/admin/groups/539,members
On 10/9/2018 8:04 AM, Erlon Cruz wrote:
If you are planning to re-image an image on a bootable volume then yes
you should use a force parameter. I have lost the discussion about this
on PTG. What is the main use cases? This seems to me something that
could be leveraged with the current revert-t
On 10/8/2018 11:05 AM, Carlos Goncalves wrote:
The Octavia team merged a patch in master [1] that fixed an issue where
load balancers could be deleted whenever queue_event_streamer driver is
enabled and RabbitMQ goes down [2].
As this is a critical bug, we would like to backport as much back a
On 10/7/2018 4:10 AM, Slawomir Kaplonski wrote:
I start working on „neutron-status upgrade check” tool with noop operation for
now. Patch is in [1]
I started using this new oslo_upgradecheck library in version 0.0.1.dev15 which
is available on pypi.org but I see that in master there are some ch
The ocata-em tag request is up for review:
https://review.openstack.org/#/c/608296/
On 9/28/2018 11:21 AM, Matt Riedemann wrote:
Per the other thread on this [1] I've created an etherpad [2] to track
what needs to happen to get nova's stable/ocata branch ready for
Extended Main
On 10/3/2018 11:21 AM, Zane Bitter wrote:
That patch is the only thing blocking the cleanup patch in
project-config, so I would like to get a definitive answer about what to
do. Should we close the branch, or does someone want to try to fix
things up?
I think we agreed on closing the branch, an
On 10/3/2018 9:45 AM, Jay S. Bryant wrote:
Team,
We had discussed the possibility of adding Gorka to the stable core team
during the PTG. He does review a number of our backport patches and is
active in that area.
If there are no objections in the next week I will add him to the list.
Than
I came across [1] today while triaging a bug [2]. Unless I'm mistaken,
the user has requested SR-IOV PF passthrough for their server and for
whatever reason we can't find the PCI device for the PF passthrough port
so we don't reflect the actual device MAC address on the port. Is that
worth stop
On 10/3/2018 7:58 AM, Doug Hellmann wrote:
There is one more patch to import the zuul configuration for the
heat-agents repository's stable/ocata branch. That branch is apparently
broken, and Zane suggested on the review [1] that we abandon the patch
and close the branch.
That patch is the only
On 10/2/2018 10:41 AM, Miguel Lavalle wrote:
Hi Stable Team,
I want to nominate Bernard Cafarrelli as a stable core reviewer for
Neutron and related projects. Bernard has been increasing the number of
stable reviews he is doing for the project [1]. Besides that, he is a
stable maintainer down
On 10/1/2018 8:37 AM, Ghanshyam Mann wrote:
+1 on adding multiattach on integrated job. It is always good to cover more
features in integrate-gate instead of separate jobs. These tests does not take
much time, it should be ok to add in tempest-full [1]. We should make only
really slow test as
On 9/30/2018 11:02 AM, Matt Riedemann wrote:
Maybe that's some conditional branch logic we can hack into
devstack-gate [7] like we do for neutron? [8]
I'm hoping this works:
https://review.openstack.org/#/c/606853/
--
Tha
I finally got a passing neutron-grenade run in change [1]. That's the
grenade change which populates the placement DB in Stein from the
placement-related table contents of the nova_api DB from Rocky. It also
writes out the placement.conf file for Stein before starting the Stein
services.
As a
On 9/29/2018 10:01 PM, Tao Li wrote:
I found this test is added about ten days ago in this patch
https://review.openstack.org/#/c/599276/,
I checked it and don’t know why it failed. I think my commit shouldn’t
cause this issue. So do you any suggestion to me?
Yes it must be an intermittent
Nova, cinder and tempest run the nova-multiattach job in their check and
gate queues. The job was added in Queens and was a specific job because
we had to change the ubuntu cloud archive we used in Queens to get
multiattach working. Since Rocky, devstack defaults to a version of the
UCA that wo
There isn't really anything to report this week. There are no new
changes up for review that I'm aware of. If your team has posted changes
for your project, please update the related task in the story [1].
I'm also waiting for some feedback from glance-minded people about [2].
[1] https://stor
On 9/28/2018 3:12 PM, Clark Boylan wrote:
I was asked to write a followup to this as the long Zuul queues have persisted
through this week. Largely because the situation from last week hasn't changed
much. We were down the upgraded cloud region while we worked around a network
configuration bu
On 9/21/2018 9:08 AM, Elõd Illés wrote:
Hi,
Here is an etherpad with the teams that have stable:follow-policy tag on
their repos:
https://etherpad.openstack.org/p/ocata-final-release-before-em
On the links you can find reports about the open and unreleased changes,
that could be a useful in
Per the other thread on this [1] I've created an etherpad [2] to track
what needs to happen to get nova's stable/ocata branch ready for
Extended Maintenance [3] which means we need to flush our existing Ocata
backports that we want in the final Ocata release before tagging the
branch as ocata-e
On 9/27/2018 3:02 PM, Jay Pipes wrote:
A great example of this would be the proposed "deploy template" from
[2]. This is nothing more than abusing the placement traits API in order
to allow passthrough of instance configuration data from the nova flavor
extra spec directly into the nodes.instan
On 9/27/2018 2:33 PM, Fox, Kevin M wrote:
If the project plugins were maintained by the OSC project still, maybe there
would be incentive for the various other projects to join the OSC project,
scaling things up?
Sure, I don't really care about governance. But I also don't really care
about
On 9/27/2018 10:13 AM, Dean Troyer wrote:
On Thu, Sep 27, 2018 at 9:10 AM, Doug Hellmann wrote:
Monty Taylor writes:
Main difference is making sure these new deconstructed plugin teams
understand the client support lifecycle - which is that we don't drop
support for old versions of services i
On 9/27/2018 5:23 AM, Sylvain Bauza wrote:
On Thu, Sep 27, 2018 at 2:46 AM Matt Riedemann <mailto:mriede...@gmail.com>> wrote:
On 9/26/2018 5:30 PM, Sylvain Bauza wrote:
> So, during this day, we also discussed about NUMA affinity and we
said
> that we cou
On 9/26/2018 5:30 PM, Sylvain Bauza wrote:
So, during this day, we also discussed about NUMA affinity and we said
that we could possibly use nested resource providers for NUMA cells in
Stein, but given we don't have yet a specific Placement API query, NUMA
affinity should still be using the NUM
On 9/26/2018 3:01 PM, Doug Hellmann wrote:
Monty Taylor writes:
On 09/26/2018 01:55 PM, Tim Bell wrote:
Doug,
Thanks for raising this. I'd like to highlight the goal "Finish moving legacy
python-*client CLIs to python-openstackclient" from the etherpad and propose this
for a T/U series goa
On 9/25/2018 8:36 AM, John Garbutt wrote:
Another thing is about existing flavors configured for these
capabilities-scoped specs. Are you saying during the deprecation we'd
continue to use those even if the filter is disabled? In the review I
had suggested that we add a pre-upgrad
On 9/24/2018 12:12 PM, Jay Pipes wrote:
There were a couple points that I did manage to decipher, though. One
thing that both articles seemed to say was that OpenStack doesn't meet
public (AWS-ish) cloud use cases and OpenStack doesn't compare favorably
to VMWare either.
Yeah I picked up on t
On 9/24/2018 2:06 PM, Matt Riedemann wrote:
Are there more specific docs about how to configure the 'image import'
feature so that I can be sure I'm careful? In other words, are there
specific things a "glance-status upgrade check" check could look at and
say, "y
Looking at the upgrade-checkers goal [1] for glance and the Rocky
upgrade release notes [2], one upgrade note says:
"As Image Import will be always enabled, care needs to be taken that it
is configured properly from this release forward. The
‘enable_image_import’ option is silently ignored."
On 9/21/2018 4:19 PM, Ben Nemec wrote:
* The only two projects that I'm aware of with patches up at this
point are monasca [2] and designate [3]. The monasca one is tricky
because as I've found going through release notes for some projects,
they don't really have any major upgrade impacts so wr
On 9/21/2018 3:53 PM, Matt Riedemann wrote:
* The reference docs I wrote for writing upgrade checks is published now
[4]. As I've been answering some questions in storyboard and IRC, it's
obvious that I need to add some FAQs into those docs because I've taken
some of this for gr
Updates for this week:
* As bnemec noted in the last update [1], he's making some progress with
the oslo.upgradecheck library. He's retrofitting the nova-status upgrade
check code to use the library and has a patch up for designate to use it.
* The only two projects that I'm aware of with pat
On 9/21/2018 1:11 PM, Michael Johnson wrote:
Thank you Jimmy for making this available for updates.
I was unable to find the code backing the project tags section of the
Project Navigator pages.
Our page is missing some upgrade tags and is showing duplicate "Stable
branch policy" tags.
https://
On 9/20/2018 12:08 PM, Elõd Illés wrote:
Hi Matt,
About 1.: I think it is a good idea to cut a final release (especially
as some vendor/operator would be glad even if there would be some
release in Extended Maintenance, too, what most probably won't
happen...) -- saying that without knowing h
On 9/20/2018 10:23 AM, Jimmy McArthur wrote:
This is basically the CFP equivalent:
https://www.openstack.org/summit/berlin-2018/vote-for-speakers Voting
isn't necessary, of course, but it should allow you to see submissions
as they roll in.
Does this work for your purposes?
Yup, that shoul
On 9/20/2018 4:16 AM, John Garbutt wrote:
Following on from the PTG discussions, I wanted to bring everyone's
attention to Nova's plans to deprecate ComputeCapabilitiesFilter,
including most of the the integration with Ironic Capabilities.
To be specific, this is my proposal in code form:
http
On 9/17/2018 11:13 AM, Jimmy McArthur wrote:
The Forum Topic Submission session started September 12 and will run
through September 26th. Now is the time to wrangle the topics you
gathered during your Brainstorming Phase and start pushing forum topics
through. Don't rely only on a PTL to make
On 9/19/2018 2:45 PM, Matt Riedemann wrote:
Another one we need to make a decision on is:
https://bugs.launchpad.net/tempest/+bug/1783405
Which I'm suggesting we need to mark more slow tests with the actual
"slow" tag in Tempest so they move to only be run in the tempest-slow
On 9/19/2018 2:11 PM, Clark Boylan wrote:
Unfortunately, right now our classification rate is very poor (only 15%), which
makes it difficult to know what exactly is causing these failures. Mriedem and
I have quickly scanned the unclassified list, and it appears there is a db
migration testing
On 9/19/2018 10:25 AM, Chris Dent wrote:
I'd like to nominate Tetsuro Nakamura for membership in the
placement-core team. Throughout placement's development Tetsuro has
provided quality reviews; done the hard work of creating rigorous
functional tests, making them fail, and fixing them; and imp
On 12/1/2017 2:47 PM, Matt Riedemann wrote:
Andrew Laski also mentioned in IRC that we didn't replace the original
instance.image_ref with the shelved image id because the shelve
operation should be transparent to the end user, they have the same
image (not really), same volumes, same IPs
On 9/18/2018 12:26 PM, Matt Riedemann wrote:
On 9/17/2018 9:41 PM, Ghanshyam Mann wrote:
On Tue, 18 Sep 2018 09:33:30 +0900 Alex Xu
wrote
> That only means after 599276 we only have servers API and
os-instance-action API stopped accepting the undefined query parameter.
>
On 9/18/2018 9:52 PM, Matt Riedemann wrote:
On 9/18/2018 12:28 PM, Doug Hellmann wrote:
What's probably missing is a version of the grenade job that allows us
to control that USE_PYTHON3 variable before and after the upgrade.
I see a few different grenade jobs (neutron-grenade,
neutron-gr
On 9/18/2018 12:28 PM, Doug Hellmann wrote:
What's probably missing is a version of the grenade job that allows us
to control that USE_PYTHON3 variable before and after the upgrade.
I see a few different grenade jobs (neutron-grenade,
neutron-grenade-multinode,
legacy-grenade-dsvm-neutron-multin
On 9/17/2018 11:13 AM, Jimmy McArthur wrote:
Hello Everyone!
The Forum Topic Submission session started September 12 and will run
through September 26th. Now is the time to wrangle the topics you
gathered during your Brainstorming Phase and start pushing forum topics
through. Don't rely only
The release page says Ocata is planned to go into extended maintenance
mode on Aug 27 [1]. There really isn't much to this except it means we
don't do releases for Ocata anymore [2]. There is a caveat that project
teams that do not wish to maintain stable/ocata after this point can
immediately
On 9/17/2018 9:41 PM, Ghanshyam Mann wrote:
On Tue, 18 Sep 2018 09:33:30 +0900 Alex Xu wrote
> That only means after 599276 we only have servers API and
os-instance-action API stopped accepting the undefined query parameter.
> What I'm thinking about is checking all the APIs, ad
On 9/17/2018 3:06 PM, Jay Pipes wrote:
My vote would be just change additionalProperties to False in the 599276
patch and be done with it.
Well, it would be on a microversion boundary so the user would be opting
into this stricter validation, but that's the point of microversions. So
my custo
This is a question from a change [1] which adds a new changes-before
filter to the servers, os-instance-actions and os-migrations APIs.
For context, the os-instance-actions API stopped accepting undefined
query parameters in 2.58 when we added paging support.
The os-migrations API stopped all
On 9/15/2018 9:50 PM, Fred Li wrote:
As a non-native English speaker, it is nice-to-have that some TC or BoD
can stay in the local social media, like wechat group in China. But it
is also very difficult for non-native Chinese speakers to stay find
useful information in ton of Chinese chats.
My
On 9/14/2018 1:52 PM, Zhipeng Huang wrote:
This is a joint question from mnaser and me :)
For the candidates who are running for tc seats, please reply to this
email to indicate if you are open to use certain social media app in
certain region (like Wechat in China, Line in Japan, etc.), in or
Just a couple of updates this week.
* I have assigned PTLs (for projects that have PTLs [1]) to their
respective tasks in StoryBoard [2]. If someone else on your team is
planning on working on the pre-upgrade check goal then please just
reassign ownership of the task.
* I have started going
tl;dr: I'm proposing a new parameter to the server stop (and suspend?)
APIs to control if nova shelve offloads the server.
Long form: This came up during the public cloud WG session this week
based on a couple of feature requests [1][2]. When a user stops/suspends
a server, the hypervisor free
On 3/28/2018 4:35 PM, Jay Pipes wrote:
On 03/28/2018 03:35 PM, Matt Riedemann wrote:
On 3/27/2018 10:37 AM, Jay Pipes wrote:
If we want to actually fix the issue once and for all, we need to
make availability zones a real thing that has a permanent identifier
(UUID) and store that permanent
On 9/12/2018 5:32 PM, Melvin Hillsman wrote:
We basically spent the day focusing on two things specific to what you
bring up and are in agreement with you regarding action not just talk
around feedback and outreach. [1]
We wiped the agenda clean, discussed our availability (set reasonable
expec
On 9/12/2018 5:13 PM, Jeremy Stanley wrote:
Sure, and I'm saying that instead I think the influence of TC
members_can_ be more valuable in finding and helping additional
people to do these things rather than doing it all themselves, and
it's not just about the limited number of available hours i
1 - 100 of 2325 matches
Mail list logo
