On Wed, May 30, 2018 at 1:33 AM, Nadathur, Sundar wrote:
> Hi all,
>The Cyborg/Nova scheduling spec [1] details what traits will be applied
> to the resource providers that represent devices like GPUs. Some of the
> traits referred to vendor names. I got feedback that traits must not refer
>
Hello,
Is there any user story for the scenario below?
- Octavia is set to TERMINATED_HTTPS and also initiates SSL to backend
servers
After testing all the combination possible and after looking at the Octavia
haproxy templates in Queens version I understand that this kind of setup i
Hi
It is with a somewhat heavy heart that I have decided that it is time to hang up my keystone core status. Having been involved since the closing stages of Folsom, I've had a good run! When I look at how far keystone has come since the v2 days, it is remarkable - and we should all feel a sense
On Wed, May 30, 2018, at 10:45 AM, Henry Nash wrote:
> Hi
>
> It is with a somewhat heavy heart that I have decided that it is time to
> hang up my keystone core status. Having been involved since the closing
> stages of Folsom, I've had a good run! When I look at how far keystone
> has come sinc
Hi,
This is a great discussion and a great suggestion overall, but I'd like to add a
grain of salt here, especially after reading some comments.
Nitpicking is bad, no disagreement. However, I don't like this whole discussion
to end up marking -1's as offense or aggression. Just as often as I
Hi Sylvain,
Glad to know we are on the same page. I haven't updated the spec with
this proposal yet, in case I got more comments :). I will do so by today.
Thanks,
Sundar
On 5/30/2018 12:34 AM, Sylvain Bauza wrote:
On Wed, May 30, 2018 at 1:33 AM, Nadathur, Sundar
mailto:sundar.nadat...@
Jay S Bryant wrote:
On 5/29/2018 3:19 PM, Doug Hellmann wrote:
Excerpts from Jonathan Proulx's message of 2018-05-29 16:05:06 -0400:
On Tue, May 29, 2018 at 03:53:41PM -0400, Doug Hellmann wrote:
:> >> maybe we're all saying the same thing here?
:> > Yeah, I feel like we're all essentially in
On Tue, May 29, 2018 at 3:12 PM, Sylvain Bauza
wrote:
On Tue, May 29, 2018 at 2:21 PM, Balázs Gibizer
wrote:
On Tue, May 29, 2018 at 1:47 PM, Sylvain Bauza
wrote:
Le mar. 29 mai 2018 à 11:02, Balázs Gibizer
a écrit :
On Tue, May 29, 2018 at 9:38 AM, Sylvain Bauza
wrote:
>
>
Hi Watchers,
I cancel weekly meeting today because of urgent internal meetings.
I’m available on openstack-watcher channel most of the time.
Let’s meet on June 6.
Best Regards,
Alex
__
OpenStack Development Mailing List
Hi,
We aim at collecting inter failures time for the compute and network
resources (i.e., availability and reliability of each resource).
Is there any mean via Restfull to collect these metrics ?
If not, which OpenStack/celiometer/heat modules may be extended in order to
collect this information
Hi all,
The docs meeting will continue today at 16:00 UTC in
#openstack-doc, as scheduled. For more details, see the meeting page:
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting
Cheers,
pk
__
OpenStack Development
Samuel Cassiba wrote:
[...]
The moniker of 'low-activity' does give the very real, negative
perception that things are just barely hanging on. It conveys the
subconscious, officiated statement (!!!whether or not this was
intended!!!) that nobody in their right mind should consider using the
s
Hi,
In the last two days the ceilometer [1] [2] [3] and tooz [4] [5] [6]
tox-py27 periodic stable jobs are failing. The root cause is the following:
* cmd2 released version 0.9.0, which requires python >=3.4 from now on.
These projects have comment in their tox.ini that they do not consume
upp
On Wed, May 30 2018, Elõd Illés wrote:
> In the last two days the ceilometer [1] [2] [3] and tooz [4] [5] [6] tox-py27
> periodic stable jobs are failing. The root cause is the following:
> * cmd2 released version 0.9.0, which requires python >=3.4 from now on.
> These projects have comment in the
Hello,
We have raised a bug in launchpad and the bug link is as follows:
https://bugs.launchpad.net/heat-dashboard/+bug/1769089 .
Can anyone please provide a solution or fix for this issue since it's been
20 days since we have created this bug.
Thanks&Regards,
Ashika Meher
___
cmd2 says that:
"Python 2.7 support is EOL
Support for adding new features to the Python 2.7 release of |cmd2| was
discontinued on April 15, 2018. Bug fixes will be supported for Python
2.7 via 0.8.x until August 31, 2018.
Supporting Python 2 was an increasing burden on our limited resources
On 2018-05-30 14:42:58 +0200 (+0200), Julien Danjou wrote:
[...]
> The question is: why cmd2 0.9.0 does not work and how do we fix that?
The cmd2 maintainers decided that they no longer want to carry
support for old Python interpreters, so versions starting with 0.9.0
only work on Python 3.4 and l
Jeremy Stanley wrote:
On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote:
It is my understanding that the infra team will enforce the
following conditions when a repo import request is received:
* The repo must be licensed under an OSI-approved open source
license.
That has been our cust
Try asking people in webirc
webchat.freenode.net
Nickname : your name
channel: #openstack-heat
and you will find people ask them it's better to talk to them rather than
here people might not respond here there you have a good chance
https://review.openstack.org/#/admin/groups/114,members
Hi,
First off, sorry for being late to response.
Looking at your comment,
your environment is Newton & AFAIK Newton is EOL, even if you will wait for
the fix, it will not be delivered to Newton.
https://releases.openstack.org/
Current my concern is that your raised issue may happen in Queens co
Hi Radomir,
I'm adding the debian bug as Cc.
On 05/28/2018 08:35 AM, Radomir Dopieralski wrote:
> I did a quick search for all the glyphs we are using:
>
> ~/dev/horizon(master)> ag 'fa-' | egrep -o 'fa-[a-z-]*' | sort | uniq
> fa-
> fa-angle-left
> [...]
Thanks for your investigation.
I did a
Hi
As Kaz mentioned,
Since we moved to StoryBoard (instead of Launchapd) please maintain your
bug here: https://storyboard.openstack.org/#!/story/1769089
Also, I try to use the same template [1] as you did to create a stack in
master version and it works (I can't reproduce it)
If possible, can y
I know the keystone team has been doing a lot of work on scoped tokens
and Lance has been trying to roll that out to other projects (like nova).
In Rocky the nova team is adding granular policy rules to the placement
API [1] which is a good opportunity to set scope on those rules as well.
For
On Tue, May 29, 2018 at 7:42 PM, Zane Bitter wrote:
[trim]
> Since I am replying to this thread, Julia also mentioned the situation where
> two core reviewers are asking for opposite changes to a patch. It is never
> ever ever the contributor's responsibility to resolve a dispute between two
> cor
I remember when I first started contributing upstream, I spent a
Saturday sending you internal emails asking about the intricacies of
database migrations :)
Since then you've give me (or I've stolen) a number of other tools and
techniques. Thanks for everything you've done for this community, Henr
On Wed, May 30, 2018 at 5:05 AM, Colleen Murphy wrote:
> On Wed, May 30, 2018, at 10:45 AM, Henry Nash wrote:
>> Hi
>>
>> It is with a somewhat heavy heart that I have decided that it is time to
>> hang up my keystone core status. Having been involved since the closing
>> stages of Folsom, I've ha
> can I know a use case for this 'live copy metadata or ' the 'only way
> to access device tags when hot-attach? my thought is this is one time
> thing in cloud-init side either through metatdata service or config
> drive and won't be used later? then why I need a live copy?
If I do something lik
We are on for this tomorrow (Thursday) at 2pm UTC (10am EST).
We'll meet here: https://redhat.bluejeans.com/dprince/ and record it
live. We'll do an overview presentation and then perhaps jump into a
terminal for some live questions.
Dan
On Tue, May 15, 2018 at 10:51 AM, Emilien Macchi wrote:
>
Hi Thomas,
> As my python3-xstatic-font-awesome removes the embedded fonts
It sounds like you broke xstatic-* packages for Debian and use something we
don't test with Horizon at all.
Speaking about Rocky/master version, our upper-constraint
XStatic-Font-Awesome===4.7.0.0 [1]. We don't test hor
On 05/30/2018 03:54 PM, Julia Kreger wrote:
On Tue, May 29, 2018 at 7:42 PM, Zane Bitter wrote:
[trim]
Since I am replying to this thread, Julia also mentioned the situation where
two core reviewers are asking for opposite changes to a patch. It is never
ever ever the contributor's responsibili
On 05/30/2018 04:10 PM, Dan Prince wrote:
> We are on for this tomorrow (Thursday) at 2pm UTC (10am EST).
meaning 3:00pm CET - conflicting with my squad meeting (3:30pm for squad
red) :(. I'll watch it on youtube then.
>
> We'll meet here: https://redhat.bluejeans.com/dprince/ and record it
> li
I don't feel like anyone is proposing to end the use of -1's, but that
we should generally be encouraging, accepting, and trusting. That
means if there are major gaps or issues, then the use of a -1 is
perfectly valid because it needs more work. We also need to be mindful
of context as well, and in
I see another problem working on patchsets with lots of revisions and
long-lived history, such as specs or a complex change. The opinions of
several reviewers may be different. So first reviewer lefts a comment, the
owner of the change amends the patch according to it. But after time and
iterations
On 30 May 2018 at 12:57, amal kammoun wrote:
> Hi,
>
> We aim at collecting inter failures time for the compute and network
> resources (i.e., availability and reliability of each resource).
>
> Is there any mean via Restfull to collect these metrics ?
>
You can use monasca-api to get measuremen
On 05/30/2018 08:47 AM, Matt Riedemann wrote:
> I know the keystone team has been doing a lot of work on scoped tokens
> and Lance has been trying to roll that out to other projects (like nova).
>
> In Rocky the nova team is adding granular policy rules to the
> placement API [1] which is a good
On Wed, May 30 2018, Elõd Illés wrote:
> cmd2 says that:
>
> "Python 2.7 support is EOL
>
> Support for adding new features to the Python 2.7 release of |cmd2| was
> discontinued on April 15, 2018. Bug fixes will be supported for Python 2.7 via
> 0.8.x until August 31, 2018.
>
> Supporting Python
On 05/30/2018 04:13 PM, Ivan Kolodyazhny wrote:
> Hi Thomas,
>
>
> As my python3-xstatic-font-awesome removes the embedded fonts
>
>
> It sounds like you broke xstatic-* packages for Debian and use something
> we don't test with Horizon at all.
>
> Speaking about Rocky/master version, our
On 30/05/18 00:52, Cédric Jeanneret wrote:
Another issue is that if the original author needs to rev the patch
again for any reason, they then need to figure out how to check out the
modified patch. This requires a fairly sophisticated knowledge of both
git and gerrit, which isn't a problem for t
On 2018-05-30 16:59:10 +0200 (+0200), Julien Danjou wrote:
[...]
> I see cliff has already set that requirements in its master branch, but
> no new version has been released. Releasing a new cliff version should
> fix that issue.
Yes, that's in progress today.
--
Jeremy Stanley
signature.asc
De
On Wednesday, 30 May 2018 17:13:41 CEST Zane Bitter wrote:
> On 30/05/18 00:52, Cédric Jeanneret wrote:
> >> Another issue is that if the original author needs to rev the patch
> >> again for any reason, they then need to figure out how to check out the
> >> modified patch. This requires a fairly s
On Wed, May 30, 2018, at 8:13 AM, Zane Bitter wrote:
> On 30/05/18 00:52, Cédric Jeanneret wrote:
> >> Another issue is that if the original author needs to rev the patch
> >> again for any reason, they then need to figure out how to check out the
> >> modified patch. This requires a fairly sophi
Excerpts from Jeremy Stanley's message of 2018-05-30 13:00:31 +:
> On 2018-05-30 14:42:58 +0200 (+0200), Julien Danjou wrote:
> [...]
> > The question is: why cmd2 0.9.0 does not work and how do we fix that?
>
> The cmd2 maintainers decided that they no longer want to carry
> support for old P
Hi Mihaela,
Backend re-encryption is on our roadmap[1], but not yet implemented.
We have all of the technical pieces to make this work, it's just
someone getting time to do the API additions and update the flows.
[1]
https://wiki.openstack.org/wiki/Octavia/Roadmap#Considerations_for_Octavia_3.0.
Thank you for all your invaluable contributions Henry. It has been a pleasure
working with you. Best of luck!
Kristi
‐‐‐ Original Message ‐‐‐
On May 30, 2018 4:45 AM, Henry Nash wrote:
> Hi
>
> It is with a somewhat heavy heart that I have decided that it is time to hang
> up my keyst
Hi,
With recent changes implemented by the OpenStack Foundation to include
projects other than "OpenStack" under its umbrella, it has become clear
that the "Project Infrastructure Team" needs to change.
The infrastructure that is run for the OpenStack project is valued by
other OpenStack Foundati
On Thu, 2018-04-26 at 15:49 +0100, Stephen Finucane wrote:
> On Wed, 2018-04-25 at 12:06 -0500, Sean McGinnis wrote:
> > > > >
> > > > > [1] https://review.openstack.org/#/c/564232/
> > > > >
> > > >
> > > > The only concern I have is that it may slow the transition to the
> > > > python 3 versi
===
#openstack-doc: docteam
===
Meeting started by pkovar at 16:00:44 UTC. The full logs are available
at
http://eavesdrop.openstack.org/meetings/docteam/2018/docteam.2018-05-30-16.00.log.html
.
Meeting summary
---
* Ops docs discussion (p
Excerpts from corvus's message of 2018-05-30 09:25:14 -0700:
> Hi,
>
> With recent changes implemented by the OpenStack Foundation to include
> projects other than "OpenStack" under its umbrella, it has become clear
> that the "Project Infrastructure Team" needs to change.
>
> The infrastructure
Excerpts from Jeremy Stanley's message of 2018-05-29 22:57:45 +:
> On 2018-05-29 17:26:16 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > There was some discussion of whether the office hours themselves
> > are useful, based on the apparent lack of participation. We had
> > theories that this w
Doug Hellmann writes:
>> * Move many of the git repos currently under the OpenStack project
>> infrastructure team's governance to this new team.
>
> I'm curious about the "many" in that sentence. Which do you anticipate
> not moving, and if this new team replaces the existing team then who
> w
On 2018-05-30 10:09:23 -0700 (-0700), James E. Blair wrote:
[...]
> An example of something that probably shouldn't move is
> "openstack-zuul-jobs". We still need people that are concerned with how
> OpenStack uses the winterscale service. I'm not sure whether that
> should be its own team or sho
Hi Gilles, I hope you enjoyed your Summit!?
Did you had any interesting talk to report about our little initiative ?
Le dim. 6 mai 2018 à 15:01, Gilles Dubreuil a écrit :
>
> Akihiro, thank you for your precious help!
>
> Regarding the choice of Neutron as PoC, I'm sorry for not providing much
>
It was great working with you Henry. Hope to see you around sometime and
wishing you all the best!
On Wed, May 30, 2018 at 3:45 AM, Henry Nash wrote:
> Hi
>
> It is with a somewhat heavy heart that I have decided that it is time to
> hang up my keystone core status. Having been involved since t
Excerpts from Doug Hellmann's message of 2018-05-29 17:26:16 -0400:
[snip]
> Chris brought up a concern about whether we have much traction on
> "doing stuff" and especially "getting things done that not everyone
> wants," Graham noted a lack of "visible impact," and Zane mentioned
> the TC visio
Excerpts from Jeremy Stanley's message of 2018-05-30 17:30:23 +:
> On 2018-05-30 10:09:23 -0700 (-0700), James E. Blair wrote:
> [...]
> > An example of something that probably shouldn't move is
> > "openstack-zuul-jobs". We still need people that are concerned with how
> > OpenStack uses the
Excerpts from corvus's message of 2018-05-30 10:09:23 -0700:
> Doug Hellmann writes:
>
> >> * Move many of the git repos currently under the OpenStack project
> >> infrastructure team's governance to this new team.
> >
> > I'm curious about the "many" in that sentence. Which do you anticipate
>
Howdy all,
This cycle, we have our spec freeze later than usual at milestone r-2
June 7 because of the review runways system we've been trying out. We
wanted to allow more time for spec approvals as blueprints were
completed via runways.
So, ahead of the spec freeze, let's have a spec review
On Thu, 2018-05-17 at 09:58 +0200, Thierry Carrez wrote:
> Jeremy Stanley wrote:
> > [...]
> > As a community, we're likely to continue to make imbalanced
> > trade-offs against relevant security features if we don't move
> > forward and declare that some sort of standardized key storage
> > soluti
On Thu, 2018-05-17 at 10:33 +0200, Cédric Jeanneret wrote:
>
> On 05/17/2018 10:18 AM, Bogdan Dobrelya wrote:
> > On 5/17/18 9:58 AM, Thierry Carrez wrote:
> > > Jeremy Stanley wrote:
> > > > [...]
> > > > As a community, we're likely to continue to make imbalanced
> > > > trade-offs against relev
On 2018-05-30 12:25 PM, James E. Blair wrote:
I propose we call the overall effort "winterscale". In the best
tradition of code names, it means nothing; look for no hidden meaning
here. We won't use it for any actual services we provide. We'll use it
to refer to the overall effort of restructu
This all sounds fully reasonable to me. One thing, though...
>> * There is a resource class per device category e.g.
>> CUSTOM_ACCELERATOR_GPU, CUSTOM_ACCELERATOR_FPGA.
Let's propose standard resource classes for these ASAP.
https://github.com/openstack/nova/blob/d741f624c81baf89f
Hi everyone:
Over the past week in the summit, there was a lot of discussion
regarding StarlingX
and members of the technical commitee had a few productive discussions regarding
the best approach to deal with a proposed new pilot project for
incubation in the OSF's Edge
Computing strategic focus a
On 5/30/2018 9:53 AM, Lance Bragstad wrote:
While scope isn't explicitly denoted by an
attribute, it can be derived from the attributes of the token response.
Yeah, this was confusing to me, which is why I reported it as a bug in
the API reference documentation:
https://bugs.launchpad.net/k
Greetings,
The TripleO CI team has just completed Sprint 13 (5/3 - 05/23). The
following is a summary of activities during our sprint. Details on our
team structure can be found in the spec [1].
# Sprint 13 Epic (CI Squad): Upgrade Support and Refactoring
- Epic Card: https://trello.com/c/cu
Hello all,
I have talked to several people about this and I would love to get this
finalized once and for all. I have checked the OpenStack puppet modules which
are mostly developed by the Red Hat team, as of right now, TripleO is using a
combo of Ansible and puppet to deploy but in the next co
Doug Hellmann writes:
>> >> * Establish a "winterscale infrastructure council" (to be renamed) which
>> >> will govern the services that the team provides by vote. The council
>> >> will consist of the PTL of the winterscale infrastructure team and one
>> >> member from each official OpenS
On Wed, 30 May 2018, Julia Kreger wrote:
I don't feel like anyone is proposing to end the use of -1's, but that
we should generally be encouraging, accepting, and trusting.
Being encouraging, accepting, and trusting is the outcome I'd like
to see from this process. Being less nitpicking is a b
Please see below:
On Wed, May 30, 2018 at 2:37 PM, Chris Dent wrote:
> On Wed, 30 May 2018, Julia Kreger wrote:
>
>> I don't feel like anyone is proposing to end the use of -1's, but that
>> we should generally be encouraging, accepting, and trusting.
>
>
> Being encouraging, accepting, and trust
Coming from Ops, yes things should always be deployable, backward
compatible and shouldn't break, but at the same time we're talking about a
master branch which is always in flux and not an actual release. I think
that statement you provided Dims should apply to releases or tags and not
the master
As promised in the sessions, here are the slides that were presented:
https://www.slideshare.net/BenNemec1/oslo-vancouver-onboarding
https://www.slideshare.net/BenNemec1/oslo-vancouver-project-update
The font in the onboarding one got a little funny in the conversion, so
if you want to see the
Howdy everyone,
As I'm sure many of you have noticed, Sean Dague has shifted his focus
onto other projects outside of Nova for some time now, and with that,
I'm removing him from the core team at this time.
I consider our team fortunate to have had the opportunity to work with
Sean over the
On Sun, Apr 29, 2018 at 09:36:15AM +0200, Jean-Philippe Evrard wrote:
> Hello,
>
> > I'd like to phase out openstack/openstack-ansible-tests and
> > openstack/openstack-ansible later.
>
> Now that we had the time to bump the roles in openstack-ansible, and
> adapt the tests, we can now EOL the re
During today's Swift team meeting[1], we discussed the idea of
relaxing review guidelines. We agreed the normal case is "one core
reviewer's approval is sufficient to land code".
We've long had a "one +2" policy for trivial and obviously correct
patches. Put simply, the old policy was one of "nor
"master should be always deployable and fully backward compatible and
so we cant let anything in anytime that could possibly regress anyone"
Should we change that attitude too? Anyone agree? disagree?
Thanks,
Dims
I'll definitely jump at this one.
I've always thought (and shared on the ML s
Welcome to the twenty second edition of a weekly update in TripleO world!
The goal is to provide a short reading (less than 5 minutes) to learn
what's new this week.
Any contributions and feedback are welcome.
Link to the previous version:
http://lists.openstack.org/pipermail/openstack-dev/2018-May
On Sat, Apr 14, 2018 at 11:02:54AM +0800, Jeffrey Zhang wrote:
> hi stable team,
>
> Kolla project is ready for Newton EOL. Since kolla-ansible is split from
> kolla since ocata cycle, so there is not newton branch in kolla-ansible.
> please make following repo EOL
>
> openstack/kolla
Okay I di
To play devils advocate and as someone that has had to git bisect an ugly
regression once I still think its important not to break trunk. It can be much
harder to deal with difficult issues like that if trunk frequently breaks.
Thanks,
Kevin
From: Sean Mc
On 2018-05-30 14:50:11 -0700 (-0700), Davanum Srinivas wrote:
[...]
> Let me poke at this a bit. Some of the projects do say (not in so
> many words):
>
> "master should be always deployable and fully backward compatible and
> so we cant let anything in anytime that could possibly regress anyone"
On 2018-05-31 00:21:35 + (+), Fox, Kevin M wrote:
> To play devils advocate and as someone that has had to git bisect
> an ugly regression once I still think its important not to break
> trunk. It can be much harder to deal with difficult issues like
> that if trunk frequently breaks.
[...]
On Wed, May 30, 2018 at 5:23 PM, Jeremy Stanley wrote:
> On 2018-05-30 14:50:11 -0700 (-0700), Davanum Srinivas wrote:
> [...]
>> Let me poke at this a bit. Some of the projects do say (not in so
>> many words):
>>
>> "master should be always deployable and fully backward compatible and
>> so we c
On Thu, May 31, 2018 at 12:21:35AM +, Fox, Kevin M wrote:
> To play devils advocate and as someone that has had to git bisect an ugly
> regression once I still think its important not to break trunk. It can be
> much harder to deal with difficult issues like that if trunk frequently
> breaks
On Thu, May 31, 2018 at 2:25 AM, James E. Blair wrote:
> Hi,
>
> With recent changes implemented by the OpenStack Foundation to include
> projects other than "OpenStack" under its umbrella, it has become clear
> that the "Project Infrastructure Team" needs to change.
>
> The infrastructure that i
Hi,
I'm using Ceph for cinder backend.
Do you have any plan to support multiattach for Ceph backend?
Thanks
Yafeng
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.ope
On Wed, May 30, 2018 at 6:09 PM, Matthew Treinish wrote:
> On Thu, May 31, 2018 at 12:21:35AM +, Fox, Kevin M wrote:
>> To play devils advocate and as someone that has had to git bisect an ugly
>> regression once I still think its important not to break trunk. It can be
>> much harder to dea
On Wed, May 30, 2018 at 10:00 PM, fengyd wrote:
> Hi,
>
> I'm using Ceph for cinder backend.
> Do you have any plan to support multiattach for Ceph backend?
A lot of people have expressed an interest in this, so I'm sure
multi-attach with Ceph will eventually be supported. However, it will
requir
The lack of ceph support is a ceph problem rather than a Cinder problem.
There are issues with replication and multi-attached RBD volumes asd I
understand it. The ceph folks are aware but have other priorities
presently. I encourage making your interest known to them.
In the meantime, check out M
On May 30, 2018, at 5:11 AM, Dmitry Tantsur wrote:
> Whatever decision the TC takes, I would like it to make sure that we don't
> paint putting -1 as a bad act. Nor do I want "if you care, just follow-up" to
> be an excuse for putting up bad contributions.
>
> Additionally, I would like to hav
We don't have anything on the agenda yet for this week's manila
meeting and my travel plans just got shuffled so I'm in the air at our
regular time so let's cancel this week's meeting and start
up again the following week.
We'll have a summary of relevant Summit events then.
-- Tom Barron (tb
On May 6, 2018, at 8:01 AM, Gilles Dubreuil wrote:
> Regarding the choice of Neutron as PoC, I'm sorry for not providing much
> details when I said "because of its specific data model",
> effectively the original mention was "its API exposes things at an
> individual table level, requiring the
Hi Kaz,
Thank you for the update regarding the issue ( https://storyboard.
openstack.org/#!/story/1769089 ). To be more clear the issue is as follows,
we have tried accessing horizon(GUI) with port forwarding(tunnel link) and
also with the direct IP. So, when we use port forwarding stack launch is
On Wed, May 30, 2018 at 11:53 PM, Lance Bragstad wrote:
>
>
> On 05/30/2018 08:47 AM, Matt Riedemann wrote:
>> I know the keystone team has been doing a lot of work on scoped tokens
>> and Lance has been trying to roll that out to other projects (like nova).
>>
>> In Rocky the nova team is adding
hi,
i plan to add Kazuhiro Suzuki to tap-as-a-service-core group. [1]
he is one of active members of the project.
he is also the original author of tap-as-a-service-dashboard.
i'll make the change after a week unless i hear any objections/concerns.
[1] https://review.openstack.org/#/admin/groups/
On 5/30/2018 1:18 PM, Eric Fried wrote:
This all sounds fully reasonable to me. One thing, though...
* There is a resource class per device category e.g.
CUSTOM_ACCELERATOR_GPU, CUSTOM_ACCELERATOR_FPGA.
Let's propose standard resource classes for these ASAP.
https://github.co
have no idea about this too.
and it looks as expected.
Thanks tony
On Thu, May 31, 2018 at 8:17 AM Tony Breeds wrote:
>
> On Sat, Apr 14, 2018 at 11:02:54AM +0800, Jeffrey Zhang wrote:
> > hi stable team,
> >
> > Kolla project is ready for Newton EOL. Since kolla-ansible is split from
> > kolla
+1
Soichi
On 2018/05/31 14:36, Takashi Yamamoto wrote:
hi,
i plan to add Kazuhiro Suzuki to tap-as-a-service-core group. [1]
he is one of active members of the project.
he is also the original author of tap-as-a-service-dashboard.
i'll make the change after a week unless i hear any objections
95 matches
Mail list logo
