settingsLogin | Registersettings

Re: [openstack-dev] OpenStack-dev Digest, Vol 51, Issue 42

0 votes

On Thu, Jul 21, 2016 at 12:53 AM, <openstack-dev-request@lists.openstack.org

wrote:

Send OpenStack-dev mailing list submissions to
openstack-dev@lists.openstack.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
or, via email, send a message with subject or body 'help' to
openstack-dev-request@lists.openstack.org

You can reach the person managing the list at
openstack-dev-owner@lists.openstack.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenStack-dev digest..."

Today's Topics:

  1. Re: [horizon] Plugin stability, failing tests etc. (Hayes, Graham)
  2. Re: [Magnum] Does Docker-Swarm not support inter-node/vm
    inter-container networking ? (Ton Ngo)
  3. [monasca] Monasca Mid-Cycle Minutes (Fabio Giannetti (fgiannet))
  4. Re: [Glare][Heat][TripleO] Heat artifact type (Mikhail Fedosin)
  5. [requirements] Project Mascot (Swapnil Kulkarni (coolsvap))
  6. Re: [devstack] How to enable SSL in devStack? (Rob Crittenden)
  7. Re: [horizon] Plugin stability, failing tests etc. (Rob Cresswell)
  8. [Monasca] Virtual Mid Cycle Coordinates - July 20
    (Fabio Giannetti (fgiannet))
  9. Re: [heat][yaql] Heat map replacement options (Zane Bitter)

    1. Re: [Glare][Heat][TripleO] Heat artifact type (Randall Burt)
    2. Re: [tc][all] Big tent? (Related to Plugins for all)
      (James Bottomley)
    3. [searchlight] Thursday July 21 meeting cancelled
      (Tripp, Travis S)
    4. Re: [TripleO] Delorean fail blocks CI for stable branches
      (Sagi Shnaidman)
    5. [new][glance] glance_store 0.14.0 release (newton)
      (no-reply@openstack.org)
    6. Re: [tc][all] Big tent? (Related to Plugins for all)
      (Fox, Kevin M)
    7. Re: FPGA as a dynamic nested resources (Ed Leafe)
    8. Re: [horizon] Plugin stability, failing tests etc.
      (Kirill Zaitsev)
    9. Re: [Glare][Heat][TripleO] Heat artifact type (Fox, Kevin M)
    10. Re: [horizon] Plugin stability, failing tests etc. (Hayes, Graham)
    11. Re: [TripleO] Delorean fail blocks CI for stable branches
      (Alan Pevec)
    12. Re: [TripleO] Delorean fail blocks CI for stable branches
      (Alan Pevec)
    13. Re: OpenStack Kolla - External Ceph (Jeffrey Zhang)
    14. Re: [tc][all] Big tent? (Related to Plugins for all)
      (James Bottomley)
    15. Re: OpenStack Kolla - External Ceph (Fox, Kevin M)
    16. Re: [horizon] Plugin stability, failing tests etc. (Rob Cresswell)
    17. Re: [devstack] How to enable SSL in devStack? (Rob Crittenden)
    18. Re: [tc][all] Big tent? (Related to Plugins for all) (Clint Byrum)
    19. Re: [TripleO] Delorean fail blocks CI for stable branches
      (Sagi Shnaidman)
    20. Re: [Nova] [RFC] ResourceProviderTags - Manage Capabilities
      with ResourceProvider (Jay Pipes)
    21. Re: [Nova] [RFC] ResourceProviderTags - Manage Capabilities
      with ResourceProvider (Jay Pipes)
    22. Re: [tc][all] Big tent? (Related to Plugins for all)
      (Fox, Kevin M)
    23. Re: [tc][all] Big tent? (Related to Plugins for all)
      (Duncan Thomas)
    24. Re: [charms] Project mascot (Billy Olsen)
    25. Re: [Nova] [RFC] ResourceProviderTags - Manage Capabilities
      with ResourceProvider (Mooney, Sean K)
    26. Re: Mascot/logo for your project (Amrith Kumar)
    27. [trove] no weekly meeting next week (Amrith Kumar)
    28. Re: [tc][all] Big tent? (Related to Plugins for all)
      (Joshua Harlow)

Message: 1
Date: Wed, 20 Jul 2016 12:38:33 +0000
From: "Hayes, Graham" graham.hayes@hpe.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [horizon] Plugin stability, failing tests
etc.
Message-ID:
<
CS1PR84MB021511BB0BBDADAC50DC8BE090080@CS1PR84MB0215.NAMPRD84.PROD.OUTLOOK.COM
>

Content-Type: text/plain; charset="us-ascii"

On 20/07/2016 10:16, Rob Cresswell wrote:

Hey all,

So we've had a few issues with plugin stability recently, and its
apparent that many plugins are building off Horizon master as a
dependency. I would really advise against this. A more manageable
development process may be to:

  • Base stable plugins against a stable release of Horizon
  • Base WIP versions/new plugins off the last Horizon milestone, b2 in
    this case, and then bump the version and capture issues within the same
    patch. This should prevent random breakages, and should allow you to
    just look at the release notes for that milestone.

So this would mean changing tox.ini or requirements files after each
horizon release?

This dovetails nicely with the other thread about how we should be doing
cross project interactions.

What would be best, would be having horizon released as a separate
library on pypi like the clients and oslo libs.

Then openstack-dashboard, and all the plugins could rely on the same
base library, without hacks like:

deps =
-r{toxinidir}/requirements.txt
-r{toxinidir}/test-requirements.txt
http://tarballs.openstack.org/horizon/horizon-master.tar.gz

in tox.ini or

# Testing Requirements
http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon

in (test-)requirements.txt

Is that on roadmap?

On the Horizon side, we've moved our FF a week earlier, so I think that
week combined with the usual RC period should be enough time to fix
bugs. We'll aim to make sure our release notes are complete with regards
to breaking issues for plugins, and deprecate appropriately.

Rob


Message: 2
Date: Wed, 20 Jul 2016 06:43:05 -0700
From: "Ton Ngo" ton@us.ibm.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Magnum] Does Docker-Swarm not support
inter-node/vm inter-container networking ?
Message-ID:
<
OFA8186E94.941C9302-ON88257FF6.004B1912-88257FF6.004B5B66@notes.na.collabserv.com
>

Content-Type: text/plain; charset="utf-8"

Hi Greg,
We should have patches in the next few weeks and the target is to have
this functionality in the Newton cycle.
Ton Ngo,

From: "Waines, Greg" Greg.Waines@windriver.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Date: 07/20/2016 04:51 AM
Subject: Re: [openstack-dev] [Magnum] Does Docker-Swarm not support
inter-node/vm inter-container networking ?

Thanks Ton,

When is the Docker libnetwork functionality forecasted to be available ?

Greg.

From: Ton Ngo ton@us.ibm.com
Reply-To: "openstack-dev@lists.openstack.org"
openstack-dev@lists.openstack.org
Date: Tuesday, July 19, 2016 at 6:58 PM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org
>
Subject: Re: [openstack-dev] [Magnum] Does Docker-Swarm not support
inter-node/vm inter-container networking ?

Hi Greg,
This is a capability that we are working on at this time: enabling Docker
libnetwork using the Kuryr driver.
This will let you set up networks where the containers are connected to and
they will be allocated unique routable IP.
In the current default networking mode, you can still let container
provides service to each other through Docker
port mapping. The end point for the container service would be the IP
address of the VM where the container is hosted
together with the port mapped. You just cannot ping from one container to
another across VM's in this mode.
Ton Ngo,

nactive hide details for "Waines, Greg" ---07/19/2016 11:12:50 AM---I hav
"Waines, Greg" ---07/19/2016 11:12:50 AM---I have successfully setup
devstack with Magnum, following this link https://github.com/openstack/mag

From: "Waines, Greg" Greg.Waines@windriver.com
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org
>
Date: 07/19/2016 11:12 AM
Subject: [openstack-dev] [Magnum] Does Docker-Swarm not support
inter-node/vm inter-container networking ?

I have successfully setup devstack with Magnum,
following this link

https://github.com/openstack/magnum/blob/master/doc/source/dev/quickstart.rst#building-and-using-a-swarm-bay

I created a Docker-Swarm bay and successfully launched some simple
containers.

I noticed that Docker-Swarm?s Container Networking Solution seems to simply
be an SNAT on its swarm-node VM.
And noticed that Docker-Swarm assigns the same Container subnet to each
swarm-node VM ? and re-uses Container IP Addresses from this subnet across
swarm-node VMs.

Given this ? it does not appear that Docker-Swarm can support networking
between two containers on different swarm-node VMs.
Is this True ?
OR
Is there a configuration option, thru Magnum or Docker-Swarm to enable this
inter-node inter-container Networking ?

Greg.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/051032da/attachment-0001.html
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/051032da/attachment-0002.gif
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 16652257.gif
Type: image/gif
Size: 106 bytes
Desc: not available
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/051032da/attachment-0003.gif
>


Message: 3
Date: Wed, 20 Jul 2016 13:54:05 +0000
From: "Fabio Giannetti (fgiannet)" fgiannet@cisco.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [monasca] Monasca Mid-Cycle Minutes
Message-ID: D3B4D03A.23C26%fgiannet@cisco.com
Content-Type: text/plain; charset="us-ascii"

Notes for Monasca July Mid Cycle 2016

Minutes July 19 from 10:30am PDT to

Dimensions Names/Values resources

This blueprint needs to be updated. The PATCH part needs to be updated.
The new URL is metrics/dimensions/names/values
The use case is driven by Grafana and is part of the templating. In order
to get the list of unique dimension names you have to do a query for all
the metrics.
The blueprint is implemented already in Java and Python and the
implementation has been gone through a good testing. It has been
implemented for Vertica and InfluxDB.
Brad to update the blueprint to relect the latest design changes.

Open Discussion
Is the vision for this project to be only for Openstack or it is possible
to extend it to other projects?
The only dependency of the project is on Keystone and once that is removed
the project can be used.
It is possible in the Python version to remove Keystone from the Pipeline
and manually provide the header data so then the API will find the context.
Making Monasca more separate from Openstack. This will require a pluggable
authentication mechanism.
Grafana already supports various Multitenancy capabilties but Kibana is
not that flexible. It seems both support LDAP.

Retrospective

What we have done good
Cool New feature added. Logging API, deterministic alarms, periodic
notificaitons
Good progress in adding new features
Multiple metrics was a good perfomance improvement. From 60s to 1s.
Well integrated in the Openstack process.
Good/Flexible architecture
More visibility in the community. Limited contributions from the "other"
teams.

What we could have done better
Installation is still complex and cumbersome, not well documented. Need of
a Monasca administration guide. Better docs in general would help.
Create an official tutorial.
Replacing Java API in Persister. It is difficult for new contributor to
come to the project. Single API change can take 2 weeks. Java+Python and 3
databases.
Focus on polishing what is already available instead of expanding the
scope.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/29ee6c53/attachment-0001.html
>


Message: 4
Date: Wed, 20 Jul 2016 16:58:31 +0300
From: Mikhail Fedosin mfedosin@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Glare][Heat][TripleO] Heat artifact type
Message-ID:
<CAGk9pwa39AJcFqv7gSP8jVRa08kcjcv5dabBqxs4SfNs==
hZWg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Wed, Jul 20, 2016 at 5:12 AM, Qiming Teng tengqim@linux.vnet.ibm.com
wrote:

On Tue, Jul 19, 2016 at 06:44:06PM +0300, Oleksii Chuprykov wrote:

Hello!

Today it was announced that Glare is ready for public review

http://lists.openstack.org/pipermail/openstack-dev/2016-July/099553.html
So

we are ready to start working on integration Heat with Glare and
implementing a POC. After discussions with Glare team we see two design
options:

1) Create one artifact type that will contain template, nested
templates
and environments.
Pros: It is easy to maintain integrity. Since artifact is immutable, we
can
guarantee the consistency and prevent from accidentally removing of
dependent environment.
Cons: If we need to add new environments to use them with template, we
need
to create new artifact.

2) Create 2 artifact types: environment and template.
Pros: It is easy to add new environments. You just need to create new
dependency from template artifact to environment one.
Cons: Some environment can be (mistakenly) removed, and template that
have
dependencies on it will be in inconsistent state.

Option 2 looks more flexible to me. I'm not sure we are encouraging
users to introduce or rely on a hard dependency from a template to an
environment file. With that, it is still good to know whether glare
supports the concept of 'reference' where a referenced artifact cannot
be deleted.

Hey!

Indeed, option 2 is more flexible, but in this case users have to manually
control dependencies, which is may be hard sometimes. Also, initially Glare
won't support 'hard' dependencies, this feature will be added in next
version, because it requires additional discussions. For this reason I
recommend option 1 and let Glare control template consistency for you, it
won't allow users to break anything.

Best,
Mike

  • Qiming

So we want to hear your opinions and suggestions on the matter. Thanks
in
advance!

Best regards,
Oleksii Chuprykov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/17bcbda0/attachment-0001.html
>


Message: 5
Date: Wed, 20 Jul 2016 19:30:08 +0530
From: "Swapnil Kulkarni (coolsvap)" me@coolsvap.net
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [requirements] Project Mascot
Message-ID:
<CAKO+H++QN0YmL=
27FCaOWB09MOEELqf2gtmjVmzz2O6zzbEJRQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hello,

We had a discussion about project mascot for requirements team today
at the team meeting. Some of the options mentioned are added to [1].
If you have any option, please add to the list.
Also do not forget to provide preference. We will finalize the mascot
on Monday July 25.

[1] https://etherpad.openstack.org/p/requirements-team-mascot

--
Best Regards,
Swapnil


Message: 6
Date: Wed, 20 Jul 2016 10:01:03 -0400
From: Rob Crittenden rcritten@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org, "Wenzhi Yu (yuywz)"
wenzhi_yu@163.com
Subject: Re: [openstack-dev] [devstack] How to enable SSL in devStack?
Message-ID: 578F841F.50000@redhat.com
Content-Type: text/plain; charset=UTF-8; format=flowed

Andrey Pavlov wrote:

Hi,

When I ran devstack with SSL I found a bug and tried to fix it -
https://review.openstack.org/#/c/242812/
But no one agree with me.
Try to apply this patch - it may help.
Also there is a chance that new bugs present in devstack that
prevented to install it with SSL.

Seeing how some other things in your local.conf might help but when I
tried to reproduce it I got the same error and it failed because Apache
didn't have an SSL listener on 443.

I'm not sure I'd recommend direct SSL in any case. I'd recommend the
tls-proxy service instead. Note that I'm pretty sure it has the same
problem: it hasn't been updated to handle port 443 for Keystone.

I'm working on switching from stud to mod_proxy if you want to take a
look and this problem is fixed there, https://review.openstack.org/301172

I'll see about adding a SSL listener to Keystone for the USE_SSL case in
the next few days.

And yeah, it's a moving target. I have an experimental gate test for
tlsproxy but it has to be requested explicitly. My plan is to enable it
as non-voting once the mod_proxy changes land so it will at least be
more obvious when things break (or maybe we can making it voting).

rob


Message: 7
Date: Wed, 20 Jul 2016 14:08:56 +0000
From: Rob Cresswell robert.cresswell@outlook.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [horizon] Plugin stability, failing tests
etc.
Message-ID:
<
AM3PR06MB0936D0ABDF274888858D5A7088080@AM3PR06MB0936.eurprd06.prod.outlook.com
>

Content-Type: text/plain; charset="utf-8"

Yes, it would mean changing your requirements after a release. So, for
example you might run two gate tests:

  • A voting Horizon-stable/milestone test, (or both)
  • A non-voting Horizon-master test

That gives you a lot of control over making your tests passing (multiple
patches to make the Horizon-master test pass, or all in one patch set
alongside the horizon-milestone test bump), rather than random failures
each week. You'd still be able to track the failures as they come in, but
they won't break your gate each time.

I don't think where horizon (the library) lives would change how you
version against it. We don't currently have any plans to separate the two;
while we realise its a desirable change, weighing the work and risk
involved in the split architecture vs the end result, we've chosen to work
on other higher priority items for now (performance, filtering
improvements, angular work etc.)

Rob

On 20 July 2016 at 13:38, Hayes, Graham <graham.hayes@hpe.com> wrote:
On 20/07/2016 10:16, Rob Cresswell wrote:

Hey all,

So we've had a few issues with plugin stability recently, and its
apparent that many plugins are building off Horizon master as a
dependency. I would really advise against this. A more manageable
development process may be to:

  • Base stable plugins against a stable release of Horizon
  • Base WIP versions/new plugins off the last Horizon milestone, b2 in
    this case, and then bump the version and capture issues within the same
    patch. This should prevent random breakages, and should allow you to
    just look at the release notes for that milestone.

So this would mean changing tox.ini or requirements files after each
horizon release?

This dovetails nicely with the other thread about how we should be doing
cross project interactions.

What would be best, would be having horizon released as a separate
library on pypi like the clients and oslo libs.

Then openstack-dashboard, and all the plugins could rely on the same
base library, without hacks like:

deps =
-r{toxinidir}/requirements.txt
-r{toxinidir}/test-requirements.txt
http://tarballs.openstack.org/horizon/horizon-master.tar.gz

in tox.ini or

# Testing Requirements
http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon

in (test-)requirements.txt

Is that on roadmap?

On the Horizon side, we've moved our FF a week earlier, so I think that
week combined with the usual RC period should be enough time to fix
bugs. We'll aim to make sure our release notes are complete with regards
to breaking issues for plugins, and deprecate appropriately.

Rob


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/5f737d0e/attachment-0001.html
>


Message: 8
Date: Wed, 20 Jul 2016 14:10:07 +0000
From: "Fabio Giannetti (fgiannet)" fgiannet@cisco.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Monasca] Virtual Mid Cycle Coordinates -
July 20
Message-ID: D3B4D43B.23C36%fgiannet@cisco.com
Content-Type: text/plain; charset="us-ascii"

Monasca Mid Cycle Day 2
July 20 2016
7am to noon PDT

Webex

Join WebEx meeting:

https://cisco.webex.com/ciscosales/j.php?MTID=m84f9f81d7c1c171be6365716522

d
e15e

Meeting number: 205 141 519
Meeting password: 8VyzUiyr

Join by phone
+1-408-525-6800 Call-in toll number (US/Canada)
+1-866-432-9903 Call-in toll-free number (US/Canada)
Access code: 205 141 519
Numeric meeting password: 01558880


Message: 9
Date: Wed, 20 Jul 2016 10:32:04 -0400
From: Zane Bitter zbitter@redhat.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat][yaql] Heat map replacement options
Message-ID: 38d79a1d-282a-93ab-2314-767c1773b455@redhat.com
Content-Type: text/plain; charset=windows-1252; format=flowed

On 19/07/16 11:04, Steven Hardy wrote:

On Fri, Jul 15, 2016 at 10:25:39AM +0100, Steven Hardy wrote:

Hi all,

I'm trying to figure out the cleanest way to do a replacement of values
in
a mapping (json parameter) in a heat template, e.g:

ServiceNetMap:
type: json
default:
IronicApiNetwork: internal_api
CephPublicNetwork: storage

NetIpMap:
type: json
default:
storage: 192.0.2.2
internal_api: 192.0.2.5

How do I get
OutputMap:
IronicApiNetwork: 192.0.2.5
CephPublicNetwork: 192.0.2.2

It seems like something yaql should be able to do, but I've so far
failed
to figure out the syntax.

The other (possibly simpler) possibility is to implement a new hot
function, e.g something like:

mapreplace:
template: {get
param: ServiceNetMap}
valuereplacements: {getparam: NetIpMap}

As a follow-up to this, I have posted this spec and implementation for
map_replace (syntax differs slightly from the keys above):

https://review.openstack.org/#/c/343696/

https://review.openstack.org/#/c/343731/

My aim is a simpler interface to the yaql example previously discussed,
and
a better error path when things like key collisions occur. Reviews
welcome! :)

This all merged in super-quick time before I even had the chance to
look, but I was wondering... is there really any difference between this
and str_replace?

Right now str_replace requires the template to be a string, but I can't
see any reason for that to be the case. Why not just relax that
requirement so the user can pass map or a list and any strings in the
values/items will get (recursively) replaced by values from the params?

That'd be simpler than adding a separate function, and more flexible too
since you can replace parts of values not just the whole thing (and it
would also handle lists and nested data). The map_replace is very tied
to this one particular use case, where the input is a map and the things
you want to replace are top-level values in their entirety.

Just a thought.

cheers,
Zane.


Message: 10
Date: Wed, 20 Jul 2016 15:18:41 +0000
From: Randall Burt randall.burt@RACKSPACE.COM
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Glare][Heat][TripleO] Heat artifact type
Message-ID: D5365681-FA7A-47D2-838A-8F258D6B4E46@rackspace.com
Content-Type: text/plain; charset="us-ascii"

FWIW, option 2 is almost required unless we plan to be able to bundle
multiple environments with a single template. While having a single
environment for a single template can be useful, the even more useful
scenario (and the primary one driving the development of environments
initially) is when you have options as to how a template behaves (use Trove
for the backend or pop vms and software config to install a database). IMO,
you'd want to de-couple environments from the templates given that multiple
environment could work for the same template.

On Jul 20, 2016, at 8:58 AM, "Mikhail Fedosin" mfedosin@mirantis.com
wrote:

On Wed, Jul 20, 2016 at 5:12 AM, Qiming Teng tengqim@linux.vnet.ibm.com
wrote:
On Tue, Jul 19, 2016 at 06:44:06PM +0300, Oleksii Chuprykov wrote:

Hello!

Today it was announced that Glare is ready for public review

http://lists.openstack.org/pipermail/openstack-dev/2016-July/099553.html
So

we are ready to start working on integration Heat with Glare and
implementing a POC. After discussions with Glare team we see two design
options:

1) Create one artifact type that will contain template, nested
templates
and environments.
Pros: It is easy to maintain integrity. Since artifact is immutable,
we can
guarantee the consistency and prevent from accidentally removing of
dependent environment.
Cons: If we need to add new environments to use them with template, we
need
to create new artifact.

2) Create 2 artifact types: environment and template.
Pros: It is easy to add new environments. You just need to create new
dependency from template artifact to environment one.
Cons: Some environment can be (mistakenly) removed, and template that
have
dependencies on it will be in inconsistent state.

Option 2 looks more flexible to me. I'm not sure we are encouraging
users to introduce or rely on a hard dependency from a template to an
environment file. With that, it is still good to know whether glare
supports the concept of 'reference' where a referenced artifact cannot
be deleted.

Hey!

Indeed, option 2 is more flexible, but in this case users have to
manually control dependencies, which is may be hard sometimes. Also,
initially Glare won't support 'hard' dependencies, this feature will be
added in next version, because it requires additional discussions. For this
reason I recommend option 1 and let Glare control template consistency for
you, it won't allow users to break anything.

Best,
Mike

  • Qiming

So we want to hear your opinions and suggestions on the matter. Thanks
in
advance!

Best regards,
Oleksii Chuprykov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Message: 11
Date: Wed, 20 Jul 2016 08:31:34 -0700
From: James Bottomley James.Bottomley@HansenPartnership.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org, Clint Byrum <clint@fewbar.com
>
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
for all)
Message-ID: 1469028694.2424.49.camel@HansenPartnership.com
Content-Type: text/plain; charset="utf-8"

On Wed, 2016-07-20 at 11:58 +0200, Julien Danjou wrote:

On Tue, Jul 19 2016, Clint Byrum wrote:

Perhaps if we form and start working together as a group, we can
disect why nothing happened, build consensus on the most important
thing to do next, and actually fix some architectural problems.

Architecture is often blamed for lack of interlock but most people
forget that the need for interlock often isn't appreciated until after
the components are built. This is why a lot of people embrace agile
methodology (an excuse for not seeing the problem a priori).

Conversely, architects who try to foresee all interlocks often end up
with a combinatorial explosion that makes it a huge burden simply to
begin the project (and then often get sidelined as 'powerpoint
engineers').

The trick is to do something in the middle: try to foresee and build
the most common interlocks, but sidestep the combinatorial explosion by
building something simple enough to adapt to any interlock requirement
that arises after completion.

The social structure that teams have is a huge part of the
deadlock we find ourselves in with certain controversial changes.
The idea is to unroll the dependency loop and start somewhere
rather than where a lot of these efforts die: starting
everywhere.

I agree with your analysis, but I fail to see how e.g. a group of
people X stating that Y should work this way in Cinder is going to
achieve any change if nobody from Cinder is in X from the beginning.

This is basically what seems to happen in many [working] groups as
far as I can see.

So this is where the Open Source method takes over. Change is produced
by those people who most care about it because they're invested. To
take your Cinder example, you're unlikely to find them within Cinder
because any project has inertia that resists change. It takes the
energy of the outside group X to force the change to Y, but this means
that X often gets to propose, develop and even code Y. Essentially
they become drive by coders for Cinder. This is where Open Source
differs from Enterprise because you have the code and the access, you
can do this. However, you have to remember the inertia problem and
build what you're trying to do as incrementally as possible: the larger
the change, the bigger the resistance to it. It's also a good test of
the value of the change: if group X can't really be bothered to code it
(and Cinder doesn't want it) then perhaps there's not really enough
value in it anyway and it shouldn't happen.

This latter observation is also an improvement over the enterprise
methods because enterprise architects do often mandate interlocks that
later turn out to be unnecessary (or at least of a lot less value than
was initially thought).

I suppose the executive summary of the above is that I don't think
you're describing a bug, I think you're describing a feature.

James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/807333ce/attachment-0001.pgp
>


Message: 12
Date: Wed, 20 Jul 2016 15:48:25 +0000
From: "Tripp, Travis S" travis.tripp@hpe.com
To: OpenStack List openstack-dev@lists.openstack.org
Subject: [openstack-dev] [searchlight] Thursday July 21 meeting
cancelled
Message-ID: EF47110A-C82D-4B00-B407-531422A210D1@hpe.com
Content-Type: text/plain; charset="utf-8"

Due to our midcycle hangout today [0], we are cancelling the searchlight
IRC meeting tomorrow (Thursday July 21).

[0] https://etherpad.openstack.org/p/searchlight-newton-hangout


Message: 13
Date: Wed, 20 Jul 2016 18:50:23 +0300
From: Sagi Shnaidman sshnaidm@redhat.com
To: Alan Pevec alan.pevec@redhat.com
Cc: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO] Delorean fail blocks CI for
stable branches
Message-ID:
<CAGHQP9wzuYF=
s9Dt6bzD-EmP7BU5WbicL1w_UG-azd8xGXtw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Wed, Jul 20, 2016 at 2:29 PM, Alan Pevec apevec@redhat.com wrote:

git clone https://git.openstack.org/openstack/tripleo-heat-templates
cd tripleo-heat-templates/
git checkout -b stable/mitaka origin/stable/mitaka

^ this is manually switching to the stable source branch

sed -i -e "s%distro=.%distro=rpm-mitaka%" projects.ini
sed -i -e "s%source=.
%source=stable/mitaka%" projects.ini

^ this configures dlrn to the correct combination of distro and source
branches, but ...

./venv/bin/dlrn --config-file projects.ini --head-only --package-name
openstack-tripleo-heat-templates --local

^ ... --local here keeps local checkout untouched, so you end up with
default rpm-master in distro git checkout.
If you remove --local it will reset local checkouts to the branches
specified in projects.ini

Alan,
I don't want to reset local checkouts and reset branches - I need to build
with these checkout, it's all CI is for.

Alan

--
Best regards
Sagi Shnaidman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/90088167/attachment-0001.html
>


Message: 14
From: no-reply@openstack.org
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [new][glance] glance_store 0.14.0 release
(newton)
Message-ID:
mailman.22599.1469042581.7714.openstack-dev@lists.openstack.org

We are psyched to announce the release of:

glance_store 0.14.0: OpenStack Image Service Store Library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/glance_store

With package available at:

https://pypi.python.org/pypi/glance_store

Please report issues through launchpad:

http://bugs.launchpad.net/glance-store

For more details, please see below.

Changes in glance_store 0.13.0..0.14.0


79532ea Add bandit to pep8 and bandit testenv
fd84300 Remove unused variable in vmware store
84e6354 Imported Translations from Zanata
6e7c722 Updated from global requirements
4b6818d Check that size is a number
19d8df3 Replace dict.iterkeys with six.iterkeys to make PY3 compatible
3e20ff9 cinder: Fix getsize return value
5c07499 The function add calculation size
gb need improve
4b10efd Updated from global requirements
a3b298e Updated from global requirements
fd1e846 Fix argument order for assertEqual to (expected, observed)
f0087f3 Updated from global requirements
a678c26 Updated from global requirements
5829046 Remove -c from tox.ini
ea4483c tox respects upper-constraints.txt
9a58812 Updated from global requirements
922233f Updated from global requirements
55af8b5 Updated from global requirements
75cd233 Updated from global requirements
0a6124f Fix minor misspellings affecting Config Reference Guide
6f4bf26 Remove verbose option from glancestore tests
2e93319 Updated from global requirements
8eda73b Updated from global requirements
0a606a5 Improve help text of swift driver opts
40dded6 Updated from global requirements
1e87dfd Add functional tests for swift
25e5d19 Imported Translations from Zanata
7b439d6 Updated from global requirements
32d964f Updated from global requirements
4412580 Fix releasenotes to pass reno gates
3758022 Updated from global requirements
7b94d3c tox: use os-testr instead of testr
9addf29 Fix swiftclient mocks
ba8e51f Deprecate swift driver options properly
da74173 Fix typos in config files
1ae475c Setup defaults for swift driver authentication
1ce1f40 Fix doc generation warnings and errors
200249a trivial:fixing one W503 pep8 error
5c6c6e6 Module docs are not generated
3b53b0b Fix cinder store to support Cinder RemoteFS backends
3b637b4 Missing params in store
addtobackend docstring
851508c Mock swiftclient's functions in tests
1d2474b Update reno for stable/mitaka
a9d6cce Add base for functional tests

Diffstat (except docs and test files)


.gitignore | 3 +
.testr.conf | 2 +-
functionaltesting.conf.sample | 9 +
glance
store/drivers/cinder.py | 12 +-
glance
store/drivers/filesystem.py | 4 +-
glance
store/drivers/http.py | 2 +-
glance
store/drivers/sheepdog.py | 7 +-
glance
store/drivers/swift/store.py | 196 +++++++++++---
glance
store/drivers/swift/utils.py | 36 ++-
glance
store/drivers/vmwaredatastore.py | 7 +-
glancestore/backend.py | 2 +
.../en
GB/LCMESSAGES/glancestore-log-warning.po | 19 ++
.../locale/enGB/LCMESSAGES/glancestore.po | 246 +++++++++++++++++
.../es/LC
MESSAGES/glancestore-log-warning.po | 8 +-
.../fr/LC
MESSAGES/glancestore-log-warning.po | 8 +-
glance
store/locale/glancestore-log-warning.pot | 25 --
glance
store/locale/glancestore.pot | 290
...event-unauthorized-errors-ebb9cf2236595cd0.yaml | 12 +-
releasenotes/source/index.rst | 1 +
.../locale/en
GB/LCMESSAGES/releasenotes.po | 113 ++++++++
releasenotes/source/mitaka.rst | 6 +
requirements.txt | 12 +-
setup.cfg | 8 +-
test-requirements.txt | 12 +-
tools/colorizer.py | 3 +-
tools/tox
install.sh | 55 ++++
tox.ini | 34 ++-
42 files changed, 1167 insertions(+), 557 deletions(-)

Requirements updates


diff --git a/requirements.txt b/requirements.txt
index f102881..a83ce1a 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -4 +4 @@
-oslo.config>=3.7.0 # Apache-2.0
+oslo.config>=3.10.0 # Apache-2.0
@@ -7,3 +7,3 @@ oslo.serialization>=1.10.0 # Apache-2.0
-oslo.utils>=3.5.0 # Apache-2.0
-oslo.concurrency>=3.5.0 # Apache-2.0
-stevedore>=1.5.0 # Apache-2.0
+oslo.utils>=3.14.0 # Apache-2.0
+oslo.concurrency>=3.8.0 # Apache-2.0
+stevedore>=1.10.0 # Apache-2.0
@@ -17,2 +17,2 @@ jsonschema!=2.5.0,<3.0.0,>=2.0.0 # MIT
-python-keystoneclient!=1.8.0,!=2.1.0,>=1.6.0 # Apache-2.0
-requests!=2.9.0,>=2.8.1 # Apache-2.0
+python-keystoneclient!=1.8.0,!=2.1.0,>=1.7.0 # Apache-2.0
+requests>=2.10.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 8c6627d..b45ee6f 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -8 +8 @@ hacking<0.11,>=0.10.0
-mock>=1.2 # BSD
+mock>=2.0 # BSD
@@ -12 +12 @@ coverage>=3.6 # Apache-2.0
-fixtures>=1.3.1 # Apache-2.0/BSD
+fixtures>=3.0.0 # Apache-2.0/BSD
@@ -14 +14 @@ python-subunit>=0.0.18 # Apache-2.0/BSD
-requests-mock>=0.7.0 # Apache-2.0
+requests-mock>=1.0 # Apache-2.0
@@ -18,0 +19,2 @@ oslotest>=1.10.0 # Apache-2.0
+os-testr>=0.7.0 # Apache-2.0
+bandit>=1.0.1 # Apache-2.0
@@ -21 +23 @@ oslotest>=1.10.0 # Apache-2.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
@@ -23 +25 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-reno>=0.1.1 # Apache2
+reno>=1.8.0 # Apache2


Message: 15
Date: Wed, 20 Jul 2016 16:08:22 +0000
From: "Fox, Kevin M" Kevin.Fox@pnnl.gov
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org, Clint Byrum <clint@fewbar.com
>
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
for all)
Message-ID:
1A3C52DFCD06494D8528644858247BF01B9A6B50@EX10MBOX03.pnnl.gov
Content-Type: text/plain; charset="us-ascii"

+1 to the finding of a middle ground.

The problem I've seen with your suggested OpenSource solution is the
current social monetary system of OpenStack makes it extremely difficult.

Each project currently prints its own currency. Reviews. It takes quite a
few Reviews (time/effort) on a project to gain enough currency that you get
payed attention to. And, one project doesn't honor another projects
currency.

When these sorts of major cross project things need to be done though, you
need to have folks with capital in many different projects and its very
difficult to amass that much.

There is no OpenStack level currency (other then being elected as a TC
member) that gets one project to stop and take the time to carefully
consider what someone is saying when bringing up cross project issues.

Without some shared currency, then the problem becomes, the person
invested in getting a solution, can propose and prototype and implement the
feature all they want (often several times), but it never actually is
accepted into the projects because a project:
a) doesn't take the time to really understand the problem, feeling its
trivial and just not accepting any reviews
b) doesn't take the time to really understand the problem, so minimize it
in their mind to a 'you should just use existing thing X...' or a heavy
handily propose alternate solutions that really aren't solutions.
c) they decide its better handled by another project and stall/block
reviews, trying to push the implementation to go elsewhere. When multiple
projects decide this, the ball just keeps getting bounced around without
any solution for years.

The status quo is not working here. The current governance structure
doesn't support progress.

Thanks,
Kevin


From: James Bottomley [James.Bottomley@HansenPartnership.com]
Sent: Wednesday, July 20, 2016 8:31 AM
To: OpenStack Development Mailing List (not for usage questions); Clint
Byrum
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for
all)

On Wed, 2016-07-20 at 11:58 +0200, Julien Danjou wrote:

On Tue, Jul 19 2016, Clint Byrum wrote:

Perhaps if we form and start working together as a group, we can
disect why nothing happened, build consensus on the most important
thing to do next, and actually fix some architectural problems.

Architecture is often blamed for lack of interlock but most people
forget that the need for interlock often isn't appreciated until after
the components are built. This is why a lot of people embrace agile
methodology (an excuse for not seeing the problem a priori).

Conversely, architects who try to foresee all interlocks often end up
with a combinatorial explosion that makes it a huge burden simply to
begin the project (and then often get sidelined as 'powerpoint
engineers').

The trick is to do something in the middle: try to foresee and build
the most common interlocks, but sidestep the combinatorial explosion by
building something simple enough to adapt to any interlock requirement
that arises after completion.

The social structure that teams have is a huge part of the
deadlock we find ourselves in with certain controversial changes.
The idea is to unroll the dependency loop and start somewhere
rather than where a lot of these efforts die: starting
everywhere.

I agree with your analysis, but I fail to see how e.g. a group of
people X stating that Y should work this way in Cinder is going to
achieve any change if nobody from Cinder is in X from the beginning.

This is basically what seems to happen in many [working] groups as
far as I can see.

So this is where the Open Source method takes over. Change is produced
by those people who most care about it because they're invested. To
take your Cinder example, you're unlikely to find them within Cinder
because any project has inertia that resists change. It takes the
energy of the outside group X to force the change to Y, but this means
that X often gets to propose, develop and even code Y. Essentially
they become drive by coders for Cinder. This is where Open Source
differs from Enterprise because you have the code and the access, you
can do this. However, you have to remember the inertia problem and
build what you're trying to do as incrementally as possible: the larger
the change, the bigger the resistance to it. It's also a good test of
the value of the change: if group X can't really be bothered to code it
(and Cinder doesn't want it) then perhaps there's not really enough
value in it anyway and it shouldn't happen.

This latter observation is also an improvement over the enterprise
methods because enterprise architects do often mandate interlocks that
later turn out to be unnecessary (or at least of a lot less value than
was initially thought).

I suppose the executive summary of the above is that I don't think
you're describing a bug, I think you're describing a feature.

James


Message: 16
Date: Wed, 20 Jul 2016 09:15:08 -0700
From: Ed Leafe ed@leafe.com
To: "Daniel P. Berrange" berrange@redhat.com, "OpenStack Development
Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] FPGA as a dynamic nested resources
Message-ID: FC9FDA36-B300-4363-AFD6-29A0947C0B00@leafe.com
Content-Type: text/plain; charset=utf-8

On Jul 20, 2016, at 2:07 AM, Daniel P. Berrange berrange@redhat.com
wrote:

For FPGA, I'd like to see an initial proposal that assumed the FPGA
is pre-programmed & pre-divided into a fixed number of slots and simply
deal with this. This is similar to how we dealt with PCI SR-IOV initially
where we assumed the dev is in VF-mode only. Only later did we start to
add cleverness around switching VF vs PF mode. For FPGA I think any kind
of dynamic re-allocation/re-configuration is better done as a stage 2

+1 to this approach. I?m not convinced yet that Nova should be in the
business of FPGA management, but once we get the basic functionality
supporting FPGA working well, seeing what would be needed to add it would
be much easier, and we could make a clearer determination as to whether
this is feasible or not.

-- Ed Leafe


Message: 17
Date: Wed, 20 Jul 2016 19:21:04 +0300
From: Kirill Zaitsev kzaitsev@mirantis.com
To: Rob Cresswell robert.cresswell@outlook.com, "OpenStack
Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [horizon] Plugin stability, failing tests
etc.
Message-ID: etPan.578fa4f0.1c21aa30.186@mirantis.com
Content-Type: text/plain; charset="utf-8"

Initially I don?t think I like the idea of making master-horizon job
non-voting for murano-dashboard.

Here are some reasons:?
1) We would still need to fix murano-dashboard to work with master
horizon (since we would need to be released together)
2) The breakage would be less visible
3) I can imagine a situation when a change would pass on master
but would not pass on a previous stable point release (even worse this
release can be n3). Say we?re trying to use some function/feature, that has
just landed.

Those are my initial ideas about this, have give it a bit more time, to
think more carefully.

BTW, I can fetch the numbers on how many times murano-dashboard gate was
broken by changes in horizon, during M and N cycles, if you?re interested.
Also for murano-dashboard we run our integration selenium tests as a
3d-party CI, so technically we?re not blocked by the job not working, in
case we need to land some security patch. =)

--?
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

On 20 juillet 2016 at 17:10:46, Rob Cresswell (
robert.cresswell@outlook.com) wrote:

Yes, it would mean changing your requirements after a release. So, for
example you might run two gate tests:

  • A voting Horizon-stable/milestone test, (or both)
  • A non-voting Horizon-master test

That gives you a lot of control over making your tests passing (multiple
patches to make the Horizon-master test pass, or all in one patch set
alongside the horizon-milestone test bump), rather than random failures
each week. You'd still be able to track the failures as they come in, but
they won't break your gate each time.

I don't think where horizon (the library) lives would change how you
version against it. We don't currently have any plans to separate the two;
while we realise its a desirable change, weighing the work and risk
involved in the split architecture vs the end result, we've chosen to work
on other higher priority items for now (performance, filtering
improvements, angular work etc.)

Rob

On 20 July 2016 at 13:38, Hayes, Graham graham.hayes@hpe.com wrote:
On 20/07/2016 10:16, Rob Cresswell wrote:

Hey all,

So we've had a few issues with plugin stability recently, and its
apparent that many plugins are building off Horizon master as a
dependency. I would really advise against this. A more manageable
development process may be to:

  • Base stable plugins against a stable release of Horizon
  • Base WIP versions/new plugins off the last Horizon milestone, b2 in
    this case, and then bump the version and capture issues within the same
    patch. This should prevent random breakages, and should allow you to
    just look at the release notes for that milestone.

So this would mean changing tox.ini or requirements files after each
horizon release?

This dovetails nicely with the other thread about how we should be doing
cross project interactions.

What would be best, would be having horizon released as a separate
library on pypi like the clients and oslo libs.

Then openstack-dashboard, and all the plugins could rely on the same
base library, without hacks like:

? ?deps =
? ? ?-r{toxinidir}/requirements.txt
? ? ?-r{toxinidir}/test-requirements.txt
? ? ?http://tarballs.openstack.org/horizon/horizon-master.tar.gz

in tox.ini or

? ?# Testing Requirements
? ?http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon

in (test-)requirements.txt

Is that on roadmap?

On the Horizon side, we've moved our FF a week earlier, so I think that
week combined with the usual RC period should be enough time to fix
bugs. We'll aim to make sure our release notes are complete with regards
to breaking issues for plugins, and deprecate appropriately.

Rob


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/07fbcda5/attachment-0001.html
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Message signed with OpenPGP using AMPGpg
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/07fbcda5/attachment-0001.pgp
>

Message: 18
Date: Wed, 20 Jul 2016 16:30:09 +0000
From: "Fox, Kevin M" Kevin.Fox@pnnl.gov
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Glare][Heat][TripleO] Heat artifact type
Message-ID:
1A3C52DFCD06494D8528644858247BF01B9A6BC2@EX10MBOX03.pnnl.gov
Content-Type: text/plain; charset="iso-8859-1"

I have a preference towards option 2 as well. I usually use templates with
all the logic in it, and an environment file with just the specific
parameters defined for launching an instance of the template so I can
repeatedly deploy/delete/redeploy it.

I've got a good template set I think that would be awesome to see in a
glare artefact.

Could this template set be wrapped up:
https://github.com/EMSL-MSC/heat-templates/tree/master/cfn/lib

And the main entrypoint template is:

https://github.com/EMSL-MSC/heat-templates/blob/master/cfn/lib/SimpleServer.yaml

Documentation on how to use it is here:

https://github.com/EMSL-MSC/heat-templates/blob/master/cfn/lib/SimpleServer.txt

With it implemented with Option 2, the user can just copy the two example
environments at the bottom of the docs there, tweak it slightly and launch
some fairly advanced servers.

Thanks,
Kevin


From: Mikhail Fedosin [mfedosin@mirantis.com]
Sent: Wednesday, July 20, 2016 6:58 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glare][Heat][TripleO] Heat artifact type

On Wed, Jul 20, 2016 at 5:12 AM, Qiming Teng <tengqim@linux.vnet.ibm.com
tengqim@linux.vnet.ibm.com> wrote:
On Tue, Jul 19, 2016 at 06:44:06PM +0300, Oleksii Chuprykov wrote:

Hello!

Today it was announced that Glare is ready for public review
http://lists.openstack.org/pipermail/openstack-dev/2016-July/099553.html
So
we are ready to start working on integration Heat with Glare and
implementing a POC. After discussions with Glare team we see two design
options:

1) Create one artifact type that will contain template, nested templates
and environments.
Pros: It is easy to maintain integrity. Since artifact is immutable, we
can
guarantee the consistency and prevent from accidentally removing of
dependent environment.
Cons: If we need to add new environments to use them with template, we
need
to create new artifact.

2) Create 2 artifact types: environment and template.
Pros: It is easy to add new environments. You just need to create new
dependency from template artifact to environment one.
Cons: Some environment can be (mistakenly) removed, and template that
have
dependencies on it will be in inconsistent state.

Option 2 looks more flexible to me. I'm not sure we are encouraging
users to introduce or rely on a hard dependency from a template to an
environment file. With that, it is still good to know whether glare
supports the concept of 'reference' where a referenced artifact cannot
be deleted.

Hey!

Indeed, option 2 is more flexible, but in this case users have to manually
control dependencies, which is may be hard sometimes. Also, initially Glare
won't support 'hard' dependencies, this feature will be added in next
version, because it requires additional discussions. For this reason I
recommend option 1 and let Glare control template consistency for you, it
won't allow users to break anything.

Best,
Mike

  • Qiming

So we want to hear your opinions and suggestions on the matter. Thanks in
advance!

Best regards,
Oleksii Chuprykov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/aa8965fb/attachment-0001.html
>


Message: 19
Date: Wed, 20 Jul 2016 16:36:14 +0000
From: "Hayes, Graham" graham.hayes@hpe.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [horizon] Plugin stability, failing tests
etc.
Message-ID:
<
CS1PR84MB021589920974E4C50CCA0CBB90080@CS1PR84MB0215.NAMPRD84.PROD.OUTLOOK.COM
>

Content-Type: text/plain; charset="us-ascii"

On 20/07/2016 15:13, Rob Cresswell wrote:

Yes, it would mean changing your requirements after a release. So, for
example you might run two gate tests:

  • A voting Horizon-stable/milestone test, (or both)
  • A non-voting Horizon-master test

That gives you a lot of control over making your tests passing (multiple
patches to make the Horizon-master test pass, or all in one patch set
alongside the horizon-milestone test bump), rather than random failures
each week. You'd still be able to track the failures as they come in,
but they won't break your gate each time.

I don't want control, I want to consume a library in a standard way -
the way we consume libraries from the rest of openstack.

I don't think where horizon (the library) lives would change how you
version against it. We don't currently have any plans to separate the
two; while we realise its a desirable change, weighing the work and risk
involved in the split architecture vs the end result, we've chosen to
work on other higher priority items for now (performance, filtering
improvements, angular work etc.)

Well, if would stop us having a reference to git branch in our
requirements, and allow to use the standard global requirements
process to manage the dependency.

It also means that as a plugin I know that the released version of
my plugin has been tested in my gate with the exact version of the
code that the horizon team release.

We can still do multiple patches to fix any changes in the horizon
library, and in the tip of the chain update the version in requirements.

The risk has just been moved to the plugins, which is not ideal.

It also makes downstream consumption a lot easier.

On 20 July 2016 at 13:38, Hayes, Graham <graham.hayes@hpe.com
graham.hayes@hpe.com> wrote:

On 20/07/2016 10:16, Rob Cresswell wrote:
> Hey all,
>
> So we've had a few issues with plugin stability recently, and its
> apparent that many plugins are building off Horizon master as a
> dependency. I would really advise against this. A more manageable
> development process may be to:
>
> - Base stable plugins against a stable release of Horizon
> - Base WIP versions/new plugins off the last Horizon milestone, b2

in

this case, and then bump the version and capture issues within the
same
patch. This should prevent random breakages, and should allow you
to
just look at the release notes for that milestone.

So this would mean changing tox.ini or requirements files after each
horizon release?

This dovetails nicely with the other thread about how we should be

doing
cross project interactions.

What would be best, would be having horizon released as a separate
library on pypi like the clients and oslo libs.

Then openstack-dashboard, and all the plugins could rely on the same
base library, without hacks like:

   deps =
     -r{toxinidir}/requirements.txt
     -r{toxinidir}/test-requirements.txt
     http://tarballs.openstack.org/horizon/horizon-master.tar.gz

in tox.ini or

   # Testing Requirements

http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon

in (test-)requirements.txt

Is that on roadmap?

> On the Horizon side, we've moved our FF a week earlier, so I think

that

week combined with the usual RC period should be enough time to fix
bugs. We'll aim to make sure our release notes are complete with
regards
to breaking issues for plugins, and deprecate appropriately.

Rob


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<

http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Message: 20
Date: Wed, 20 Jul 2016 18:39:34 +0200
From: Alan Pevec apevec@redhat.com
To: Sagi Shnaidman sshnaidm@redhat.com
Cc: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO] Delorean fail blocks CI for
stable branches
Message-ID:
<CABYd8ScS7xrtXkTRGL35CRtOevjgy3L8C=
W1Q7zOhr1zGtH1ug@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

^ ... --local here keeps local checkout untouched, so you end up with
default rpm-master in distro git checkout.
If you remove --local it will reset local checkouts to the branches
specified in projects.ini

Alan,
I don't want to reset local checkouts and reset branches - I need to
build
with these checkout, it's all CI is for.

DLRN finds matching packaging branch only when you let it reset git
checkouts.
For tripleo-ci use-case we would need to add a new option to keep
source repo as-is and reset packaging checkout only, in the meantime
as a quickfix in tripleo.sh you could patch dlrn and set local=True in
[2]

Alan

[1]
https://github.com/openstack-packages/DLRN/blob/master/dlrn/shell.py#L522-L536

[2]
https://github.com/openstack-packages/DLRN/blob/master/dlrn/drivers/rdoinfo.py#L83-L84


Message: 21
Date: Wed, 20 Jul 2016 18:50:57 +0200
From: Alan Pevec apevec@redhat.com
To: Alan Pevec alan.pevec@redhat.com
Cc: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO] Delorean fail blocks CI for
stable branches
Message-ID:
<
CABYd8Se-jmf8wG7HEB-jczeAhFx241LDqTsTqEGwrrt5diOzSQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

as a quickfix in tripleo.sh you could patch dlrn and set local=True in

correction, patch local=False there while running dlrn command with
--local to keep source checkout as-is


Message: 22
Date: Thu, 21 Jul 2016 00:51:59 +0800
From: Jeffrey Zhang zhang.lei.fly@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] OpenStack Kolla - External Ceph
Message-ID:
<
CAATxhGfZ3bm1dfOXvQpLZcx-jTQ-vLROUm9fcVBJGwFq+thmaw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 6, 2016 at 1:47 AM, Steven Dake (stdake) stdake@cisco.com
wrote:

At this point, I feel we are going a direction in which we try to wrap
everything anybody could possibly want to configure with Kolla by making
extensive use of global.yml. We would have to introduce flags indicating
a
couple of different scenarios:

  1. Deploy Ceph (already there: enable_ceph="yes")
  2. Use Ceph with Glance (enablecephglance="yes")
  3. Use Ceph with Cinder (enablecephcinder="yes")
  4. Use Ceph with Nova (enablecephnova="yes")

I disagree. If ceph is enabled, then ceph should be used, if ceph is not
enabled, then ceph shouldn't be used. That implies all of OpenStack
either
uses Ceph or not. So we really just need enable_ceph.

why we need separate configuration for ceph? I think if ceph is
enable, all the service should use ceph, too.

--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me


Message: 23
Date: Wed, 20 Jul 2016 09:57:27 -0700
From: James Bottomley James.Bottomley@HansenPartnership.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org, Clint Byrum <clint@fewbar.com
>
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
for all)
Message-ID: 1469033847.2424.66.camel@HansenPartnership.com
Content-Type: text/plain; charset="UTF-8"

On Wed, 2016-07-20 at 16:08 +0000, Fox, Kevin M wrote:

+1 to the finding of a middle ground.

Thanks ... I have actually been an enterprise architect (I just keep
very quiet about it when talking Open Source).

The problem I've seen with your suggested OpenSource solution is the
current social monetary system of OpenStack makes it extremely
difficult.

Each project currently prints its own currency. Reviews. It takes
quite a few Reviews (time/effort) on a project to gain enough
currency that you get payed attention to. And, one project doesn't
honor another projects currency.

OK, I accept your analogy, even though I would view currency as the
will to create and push patches.

The problem you describe: getting the recipients to listen and accept
your patches, is also a common one. The first essential is simple
minimal patches because they're hard to reject.

Once you've overcome the reject barrier, there's the indifference one
(no-one says no, but no-one says yes).

Overcoming indifference involves partly knowing who to bother and when
(In openstack, it's quite easy since you know who the core reviewers
are) and also building a consensus for the patch; usually this involves
finding other people who need the feature and getting them to pipe up
(if you can't find other projects, then you can get potential users to
do this) even better if they help you write the patches. Ideally, you
build your consensus before you actually push the patch set. Sometimes
building consensus involves looking beyond your particular need to a
bigger one that would satisfy you but also pulls other people in.

When these sorts of major cross project things need to be done
though, you need to have folks with capital in many different
projects and its very difficult to amass that much.

There is no OpenStack level currency (other then being elected as a
TC member) that gets one project to stop and take the time to
carefully consider what someone is saying when bringing up cross
project issues.

Without some shared currency, then the problem becomes, the person
invested in getting a solution, can propose and prototype and
implement the feature all they want (often several times), but it
never actually is accepted into the projects because a project:
a) doesn't take the time to really understand the problem, feeling
its trivial and just not accepting any reviews
b) doesn't take the time to really understand the problem, so
minimize it in their mind to a 'you should just use existing thing
X...' or a heavy handily propose alternate solutions that really
aren't solutions.
c) they decide its better handled by another project and stall/block
reviews, trying to push the implementation to go elsewhere. When
multiple projects decide this, the ball just keeps getting bounced
around without any solution for years.

The status quo is not working here. The current governance structure
doesn't support progress.

What you'll find you've described above is a process that doesn't
support drive by coders at all and, by extension therefore, doesn't
welcome newcomers, which is a big problem, but one I thought OpenStack
was tackling?

The bounce problem is annoying but not insuperable. It mostly occurs
where there's overlap. Often the best method for coping is to field
the bounce: produce the patch for the other project. If it's smaller
and neater, perhaps the bounce was correct. If it's bigger and uglier,
get the other project to say so and you now have a solid reason to go
back and say "we tried what you suggested and here's why it didn't
work". Morally, you're now on higher ground because incorrect
technical advice is a personal failure for whoever bounced you (make
sure to capitalise on it if they try another bounce).

James


Message: 24
Date: Wed, 20 Jul 2016 17:12:30 +0000
From: "Fox, Kevin M" Kevin.Fox@pnnl.gov
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] OpenStack Kolla - External Ceph
Message-ID:
1A3C52DFCD06494D8528644858247BF01B9A6CC7@EX10MBOX03.pnnl.gov
Content-Type: text/plain; charset="us-ascii"

We use ceph with cinder and glance. I don't see a reason not to.

We do not set nova to use it for anything but cinder volumes though.

The reason being, if you set it up that way, your users have no way of
opting out of the potential performance hit if using no local storage for
non pets.

If you leave it nova local, you can always still get ceph remote storage
for the whole vm by requesting the root disk be volume backed.

We also already have a ceph deployment managed without kolla, and that's
unlikely to change.

So, for our site, our settings would probably be:
1. Deploy Ceph (enableceph="no")
2. Use Ceph with Glance (enable
cephglance="yes")
3. Use Ceph with Cinder (enable
cephcinder="yes")
4. Use Ceph with Nova (enable
ceph_nova="no")

Thanks,
Kevin


From: Jeffrey Zhang [zhang.lei.fly@gmail.com]
Sent: Wednesday, July 20, 2016 9:51 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] OpenStack Kolla - External Ceph

On Wed, Jul 6, 2016 at 1:47 AM, Steven Dake (stdake) stdake@cisco.com
wrote:

At this point, I feel we are going a direction in which we try to wrap
everything anybody could possibly want to configure with Kolla by making
extensive use of global.yml. We would have to introduce flags indicating
a
couple of different scenarios:

  1. Deploy Ceph (already there: enable_ceph="yes")
  2. Use Ceph with Glance (enablecephglance="yes")
  3. Use Ceph with Cinder (enablecephcinder="yes")
  4. Use Ceph with Nova (enablecephnova="yes")

I disagree. If ceph is enabled, then ceph should be used, if ceph is not
enabled, then ceph shouldn't be used. That implies all of OpenStack
either
uses Ceph or not. So we really just need enable_ceph.

why we need separate configuration for ceph? I think if ceph is
enable, all the service should use ceph, too.

--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Message: 25
Date: Wed, 20 Jul 2016 17:21:31 +0000
From: Rob Cresswell robert.cresswell@outlook.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [horizon] Plugin stability, failing tests
etc.
Message-ID:
<
AM3PR06MB0936D02113CFEF76C538C37088080@AM3PR06MB0936.eurprd06.prod.outlook.com
>

Content-Type: text/plain; charset="utf-8"

Kirill: The failures are just as visible, since the cores still control
merging anyway. The only difference is that if it takes a few days to fix
something in upstream Horizon, you needn't block your own content in the
meantime. Later in the release cycle (around N-3, for example) cores could
just not merge failing tests. Regardless, this is just a recommendation,
and if you're comfortable adjusting to issues as they come through, then
thats fine to base off master.

Graham: The "risk" I refer to is in that in any project architecture
rewrite you can make mistakes and break functionality. So that risk only
arises from a rewrite.

"It also means that as a plugin I know that the released version of my
plugin has been tested in my gate with the exact version of the code that
the horizon team release." - I don't understand this part. If we release a
horizon lib, we'd still being doing milestone releases to PyPI. So again,
whether you consume that as a tarball or a PyPI package makes little
difference to the day to day testing of your plugin. Its the same code.

Ideally - yes, we'd probably split horizon as a separate library, but
thats something to discuss at the summit and judge demand, because most
discussions thus far have concluded that its a lower priority issue than
others.

Rob

On 20 July 2016 at 17:36, Hayes, Graham <graham.hayes@hpe.com> wrote:
On 20/07/2016 15:13, Rob Cresswell wrote:

Yes, it would mean changing your requirements after a release. So, for
example you might run two gate tests:

  • A voting Horizon-stable/milestone test, (or both)
  • A non-voting Horizon-master test

That gives you a lot of control over making your tests passing (multiple
patches to make the Horizon-master test pass, or all in one patch set
alongside the horizon-milestone test bump), rather than random failures
each week. You'd still be able to track the failures as they come in,
but they won't break your gate each time.

I don't want control, I want to consume a library in a standard way -
the way we consume libraries from the rest of openstack.

I don't think where horizon (the library) lives would change how you
version against it. We don't currently have any plans to separate the
two; while we realise its a desirable change, weighing the work and risk
involved in the split architecture vs the end result, we've chosen to
work on other higher priority items for now (performance, filtering
improvements, angular work etc.)

Well, if would stop us having a reference to git branch in our
requirements, and allow to use the standard global requirements
process to manage the dependency.

It also means that as a plugin I know that the released version of
my plugin has been tested in my gate with the exact version of the
code that the horizon team release.

We can still do multiple patches to fix any changes in the horizon
library, and in the tip of the chain update the version in requirements.

The risk has just been moved to the plugins, which is not ideal.

It also makes downstream consumption a lot easier.

On 20 July 2016 at 13:38, Hayes, Graham <graham.hayes@hpe.com
<mailto:graham.hayes@hpe.comgraham.hayes@hpe.com>> wrote:

On 20/07/2016 10:16, Rob Cresswell wrote:
> Hey all,
>
> So we've had a few issues with plugin stability recently, and its
> apparent that many plugins are building off Horizon master as a
> dependency. I would really advise against this. A more manageable
> development process may be to:
>
> - Base stable plugins against a stable release of Horizon
> - Base WIP versions/new plugins off the last Horizon milestone, b2

in

this case, and then bump the version and capture issues within the
same
patch. This should prevent random breakages, and should allow you
to
just look at the release notes for that milestone.

So this would mean changing tox.ini or requirements files after each
horizon release?

This dovetails nicely with the other thread about how we should be

doing
cross project interactions.

What would be best, would be having horizon released as a separate
library on pypi like the clients and oslo libs.

Then openstack-dashboard, and all the plugins could rely on the same
base library, without hacks like:

   deps =
     -r{toxinidir}/requirements.txt
     -r{toxinidir}/test-requirements.txt
     http://tarballs.openstack.org/horizon/horizon-master.tar.gz

in tox.ini or

   # Testing Requirements

http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon

in (test-)requirements.txt

Is that on roadmap?

> On the Horizon side, we've moved our FF a week earlier, so I think

that

week combined with the usual RC period should be enough time to fix
bugs. We'll aim to make sure our release notes are complete with
regards
to breaking issues for plugins, and deprecate appropriately.

Rob


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<

http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<
http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/433e2b02/attachment-0001.html
>


Message: 26
Date: Wed, 20 Jul 2016 13:29:02 -0400
From: Rob Crittenden rcritten@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org, "Wenzhi Yu (yuywz)"
wenzhi_yu@163.com
Subject: Re: [openstack-dev] [devstack] How to enable SSL in devStack?
Message-ID: 578FB4DE.8080500@redhat.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Rob Crittenden wrote:

Andrey Pavlov wrote:

Hi,

When I ran devstack with SSL I found a bug and tried to fix it -
https://review.openstack.org/#/c/242812/
But no one agree with me.
Try to apply this patch - it may help.
Also there is a chance that new bugs present in devstack that
prevented to install it with SSL.

Seeing how some other things in your local.conf might help but when I
tried to reproduce it I got the same error and it failed because Apache
didn't have an SSL listener on 443.

I'm not sure I'd recommend direct SSL in any case. I'd recommend the
tls-proxy service instead. Note that I'm pretty sure it has the same
problem: it hasn't been updated to handle port 443 for Keystone.

I'm working on switching from stud to mod_proxy if you want to take a
look and this problem is fixed there,
https://review.openstack.org/301172

I'll see about adding a SSL listener to Keystone for the USE_SSL case in
the next few days.

And yeah, it's a moving target. I have an experimental gate test for
tlsproxy but it has to be requested explicitly. My plan is to enable it
as non-voting once the mod_proxy changes land so it will at least be
more obvious when things break (or maybe we can making it voting).

Fixing Keystone is easy. An Apache VirtualHost for 443 needs to be added.

But I found another, deeper problem: cinder won't listen on SSL. When
they switched to using oslo_service for WSGI they completely removed the
ability to use SSL. See bug https://bugs.launchpad.net/cinder/+bug/1590901

rob


Message: 27
Date: Wed, 20 Jul 2016 10:37:13 -0700
From: Clint Byrum clint@fewbar.com
To: "\"OpenStack Development Mailing List (not for usage questions)\""
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
for all)
Message-ID: 1469035947-sup-1293@fewbar.com
Content-Type: text/plain; charset=UTF-8

Excerpts from James Bottomley's message of 2016-07-20 08:31:34 -0700:

So this is where the Open Source method takes over. Change is produced
by those people who most care about it because they're invested. To
take your Cinder example, you're unlikely to find them within Cinder
because any project has inertia that resists change. It takes the
energy of the outside group X to force the change to Y, but this means
that X often gets to propose, develop and even code Y. Essentially
they become drive by coders for Cinder. This is where Open Source
differs from Enterprise because you have the code and the access, you
can do this. However, you have to remember the inertia problem and
build what you're trying to do as incrementally as possible: the larger
the change, the bigger the resistance to it. It's also a good test of
the value of the change: if group X can't really be bothered to code it
(and Cinder doesn't want it) then perhaps there's not really enough
value in it anyway and it shouldn't happen.

Thanks so much for stating this James. I couldn't agree more. A group
that can actually accomplish change, and not just suggest it, is
exactly what we're working to start with the architecture WG. There are
plenty of people with the will to change, and I feel strongly that if
those people are given a structure and support, then they'll find the
time and space to complete these objectives.

I just want to make one nuance point about Cinder changes: the recent
DLM work, done outside any architecture working group, did actually come
from both inside and outside Cinder. The Cinder team realized something
was happening that would perhaps affect everyone, and raised it to the
cross-project level, which helped external individuals get involved. So
these initiatives can come from either direction. The key is that enough
momentum builds up to counter the natural inertia that you mentioned in
your message.


Message: 28
Date: Wed, 20 Jul 2016 20:49:47 +0300
From: Sagi Shnaidman sshnaidm@redhat.com
To: Alan Pevec alan.pevec@redhat.com
Cc: James Slagle jslagle@redhat.com, "OpenStack Development Mailing
List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [TripleO] Delorean fail blocks CI for
stable branches
Message-ID:
<CAGHQP9yJQ4sRbpq=XEAmzfixsmOm27FA=
a__ROboTLDbY_yJZg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

How then it worked before? Can you show me the patch that broke this
functionality in delorean? It should be about 15 Jul when jobs started to
fail.
How then master branch works? It also runs on patched repo and succeeds.

I don't think we can use this workaround, each time this source file will
change - all our jobs will fail again? It's not even a workaround.
Please let's stop discussing and let's solve it finally, it blocks our CI
for stable patches.
I'd expect for a little bit more involvement in this issue and suggest you
or anybody who understand well delorean code and specs will try to solve it
when I provide him a whole TripleO CI dev environment with walking through
every CI step and any other info I can provide. Let's just sit and solve
it, otherwise we'll never get it working.

Thanks

On Wed, Jul 20, 2016 at 7:50 PM, Alan Pevec apevec@redhat.com wrote:

as a quickfix in tripleo.sh you could patch dlrn and set local=True in

correction, patch local=False there while running dlrn command with
--local to keep source checkout as-is

--
Best regards
Sagi Shnaidman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/be70d6f1/attachment-0001.html
>


Message: 29
Date: Wed, 20 Jul 2016 11:08:43 -0700
From: Jay Pipes jaypipes@gmail.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags -
Manage Capabilities with ResourceProvider
Message-ID: 00dc5392-3edc-5174-91ed-c9d048fa8036@gmail.com
Content-Type: text/plain; charset=windows-1252; format=flowed

On 07/18/2016 01:45 PM, Matt Riedemann wrote:

On 7/15/2016 8:06 PM, Alex Xu wrote:

Actually I still think aggregates isn't good for Manage Caps, just as I
said in previous reply about Aggregates. One of reason is just same with

2 you said :) And It's totally not managable. User is even no way to

query a specific host in which host-aggregate. And there isn't a
interface to query what metadata was related to the host by
host-aggregate. I prefer just keep the Aggregate as tool to group the
hosts. But yes, user still can use host-aggregate to manage host with
old way, let's user decide what is more convenient.

+1 to Alex's point. I just read through this thread and had the same
thought. If the point is to reduce complexity in the system and surface
capabilities to the end user, let's do that with resource provider tags,
not a mix of host aggregate metadata and resource provider tags so that
an operator has to set both, but also know in what situations he/she has
to set it and where.

Yeah, having the resource provider be tagged with capabilities versus
having to manage aggregate tags may make some of the qualitative
matching queries easier to grok. The query performance won't necessarily
be any better, but they will likely be easier to read...

I'm hoping Jay or someone channeling Jay can hold my hand and walk me
safely through the evil forest that is image properties / flavor extra
specs / scheduler hints / host aggregates / resource providers / and the
plethora of scheduler filters that use them to build a concrete
picture/story tying this all together. I'm thinking like use cases, what
does the operator need to do

Are you asking how things are currently done in Nova? If so, I'll need
to find some alcohol.

If you are asking about how we'd like all of the qualitative things to
be requested and queried in the new placement API, then less alcohol is
required.

The schema I'm thinking about on the placement engine side looks like this:

CREATE TABLE tags (
id INT NOT NULL,
name VARCHAR(200) NOT NULL,
PRIMARY KEY (id),
UNIQUE INDEX (name)
);

CREATE TABLE resourceprovidertags (
resourceproviderid INT NOT NULL
tagid INT NOT NULL,
PRIMARY KEY (resource
providerid, tagid),
INDEX (tag_id)
);

On the Nova side, we need a mechanism of associating a set of
capabilities that may either be required or preferred. The thing that we
currently use for associating requested things in Nova is the flavor, so
we'd need to define a mapping in Nova for the tags a flavor would
require or prefer.

CREATE TABLE flavortags (
flavor
id INT NOT NULL,
tagname VARCHAR(200) NOT NULL,
is
required INT NOT NULL
);

We would need to have a call in the placement REST API to find the
resource providers that matched a particular set of required or
preferred capability tags. Such a call might look like the following:

GET /resourceproviders
{
"resources": {
"VCPU": 2,
"MEMORY
MB": 2048,
"DISKGB": 100
},
"requires": [
"storage:ssd",
"compute:hw:x86:avx2",
],
"prefers": [
"compute:virt:accelerated
whizzybang"
]
}

Disregard the quantitative side of the above request right now. We could
answer the qualitative side of the equation with the following SQL query
in the placement engine:

SELECT rp.uuid
FROM resourceproviders AS rp, tags AS t1, tags AS t2, tags AS t3
INNER JOIN resource
providertags AS rpt1
ON rp.id = rpt1.resource
providerid
AND rpt1.tag
id = t1.id
INNER JOIN resourceprovidertags AS rpt2
AND rpt1.resourceproviderid = rpt2.resourceproviderid
AND rpt2.tagid = t2.id
LEFT JOIN resource
providertags AS rpt3
ON rp.id = rpt3.resource
providerid
AND rpt3.tag
id = t3.id
GROUP BY rp.uuid
ORDER BY COUNT(COALESCE(rpt3.resourceproviderid, 0)) DESC
WHERE t1.name = 'storage:ssd'
AND t2.name = 'compute:hw:x86:avx2'
AND t3.name IN ('compute:virt:accelerated_whizzybang')

The above returns all resource providers having the 'storage:ssd' and
'compute:hw:x86:avx2' tags and returns resource providers first that
have the 'compute:virt:accelerated_whizzybang' tag.

, what does the end user of the cloud need
to do, etc. I think if we're going to do resource providers tags for
capabilities we also need to think about what we're replacing. Maybe
that's just host aggregate metadata, but what's the deprecation plan for
that?

Good question, as usual. My expectation would be that in Ocata, when we
start adding the qualitative aspects to the placement REST API, we would
introduce documentation that operators could use to translate common use
cases that they were using flavor extra_specs and aggregate metadata for
in the pre-placement world to the resource provider tags setup that
would replace that functonality in the placement API world. Unlike most
of the quantitative side of things, there really isn't a good way to
"autoheal" or "autosetup" these things.

There is a ton to talk about here, so I'll leave that for the midcycle.
But let's think about what, if anything, needs to land in Newton to
enable us working on this in Ocata - but our priority for the midcycle
is really going to be focused on what things we need to get done yet in
Newton based on what we said we'd do in Austin.

Also, a final nit - can we please be specific about roles in this thread
and any specs? I see 'user' thrown around a lot, but there are different
kinds of users. Only admins can see host aggregates and their metadata.
And when we're talking about how these tags will be used, let's be clear
about who the actors are - admins or cloud users. It helps avoid some
confusion.

Correct. ONLY administrators can set, delete and associate tags with
resource providers. End users only see a flavor name IMHO. It would be
up to the deployer to document for end users whether and what
capabilities a particular flavor provides...

Best,
-jay


Message: 30
Date: Wed, 20 Jul 2016 11:15:44 -0700
From: Jay Pipes jaypipes@gmail.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags -
Manage Capabilities with ResourceProvider
Message-ID: 77e8e16b-4e8f-87b7-aa53-4d047ad7ade3@gmail.com
Content-Type: text/plain; charset=utf-8; format=flowed

On 07/13/2016 01:37 PM, Ed Leafe wrote:

On Jul 11, 2016, at 6:08 AM, Alex Xu soulxu@gmail.com wrote:

For example, the capabilities can be defined as:

COMPUTE_HW_CAP_CPU_AVX
COMPUTE_HW_CAP_CPU_SSE
....
COMPUTE_HV_CAP_LIVE_MIGRATION
COMPUTE_HV_CAP_LIVE_SNAPSHOT
....

( The COMPUTE means this is coming from Nova. HW means this is hardware
related Capabilities. HV means this is
capabilities of Hypervisor. But the catalog of Capabilities can be
discussed separated. This propose focus on the
ResourceTags. We also have another idea about not using 'PREFIX' to
manage the Tags. We can add attributes to the
Tags. Then we have more control on the Tags. This will describe
separately in the bottom. )

I was ready to start ranting about using horribly mangled names to
represent data, and then saw your comment about attributes for tags. Yes, a
thousand times yes to attributes! There can be several standards, such as
?compute? or ?networking? that we use for some basic cross-cloud
compatibility, but making them flexible is a must for adoption.

I disagree :) Adoption -- at least interoperable cloud adoption -- of
this functionality will likely be hindered by super-flexible description
of capabilities. I think having a set of "standard" capabilities that
can be counted on to be cross-OpenStack-cloud compatible and a set of
"dynamic" capabilities that are custom to a deployment would be a good
thing to do.

Best,
-jay

I can update the qualitative request spec to add ResourceProviderTags as
a possible implementation.


Message: 31
Date: Wed, 20 Jul 2016 18:18:42 +0000
From: "Fox, Kevin M" Kevin.Fox@pnnl.gov
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org, Clint Byrum <clint@fewbar.com
>
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
for all)
Message-ID:
1A3C52DFCD06494D8528644858247BF01B9A6DA7@EX10MBOX03.pnnl.gov
Content-Type: text/plain; charset="us-ascii"

I wish it was so simple. Its not.

There is a good coding practice:
"The code is done, not when there is nothing more to add, but nothing more
to remove"

Some of the more mature projects are in this mode of thinking now. (which
is mostly good, really). They don't want to add features unless they see it
as a benefit to their users. This is the problem, there is a disconnect
between the view of Project X's users, and greater view of OpenStack Users.

Even accepting the smallest of patches to work towards the goal is
unacceptable to projects if they believe it is not a helpful feature to
their perceived user base, or helpful enough to them to justify adding more
code to their project. Or the feeling that "just push it to a new project
or a different one is better". This fractured view of OpenStack users at
the project level is preventing progress on OpenStack as a whole.

Only an overarching Architectural group with some power to define what a
user is, or the TC can address those sorts of issues.

Thanks,
Kevin


From: James Bottomley [James.Bottomley@HansenPartnership.com]
Sent: Wednesday, July 20, 2016 9:57 AM
To: OpenStack Development Mailing List (not for usage questions); Clint
Byrum
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for
all)

On Wed, 2016-07-20 at 16:08 +0000, Fox, Kevin M wrote:

+1 to the finding of a middle ground.

Thanks ... I have actually been an enterprise architect (I just keep
very quiet about it when talking Open Source).

The problem I've seen with your suggested OpenSource solution is the
current social monetary system of OpenStack makes it extremely
difficult.

Each project currently prints its own currency. Reviews. It takes
quite a few Reviews (time/effort) on a project to gain enough
currency that you get payed attention to. And, one project doesn't
honor another projects currency.

OK, I accept your analogy, even though I would view currency as the
will to create and push patches.

The problem you describe: getting the recipients to listen and accept
your patches, is also a common one. The first essential is simple
minimal patches because they're hard to reject.

Once you've overcome the reject barrier, there's the indifference one
(no-one says no, but no-one says yes).

Overcoming indifference involves partly knowing who to bother and when
(In openstack, it's quite easy since you know who the core reviewers
are) and also building a consensus for the patch; usually this involves
finding other people who need the feature and getting them to pipe up
(if you can't find other projects, then you can get potential users to
do this) even better if they help you write the patches. Ideally, you
build your consensus before you actually push the patch set. Sometimes
building consensus involves looking beyond your particular need to a
bigger one that would satisfy you but also pulls other people in.

When these sorts of major cross project things need to be done
though, you need to have folks with capital in many different
projects and its very difficult to amass that much.

There is no OpenStack level currency (other then being elected as a
TC member) that gets one project to stop and take the time to
carefully consider what someone is saying when bringing up cross
project issues.

Without some shared currency, then the problem becomes, the person
invested in getting a solution, can propose and prototype and
implement the feature all they want (often several times), but it
never actually is accepted into the projects because a project:
a) doesn't take the time to really understand the problem, feeling
its trivial and just not accepting any reviews
b) doesn't take the time to really understand the problem, so
minimize it in their mind to a 'you should just use existing thing
X...' or a heavy handily propose alternate solutions that really
aren't solutions.
c) they decide its better handled by another project and stall/block
reviews, trying to push the implementation to go elsewhere. When
multiple projects decide this, the ball just keeps getting bounced
around without any solution for years.

The status quo is not working here. The current governance structure
doesn't support progress.

What you'll find you've described above is a process that doesn't
support drive by coders at all and, by extension therefore, doesn't
welcome newcomers, which is a big problem, but one I thought OpenStack
was tackling?

The bounce problem is annoying but not insuperable. It mostly occurs
where there's overlap. Often the best method for coping is to field
the bounce: produce the patch for the other project. If it's smaller
and neater, perhaps the bounce was correct. If it's bigger and uglier,
get the other project to say so and you now have a solid reason to go
back and say "we tried what you suggested and here's why it didn't
work". Morally, you're now on higher ground because incorrect
technical advice is a personal failure for whoever bounced you (make
sure to capitalise on it if they try another bounce).

James


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Message: 32
Date: Wed, 20 Jul 2016 21:24:53 +0300
From: Duncan Thomas duncan.thomas@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
for all)
Message-ID:
<CAOyZ2aH=
fbAh+ohbpYfYLnJnLbR0_MgbhX7YjSfkr1+iWUbHmw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On 20 July 2016 at 19:57, James Bottomley <
James.Bottomley@hansenpartnership.com> wrote:

OK, I accept your analogy, even though I would view currency as the
will to create and push patches.

The problem you describe: getting the recipients to listen and accept
your patches, is also a common one. The first essential is simple
minimal patches because they're hard to reject.

Once you've overcome the reject barrier, there's the indifference one
(no-one says no, but no-one says yes).

[snip]

The trouble with drive-by architecture patches (or large feature patches of
any kind) is that it is often better not to merge them if you don't think
the contributor is going to stick around for a while. This changes are
usually intrusive, and have repercussions that take time to discover. It's
often difficult to keep a change clean when the original author isn't
around to review the follow-on work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/7e9c1bfd/attachment-0001.html
>


Message: 33
Date: Wed, 20 Jul 2016 11:39:23 -0700
From: Billy Olsen billy.olsen@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [charms] Project mascot
Message-ID:
<CA+4oKthjupHFYf1iato_Zess+u=
kQumSCRZhFNz5iuWw67ok9w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

I like the idea of the Kraken...

though I think I like the giant squid over an octopus, but either one
is in the same vein :-)

On Mon, Jul 18, 2016 at 1:27 AM, James Page james.page@ubuntu.com wrote:

Hi All

As an approved project, we need to provide some ideas for a project
mascot
for the Charms project (see [0]).

Some suggestions as discussed on IRC:

1) cobra ('[snake] charming openstack') - which aligns with the Juju
logo a
little.
2) kraken ('many armed animal managing openstack') - but I think that
falls
into mythical creatures so its probably excluded so maybe octopus
instead?

It would be nice to have one or two more ideas - any suggestions?

Cheers

James

[0] http://www.openstack.org/project-mascots


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Message: 34
Date: Wed, 20 Jul 2016 18:43:55 +0000
From: "Mooney, Sean K" sean.k.mooney@intel.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags -
Manage Capabilities with ResourceProvider
Message-ID:
<
4B1BB321037C0849AAE171801564DFA65F3335CA@IRSMSX107.ger.corp.intel.com>

Content-Type: text/plain; charset="utf-8"

-----Original Message-----
From: Jay Pipes [mailto:jaypipes@gmail.com]
Sent: Wednesday, July 20, 2016 7:16 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags - Manage
Capabilities with ResourceProvider

On 07/13/2016 01:37 PM, Ed Leafe wrote:

On Jul 11, 2016, at 6:08 AM, Alex Xu soulxu@gmail.com wrote:

For example, the capabilities can be defined as:

COMPUTE_HW_CAP_CPU_AVX
COMPUTE_HW_CAP_CPU_SSE
....
COMPUTE_HV_CAP_LIVE_MIGRATION
COMPUTE_HV_CAP_LIVE_SNAPSHOT
....

( The COMPUTE means this is coming from Nova. HW means this is
hardware related Capabilities. HV means this is capabilities of
Hypervisor. But the catalog of Capabilities can be discussed
separated. This propose focus on the ResourceTags. We also have
another idea about not using 'PREFIX' to manage the Tags. We can add
attributes to the Tags. Then we have more control on the Tags. This
will describe separately in the bottom. )

I was ready to start ranting about using horribly mangled names to
represent data, and then saw your comment about attributes for tags.
Yes, a thousand times yes to attributes! There can be several
standards, such as ?compute? or ?networking? that we use for some basic
cross-cloud compatibility, but making them flexible is a must for
adoption.

I disagree :) Adoption -- at least interoperable cloud adoption -- of
this functionality will likely be hindered by super-flexible
description of capabilities. I think having a set of "standard"
capabilities that can be counted on to be cross-OpenStack-cloud
compatible and a set of "dynamic" capabilities that are custom to a
deployment would be a good thing to do.

[Mooney, Sean K]
I know there is a bad memories when I metion CIM (
http://www.dmtf.org/standards/cim)
for many on the nova team but if we are to use standard names we should
probably
actually assess are there existing standads that we could adopt instead of
defining
our own standard names in nova for the resources.
For example
http://schemas.dmtf.org/wbem/cim-html/2/CIM_ProcessorAllocationSettingData.html
Define the name for different instcution set extentions for example avx is
DMTF:x86:AVX.
Some work has been done in glance to allow importing cim metadata from ovf
files also

https://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cim-namespace-metadata-definitions.html

while I don?t think using the full cim information model is useful in this
case using the name would be
from an inter-operability point of view as we not only would have standard
names in openstack but those names
would conform to an existing standard.

We could still allow custom attribute but is see value in standardizing
what can be standardized.

Best,
-jay

I can update the qualitative request spec to add ResourceProviderTags
as a possible implementation.



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-
request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Message: 35
Date: Wed, 20 Jul 2016 19:01:06 +0000
From: Amrith Kumar amrith@tesora.com
To: "heidijoy@openstack.org" heidijoy@openstack.org
Cc: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Mascot/logo for your project
Message-ID:
<
CO2PR17MB0011B89DCABCD8C561183275A0080@CO2PR17MB0011.namprd17.prod.outlook.com
>

Content-Type: text/plain; charset="utf-8"

Heidi,

The Trove team came up with several logo options. The result of a vote was
decisive:

  1. Stingray [1]

  2. A Clam with a Pearl in it. [2]

I have heard of no one else wanting to use the Stingray so I would like to
request that the foundation consider that our preference.

Among the options suggested was ?Salmonella?. One person (nameless)
explained it to me as ?A small female fish?. The community will be happy to
know that in the voting, Salmonella received zero votes. If any other team
would like to take the idea of salmonella after reading this email, I?d
request that they please credit the Trove team for this suggestion ? We
promise that we won?t use that logo and there will be no conflict. Here?s a
picture of ?salmonella? [3].

Other options which did not garner enough support included a whale, a
koala bear, and a sea dragon.

Thanks,

-amrith

[1] http://cdn.xl.thumbs.canstockphoto.com/canstock26887885.jpg
[2]
http://image.shutterstock.com/z/stock-photo-an-open-sea-shell-with-a-pearl-inside-52231675.jpg
[3] https://c2.staticflickr.com/8/7032/6400406229_f99d5e268e_b.jpg

From: Heidi Joy Tretheway [mailto:heidijoy@openstack.org]
Sent: Monday, July 11, 2016 11:00 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Mascot/logo for your project

The Foundation would like to help promote OpenStack projects in the big
tent with branding and marketing services. The idea is to create a family
of logos for OpenStack projects that are unique, yet immediately
identifiable as part of OpenStack. We?ll be using these logos to promote
your project on the OpenStack website, at the Summit and in marketing
materials.

We?re asking project teams to choose a mascot to represent as their logo.
Your team can select your own mascot, and then we?ll have an illustrator
create the logo for you (and we also plan to print some special collateral
for your team in Barcelona).

If your team already has a logo based on a mascot from nature, you?ll have
first priority to keep that mascot, and the illustrator will restyle it to
be consistent with the other projects. If you have a logo that doesn?t have
a mascot from nature, we encourage your team to choose a mascot.

Here?s an FAQ and examples of what the logos can look like:
http://www.openstack.org/project-mascots
We?ve also recorded a quick video with an overview of the project:
https://youtu.be/LOdsuNr2T-o

You can get in touch with your PTL to participate in the logo choice
discussion. If you have more questions, I?m happy to help. :-)

Cheers,
Heidi Joy


Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769 | skype: heidi.tretheway

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/299b7b6f/attachment-0001.html
>


Message: 36
Date: Wed, 20 Jul 2016 19:03:02 +0000
From: Amrith Kumar amrith@tesora.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [trove] no weekly meeting next week
Message-ID:
<
CO2PR17MB001125161A4E066C6ABF341BA0080@CO2PR17MB0011.namprd17.prod.outlook.com
>

Content-Type: text/plain; charset="us-ascii"

We won't have our weekly meeting next week as we are going to be meeting
anyway for our virtual mid-cycle.

Thanks,

-amrith


Message: 37
Date: Wed, 20 Jul 2016 12:22:56 -0700
From: Joshua Harlow harlowja@fastmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
for all)
Message-ID: 578FCF90.7080402@fastmail.com
Content-Type: text/plain; charset=UTF-8; format=flowed

Duncan Thomas wrote:

On 20 July 2016 at 19:57, James Bottomley
<James.Bottomley@hansenpartnership.com
James.Bottomley@hansenpartnership.com> wrote:

OK, I accept your analogy, even though I would view currency as the
will to create and push patches.

The problem you describe: getting the recipients to listen and accept
your patches, is also a common one.  The first essential is simple
minimal patches because they're hard to reject.

Once you've overcome the reject barrier, there's the indifference one
(no-one says no, but no-one says yes).

[snip]

The trouble with drive-by architecture patches (or large feature patches
of any kind) is that it is often better not to merge them if you don't
think the contributor is going to stick around for a while. This
changes are usually intrusive, and have repercussions that take time to
discover. It's often difficult to keep a change clean when the original
author isn't around to review the follow-on work.

Agreed, and knowing where yahoo and HP(e) are at right now (with regards
to openstack and ...) these kind of things are a little more prevalent
(with regards to quota, tasks...) now-a-days (for better or worse); not
how I want it to be but it's reality.

Which I guess is why I'd be nice to have cross-project architecture
'standardization' (? for lack of better word) with a more long term
strategic vision (vs localized tactical visions). Such things are
obviously not hard to get going (and are equally hard to sustain).

>
>


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

End of OpenStack-dev Digest, Vol 51, Issue 42



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jul 20, 2016 in openstack-dev by Data_Chennai (120 points)  
retagged Jan 26, 2017 by admin
...