Excerpts from Dmitry Tantsur's message of 2017-02-18 18:54:59 +0100:
> 2017-02-17 19:16 GMT+01:00 Clint Byrum <cl...@fewbar.com>:
> 
> > Hello, I'm looking forward to seeing many of you next week in Atlanta.
> > We're going to be working on Arch-WG topics all day Tuesday, and if
> > you'd like to join us for that in general, please add your topic here:
> >
> > https://etherpad.openstack.org/p/ptg-architecture-workgroup
> >
> > I specifically want to call out an important discussion session for one
> > of our active work streams, nova-compute-api:
> >
> > https://review.openstack.org/411527
> > https://review.openstack.org/435555
> >
> > At this point, we've gotten a ton of information from various
> > contributors, and I want to thank everyone who commented on 411527 with
> > helpful data. I'll be compiling the data we have into some bullet points
> > which I intend to share on the projector in an etherpad[1], and then invite
> > the room to ensure the accuracy and completeness of what we have there.
> > I grabbed two 30-minute slots in Macon for Tuesday to do this, and I'd
> > like to invite anyone who has thoughts on how nova-compute interacts to
> > join us and participate. If you will not be able to attend, please read
> > the documents and comments in the reviews above and fill in any information
> > you think is missing on the etherpad[1] so we can address it there.
> >
> > [1] https://etherpad.openstack.org/p/arch-wg-nova-compute-api-ptg-pike
> 
> 
> https://ethercalc.openstack.org/Pike-PTG-Discussion-Rooms says you're in
> South Capital, not Macon. Who is right? :)
> 

OOOOOPS, you're right. Yes, please come to South Capital, not Macon. :)

> I can attend, but I don't really understand what this topic is about. Mind
> providing at TL;DR? Why exactly should we change something around
> nova-compute <-> ironic?
> 

It's ok, if you don't have time to read the referenced documents, I'll
try to summarize:

nova-compute is communicated with through a variety of poorly documented
or poorly encapsulated APIs. os-brick and os-vif do odd things with lock
files (I think!), ceilometer inspects files on disk and system level
monitors.

The idea is to define the entry points into nova-compute and more
clearly draw a line where nova-compute's responsibility begins and other
services authority ends. This is already well defined between
nova-compute and nova-conductor, but not so much with others.

My reason for wanting this is simplification of the interactions with the
compute node so OpenStack can be enhanced and debugged without reading
the code of nova-compute.

For Ironic, I believe there may be ways in which nova-compute imposes
a bit of an odd structure on the baremetal service, and I'm interested
in hearing Ironic developers' opinions on that. I may be totally off
base.

> >
> >
> > Once we have this data, I'll likely spend a small amount of time grabbing
> > people from
> > each relevant project team on Wednesday/Thursday to get a deeper
> > understanding of some
> > of the pieces that we talk about on Tuesday.
> >
> > From that, as a group we'll produce a detailed analysis of all the ways
> > nova-compute is interacted with today, and ongoing efforts to change
> > them. If you are interested in this please do raise your hand and come
> > to our meetings[2] as my time to work on this is limited, and the idea
> > for the Arch-WG isn't "Arch-WG solves OpenStack" but "Arch-WG provides
> > a structure by which teams can raise understanding of architecture."
> >
> > [2] https://wiki.openstack.org/wiki/Meetings/Arch-WG
> >
> > Once we've produced that analysis, which we intend to land as a document
> > in our arch-wg repository, we'll produce a set of specs in the appropriate
> > places (likely openstack-specs) for how to get it to where we want to
> > go.
> >
> > Also, speaking of the meeting -- Since we'll all be meeting on Tuesday
> > at the PTG, the meeting for next week is cancelled.
> >
> > __________________________________________________________________________
> > 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
> >
> 

__________________________________________________________________________
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

Reply via email to