<font size=2 face="sans-serif">Dear All,</font>
<br>
<br><font size=2 face="sans-serif">Requesting your help on following issue:</font>
<br>
<br><font size=2 face="sans-serif">I am trying to deploy Multi Node OpenStack
(Liberty) env and following exact instructions given at following link:</font>
<br><a href="http://docs.openstack.org/liberty/install-guide-ubuntu/"><font size=2 color=blue face="sans-serif">http://docs.openstack.org/liberty/install-guide-ubuntu/</font></a>
<br>
<br><font size=2 face="sans-serif">After Keystone configuration, while
trying to verify its operation and generating token, facing following error:</font>
<br><font size=2 face="sans-serif"><b>Command:</b></font>
<br><font size=2 color=#0000e0 face="sans-serif">openstack --os-auth-url
</font><a href=http://controller:35357/v3><font size=2 color=#0000e0 face="sans-serif">http://controller:35357/v3</font></a><font size=2 color=#0000e0 face="sans-serif">
--os-project-domain-id default --os-user-domain-id default --os-project-name
admin --os-username admin --os-auth-type password token issue</font>
<br>
<br><font size=2 face="sans-serif"><b>Error:</b></font>
<br><font size=2 color=#c20041 face="sans-serif">An unexpected error prevented
the server from fulfilling your request. (HTTP 500) (Request-ID: req-c89801db-f8de-457b-8fc5-df0d3c72d44e)</font>
<br>
<br><font size=2 face="sans-serif"><b>Keystone log</b> (/var/log/apache2/keystone.log)
shows following:</font>
<br><font size=1 face="sans-serif">2016-02-12 11:50:48.044811 2016-02-12
11:50:48.0442808 INFO keystone.common.wsgi [req-c89801db-f8de-457b-8fc5-df0d3c72d44e
- - - - -] POST </font><a href=http://controller:5000/v3/auth/tokens><font size=1 face="sans-serif">http://controller:5000/v3/auth/tokens</font></a>
<br><font size=1 face="sans-serif">2016-02-12 11:50:48.363340 2016-02-12
11:50:48.362 2808 INFO keystone.common.kvs.core [req-c89801db-f8de-457b-8fc5-df0d3c72d44e
- - - - -] Using default dogpile sha1_mangle_key as KVS region token-driver
key_mangler</font>
<br><font size=1 face="sans-serif">2016-02-12 11:50:55.692962 2016-02-12
11:50:55.692 2808 WARNING keystone.common.wsgi [req-c89801db-f8de-457b-8fc5-df0d3c72d44e
- - - - -] An unexpected error prevented the server from fulfilling your
request. </font><font size=2 face="sans-serif">
</font>
<br>
<br><font size=2 face="sans-serif">Best Regards<br>
Ankit Agrawal<br>
<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">openstack-dev-request@lists.openstack.org</font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">openstack-dev@lists.openstack.org</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">02/12/2016 04:48 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">OpenStack-dev
Digest, Vol 46, Issue 32</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Send OpenStack-dev mailing list submissions to<br>
openstack-dev@lists.openstack.org<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
or, via email, send a message with subject or body 'help' to<br>
openstack-dev-request@lists.openstack.org<br>
<br>
You can reach the person managing the list at<br>
openstack-dev-owner@lists.openstack.org<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenStack-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: [all] [tc] "No Open Core" in 2016 (Flavio Percoco)<br>
2. Re: [Fuel][QA] What is the preferred way to bootstrap a<br>
baremetal node with Fuel on product CI? (Dennis Dmitriev)<br>
3. Re: [qa] deprecating Tempest stress framework (Daniel Mellado)<br>
4. Re: [Fuel] URL of Horizon is hard to find on the
dashboard<br>
(Igor Kalnitsky)<br>
5. [ironic] More midcycle details (Jim Rollenhagen)<br>
6. Glance Image signing and verification (Pankaj Mishra)<br>
7. Re: Glance Image signing and verification (Nikhil Komawar)<br>
8. Re: [infra] [trove] gate jobs failing with ovh apt mirrors<br>
(Jeremy Stanley)<br>
9. Re: [neutron] [ipam] Migration to pluggable IPAM (John Belamaric)<br>
10. Re: [OpenStack-Infra] Gerrit downtime on Friday
2016-02-12 at<br>
22:00 UTC (Mateusz Matuszkowiak)<br>
11. Re: [Fuel][Plugins] Multi release packages (Simon Pasquier)<br>
12. Re: [infra] [trove] gate jobs failing with ovh apt
mirrors<br>
(Craig Vyvial)<br>
13. [neutron] Broken Gate tests on branch stable/kilo, Project:<br>
openstack/neutron (John Joyce (joycej))<br>
14. Re: [neutron] Broken Gate tests on branch
stable/kilo,<br>
Project: openstack/neutron (Ihar Hrachyshka)<br>
15. Re: All hail the new per-region pypi, wheel and apt mirrors<br>
(Matthew Treinish)<br>
16. Re: [magnum][heat] Bug 1544227 (Hongbin Lu)<br>
17. [nova] Updating a volume attachment (Shoham Peller)<br>
18. Re: [nova] Updating a volume attachment (Andrea Rosa)<br>
19. Re: [neutron] [ipam] Migration to pluggable IPAM (Armando M.)<br>
20. Re: [neutron] [ipam] Migration to pluggable IPAM (Armando M.)<br>
21. Re: [nova] Updating a volume attachment (Shoham Peller)<br>
22. Re: [Nova][Cinder] Multi-attach, determining when to call<br>
os-brick's connector.disconnect_volume (Walter A.
Boring IV)<br>
23. Re: [infra] [trove] gate jobs failing with ovh apt
mirrors<br>
(Clint Byrum)<br>
24. [release] Release countdown for week R-7, Feb 15-19<br>
(Doug Hellmann)<br>
25. Re: [Fuel][Plugins] Multi release packages (Ilya Kutukov)<br>
26. Re: [Fuel][Plugins] Multi release packages (Ilya Kutukov)<br>
27. Re: [neutron] [ipam] Migration to pluggable IPAM (Carl Baldwin)<br>
28. Re: [neutron] [ipam] Migration to pluggable IPAM (Carl Baldwin)<br>
29. Re: [neutron] [ipam] Migration to pluggable IPAM (Carl Baldwin)<br>
30. Multiple delete of network through CLI is not
available as
of<br>
now (Monika Parkar)<br>
31. Re: [neutron] [ipam] Migration to pluggable IPAM (John Belamaric)<br>
32. [mitaka][hackathon] Mitaka Bug Smash Hackathon in Bay Area<br>
(March 7-9) (Boris Pavlovic)<br>
33. [nova] Update on scheduler and resource tracker
progress<br>
(Jay Pipes)<br>
34. Re: [infra][keystone][kolla][bandit] linters jobs<br>
(Steven Dake (stdake))<br>
35. Re: [magnum][heat] Bug 1544227 (Thomas Herve)<br>
36. [QA][grenade] Create new grenade job (Christopher N Solis)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 11 Feb 2016 07:33:12 -0430<br>
From: Flavio Percoco <flavio@redhat.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [all] [tc] "No Open Core" in 2016<br>
Message-ID: <20160211120312.GF11619@redhat.com><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
On 11/02/16 17:31 +0800, Thomas Goirand wrote:<br>
>On 02/08/2016 09:54 PM, Flavio Percoco wrote:<br>
>> Would our votes change if Poppy had support for OpenCDN (imagine
it's being<br>
>> maintained) even if that solution is terrible?<br>
><br>
>Let's say it was doing that, and spawning instances containing OpenCDN<br>
>running on a multi-datacenter OpenStack deployment, then IMO it would
be<br>
>a good candidate.<br>
><br>
<br>
This might be an overkill for cloud admins and there'll be close to no
clouds<br>
running their own CDN.<br>
<br>
>Oh, that, and ... not using CassandraDB. And yes, this thread is a
good<br>
>place to have this topic. I'm not sure who replied to me this thread<br>
>wasn't the place to discuss it: I respectfully disagree, since it's<br>
>another major blocker, IMO as important, if not more, as using a free<br>
>software CDN solution.<br>
<br>
It was me and I disagree. This thread is to talk about the *open core*
issue. In<br>
fact, the first email didn't even call out Poppy to begin with. For all
the<br>
remaining issues there's a spec in the governance repo that can be used.
Also,<br>
this topic was discussed in the latest TC meeting.<br>
<br>
Flavio<br>
<br>
-- <br>
@flaper87<br>
Flavio Percoco<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 819 bytes<br>
Desc: not available<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/4d9d2c6d/attachment-0001.pgp"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/4d9d2c6d/attachment-0001.pgp</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 11 Feb 2016 14:45:43 +0200<br>
From: Dennis Dmitriev <ddmitriev@mirantis.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [Fuel][QA] What is the preferred way to<br>
bootstrap a baremetal node with Fuel on product CI?<br>
Message-ID: <56BC8277.9020202@mirantis.com><br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
Thanks to all for answers!<br>
<br>
We will leave Fuel master node on a VM for our testing until some<br>
specific cases will require it on a baremetal.<br>
Ironic looks like a good tool for PXE provisioning and manage other<br>
baremetal slaves via IPMI, we will investigate how it could be used in<br>
our testing tools later.<br>
<br>
On 02/10/2016 12:43 PM, Vladimir Kuklin wrote:<br>
> Folks<br>
><br>
> I think the easiest and the best option here is to boot iPXE or<br>
> pxelinux with NFS and put master node image onto an NFS mount. This<br>
> one should work seamlessly.<br>
><br>
> On Wed, Feb 10, 2016 at 1:36 AM, Andrew Woodward<br>
> <awoodward@mirantis.com <</font></tt><a href=mailto:awoodward@mirantis.com><tt><font size=2>mailto:awoodward@mirantis.com</font></tt></a><tt><font size=2>>>
wrote:<br>
><br>
> Unless we hope to gain some insight and specific testing
by<br>
> installing the ISO on a bare-metal node (like UEFI),
I'd propose<br>
> that we stop testing things that are well tested elsewhere
(a<br>
> given ISO produces a working fuel master) and just focus
on what<br>
> we want to test in this environment. <br>
><br>
> Along this line, we cold<br>
><br>
> a) keep fuel masternode as a VM that is set up with
access to the<br>
> networks with the BM nodes. We have a good set of tools
to build<br>
> the master node in a VM already we can just re-use time
<br>
><br>
> b) use cobbler to control PXE based ISO boot/install,
then either<br>
> create new profiles in cobbler for various fuel nodes
with<br>
> different ISO or replace the single download link. (Make
sure you<br>
> transfer the image over HTTP as TFTP will be slow for
such size.<br>
> We have some tools and knowledge around using cobbler
as this is<br>
> effectively what fuel does its self.<br>
><br>
> c) fuel on fuel, as an extension of b, we can just use
cobbler on<br>
> an existing fuel node to provision another fuel node,
either from<br>
> ISO or even it's own repo's (we just need to send a
kickstart)<br>
><br>
> d) you can find servers with good BMC or DRAC that we
can issue<br>
> remote mount commands to the virtual cd-rom<br>
><br>
> e) consider using live-cd approach (long implmentation).
I've been<br>
> asked about supporting this in product where we start
an<br>
> environment with live-cd, the master node may make it's
own home<br>
> and then it can be moved off the live-cd when it's ready<br>
><br>
><br>
> On Tue, Feb 9, 2016 at 10:25 AM Pavlo Shchelokovskyy<br>
> <pshchelokovskyy@mirantis.com<br>
> <</font></tt><a href=mailto:pshchelokovskyy@mirantis.com><tt><font size=2>mailto:pshchelokovskyy@mirantis.com</font></tt></a><tt><font size=2>>>
wrote:<br>
><br>
> Hi,<br>
><br>
> Ironic also supports running it as standalone
service, w/o<br>
> Keystone/Glance/Neutron/Nova etc integration,
deploying images<br>
> from HTTP links. Could that be an option
too?<br>
><br>
> BTW, there is already an official project
under OpenStack<br>
> Baremetal program called Bifrost [0] that,
quoting, "automates<br>
> the task of deploying a base image onto
a set of known<br>
> hardware using Ironic" by installing
and configuring Ironic in<br>
> standalone mode.<br>
><br>
> [0] </font></tt><a href=https://github.com/openstack/bifrost><tt><font size=2>https://github.com/openstack/bifrost</font></tt></a><tt><font size=2><br>
><br>
> Cheers,<br>
><br>
><br>
> On Tue, Feb 9, 2016 at 6:46 PM Dennis
Dmitriev<br>
> <ddmitriev@mirantis.com <</font></tt><a href=mailto:ddmitriev@mirantis.com><tt><font size=2>mailto:ddmitriev@mirantis.com</font></tt></a><tt><font size=2>>>
wrote:<br>
><br>
> Hi all!<br>
><br>
> To run system tests on CI
on a daily basis using baremetal<br>
> servers<br>
> instead of VMs, Fuel admin
node also should be bootstrapped.<br>
><br>
> There is no a simple way
to mount an ISO with Fuel as a<br>
> CDROM or USB<br>
> device to a baremetal server,
so we choose the<br>
> provisioning with PXE.<br>
><br>
> It could be done in different
ways:<br>
><br>
> - Configure a libvirt bridge
as dnsmasq/tftp server for<br>
> admin/PXE network.<br>
> Benefits:
no additional services to be configured.<br>
> Doubts:
ISO should be mounted on the CI host (via<br>
> fusefs?); a HTTP<br>
> or NFS server for basic
provisioning should be started in<br>
> the admin/PXE<br>
> network (on the CI host);<br>
><br>
> - Start a VM that is connected
to admin/PXE network, and<br>
> configure<br>
> dnsmasq/tftp there.<br>
> Benefits:
no additional configuration on the CI host<br>
> should be<br>
> performed<br>
> Doubts:
starting the PXE service becomes a little<br>
> complicated<br>
><br>
> - Use Ironic for manage
baremetal nodes.<br>
> Benefits:
good support for different hardware,<br>
> support for<br>
> provisioning from ISO 'out
of the box'.<br>
> Doubts:
support for Ironic cannot be implemented in<br>
> short terms,<br>
> and there should be performed
additional investigations.<br>
><br>
> My question is: what
other benefits or doubts I missed<br>
> for first two<br>
> ways? Is there other ways
to provision baremetal with Fuel<br>
> that can be<br>
> automated in short terms?<br>
><br>
> Thanks for any suggestions!<br>
><br>
><br>
> --<br>
> Regards,<br>
> Dennis Dmitriev<br>
> QA Engineer,<br>
> Mirantis Inc. </font></tt><a href=http://www.mirantis.com/><tt><font size=2>http://www.mirantis.com</font></tt></a><tt><font size=2><br>
> e-mail/jabber: dis.xcom@gmail.com
<</font></tt><a href=mailto:dis.xcom@gmail.com><tt><font size=2>mailto:dis.xcom@gmail.com</font></tt></a><tt><font size=2>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing
List (not for usage questions)<br>
> Unsubscribe:<br>
> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> <</font></tt><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"><tt><font size=2>http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</font></tt></a><tt><font size=2>><br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
><br>
> -- <br>
> Dr. Pavlo Shchelokovskyy<br>
> Senior Software Engineer<br>
> Mirantis Inc<br>
> </font></tt><a href=www.mirantis.com><tt><font size=2>www.mirantis.com</font></tt></a><tt><font size=2><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not
for usage questions)<br>
> Unsubscribe:<br>
> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> <</font></tt><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"><tt><font size=2>http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</font></tt></a><tt><font size=2>><br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
><br>
> -- <br>
> -- <br>
> Andrew Woodward<br>
> Mirantis<br>
> Fuel Community Ambassador<br>
> Ceph Community <br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> <</font></tt><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"><tt><font size=2>http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</font></tt></a><tt><font size=2>><br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
><br>
><br>
><br>
><br>
> -- <br>
> Yours Faithfully,<br>
> Vladimir Kuklin,<br>
> Fuel Library Tech Lead,<br>
> Mirantis, Inc.<br>
> +7 (495) 640-49-04<br>
> +7 (926) 702-39-68<br>
> Skype kuklinvv<br>
> 35bk3, Vorontsovskaya Str.<br>
> Moscow, Russia,<br>
> </font></tt><a href=www.mirantis.com><tt><font size=2>www.mirantis.com</font></tt></a><tt><font size=2>
<</font></tt><a href=http://www.mirantis.ru/><tt><font size=2>http://www.mirantis.ru/</font></tt></a><tt><font size=2>><br>
> </font></tt><a href=www.mirantis.ru><tt><font size=2>www.mirantis.ru</font></tt></a><tt><font size=2>
<</font></tt><a href=http://www.mirantis.ru/><tt><font size=2>http://www.mirantis.ru/</font></tt></a><tt><font size=2>><br>
> vkuklin@mirantis.com <</font></tt><a href=mailto:vkuklin@mirantis.com><tt><font size=2>mailto:vkuklin@mirantis.com</font></tt></a><tt><font size=2>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
-- <br>
Regards,<br>
Dennis Dmitriev<br>
QA Engineer,<br>
Mirantis Inc. </font></tt><a href=http://www.mirantis.com/><tt><font size=2>http://www.mirantis.com</font></tt></a><tt><font size=2><br>
e-mail/jabber: dis.xcom@gmail.com<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/a4d88bff/attachment-0001.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/a4d88bff/attachment-0001.html</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 11 Feb 2016 13:59:16 +0100<br>
From: Daniel Mellado <daniel.mellado.es@ieee.org><br>
To: openstack-dev@lists.openstack.org<br>
Subject: Re: [openstack-dev] [qa] deprecating Tempest stress framework<br>
Message-ID: <56BC85A4.5080000@ieee.org><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
+1 to that, it was my 2nd to-be-deprecated after javelin ;)<br>
<br>
El 11/02/16 a las 12:47, Sean Dague escribi?:<br>
> In order to keep Tempest healthy I feel like it's time to prune things<br>
> that are outside of the core mission, especially when there are other<br>
> options out there.<br>
><br>
> The stress test framework in tempest is one of those. It builds on
other<br>
> things in Tempest, but isn't core to it.<br>
><br>
> I'd propose that becomes deprecated now, and removed in Newton. If
there<br>
> are folks that would like to carry it on from there, I think we should<br>
> spin it into a dedicated repository and just have it require tempest.<br>
><br>
> -Sean<br>
><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Thu, 11 Feb 2016 15:10:03 +0200<br>
From: Igor Kalnitsky <ikalnitsky@mirantis.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [Fuel] URL of Horizon is hard to find on<br>
the
dashboard<br>
Message-ID:<br>
<CACo6NWCoUvPY+naZVhVZM+tubtAndeGtZ-jra=dpB+3MC5AJhg@mail.gmail.com><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Vitaly,<br>
<br>
What about adding some button with "Go" or "Visit"
text? Somewhere on<br>
the right size of line? It'd be easy to understand what to click to<br>
visit the dashboard.<br>
<br>
- Igor<br>
<br>
On Thu, Feb 11, 2016 at 1:38 PM, Vitaly Kramskikh<br>
<vkramskikh@mirantis.com> wrote:<br>
> Roman,<br>
><br>
> For with enabled SSL it still can be quite long as it contains FQDN.
And we<br>
> also need to change plugin link representation accordingly, which
I don't<br>
> fine acceptable. I think you just got used to the old interface where
the<br>
> link to Horizon was a part of deployment task result message. We've
merged<br>
> small style update to underline Horizon/plugin links, I think it would
be<br>
> enough to solve the issue.<br>
><br>
> 2016-02-09 20:31 GMT+07:00 Roman Prykhodchenko <me@romcheg.me>:<br>
>><br>
>> Cannot we use display the same link we use in the title?<br>
>><br>
>> 9 ???. 2016 ?. ? 14:14 Vitaly Kramskikh <vkramskikh@mirantis.com><br>
>> ???????(??):<br>
>><br>
>> Hi, Roman,<br>
>><br>
>> I think the only solution here is to underline the title so it
would look<br>
>> like a link. I don't think it's a good idea to show full URL because:<br>
>><br>
>> If SSL is enabled, there will be 2 links - HTTP and HTTPS.<br>
>> Plugins can provide their own links for their dashboards, and
they would<br>
>> be shown using exactly the same representation which is used for
Horizon.<br>
>> These links could be quite long.<br>
>><br>
>><br>
>> 2016-02-09 20:04 GMT+07:00 Roman Prykhodchenko <me@romcheg.me>:<br>
>>><br>
>>> Whoops! I forgot to attach the link. Sorry!<br>
>>><br>
>>> 1. </font></tt><a href=http://i.imgur.com/8GaUtDq.png><tt><font size=2>http://i.imgur.com/8GaUtDq.png</font></tt></a><tt><font size=2><br>
>>><br>
>>> > 9 ???. 2016 ?. ? 13:48 Roman Prykhodchenko <me@romcheg.me>
???????(??):<br>
>>> ><br>
>>> > Hi fuelers!<br>
>>> ><br>
>>> > I?m not sure, if it?s my personal problem or the UX can
be improved a<br>
>>> > little, but I?ve literary spend more than 5 minutes trying
to figure out how<br>
>>> > to find a URL of Horizon. I?ve made a screenshot [1]
and I suggest to add a<br>
>>> > full a link with the full URL in its test after "The
OpenStack dashboard<br>
>>> > Horizon is now available". That would make things
much more usable.<br>
>>> ><br>
>>> ><br>
>>> > - romcheg<br>
>>> ><br>
>>> ><br>
>>> > __________________________________________________________________________<br>
>>> > OpenStack Development Mailing List (not for usage questions)<br>
>>> > Unsubscribe:<br>
>>> > OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>>> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>><br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Vitaly Kramskikh,<br>
>> Fuel UI Tech Lead,<br>
>> Mirantis, Inc.<br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>><br>
><br>
><br>
><br>
> --<br>
> Vitaly Kramskikh,<br>
> Fuel UI Tech Lead,<br>
> Mirantis, Inc.<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Thu, 11 Feb 2016 05:20:27 -0800<br>
From: Jim Rollenhagen <jim@jimrollenhagen.com><br>
To: openstack-dev@lists.openstack.org<br>
Subject: [openstack-dev] [ironic] More midcycle details<br>
Message-ID: <20160211132027.GE18744@jimrollenhagen.com><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Hi all,<br>
<br>
Our midcycle is next week! Here's everything you need to know.<br>
<br>
First and foremost, please RSVP on the etherpad, and add any topics<br>
(with your name!) that you'd like to discuss.<br>
</font></tt><a href="https://etherpad.openstack.org/p/ironic-mitaka-midcycle"><tt><font size=2>https://etherpad.openstack.org/p/ironic-mitaka-midcycle</font></tt></a><tt><font size=2><br>
<br>
Secondly, here are the time slots we'll be meeting at. All times UTC.<br>
February 16 15:00-20:00<br>
February 17 00:00-04:00<br>
February 17 15:00-20:00<br>
February 18 00:00-04:00<br>
February 18 15:00-20:00<br>
February 19 00:00-04:00<br>
<br>
Our regular weekly meeting for February 15 is cancelled.<br>
<br>
Communications: we'll be using VOIP, IRC, and etherpad.<br>
<br>
The VOIP system is provided by the infra team. We'll be in room 7777.<br>
More details: </font></tt><a href=https://wiki.openstack.org/wiki/Infrastructure/Conferencing><tt><font size=2>https://wiki.openstack.org/wiki/Infrastructure/Conferencing</font></tt></a><tt><font size=2><br>
You may use a telephone or any SIP client to connect.<br>
We will not be officially recording the audio; however do note that I<br>
can't stop anyone from doing so.<br>
<br>
We'll be using #openstack-sprint on Freenode for the main IRC channel<br>
for the meetup. Most of us will also be in #openstack-ironic.<br>
Please note that these channels are publically logged.<br>
<br>
The main etherpad for the meetup is here:<br>
</font></tt><a href="https://etherpad.openstack.org/p/ironic-mitaka-midcycle"><tt><font size=2>https://etherpad.openstack.org/p/ironic-mitaka-midcycle</font></tt></a><tt><font size=2><br>
It also contains all of these details.<br>
We may start additional etherpads for some topics during the meeting;<br>
those will be linked from the main etherpad.<br>
<br>
If you need help during the midcycle, here's a good list of people to<br>
ping in IRC, who will be at most of the time slots:<br>
* jroll (me)<br>
* devananda<br>
* jlvillal<br>
* TheJulia<br>
<br>
If you have any questions or comments, please reply to this email or<br>
ping me directly in IRC.<br>
<br>
Hope to see you all there! :)<br>
<br>
// jim<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Thu, 11 Feb 2016 19:15:51 +0530<br>
From: Pankaj Mishra <pm.mishra167@gmail.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: [openstack-dev] Glance Image signing and verification<br>
Message-ID:<br>
<CAD1-J_Da7ko+Qr_HiOgG7PmCxbkB3Xb6iix7gmhrqnW90bZVow@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
<br>
<br>
I am new in OpenStack and I want to create image through glance CLI and
I<br>
am referring blueprint<br>
</font></tt><a href="https://blueprints.launchpad.net/glance/+spec/image-signing-and-verification-support"><tt><font size=2>https://blueprints.launchpad.net/glance/+spec/image-signing-and-verification-support</font></tt></a><tt><font size=2><br>
and I am using below mentioned command to create the image. So what is
the<br>
step for Glance Image signing and verification by using glance cli.<br>
<br>
<br>
<br>
glance --os-image-api-version 2 image-create [--architecture<br>
<ARCHITECTURE>]
[--protected [True|False]]<br>
[--name <NAME>]
[--instance-uuid<br>
<INSTANCE_UUID>]
[--min-disk <MIN_DISK>]<br>
[--visibility <VISIBILITY>]
[--kernel-id<br>
<KERNEL_ID>]
[--tags <TAGS> [<TAGS> ...]]<br>
[--os-version <OS_VERSION>]<br>
[--disk-format <DISK_FORMAT>] [--self <SELF>]<br>
[--os-distro <OS_DISTRO>] [--id <ID>]<br>
[--owner <OWNER>] [--ramdisk-id <RAMDISK_ID>]<br>
[--min-ram <MIN_RAM>]
[--container-format<br>
<CONTAINER_FORMAT>]
[--property <key=value>]<br>
[--file <FILE>]
[--progress]<br>
<br>
<br>
<br>
Please any one suggest me, how to execute this command for image signing<br>
and verification.<br>
<br>
<br>
<br>
Thanks & Regards,<br>
<br>
Pankaj<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/ab72d6f1/attachment-0001.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/ab72d6f1/attachment-0001.html</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Thu, 11 Feb 2016 08:51:08 -0500<br>
From: Nikhil Komawar <nik.komawar@gmail.com><br>
To: openstack-dev@lists.openstack.org<br>
Subject: Re: [openstack-dev] Glance Image signing and verification<br>
Message-ID: <56BC91CC.9090503@gmail.com><br>
Content-Type: text/plain; charset=utf-8<br>
</font></tt>
<br><tt><font size=2>Hi Pankaj,<br>
<br>
Here's a example instruction set for that feature.<br>
<br>
</font></tt><a href="https://etherpad.openstack.org/p/liberty-glance-image-signing-instructions"><tt><font size=2>https://etherpad.openstack.org/p/liberty-glance-image-signing-instructions</font></tt></a><tt><font size=2><br>
<br>
Hope it helps.<br>
<br>
On 2/11/16 8:45 AM, Pankaj Mishra wrote:<br>
><br>
> Hi,<br>
><br>
> <br>
><br>
> I am new in OpenStack and I want to create image through glance CLI<br>
> and I am referring blueprint<br>
> </font></tt><a href="https://blueprints.launchpad.net/glance/+spec/image-signing-and-verification-support"><tt><font size=2>https://blueprints.launchpad.net/glance/+spec/image-signing-and-verification-support</font></tt></a><tt><font size=2><br>
> and I am using below mentioned command to create the image.
So what<br>
> is the step for Glance Image signing and verification by using
glance<br>
> cli.<br>
><br>
> <br>
><br>
> glance --os-image-api-version 2 image-create [--architecture<br>
> <ARCHITECTURE>]<br>
> [--protected [True|False]] [--name <NAME>]<br>
> [--instance-uuid <INSTANCE_UUID>]<br>
> [--min-disk <MIN_DISK>] [--visibility <VISIBILITY>]<br>
> [--kernel-id <KERNEL_ID>]<br>
> [--tags <TAGS> [<TAGS> ...]]<br>
> [--os-version <OS_VERSION>]<br>
> [--disk-format <DISK_FORMAT>] [--self <SELF>]<br>
> [--os-distro <OS_DISTRO>] [--id <ID>]<br>
> [--owner <OWNER>] [--ramdisk-id <RAMDISK_ID>]<br>
> [--min-ram <MIN_RAM>]<br>
> [--container-format <CONTAINER_FORMAT>]<br>
> [--property <key=value>] [--file <FILE>]<br>
> [--progress]<br>
><br>
> <br>
><br>
> Please any one suggest me, how to execute this command for image<br>
> signing and verification.<br>
><br>
> <br>
><br>
> Thanks & Regards,<br>
><br>
> Pankaj<br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
-- <br>
<br>
Thanks,<br>
Nikhil<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Thu, 11 Feb 2016 14:44:24 +0000<br>
From: Jeremy Stanley <fungi@yuggoth.org><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [infra] [trove] gate jobs failing with<br>
ovh apt mirrors<br>
Message-ID: <20160211144424.GE2343@yuggoth.org><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On 2016-02-11 07:00:01 +0000 (+0000), Craig Vyvial wrote:<br>
> I started noticing more of the Trove gate jobs failing in the last
24 hours<br>
> and I think i've tracked it down to this mirror specifically.<br>
> </font></tt><a href=http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/main/p/><tt><font size=2>http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/main/p/</font></tt></a><tt><font size=2><br>
> It looks like its missing the python-software-properties package and<br>
> causing our gate job to fail.<br>
[...]<br>
<br>
I think you're looking for this:<br>
<br>
</font></tt><a href="http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/universe/s/software-properties/"><tt><font size=2>http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/universe/s/software-properties/</font></tt></a><tt><font size=2><br>
<br>
> </font></tt><a href="http://logs.openstack.org/50/278050/1/check/gate-trove-functional-dsvm-mysql/e70f5c0/logs/devstack-gate-post_test_hook.txt.gz#_2016-02-11_05_12_01_023"><tt><font size=2>http://logs.openstack.org/50/278050/1/check/gate-trove-functional-dsvm-mysql/e70f5c0/logs/devstack-gate-post_test_hook.txt.gz#_2016-02-11_05_12_01_023</font></tt></a><tt><font size=2><br>
[...]<br>
<br>
The error there implies that diskimage-builder invocation in your<br>
job is reusing the host's apt sources but not its apt configuration,<br>
and so is expecting the packages on the mirrors to be secure-apt<br>
signed by a trusted key.<br>
-- <br>
Jeremy Stanley<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Thu, 11 Feb 2016 15:01:15 +0000<br>
From: John Belamaric <jbelamaric@infoblox.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [neutron] [ipam] Migration to pluggable<br>
IPAM<br>
Message-ID: <1CF4D11A-B29E-4327-8525-AF4F5A8C8B6C@infoblox.com><br>
Content-Type: text/plain; charset="Windows-1252"<br>
<br>
<br>
<br>
---<br>
John Belamaric<br>
(240) 383-6963<br>
<br>
> On Feb 11, 2016, at 5:37 AM, Ihar Hrachyshka <ihrachys@redhat.com>
wrote:<br>
> <br>
> What?s the user visible change in behaviour after the switch? If it?s
only internal implementation change, I don?t see why we want to leave the
choice to operators.<br>
> <br>
<br>
It is only internal implementation changes. <br>
<br>
<br>
>> The other aspect is the deprecation process. If you add the switch
into the DB migration path then the whole deprecation becomes superseded
as the old IPAM logic should be abandoned immediately after that. But perhaps
the other way of looking at it is that we should make an exception in the
deprecation process.<br>
>> <br>
>> Salvatore<br>
>> <br>
>> On 11 February 2016 at 00:19, Carl Baldwin <carl@ecbaldwin.net>
wrote:<br>
>> On Thu, Feb 4, 2016 at 8:12 PM, Armando M. <armamig@gmail.com>
wrote:<br>
>> > Technically we can make this as sophisticated and seamless
as we want, but<br>
>> > this is a one-off, once it's done the pain goes away, and
we won't be doing<br>
>> > another migration like this ever again. So I wouldn't over
engineer it.<br>
>> <br>
>> Frankly, I was worried that going the other way was over-engineering<br>
>> it. It will be more difficult for us to manage this transition.<br>
>> <br>
>> I'm still struggling to see what makes this particular migration<br>
>> different than other cases where we change the database schema
and the<br>
>> code a bit and we automatically migrate everyone to it as part
of the<br>
>> routine migration. What is it about this case that necessitates<br>
>> giving the operator the option?<br>
>> <br>
>> Carl<br>
>> <br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>> <br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
> <br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Thu, 11 Feb 2016 16:30:28 +0100<br>
From: Mateusz Matuszkowiak <mmatuszkowiak@mirantis.com><br>
To: "Elizabeth K. Joseph" <lyz@princessleia.com><br>
Cc: OpenStack Development Mailing List<br>
<openstack-dev@lists.openstack.org>, OpenStack Infra<br>
<openstack-infra@lists.openstack.org><br>
Subject: Re: [openstack-dev] [OpenStack-Infra] Gerrit downtime on<br>
Friday
2016-02-12 at 22:00 UTC<br>
Message-ID: <0922A746-C0AC-4EF8-A7AF-F49805EA8467@mirantis.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello!<br>
<br>
I have created a small patch [0] which is about renaming "openstack/fuel-plugin-astra?
to "openstack/fuel-plugin-astara? (one character missing).<br>
Please also include it within Gerrit downtime.<br>
<br>
Thanks in advance.<br>
<br>
[0] </font></tt><a href=https://review.openstack.org/#/c/279138/><tt><font size=2>https://review.openstack.org/#/c/279138/</font></tt></a><tt><font size=2>
<</font></tt><a href=https://review.openstack.org/#/c/279138/><tt><font size=2>https://review.openstack.org/#/c/279138/</font></tt></a><tt><font size=2>><br>
<br>
Regards,<br>
--<br>
Fuel DevOps<br>
Mateusz Matuszkowiak<br>
<br>
<br>
<br>
<br>
> On Feb 10, 2016, at 12:05 AM, Elizabeth K. Joseph <lyz@princessleia.com>
wrote:<br>
> <br>
> Hi everyone,<br>
> <br>
> On Friday, February 12th at 22:00 UTC Gerrit will be unavailable for<br>
> about 60 minutes while we rename some projects.<br>
> <br>
> Existing reviews, project watches, etc, should all be carried over.<br>
> Currently, we plan on renaming the following projects:<br>
> <br>
> openstack/ceilometer-specs -> openstack/telemetry-specs<br>
> openstack/sahara-scenario -> openstack/sahara-tests<br>
> <br>
> This list is subject to change.<br>
> <br>
> If you have any questions about the maintenance, please reply here
or<br>
> contact us in #openstack-infra on Freenode.<br>
> <br>
> -- <br>
> Elizabeth Krumbach Joseph || Lyz || pleia2<br>
> <br>
> _______________________________________________<br>
> OpenStack-Infra mailing list<br>
> OpenStack-Infra@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra</font></tt></a><tt><font size=2><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/57cf78f3/attachment-0001.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/57cf78f3/attachment-0001.html</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Thu, 11 Feb 2016 16:31:52 +0100<br>
From: Simon Pasquier <spasquier@mirantis.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [Fuel][Plugins] Multi release packages<br>
Message-ID:<br>
<CAOq3GZU1O=eUenRsgbT9BCNxQ5=o7zh9gnaFM5ms_0A0V_5HMg@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
On Thu, Feb 11, 2016 at 11:46 AM, Igor Kalnitsky <ikalnitsky@mirantis.com><br>
wrote:<br>
<br>
> Hey folks,<br>
><br>
> The original idea is to provide a way to build plugin that are<br>
> compatible with few releases. It makes sense to me, cause it looks<br>
> awful if you need to maintain different branches for different Fuel<br>
> releases and there's no difference in the sources. In that case, each<br>
> bugfix to deployment scripts requires:<br>
><br>
> * backport bugfix to other branches (N backports)<br>
> * build new packages for supported releases (N builds)<br>
> * release new packages (N releases)<br>
><br>
> It's somehow.. annoying.<br>
><br>
<br>
A big +1 on Igor's remark. I've already expressed it in another thread
but<br>
it should be expected that plugin developers want to support 2 consecutive<br>
versions of Fuel for a given version of their plugin.<br>
That being said, I've never had issues to do it with the current plugin<br>
framework. Except when Fuel breaks the backward compatibility but it's<br>
another story...<br>
<br>
Simon<br>
<br>
<br>
><br>
> However, I starting agree that having all-in-one RPM when deployment<br>
> scripts are different, tasks are different, roles/volumes are<br>
> different, probably isn't a good idea. It basically means that your<br>
> sources are completely different, and that means you have different<br>
> implementations of the same plugin. In that case, in order to avoid<br>
> mess in source tree, it'd be better to separate such implementations<br>
> on VCS level.<br>
><br>
> But I'd like to hear more opinion from plugin developers.<br>
><br>
> - Igor<br>
><br>
> On Thu, Feb 11, 2016 at 9:16 AM, Bulat Gaifullin<br>
> <bgaifullin@mirantis.com> wrote:<br>
> > I agree with Stas, one rpm - one version.<br>
> ><br>
> > But plugin builder allows to specify several releases as compatible.
The<br>
> > deployment tasks and repositories can be specified per release,
at the<br>
> same<br>
> > time the deployment graph is one for all releases.<br>
> > Currently it looks like half-implemented feature. Can we
drop this<br>
> feature?<br>
> > or should we finish implementation of this feature.<br>
> ><br>
> ><br>
> > Regards,<br>
> > Bulat Gaifullin<br>
> > Mirantis Inc.<br>
> ><br>
> ><br>
> ><br>
> > On 11 Feb 2016, at 02:41, Andrew Woodward <xarses@gmail.com>
wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko <<br>
> dborodaenko@mirantis.com><br>
> > wrote:<br>
> >><br>
> >> +1 to Stas, supplanting VCS branches with code duplication
is a path to<br>
> >> madness and despair. The dubious benefits of a cross-release
backwards<br>
> >> compatible plugin binary are not worth the code and infra
technical debt<br>
> >> that such approach would accrue over time.<br>
> ><br>
> ><br>
> > Supporting multiple fuel releases will likely result in madness
as<br>
> > discussed, however as we look to support multiple OpenStack releases
from<br>
> > the same version of fuel, this methodology becomes much more
important.<br>
> ><br>
> >><br>
> >> On Wed, Feb 10, 2016 at 07:36:30PM +0300, Stanislaw Bogatkin
wrote:<br>
> >> > It changes mostly nothing for case of furious plugin
development when<br>
> >> > big<br>
> >> > parts of code changed from one release to another.<br>
> >> ><br>
> >> > You will have 6 different deployment_tasks directories
and 30 a little<br>
> >> > bit<br>
> >> > different files in root directory of plugin. Also you
forgot about<br>
> >> > repositories directory (+6 at least), pre_build hooks
(also 6) and so<br>
> >> > on.<br>
> >> > It will look as hell after just 3 years of development.<br>
> >> ><br>
> >> > Also I can't imagine how to deal with plugin licensing
if you have<br>
> >> > Apache<br>
> >> > for liberty but BSD for mitaka release, for example.<br>
> >> ><br>
> >> > Much easier way to develop a plugin is to keep it's
source in VCS like<br>
> >> > Git<br>
> >> > and just make a branches for every fuel release. It
will give us<br>
> >> > opportunity to not store a bunch of similar but a little
bit different<br>
> >> > files in repo. There is no reason to drag all different
versions of<br>
> code<br>
> >> > for specific release.<br>
> >> ><br>
> >> ><br>
> >> > On other hand there is a pros - your plugin can survive
after upgrade<br>
> if<br>
> >> > it<br>
> >> > supports new release, no changes needed here.<br>
> >> ><br>
> >> > On Wed, Feb 10, 2016 at 4:04 PM, Alexey Shtokolov<br>
> >> > <ashtokolov@mirantis.com><br>
> >> > wrote:<br>
> >> ><br>
> >> > > Fuelers,<br>
> >> > ><br>
> >> > > We are discussing the idea to extend the multi
release packages for<br>
> >> > > plugins.<br>
> >> > ><br>
> >> > > Fuel plugin builder (FPB) can create one rpm-package
for all<br>
> supported<br>
> >> > > releases (from metadata.yaml) but we can specify
only deployment<br>
> >> > > scripts<br>
> >> > > and repositories per release.<br>
> >> > ><br>
> >> > > Current release definition (in metadata.yaml):<br>
> >> > > - os: ubuntu<br>
> >> > > version: liberty-8.0<br>
> >> > > mode: ['ha']<br>
> >> > > deployment_scripts_path: deployment_scripts/<br>
> >> > > repository_path: repositories/ubuntu<br>
> >> > ><br>
> ><br>
> ><br>
> > This will result in far too much clutter.<br>
> > For starters we should support nested over rides. for example
the author<br>
> may<br>
> > have already taken account for the changes between one openstack
version<br>
> to<br>
> > another. In this case they only should need to define the releases
they<br>
> > support and not specify any additional locations. Later they
may<br>
> determine<br>
> > that they only need to replace packages, or one other file they
should<br>
> not<br>
> > be required to code every location for each release<br>
> ><br>
> > Also, at the same time we MUST clean up importing various yaml
files.<br>
> > Specifically, tasks, volumes, node roles, and network roles.
Requiring<br>
> that<br>
> > they all be maintained in a single file doesn't scale, we don't
require<br>
> it<br>
> > for tasks.yaml in fuel library, and we should not require it
in plugins.<br>
> We<br>
> > should simply do the same thing as tasks.yaml in library, scan
the<br>
> subtree<br>
> > for specific file names and just merge them all together. (This
has been<br>
> > expressed multiple times by people with larger plugins)<br>
> ><br>
> >> > > So the idea [0] is to make releases fully configurable.<br>
> >> > > Suggested changes for release definition (in metadata.yaml):<br>
> >> > > components_path: components_liberty.yaml<br>
> >> > > deployment_tasks_path: deployment_tasks_liberty/
# <- folder<br>
> >><br>
> >> > > environment_config_path: environment_config_liberty.yaml<br>
> >> > > network_roles_path: network_roles_liberty.yaml<br>
> >> > > node_roles_path: node_roles_liberty.yaml<br>
> >> > > volumes_path: volumes_liberty.yaml<br>
> >> > ><br>
> >> > > I see the issue: if we change anything for one
release (e.g.<br>
> >> > > deployment_task typo) revalidation is needed for
all releases.<br>
> >> > ><br>
> >> > > Your Pros and cons please?<br>
> >> > ><br>
> >> > > [0] </font></tt><a href=https://review.openstack.org/#/c/271417/><tt><font size=2>https://review.openstack.org/#/c/271417/</font></tt></a><tt><font size=2><br>
> >> > > ---<br>
> >> > > WBR, Alexey Shtokolov<br>
> >> > ><br>
> >> > ><br>
> >> > ><br>
> __________________________________________________________________________<br>
> >> > > OpenStack Development Mailing List (not for usage
questions)<br>
> >> > > Unsubscribe:<br>
> >> > > OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> >> > > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> >> > ><br>
> >> > ><br>
> >> ><br>
> >> ><br>
> >> > --<br>
> >> > with best regards,<br>
> >> > Stan.<br>
> >><br>
> >> ><br>
> >> ><br>
> __________________________________________________________________________<br>
> >> > OpenStack Development Mailing List (not for usage questions)<br>
> >> > Unsubscribe:<br>
> >> > OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> >> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> >><br>
> >><br>
> >><br>
> __________________________________________________________________________<br>
> >> OpenStack Development Mailing List (not for usage questions)<br>
> >> Unsubscribe:<br>
> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> >> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> ><br>
> > --<br>
> ><br>
> > --<br>
> ><br>
> > Andrew Woodward<br>
> ><br>
> > Mirantis<br>
> ><br>
> > Fuel Community Ambassador<br>
> ><br>
> > Ceph Community<br>
> ><br>
> ><br>
> __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe:<br>
> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> ><br>
> ><br>
> ><br>
> ><br>
> __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe:<br>
> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> ><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/6368b0b9/attachment-0001.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/6368b0b9/attachment-0001.html</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Thu, 11 Feb 2016 15:43:40 +0000<br>
From: Craig Vyvial <cp16net@gmail.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [infra] [trove] gate jobs failing with<br>
ovh apt
mirrors<br>
Message-ID:<br>
<CAOK58XTpsBmbjWafyMsotsa__dfhP7rBTYohdBcttm0BS2NFVQ@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Jeremy,<br>
<br>
Thanks for looking at this. That makes sense but I'm not sure how to<br>
resolve this issue with the current diskimage-builder elements. If anyone<br>
has ideas it would be greatly appreciated.<br>
<br>
Thanks,<br>
-Craig Vyvial<br>
<br>
On Thu, Feb 11, 2016 at 8:44 AM Jeremy Stanley <fungi@yuggoth.org>
wrote:<br>
<br>
> On 2016-02-11 07:00:01 +0000 (+0000), Craig Vyvial wrote:<br>
> > I started noticing more of the Trove gate jobs failing in the
last 24<br>
> hours<br>
> > and I think i've tracked it down to this mirror specifically.<br>
> > </font></tt><a href=http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/main/p/><tt><font size=2>http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/main/p/</font></tt></a><tt><font size=2><br>
> > It looks like its missing the python-software-properties package
and<br>
> > causing our gate job to fail.<br>
> [...]<br>
><br>
> I think you're looking for this:<br>
><br>
><br>
> </font></tt><a href="http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/universe/s/software-properties/"><tt><font size=2>http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/universe/s/software-properties/</font></tt></a><tt><font size=2><br>
><br>
> ><br>
> </font></tt><a href="http://logs.openstack.org/50/278050/1/check/gate-trove-functional-dsvm-mysql/e70f5c0/logs/devstack-gate-post_test_hook.txt.gz#_2016-02-11_05_12_01_023"><tt><font size=2>http://logs.openstack.org/50/278050/1/check/gate-trove-functional-dsvm-mysql/e70f5c0/logs/devstack-gate-post_test_hook.txt.gz#_2016-02-11_05_12_01_023</font></tt></a><tt><font size=2><br>
> [...]<br>
><br>
> The error there implies that diskimage-builder invocation in your<br>
> job is reusing the host's apt sources but not its apt configuration,<br>
> and so is expecting the packages on the mirrors to be secure-apt<br>
> signed by a trusted key.<br>
> --<br>
> Jeremy Stanley<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/79951157/attachment-0001.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/79951157/attachment-0001.html</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Thu, 11 Feb 2016 16:01:21 +0000<br>
From: "John Joyce (joycej)" <joycej@cisco.com><br>
To: "openstack-dev@lists.openstack.org"<br>
<openstack-dev@lists.openstack.org><br>
Subject: [openstack-dev] [neutron] Broken Gate tests on branch<br>
stable/kilo, Project: openstack/neutron<br>
Message-ID: <98ed36b1c2c54f6b9902a0b13068c8c2@XCH-RTP-013.cisco.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I was trying to cherry pick a change in Liberty back to stable Kilo: </font></tt><a href=https://review.openstack.org/#/c/277962/><tt><font size=2>https://review.openstack.org/#/c/277962/</font></tt></a><tt><font size=2><br>
Many of the gate tests failed and I notice that appears to be the case
with most of the reviews going back a while in the past. From
a quick check I did not see anything related to this change that would
have caused the failure signatures I was seeing. <br>
<br>
Is this a known problem? Is anyone already working on it in any
capacity?<br>
John<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Thu, 11 Feb 2016 17:08:19 +0100<br>
From: Ihar Hrachyshka <ihrachys@redhat.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [neutron] Broken Gate tests on branch<br>
stable/kilo, Project: openstack/neutron<br>
Message-ID: <A3538DD1-86CB-4051-B0D8-FE75FEF2C087@redhat.com><br>
Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed<br>
<br>
John Joyce (joycej) <joycej@cisco.com> wrote:<br>
<br>
> I was trying to cherry pick a change in Liberty back to stable Kilo:
<br>
> </font></tt><a href=https://review.openstack.org/#/c/277962/><tt><font size=2>https://review.openstack.org/#/c/277962/</font></tt></a><tt><font size=2><br>
> Many of the gate tests failed and I notice that appears to be the
case <br>
> with most of the reviews going back a while in the past. From
a quick <br>
> check I did not see anything related to this change that would have
<br>
> caused the failure signatures I was seeing.<br>
><br>
> Is this a known problem? Is anyone already working on it in
any capacity?<br>
>
John<br>
<br>
The issue was due to fixtures release. Now fixed. You already rechecked,
so <br>
just wait for new test results.<br>
<br>
Ihar<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Thu, 11 Feb 2016 11:16:01 -0500</font></tt>
<br><tt><font size=2>From: Matthew Treinish <mtreinish@kortar.org><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] All hail the new per-region pypi, wheel<br>
and apt mirrors<br>
Message-ID: <20160211161601.GA22458@sazabi.kortar.org><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On Wed, Feb 10, 2016 at 06:45:25PM -0600, Monty Taylor wrote:<br>
> Hey everybody,<br>
> <br>
> tl;dr - We have new AFS-based consistent per-region mirrors of PyPI
and APT<br>
> repos with additional wheel repos containing pre-built wheels for
all the<br>
> modules in global-requirements<br>
> <br>
> We've just rolled out a new change that you should mostly never notice
-<br>
> except that jobs should be a bit faster and more reliable.<br>
> <br>
> The underpinning of the new mirrors is AFS, which is a global distributed<br>
> filesystem developed by Carnegie Mellon back in the 1980's. In a lovely
fit<br>
> of old-is-new-again, the challenges that software had to deal with
in the<br>
> 80s (flaky networks, frequent computer failures) mirror life in the
cloud<br>
> pretty nicely, and the engineering work to solve them winds up being
quite<br>
> relevant.<br>
> <br>
> One of the nice things we get from AFS is the ability to do atomic<br>
> consistent releases of new filesystem snapshots to read-only replicas.
That<br>
> means we can build a new version of our mirror content, check it for<br>
> consistency, and then release it for consumption to all of the consumers
at<br>
> the same time. That's important for the gate, because our "package
not<br>
> found" errors are usually about the mirror state shifting during
a test job<br>
> run.<br>
> <br>
> We've had per-region PyPI mirrors for quite some time (and indeed
the gate<br>
> would largely be dead in the water without them). The improvement
from this<br>
> work for them is that they're now AFS based, so we should never have
a<br>
> visible mirror state that's wonky or inconsistent between regions,
and we<br>
> can more easily expand into new cloud regions.<br>
> <br>
> We've added per-region apt mirrors (with yum to come soon) to the
mix based<br>
> on the same concept - we build the new mirror state then release it.
There<br>
> is one additional way that apt can fail even with consistent mirror
states,<br>
> which is that apt repos purge old versions of packages that are no
longer<br>
> referenced. If a new mirror state rolls out between the time devstack
runs<br>
> apt-get update and the time it tries to do apt-get install of something,
you<br>
> can get a situation where apt is trying to install a version of a
package<br>
> that is no longer present in the archive. To mitigate this, we're
purging<br>
> our mirror on a delay ... in our mirror runs every 2 hours we add
new<br>
> packages and update the index, and then in the next mirror run we'll
delete<br>
> the packages the previous run made unreferenced. This should make
apt errors<br>
> about package not found go away.<br>
> <br>
> Last but certainly not least, there are now also wheel repositories
of<br>
> wheels built for all of our python packages from global-requirements.
This<br>
> is a speed increase and shaves 1.8 tens of minutes off of a
normal devstack<br>
> run.<br>
<br>
This is a big win for everyone. You can see the speed improvement:<br>
<br>
</font></tt><a href="http://status.openstack.org/openstack-health/#/test/devstack?end=2016-02-10T15:04:32.039Z&resolutionKey=hour&duration=P1M"><tt><font size=2>http://status.openstack.org/openstack-health/#/test/devstack?end=2016-02-10T15:04:32.039Z&resolutionKey=hour&duration=P1M</font></tt></a><tt><font size=2><br>
<br>
It's quite obvious devstack started getting much faster when the wheel
mirror<br>
was enabled.<br>
<br>
> <br>
> With these changes, it means we're writing not only pip.conf but now<br>
> sources.list files into the test nodes. If you happen to be doing
extra<br>
> special things with either of those in your jobs, you'll want to make
sure<br>
> you consume the config files we're laying down<br>
> <br>
> Finally, although all Infra projects are a team effort - a big shout
out to<br>
> Michael Krotschek and Jim Blair for diving in and getting this finished
over<br>
> the past couple of weeks.<br>
> <br>
> Monty<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 819 bytes<br>
Desc: not available<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/9b0d1285/attachment-0001.pgp"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/9b0d1285/attachment-0001.pgp</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Thu, 11 Feb 2016 16:23:54 +0000<br>
From: Hongbin Lu <hongbin.lu@huawei.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [magnum][heat] Bug 1544227<br>
Message-ID:<br>
<0957CD8F4B55C0418161614FEC580D6B01BE49AB@YYZEML702-CHM.china.huawei.com><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Rabi,<br>
<br>
As you observed, I have uploaded two testing patches [1][2] that depends
on your fix patch [3] and the reverted patch [4] respectively. An observation
is that the test "gate-functional-dsvm-magnum-mesos" failed in
[1], but passed in [2]. That implies the reverted patch does resolve an
issue (although I am not sure exactly how).<br>
<br>
I did notice there are several 404 errors from Neutron, but those errors
exist in successful tests as well so I don't think they are the root cause.<br>
<br>
[1] </font></tt><a href=https://review.openstack.org/#/c/278578/><tt><font size=2>https://review.openstack.org/#/c/278578/</font></tt></a><tt><font size=2><br>
[2] </font></tt><a href=https://review.openstack.org/#/c/278778/><tt><font size=2>https://review.openstack.org/#/c/278778/</font></tt></a><tt><font size=2><br>
[3] </font></tt><a href=https://review.openstack.org/#/c/278576/><tt><font size=2>https://review.openstack.org/#/c/278576/</font></tt></a><tt><font size=2><br>
[4] </font></tt><a href=https://review.openstack.org/#/c/278575/><tt><font size=2>https://review.openstack.org/#/c/278575/</font></tt></a><tt><font size=2><br>
<br>
Best regards,<br>
Hongbin<br>
<br>
-----Original Message-----<br>
From: Rabi Mishra [</font></tt><a href=mailto:ramishra@redhat.com><tt><font size=2>mailto:ramishra@redhat.com</font></tt></a><tt><font size=2>]
<br>
Sent: February-11-16 12:46 AM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] [magnum][heat] Bug 1544227<br>
<br>
Hi,<br>
<br>
We did some analysis of the issue you are facing.<br>
<br>
One of the issues from heat side is, we convert None(singleton) resource
references to 'None'(string) and the translation logic is not ignoring
them. Though we don't apply translation rules to resource references[1].We
don't see this issue after this patch[2].<br>
<br>
The issue you mentioned below with respect to SD and SDG, does not look
like something to do with this patch. I also see the similar issues when
you tested with the reverted patch[3].<br>
<br>
I also noticed that there are some 404 from neutron in the engine logs[4]
for the test patch. <br>
I did not notice them when I tested locally with the templates you had
provided.<br>
<br>
<br>
Having said that, we can still revert the patch, if that resolves your
issue. <br>
<br>
[1] </font></tt><a href=https://github.com/openstack/heat/blob/master/heat/engine/translation.py#L234><tt><font size=2>https://github.com/openstack/heat/blob/master/heat/engine/translation.py#L234</font></tt></a><tt><font size=2><br>
[2] </font></tt><a href=https://review.openstack.org/#/c/278576/><tt><font size=2>https://review.openstack.org/#/c/278576/</font></tt></a><tt><font size=2><br>
[3]</font></tt><a href="http://logs.openstack.org/78/278778/1/check/gate-functional-dsvm-magnum-k8s/ea48ba2/console.html#_2016-02-11_03_07_49_039"><tt><font size=2>http://logs.openstack.org/78/278778/1/check/gate-functional-dsvm-magnum-k8s/ea48ba2/console.html#_2016-02-11_03_07_49_039</font></tt></a><tt><font size=2><br>
[4] </font></tt><a href="http://logs.openstack.org/78/278578/1/check/gate-functional-dsvm-magnum-swarm/51eeb3b/logs/screen-h-eng.txt"><tt><font size=2>http://logs.openstack.org/78/278578/1/check/gate-functional-dsvm-magnum-swarm/51eeb3b/logs/screen-h-eng.txt</font></tt></a><tt><font size=2><br>
<br>
<br>
Regards,<br>
Rabi<br>
<br>
> Hi Heat team,<br>
> <br>
> As mentioned in IRC, magnum gate broke with bug 1544227 . Rabi <br>
> submitted on a fix (</font></tt><a href=https://review.openstack.org/#/c/278576/><tt><font size=2>https://review.openstack.org/#/c/278576/</font></tt></a><tt><font size=2>),
but it <br>
> doesn't seem to be enough to unlock the broken gate. In particular,
it <br>
> seems templates with SoftwareDeploymentGroup resource failed to <br>
> complete (I have commented on the review above for how to reproduce).<br>
> <br>
> Right now, I prefer to merge the reverted patch<br>
> (</font></tt><a href=https://review.openstack.org/#/c/278575/><tt><font size=2>https://review.openstack.org/#/c/278575/</font></tt></a><tt><font size=2>)
to unlock our gate <br>
> immediately, unless someone can work on a quick fix. We appreciate
the help.<br>
> <br>
> Best regards,<br>
> Hongbin<br>
> <br>
> <br>
> ______________________________________________________________________<br>
> ____ OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <br>
> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Thu, 11 Feb 2016 18:51:03 +0200<br>
From: Shoham Peller <shoham.peller@stratoscale.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: [openstack-dev] [nova] Updating a volume attachment<br>
Message-ID:<br>
<CACKFtusThtMUi2_RAETwRjXGtH0-t4=56u2yS9uE3ZMTWkTVxQ@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
Currently there is no way to update the volume-attachment bdm parameters,<br>
i.e. the bus type or device name, without detaching and re-attaching the<br>
volume, and supplying the new parameters. This is obviously not ideal,
and<br>
if the volume we want to update is the boot volume, detaching to update
the<br>
bdm, is not even possible.<br>
<br>
I want to send a spec proposition to allow updating those attachment<br>
parameters, while the server is shutoff of course.<br>
<br>
A question is what do you think is the right API for this request.<br>
My first thought is to expand the "os-volume_attachments" API
and to add a<br>
PUT method which will get new bdm parameters. Problem is the POST method<br>
doesn't get all the parameters in a bdm - only a device_name.<br>
<br>
The options I can think off are:<br>
1. Add to the POST and to the PUT "os-volume_attachments" methods,
in the<br>
volumeAttachment dict all the parameters from the bdm that we want the
user<br>
to be able to update - probably just device_type and bus_type (device_name<br>
is already present). They will be optional of course, for<br>
backward-compatibility.<br>
2. Instead of expanding the "os-volume_attachments" API, expand
the other<br>
way to attach a volume - through a server "attach" action request.
We can<br>
add another action - "attachUpdate", which will get the same
parameters as<br>
the volume-attach, including the bdm parameters, and with that the user
can<br>
update the bdm.<br>
<br>
What do you think about the proposal and about the API dilemma?<br>
<br>
Thanks,<br>
Shoham<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/9f0e7166/attachment-0001.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/9f0e7166/attachment-0001.html</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 18<br>
Date: Thu, 11 Feb 2016 17:04:42 +0000<br>
From: Andrea Rosa <andrea.rosa@hpe.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [nova] Updating a volume attachment<br>
Message-ID: <56BCBF2A.3080908@hpe.com><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
Hi<br>
<br>
On 11/02/16 16:51, Shoham Peller wrote:<br>
> if the volume we want to update is the boot<br>
> volume, detaching to update the bdm, is not even possible.<br>
<br>
You might be interested in the approved spec [1] we have for Mitaka<br>
(ref. detach boot volume).<br>
Unfortunately the spec was not part of the high-priority list and it<br>
didn't get implemented but we are going to propose it again for Newton.<br>
<br>
Regards<br>
--<br>
Andrea Rosa<br>
<br>
[1]<br>
</font></tt><a href="http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/detach-boot-volume.html"><tt><font size=2>http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/detach-boot-volume.html</font></tt></a><tt><font size=2><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 19<br>
Date: Thu, 11 Feb 2016 09:04:10 -0800<br>
From: "Armando M." <armamig@gmail.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [neutron] [ipam] Migration to pluggable<br>
IPAM<br>
Message-ID:<br>
<CAK+RQeZ+2OSeRKJWznHsG8dVifD=hrNDSWf4nzG5x9NFC6tD0A@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On 10 February 2016 at 15:19, Carl Baldwin <carl@ecbaldwin.net> wrote:<br>
<br>
> On Thu, Feb 4, 2016 at 8:12 PM, Armando M. <armamig@gmail.com>
wrote:<br>
> > Technically we can make this as sophisticated and seamless as
we want,<br>
> but<br>
> > this is a one-off, once it's done the pain goes away, and we
won't be<br>
> doing<br>
> > another migration like this ever again. So I wouldn't over engineer
it.<br>
><br>
> Frankly, I was worried that going the other way was over-engineering<br>
> it. It will be more difficult for us to manage this transition.<br>
><br>
> I'm still struggling to see what makes this particular migration<br>
> different than other cases where we change the database schema and
the<br>
> code a bit and we automatically migrate everyone to it as part of
the<br>
> routine migration. What is it about this case that necessitates<br>
> giving the operator the option?<br>
><br>
<br>
I believe we have more recovery options out a potentially fatal situation.<br>
In fact the offline script can provide a dry-run option that can just<br>
validate that the migration will succeed before it is even actually<br>
performed; I think that the size and the amount of tables involved in the<br>
data migration justifies this course of action rather than the other. Think<br>
about what Sean said, bugs are always lurking in the dark and as much as
we<br>
can strive for correctness, things might go bad. This is not a routine<br>
migration and some operators may not be in a rush to embrace pluggable<br>
IPAM, hence I don't think we are in the position to make the decision on<br>
their behalf and go through the usual fast-path deprecation process.<br>
<br>
<br>
><br>
> Carl<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/be3c9d9f/attachment-0001.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/be3c9d9f/attachment-0001.html</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 20<br>
Date: Thu, 11 Feb 2016 09:04:47 -0800<br>
From: "Armando M." <armamig@gmail.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [neutron] [ipam] Migration to pluggable<br>
IPAM<br>
Message-ID:<br>
<CAK+RQeayK7mRarVwj114Djb16T4zpKxH19YYeC2cLFztWA4HQQ@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On 11 February 2016 at 07:01, John Belamaric <jbelamaric@infoblox.com><br>
wrote:<br>
<br>
><br>
><br>
> ---<br>
> John Belamaric<br>
> (240) 383-6963<br>
><br>
> > On Feb 11, 2016, at 5:37 AM, Ihar Hrachyshka <ihrachys@redhat.com><br>
> wrote:<br>
> ><br>
> > What?s the user visible change in behaviour after the switch?
If it?s<br>
> only internal implementation change, I don?t see why we want to leave
the<br>
> choice to operators.<br>
> ><br>
><br>
> It is only internal implementation changes.<br>
><br>
<br>
That's not entirely true, is it? There are config variables to change and<br>
it opens up the possibility of a scenario that the operator may not care<br>
about.<br>
<br>
<br>
><br>
><br>
> >> The other aspect is the deprecation process. If you add the
switch into<br>
> the DB migration path then the whole deprecation becomes superseded
as the<br>
> old IPAM logic should be abandoned immediately after that. But perhaps
the<br>
> other way of looking at it is that we should make an exception in
the<br>
> deprecation process.<br>
> >><br>
> >> Salvatore<br>
> >><br>
> >> On 11 February 2016 at 00:19, Carl Baldwin <carl@ecbaldwin.net>
wrote:<br>
> >> On Thu, Feb 4, 2016 at 8:12 PM, Armando M. <armamig@gmail.com>
wrote:<br>
> >> > Technically we can make this as sophisticated and seamless
as we<br>
> want, but<br>
> >> > this is a one-off, once it's done the pain goes away,
and we won't be<br>
> doing<br>
> >> > another migration like this ever again. So I wouldn't
over engineer<br>
> it.<br>
> >><br>
> >> Frankly, I was worried that going the other way was over-engineering<br>
> >> it. It will be more difficult for us to manage this
transition.<br>
> >><br>
> >> I'm still struggling to see what makes this particular migration<br>
> >> different than other cases where we change the database schema
and the<br>
> >> code a bit and we automatically migrate everyone to it as
part of the<br>
> >> routine migration. What is it about this case that
necessitates<br>
> >> giving the operator the option?<br>
> >><br>
> >> Carl<br>
> >><br>
> >><br>
> __________________________________________________________________________<br>
> >> OpenStack Development Mailing List (not for usage questions)<br>
> >> Unsubscribe:<br>
> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> >> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> >><br>
> >><br>
> __________________________________________________________________________<br>
> >> OpenStack Development Mailing List (not for usage questions)<br>
> >> Unsubscribe:<br>
> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> >> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> ><br>
> ><br>
> ><br>
> __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe:<br>
> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/9ab83cef/attachment-0001.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/9ab83cef/attachment-0001.html</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 21<br>
Date: Thu, 11 Feb 2016 19:20:27 +0200<br>
From: Shoham Peller <shoham.peller@stratoscale.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [nova] Updating a volume attachment<br>
Message-ID:<br>
<CACKFtuvbFA4pD2-YjEeOM5yYh5gnyYjrduKZXB4hsZEJ8gda_Q@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Thank you Andrea for your reply.<br>
<br>
I know this spec and it is indeed a viable solution.<br>
However, I think allowing users to update the attachment detail, rather<br>
than detach and re-attach a volume for every change is more robust and
more<br>
convenient.<br>
<br>
Also, IMHO it's a better user-experience if users can use a single API
call<br>
instead of detach API call, poll for the detachment, re-attach the volume,<br>
and poll again for the attachment if they want to powerup the VM.<br>
The bdm DB updating, can happen from nova-api, without IRC'ing a compute<br>
node, and thus return only when the request has been completed fully.<br>
<br>
Don't you agree it's needed, even when detaching a boot volume is possible?<br>
<br>
Shoham<br>
<br>
On Thu, Feb 11, 2016 at 7:04 PM, Andrea Rosa <andrea.rosa@hpe.com>
wrote:<br>
><br>
> Hi<br>
><br>
> On 11/02/16 16:51, Shoham Peller wrote:<br>
> > if the volume we want to update is the boot<br>
> > volume, detaching to update the bdm, is not even possible.<br>
><br>
> You might be interested in the approved spec [1] we have for Mitaka<br>
> (ref. detach boot volume).<br>
> Unfortunately the spec was not part of the high-priority list and
it<br>
> didn't get implemented but we are going to propose it again for Newton.<br>
><br>
> Regards<br>
> --<br>
> Andrea Rosa<br>
><br>
> [1]<br>
><br>
</font></tt><a href="http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/detach-boot-volume.html"><tt><font size=2>http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/detach-boot-volume.html</font></tt></a><tt><font size=2><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/032e4de7/attachment-0001.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/032e4de7/attachment-0001.html</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 22<br>
Date: Thu, 11 Feb 2016 09:31:29 -0800<br>
From: "Walter A. Boring IV" <walter.boring@hpe.com><br>
To: openstack-dev@lists.openstack.org<br>
Subject: Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining<br>
when to call os-brick's connector.disconnect_volume<br>
Message-ID: <56BCC571.1010102@hpe.com><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
There seems to be a few discussions going on here wrt to detaches.
One <br>
is what to do on the Nova side with calling os-brick's <br>
disconnect_volume, and also when to or not to call Cinder's <br>
terminate_connection and detach.<br>
<br>
My original post was simply to discuss a mechanism to try and figure out
<br>
the first problem. When should nova call brick to remove<br>
the local volume, prior to calling Cinder to do something.<br>
<br>
Nova needs to know if it's safe to call disconnect_volume or not. Cinder
<br>
already tracks each attachment, and it can return the connection_info <br>
for each attachment with a call to initialize_connection. If 2 of
<br>
those connection_info dicts are the same, it's a shared volume/target.
<br>
Don't call disconnect_volume if there are any more of those left.<br>
<br>
On the Cinder side of things, if terminate_connection, detach is called,
<br>
the volume manager can find the list of attachments for a volume, and <br>
compare that to the attachments on a host. The problem is, Cinder
<br>
doesn't track the host along with the instance_uuid in the attachments
<br>
table. I plan on allowing that as an API change after microversions
<br>
lands, so we know how many times a volume is attached/used on a <br>
particular host. The driver can decide what to do with it at <br>
terminate_connection, detach time. This helps account for<br>
the differences in each of the Cinder backends, which we will never get
<br>
all aligned to the same model. Each array/backend handles attachments
<br>
different and only the driver knows if it's safe to remove the target or
<br>
not, depending on how many attachments/usages it has<br>
on the host itself. This is the same thing as a reference counter,
<br>
which we don't need, because we have the count in the attachments table,
<br>
once we allow setting the host and the instance_uuid at the same time.<br>
<br>
Walt<br>
> On Tue, Feb 09, 2016 at 11:49:33AM -0800, Walter A. Boring IV wrote:<br>
>> Hey folks,<br>
>> One of the challenges we have faced with the ability
to attach a single<br>
>> volume to multiple instances, is how to correctly detach that
volume. The<br>
>> issue is a bit complex, but I'll try and explain the problem,
and then<br>
>> describe one approach to solving one part of the detach puzzle.<br>
>><br>
>> Problem:<br>
>> When a volume is attached to multiple instances on
the same host. There<br>
>> are 2 scenarios here.<br>
>><br>
>> 1) Some Cinder drivers export a new target for every
attachment on a<br>
>> compute host. This means that you will get a new unique
volume path on a<br>
>> host, which is then handed off to the VM instance.<br>
>><br>
>> 2) Other Cinder drivers export a single target for
all instances on a<br>
>> compute host. This means that every instance on a single
host, will reuse<br>
>> the same host volume path.<br>
><br>
> This problem isn't actually new. It is a problem we already have in
Nova<br>
> even with single attachments per volume. eg, with NFS and SMBFS
there<br>
> is a single mount setup on the host, which can serve up multiple volumes.<br>
> We have to avoid unmounting that until no VM is using any volume provided<br>
> by that mount point. Except we pretend the problem doesn't exist and
just<br>
> try to unmount every single time a VM stops, and rely on the kernel<br>
> failing umout() with EBUSY. Except this has a race condition
if one VM<br>
> is stopping right as another VM is starting<br>
><br>
> There is a patch up to try to solve this for SMBFS:<br>
><br>
> </font></tt><a href=https://review.openstack.org/#/c/187619/><tt><font size=2>https://review.openstack.org/#/c/187619/</font></tt></a><tt><font size=2><br>
><br>
> but I don't really much like it, because it only solves it for one<br>
> driver.<br>
><br>
> I think we need a general solution that solves the problem for all<br>
> cases, including multi-attach.<br>
><br>
> AFAICT, the only real answer here is to have nova record more info<br>
> about volume attachments, so it can reliably decide when it is safe<br>
> to release a connection on the host.<br>
><br>
><br>
>> Proposed solution:<br>
>> Nova needs to determine if the volume that's being
detached is a shared or<br>
>> non shared volume. Here is one way to determine that.<br>
>><br>
>> Every Cinder volume has a list of it's attachments.
In those attachments<br>
>> it contains the instance_uuid that the volume is attached to.
I presume<br>
>> Nova can find which of the volume attachments are on the same
host. Then<br>
>> Nova can call Cinder's initialize_connection for each of those
attachments<br>
>> to get the target's connection_info dictionary. This connection_info<br>
>> dictionary describes how to connect to the target on the cinder
backend. If<br>
>> the target is shared, then each of the connection_info dicts for
each<br>
>> attachment on that host will be identical. Then Nova would
know that it's a<br>
>> shared target, and then only call os-brick's disconnect_volume,
if it's the<br>
>> last attachment on that host. I think at most 2 calls to
cinder's<br>
>> initialize_connection would suffice to determine if the volume
is a shared<br>
>> target. This would only need to be done if the volume is
multi-attach<br>
>> capable and if there are more than 1 attachments on the same host,
where the<br>
>> detach is happening.<br>
> As above, we need to solve this more generally than just multi-attach,<br>
> even single-attach is flawed today.<br>
><br>
> Regards,<br>
> Daniel<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 23<br>
Date: Thu, 11 Feb 2016 09:59:36 -0800<br>
From: Clint Byrum <clint@fewbar.com><br>
To: openstack-dev <openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [infra] [trove] gate jobs failing with<br>
ovh apt
mirrors<br>
Message-ID: <1455213419-sup-4364@fewbar.com><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Excerpts from Craig Vyvial's message of 2016-02-11 07:43:40 -0800:<br>
> Jeremy,<br>
> <br>
> Thanks for looking at this. That makes sense but I'm not sure how
to<br>
> resolve this issue with the current diskimage-builder elements. If
anyone<br>
> has ideas it would be greatly appreciated.<br>
> <br>
<br>
Any job using these images and sources lists will need to add in the<br>
'apt-conf' element, and set DIB_APT_CONF=/etc/apt/apt.conf<br>
<br>
> Thanks,<br>
> -Craig Vyvial<br>
> <br>
> On Thu, Feb 11, 2016 at 8:44 AM Jeremy Stanley <fungi@yuggoth.org>
wrote:</font></tt>
<br><tt><font size=2>> <br>
> > On 2016-02-11 07:00:01 +0000 (+0000), Craig Vyvial wrote:<br>
> > > I started noticing more of the Trove gate jobs failing in
the last 24<br>
> > hours<br>
> > > and I think i've tracked it down to this mirror specifically.<br>
> > > </font></tt><a href=http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/main/p/><tt><font size=2>http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/main/p/</font></tt></a><tt><font size=2><br>
> > > It looks like its missing the python-software-properties
package and<br>
> > > causing our gate job to fail.<br>
> > [...]<br>
> ><br>
> > I think you're looking for this:<br>
> ><br>
> ><br>
> > </font></tt><a href="http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/universe/s/software-properties/"><tt><font size=2>http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/universe/s/software-properties/</font></tt></a><tt><font size=2><br>
> ><br>
> > ><br>
> > </font></tt><a href="http://logs.openstack.org/50/278050/1/check/gate-trove-functional-dsvm-mysql/e70f5c0/logs/devstack-gate-post_test_hook.txt.gz#_2016-02-11_05_12_01_023"><tt><font size=2>http://logs.openstack.org/50/278050/1/check/gate-trove-functional-dsvm-mysql/e70f5c0/logs/devstack-gate-post_test_hook.txt.gz#_2016-02-11_05_12_01_023</font></tt></a><tt><font size=2><br>
> > [...]<br>
> ><br>
> > The error there implies that diskimage-builder invocation in
your<br>
> > job is reusing the host's apt sources but not its apt configuration,<br>
> > and so is expecting the packages on the mirrors to be secure-apt<br>
> > signed by a trusted key.<br>
> > --<br>
> > Jeremy Stanley<br>
> ><br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> ><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 24<br>
Date: Thu, 11 Feb 2016 13:25:58 -0500<br>
From: Doug Hellmann <doug@doughellmann.com><br>
To: openstack-dev <openstack-dev@lists.openstack.org><br>
Subject: [openstack-dev] [release] Release countdown for week R-7, Feb<br>
15-19<br>
Message-ID: <1455215085-sup-8769@lrrr.local><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Focus<br>
-----<br>
<br>
We have 1 more week before the final releases for non-client libraries<br>
for this cycle, and 2 weeks before the final releases for client<br>
libraries. Project teams should be focusing on wrapping up new<br>
feature work in all libraries.<br>
<br>
We have 2 more weeks before the Mitaka-3 milestone and overall<br>
feature freeze.<br>
<br>
Release Actions<br>
---------------<br>
<br>
We will be more strictly enforcing the library release freeze before<br>
M3 in 2 weeks. Please review client libraries, integration libraries,<br>
and any other libraries managed by your team and ensure that recent<br>
changes have been released and the global requirements and constraints<br>
lists are up to date with accurate minimum versions and exclusions.<br>
<br>
Projects using the cycle-with-intermediary release model need to<br>
produce intermediate releases, if you are going to have one this<br>
cycle. See Thierry's email for details [1].<br>
<br>
Liaisons should be familiar with the final release process, documented<br>
in Thierry's email [1]. We have some time to respond to questions<br>
before we get into the crush of actually preparing the release, so<br>
please post follow-ups on the mailing list if you have them.<br>
<br>
Review your stable/liberty branches for necessary releases and<br>
submit patches to openstack/releases if you want them.<br>
<br>
[1] </font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/2016-February/086152.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/2016-February/086152.html</font></tt></a><tt><font size=2><br>
<br>
Important Dates<br>
---------------<br>
<br>
Final release for non-client libraries: Feb 24<br>
Final release for client libraries: Mar 2<br>
Mitaka 3: Feb 29-Mar 4 (includes feature freeze and soft string freeze)<br>
<br>
Mitaka release schedule:<br>
</font></tt><a href=http://docs.openstack.org/releases/schedules/mitaka.html><tt><font size=2>http://docs.openstack.org/releases/schedules/mitaka.html</font></tt></a><tt><font size=2><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 25<br>
Date: Thu, 11 Feb 2016 21:35:12 +0300<br>
From: Ilya Kutukov <ikutukov@mirantis.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [Fuel][Plugins] Multi release packages<br>
Message-ID:<br>
<CABizYvT1L=hKWwun6Z5skHgrZw3sbQ-fWqkYXrCnCLw4=qQg0g@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
My opinion that i've seen no example of multiple software of plugins<br>
versions shipped in one package or other form of bundle. Its not a common<br>
practice.<br>
<br>
Anyway we need to provide ability to override paths in manifest<br>
(metadata.yaml).<br>
<br>
So the plugin developers could use this approaches to provide multiple<br>
versions support:<br>
<br>
* tasks logic (do the plugin developers have access to current release<br>
info?)<br>
* hooks in pre-build process. Its not a big deal to preprocess source<br>
folder to build different packages with scripts that adding or removing<br>
some files or replacing some paths.<br>
* and, perhaps, logic anchors with YACL or other DSL in tasks dependancies<br>
if this functionality will be added this in theory could allow to use or<br>
not to use some graph parts depending on release.<br>
<br>
I think its already better than nothing and more flexible than any<br>
standardised approach.<br>
<br>
On Thu, Feb 11, 2016 at 6:31 PM, Simon Pasquier <spasquier@mirantis.com><br>
wrote:<br>
<br>
> Hi,<br>
><br>
> On Thu, Feb 11, 2016 at 11:46 AM, Igor Kalnitsky <ikalnitsky@mirantis.com><br>
> wrote:<br>
><br>
>> Hey folks,<br>
>><br>
>> The original idea is to provide a way to build plugin that are<br>
>> compatible with few releases. It makes sense to me, cause it looks<br>
>> awful if you need to maintain different branches for different
Fuel<br>
>> releases and there's no difference in the sources. In that case,
each<br>
>> bugfix to deployment scripts requires:<br>
>><br>
>> * backport bugfix to other branches (N backports)<br>
>> * build new packages for supported releases (N builds)<br>
>> * release new packages (N releases)<br>
>><br>
>> It's somehow.. annoying.<br>
>><br>
><br>
> A big +1 on Igor's remark. I've already expressed it in another thread
but<br>
> it should be expected that plugin developers want to support 2 consecutive<br>
> versions of Fuel for a given version of their plugin.<br>
> That being said, I've never had issues to do it with the current plugin<br>
> framework. Except when Fuel breaks the backward compatibility but
it's<br>
> another story...<br>
><br>
> Simon<br>
><br>
><br>
>><br>
>> However, I starting agree that having all-in-one RPM when deployment<br>
>> scripts are different, tasks are different, roles/volumes are<br>
>> different, probably isn't a good idea. It basically means that
your<br>
>> sources are completely different, and that means you have different<br>
>> implementations of the same plugin. In that case, in order to
avoid<br>
>> mess in source tree, it'd be better to separate such implementations<br>
>> on VCS level.<br>
>><br>
>> But I'd like to hear more opinion from plugin developers.<br>
>><br>
>> - Igor<br>
>><br>
>> On Thu, Feb 11, 2016 at 9:16 AM, Bulat Gaifullin<br>
>> <bgaifullin@mirantis.com> wrote:<br>
>> > I agree with Stas, one rpm - one version.<br>
>> ><br>
>> > But plugin builder allows to specify several releases as
compatible. The<br>
>> > deployment tasks and repositories can be specified per release,
at the<br>
>> same<br>
>> > time the deployment graph is one for all releases.<br>
>> > Currently it looks like half-implemented feature. Can
we drop this<br>
>> feature?<br>
>> > or should we finish implementation of this feature.<br>
>> ><br>
>> ><br>
>> > Regards,<br>
>> > Bulat Gaifullin<br>
>> > Mirantis Inc.<br>
>> ><br>
>> ><br>
>> ><br>
>> > On 11 Feb 2016, at 02:41, Andrew Woodward <xarses@gmail.com>
wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko <<br>
>> dborodaenko@mirantis.com><br>
>> > wrote:<br>
>> >><br>
>> >> +1 to Stas, supplanting VCS branches with code duplication
is a path to<br>
>> >> madness and despair. The dubious benefits of a cross-release
backwards<br>
>> >> compatible plugin binary are not worth the code and infra
technical<br>
>> debt<br>
>> >> that such approach would accrue over time.<br>
>> ><br>
>> ><br>
>> > Supporting multiple fuel releases will likely result in madness
as<br>
>> > discussed, however as we look to support multiple OpenStack
releases<br>
>> from<br>
>> > the same version of fuel, this methodology becomes much more
important.<br>
>> ><br>
>> >><br>
>> >> On Wed, Feb 10, 2016 at 07:36:30PM +0300, Stanislaw Bogatkin
wrote:<br>
>> >> > It changes mostly nothing for case of furious plugin
development when<br>
>> >> > big<br>
>> >> > parts of code changed from one release to another.<br>
>> >> ><br>
>> >> > You will have 6 different deployment_tasks directories
and 30 a<br>
>> little<br>
>> >> > bit<br>
>> >> > different files in root directory of plugin. Also
you forgot about<br>
>> >> > repositories directory (+6 at least), pre_build
hooks (also 6) and so<br>
>> >> > on.<br>
>> >> > It will look as hell after just 3 years of development.<br>
>> >> ><br>
>> >> > Also I can't imagine how to deal with plugin licensing
if you have<br>
>> >> > Apache<br>
>> >> > for liberty but BSD for mitaka release, for example.<br>
>> >> ><br>
>> >> > Much easier way to develop a plugin is to keep it's
source in VCS<br>
>> like<br>
>> >> > Git<br>
>> >> > and just make a branches for every fuel release.
It will give us<br>
>> >> > opportunity to not store a bunch of similar but
a little bit<br>
>> different<br>
>> >> > files in repo. There is no reason to drag all different
versions of<br>
>> code<br>
>> >> > for specific release.<br>
>> >> ><br>
>> >> ><br>
>> >> > On other hand there is a pros - your plugin can
survive after<br>
>> upgrade if<br>
>> >> > it<br>
>> >> > supports new release, no changes needed here.<br>
>> >> ><br>
>> >> > On Wed, Feb 10, 2016 at 4:04 PM, Alexey Shtokolov<br>
>> >> > <ashtokolov@mirantis.com><br>
>> >> > wrote:<br>
>> >> ><br>
>> >> > > Fuelers,<br>
>> >> > ><br>
>> >> > > We are discussing the idea to extend the multi
release packages for<br>
>> >> > > plugins.<br>
>> >> > ><br>
>> >> > > Fuel plugin builder (FPB) can create one rpm-package
for all<br>
>> supported<br>
>> >> > > releases (from metadata.yaml) but we can specify
only deployment<br>
>> >> > > scripts<br>
>> >> > > and repositories per release.<br>
>> >> > ><br>
>> >> > > Current release definition (in metadata.yaml):<br>
>> >> > > - os: ubuntu<br>
>> >> > > version: liberty-8.0<br>
>> >> > > mode: ['ha']<br>
>> >> > > deployment_scripts_path:
deployment_scripts/<br>
>> >> > > repository_path: repositories/ubuntu<br>
>> >> > ><br>
>> ><br>
>> ><br>
>> > This will result in far too much clutter.<br>
>> > For starters we should support nested over rides. for example
the<br>
>> author may<br>
>> > have already taken account for the changes between one openstack<br>
>> version to<br>
>> > another. In this case they only should need to define the
releases they<br>
>> > support and not specify any additional locations. Later they
may<br>
>> determine<br>
>> > that they only need to replace packages, or one other file
they should<br>
>> not<br>
>> > be required to code every location for each release<br>
>> ><br>
>> > Also, at the same time we MUST clean up importing various
yaml files.<br>
>> > Specifically, tasks, volumes, node roles, and network roles.
Requiring<br>
>> that<br>
>> > they all be maintained in a single file doesn't scale, we
don't require<br>
>> it<br>
>> > for tasks.yaml in fuel library, and we should not require
it in<br>
>> plugins. We<br>
>> > should simply do the same thing as tasks.yaml in library,
scan the<br>
>> subtree<br>
>> > for specific file names and just merge them all together.
(This has been<br>
>> > expressed multiple times by people with larger plugins)<br>
>> ><br>
>> >> > > So the idea [0] is to make releases fully configurable.<br>
>> >> > > Suggested changes for release definition (in
metadata.yaml):<br>
>> >> > > components_path: components_liberty.yaml<br>
>> >> > > deployment_tasks_path:
deployment_tasks_liberty/ # <- folder<br>
>> >><br>
>> >> > > environment_config_path:
environment_config_liberty.yaml<br>
>> >> > > network_roles_path: network_roles_liberty.yaml<br>
>> >> > > node_roles_path: node_roles_liberty.yaml<br>
>> >> > > volumes_path: volumes_liberty.yaml<br>
>> >> > ><br>
>> >> > > I see the issue: if we change anything for
one release (e.g.<br>
>> >> > > deployment_task typo) revalidation is needed
for all releases.<br>
>> >> > ><br>
>> >> > > Your Pros and cons please?<br>
>> >> > ><br>
>> >> > > [0] </font></tt><a href=https://review.openstack.org/#/c/271417/><tt><font size=2>https://review.openstack.org/#/c/271417/</font></tt></a><tt><font size=2><br>
>> >> > > ---<br>
>> >> > > WBR, Alexey Shtokolov<br>
>> >> > ><br>
>> >> > ><br>
>> >> > ><br>
>> __________________________________________________________________________<br>
>> >> > > OpenStack Development Mailing List (not for
usage questions)<br>
>> >> > > Unsubscribe:<br>
>> >> > > OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>> >> > > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>> >> > ><br>
>> >> > ><br>
>> >> ><br>
>> >> ><br>
>> >> > --<br>
>> >> > with best regards,<br>
>> >> > Stan.<br>
>> >><br>
>> >> ><br>
>> >> ><br>
>> __________________________________________________________________________<br>
>> >> > OpenStack Development Mailing List (not for usage
questions)<br>
>> >> > Unsubscribe:<br>
>> >> > OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>> >> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>> >><br>
>> >><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> Unsubscribe:<br>
>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>> >> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>> ><br>
>> > --<br>
>> ><br>
>> > --<br>
>> ><br>
>> > Andrew Woodward<br>
>> ><br>
>> > Mirantis<br>
>> ><br>
>> > Fuel Community Ambassador<br>
>> ><br>
>> > Ceph Community<br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>> ><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/bf72876a/attachment-0001.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/bf72876a/attachment-0001.html</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 26<br>
Date: Thu, 11 Feb 2016 21:53:27 +0300<br>
From: Ilya Kutukov <ikutukov@mirantis.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [Fuel][Plugins] Multi release packages<br>
Message-ID:<br>
<CABizYvQSNzhb1qiCCYbU1ZQbtfss7iTw29g50LpOrT3fQ+A-MQ@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
r/YACL/YAQL/<br>
<br>
On Thu, Feb 11, 2016 at 9:35 PM, Ilya Kutukov <ikutukov@mirantis.com>
wrote:<br>
<br>
> My opinion that i've seen no example of multiple software of plugins<br>
> versions shipped in one package or other form of bundle. Its not a
common<br>
> practice.<br>
><br>
> Anyway we need to provide ability to override paths in manifest<br>
> (metadata.yaml).<br>
><br>
> So the plugin developers could use this approaches to provide multiple<br>
> versions support:<br>
><br>
> * tasks logic (do the plugin developers have access to current release<br>
> info?)<br>
> * hooks in pre-build process. Its not a big deal to preprocess source<br>
> folder to build different packages with scripts that adding or removing<br>
> some files or replacing some paths.<br>
> * and, perhaps, logic anchors with YACL or other DSL in tasks dependancies<br>
> if this functionality will be added this in theory could allow to
use or<br>
> not to use some graph parts depending on release.<br>
><br>
> I think its already better than nothing and more flexible than any<br>
> standardised approach.<br>
><br>
> On Thu, Feb 11, 2016 at 6:31 PM, Simon Pasquier <spasquier@mirantis.com><br>
> wrote:<br>
><br>
>> Hi,<br>
>><br>
>> On Thu, Feb 11, 2016 at 11:46 AM, Igor Kalnitsky <ikalnitsky@mirantis.com<br>
>> > wrote:<br>
>><br>
>>> Hey folks,<br>
>>><br>
>>> The original idea is to provide a way to build plugin that
are<br>
>>> compatible with few releases. It makes sense to me, cause
it looks<br>
>>> awful if you need to maintain different branches for different
Fuel<br>
>>> releases and there's no difference in the sources. In that
case, each<br>
>>> bugfix to deployment scripts requires:<br>
>>><br>
>>> * backport bugfix to other branches (N backports)<br>
>>> * build new packages for supported releases (N builds)<br>
>>> * release new packages (N releases)<br>
>>><br>
>>> It's somehow.. annoying.<br>
>>><br>
>><br>
>> A big +1 on Igor's remark. I've already expressed it in another
thread<br>
>> but it should be expected that plugin developers want to support
2<br>
>> consecutive versions of Fuel for a given version of their plugin.<br>
>> That being said, I've never had issues to do it with the current
plugin<br>
>> framework. Except when Fuel breaks the backward compatibility
but it's<br>
>> another story...<br>
>><br>
>> Simon<br>
>><br>
>><br>
>>><br>
>>> However, I starting agree that having all-in-one RPM when
deployment<br>
>>> scripts are different, tasks are different, roles/volumes
are<br>
>>> different, probably isn't a good idea. It basically means
that your<br>
>>> sources are completely different, and that means you have
different<br>
>>> implementations of the same plugin. In that case, in order
to avoid<br>
>>> mess in source tree, it'd be better to separate such implementations<br>
>>> on VCS level.<br>
>>><br>
>>> But I'd like to hear more opinion from plugin developers.<br>
>>><br>
>>> - Igor<br>
>>><br>
>>> On Thu, Feb 11, 2016 at 9:16 AM, Bulat Gaifullin<br>
>>> <bgaifullin@mirantis.com> wrote:<br>
>>> > I agree with Stas, one rpm - one version.<br>
>>> ><br>
>>> > But plugin builder allows to specify several releases
as compatible.<br>
>>> The<br>
>>> > deployment tasks and repositories can be specified per
release, at the<br>
>>> same<br>
>>> > time the deployment graph is one for all releases.<br>
>>> > Currently it looks like half-implemented feature. Can
we drop this<br>
>>> feature?<br>
>>> > or should we finish implementation of this feature.<br>
>>> ><br>
>>> ><br>
>>> > Regards,<br>
>>> > Bulat Gaifullin<br>
>>> > Mirantis Inc.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > On 11 Feb 2016, at 02:41, Andrew Woodward <xarses@gmail.com>
wrote:<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko <<br>
>>> dborodaenko@mirantis.com><br>
>>> > wrote:<br>
>>> >><br>
>>> >> +1 to Stas, supplanting VCS branches with code duplication
is a path<br>
>>> to<br>
>>> >> madness and despair. The dubious benefits of a cross-release
backwards<br>
>>> >> compatible plugin binary are not worth the code and
infra technical<br>
>>> debt<br>
>>> >> that such approach would accrue over time.<br>
>>> ><br>
>>> ><br>
>>> > Supporting multiple fuel releases will likely result
in madness as<br>
>>> > discussed, however as we look to support multiple OpenStack
releases<br>
>>> from<br>
>>> > the same version of fuel, this methodology becomes much
more important.<br>
>>> ><br>
>>> >><br>
>>> >> On Wed, Feb 10, 2016 at 07:36:30PM +0300, Stanislaw
Bogatkin wrote:<br>
>>> >> > It changes mostly nothing for case of furious
plugin development<br>
>>> when<br>
>>> >> > big<br>
>>> >> > parts of code changed from one release to another.<br>
>>> >> ><br>
>>> >> > You will have 6 different deployment_tasks directories
and 30 a<br>
>>> little<br>
>>> >> > bit<br>
>>> >> > different files in root directory of plugin.
Also you forgot about<br>
>>> >> > repositories directory (+6 at least), pre_build
hooks (also 6) and<br>
>>> so<br>
>>> >> > on.<br>
>>> >> > It will look as hell after just 3 years of development.<br>
>>> >> ><br>
>>> >> > Also I can't imagine how to deal with plugin
licensing if you have<br>
>>> >> > Apache<br>
>>> >> > for liberty but BSD for mitaka release, for
example.<br>
>>> >> ><br>
>>> >> > Much easier way to develop a plugin is to keep
it's source in VCS<br>
>>> like<br>
>>> >> > Git<br>
>>> >> > and just make a branches for every fuel release.
It will give us<br>
>>> >> > opportunity to not store a bunch of similar
but a little bit<br>
>>> different<br>
>>> >> > files in repo. There is no reason to drag all
different versions of<br>
>>> code<br>
>>> >> > for specific release.<br>
>>> >> ><br>
>>> >> ><br>
>>> >> > On other hand there is a pros - your plugin
can survive after<br>
>>> upgrade if<br>
>>> >> > it<br>
>>> >> > supports new release, no changes needed here.<br>
>>> >> ><br>
>>> >> > On Wed, Feb 10, 2016 at 4:04 PM, Alexey Shtokolov<br>
>>> >> > <ashtokolov@mirantis.com><br>
>>> >> > wrote:<br>
>>> >> ><br>
>>> >> > > Fuelers,<br>
>>> >> > ><br>
>>> >> > > We are discussing the idea to extend the
multi release packages<br>
>>> for<br>
>>> >> > > plugins.<br>
>>> >> > ><br>
>>> >> > > Fuel plugin builder (FPB) can create one
rpm-package for all<br>
>>> supported<br>
>>> >> > > releases (from metadata.yaml) but we can
specify only deployment<br>
>>> >> > > scripts<br>
>>> >> > > and repositories per release.<br>
>>> >> > ><br>
>>> >> > > Current release definition (in metadata.yaml):<br>
>>> >> > > - os: ubuntu<br>
>>> >> > > version: liberty-8.0<br>
>>> >> > > mode: ['ha']<br>
>>> >> > > deployment_scripts_path:
deployment_scripts/<br>
>>> >> > > repository_path: repositories/ubuntu<br>
>>> >> > ><br>
>>> ><br>
>>> ><br>
>>> > This will result in far too much clutter.<br>
>>> > For starters we should support nested over rides. for
example the<br>
>>> author may<br>
>>> > have already taken account for the changes between one
openstack<br>
>>> version to<br>
>>> > another. In this case they only should need to define
the releases they<br>
>>> > support and not specify any additional locations. Later
they may<br>
>>> determine<br>
>>> > that they only need to replace packages, or one other
file they should<br>
>>> not<br>
>>> > be required to code every location for each release<br>
>>> ><br>
>>> > Also, at the same time we MUST clean up importing various
yaml files.<br>
>>> > Specifically, tasks, volumes, node roles, and network
roles. Requiring<br>
>>> that<br>
>>> > they all be maintained in a single file doesn't scale,
we don't<br>
>>> require it<br>
>>> > for tasks.yaml in fuel library, and we should not require
it in<br>
>>> plugins. We<br>
>>> > should simply do the same thing as tasks.yaml in library,
scan the<br>
>>> subtree<br>
>>> > for specific file names and just merge them all together.
(This has<br>
>>> been<br>
>>> > expressed multiple times by people with larger plugins)<br>
>>> ></font></tt>
<br><tt><font size=2>>>> >> > > So the idea [0] is
to make releases fully configurable.<br>
>>> >> > > Suggested changes for release definition
(in metadata.yaml):<br>
>>> >> > > components_path: components_liberty.yaml<br>
>>> >> > > deployment_tasks_path:
deployment_tasks_liberty/ # <- folder<br>
>>> >><br>
>>> >> > > environment_config_path:
environment_config_liberty.yaml<br>
>>> >> > > network_roles_path:
network_roles_liberty.yaml<br>
>>> >> > > node_roles_path: node_roles_liberty.yaml<br>
>>> >> > > volumes_path: volumes_liberty.yaml<br>
>>> >> > ><br>
>>> >> > > I see the issue: if we change anything
for one release (e.g.<br>
>>> >> > > deployment_task typo) revalidation is needed
for all releases.<br>
>>> >> > ><br>
>>> >> > > Your Pros and cons please?<br>
>>> >> > ><br>
>>> >> > > [0] </font></tt><a href=https://review.openstack.org/#/c/271417/><tt><font size=2>https://review.openstack.org/#/c/271417/</font></tt></a><tt><font size=2><br>
>>> >> > > ---<br>
>>> >> > > WBR, Alexey Shtokolov<br>
>>> >> > ><br>
>>> >> > ><br>
>>> >> > ><br>
>>> __________________________________________________________________________<br>
>>> >> > > OpenStack Development Mailing List (not
for usage questions)<br>
>>> >> > > Unsubscribe:<br>
>>> >> > > OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>>> >> > > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>> >> > ><br>
>>> >> > ><br>
>>> >> ><br>
>>> >> ><br>
>>> >> > --<br>
>>> >> > with best regards,<br>
>>> >> > Stan.<br>
>>> >><br>
>>> >> ><br>
>>> >> ><br>
>>> __________________________________________________________________________<br>
>>> >> > OpenStack Development Mailing List (not for
usage questions)<br>
>>> >> > Unsubscribe:<br>
>>> >> > OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>>> >> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> __________________________________________________________________________<br>
>>> >> OpenStack Development Mailing List (not for usage
questions)<br>
>>> >> Unsubscribe:<br>
>>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>>> >> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>> ><br>
>>> > --<br>
>>> ><br>
>>> > --<br>
>>> ><br>
>>> > Andrew Woodward<br>
>>> ><br>
>>> > Mirantis<br>
>>> ><br>
>>> > Fuel Community Ambassador<br>
>>> ><br>
>>> > Ceph Community<br>
>>> ><br>
>>> ><br>
>>> __________________________________________________________________________<br>
>>> > OpenStack Development Mailing List (not for usage questions)<br>
>>> > Unsubscribe:<br>
>>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>>> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> __________________________________________________________________________<br>
>>> > OpenStack Development Mailing List (not for usage questions)<br>
>>> > Unsubscribe:<br>
>>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>>> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>> ><br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>><br>
>><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/6d78f3b7/attachment-0001.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/6d78f3b7/attachment-0001.html</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 27<br>
Date: Thu, 11 Feb 2016 11:53:56 -0700<br>
From: Carl Baldwin <carl@ecbaldwin.net><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [neutron] [ipam] Migration to pluggable<br>
IPAM<br>
Message-ID:<br>
<CALiLy7qQ1kOzYFCmO_bhyMZ86OtuNFFQxnrGqDMWkF=sy-=RMw@mail.gmail.com><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Thu, Feb 11, 2016 at 3:20 AM, Salvatore Orlando<br>
<salv.orlando@gmail.com> wrote:<br>
> The difference lies in the process in my opinion.<br>
> If the switch is added into the migration path then we will tell operators<br>
> when to switch.<br>
> I was suggesting doing it manual because we just don't know if every<br>
> operator is happy about doing the switch when upgrading to Newton,
but<br>
> perhaps it is just me over-worrying about operator behaviour.<br>
<br>
I think this is the point that makes this discussion worth having. It<br>
does help me to hear you state this concern in this way. I'd like
to<br>
hear/read some other opinions.<br>
<br>
> The other aspect is the deprecation process. If you add the switch
into the<br>
> DB migration path then the whole deprecation becomes superseded as
the old<br>
> IPAM logic should be abandoned immediately after that. But perhaps
the other<br>
> way of looking at it is that we should make an exception in the deprecation<br>
> process.<br>
<br>
I agree. If we do decide that we force the switch then we should<br>
immediately abandon the old code. However, I don't this should drive<br>
the decision to do the switch with the migration.<br>
<br>
Carl<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 28<br>
Date: Thu, 11 Feb 2016 11:56:15 -0700<br>
From: Carl Baldwin <carl@ecbaldwin.net><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [neutron] [ipam] Migration to pluggable<br>
IPAM<br>
Message-ID:<br>
<CALiLy7p5JHrwZT+ZqZOJ8vK_HzZK7e0G1R94NqrJ7k1x7rwmrg@mail.gmail.com><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Thu, Feb 11, 2016 at 3:32 AM, Ihar Hrachyshka <ihrachys@redhat.com>
wrote:<br>
> Salvatore Orlando <salv.orlando@gmail.com> wrote:<br>
><br>
>> The difference lies in the process in my opinion.<br>
>> If the switch is added into the migration path then we will tell
operators<br>
>> when to switch.<br>
>> I was suggesting doing it manual because we just don't know if
every<br>
>> operator is happy about doing the switch when upgrading to Newton,
but<br>
>> perhaps it is just me over-worrying about operator behaviour.<br>
><br>
> What?s the user visible change in behaviour after the switch? If it?s
only<br>
> internal implementation change, I don?t see why we want to leave the
choice<br>
> to operators.<br>
<br>
This was my thinking exactly. However, I did not do the<br>
implementation, Salvatore did. So, ultimately, I think that he should<br>
be convinced that we're doing the right thing. I value his input<br>
highly.<br>
<br>
Carl<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 29<br>
Date: Thu, 11 Feb 2016 11:58:16 -0700<br>
From: Carl Baldwin <carl@ecbaldwin.net><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [neutron] [ipam] Migration to pluggable<br>
IPAM<br>
Message-ID:<br>
<CALiLy7reBzPtVbeCRXTP4cWb6g8Zj+gO_N8we_avj=8X6ZC3FA@mail.gmail.com><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Thu, Feb 11, 2016 at 10:04 AM, Armando M. <armamig@gmail.com>
wrote:<br>
> On 11 February 2016 at 07:01, John Belamaric <jbelamaric@infoblox.com><br>
> wrote:<br>
>> It is only internal implementation changes.<br>
><br>
> That's not entirely true, is it? There are config variables to change
and it<br>
> opens up the possibility of a scenario that the operator may not care
about.<br>
<br>
You're right. I was thinking that if we handled the switch then we<br>
could obsolete the config variable. Maybe we shot ourselves in the<br>
foot already by having the config option in the first place. Is that<br>
what you're thinking?<br>
<br>
Carl<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 30<br>
Date: Fri, 12 Feb 2016 00:44:41 +0530<br>
From: Monika Parkar <monikaparkar25@gmail.com><br>
To: openstack-dev@lists.openstack.org<br>
Subject: [openstack-dev] Multiple delete of network through CLI is not<br>
available as of now<br>
Message-ID:<br>
<CAJ7mFWn8yXXLywbiDGhXqNJfQxJz3u8eM3akBgAfDUaXUQj-oQ@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello,<br>
<br>
I am monika. new to the openstack community.Having working experience in<br>
Python. I was going through the the neutron use-cases I observed that we<br>
can delete multiple network at a time through the dashboard but the same
is<br>
not possible through the command line.<br>
<br>
But in the ironic component multiple delete feature is available through<br>
the command line.<br>
<br>
So may I propose this as a blueprint.<br>
<br>
Awaiting for your kind response/suggestion .<br>
<br>
Thanks & Regards<br>
Monika<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160212/1e6f21a9/attachment-0001.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160212/1e6f21a9/attachment-0001.html</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 31<br>
Date: Thu, 11 Feb 2016 19:17:39 +0000<br>
From: John Belamaric <jbelamaric@infoblox.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [neutron] [ipam] Migration to pluggable<br>
IPAM<br>
Message-ID: <69446D19-EB1A-4B4F-8A44-80B177560489@infoblox.com><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
<br>
On Feb 11, 2016, at 12:04 PM, Armando M. <armamig@gmail.com<</font></tt><a href=mailto:armamig@gmail.com><tt><font size=2>mailto:armamig@gmail.com</font></tt></a><tt><font size=2>>>
wrote:<br>
<br>
<br>
<br>
On 11 February 2016 at 07:01, John Belamaric <jbelamaric@infoblox.com<</font></tt><a href=mailto:jbelamaric@infoblox.com><tt><font size=2>mailto:jbelamaric@infoblox.com</font></tt></a><tt><font size=2>>>
wrote:<br>
<br>
<br>
<br>
It is only internal implementation changes.<br>
<br>
That's not entirely true, is it? There are config variables to change and
it opens up the possibility of a scenario that the operator may not care
about.<br>
<br>
<br>
If we were to remove the non-pluggable version altogether, then the default
for ipam_driver would switch from None to internal. Therefore, there would
be no config file changes needed.<br>
<br>
<br>
John<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/0d1dd02f/attachment-0001.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/0d1dd02f/attachment-0001.html</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 32<br>
Date: Thu, 11 Feb 2016 11:21:27 -0800<br>
From: Boris Pavlovic <boris@pavlovic.me><br>
To: OpenStack Development Mailing List<br>
<openstack-dev@lists.openstack.org><br>
Subject: [openstack-dev] [mitaka][hackathon] Mitaka Bug Smash<br>
Hackathon in Bay Area (March 7-9)<br>
Message-ID:<br>
<CAD85om2OPMieJ2waaFVzMvBeSDg64FQzQ3rsFq2YufS5bkrtnA@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi stackers,<br>
<br>
If you are in Bay Area and you would to work together with your friends<br>
from community on fixing non trivial bugs together, you have a great<br>
chance.<br>
<br>
There is going to be special event "Mitaka bug smash".<br>
Here is the full information:<br>
</font></tt><a href="https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka"><tt><font size=2>https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka</font></tt></a><tt><font size=2><br>
<br>
*If you would like to take a part and you are in Bay Area, please register<br>
here: *<br>
</font></tt><a href="https://www.eventbrite.com/e/global-openstack-bug-smash-bay-area-tickets-21241532997?utm_source=eb_email&utm_medium=email&utm_campaign=new_event_email&utm_term=viewmyevent_button"><tt><font size=2>https://www.eventbrite.com/e/global-openstack-bug-smash-bay-area-tickets-21241532997?utm_source=eb_email&utm_medium=email&utm_campaign=new_event_email&utm_term=viewmyevent_button</font></tt></a><tt><font size=2><br>
<br>
As well, please provide here info in which project you are interested:<br>
</font></tt><a href="https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka-BayArea"><tt><font size=2>https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka-BayArea</font></tt></a><tt><font size=2><br>
<br>
<br>
<br>
Best regards,<br>
Boris Pavlovic<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/1e709ca7/attachment-0001.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/1e709ca7/attachment-0001.html</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
Message: 33<br>
Date: Thu, 11 Feb 2016 15:24:04 -0500<br>
From: Jay Pipes <jaypipes@gmail.com><br>
To: OpenStack Development Mailing List<br>
<openstack-dev@lists.openstack.org><br>
Subject: [openstack-dev] [nova] Update on scheduler and resource<br>
tracker
progress<br>
Message-ID: <56BCEDE4.5020507@gmail.com><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Hello all,<br>
<br>
Performance working group, please pay attention to Chapter 2 in the <br>
details section.<br>
<br>
tl;dr<br>
-----<br>
<br>
At the Nova mid-cycle, we finalized decisions on a way forward in <br>
redesigning the way that resources are tracked in Nova. This work is a
<br>
major undertaking and has implications for splitting out the scheduler
<br>
from Nova, for the ability of the placement engine to scale, and for <br>
removing long-standing reporting and race condition bugs that have <br>
plagued Nova for years.<br>
<br>
The following blueprint specifications outline the effort, which we are
<br>
calling the "resource providers framework":<br>
<br>
* resource-classes (bp MERGED, code MERGED)<br>
* pci-generate-stats (bp MERGED, code IN REVIEW)<br>
* resource-providers (bp MERGED, code IN REVIEW)<br>
* generic-resource-pools (bp IN REVIEW, code TODO)<br>
* compute-node-inventory (bp IN REVIEW, code TODO)<br>
* resource-providers-allocations (bp IN REVIEW, code TODO)<br>
* resource-providers-scheduler (bp IN REVIEW, code TODO)<br>
<br>
The group working on this code and doing the reviews are hopeful that <br>
the generic-resource-pools work can be completed in Mitaka, and we also
<br>
are going to aim to get the compute-node-inventory work done in Mitaka,
<br>
though that will be more of a stretch.<br>
<br>
The remainder of the resource providers framework blueprints will be <br>
targeted to Newton. The resource-providers-scheduler blueprint is the <br>
final blueprint required before the scheduler can be fully separated <br>
from Nova.<br>
<br>
details<br>
-------<br>
<br>
Chapter 1 - How the blueprints fit together<br>
===========================================<br>
<br>
A request to launch an instance in Nova involves requests for two <br>
different things: *resources* and *capabilities*. Resources are the <br>
quantitative part of the request spec. Capabilities are the qualitative
<br>
part of the request.<br>
<br>
The *resource providers framework* is a set of 7 blueprints that <br>
reorganize the way that Nova handles the quantitative side of the <br>
equation. These 7 blueprints are described below.<br>
<br>
Compute nodes are a type of *resource provider*, since they allow <br>
instances to *consume* some portion of its *inventory* of various types
<br>
of resources. We call these types of resources *"resource classes"*.<br>
<br>
resource-classes bp: </font></tt><a href=https://review.openstack.org/256297><tt><font size=2>https://review.openstack.org/256297</font></tt></a><tt><font size=2><br>
<br>
The resource-providers blueprint introduces a new set of tables for <br>
storing capacity and usage amounts of all resources in the system:<br>
<br>
resource-providers bp: </font></tt><a href=https://review.openstack.org/225546><tt><font size=2>https://review.openstack.org/225546</font></tt></a><tt><font size=2><br>
<br>
While all compute nodes are resource providers [1], not all resource <br>
providers are compute nodes. *Generic resource pools* are resource <br>
providers that have an inventory of a *single resource class* and that
<br>
provide that resource class to consumers that are placed on multiple <br>
compute nodes.<br>
<br>
The canonical example of a generic resource pool is a shared storage <br>
system. Currently, a Nova compute node doesn't really know whether the
<br>
storage location it uses for storing disk images is a shared <br>
drive/cluster (ala NFS or RBD) or if the storage location is a local <br>
disk drive [2]. The generic-resource-pools blueprint covers the addition
<br>
of these generic resource pools, their relation to host aggregates, and
<br>
the RESTful API [3] added to control this external resource pool <br>
information.<br>
<br>
generic-resource-pools bp: </font></tt><a href=https://review.openstack.org/253187><tt><font size=2>https://review.openstack.org/253187</font></tt></a><tt><font size=2><br>
<br>
Within the Nova database schemas [4], capacity and inventory information
<br>
is stored in a variety of tables, columns and formats. vCPU, RAM and <br>
DISK capacity information is stored in integer fields, PCI capacity <br>
information is stored in the pci_devices table, NUMA inventory is stored
<br>
combined together with usage information in a JSON blob, etc. The <br>
compute-node-inventory blueprint migrates all of the disparate capacity
<br>
information from compute_nodes into the new inventory table.<br>
<br>
compute-node-inventory bp: </font></tt><a href=https://review.openstack.org/260048><tt><font size=2>https://review.openstack.org/260048</font></tt></a><tt><font size=2><br>
<br>
For the PCI resource classes, Nova currently has an entirely different
<br>
resource tracker (in /nova/pci/*) that stores an aggregate view of the
<br>
PCI resources (grouped by product, vendor, and numa node) in the <br>
compute_nodes.pci_stats field. This information is entirely redundant <br>
information since all fine-grained PCI resource information is stored in
<br>
the pci_devices table. This storage of summary information presents a <br>
sync problem. The pci-generate-stats blueprint describes the effort to
<br>
remove this storage of summary device pool information and instead <br>
generate this summary information on the fly for the scheduler. This <br>
work is a pre-requisite to having all resource classes managed in a <br>
unified manner in Nova:<br>
<br>
pci-generate-stats bp: </font></tt><a href=https://review.openstack.org/240852><tt><font size=2>https://review.openstack.org/240852</font></tt></a><tt><font size=2><br>
<br>
In the same way that capacity fields are scattered among different <br>
tables, columns and formats, so too are the fields that store usage <br>
information. Some fields are in the instances table, some in the <br>
instance_extra table, some information is derived from the pci_devices
<br>
table, other bits from a JSON blob field. In short, it's an inconsistent
<br>
mess. This mess means adding support for adding additional types of <br>
resources typically involves adding yet more inconsistency and <br>
conditional logic into the scheduler and nova-compute's resource <br>
tracker. The resource-providers-allocations blueprint involves work to
<br>
migrate all usage record information out of the disparate fields in the
<br>
current schema and into the allocations table introduced in the <br>
resource-providers blueprint:<br>
<br>
resource-providers-allocations bp: </font></tt><a href=https://review.openstack.org/271779><tt><font size=2>https://review.openstack.org/271779</font></tt></a><tt><font size=2><br>
<br>
Once all of the inventory (capacity) and allocation (usage) information
<br>
has been migrated to the database schema described in the <br>
resource-providers blueprint, Nova will be treating all types of <br>
resources in a generic fashion. The next step is to modify the scheduler
<br>
to take advantage of this new resource representation. The <br>
resource-providers-scheduler blueprint undertakes this important step:<br>
<br>
resource-providers-scheduler bp: </font></tt><a href=https://review.openstack.org/271823><tt><font size=2>https://review.openstack.org/271823</font></tt></a><tt><font size=2><br>
<br>
Chapter 2 - Addressing performance and scale<br>
============================================<br>
<br>
One of the significant performance problems with the Nova scheduler is
<br>
the fact that for every call to the select_destinations() RPC API method
<br>
-- which itself is called at least once every time a launch or migration
<br>
request is made -- the scheduler grabs all records for all compute nodes
<br>
in the deployment. Once retrieving all these compute node records, the
<br>
scheduler runs each through a set of filters to determine which compute
<br>
nodes have the required capacity to service the instance's requested <br>
resources. Having the scheduler continually retrieve every compute node
<br>
record on each request to select_destinations() is extremely <br>
inefficient. The greater the number of compute nodes, the bigger the <br>
performance and scale problem this becomes.<br>
<br>
On a loaded cloud deployment -- say there are 1000 compute nodes and 900
<br>
of them are fully loaded with active virtual machines -- the scheduler
<br>
is still going to retrieve all 1000 compute node records on every <br>
request to select_destinations() and process each one of those records
<br>
through all scheduler filters. Clearly, if we could filter the amount of
<br>
compute node records that are returned by removing those nodes that do
<br>
not have available capacity, we could dramatically reduce the amount of
<br>
work that each call to select_destinations() would need to perform.<br>
<br>
The resource-providers-scheduler blueprint attempts to address the above
<br>
problem by replacing a number of the scheduler filters that currently <br>
run *after* the database has returned all compute node records with <br>
instead a series of WHERE clauses and join conditions on the database <br>
query. The idea here is to winnow the number of returned compute node <br>
results as much as possible. The fewer records the scheduler must <br>
post-process, the faster the performance of each individual call to <br>
select_destinations().<br>
<br>
The second major scale problem with the current Nova scheduler design <br>
has to do with the fact that the scheduler does *not* actually claim <br>
resources on a provider. Instead, the scheduler selects a destination <br>
host to place the instance on and the Nova conductor then sends a <br>
message to that target host which attempts to spawn the instance on its
<br>
hypervisor. If the spawn succeeds, the target compute host updates the
<br>
Nova database and decrements its count of available resources. These <br>
steps (from nova-scheduler to nova-conductor to nova-compute to <br>
database) all take some not insignificant amount of time. During this <br>
time window, a different scheduler process may pick the exact same <br>
target host for a like-sized launch request. If there is only room on <br>
the target host for one of those size requests [5], one of those spawn
<br>
requests will fail and trigger a retry operation. This retry operation
<br>
will attempt to repeat the scheduler placement decisions (by calling <br>
select_destinations()).<br>
<br>
This retry operation is relatively expensive and needlessly so: if the
<br>
scheduler claimed the resources on the target host before sending its <br>
pick back to the scheduler, then the chances of producing a retry will
<br>
be almost eliminated [6]. The resource-providers-scheduler blueprint <br>
attempts to remedy this second scaling design problem by having the <br>
scheduler write records to the allocations table before sending the <br>
selected target host back to the Nova conductor.<br>
<br>
Conclusions<br>
===========<br>
<br>
Thanks if you've made it this far in this epic email. :) If you have <br>
questions about the plans, please do feel free to respond here or come
<br>
find us on Freenode #openstack-nova IRC. Your reviews and comments are
<br>
also very welcome on the specs and patches.<br>
<br>
Best,<br>
-jay<br>
<br>
[1] One might argue that nova-compute daemons that proxy for some other
<br>
resource manager like vCenter or Ironic are not actually resource <br>
providers, but just go with me on this one...<br>
<br>
[2] This results in a number of resource reporting bugs, including Nova
<br>
reporting that the deployment has X times as much disk capacity as it <br>
really does (where X is the number of compute nodes sharing the same <br>
storage location).<br>
<br>
[3] The RESTful API in the generic-resource-pools blueprint actually <br>
will be a completely new REST endpoint and service (/placement) that <br>
will be the start of the new extracted schd<br>
<br>
[4] Nova has two database schemas. The first is what is known as the <br>
Child Cell database and contains the majority of database tables. The <br>
second is known as the API database and contains global and top-level <br>
routing tables.<br>
<br>
[5] This situation is more common than you might originally think. Any
<br>
cloud that runs a pack-first placement strategy with multiple scheduler
<br>
daemon processes will suffer from this problem.<br>
<br>
[6] Technically, it cannot be eliminated because an out-of-band <br>
operation could theoretically occur (for example, an administrator could
<br>
manually -- not through Nova -- launch a virtual machine on the target
<br>
host) and therefore introduce some unaccounted-for amount of used <br>
resources for a small window of time in between the periodic interval by
<br>
which the nova-compute runs an audit task.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 34<br>
Date: Thu, 11 Feb 2016 20:26:10 +0000<br>
From: "Steven Dake (stdake)" <stdake@cisco.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [infra][keystone][kolla][bandit] linters<br>
jobs<br>
Message-ID: <D2E23BEA.1670F%stdake@cisco.com><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Andreas,<br>
<br>
Totally understand the overload problem with no short-term workarounds.
I<br>
think all engineering in OpenStack is over capacity a bit and folks are<br>
really burning the midnight oil to make sure Mitaka is the best release
of<br>
OpenStack yet!<br>
<br>
Please feel free to drop by #kolla and ping the core reviewers if you need<br>
any help getting this work reverted until the timing is better.<br>
<br>
Regards<br>
-steve<br>
<br>
<br>
On 2/11/16, 1:50 AM, "Andreas Jaeger" <aj@suse.com> wrote:<br>
<br>
>On 2016-02-11 02:50, Joshua Hesketh wrote:<br>
>> Hey Andreas,<br>
>> <br>
>> Why not keep pep8 as an alias for the new linters target? Would
this<br>
>> allow for a transition path while work on updating the PTI is
done?<br>
><br>
>pep8 and linters do different work in infra, and infra calls pep8.
A<br>
>project can have both...<br>
><br>
>It's more than updating PTI, it's also taking care that linters does
the<br>
>same tests as pep8 and then updating *all* projects...<br>
><br>
>Andreas<br>
><br>
>> Cheers,<br>
>> Josh<br>
>> <br>
>> On Thu, Feb 11, 2016 at 6:55 AM, Andreas Jaeger <aj@suse.com<br>
>> <</font></tt><a href=mailto:aj@suse.com><tt><font size=2>mailto:aj@suse.com</font></tt></a><tt><font size=2>>>
wrote:<br>
>> <br>
>> Hi,<br>
>> </font></tt>
<br><tt><font size=2>>> the pep8 target is our usual
target to include style and lint<br>
>>checks and<br>
>> thus is used besides pep8 also for doc8, bashate,
bandit, etc as<br>
>> documented in the PTI (=Python Test Interface,<br>
>> </font></tt><a href=http://governance.openstack.org/reference/cti/python_cti.html><tt><font size=2>http://governance.openstack.org/reference/cti/python_cti.html</font></tt></a><tt><font size=2>).<br>
>> <br>
>> We've had some discussions to introduce a new target
called linters<br>
>>as<br>
>> better name for this and when I mentioned this in
a few<br>
>>discussions, it<br>
>> resonated with these projects. Unfortunately, I
missed the<br>
>>relevance of<br>
>> the PTI for such a change - and changing the PTI
to replace pep8<br>
>>with<br>
>> linters and then pushing that one through to all
projects is more<br>
>>than I<br>
>> can commit to right now.<br>
>> <br>
>> I apologize for being a too eager and will send
patches for official<br>
>> projects moving them back to pep8, so consider this
is heads up and<br>
>> background about my incoming patches with topic
"pti-pep8-linters".<br>
>> <br>
>> If somebody else wants to do the whole conversion
in the future, I<br>
>>can<br>
>> give pointers on what to do,<br>
>> <br>
>> Andreas<br>
>> --<br>
>> Andreas Jaeger aj@{suse.com <</font></tt><a href=http://suse.com/><tt><font size=2>http://suse.com</font></tt></a><tt><font size=2>>,opensuse.org<br>
>> <</font></tt><a href=http://opensuse.org/><tt><font size=2>http://opensuse.org</font></tt></a><tt><font size=2>>}
Twitter/Identica: jaegerandi<br>
>> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg,
Germany<br>
>> GF: Felix Imend?rffer, Jane Smithard,
Graham Norton,<br>
>> HRB 21284 (AG N?rnberg)<br>
>> GPG fingerprint = 93A3 365E CE47 B889
DF7F FED1 389A 563C C272<br>
>>A126<br>
>> <br>
>> <br>
>> <br>
>>_________________________________________________________________________<br>
>>_<br>
>> OpenStack Development Mailing List (not for usage
questions)<br>
>> Unsubscribe:<br>
>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>> <br>
>><</font></tt><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"><tt><font size=2>http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</font></tt></a><tt><font size=2>><br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>> <br>
>> <br>
>> <br>
>> <br>
>> <br>
>>_________________________________________________________________________<br>
>>_<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <br>
>>OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>> <br>
><br>
><br>
>-- <br>
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi<br>
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany<br>
> GF: Felix Imend?rffer, Jane Smithard, Graham Norton,<br>
> HRB 21284 (AG N?rnberg)<br>
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A
563C C272 A126<br>
><br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
></font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 35<br>
Date: Thu, 11 Feb 2016 21:30:26 +0100<br>
From: Thomas Herve <therve@redhat.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: Re: [openstack-dev] [magnum][heat] Bug 1544227<br>
Message-ID:<br>
<CAFsfq7Kgt16VOYpj1jQRGN2Y8tKsWhMyByws9daP3DLhBuZY1A@mail.gmail.com><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Thu, Feb 11, 2016 at 5:23 PM, Hongbin Lu <hongbin.lu@huawei.com>
wrote:<br>
> Rabi,<br>
><br>
> As you observed, I have uploaded two testing patches [1][2] that depends
on your fix patch [3] and the reverted patch [4] respectively. An observation
is that the test "gate-functional-dsvm-magnum-mesos" failed in
[1], but passed in [2]. That implies the reverted patch does resolve an
issue (although I am not sure exactly how).<br>
><br>
> I did notice there are several 404 errors from Neutron, but those
errors exist in successful tests as well so I don't think they are the
root cause.<br>
><br>
> [1] </font></tt><a href=https://review.openstack.org/#/c/278578/><tt><font size=2>https://review.openstack.org/#/c/278578/</font></tt></a><tt><font size=2><br>
> [2] </font></tt><a href=https://review.openstack.org/#/c/278778/><tt><font size=2>https://review.openstack.org/#/c/278778/</font></tt></a><tt><font size=2><br>
> [3] </font></tt><a href=https://review.openstack.org/#/c/278576/><tt><font size=2>https://review.openstack.org/#/c/278576/</font></tt></a><tt><font size=2><br>
> [4] </font></tt><a href=https://review.openstack.org/#/c/278575/><tt><font size=2>https://review.openstack.org/#/c/278575/</font></tt></a><tt><font size=2><br>
<br>
Hi,<br>
<br>
Interestingly, [2] fails with a different error. At some point, we get<br>
the following error:<br>
<br>
Unable to find network with name '3bc0ffd2-6c4a-4e46-9a0e-4fbc91920daf'<br>
<br>
It doesn't make much sense, because we retrieve that network seconds<br>
before, but suddenly it fails. In the neutron log, you can find this:<br>
<br>
SAWarning: The IN-predicate on "ml2_network_segments.network_id"
was<br>
invoked with an empty sequence. This results in a contradiction, which<br>
nonetheless can be expensive to evaluate. Consider alternative<br>
strategies for improved performance.<br>
<br>
It's possible that patch highlights a bug in neutron.<br>
<br>
-- <br>
Thomas<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 36<br>
Date: Thu, 11 Feb 2016 23:17:24 +0000<br>
From: "Christopher N Solis" <cnsolis@us.ibm.com><br>
To: "OpenStack Development Mailing List \(not for usage questions\)"<br>
<openstack-dev@lists.openstack.org><br>
Subject: [openstack-dev] [QA][grenade] Create new grenade job<br>
Message-ID: <201602112317.u1BNHSj2002493@d01av04.pok.ibm.com><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/622837d3/attachment.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/622837d3/attachment.html</font></tt></a><tt><font size=2>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
<br>
End of OpenStack-dev Digest, Vol 46, Issue 32<br>
*********************************************<br>
</font></tt>
<br><p>=====-----=====-----=====<br>
Notice: The information contained in this e-mail<br>
message and/or attachments to it may contain <br>
confidential or privileged information. If you are <br>
not the intended recipient, any dissemination, use, <br>
review, distribution, printing or copying of the <br>
information contained in this e-mail message <br>
and/or attachments to it are strictly prohibited. If <br>
you have received this communication in error, <br>
please notify us by reply e-mail or telephone and <br>
immediately and permanently delete the message <br>
and any attachments. Thank you</p>
<p></p>