<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 4, 2017 at 9:10 AM, Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(top-posting, as it is not a direct response to a specific line)<br>
<br>
This is your friendly reminder that we're not quite near containerized ironic-inspector. The THT for it has probably never been tested at all, and the iptables magic we do may simply not be containers-compatible. Milan would appreciate any help with his ironic-inspector rework.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div>Thanks Dmitry. Exactly the update I was looking for. Look forward to syncing w/ Milan on this.</div><div><br></div><div>Dan</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Dmitry</font></span><div><div class="h5"><br>
<br>
On 10/04/2017 03:00 PM, Dan Prince wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
On Tue, 2017-10-03 at 16:03 -0600, Alex Schultz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Oct 3, 2017 at 2:46 PM, Dan Prince <<a href="mailto:dprince@redhat.com" target="_blank">dprince@redhat.com</a>><br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Tue, Oct 3, 2017 at 3:50 PM, Alex Schultz <<a href="mailto:aschultz@redhat.com" target="_blank">aschultz@redhat.com</a>><br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Tue, Oct 3, 2017 at 11:12 AM, Dan Prince <<a href="mailto:dprince@redhat.com" target="_blank">dprince@redhat.com</a>><br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 2017-10-02 at 15:20 -0600, Alex Schultz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey Dan,<br>
<br>
Thanks for sending out a note about this. I have a few<br>
questions<br>
inline.<br>
<br>
On Mon, Oct 2, 2017 at 6:02 AM, Dan Prince <<a href="mailto:dprince@redhat.co" target="_blank">dprince@redhat.co</a><br>
m><br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One of the things the TripleO containers team is planning<br>
on<br>
tackling<br>
in Queens is fully containerizing the undercloud. At the<br>
PTG we<br>
created<br>
an etherpad [1] that contains a list of features that need<br>
to be<br>
implemented to fully replace instack-undercloud.<br>
<br>
</blockquote>
<br>
I know we talked about this at the PTG and I was skeptical<br>
that this<br>
will land in Queens. With the exception of the Container's<br>
team<br>
wanting this, I'm not sure there is an actual end user who is<br>
looking<br>
for the feature so I want to make sure we're not just doing<br>
more work<br>
because we as developers think it's a good idea.<br>
</blockquote>
<br>
I've heard from several operators that they were actually<br>
surprised we<br>
implemented containers in the Overcloud first. Validating a new<br>
deployment framework on a single node Undercloud (for<br>
operators) before<br>
overtaking their entire cloud deployment has a lot of merit to<br>
it IMO.<br>
When you share the same deployment architecture across the<br>
overcloud/undercloud it puts us in a better position to decide<br>
where to<br>
expose new features to operators first (when creating the<br>
undercloud or<br>
overcloud for example).<br>
<br>
Also, if you read my email again I've explicitly listed the<br>
"Containers" benefit last. While I think moving the undercloud<br>
to<br>
containers is a great benefit all by itself this is more of a<br>
"framework alignment" in TripleO and gets us out of maintaining<br>
huge<br>
amounts of technical debt. Re-using the same framework for the<br>
undercloud and overcloud has a lot of merit. It effectively<br>
streamlines<br>
the development process for service developers, and 3rd parties<br>
wishing<br>
to integrate some of their components on a single node. Why be<br>
forced<br>
to create a multi-node dev environment if you don't have to<br>
(aren't<br>
using HA for example).<br>
<br>
Lets be honest. While instack-undercloud helped solve the old<br>
"seed" VM<br>
issue it was outdated the day it landed upstream. The entire<br>
premise of<br>
the tool is that it uses old style "elements" to create the<br>
undercloud<br>
and we moved away from those as the primary means driving the<br>
creation<br>
of the Overcloud years ago at this point. The new<br>
'undercloud_deploy'<br>
installer gets us back to our roots by once again sharing the<br>
same<br>
architecture to create the over and underclouds. A demo from<br>
long ago<br>
expands on this idea a bit:  <a href="https://www.youtube.com/watch?v=y1" rel="noreferrer" target="_blank">https://www.youtube.com/watch?<wbr>v=y1</a><br>
qMDLAf26<br>
Q&t=5s<br>
<br>
In short, we aren't just doing more work because developers<br>
think it is<br>
a good idea. This has potential to be one of the most useful<br>
architectural changes in TripleO that we've made in years.<br>
Could<br>
significantly decrease our CI reasources if we use it to<br>
replace the<br>
existing scenarios jobs which take multiple VMs per job. Is a<br>
building<br>
block we could use for other features like and HA undercloud.<br>
And yes,<br>
it does also have a huge impact on developer velocity in that<br>
many of<br>
us already prefer to use the tool as a means of streamlining<br>
our<br>
dev/test cycles to minutes instead of hours. Why spend hours<br>
running<br>
quickstart Ansible scripts when in many cases you can just<br>
doit.sh. htt<br>
ps://<a href="http://github.com/dprince/undercloud_containers/blob/master/doit" rel="noreferrer" target="_blank">github.com/dprince/underc<wbr>loud_containers/blob/master/<wbr>doit</a>.<br>
sh<br>
<br>
</blockquote>
<br>
So like I've repeatedly said, I'm not completely against it as I<br>
agree<br>
what we have is not ideal.  I'm not -2, I'm -1 pending additional<br>
information. I'm trying to be realistic and reduce our risk for<br>
this<br>
cycle.<br>
</blockquote>
<br>
<br>
This reduces our complexity greatly I think in that once it is<br>
completed<br>
will allow us to eliminate two project (instack and instack-<br>
undercloud) and<br>
the maintenance thereof. Furthermore, as this dovetails nice with<br>
the<br>
Ansible<br>
<br>
</blockquote>
<br>
I agree. So I think there's some misconceptions here about my<br>
thoughts<br>
on this effort. I am not against this effort. I am for this effort<br>
and<br>
wish to see more of it. I want to see the effort communicated<br>
publicly<br>
via ML and IRC meetings.  What I am against switching the default<br>
undercloud method until the containerization of the undercloud has<br>
the<br>
appropriate test coverage and documentation to ensure it is on par<br>
with what it is replacing.  Does this make sense?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  IMHO doit.sh is not acceptable as an undercloud installer and<br>
this is what I've been trying to point out as the actual impact<br>
to the<br>
end user who has to use this thing.<br>
</blockquote>
<br>
<br>
doit.sh is an example of where the effort is today. It is<br>
essentially the<br>
same stuff we document online here:<br>
<a href="http://tripleo.org/install/containers_deployment/undercloud.html" rel="noreferrer" target="_blank">http://tripleo.org/install/con<wbr>tainers_deployment/undercloud.<wbr>html</a>.<br>
<br>
Similar to quickstart it is just something meant to help you setup<br>
a dev<br>
environment.<br>
<br>
</blockquote>
<br>
Right, providing something that the non-developer uses vs providing<br>
something for hacking are two separate things. Making it consumable<br>
by<br>
the end user (not developer) is what I'm pointing out that needs to<br>
be<br>
accounted for.  This is a recurring theme that I have pushed for in<br>
OpenStack to ensure that the operator (actual end user) is accounted<br>
for when making decisions.  Tripleo has not done a good job of this<br>
either.  Sure the referenced documentation works for the dev case,<br>
but<br>
probably not the actual deployer/operator case.<br>
</blockquote>
<br>
This will come in time. What I would encourage us to do upstream is<br>
make as much progress on this in Queens as possible so that getting to<br>
the point of polishing our documentation is the focus... instead of the<br>
remaining work.<br>
<br>
And to be clear all of this work advocates for the Operator just as<br>
much as it does for the developer. No regressions, improved Ansible<br>
feedback on the CLI, potential for future features around multitude and<br>
  alignment of the architecture around containers. Boom! I think<br>
operators will like all of this. We can and will document it.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   There needs to be a<br>
migration guide or documentation of old configuration -> new<br>
configuration for the people who are familiar with non-containerized<br>
undercloud vs containerized undercloud.  Do we have all the use cases<br>
accounted for etc. etc. This is the part that I don't think we have<br>
figured out and which is what I'm asking that we make sure we account<br>
for with this.<br>
</blockquote>
<br>
The use case is the replace instack-undercloud with no feature<br>
regressions.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We have an established<br>
installation method for the undercloud, that while isn't great,<br>
isn't<br>
a bash script with git fetches, etc.  So as for the<br>
implementation,<br>
this is what I want to see properly flushed out prior to<br>
accepting<br>
this feature as complete for Queens (and the new default).<br>
</blockquote>
<br>
<br>
Of course the feature would need to prove itself before it becomes<br>
the new<br>
default Undercloud. I'm trying to build consensus and get the team<br>
focused<br>
on these things.<br>
<br>
What strikes me as odd is your earlier comment about " I want to<br>
make sure<br>
we're not just doing more work because we as developers think it's<br>
a good<br>
idea." I'm a developer and I do think this is a good idea. Please<br>
don't try<br>
to de-motivate this effort just because you happen to believe this.<br>
It was<br>
accepted for Pike and unfortunately we didn't get enough buy in<br>
early enough<br>
to get focus on it. Now that is starting to change and just as it<br>
is you are<br>
suggesting we not keep it a priority?<br>
<br>
</blockquote>
<br>
Once again, I agree and I am on board to the end goal that I think is<br>
trying to be achieved by this effort. What I am currently not on<br>
board<br>
with is the time frame of for Queens based on concerns previously<br>
mentioned.  This is not about trying to demotivating an effort. It's<br>
about ensuring quality and something that is consumable by an<br>
additional set of end users of the software (the operator/deployer,<br>
not developer).  Given that we have not finished the overcloud<br>
deployment and are still working on fixing items found for that, I<br>
personally feel it's a bit early to consider switching the undercloud<br>
default install to a containerized method.  That being said, I have<br>
repeatedly stated that if we account for updates, upgrades, docs and<br>
the operator UX there's no problems with this effort. I just don't<br>
think it's realistic given current timelines (~9 weeks).<br>
  Please feel<br>
free to provide information/patches to the contrary.<br>
</blockquote>
<br>
Whether this feature makes the release or not I think it is too early<br>
to say. What I can say is the amount of work remaining on the<br>
Undercloud feature is IMO a good bit less than we knocked out in the<br>
last release:<br>
<br>
<a href="https://etherpad.openstack.org/p/tripleo-composable-containers-underclo" rel="noreferrer" target="_blank">https://etherpad.openstack.org<wbr>/p/tripleo-composable-containe<wbr>rs-underclo</a><br>
ud<br>
<br>
And regardless of whether we make the release or not there is a huge<br>
value to moving the work forward now... if only to put us in a better<br>
position for the next release.<br>
<br>
I've been on the containers team for a while now and I'm more familiar<br>
with the velocity that we could handle. Let us motivate ourselves and<br>
give updates along the way over the next 2 months as this effort<br>
progresses. Please don't throw "cold water" on why you don't think we<br>
are going to make the release (especially as PTL, this can be quite<br>
harmful to the effort for some). In fact, lets just stop talking about<br>
Queens, and Rocky entirely. I think we can agree that this feature is a<br>
high priority and have people move the effort forward as much as we<br>
can.<br>
<br>
This *is* a very important feature. It can be fun to work on. Let those<br>
of us who are doing the work finish scoping it and at least have a<br>
chance at making progress before you throw weight against us not making<br>
the release months from now.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  I have not said<br>
don't work on it.  I just want to make sure we have all the pieces in<br>
place needed to consider it a proper replacement for the existing<br>
undercloud installation (by M2).  If anything there's probably more<br>
work that needs to be done and if we want to make it a priority to<br>
happen, then it needs to be documented and communicated so folks can<br>
assist as they have cycles.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I would<br>
like to see a plan of what features need to be added (eg. the<br>
stuff on<br>
the etherpad), folks assigned to do this work, and estimated<br>
timelines.  Given that we shouldn't be making major feature<br>
changes<br>
after M2 (~9 weeks), I want to get an understanding of what is<br>
realistically going to make it.  If after reviewing the initial<br>
details we find that it's not actually going to make M2, then<br>
let's<br>
agree to this now rather than trying to force it in at the end.<br>
</blockquote>
<br>
<br>
All of this is forthcoming. Those details will come in time.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
I know you've been a great proponent of the containerized<br>
undercloud<br>
and I agree it offers a lot more for development efforts. But I<br>
just<br>
want to make sure that we are getting all the feedback we can<br>
before<br>
continuing down this path.  Since, as you point out, a bunch of<br>
this<br>
work is already available for consumption by developers, I don't<br>
see<br>
making it the new default as a requirement for Queens unless it's<br>
a<br>
fully implemented and tested.  There's nothing stopping folks<br>
from<br>
using it now and making incremental improvements during Queens<br>
and we<br>
commit to making it the new default for Rocky.<br>
<br>
The point of this cycle was supposed to be more<br>
stablization/getting<br>
all the containers in place. Doing something like this seems to<br>
go<br>
against what we were actually trying to achieve.  I'd rather make<br>
smaller incremental progress with your proposal being the end<br>
goal and<br>
agreeing that perhaps Rocky is more realistic for the default cut<br>
over.<br>
</blockquote>
<br>
<br>
I thought the point of this release was full containerization? And<br>
part of<br>
that is containerizing the undercloud too right?<br>
<br>
</blockquote>
<br>
Not that I was aware of. Others have asked because they have not been<br>
aware that it included the undercloud.  Given that we are wanting to<br>
eventually look to kubernetes maybe we don't need to containerize the<br>
undercloud as it may be it could be discarded with that switch.<br>
</blockquote>
<br>
I don't think so. The whole point of the initial Undercloud work was<br>
that it aligns the architectures. Using Kubernetes to maintain an<br>
Undercloud would also be a valid approach I think. Perhaps a bit<br>
overkill but it would be a super useful dev environment tool to develop<br>
  Kubernetes services on regardless.<br>
<br>
And again, there are no plans to containerize instack-undercloud<br>
components as is. I think we have agreement that using containers in<br>
the Undercloud is a high priority and we need to move this effort<br>
forwards.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's probably a longer discussion. It might need to be researched<br>
which is why it's important to understand why we're doing the<br>
containerization effort and what exactly it entails.  Given that I<br>
don't think we're looking to deploy kubernetes via<br>
THT/tripleo-puppet/containers, I wonder what impact this would have<br>
with this effort?  That's probably a conversation for another thread.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lastly, this isn't just a containers team thing. We've been<br>
using the<br>
undercloud_deploy architecture across many teams to help<br>
develop for<br>
almost an entire cycle now. Huge benefits. I would go as far as<br>
saying<br>
that undercloud_deploy was *the* biggest feature in Pike that<br>
enabled<br>
us to bang out a majority of the docker/service templates in<br>
tripleo-<br>
heat-templates.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  Given that etherpad<br>
appears to contain a pretty big list of features, are we<br>
going to be<br>
able to land all of them by M2?  Would it be beneficial to<br>
craft a<br>
basic spec related to this to ensure we are not missing<br>
additional<br>
things?<br>
</blockquote>
<br>
I'm not sure there is a lot of value in creating a spec at this<br>
point.<br>
We've already got an approved blueprint for the feature in Pike<br>
here: h<br>
ttps://<a href="http://blueprints.launchpad.net/tripleo/+spec/containerized-" rel="noreferrer" target="_blank">blueprints.launchpad.ne<wbr>t/tripleo/+spec/containerized-</a><br>
undercloud<br>
<br>
I think we might get more velocity out of grooming the etherpad<br>
and<br>
perhaps dividing this work among the appropriate teams.<br>
<br>
</blockquote>
<br>
That's fine, but I would like to see additional efforts made to<br>
organize this work, assign folks and add proper timelines.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Benefits of this work:<br>
<br>
  -Alignment: aligning the undercloud and overcloud<br>
installers gets<br>
rid<br>
of dual maintenance of services.<br>
<br>
</blockquote>
<br>
I like reusing existing stuff. +1<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  -Composability: tripleo-heat-templates and our new Ansible<br>
architecture around it are composable. This means any set<br>
of<br>
services<br>
can be used to build up your own undercloud. In other words<br>
the<br>
framework here isn't just useful for "underclouds". It is<br>
really<br>
the<br>
ability to deploy Tripleo on a single node with no external<br>
dependencies. Single node TripleO installer. The containers<br>
team<br>
has<br>
already been leveraging existing (experimental)<br>
undercloud_deploy<br>
installer to develop services for Pike.<br>
<br>
</blockquote>
<br>
Is this something that is actually being asked for or is this<br>
just an<br>
added bonus because it allows developers to reduce what is<br>
actually<br>
being deployed for testing?<br>
</blockquote>
<br>
There is an implied ask for this feature when a new developer<br>
starts to<br>
use TripleO. Right now resource bar is quite high for TripleO.<br>
You have<br>
to have a multi-node development environment at the very least<br>
(one<br>
undercloud node, and one overcloud node). The ideas we are<br>
talking<br>
about here short circuits this in many cases... where if you<br>
aren't<br>
testing HA services or Ironic you could simple use<br>
undercloud_deploy to<br>
test tripleo-heat-template changes on a single VM. Less<br>
resources, and<br>
much less time spent learning and waiting.<br>
<br>
</blockquote>
<br>
IMHO I don't think the undercloud install is the limiting factor<br>
for<br>
new developers and I'm not sure this is actually reducing that<br>
complexity.  It does reduce the amount of hardware needed to<br>
develop<br>
some items, but there's a cost in complexity by moving the<br>
configuration to THT which is already where many people<br>
struggle.  As<br>
I previously mentioned, there's nothing stopping us from<br>
promoting the<br>
containerized undercloud as a development tool and ensuring it's<br>
full<br>
featured before switching to it as the default at a later date.<br>
</blockquote>
<br>
<br>
Because the new undercloud_deploy installer uses t-h-t we get<br>
containers for<br>
free. Additionally as we convert over to Ansible instead of Heat<br>
software<br>
deployments we also get better operator feedback there as well.<br>
Woudn't it<br>
be nice to have an Undercloud installer driven by Ansible instead<br>
of Python<br>
and tripleo-image-elements?<br>
</blockquote>
<br>
Yup, and once again I recognize this as a benefit.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The reason I linked in doit.sh above (and if you actually go and<br>
look at the<br>
recent patches) we are already wiring these things up right now<br>
(before M1!)<br>
and it looks really nice. As we eventually move away from Puppet<br>
for<br>
configuration that too goes away. So I think the idea here is a<br>
net-reduction in complexity because we no longer have to maintain<br>
instack-undercloud, puppet modules, and elements.<br>
<br>
It isn't that the undercloud install is a limiting factor. It is<br>
that the<br>
set of services making up your "Undercloud" can be anything you<br>
want because<br>
t-h-t supports all of our services. Anything you want with minimal<br>
t-h-t,<br>
Ansible, and containers. This means you can effectively develop on<br>
a single<br>
node for many cases and it will just work in a multi-node Overcloud<br>
setup<br>
too because we have the same architecture.<br>
<br>
</blockquote>
<br>
My concern is making sure we aren't moving too fast and introducing<br>
more regressions/bugs/missing use cases/etc. My hope is by<br>
documenting<br>
all of this, ensuring we have proper expectations around a definition<br>
of done (and time frames), and allowing for additional review, we<br>
will<br>
reduce the risk introduced by this switch.  These types of things<br>
align with what we talked about at the PTG in during the retro[0]<br>
(see: start define definition of done,  start status reporting on ML,<br>
stop over committing, stop big change without tests, less complexity,<br>
etc, etc).  This stuff's complicated, let's make sure we do it right.<br>
<br>
Thanks,<br>
-Alex<br>
<br>
[0] <a href="http://people.redhat.com/aschultz/denver-ptg/tripleo-ptg-retro.jp" rel="noreferrer" target="_blank">http://people.redhat.com/aschu<wbr>ltz/denver-ptg/tripleo-ptg-<wbr>retro.jp</a><br>
g<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dan<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  -Development: The containerized undercloud is a great<br>
development<br>
tool. It utilizes the same framework as the full overcloud<br>
deployment<br>
but takes about 20 minutes to deploy.  This means faster<br>
iterations,<br>
less waiting, and more testing.  Having this be a first<br>
class<br>
citizen<br>
in the ecosystem will ensure this platform is functioning<br>
for<br>
developers to use all the time.<br>
<br>
</blockquote>
<br>
Seems to go with the previous question about the re-usability<br>
for<br>
people who are not developers.  Has everyone (including non-<br>
container<br>
folks) tried this out and attest that it's a better workflow<br>
for<br>
them?<br>
  Are there use cases that are made worse by switching?<br>
</blockquote>
<br>
I would let other chime in but the feedback I've gotten has<br>
mostly been<br>
  that it improves the dev/test cycle greatly.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  -CI resources: better use of CI resources. At the PTG we<br>
received<br>
feedback from the OpenStack infrastructure team that our<br>
upstream<br>
CI<br>
resource usage is quite high at times (even as high as 50%<br>
of the<br>
total). Because of the shared framework and single node<br>
capabilities we<br>
can re-architecture much of our upstream CI matrix around<br>
single<br>
node.<br>
We no longer require multinode jobs to be able to test many<br>
of the<br>
services in tripleo-heat-templates... we can just use a<br>
single<br>
cloud VM<br>
instead. We'll still want multinode undercloud -> overcloud<br>
jobs<br>
for<br>
testing things like HA and baremetal provisioning. But we<br>
can cover<br>
a<br>
large set of the services (in particular many of the new<br>
scenario<br>
jobs<br>
we added in Pike) with single node CI test runs in much<br>
less time.<br>
<br>
</blockquote>
<br>
I like this idea but would like to see more details around<br>
this.<br>
Since this is a new feature we need to make sure that we are<br>
properly<br>
covering the containerized undercloud with CI as well.  I<br>
think we<br>
need 3 jobs to properly cover this feature before marking it<br>
done. I<br>
added them to the etherpad but I think we need to ensure the<br>
following<br>
3 jobs are defined and voting by M2 to consider actually<br>
switching<br>
from the current instack-undercloud installation to the<br>
containerized<br>
version.<br>
<br>
1) undercloud-containers - a containerized install, should be<br>
voting<br>
by m1<br>
2) undercloud-containers-update - minor updates run on<br>
containerized<br>
underclouds, should be voting by m2<br>
3) undercloud-containers-upgrade - major upgrade from<br>
non-containerized to containerized undercloud, should be<br>
voting by<br>
m2.<br>
<br>
If we have these jobs, is there anything we can drop or mark<br>
as<br>
covered that is currently being covered by an overcloud job?<br>
<br>
</blockquote></blockquote>
<br>
Can you please comment on these expectations as being<br>
achievable?  If<br>
they are not achievable, I don't think we can agree to switch the<br>
default for Queens.  As we shipped the 'undercloud deploy' as<br>
experimental for Pike, it's well within reason to continue to do<br>
so<br>
for Queens. Perhaps we change the labeling to beta or working it<br>
into<br>
a --containerized option for 'undercloud install'.<br>
<br>
I think my ask for the undercloud-containers job as non-voting by<br>
m1<br>
is achievable today because it's currently green (pending any<br>
zuul<br>
freezes). My concern is really minor updates and upgrades need to<br>
be<br>
understood and accounted for ASAP.  If we're truly able to reuse<br>
some<br>
of the work we did for O->P upgrades, then these should be fairly<br>
straight forward things to accomplish and there would be fewer<br>
blockers to make the switch.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  -Containers: There are no plans to containerize the<br>
existing<br>
instack-<br>
undercloud work. By moving our undercloud installer to a<br>
tripleo-<br>
heat-<br>
templates and Ansible architecture we can leverage<br>
containers.<br>
Interestingly, the same installer also supports baremetal<br>
(package)<br>
installation as well at this point. Like to overcloud<br>
however I<br>
think<br>
making containers our undercloud default would better align<br>
the<br>
TripleO<br>
tooling.<br>
<br>
We are actively working through a few issues with the<br>
deployment<br>
framework Ansible effort to fully integrate that into the<br>
undercloud<br>
installer. We are also reaching out to other teams like the<br>
UI and<br>
Security folks to coordinate the efforts around those<br>
components.<br>
If<br>
there are any questions about the effort or you'd like to<br>
be<br>
involved<br>
in the implementation let us know. Stay tuned for more<br>
specific<br>
updates<br>
as we organize to get as much of this in M1 and M2 as<br>
possible.<br>
<br>
</blockquote>
<br>
I would like to see weekly updates on this effort during the<br>
IRC<br>
meeting. As previously mentioned around squad status, I'll be<br>
asking<br>
for them during the meeting so it would be nice to get an<br>
update this<br>
on a weekly basis so we can make sure that we'll be OK to cut<br>
over.<br>
<br>
Also what does the cut over plan look like?  This is<br>
something that<br>
might be beneficial to have in a spec. IMHO, I'm ok to<br>
continue<br>
pushing the container effort using the openstack undercloud<br>
deploy<br>
method for now. Once we have voting CI jobs and the feature<br>
list has<br>
been covered then we can evaluate if we've made the M2 time<br>
frame to<br>
switching openstack undercloud deploy to be the new<br>
undercloud<br>
install.  I want to make sure we don't introduce regressions<br>
and are<br>
doing thing in a user friendly fashion since the undercloud<br>
is the<br>
first intro an end user gets to tripleo. It would be a good<br>
idea to<br>
review what the new install process looks like and make sure<br>
it "just<br>
works" given that the current process[0] (with all it's<br>
flaws) is<br>
fairly trivial to perform.<br>
<br>
</blockquote></blockquote>
<br>
Basically what I would like to see before making this new default<br>
is:<br>
1) minor updates work (with CI)<br>
2) P->Q upgrades work (with CI)<br>
3) Documentation complete<br>
4) no UX impact for installation (eg. how they installed it<br>
before is<br>
the same as they install it now for containers)<br>
<br>
If these are accounted for and completed before M2 then I would<br>
be +2<br>
on the switch.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
-Alex<br>
<br>
[0] <a href="https://docs.openstack.org/tripleo-docs/latest/install/in" rel="noreferrer" target="_blank">https://docs.openstack.org/tri<wbr>pleo-docs/latest/install/in</a><br>
stallati<br>
on/installation.html#installin<wbr>g-the-undercloud<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On behalf of the containers team,<br>
<br>
Dan<br>
<br>
[1] <a href="https://etherpad.openstack.org/p/tripleo-queens-undercl" rel="noreferrer" target="_blank">https://etherpad.openstack.org<wbr>/p/tripleo-queens-undercl</a><br>
oud-cont<br>
aine<br>
rs<br>
<br>
______________________________<wbr>_____________________________<br>
________<br>
_______<br>
OpenStack Development Mailing List (not for usage<br>
questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subj" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subj</a><br>
ect:unsu<br>
bscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/opensta" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/opensta</a><br>
ck-dev<br>
</blockquote>
<br>
______________________________<wbr>______________________________<wbr>_<br>
________<br>
_____<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subjec" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subjec</a><br>
t:unsubs<br>
cribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k</a><br>
-dev<br>
</blockquote>
<br>
<br>
______________________________<wbr>______________________________<wbr>___<br>
___________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<br>
<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-d" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-d</a><br>
ev<br>
</blockquote>
<br>
______________________________<wbr>______________________________<wbr>_____<br>
_________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:un" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:un</a><br>
subscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>_______<br>
_______<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsu" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsu</a><br>
bscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote>
<br>
______________________________<wbr>______________________________<wbr>_________<br>
_____<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubs" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubs</a><br>
cribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote>
<br></div></div>
______________________________<wbr>______________________________<wbr>______________<span class=""><br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</span></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>