On Thu, Oct 18, 2018 at 4:45 PM John Fulton wrote:
> On Thu, Oct 18, 2018 at 11:56 AM Jim Rollenhagen
> wrote:
> >
> > On Thu, Oct 18, 2018 at 10:23 AM Dmitry Tantsur
> wrote:
> >>
> >> Hi all,
> >>
> >> Sorry for chiming i
ng_Group/Edge_Reference_Architectures#Overview
>
> Now, I don't have really great suggestions. Something that came up in
> TripleO
> discussions [1] is Core/Hub/Edge, which I think reflects the idea better.
>
I'm also fine
ed with Taskflow a few years
> back. Eventually the other 2 gave up and moved on also.
>
As a note, the 2+2 requirement is only a convention, not a rule. Swift has
moved to 1+2 already, and other projects have considered it.
// jim
_
On Tue, Oct 9, 2018 at 10:25 PM Gilles Dubreuil wrote:
>
>
> On 09/10/18 23:58, Jeremy Stanley wrote:
> > On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote:
> > [...]
> >> It seems to me that a major goal of openstacksdk is to hide differences
> >&g
On Mon, Oct 8, 2018 at 5:58 AM Gilles Dubreuil wrote:
>
> On 05/10/18 21:54, Jim Rollenhagen wrote:
>
> GraphQL has introspection features that allow clients to pull the schema
> (types, queries, mutations, etc): https://graphql.org/learn/introspection/
>
> That said, it see
nity
> could or should take ownership of?
>
Makes sense to me, but we should also have an explicit goal of using tenks
to kill our devstack code (and the other things mentioned).
Consider me +2 on the spec but leaving time for additional discussion. :)
Thank
x27;d
have to fetch the schema, map it to actual features somehow, and adjust
queries based on this info.
I guess there might be a middleground where we could fetch the REST API
version, and know from that what GraphQL queries can be made.
// jim
On Fri, Oct 5, 2018 at 7:30 AM Doug Hellmann
majority of use cases right away
> without having to wait for that ideal solution to materialize.
>
Ah, good point, I had missed that initially. Thanks. Let's do that.
So if we all agree Jay's proposal is the right thing to do, is there any
reason to start working on a short-term ha
And you would also have a list of traits in the deploy template:
{"traits": {"required": ["STORAGE_HARDWARE_RAID"]}, "config": }
This allows for making flavors that are reasonably flexible (instead of two
flavors that do VMX and IPSEC acceleration, one of wh
On Mon, Oct 1, 2018 at 10:13 AM Jay Pipes wrote:
> On 10/01/2018 09:01 AM, Jim Rollenhagen wrote:
> > On Mon, Oct 1, 2018 at 8:03 AM Jay Pipes > <mailto:jaypi...@gmail.com>> wrote:
> >
> > On 10/01/2018 04:36 AM, John Garbutt wrote:
> > &g
ace for now, while we decide what to do (i.e. future of "deploy
> > template" concept).
> >
> > It feels like Ironic's plan to define the "deploy templates" in Ironic
> > should replace the dependency on Glare for this use case, largely
> >
board ordered by priority
>
I, for one, would not want to scroll through every lane on a large
project's bug board to find the priority or target date for a given bug.
For example, Nova has 819 open bugs right now.
It would be a muc
On Wed, Sep 19, 2018 at 8:49 AM, Jim Rollenhagen
wrote:
>
> Tuesday: edge
>
Since cdent asked in IRC, when we talk about edge and far edge, we defined
these roughly like this:
https://usercontent.irccloud-cdn.com/file/NunkkS2y/edge_architecture1.JP
en about to death).
// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
milar
> to what I described above, I no longer have concerns or objections.
>
The plan is to maintain support for both Python 2 and 3 in the T release
(and possibly S, if the projects get py3 work done quickly). See
https://governance.openstack.org/tc/resolutions/20180529-python2-deprecation-ti
On Wed, Sep 12, 2018 at 2:28 PM, Doug Hellmann
wrote:
> Excerpts from Doug Hellmann's message of 2018-09-12 12:04:02 -0600:
> > Excerpts from Clark Boylan's message of 2018-09-12 10:44:55 -0700:
> > > On Wed, Sep 12, 2018, at 10:23 AM, Jim Rollenhagen wrote:
>
n the other node.
Should we (openstack) test this situation, or even care?
// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
eo-ipsec
>
> the rest of the repos seem to be plugins, which I'm personally less
> concerned about, but should still be branched (preferably sooner rather
> than later).
>
Tempest plugins, like tempest, are not meant to be branched:
http://lists.openstack.org/pipermail/opens
k One Platform for containers/VMs/Bare Metal (Strategic
> session) the entire community congregates to share opinions on how to make
> OpenStack achieve its integration engine goal
>
Just to clarify some speculation going on in IRC: this is an example,
right? Not a new thi
ifrost. With this change I hope to get more exposure
> for it.
>
> The library itself is small, documented [2], follows OpenStack practices
> and does not have particular operating requirements. There is nothing in it
> that is not familiar to the Ironic team members.
>
I
++
// jim
On Thu, Aug 23, 2018 at 2:24 PM, Julia Kreger
wrote:
> Greetings everyone!
>
> In our team meeting this week we stumbled across the subject of
> promoting contributors to be sub-project's core reviewers.
> Traditionally it is something we've only addressed
;ll be welcomed back.
>
+1000. Thanks for all the great work you've done, even if it means you now
have dents in your forehead from banging it against the wall making grenade
and friends happy. :)
Hope to see you around \o
// jim
would have been happy to fix those as well.
[7] and [8] are just general code maintenance, and aren't really an
argument to me for having the ironic team take over this project.
Besides, as Dmitry notes, he "has to" care about ironic-staging-drivers
anyway, and 3 out of those
// jim
On Mon, Aug 13, 2018 at 9:46 AM, Doug Hellmann
wrote:
> Excerpts from Dmitry Tantsur's message of 2018-08-13 15:35:23 +0200:
> > Hi,
> >
> > The plugins are branchless and should stay so. Let us not dive into this
> madness
> > again please.
>
&g
case you (or others) missed it, infra actually went through and made
all official OpenStack channels +r. They're also set to redirect to
#openstack-unregistered where there's a message about what's going on
, I'm +1 for this, however we need a second
> ironic-core to be willing to review this over the next few days.
>
Happy to help, I'm +2 on the IPA patch. Ironic patch just needs some unit
tests.
// jim
> On Mon, Jul 30, 2018 at 1:55 PM, Michael Turek
> wrote:
> > I
gt;
Great, that's super helpful. Thanks!
Is there someone (Luke?) on the list that can send a correction for this
OSSN to all the lists it needs to go to?
// jim
>
> On Tue, Jul 10, 2018 at 10:41 AM Jim Rollenhagen
> wrote:
>
>> On Tue, Jul 10, 2018 at 4:20 AM, Luke
g disabled.
If the bug is with thin volumes and zero padding, then the workaround seems
quite wrong. :)
I'm not super familiar with Cinder, so could some Cinder folks check this
out and re-issue a more accurate OSSN, please?
// jim
>
> ### Discussion ###
> Using both thin volumes an
nsport-Security" as one shouldn't be
enabling that without ensuring a correct TLS config.
Bonus points in that upstream wouldn't need any changes, and we won't need
to change every project. :)
// jim
__
He might not always have time,
> but I think at the end of the day, we’re all in that same boat.
>
+2!
// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.op
cleanup
>>>
>>
>> This also came up at the Pike PTG in Atlanta:
>>
>> https://etherpad.openstack.org/p/ptg-architecture-workgroup
>>
>> See the "raising the minimum microversion" section. The TODO was Ironic
>> was going to go off and do t
sed by
> the application.
>
This was asked in another thread, see my reply :)
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128797.html
// jim
__
OpenStack Development Mailing List (not for usage q
On Thu, May 10, 2018 at 11:19 AM, Matthew Thode
wrote:
> On 18-05-10 11:09:41, Jim Rollenhagen wrote:
> >
> > Awesome. Can someone submit a patch? It will need to remove the special
> URL
> > building for radosgw linked earlier in the thread, and add a reference to
>
test and get back to you on it.
> >
>
> Confirmed that the option works.
>
Awesome. Can someone submit a patch? It will need to remove the special URL
building for radosgw linked earlier in the thread
w if ironic works with "normal" swift tempurls or only the
> radosgw implementation of the swift api?
>
It works with both, see the link from earlier in the thread:
https://github.com/openstack/ironic/blob/214b694f05d200ac1e2ce6db631546f2831c01f7/ironic/common/glance_service/v2/image_ser
x27;d need to wait for either ceph to fix
> this and support the account part of the url (probably just dropping it)
> or have people fork python-swiftclient to 'fix' it.
>
> I'm not sure what the right answer is...
&g
The
ironic-tempest-plugin project runs tests on multiple stable branches, that
config is here[0]. The parent jobs referred to in that file are here[1].
[0]
https://git.openstack.org/cgit/openstack/ironic-tempest-plugin/tree/zuul.d/stable-jobs.yaml
[1] https://git.openstack.org/cgi
ng an older version)
> option from nova.conf. Any other comments are welcome as well :)
>
At Oath:
AggregateImagePropertiesIsolation
ComputeFilter
CoreFilter
DifferentHostFilter
SameHostFilter
ServerGroupAntiAffinityFilter
ServerGroupAffinityFilter
AvailabilityZoneFilter
AggregateInstanceExtra
first Thursday of every
> month?
>
I'd totally support a monthly bug day! I'm not sure Thursday is the best
day for me but I may be able to make it work.
// jim
__
OpenStack Development Mailing List (not for
gt;
Agree this is something we should do eventually.
For now, rloo came up with a better solution - remove ironic's pycodestyle
pin. We had backported the pin, then fixed and unpinned in master, but
didn't backport the unpin. After backporting the patch to unpin it, we
ually the config drive itself is making by iso by default
> then wrap a zip/base64 format ... thanks
>
We only gzip and base64 to send it to the ironic API. It is decoded and
unzipped before writing it to disk, so it is a pure
On Fri, Apr 20, 2018 at 7:33 AM, Jim Rollenhagen
wrote:
> On Thu, Apr 19, 2018 at 3:21 PM, Doug Hellmann
> wrote:
>>
>>
>> Reading through that log more carefully, I see an early attempt to pin
>> pycodestyle <= 2.3.1 [1], followed later by pycodestyle
e devstack look at the blacklisted packages and skip installing them.
>
Yeah, seems like either would work. With the latter, would devstack edit
these out of test-requirements.txt before installing, I presume? The former
seems less hacky,
-tempest-dsvm-ironic-inspector-queens/5a4a6c9/logs/devstacklog.txt.gz#_2018-04-16_15_47_40_822
[3] https://review.openstack.org/#/c/561358/
// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsu
ironic with the deploy request. On the ironic side, we
unpack it and write it to the end of the boot disk.
https://github.com/openstack/nova/blob/324899c621ee02d877122ba3412712ebb92831f2/nova/virt/ironic/driver.py#L952-L985
// jim
__
On Mon, Apr 2, 2018 at 8:26 AM, Jim Rollenhagen
wrote:
> On Sat, Mar 31, 2018 at 7:24 PM, Matthew Thode
> wrote:
>
>> Here's the current status. I'd like to ask the projects what's keeping
>> them from removing pycrypto in facor of a maintained library.
On Wed, Apr 4, 2018 at 1:18 PM, Jim Rollenhagen
wrote:
> On Wed, Apr 4, 2018 at 8:39 AM, Dan Prince wrote:
>
>> Kind of a support question but figured I'd ask here in case there are
>> suggestions for workarounds for specific machines.
>>
>> Setting up a new r
e enlightening. :)
Also curious what version of ipmitool this is, maybe you're hitting an old
bug.
// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
6
branch that can be released on the previous minor version for the people
that need this on 2.6. Thoughts?
// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-r
s.openstack.org/oslo.config/latest/reference/mutable.html#calling-mutate-config-files
// jim
On Tue, Mar 27, 2018 at 12:20 PM, Michael Johnson
wrote:
> Does anyone know how this will work with services that are using
> cotyledon instead of oslo.service (for eliminating eventlet)?
>
> Michael
tch
> switching them from oslosphinx to openstackdocstheme would serve
> for that and a small change to the readme or another file would do it
> for any that are already using the theme.
>
Thanks Doug, I'll investigate this route more when
;s up to the Ironic
> team how they will want to proceed. Option 3 is the desired ideal solution
> but will take a rewrite of the related Ironic driver unit tests as they
> currently all mock ironicclient
>
We discussed this further in IRC yester
On Mon, Mar 19, 2018 at 3:46 PM, Jeremy Stanley wrote:
> On 2018-03-19 14:57:58 + (+), Jim Rollenhagen wrote:
> [...]
> > What do folks think about a banner at the top of the specs website
> > (or each individual spec) that points this out? I'm happy to do
> >
each
individual spec) that points this out? I'm happy to do the work if we agree
it's a good thing to do. My suggested wording:
"NOTE: specifications are a point-in-time design reference, not up-to-date
feature doc
aid, it should be easy to implement in services that
don't want this dependency, so +1.
// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.o
API services.
It's a super useful thing though, so I'd love to figure out a way we can do
it.
Thoughts?
[0]
http://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIRestrictSignal.html
[1]
http://uwsgi-docs.readthedocs.io/en/latest/Management.html#signals-for-controlling-uwsgi
>
> ...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 we'll
Thank you for all of your good work, Vasyl. Sorry to see you go, but
hopefully you'll still be around IRC and such :)
// jim
On Fri, Feb 23, 2018 at 4:02 AM, Vasyl Saienko
wrote:
> Hey Ironic community!
>
> Unfortunately I don't work on Ironic as much as I used to any more
ar as integrating it with ironic-python-agent, just make your hardware
manager something that can be installed by pip, and add entrypoints similar
to the example[2]. Then, just install it alongside the agent when building
the image, and it will be included.
// jim
[0]
https://github.com/opensta
>>
>
> ++ can we please rename it? I think people (myself included) will expect
> specifically something related to bare metal instances co-existing with
> virtual ones (e.g. scheduling or networking concerns). Which is also a
> great topic, but it does not seem to be present on
e projects? Or perhaps not dedicated days, but
> planned-in-advance meeting time? Or should we wait and schedule it
> ad-hoc if we feel like we need it?
>
There's always plenty to discuss between nova and ironic, but we u
te, FWIW: https://review.openstack.org/#/c/537453/
// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/
Huge +1, I didn't realize this was in docs now. We can finally stop doing
it manually \o/
// jim
On Mon, Jan 22, 2018 at 7:45 AM, John Garbutt wrote:
> Hi,
>
> While I was looking at the traits work, I noticed we still have policy and
> config in tree for ironic and ironic in
Hey friends,
I've been mostly missing for the past six weeks while looking for a new
job, so maybe you've forgotten me already, maybe not. I'm happy to tell you
I've found one that I think is a great opportunity for me. But, I'm sad to
tell you that it's totally outside of the OpenStack community.
On Thu, Mar 30, 2017 at 3:24 PM, Doug Hellmann
wrote:
> Excerpts from Jim Rollenhagen's message of 2017-03-30 15:08:13 -0400:
> > On Thu, Mar 30, 2017 at 2:36 PM, Doug Hellmann
> > wrote:
> >
> > > Excerpts from Sean McGinnis's message of 2017-03-22 10:4
t of the application loop log the error? And if
> it's something that the application is catching and handling, that makes
> it seem like it's not an operator-facing error.
>
That's a good point. Without looking for examples, I s
re that the governance repo is the right place for this, though
I don't have a better suggestion.
* if we do put it here, we should do it per deliverable, as some projects
may have more than one deliverable with an API (e.g. when nova spins
placement out to its own repo).
Thanks for p
We can now call this vote: 4 out of 4 of the active cores, all +1. Welcome
to the team, Thomas!
On Thu, Mar 23, 2017 at 11:28 AM, git harry wrote:
> +1
>
> --
> *From:* Jim Baker
> *Sent:* 21 March 2017 20:41
> *To:* OpenStack Development Maili
omething like:
>
> msg = _('') % {: }
> LOG.error(msg)
> raise Exception(msg)
>
> This results in a translated string going to the log, but I think that's
> OK.
>
+1, let's not overcomplicate this. If folks report it as a problem, we
can always go bac
rther
improve the velocity for our project as a whole as a core reviewer. I hope
others concur with me in this assessment!
- Jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
On Thu, Mar 16, 2017 at 5:17 AM, Thierry Carrez
wrote:
> Jim Rollenhagen wrote:
> > On Wed, Mar 15, 2017 at 8:15 AM, John Garbutt > <mailto:j...@johngarbutt.com>> wrote:
> >> In the absence of tooling, could we replace the meeting with weekly
> >>
ordination by
> > replacing it with better async status coordination / reminder tools,
> > some framework to facilitate ad-hoc discussions, and ramping up activity
> > in IRC channel. If that ends up being successful, we could promote our
> > techniques to
style of the rest. Thanks for your patience as we worked
> on this! Feel free to direct feedback to me; we really want to get this
> right for you.
>
This is fantastic! Thank you for putting up with us, I think it turned o
nic as an
experiment for this. It's an admin-only API, so the API users should be the
same (or in contact with) the folks deploying it, and so it shouldn't be as
surprising. We hope to get some feedback and find out if doing this i
s a bit overkill for this, but I won't deny Ruby's
request.
Ping me when it's up and I'm happy to review it ASAP.
// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
at least
three months. This is described in governance docs:
https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html
// jim
__
OpenStack Development Mailing List (not for usage questions)
Uns
that is
> hard to catch up with.
>
We stopped that meeting because it had turned into a status update. We just
rolled it back up into the usual subteam updates.
I'd like to leave it to the folks working on that to decide if they need a
meeting to keep up with everything.
// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
We've a clear majority here, I took the liberty of adding Mario and Vasyl
while Dmitry is busy running our sessions today. Welcome to the team, y'all
:)
// jim
On Fri, Feb 17, 2017 at 4:40 AM, Dmitry Tantsur wrote:
> Hi all!
>
> I'd like to propose a few cha
;
> Thanks,
> Doug
>
> [1] https://review.openstack.org/#/c/435816/1
I see this is only for milestone-based projects. Should
cycle-with-intermediary
projects like ironic add a diff-start to the most recent release, so the
release
announcement
t really understand what this topic is about. Mind
> providing at TL;DR? Why exactly should we change something around
> nova-compute <-> ironic?
Seems it's more about the architecture working group correctly understanding
everything nova-compute does, before proposing any changes.
r everything Deva, good luck with your current challenges!
>
Sadly agree. Deva, thank you for everything you've done for the project -
from building a nemesis^W^Wnova-baremetal to founding ironic to leading the
project for quite some ti
; > -Kendall Nelson (diablo_rojo)
>
> not realizing there is a space at the beginning of a line, and
> typing a '/' command.
>
> I am constantly typing ' /win 10' into channels, or more embarrassingly
> ' /whois '
>
Even more embarassing whe
On Thu, Feb 9, 2017 at 7:00 AM, Jim Rollenhagen
wrote:
> Hey folks,
>
> Ironic plans to release Ocata this week, once we have a couple small
> patches
> and a release note cleanup landed.
>
> However, our grenade job is now testing master->master, best I can tell.
> T
Yubikey users tend to dump randomness in IRC at times, e.g.:
ccduggvhtnbdlhnnggbudfciuvjvgbdininggijb
// jim
On Wed, Feb 8, 2017 at 3:36 PM, Kendall Nelson
wrote:
> Hello All!
>
> So I am sure we've all seen it: people writing terminal commands into our
> project c
On Thu, Feb 9, 2017 at 7:51 AM, Sean Dague wrote:
> On 02/09/2017 07:00 AM, Jim Rollenhagen wrote:
> > Hey folks,
> >
> > Ironic plans to release Ocata this week, once we have a couple small
> patches
> > and a release note cleanup landed.
> >
> > Howe
me help on navigating this
one.
2) Make our grenade job non-voting for now, release 7.0.0 anyway, and
immediately make sure that the stable/ocata branch runs grenade as expected
and
passes. If it isn't passing, fix what we need to and cut 7.0.
+1 to both recommendations by Sulo.
Let me also add: Harry has proven himself as a strong contributor to Craton
development. I have been especially impressed by how his work has helped
improve the quality and consistency of our coding; often while removing
large chunks of unnecessary code at the s
Hey ironic-ers,
The foundation has passed along a new version of our mascot (attached) to
us, and would like your feedback on it.
They're hoping to have all mascot-related things ready in time for the PTG,
so please do send your thoughts quickly, if you have them. :)
/
aren't rushing, but late enough that we have wiggle room if
something comes up (the real deadline for our final release is R-1).
Of course, we are playing this by ear, and will adjust as needed.
Questions/comments welcome :)
// jim
___
hange
> to avoid using nested KVM altogether. Lower reliability for our jobs is not
> worth a small decrease in job run time.
>
+2, especially this late in the cycle, we need our CI to be rock solid.
// jim
__
OpenSta
Mario.
>
FYI, this is the one I sent in. Thanks for the suggestions.
// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://
me to do so. I hope the following cycles are
even better. :)
// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstac
nyway, here's the planning etherpad:
https://etherpad.openstack.org/p/ironic-pike-ptg
Please add the topics you wish to talk about there *with your name and a
description and/or link*. I've added a bunch of stuff that we have in the
pipeline/backlog to kick it off.
folks can get us the raw answers before
the PTG.
So, Ironicers, what question would you like to ask users, and which group of
users would you like to ask?
// jim
__
OpenStack Development Mailing List (not for usage questions
ecs.openstack.org/openstack/ironic-specs/
> specs/not-implemented/third-party-ci.html
> [1] https://review.openstack.org/#/c/397847
> [2] http://ironic-staging-drivers.readthedocs.io/en/
> latest/README.html#what-the-ironic-staging-drivers-is-not
>
Thanks for sending this, Pavlo. :
as explained to me at the beginning of all this, flavors were going
to have some sort of JSON blob with the requirements, so for an ironic
flavor it would look something like:
{
"name": "baremetal-gold",
"requires: {
"baremetal-gold-reso
on it's a +1
> from
> me! Jay does good work on the ironic stable branches :)
>
> Go Jay!
>
> Yours Tony.
Sounds like consensus. Welcome to the team, Jay \o/
// jim
__
OpenStack Development Mai
On Tue, Nov 22, 2016 at 6:10 AM, Jim Rollenhagen
wrote:
> On Mon, Nov 21, 2016 at 9:03 PM, Tony Breeds wrote:
>> On Wed, Nov 16, 2016 at 02:02:44PM +0100, Dmitry Tantsur wrote:
>>> Hi!
>>>
>>> I'm formally proposing that the ironic-stable-maint
o the
> main Monday ironic meeting, and handle any work via sub team reports.
> Comments?
As a note, this was discussed in this morning's ironic meeting,
nobody was against it. We're waiting for John V's opinion before
cancelling it for real, but everyone's c
agged as
> bad etc. This is done using `plugins` that talk to nova etc. So I think
> some of what you are looking for falls into that perhaps ? This can be
> based on some notification the Craton engine receives from another
> application (like monitoring for example).
>
>
>>
1 - 100 of 460 matches
Mail list logo
