<div dir="ltr">Hi,<br><div class="gmail_extra">
<br><div class="gmail_quote">On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn <span dir="ltr"><<a href="mailto:mmosesohn@mirantis.com" target="_blank">mmosesohn@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Vladimir,<br><br></div>The old site.pp is long out of date and should just be recreated from the content of all the other $service-only.pp files.<br><br></div>My main question is how do we propose to do a rollback from an update (in theory, from 8.0 to 9.0, then back to 8.0)? Should we hardcode persistent data directories (or symlink them?) to /var/lib/fuel/$fuel_version/$service_name, as we are doing behind the scenes currently with Docker? If we keep that mechanism in place, all the existing puppet modules can be used without any modifications. On the same note, upgrade/rollback is the same as backup and restore, that means our restore should follow a similar approach.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888">-Matthew<br></font></span></div></blockquote><div><br></div><div>There only one idea I have is to do dual partitioning system. The similar approach is implemented in CoreOS.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="HOEnZb"><font color="#888888"></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Nov 19, 2015 at 6:36 PM, Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>></span> wrote:<br></span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 19.11.2015 15:59, Vladimir Kozhukalov wrote:<br>
> Dear colleagues,<br>
><br>
> As might remember, we introduced Docker containers on the master node a<br>
> while ago when we implemented first version of Fuel upgrade feature. The<br>
> motivation behind was to make it possible to rollback upgrade process if<br>
> something goes wrong.<br>
><br>
> Now we are at the point where we can not use our tarball based upgrade<br>
> approach any more and those patches that deprecate upgrade tarball has<br>
> been already merged. Although it is a matter of a separate discussion,<br>
> it seems that upgrade process rather should be based on kind of backup<br>
> and restore procedure. We can backup Fuel data on an external media,<br>
> then we can install new version of Fuel from scratch and then it is<br>
> assumed backed up Fuel data can be applied over this new Fuel instance.<br>
<br>
</span>A side-by-side upgrade, correct? That should work as well.<br>
<span><br>
> The procedure itself is under active development, but it is clear that<br>
> rollback in this case would be nothing more than just restoring from the<br>
> previously backed up data.<br>
><br>
> As for Docker containers, still there are potential advantages of using<br>
> them on the Fuel master node, but our current implementation of the<br>
> feature seems not mature enough to make us benefit from the<br>
> containerization.<br>
><br>
> At the same time there are some disadvantages like<br>
><br>
</span>>   * it is tricky to get logs and other information (for example, rpm<br>
<span>>     -qa) for a service like shotgun which is run inside one of containers.<br>
</span>>   * it is specific UX when you first need to run dockerctl shell<br>
<span>>     {container_name} and then you are able to debug something.<br>
</span>>   * when building IBP image we mount directory from the host file system<br>
<span>>     into mcollective container to make image build faster.<br>
</span>>   * there are config files and some other files which should be shared<br>
<span>>     among containers which introduces unnecessary complexity to the<br>
>     whole system.<br>
</span>>   * our current delivery approach assumes we wrap into rpm/deb packages<br>
<span>>     every single piece of the Fuel system. Docker images are not an<br>
>     exception. And as far as they depend on other rpm packages we forced<br>
>     to build docker-images rpm package using kind of specific build<br>
>     flow. Besides this package is quite big (300M).<br>
</span>>   * I'd like it to be possible to install Fuel not from ISO but from RPM<br>
<span>>     repo on any rpm based distribution. But it is double work to support<br>
>     both Docker based and package based approach.<br>
<br>
</span>There is another point, the containers long build time when installing<br>
the master node.<br>
<span><br>
><br>
> Probably some of you can give other examples. Anyway, the idea is to get<br>
> rid of Docker containers on the master node and switch to plane package<br>
> based approach that we used before.<br>
><br>
> As far as there is nothing new here, we just need to use our old site.pp<br>
> (with minimal modifications), it looks like it is possible to implement<br>
> this during 8.0 release cycle. If there are no principal objections,<br>
> please give me a chance to do this ASAP (during 8.0), I know it is a<br>
> huge risk for the release, but still I think I can do this.<br>
><br>
><br>
><br>
><br>
> Vladimir Kozhukalov<br>
><br>
><br>
</span>> __________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<span><font color="#888888"><br>
<br>
--<br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div></div></div><br></div>
<br>__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>